unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Philip McGrath <philip@philipmcgrath.com>
Cc: Guix Devel <guix-devel@gnu.org>
Subject: Re: License issue with SRFI 5
Date: Fri, 29 Oct 2021 16:44:14 +0200	[thread overview]
Message-ID: <87o877zy9t.fsf@gnu.org> (raw)
In-Reply-To: <eb9fb60a-ab1a-0690-12e2-6e4f728786d5@philipmcgrath.com> (Philip McGrath's message of "Fri, 22 Oct 2021 22:13:19 -0400")

Hi,

Philip McGrath <philip@philipmcgrath.com> skribis:

> Since 2005, SRFIs have used the MIT/Expat license, and all but two
> older SRFIs were relicensed: however, the SRFI editors were not able
> to contact the author of SRFI 5, Andy Gaynor, so it remains under the 
> original SRFI license.[1] That license, modeled on that of IETF RFCs,
> was intended to be quite permissive while also trying to ensure 
> derivative works would not be confused with the final, official SRFI
> itself. (The many versions of some SRFIs that nonetheless have come up 
> while hunting down related issues has given me some sympathy for that
> goal.) Unfortunately, the restrictions on modifications went to far,
> at least in the judgement of Debian and Fedora.
>
> Here is the license text, as it appears at
> <https://srfi.schemers.org/srfi-5/srfi-5.html> and 
> <https://docs.racket-lang.org/srfi-nf/srfi-std/srfi-5.html>:

Oh.

Do people actually use SRFI-5? (Honest question, I didn’t know about it
and don’t feel much appeal.)

Is there code inside Racket that uses it?

[...]

> Racketeers have high expectations of their documentation, like being
> able to right-click on an identifier in DrRacket (or the equivalent in 
> Emacs with racket-mode) and jump to the locally-installed
> documentation for the relevant binding according to lexical scope and
> the module system---even for a binding like `let`, which is defined by
> 27 different Racket modules, including `srfi/5`. My tentative plan is
> to write free replacement documentation for SRFI 5, eliminate
> everything from "srfi-doc-nonfree" but the official SRFI 5 document
> itself, and program the free SRFI 5 documentation (in Racket's
> Scribble language) to link to the SRFI 5 document at racket-lang.org
> if there isn't a local copy installed.
>
> This all raises a few questions about Guix policy:
>
>  1. Can Guix distribute the official SRFI 5 standard document under
>     the license listed above?

I don’t think so; it looks like a non-free software license to me.

>  2. If not, can Guix distribute free documentation that links
>     to an online copy of the official SRFI 5 standard document?

I think it would be easy to do a “clean room” section documenting SRFI-5
no?  I mean, once you know the spec, documenting it is trivial, to the
point that it’s even hardly copyrightable (there’s little invention).

>  3. Would it be permissible for the free documentation to
>     include instructions for installing the official SRFI 5 standard
>     document locally, e.g. `raco pkg install srfi-doc-nonfree`?
>     (Or perhaps `raco pkg install srfi-5-std-doc`, to avoid the
>     implication of arbitrary non-free materials?)

Per the FSDG, no.

[...]

> However, there are a few less-than-fully-developed sentences in the
> FSDG that cast some doubt, e.g., "Programs in the system should not
> suggest installing nonfree plugins, documentation, and so on."[8] I do
> not think this should be read to prohibit free documentation for free
> software for referring to restrictively licensed standards implemented

[...]

You’re right that the FSDG can be interpreted in different ways.
Hopefully its spirit is clearer than its wording.

For this case, I’d take the pragmatic approach (if Debian and Fedora
haven’t done it way) to either remove SRFI-5 from Racket if it’s
possible, or to do, like you suggest, a clean-room implementation of the
code and spec.  Rewriting is likely going to take less time and be more
fun than trying to disentangle all the issues you mention.

Again, it’s probably going to look very similar to the original code
(unless you use ‘syntax-parse’ for the fun of it :-)), but that’s
because there’s little code and there aren’t a thousand ways to do it.

Thanks for raising this issue; HTH!

Ludo’.


  reply	other threads:[~2021-10-29 14:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-23  2:13 License issue with SRFI 5 Philip McGrath
2021-10-29 14:44 ` Ludovic Courtès [this message]
2022-02-01  1:05   ` Philip McGrath
2022-03-07 10:41     ` Ludovic Courtès
2022-03-07 22:11       ` Philip McGrath

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o877zy9t.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=philip@philipmcgrath.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).