Documentation points to spdx.org for license identifiers, but listed license identifiers are invalid. #4888
Labels
A-documenting-cargo-itself
Area: Cargo's documentation
Comments
That form is new in v3.0 of the license list. See github/choosealicense.com#563 and spdx/spdx-spec#6 for some elated discussion. In the mean time, you get the same semantics with |
|
Appears to me the error is coming from https://github.com/rust-lang/crates.io/blob/c69ca7a8531e52f534e5f0eb9f714f91012bfcec/src/version/mod.rs#L199-L204 and in turn from https://github.com/withoutboats/license-exprs which looks like it needs maintainer attention (there isn't a PR for SPDX license list 3.0 yet, but there are several other updates outstanding). |
wking
added a commit
to wking/cargo
that referenced
this issue
Jan 4, 2018
Before this commit, the license-list URL was floating, which lead to issues when manifest authors used IDs from the list that had not yet made it into crate.io's whitelist [1]. This commit pins both the SPDX-spec version (to avoid floating the license-expresion syntax) and the license-list version (to avoid floating the license/exception identifiers). I've also deprecated the / syntax, since it was not clear whether that was conjunctive (like AND) or disjunctive (like OR). crates.io is using license-exprs 1.3^ [2], and that version supports WITH, AND, OR, and the + suffix [3], so as far as crates.io-validation is concerned, the value can use vanilla license expressions. It's unfortunate that there's not an easily-browsable version of the 2.4 license list up anywhere canonical (as far as I know). Starting with the 3.0 license list, there's a Markdown page in the authoritative list-data repository [4]. I can also see about getting earlier versions of the HTML (e.g. [5]) up on spdx.org somewhere. I'm expecting the version-bump procedure will look something like: 1. SPDX cuts a new spec and/or license list release. 2. license-exprs updates to cover the change. 3. crates.io updates to depend on the new license-exprs version. 4. cargo updates the documentation to allow the new version. 5. authors read the new cargo docs and start using the new expression syntax and/or identifiers. There's a window there where crates.io will be validating to a different version than the cargo docs recommend, so it would be good to have 4 follow 3 as closely as possible. But the SPDX maintainers have been good about providing long deprecation windows, so a bit of a gap is acceptable. It's possible that crates.io will want to warn authors about their use of deprecated identifiers or syntax (e.g. the '/' I've deprecated here) so they can upgrade before the deprecated element is dropped (probably years after the initial deprecation). That would help limit the gap between 3 and 5 (although warnings sent before 4 might be confusing). The parallel edits to the two manifest files are based on Carol Nichols' recommendation. She points out on IRC that the goal is to drop the src/doc/manifest.md reference soon with the book up on doc.rust-lang.org/cargo today [6]. [1]: rust-lang#4888 [2]: rust-lang/crates.io#385 [3]: https://github.com/withoutboats/license-exprs/blob/5bdb5355540792234e10011b9bbe4766cd08ff26/src/lib.rs#L53-L56 [4]: https://github.com/spdx/license-list-data/blob/v3.0/licenses.md [5]: https://github.com/spdx/license-list-data/tree/v2.4/website [6]: https://botbot.me/mozilla/cargo/2018-01-04/?msg=95358280&page=2
|
After some discussion on IRC this morning, I've filed #4898 with the pinning approach. An alternative for this issue would be the “immediately support new identifiers as the SPDX cuts license-list releases” approach, but I think it's better to pin and get a bit of breathing room. |
bors
added a commit
that referenced
this issue
Jan 4, 2018
src/doc/manifest: Pin 'license' to SPDX 2.1 expressions and the 2.4 list Before this commit, the license-list URL was floating, which lead to issues when manifest authors used IDs from the list that had not yet made it into crate.io's whitelist (#4888). This commit pins both the SPDX-spec version (to avoid floating the license-expresion syntax) and the license-list version (to avoid floating the license/exception identifiers). I've also deprecated the `/` syntax, since it was not clear whether that was conjunctive (like `AND`) or disjunctive (like `OR`). crates.io is [using license-exprs 1.3^][2], and [that version supports `WITH`, `AND`, `OR`, and the `+` suffix][3], so as far as crates.io-validation is concerned, the value can use vanilla license expressions. It's unfortunate that there's not an easily-browsable version of the 2.4 license list up anywhere canonical (as far as I know). Starting with the 3.0 license list, there's [a Markdown page in the authoritative list-data repository][4]. I can also see about getting [earlier versions of the HTML][5] up on spdx.org somewhere. I'm expecting the version-bump procedure will look something like: 1. SPDX cuts a new spec and/or license list release. 2. license-exprs updates to cover the change. 3. crates.io updates to depend on the new license-exprs version. 4. cargo updates the documentation to allow the new version. 5. authors read the new cargo docs and start using the new expression syntax and/or identifiers. There's a window there where crates.io will be validating to a different version than the cargo docs recommend, so it would be good to have 4 follow 3 as closely as possible. But the SPDX maintainers have been good about providing long deprecation windows, so a bit of a gap is acceptable. It's possible that crates.io will want to warn authors about their use of deprecated identifiers or syntax (e.g. the `/` I've deprecated here) so they can upgrade before the deprecated element is dropped (probably years after the initial deprecation). That would help limit the gap between 3 and 5 (although warnings sent before 4 might be confusing). The parallel edits to the two manifest files are based on @carols10cents' recommendation. She [points out on IRC][6] that the goal is to drop the `src/doc/manifest.md` reference soon with the book up on `doc.rust-lang.org/cargo` today. Fixes #4888, although it would be good to start the upgrade cycle to pull in the [newly-released SPDX license list 3.0][7] so folks can start using the new identifiers. [2]: rust-lang/crates.io#385 [3]: https://github.com/withoutboats/license-exprs/blob/5bdb5355540792234e10011b9bbe4766cd08ff26/src/lib.rs#L53-L56 [4]: https://github.com/spdx/license-list-data/blob/v3.0/licenses.md [5]: https://github.com/spdx/license-list-data/tree/v2.4/website [6]: https://botbot.me/mozilla/cargo/2018-01-04/?msg=95358280&page=2 [7]: https://lists.spdx.org/pipermail/spdx/2017-December/001159.html
rolag
added a commit
to rolag/lockfreehashmap-rs
that referenced
this issue
Mar 24, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While I understand that this is partially a PEBCAK issue, I'm putting it up anyway because it's probably caused/causing someone else grief too.
I wanted to publish a new crate - I'm new to rust/cargo so didn't realize the license was a required field. So tried to publish w/o a license, got the nice warning:
warning: manifest has no description, license, license-file, documentation, homepage or repository. See http://doc.crates.io/manifest.html#package-metadata for more info.R'd TFM:
This is a string description of the license for this package. Currently crates.io will validate the license provided against a whitelist of known license identifiers from http://spdx.org/licenses/. Multiple licenses can be separated with a/.Yay, that's simple enough. Went to http://spdx.org/licenses/, grabbed the listed identifier for LGPL 3.0:
LGPL-3.0-or-later, put it in myCargo.toml, and boom:error: api errors: unknown license or other term: LGPL-3.0-or-later; see http://opensource.org/licenses for options, and http://spdx.org/licenses/ for their identifiersSo, um...yeah. Cargo doesn't seem to like the
-or-later. Either the documentation, or the application, needs an update.The text was updated successfully, but these errors were encountered: