[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
License issue with SRFI 5
License issue with SRFI 5
Fri, 22 Oct 2021 22:13:19 -0400
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.2
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. 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
Before going any further, let me emphasize that a great deal of progress
has been made since distro packagers first pointed out the problem.
First, there was work to separate the problematic SRFIs (plural, at the
time) into "srfi-lib-nonfree" and "srfi-doc-nonfree" Racket packages.
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. 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. So the
only problem remaining is the SRFI 5 standard document.
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
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
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
The first question is fundamental but less immediately important to me:
since Debian and Fedora, at least, have answered in the negative, that's
a scenario Racket will have to support. In FSDG terms, the SRFI 5
standard does seem like "information for practical use", so it probably
would need a free license. On the other hand, of course, FSDG standards
do allow some parts of documentation not to be modifiable. As a
practical matter, the permission for "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"---particularly
given "in part"---seems to grant just about every permission practically
necessary, and the part about "this document itself" could be read to
refer only to a document which purports to *be* the official SRFI 5
standard, rather than merely to be derived it. (But I am not a lawyer.)
I very much hope the answer to the second question is that, yes, we can
link to an online copy of the standard. It seems there is strong
precedent for this. The GCC manual  links directly to "the
authoritative manual on traditional Objective-C (1.0)" by NeXTstep,
hosted by GNUstep,  and the "authoritative manual on Objective-C 2.0
... from Apple" , neither of which appear to permit any modified
derivative works at all. The same page refers to various ISO C
standards, which AIUI are not even freely (gratis) distributed in final
published form, and links to a reading list  which in turn links to
numerous restrictively-licensed documents, from the ARM ABI standard
 to a monograph on the history of the C language .
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." I do not think
this should be read to prohibit free documentation for free software for
referring to restrictively licensed standards implemented by the
software. To interpret the guidelines---which themselves state that they
"are not complete"---I turn to broader statements about the rationale
for why free software needs free documentation: in short, so that
when users exercise their freedom  "to modify the software, and add
or change its features, if they are conscientious they will change the
manual too—so they can provide accurate and usable documentation with
the modified program." As long as free documentation for the free
program implementing the standard exists, that criterion is
satisfied---and indeed there are subtleties I encountered when writing
the free implementation of SRFI 5 that are not clearly explained by the
standard. If someone modifies the free implementation, they are free to
modify the free documentation accordingly. There is no need to modify
the SRFI 5 standard document, and indeed any modified document would no
longer *be* the SRFI 5 standard as finalized on 1999-04-26 and amended
on 2003-01-27. Perhaps "standards" should not be in precisely the same
category as "documentation" in general. Of course, we should advocate
for standards to be freely licensed, too! But when restrictively
licensed standards exist, free programs can implement them, and I think
their free documentation need not be coy about referring to the official
standard document, especially if adequate free documentation exists for
the free implementation.
Finally, there is the question of whether instructions could be provided
for changing the hyperlinks in your local installation of some free
documentation to point to a copy of the restrictively-licensed standard
that you have downloaded to your machine, rather than a copy on the
internet. I do not see what good purpose would be served by prohibiting
this. Indeed, offline documentation advances positive goods like privacy
that Guix should support. Perhaps this is also a reason to answer the
first question in the affirmative.
I wish, albeit with the benefit of hindsight, that SRFIs had used a
well-known and unambiguously libre license from the start---or, again,
that someone might manage to contact Andy Gaynor and secure permission
for relicensing. While the status quo persists, I want to provide the
best-integrated free documentation for SRFI 5 I can.
Thanks for bearing with this long email. I hope we can think through
together how Guix's principles ought to apply to the case of the SRFI 5
- License issue with SRFI 5,
Philip McGrath <=