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

[bremner]

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

[bremner]

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.

[jeapostrophe]

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

[samth]

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.

[samth]

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

[bremner]

Jay McCarthy <notifications@github.com> writes:

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

I wouldn't say it blocks me, just creates some inconvenience, and it means the tarball debian distributes is not identical to the one that PLT does, which makes e.g. tamper detection harder. d

[jeapostrophe]

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?

[bremner]

Jay McCarthy <notifications@github.com> writes:

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?

I guess as long as you don't want to claim that everything you distribute is (re)-licensed under some umbrella license, distributing those (unmodifed) files is fine. Practically it will probably slow down the distro packaging of new releases a bit, since it's a bit of busywork. d

[samth]

Well, at least for srfi 32, we can just update the file to one with a permissive license.

…

On Oct 27, 2017 1:50 PM, "bremner" ***@***.***> wrote: Jay McCarthy ***@***.***> writes: > 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? > I guess as long as you don't want to claim that everything you distribute is (re)-licensed under some umbrella license, distributing those (unmodifed) files is fine. Practically it will probably slow down the distro packaging of new releases a bit, since it's a bit of busywork. d — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAO7883DvhH6vJrgvVl3YQZQZppJk8auks5swkIcgaJpZM4Px2K_> .

[samth]

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.

[dbenoit17]

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.