As to Rust saying MPL-2.0+ is invalid - this is likely because Rust thinks of the SPDX License List as *only* what is this page https://spdx.org/licenses/ - ignoring the links at the top of that page that provide the greater context, which is really important to understand. This is a somewhat common misconception, especially when adoption of SPDX ids occurs without actual engagement in the SPDX community. Some time ago, I started (in presentations) to repeat "it's not just a 'list'" to help educate people and updated the first FAQ to this end - https://github.com/spdx/license-list-XML/blob/main/DOCS/faq.md
Maybe I need to re-write that lead-in language on the top of the page again or put a big yellow flashing sign also? sigh
If you want to pass along this concept to people at Rust and tell them to join the spdx-legal mailing list, we'd be happy to help advise.
As for deprecated SPDX ids and validity in the context of Fedora - I would strongly urge us to use the current ids and not muddy things with the use of deprecated ids. The change as of the SPDX License List 2.0 added the operators (AND, OR, WITH, and +) and so it would super confusing if people still used the ids from v1.0
Further comments below
thanks,
Jilayne
On 8/22/23 2:55 PM, Richard Fontana
wrote:
correctOn Tue, Aug 22, 2023 at 4:44 PM Fabio Valentini <decathorpe@xxxxxxxxx> wrote:On Tue, Aug 22, 2023 at 10:39 PM Richard Fontana <rfontana@xxxxxxxxxx> wrote:On Tue, Aug 22, 2023 at 3:06 PM Fabio Valentini <decathorpe@xxxxxxxxx> wrote:On Tue, Aug 22, 2023 at 1:21 PM Miroslav Suchý <msuchy@xxxxxxxxxx> wrote:rust-bitmaps warning: not valid neither as Callaway nor as SPDX, please checkThis uses MPL-2.0 or later, denoted as "MPL-2.0+". It looks like an SPDX identifier, but it's not (there is no "-or-later" variant of MPL-2.0 in SPDX). I'll investigate and file an issue with upstream.Jilayne can correct me if I'm wrong, but I am pretty sure `MPL-2.0+` is a valid and semantically meaningful SPDX identifier. It is arguably redundant since MPL-2.0 permits downstream relicensing to later versions.
Here is the current spec link https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/It's not on the list though: https://spdx.org/licenses/The use of `+` is documented at https://spdx.github.io/spdx-spec/v2-draft/SPDX-license-expressions/ (there's probably a more recent version)
this is more or less correct, although we did some analysis on the various license with "or later" clauses and the variations on the actual wording and meaning was surprising...<excerpt> D.3 Simple license expressions A simple <license-_expression_> is composed one of the following: An SPDX License List Short Form Identifier. For example: CDDL-1.0 An SPDX License List Short Form Identifier with a unary "+" operator suffix to represent the current version of the license or any later version. For example: CDDL-1.0+ An SPDX user defined license reference: ["DocumentRef-"1*(idstring)":"]"LicenseRef-"1*(idstring) </excerpt> I believe CDDL-1.0 is like MPL-2.0 in having a built-in "later versions" clause.
see comment above - but I'd rephrase that crates.io is probably not "redefining" but operating on a limited understanding :(Also, cargo / crates.io even documents that licenses in crate metadata needs to be valid SPDX expressions and only things from SPDX license list are acceptable, so this isn't considered valid by crates.ioThat is at least in some sense wrong, since the SPDX spec shows that valid SPDX expressions include use of the `+` operator with SPDX identifiers. I think in reality crates.io is redefining what "valid SPDX expressions" means, though possibly not intentionally.
I would argue that Apache-2.0+, while technically valid, would be silly/incorrect, though :)For Fedora, I think there are (quite rare) cases where the use of postpositional `+` should be recognized as valid. I know of one package (though I can't remember what it is now) that says its license is the Apache License 2.0 or any later version -- this is validly represented as `Apache-2.0+` in SPDX.
Richard
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue