Re: SPDX files as templates


Warner Losh
 



On Tue, Nov 16, 2021 at 11:18 AM J Lovejoy <opensource@...> wrote:
Hi all,

This is a topic that came up some time ago (I think by way of the Reuse folks) and I’ve been meaning to raise it in a separate thread.

SPDX has a lot of license data by way of the SPDX License List and associated tooling and files. Some people are using that data to grab license text for as a kind of license template (as I understand it, but correct my terminology as need be!)  There were some opinions expressed that this is a bad idea - I’m not sure why.

The licenses for the SPDX License List are stored in two formats in the main repo: the XML format which applies some of the matching guidelines and other formatting and a plain .txt file. I believe it is the latter that some people may be using for the above scenario. For example, if someone wants to use the MIT license, for example, why wouldn’t they simply pull it from https://github.com/spdx/license-list-XML/blob/master/test/simpleTestForGenerator/MIT.txt ?

I am wondering if I have the scenario correct or are there other scenarios like this?
And if I’m pointing to where people are pulling the text from (or are other places being used? hopefully not the XML files or scraping the website!)

The plan for FreeBSD is to say that when there's an SPDX-License-Identifier: and no other grant of license, it should be construed (right word?) to include that identifier (eg MIT) from /usr/share/licenses/MIT.txt, as appropriate for the included expression. We plan on having this explicitly spelled out in our policies since this is, imho (not legal), it is no different than the GPL license saying "this is licensed under the GPL 2.0 or later" or whatever of the 100-odd variations on those words are. The policy makes the intent clear, both to contributors that are licensing their work, and to users who wish to be in compliance. We also plan to spell out that example copyright notices contained there in are by way of example only and the copyright notice is contained in the file doing the licensing, as well as similar language for spelling out that "author", "contributor" or "copyright hold" etc should be construed to be formed from the copyright notices in the file. But that's really awkwardly stated, I'm sure, and I've not yet run this past the legal folks that specialize in this area to know if that forms a "contract" or "agreement" or whatever the right term is between two parties that allows one party to copy the other party's work.
 
Relatedly, we have had requests to remove specific names in copyright notices so as to avoid anyone using the wrong notice. From an SPDX matching guidelines perspective, what name exists in the copyright notice does not matter, as that is not “matchable” text for the purposes of matching a license. I would also point out that anyone using the .txt files as a copy of the license for their own code, would *always* need to update the copyright notice - whether it has some other name or simply “author”. In any case, I don’t see this as a reason not to use the .txt files of the license text for other purpose outside of SPDX. And it’s fine for us to change those copyright notices to generic “author” or “name” if that helps.

Thoughts?

When people use the text, like we do, with an indirection, there's no chance to update the 'template' that's in the /usr/share/licenses directory, except via the templating operation I'm trying to document.  That's my use case.

Other projects seem to do this vary widely. Linux kernel documents this, to an extent. u-boot seems to document it by implication only. There seems to be no real standard here, with each project making it up as they go along down this path, but generally huing either to the Linux Kernel end of the spectrum (eg being explicit) or the u-boot end (people can figure it out) with little in between. Of course, my survey has been far from scientific or systematic.

Is that the feedback you are looking for? Or did I miss the boat?

Warner
 




Join Spdx-legal@lists.spdx.org to automatically receive all group messages.