Hi John, [...]
>> 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. >> > > There seems to be a strong consensus not to do that. It requires authorial > permission, for one thing (unlike adding the SPDX metadata). For another, > it creates complications when code or text are reused under a different > license. In order to conform to MIT, the text of the original license has > to be provided along with the reused code. We do not want two different > and apparently contradictory pieces of metadata. > > 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). >> > > That's not helpful when the file is copied to another repo. Good point. I believe the SPDX unique license identifiers hold by themselves in court, but I do see the [...] > A verbatim copy can't be placed under a new license, because the creator of > the copy is not an author. I understood "SRFI authors" as in original authors (rightsholders), so they have the right to dual license their work. >> 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. >> > > Be careful. Not all files support comments. I've yet to encounter one in practice, but SPDX has prepared for that. A license can be attached to a file-name.license file or mapped to a file within the .reuse/dep5 file. > 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. >> > > Or better yet left alone. Metadata is useful when a standard license is > employed, but it makes little sense for nonstandard licenses. That makes sense, but not for the aim of REUSE/SPDX, which is to be able to machine-read all the license files, compute an SPDX document, run automated checks, etc. For 'reuse lint' to pass, *every* file needs the SPDX-License-Identifier data, even the ones having custom licenses (on top of having a copyright notice). > 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). >> > > While I don't object *as strongly* to this approach as to removing text > from existing licenses, it has two problems: the location of the license > text can be in either of two places, and the license is not remotely > satisfied if the links break in the (multi-decade) future. I would have preferred doing away with the boilerplate for new SRFIs, but I see what you mean: since copying a few SRFI library files to a Scheme implementation is a common use case and otherwise people would need to think of carrying a LICENSES/MIT.txt around, which they may forget. I don't mind too much. One thing which is firm on my side though is that 'reuse lint' must pass, because it's great to have the support of tooling (and a total lack of ambiguity when it comes to licensing). -- Thanks, Maxim
