Well, insanity question aside (because at some level, all of our sanity will need to be questioned because we deal with this ;) ), if you don't reproduce them (variations and all), you risk breaching

Hi Richard, Thanks for sharing this question. I've been mulling it over and don't have a good answer, so here instead are a few disjointed thoughts. My main hesitation with an "If-Needed-exception"

Hi everyone, On account of the US Thanksgiving holiday, we will not have an SPDX-legal team meeting tomorrow, Thursday, Nov 25th Have a great holiday or weekend and

Greetings, Over at Red Hat, we've been gradually increasing our support of the use of "SPDX-License-Identifier:" in source files for various reasons. We've encountered some situations where a

I'll point out that the variations are an enormous pain in the ass for FreeBSD and create more uncertainty and compliance issues not less. If I don't reproduce every single license in the tree,

If this was attempted some number of years ago, I'm not sure it would have been appropriate but things evolve. Through the efforts of SPDX and others, I think it is now very clear what these

There's no Linux drm code in FreeBSD proper. Certainly none with the new-style having the only SPDX-License-Identifier: tags (there's a few stragglers from some ancient drm implementation used only on

I'd personally rather we didn't even make the *appearance* of a recommendation that SPDX-License-Identifiers are suitable replacements for standard license headers. Especially with licenses that

Adding a couple of facts to the discussion: Over the last couple of releases, the license text field in the JSON and RDF representations as well as the license-list-data/text is a copy of the test

Data point: REUSE specifically directs people to copy the text fromhttps://github.com/spdx/license-list-data/tree/master/text. Citation: https://reuse.software/tutorial/ --V -- VM (Vicky)

As a programmatic user of the list, I think we should expect the use per Vicky’s points. One extra data point, I’m not accessing any of the GitHub repos listed so far but relying on whatever the

Previously I've been generally against the idea of encouraging folks to use the test/simpleTestForGenerator/*.txt files for anything other than the automated tests for the XML files. Mostly for the

Hi Alexios, You are correct re: the license-list-XML repo and originally - when we were still getting the whole XML files sorted - I believe, we had some kind of explicit

I'd rather go inline with my reply, but as Outlook has Opinions™ about the format of replies…then top-posting it is. I've frequently seen people copy the .txt of the licenses then drop that into

Hi Jilayne, The way we have operated for years is that the license-list-XML repo is for internal work of the SPDX Legal Team. These files are automagically processed and everything inside

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

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

Perhaps we should recommend that any policy about the license marking of files should address this. FreeBSD's policy will likely state that the actual boiler plate license text in the file is

Dear Jilayne, I'd completely agree with your appraisal here. Personally, I prefer to use just the SPDX license headers. I imagine that, in some cases, having both could be confusing - for example, if

Hello all, The version 3.15 release of the license list is now tagged and live at https://spdx.org/licenses. 4 new licenses were added to the