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

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. For details, see
<https://srfi-email.schemers.org/srfi-announce/msg/2652023/>. (It is
indicative of the thorny details that come up in this area that the
announcement email called it "the MIT (X11) license", but the actual
text of the license, both in the email and as used in practice by SRFIs,
is the MIT/Expat license, without the advertising clause that
distinguishes the X11 license. One of the benefits of SPDX, in addition
to the namespace of licenses, is the XML specification of what text
actually matches each license.)

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>:

> 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?

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.

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.

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.

(Tangentially, in case it is useful for anyone, I designed for Racket a
grammar of "license S-expressions" for representing an SPDX license
expression as a Scheme datum, with the useful property that Scheme's
normal `write` will emit text conforming to the character-based grammar
of the SPDX standard. The documentation is at
<https://docs.racket-lang.org/pkg/metadata.html#%28tech._license._s._expression%29>.)

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.

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

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"!).

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.

Thanks again for diving into this thorny thicket,
Philip