guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: License issue with SRFI 5


From: Ludovic Courtès
Subject: Re: License issue with SRFI 5
Date: Fri, 29 Oct 2021 16:44:14 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

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 via email to

[Prev in Thread] Current Thread [Next in Thread]