SPDX dual-license inconsistency

[diwic]

According to the current SPDX spec, dual-licensing should be done as: (Apache-2.0 OR MIT) (and there's also AND, + and WITH), but our manifest format says one should simply separate licences with / without being 100% clear on whether that means an "AND" or "OR".

This just seems to be an unnecessary inconsistency with the SPDX spec. Can we change the doc to encourage dual-licensing using the (x OR y) syntax instead?

[alexcrichton]

I'd prefer to just remove that clause about multiple licenses. I'm already a little uncomfortable referencing a somewhat-obscure spec and sidestepping the problem altogether would be nice.

[diwic]

To add additional motivation I went to a talk yesterday about fossology and my takeaway from that was, that what you should do as a good citizen is basically to conform to a SPDX tag, to make the license scanners happy. The person I talked to also recommended sprinkling the top of every source file with them, like this:

/*
 * (C) Copyright 2015 Some One <[email protected]>
 * SPDX-License-Identifier:     GPL-2.0+
 */

[codyps]

I'm also in favor of following SPDX more closely. / doesn't seem necessary.

[bluss]

Rust itself is dual licensed, and this encourages MIT/Apache-2.0 in the ecosystem, so it's not a fringe use case.

[edef1c]

@alexcrichton SPDX isn't exactly "obscure" — it's the Linux Foundation sponsored spec for licensing information, and npm uses it for one (there are probably a bunch of others)
It took a bunch of work to convert the npm ecosystem to SPDX (not done yet, by far), and this is something specifically requested after node started seeing wider commercial adoption.
If we want to make it easy to adopt Rust for companies with any kind of sensible IP auditing policy, "just put whatever the fuck you want in the license field and have a human guess" isn't really helpful.

[SimonSapin]

I’m in favor of warning for / on new crates.io uploads for a while, and later rejecting such uploads. All with a link to an explanation.

Rust’s own license is an OR, right?

[hobofan]

@SimonSapin I think before we can really push for widespread adoption of SPDX in the Rust ecosystem there should be a fully featured SPDX license parser in Rust. The one used for crates.io is missing support for parens.

[posborne]

I too would like to see a push toward following SPDX more closely and additional tooling related to licensing (although that may not be a cargo concern directly).

In my case, I am working on embedded systems where we actually distribute devices with code to users. For cases like this (as opposed to just operating a service accessed via the web), it is important that we be able to correctly report the license information for all packages requiring that we do so. SPDX provides a standard for reporting this information and I think it makes sense to follow it.

In addition...

# If a project is using a nonstandard license, then this key may be specified in
# lieu of the above key and must point to a file relative to this manifest
# (similar to the readme key).
license-file = "..."

I think user's should be encouraged to include a pointer to the license file even in cases where the license is standard (of course in addition to the license field). If you look at the MIT license, for instance, note the text that in addition to the license notice itself that the copyright notice be included. The copyright notice can probably only be included if the actual license file is included.

[joshtriplett]

I'd like to see this improved as well, so that a standard SPDX parser can process the entire license field, rather than having to split it on '/' first and treat that as OR.

[codyps]

I was looking into code for this a few weeks back. It seems like we could transition to this the same way the transition to forbidding "*" versions on crates.io worked:

• add a warning to cargo
• queue up a patch to crates.io that emits an error (cargo didn't do license verification when I was looking, crates.io does all of it. crates.io also didn't have a mechanism to return warnings when I was looking)
• after a grace period, merge error patch to crates.io to forbid new crates with "/" splitting (only allow standard SPDX).

[wking]

/ is deprecated and AND / OR recommended (via the SPDX license expression docs) with the just-landed #4898. The only remaining issues here are the lack of parens (ehuss/license-exprs#3) and reporting deprecation warnings (slightly more on a license-exprs API to return deprecation warnings here).

[wking]

crates.io also didn't have a mechanism to return warnings when I was looking…

Looks like it grew one in rust-lang/crates.io@1cee6d8c (rust-lang/crates.io#473) with the Cargo side in f697b8c (#3301). We'd probably have to add a new structured field for license warnings (like we did for badges in #3546).

[wking]

I think user's should be encouraged to include a pointer to the license file even in cases where the license is standard (of course in addition to the license field).

This particular wrinkle may be related to #3537.

[sanmai-NL]

@posborne: Does a license file need to referenced in metadata , though? There may be multiple license files, each copy may be in a different language, etc. It’s a can of worms and something better suited for human processing rather than automation. I propose to remove this field and stick with SPDX expressions in the metadata, accompanied with proper documentation on e.g. licensing, in a manner to be settled by projects themselves.

[posborne]

@sanmai-NL I understand your point. One of the main reasons I see for including the license file (even for packages using a defined license) is that the LICENSE file will typically (almost universally based on templates) also include the copyright notice for the package. Including this copyright notice is a requirement of many licenses. The author information may be the same as the copyright notice or it may not.

[stale]

As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it.

I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect?

The team would be especially grateful if such a comment included details such as:

• Is this still relevant?
• If so, what is blocking it?
• Is it known what could be done to help move this forward?

Thank you for contributing!

(The cargo team is currently evaluating the use of Stale bot, and using #6035 as the tracking issue to gather feedback.)

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!

[joshtriplett]

This issue still exists.

Part of the work needs to happen in the license-exprs package. Cargo and crates.io can then use that to check it.

[dwijnand]

So is this blocked on ehuss/license-exprs#5?

[wking]

So is this blocked on ehuss/license-exprs#5?

Or something like it. We still need something to support parens and deprecation warnings.

[withoutboats]

I'm pretty sure this should be closed for these reasons:

1. This is the wrong repository, cargo does not parse license exprs, they're parsed server side by the registry (from cargo's perspective, the license field is a string).
2. crates.io does support license exprs, with the exception of some SPDX features like parens (it depends on license-exprs). That is, the ambiguity this issue is about is partially solved.
3. crates.io still supports /, which is ambiguous, but its supported for backwards compatibility.

Ways forward IMO are:

1. Open an issue or PR to propose that crates.io stop accepting new publications with /, in the crates.io repo.
2. Improve license-exprs to support the unsupported part of SPDX.

Neither of these things seems well tracked in this repository.

[joshtriplett]

While I think this also needs handling in other repos, I do think cargo should help with this by warning if it can't parse the license field.

[withoutboats]

@joshtriplett cargo currently does not parse the license field at all except that it must be a string, and any registry can establish any policy about what licenses are acceptable. SPDX is a crates.io specific requirement.

[dwijnand]

Apparently there are crates.io specific requirements being enforced already, see #4840. Correct? So perhaps the fact that licenses aren't verified until the package is published is an outlier?

[withoutboats]

@dwijnand IMO that's a mistake and the fix is to stop checking those requirements in cargo

[epage]

With #12235, I think this is a lot more doable. I would recommend two lints

• Syntax is invalid
• License is invalid

On an edition boundary, we could even make those lints deny by default instead of warn.

The main issue this proposed design is working around is that our list of licenses can be out of date (hence separate lints to always give some protection, using a lint instead of an error to not block people)