Update SPDX License List in Appendix 1

[tsteenbe]

The following table contains the full names and short identifiers for the SPDX License List, v2.5 which was released July 2016. For the full and most up-to-date version of the SPDX License List as well as other related information, please see http://spdx.org/licenses/

Should we upgrade to v2.6 in the next fix release

[kestewart]

Discussed on SPDX Tech call. Please update to the next rev of the license list to go along with the next 2.1.1 rev of the spec (along with any necessary bug fixes and links). Kate to let Jilayne know we'll be doing this, and make sure she's ok.

[wking]

I've filed a script to automate this and bumped the Markdown in #10.

[wking]

After some discussion with @mlinksva here, I'd like to re-raise dropping the license-list appendix in favor of an external link (which I'd mentioned briefly here; @goneall seemed ambivalent). If we do that, we'd want to either transition LicenseListVersion from optional to required or define its default more clearly. As it stands, it's not clear to me what the license-list version defaults to when LicenseListVersion is not set. Is it 2.5 since that's the version in the 2.1 spec's appendix I? Is it the most-recently released license list? Without these changes, it is unclear to me how the 3.0 license-list release is expected to impact spec consumers. For example, are package.json authors expected to wait until npm updates the docs before they start using license-list 3.0 identifiers or can they start using them now? Is npm blocked on a new spec release or can they update those docs now to specify the 2.1 spec with the 3.0 license list?

[mlinksva]

I don't care that much, but my bias is against making LicenseListVersion required.

It seems the license list has a de facto (possibly I've missed explicit or contrary) backwards-compatibility policy, that is deprecating rather than removing license identifiers. This makes knowing what version of the license list a producer is working with a lot less critical.

Required fields often aren't provided anyway, which makes requiring ones that aren't absolutely critical somewhat pointless. I'm not sure whether being a tutorial file makes it more or less on point, but skimming, I lost count (something like 10) of the number of mandatory fields missing from https://github.com/david-a-wheeler/spdx-tutorial/blob/master/LICENSE.spdx

[wking]

On Wed, Jan 03, 2018 at 12:02:47AM +0000, Mike Linksvayer wrote: It seems the license list has a de facto (possibly I've missed explicit or contrary) backwards-compatibility policy, that is deprecating rather than removing license identifiers. This makes knowing what version of the license list a producer is working with a lot less critical.

I'm in favor of making the backwards-compat explicit by adopting Semantic Versioning [1]. And yes, backwards-compat is an important consideration. But there is a desire to (at some point) drop long-deprecated identifiers from the list, although I can't dig up a reference at the moment besides my own [2]. I agree that knowing the exact version is less important if we never actually break backwards compat. But even if we went that way (and I'm not sure we should), you'd need a version declaration if you wanted to get errors like “I don't speak license-list 3.0 yet” instead of “I have no idea what GPL-3.0-or-later is” from your tooling.

Required fields often aren't provided anyway, which makes requiring ones that aren't absolutely critical somewhat pointless.

I'm fine with a clarification like: For SPDX-2.2, the default license list version is 3.0. which gets bumped as needed for future SPDX releases. Then we could leave LicenseListVersion as optional. [1]: https://semver.org/ [2]: https://lists.spdx.org/pipermail/spdx-legal/2017-November/002311.html

[goneall]

Discussed on tech call 12 June 2018: For 2.2, we will update the appendix to the latest license list version. For 3.0, there is a proposal to remove the appendix and just reference the license list by URL. Since some of the proposal has backwards compatibility issues (e.g. making LicenseListVersion required), this is more of a 3.0 topic.

[goneall]

Suggest doing a PR after version 3.2 of the license list is released.

[wking]

For 3.0, there is a proposal to remove the appendix and just reference the license list by URL. Since some of the proposal has backwards compatibility issues (e.g. making LicenseListVersion required), this is more of a 3.0 topic.

Whether we require LicenseListVersion or not is orthogonal to whether we inline or reference a given version of the list. For example, see the wording I floated in my previous comment. If there is a consensus around incorporating the license list by reference, I don't see any problems with doing that as part of 2.2.

[kestewart]

see: #151

[iamwillbar]

Closing since #151 has been merged into the upcoming 2.2 release.