Hi John, John Cowan <xxxxxx@ccil.org> 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
