On 12/7/23 14:00, Arthur A. Gleckler wrote:
> On Thu, Dec 7, 2023 at 10:31 AM Wolfgang Corcoran-Mathe
> <xxxxxx@sigwinch.xyz <mailto:xxxxxx@sigwinch.xyz>> wrote:
>
>     I'm very dubious about replacing *all* license information with a
>     URL. SPDX is about 12 years old, according to Wikipedia.
>     Organizations come and go. Giving future lawyers a LICENSE file to
>     argue over seems better than giving them a dead link.
>
>
> That's a very good point.  Frankly, I'm surprised that a link to a
> license has legal standing.

To clarify, the <https://reuse.software> guidelines that Maxim proposed
adopting in fact require that a source repository contain the full texts
of all of the licenses it uses in files like "LICENSES/MIT.txt". The
name of the file must match the short identifier of the license, either
drawn from the published license list or using the form
"LicenseRef-MyStrangeLicense" for licenses not on the list.

When I wrote:

On 12/7/23 00:05, Philip McGrath wrote:
 >
 > 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.
 >

The link could just as well be to <./LICENSES/MIT.txt>. My suggestion
here is merely that, for new SRFIs, we reduce the number of separate
places that the full text of the MIT license is written out, to reduce
the danger of some of those places not precisely reproducing the
canonical license text. If that suggestion does not appeal, though, or
if more discussion is needed, I don't think it should block Maxim's
effort to add metadata.

Along similar lines:

On 12/7/23 07:22, Lassi Kortela wrote:
 >
 >> In my last email I wrote that it has the advantage that readers don't
 >> have to determine if the text is exactly the standard text, but it
 >> also has the disadvantage that copiers must be sure to also copy the
 >> separate file for the license.
 >
 > To change the license text to a standard wording, it'd be best to get
 > confirmation from each author.

If an existing file has text that is subtly different from the standard
MIT license, then its license is whatever that text actually says, even
if the differences from the standard text seem to us non-lawyers to be
trivial and likely inadvertent. I agree that the only way to change to
the standard license text is for the original author to agree to
relicense. My thoughts on how we might reduce the risk of such problems
in the future don't solve any cases that already exist.

The only way I'd consider licenses equivalent that are not absolutely
identical would be the SPDX matching guidelines (see
<https://spdx.github.io/spdx-spec/v2.3/license-matching-guidelines-and-templates/>),
which are supported by XML markup in the canonical license list. The
markup can encode variable parts of licenses, such as the name of the
actual copyright holder when inserted into MIT-style licenses. A very
important aspect is that such cases are cautiously evaluated by a group
of actual lawyers to ensure that any allowed variation is unambiguously
non-substantive without having "to make a judgment or interpretation".
The level of painstaking caution means that, for e.g. the Historical
Permission Notice and Disclaimer license, with the short identifier
HPND, we end up with HPND-sell-variant,
HPND-sell-variant-MIT-disclaimer,  HPND-sell-regexpr,  HPND-UC,
HPND-Markus-Kuhn, HPND-DEC, and many other subtly different variants
listed individually.

Philip