As a SRFI author, I prefer to have the license in text form in each (non-trivial) source file, making the files self-contained as far as licensing goes. This is not unimportant when files are copied or merged by users of the code.
I agree that only "canonical" and well-recognized licenses should be used. I don't believe in mass-copying SRFI sample implementations into Scheme systems/library distributions because the sample implementations are usually not tuned to a particular system or tuned at all. The time needed to check the licence is neglectable to the time needed to understand the code and tuning/rewriting it for a particular system. Marc Am Fr., 8. Dez. 2023 um 17:05 Uhr schrieb Maxim Cournoyer < [email protected]>: > Hi John, > > John Cowan <[email protected]> writes: > > [...] > > >> You write that: > >> > >> > It's > >> > also common for files to not carry any license header at all. > >> > > > > In my view, that means that they inherit their license from the SRFI > itself. > > Things can be a bit unwieldy when various licenses are mixed within the > same SRFI; I think explicit is also preferable over implicit. > > >> In addition to the machine-readable license > >> comment, I personally would suggest replacing the written-out text of > >> the license in new SRFI documents with a link to > >> <https://spdx.org/licenses/MIT.html>, relieving future readers of the > >> burden of determining that the text really is the SPDX-defined MIT > >> license and not one of many very slightly different licenses. > >> > > > > That could be done for future SRFIs, though I recommend against it (see > > below). > > > > Also, related to this comment from Maxim: > >> > >> > The activity of reviewing each source files for license information is > >> > also useful in its own, uncovering potential problems, such as the > >> > apparent use of a non-free (ethical) software license in the SRFI 125 > >> > implementation > >> > > > > Can you point to this? The author requests that copies of modifications > be > > sent to him, but does not require it; therefore that text is not part of > > the license. > > Here's the reference to the license notice blurb: > > https://github.com/scheme-requests-for-implementation/srfi-125/blob/0c11dec815d0d34eeb098eb97387ecc4bc1a212a/srfi/125.body.scm#L4 > > Note the "for any *lawful* purpose". That's subtle, but free software > licenses do not restrict use for *any* purpose, unlike ethical licenses. > Ethical licenses are thus not compatible with free software licenses. > > >> Furthermore, I think SRFI authors should be encouraged to consider at > >> least dual-licensing the sample implementation under the MIT license, as > >> the consistency is a benefit for downstream users and distributors of > >> SRFIs. > >> > > > > That's reasonable when the software is written by a SRFI author, but > that's > > not necessarily the case. > > > > though not all of the same considerations as with GPL-2.0-only > >> would apply here. > >> > > > > They certainly would not. The GPL-2.0-only license neither requires nor > > even recommends verbatim inclusion of the license text in the files to > > which it applies, whereas the MIT license unambiguously requires it. The > > MIT license text plainly says (emphasis added) "The above copyright > notice > > and this permission notice (including the next paragraph) *shall* be > > included in all copies or substantial portions of the Software." It does > > not say that a link to an outboard copy of the license is an adequate > > substitute for this requirement: the word "shall" implies that the > > requirement must be followed as written. > > The copy is not external to the repository; as Philip pointed out, it'd > live at LICENSES/MIT.txt in full. Having the license appear once in the > copy of the software and unambiguously referenced via SPDX license > identifiers doesn't seem like a very big leap, but I'm not a lawyer. > I'd assume lawyers to have pondered over the ramifications of using SPDX > though, as SPDX appears to be a well resourced initiative. > > > Therefore, removing the license text cannot be done without the consent > of > > the author. As the author (as a whole or in part) of more than fifty > > SRFIs, you do not have and will not get my consent to remove the license > > text from any of them. Adding the SPDX metadata is fine, but not a > > substitute for the requirement to provide a verbatim copy of the license > in > > any redistribution with or without modifications. > > OK. I'm fine with that for existing SRFIs/code out there; for newly > authored ones, could we agree to use SPDX-only metadata + LICENSES/ > files and let go of the usual license boilerplate, in the name of > brevity and making our lives easier? > > > Since I am prepared to be quite stroppy about this, I strongly recommend > > that no license texts be removed. The result would be a messy > > non-uniformity in which some SRFIs contain license text and others do > > not. > > I think it'd be a stretch to qualify the current state of things as > uniform. This current effort is about improving on that. I think going > with SPDX-only identifiers for new SRFIs and dropping the (non-uniformly > used) boilerplate would be a good step toward achieving it. > > [...] > > >> If the conclusion is that the existing text should be preserved vebatim > >> in existing files, note that a comment like ";; Copyright (c) 2010 > >> Derick Eddington" is recognized by the Reuse specification and tool, so > >> only the SPDX-License-Identifier comment would need to be added. > >> > > > > The proposed patch to SRFI 119, which is the only one I've seen so far, > > also changes certain existing ";;" comments into ";;;;" comments. That > > violates a strong convention of the Scheme (and indeed the wider Lisp) > > community that comments with four semicolons represent outline headings. > > See <https://mumble.net/~campbell/scheme/style.txt> s.v. "Outline > > Headings". Therefore, this change should be undone. > > Thanks for commenting on this. I had read that very document to chose > between three semicolons or four ones when sending this fix to the reuse > tool project [0] (the tool was currently using a single ';' for its > comments), and apparently got confused by the exact meaning of "heading > comments". I'll change it to ";;;". > > I'll update this PR and review the REUSE-related SRFI PRs to use ';;;' > instead of ';;;;'. > > [0] > https://github.com/fsfe/reuse-tool/pull/874/files#diff-f441bf32c60e08c14a86c914caff66b5bdb82373adb56ed77a26173e142a1253R444 > > -- > Thanks, > Maxim >
