Hi!

Philip McGrath <xxxxxx@philipmcgrath.com> writes:

> Hi,
>
> Yes, thanks, Maxim, for looking into this issue. I've also spent some
> time digging into license issues with historical SRFIs, as they
> affected some of the SRFIs distributed with Racket. (In particular,
> I've worked to ensure that the main Racket distribution satisfies the
> Debian Free Software Guidelines, Guix's Free System Distribution
> Guidelines, and every other set of guidelines I'm aware of.)

I think you meant the GNU Free System Distribution Guidelines (rather
than Guix) here, right? (GNU FSDG).

> Broadly, I think clear and accurate license information is a good
> thing, and the https://reuse.software guidelines are indeed a
> relatively quick and easy way to record that information. I do have a
> few questions, though.
>
> As I understand the historical situation, when the SRFI process began
> in 1998, it adopted a variant of the IETF RFC license. The license was
> intended to be very permissive, but it also tried to ensure that
> derivative works would not be confused with the final, immutable SRFI
> document itself. (I have gained some sympathy for this goal as, when
> hunting down related issues, I have encountered and tried to reconcile
> subtly different versions of a few SRFI documents.) Unfortunately, in
> the judgement of Debian, Fedora, and others, the restrictions on
> modification went too far.
>
> In 2005, the SRFI editors undertook a relicensing process, changing
> the license for new SRFIs to MIT/Expat and relicensing all older SRFIs
> except for SRFI 5 and SRFI 24, for which they were unable to contact
> the authors.

[...]

> My understanding is that, since 2005, the SRFI process has included
> essentially unchanged requirement 9 under "Structure" in the current
> <https://srfi.schemers.org/srfi-process.html>:

Interesting background information.  I haven't encountered the IETF RFC
license yet in the SRFIs surveyed, and looking at SRFI 5 and 24,
thankfully only SRFI 5 (which has been withdawn) appears to still be
using it [0, 1].

[0]  https://github.com/scheme-requests-for-implementation/srfi-5/blob/755600f7b066ebbfd570e74397a1e2b94eba9be3/srfi-5.html#L325
[1]  https://github.com/scheme-requests-for-implementation/srfi-24/blob/09c37bf07f8339a1130a47d000bdb2d0a22a53df/srfi-24.html#L322

>> The SRFI document] must contain a copyright statement as follows
>> (where AUTHOR should be replaced by the name(s) of the author(s)
>>  and YEAR will be the year in which the SRFI number is allocated):
>> [ ... text of the MIT/Expat license ... ]
>> In addition to the SRFI document, any software written
>> specifically for the SRFI should be published under the above
>> license.  However, at the editors' discretion, the SRFI may
>> reference software that was already written and published under
>> another license, citing that software as its sample
>> implementation.  The BSD 2- and 3-clause licenses are
>> specifically allowed for this purpose
>
> Maxim, have you (or has anyone else) found any cases that appear to be
> inconsistent with this requirement?

Yes, it's not true that every SRFI source out there is licensed using
the set of {MIT, BSD-2-Clause, BSD-3-Clause} licenses.  Some are public
domain, some using the SLIB license, some are custom, etc.  They are
rather far and few in between, but this situation exists.

> You write that:
>
>> The srfi-N.html specification text often carries an Expat
>> (MIT) license text and copyright notice, but there are sometimes source
>> files that carry a different license, for example SRFI 120 [2].  It's
>> also common for files to not carry any license header at all.
>
> My understanding of the structure requirement is that *all*
> srfi-N.html documents should be under the MIT/Expat license except for
> the historical srfi-5.html and srfi-24.html. Sample implementations
> may use other licenses when specifically noted, but I think the
> requirement means that sample implementations that do not say
> otherwise should be included under the MIT/Expat SRFI license.

Yes, that's fair to assume, but in some cases there may be more than 2
licenses at play, in which case this assumption becomes a bit unwieldy.
Some guidelines, as those of the GNU project, suggest that every
non-trivial file should include a copyright and license notices [0].
Non-trivial in the context of copyright protection is defined elsewhere
in that document as 15 lines or more of code [1].  For remove any
ambiguity, I think it's best to stick to the REUSE guidelines of having
every file annotated with its license/copyright information.

[0]  https://www.gnu.org/prep/maintain/maintain.html#Copyright-Notices
[1]  https://www.gnu.org/prep/maintain/maintain.html#Legally-Significant

> If Maxim's proposal is adopted, I think the SRFI process document
> should be updated accordingly. 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.

Sounds like a good idea to me (noting as you did later that the license
text would still appear in a text file of the repo as LICENSES/MIT.txt).

> 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
>
> To avoid such potential problems, I would suggest that, where the
> process document gives SRFI editors discretion to allow sample
> implementations under other licenses, the document should at least
> strongly encourage, and perhaps even require, that the sample
> implementation use an existing broadly-accepted license.
>
> Here's one possible concrete guideline, as articulated in
> <https://sfconservancy.org/blog/2018/oct/16/mongodb-copyleft-drafting/>:
>
>> We de-facto instituted what my colleague Richard Fontana once
>> called the “Rule of Three” — assuring that any potential FOSS
>> license should be met with suspicion unless (a) the OSI declares
>> that it meets their Open Source Definition, (b) the FSF declares
>> that it meets their Free Software Definition, and (c) the Debian
>> Project declares that it meets their Debian Free Software Guidelines.
>
> 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 a good suggestion; if everything was either Expat (MIT) or dual
license with it as an option, it'd simplify the life of downstream
users, not having to manually review if the licenses used are compatible
with their Scheme project's own license.

