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

On 11/10/21 11:07 PM, Warner Losh wrote: the full 15' sounds great, as I think all will be interested in the context as well thanks and look forward to it!

I'm ready to go if there's space in the agenda. My rehearsal of the talk clocks in at about 15 minutes, though I could trim this a bit because it's heavy on history to try to provide the full context

Hi all, We have our regularly scheduled call tomorrow, Thursday at 10 am mountain standard time. (the US has now pushed our clocks forward, so we should be back to our normal time zone gap

Hi Neal, I made an issue for a new license request - https://github.com/spdx/license-list-XML/issues/1355 In the future, please submit a new licenses to be added to the SPDX License List via the

I don't want to use LicenseRef identifiers. They're terrible hacks to deal with a process problem. SPDX agreed to import Fedora license identifiers some time ago, but since that stalled out, I want to

Hi Neal! If this can help we have tracked this in ScanCode for as long as I and git can remember: https://scancode-licensedb.aboutcode.org/fraunhofer-fdk-aac-codec.html We use this SPDX

Hey all, Since SPDX's effort to include all remaining approved Fedora licenses in SPDX has stalled out (again!)[1][2], can someone *please* add the FDK-AAC identifier to SPDX? It's blocking my

Dear all, My pull request regarding the BSD-1-Clause license is up and ready to be merged (https://github.com/spdx/license-list-XML/pull/1350). :) I've also been looking through the