Giters

racket / srfi

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

srfi-lib/srfi/32/sort.txt, srfi-doc/srfi/scribblings/srfi-{5,29}.html licensing looks incompatible with LGPL

bremner opened this issue · comments

commented

The statement "this document itself may not be modified in any way" seems to be incompatible with the top level LGPL license. Possibly unrelated, but I didn't find documentation for srfi/32 on docs.racket-lang.org

commented

Same issue for srfi-doc/srfi/scribblings/srfi-std/srfi-29.html, srfi/scribblings/srfi-std/srfi-5.html

I'm happy to open seperate issues if that's less annoying.

commented

@samth Can you weigh in on this? Can we just delete the documentation, given that it is legacy stuff? Maybe provide a link to the SRFI site so we are not distributing it? The Debian maintainers think this will block them, as well as Fedora.

commented

I think these are not combined with anything else in the Racket distribution, and thus we're just distributing them in a way consistent with their license. However, if people want to remove them in further distribution of Racket, that seems fine too. Do we need to remove them ourselves for that to happen?

Also, I thought srfis had a license they were supposed to follow.

commented

At least 32 is available under a less restrictive license here: https://srfi.schemers.org/srfi-32/srfi-32.txt

commented
commented

I guess, we don't need to remove them and the only downside is if the online docs disagree with local, but that happens anyways because of packages. So, I'll be closing this issue and just advising distributors that care that it is okay to delete the files as they need?

commented
commented
commented

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.

commented

Based on the wording of the licences, it is arguable that since the SRFIs contain code directly from the sample implementations, they should be considered derivatives subject to the same terms as the specifications themselves.

I have just finished an update to help lessen the impact of this issue for package maintainers, and I will submit a PR.

commented

Sorry, I didn't know about the license issue with SRFI 29. It was supposed to have been switched to the MIT license in 2005 when almost all the other SRFIs were transitioned, but somehow that didn't happen. I've checked with the author, Scott Miller, and he agreed to the change, so I've just updated the license.

I'm just mentioning this change in case you need to take some action for SRFI 29 in Racket. It's my understanding that it affects packaging for Debian.

Thanks to Philip McGrath for reporting this issue.

commented

@arthurgleckler Thanks very much! (And wow, that was fast!)

As I discussed with @samth in #12, I'll plan to move the MIT-licensed SRFI 29 document from scheme-requests-for-implementation/srfi-29@8790e9a into the free srfi-doc package and shrink srfi-doc-nonfree down to only the absolute minimal files that cause problems for Debian, Guix, or Fedora packaging, basically along the lines of what I was considering in #7 (comment): ideally, as long as it works with everyone's policies, we can just have Scribble link to the SRFI 5 document online if a local copy isn't installed.

(@arthurgleckler, @dvanhorn said in https://srfi-email.schemers.org/srfi-announce/msg/2652023/ that they weren't able to contact the author of SRFI 5, Andy Gaynor, back in 2005, so it never switched to the MIT license.)

commented

I've started a thread on the guix-devel mailing list to clarify Guix's policy in this case: https://lists.gnu.org/archive/html/guix-devel/2021-10/msg00220.html

I'm particularly interested also in confirming Debian, Fedora, or others' answers to three questions (@dbenoit17? @bremner?):

  1. Can your distro distribute the official SRFI 5 standard document under its current license?

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

  3. Would it be permissible for your distro's 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?)

IIUC, the answers are "no," "yes," "yes."

Again, my goal is to come up with a solution that works well, with a minimum of patching, for all distros with strict licensing policies, whatever they may be (and regardless of my personal policy preferences).

commented

@arthurgleckler As I've been working on updating Racket's copy of SRFI 29, I noticed that Racket at some point added anchors for linking to the specifications of individual identifiers, which are not present in the upstream version (and never were—I've looked through the entire Git history). For example, compare

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

Line 106 in 736ae1a

<p><b><a name="current-language"></a><tt>current-language</tt></b> <tt>-&gt;
to https://github.com/scheme-requests-for-implementation/srfi-29/blob/e39958a31c97af26f2f6a3d14fa027e09de15feb/srfi-29.html#L117.

I want to take this opportunity to sync all of Racket's SRFI HTML documents with the vastly improved upstream markup (e.g. for #8). I'd be happy to make pull requests to the @scheme-requests-for-implementation repositories to add any missing anchors, but I wanted to check (a) if that would be desirable and (b) if I should just do it by hand or if there are scripts I ought to use.

commented