[...]

> I also have some more specific questions and comments about the pull
> requests, for which I'll take
> <https://github.com/scheme-requests-for-implementation/srfi-104/pull/1>
> as an example.
>
> The commit adds a ".reuse/dep5" file. My understanding is that this is
> not required unless it is actually used to give license information
> for files that don't include it. either as comments or in adjacent
> ".license" files. Since it isn't used in this case, I think it
> shouldn't be included.

These files were generated when using 'reuse init'.  You are right that
they don't seem to be part of the REUSE spec (deleting the .reuse
directory doesn't cause 'reuse lint' to fail).  I'd keep them around
though, since they still define useful metadata for the project, such as
the 'Upstream-Name', 'Upstream-Contact' and 'Source' URL (git repository
location).

> The repository includes a ".gitignore" file that, before the new
> commit, contained only "*~". I'm not a lawyer, but I would be shocked
> if this file were actually uncopyrightable. The tutorial at
> <https://reuse.software/tutorial/#insignificant-files> and FAQ at
> <https://reuse.software/faq/#uncopyrightable> suggest CC0-1.0 for such
> files, which is what I do in my own projects. In fairness, though, the
> best way to handle such files is a thorny issue under ongoing
> discussion: see <https://github.com/fsfe/reuse-docs/issues/62>.

I pondered on that situation, also in the case where the files are
already waived from copyright via some public domain assignment text.
CC0 is to be used by the author of the files (the original copyright
holder) to waive the copyright, so we can't just mark existing public
domain files with CC0.  For files not covered by copyright because of
their insignificant content (e.g. tiny '.gitignore') files, it seems it
doesn't matter too much; CC0 would convey 'public domain' status well,
but means adding an extra LICENSES/CC0-1.0.txt verbose file just for
that.  I've opted for the pragmatic solution, which is to mark these
insignificant files as MIT licensed, knowing it wouldn't be found
protected by copyright in court anyway (no harm done), which was
suggested somewhere.

> In files like "library-files-utilities.r6rs-lib", the commit removes
> the comment with the full text of the license and replaces it with
> "SPDX-License-Identifier: MIT".
>
> Only after reading the diff several times to comment on this change
> for other reasons did I notice that this the text in this file
> includes an advertising clause, which means it is not the SPDX-defined
> MIT license. It is almost the X11 license, except for two issues: the
> advertising clause is before the warranty clause, instead of after it,
> and the advertising clause ends with "prior written authorization",
> but the SPDX markup for the X11 license (see
> <https://github.com/spdx/license-list-XML/blob/main/src/X11.xml> ends
> in:
>
> ```
> authorization from <alt match=".+" name="name3Disclaimer">the X
> Consortium.</alt>
> ```
>
> which means " from " is required. I encountered a similar issue with
> software derived from Tiny CLOS, which used text that did not quite
> match the SPDX definition of the Xerox license: you may want to open a
> PR like <https://github.com/spdx/license-list-XML/pull/1346> (and
> hopefully the SPDX lawyers won't consider this one "a more interesting
> question"!).

Good catch.  In light of the above, the license could be extracted to a
custom license, e.g. LICENSES/LicenseRef-Custom.txt and refered via the
LicenseRef-Custom identifier.

> The point I originally wanted to raise about this change is that,
> while I don't have a strong view about it myself, my understanding is
> that there has been some controversy over removing existing license
> comments when adding SPDX comments. (If it is permissible, my personal
> preference would probably be in favor of removal, again with the idea
> of relieving future readers of the burden of verifying weather the
> text is really what the identifier says or if very subtle changes
> might have snuck in.)
>
> The concern as I understand it is about language like, "The above
> copyright notice and this permission notice shall be included in all
> copies or substantial portions of the Software." Under some
> circumstances and some interpretations, concerns have been raised
> about whether removing the literal text of such notices might pose
> various potential issues. (Let me say once again that I am not a
> lawyer!) I've heard this concern raised in particular in the context
> of the Linux kernel, though not all of the same considerations as with
> GPL-2.0-only would apply here. There's some discussion in this thread,
> for example:
> <https://lore.kernel.org/linux-spdx/xxxxxx@ebb.org/>
>
> 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.
>
> Overall, I'm supportive of Maxim's proposal, but I think a great deal
> of care must be taken with the details to ensure that the license
> situation ends up unambiguously better, without introducing new
> potential problems. It might even be worth seeking guidance from a
> group like the Software Freedom Conservancy, which helped Racket to
> finish its years-long relicensing effort.

I agree that we must thread carefully.  One mistake I've made in one
(some?)  PRs (I'll change it) was to mark public domain work (with a
copyright waiver text) as CC0.  It's not my call to do so, so I should
instead use a custom public domain "license" via LicenseRef.

I'd prefer to take out the license text after it's extracted to
LICENSES/LicenseRef-SomeCustomLicense.txt instead of leaving it in to
keep things dry and consistent.

Perhaps a compromise could be: leave existing works text untouched (add
extra SPDX annotation only), while make it a policy for new SRFIs to use
strictly SPDX matching the REUSE guidelines? (with no license notice
embedded in each file).

--
Thanks,
Maxim