add license to package info.rkt files

[LiberalArtist]

Related to racket/racket#3760.

Note: I haven't attempted to characterize the license of srfi-doc-nonfree.

[samth]

I think many of the SRFIs are licensed under an MIT-like license, as here: https://srfi.schemers.org/srfi-71/srfi-71.html

[LiberalArtist]

Right, SRFIs since 2005 have been under the MIT license, and all but two of the earlier SRFIs were re-licensed under the MIT license (according to @dvanhorn, in https://srfi-email.schemers.org/srfi-announce/msg/2652023/). I think (Apache-2.0 OR MIT) works fine for those, though I guess it could more pedantically be (MIT AND (Apache-2.0 OR MIT)).

The issue is with the srfi-doc-nonfree package, as raised in #4 and further discussed in #5 and #7. I was going to need to follow up on this anyway, since I've sort of stumbled into packaging Racket for Guix, which has similarly strict (though substantively different) license rules as Debian and Fedora. As I refresh my memory, there are two, slightly different, issues:

1. SRFI 5 is one of the two SRFIs which, per @dvanhorn's announcement, "remain licensed under the RFC-style license since we have not been able to contact the authors"—in this case, Andy Gaynor. Ideally, of course, someone would find him, but we presumably have to move forward assuming that won't happen. The old SRFI license, which apparently was based on the IETF RFC license, doesn't have a SPDX identifier:

   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.

2. SRFI 29 is more complicated. [Here I confused SRFI 32, which is ok now, with SRFI 29, which is still a problem. See https://github.com/add license to package info.rkt files #12#issuecomment-949704640 below for the real state of SRFI 29.] There is an MIT-licensed version at https://srfi.schemers.org/srfi-32/srfi-32.html, but you (@samth) said in srfi-lib/srfi/32/sort.txt, srfi-doc/srfi/scribblings/srfi-{5,29}.html licensing looks incompatible with LGPL  #4 (comment) that:

   So, the version in the source code for SRFI 32 is somewhat newer and in line with the source code, but I can't find the source of it at all. The source on Olin's web site, and on the SRFI site, has an earlier version of the text. I can't find the text we have anywhere on the internet.

   (This comment gives me some sympathy for the intent of the original license.)

   It's possible the situation may have changed: https://srfi.schemers.org/srfi-32/srfi-32.html says it is a (withdrawn!) version from 2003 converted to HTML in 2019 (so after @samth looked in 2017), whereas the version in srfi-doc-nonfree says:

   srfi/srfi-doc-nonfree/srfi/scribblings/srfi-std/srfi-29.html

   Lines 502 to 504 in bc905dd

   	<!-- Created: Tue Sep 29 19:20:08 EDT 1998 -->
   	<!-- hhmts start -->Last modified: Mon Jun 17 12:00:08 Pacific
   	Daylight Time 2002 <!-- hhmts end --> <br>

   
   I will investigate that further. If we can find an MIT-licensed version of SRFI 32 that corresponds to what Racket ships, that would be ideal.

As I said in #7 (comment) (and tangentially in #8), I'm prepared to do some work to improve the documentation situation for users of Debian, Guix, Fedora, and other distros with strict license policies, including writing replacement documentation and falling back gracefully to docs.racket-lang.org versions if the documents aren't installed locally. I'd like I do along those lines works with all of the various policies, with minimal patching and the best possible experience for users. Probably I should ping @bremner and @dbenoit17 here.

My understanding of the Debian Free Software Guidelines is that the restrictions on modification in the old SRFI license would prevent distributing these documents in main, but I think it would be ok to link to online versions, like my Debian-packaged Emacs does for CC-BY-ND-4.0 essays. I'm less sure about the Free System Distribution Guidelines that apply to Guix: they allow some non-modifiable things, but in other cases (I hope not this one!) don't allow linking to things they can't distribute. I will need to open a discussion on the mailing list, which would probably be useful anyway, Guix having a high concentration of Schemers who care about licensing. I'm least sure about Fedora's policy: it's been well over a decade since I've spent time on the RPM side of things.

That leaves the question of what to put in srfi-doc-nonfree/info.rkt:

• I don't know any SPDX identifier that would cover the old SRFI license. If someone does, we should use that.
• I guess we could submit a request for SPDX to add the license, but I think it's less compelling than add license to package info.rkt files (special case) r5rs#4, since it's strictly historical, and my goal would be to isolate the restrictively-licensed stuff as much as possible.
• My inclination would be to leave the file without (define license ...) at all, and just add a comment explaining the situation. The lack of license information would signal an issue to anyone looking, and it seems like less work than properly encoding the problematic license.

[samth]

I vote for the add-a-comment approach (and I'm happy to hear that you might be able to fix the problem entirely).

[samth]

As far as I can tell, the text in srfi-32.txt is identical to the text at https://srfi.schemers.org/srfi-32/srfi-32.html, so maybe that newer version has resolved the problem, which would be nice.

Also, your discussion mentions SRFI 29 but then talks about SRFI 32. Which do you mean?

[LiberalArtist]

As far as I can tell, the text in srfi-32.txt is identical to the text at https://srfi.schemers.org/srfi-32/srfi-32.html, so maybe that newer version has resolved the problem, which would be nice.

Also, your discussion mentions SRFI 29 but then talks about SRFI 32. Which do you mean?

Ah, that was me getting confused: SRFI 32's issues were fixed by @dbenoit17 in #5.

SRFI 29 is the one that is still in srfi-doc-nonfree. According to @dvanhorn in https://srfi-email.schemers.org/srfi-announce/msg/2652023/, it should be covered by the MIT license, but the version at https://srfi.schemers.org/srfi-29/srfi-29.html, like the version in this repository, still has the old SRFI license. I'll look into the situation further, and also edit my comment here to reduce confusion.

SRFI 5 is as I described above.

[LiberalArtist]

I've sent a message at https://srfi-email.schemers.org/srfi-discuss/msg/17981856/ (also at https://srfi-email.schemers.org/srfi-29/msg/17981842/) asking to clarify that the SRFI 29 document is under the MIT license.

In any case, for now, I'll update this PR to add a comment addressing the status quo.

[LiberalArtist]

I've force-pushed new commits (and also rebased, because apparently I'd started from a stale fork).