*GPL -or-later and -only in sidebar instructions #563
Conversation
Reflect that in sidebar instructions for *GPL as seen e.g. at https://choosealicense.com/licenses/agpl-3.0/
_includes/sidebar.html
Outdated
| @@ -14,7 +14,7 @@ <h3>How to apply this license</h3> | |||
| {% endif %} | |||
| {% assign xgpl = false %} | |||
| {% if page.spdx-id contains 'GPL' %}{% assign xgpl = true %}{% endif %} | |||
| <p class="note"><strong>Optional: </strong> Add <strong><code>{{ page.spdx-id }}</code>{% if xgpl %}+{% endif %}</strong>{% if xgpl %} (or <strong><code>{{ page.spdx-id }}</code></strong> to disallow future versions){% endif %} to your project's package description, if applicable (e.g., <a href="https://docs.npmjs.com/files/package.json#license">Node.js</a>, <a href="http://guides.rubygems.org/specification-reference/#license=">Ruby</a>, and <a href="http://doc.crates.io/manifest.html#package-metadata">Rust</a>). This will ensure the license is displayed in package directories.</p> | |||
| <p class="note"><strong>Optional: </strong> Add <strong><code>{{ page.spdx-id }}{% if xgpl %}-or-later{% endif %}</code></strong>{% if xgpl %} (or <strong><code>{{ page.spdx-id }}-only</code></strong> to disallow future versions){% endif %} to your project's package description, if applicable (e.g., <a href="https://docs.npmjs.com/files/package.json#license">Node.js</a>, <a href="http://guides.rubygems.org/specification-reference/#license=">Ruby</a>, and <a href="http://doc.crates.io/manifest.html#package-metadata">Rust</a>). This will ensure the license is displayed in package directories.</p> | |||
There was a problem hiding this comment.
I haven't checked all of these locations, but the package.json docs explicitly call for SPDX 2.0:
If your package is licensed under multiple common licenses, use an SPDX license expression syntax version 2.0 string, …
although it's not clear to me how strongly they mean that. In any case, I think it's probably best to continue to recommend SPDX license expressions use the old identifiers, at least until consumering tools have had some time to update. It's also not entirely clear to me how the license list is supposed to interact with the spec. Does the 2.1 spec's inclusion of the 2.5 license list limit SPDX 2.1 license expressions to those IDs? In spdx/spdx-spec#37, I'm suggesting explicitly pinning the license-list version. If that sounds like a possible interpretation of the current spec, you may want to wait at least until the next SPDX spec release before recommending the 3.0 license list identifiers.
There was a problem hiding this comment.
I assumed the there is no intent to have the spec version imply a license list version. Surely that intent would be clearly expressed places like:
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/
Not to mention in the definitions of various license declared/concluded/data license fields.
I'll leave this open pending more information, and subscribe to the issue you point out. Thanks!
There was a problem hiding this comment.
Meant to mention: there's an optional LicenseListVersion field in the SPDX spec, which is a pretty strong implication that a spec version isn't tied to a license list version, though a producer can explicitly specify one.
There was a problem hiding this comment.
…there's an optional
LicenseListVersionfield in the SPDX spec…
That sounds useful when you have an SPDX file, although the spec doesn't seem to discuss the default value. The package.json docs don't either, and there's no way to specify a license-list version there. License-expression consumers would seem to need both an SPDX-spec version for the license-expression syntax and (if it is intended to float independently, as LicenseListVersion implies) a license list version.
There was a problem hiding this comment.
until consumering tools have had some time to update
There was a problem hiding this comment.
The Rust docs seem to have moved to https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata:
$ curl -s http://doc.crates.io/manifest.html | grep moved
This page has moved. Click <a href="https://doc.rust-lang.org/cargo/reference/manifest.html">here</a> to go to the new page.And those docs do not yet contain rust-lang/cargo#4898. Perhaps they only update them after Cargo releases?
And the Ruby docs seem to have a similar issue to the old Rust/Cargo /, with licenses that does not distinguish between AND and OR and a lack of clarity about the SPDX (list) versions and whether license takes license expressions or just short identifiers. I think pulling the Rust declarations forward is going to absorb my available free time, so I'll leave pulling Ruby forward to someone else ;).
There was a problem hiding this comment.
@wking I think I found where for Ruby: rubygems/rubygems#2152
There was a problem hiding this comment.
(I mean where rubygems gets its list of licenses; lack of support for license expressions and/or use instead of ambiguous licenses I haven't looked into, and doesn't impact this PR.)
There was a problem hiding this comment.
For my own memory, npm/npm#19558 is probably what will be closed when npm uses the updated license list.
There was a problem hiding this comment.
npm 6, released today, includes updated license list support.
SPDX license list 3.0 uses -or-later and -only over + and no modifier
Reflect that update in sidebar instructions for *GPL as seen e.g. at https://choosealicense.com/licenses/agpl-3.0/