Re: License issue with SRFI 5

[Philip McGrath]

Hi,

On Monday, March 7, 2022 5:41:46 AM EST Ludovic Courtès wrote:
> Hi,
> 
> Philip McGrath  skribis:
> > To start with that, my proposed approach, which I hope satisfies the
> > FSDG, is here: https://github.com/racket/srfi/pull/15
> 
> Good to know; I hope the next Racket release will include it.
> 

Yes! It's been merged upstream, so it will be in 8.5 (and snapshots, 
meanwhile), and we've included it in Guix as of the recent update to Racket 
8.4.

-Philip

signature.asc
Description: This is a digitally signed message part.

Re: License issue with SRFI 5

[Ludovic Courtès]

Hi,

Philip McGrath  skribis:

> To start with that, my proposed approach, which I hope satisfies the 
> FSDG, is here: https://github.com/racket/srfi/pull/15

Good to know; I hope the next Racket release will include it.

Thank you,
Ludo’.

Re: License issue with SRFI 5

[Philip McGrath]

Hi,

On 10/29/21 10:44, Ludovic Courtès wrote:

Hi,


This reply has taken a while because I did as you suggested and wrote 
some free replacement documentation (which involved paging back in some 
confusing details[1] and shaving several yaks), so now we have something 
concrete to talk about.


To start with that, my proposed approach, which I hope satisfies the 
FSDG, is here: https://github.com/racket/srfi/pull/15


There are some loose ends to tie up (e.g. I have 48 pull requests open 
making tedious changes to the HTML markup of SRFI specification 
documents to bring Racket's version into alignment with upstream, which 
the current SRFI editor, Arthur Gleckler, is stalwartly reviewing), but 
Guix can cherry-pick it on top of Racket 8.4 (which may be released as 
soon as this week).


The question is, do these changes resolve the situation for Guix (as I 
hope they do for Debian and Fedora, too), or is there anything 
more/different that needs to be done?




Philip McGrath  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
 and
:


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?


In short, no.

When the Debian package maintainer first discovered the problem in late 
2017 [2], the conclusion was that SRFI 5 wasn't used by any other part 
of Racket. The workaround [3] contributed by the Fedora package 
maintainer in early 2018 was to move the offending files into new 
"srfi-lib-nonfree" and "srfi-doc-nonfree" packages and for distribution 
maintainers to patch out the dependencies on them from the "srfi" 
package. This was all to accommodate Racket's exceptionally strong 
commitment to backwards compatibility, because it's a breaking change 
for a Racket package to stop providing a particular module (or 
documentation for a module) without adding an `implies` dependency on 
the new package it has moved to, and Racket packages are never supposed 
to make breaking changes. (The idea is you should make a new package 
under a different name, analogous to how a Debian system could have both 
the "guile-2.2" and the "guile-3.0" packages installed.)


(At the time there were also issues with SRFIs 32 and 29 at the time, 
but those had actually been relicensed to MIT/Expat; it was just a 
matter of resolving lots of confusing different versions of things.)


I then noticed "srfi-lib-nonfree" fly across my terminal, learned of the 
whole mess, and contributed a free reimplementation of SRFI 5 in 2019 
[4], using `syntax-parse` to give vastly better error reporting. At that 
point "srfi-lib-nonfree" became an empty, free package that exists only 
to provide an `implies` dependency on "srfi-lib".


According to [5], though, SRFI 5 is also implemented for Chez, Gauche, 
Larceny, STklos, and Scsh: I'm in the process of adapting my free 
implementation and compatibility test suite, which covers various 
ambiguities and errata [1], to R6RS to send upstream, so hopefully no 
one has to deal with this headache again.





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`.


[...]



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).



This is what I've done.

With these changes, documentation for the `srfi/5` module points to the 
new, free Scribble documentation I've written. That let me remove the 
dependency from 

Re: License issue with SRFI 5

[Ludovic Courtès]

Hi,

Philip McGrath  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
>  and 
> :

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’.

License issue with SRFI 5

[Philip McGrath]

Hi Guix,

I was recently reminded of a thorny license issue with the SRFI 5 
standard document, which is part of the main Racket distribution. People 
from Racket, the SRFI community, Debian, and Fedora have taken steps to 
help mitigate the problem: I want to make some further improvements, but 
I first need clarity on what Guix's policy requires and permits.


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>:



Copyright (C) Andy Gaynor (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and 
derivative works that comment on or otherwise explain it or assist in its 
implementation may be prepared, copied, published and distributed, in whole or 
in part, without restriction of any kind, provided that the above copyright 
notice and this paragraph are included on all such copies and derivative works. 
However, this document itself may not be modified in any way, such as by 
removing the copyright notice or references to the Scheme Request For 
Implementation process or editors, except as needed for the purpose of 
developing SRFIs in which case the procedures for copyrights defined in the 
SRFI process must be followed, or as required to translate it into languages 
other than English.

The limited permissions granted above are perpetual and will not be revoked by 
the authors or their successors or assigns.

This document and the information contained herein is provided on an "AS IS" 
basis and THE AUTHOR AND THE SRFI EDITORS DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 
PARTICULAR PURPOSE.
Before going any further, let me emphasize that a great deal of progress 
has been made since distro packagers first pointed out the problem.[2] 
First, there was work to separate the problematic SRFIs (plural, at the 
time) into "srfi-lib-nonfree" and "srfi-doc-nonfree" Racket packages.[3] 
Distro packagers could cleanly remove these from their Racket 
distributions, and they also work properly if a user of the 
distro-packaged Racket explicitly decides to install them. Later, I 
wrote a free implementation of SRFI 5, so "srfi-lib-nonfree" is now 
(confusingly) free software, an empty package definition for backwards 
compatibility.[4] SRFI 29 was supposed to have been converted to the 
MIT/Expat license in 2005, but somehow was missed: just today, the 
current SRFI editor, Arthur Gleckler, confirmed the permission of the 
author, Scott Miller, and updated the official document.[5][6][7] So the 
only problem remaining is the SRFI 5 standard document.


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?

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

 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?)

(Of course, if someone can manage to contact Andy Gaynor, that would be 
even better!)


The first question is fundamental