Support parsing with unknown license/exception identifer

[weihanglo]

Is your feature request related to a problem? Please describe.

Hi @Jake-Shadle.

Could this crate supports some sort of "allow unknown identifier" mode? Given SPDX license list updates frequently. When people want to use new license but this crate hasn't updated. They may see parse error before this crate catches up with SPDX data.

The main issue for Cargo is it becomes code-freeze for at least 6 weeks whenever the Rust nightly version becomes beta. During that time the SPDX data list cannot be updated. However, we want to implement a invalid_spdx_license_expression lint for checking the package.license field in Cargo.toml. Without the relaxing rule, it might be a bit hard for some folk eagerly changing their packages' license (I don't think that is very common but in theory it could happen).

Describe the solution you'd like
A new ParseMode config such as allow_unknown_identifier?

Or have two passes, one for expression, one validate identifiers.

Describe alternatives you've considered
Just don't allow. That is also valid as people can use LicenseRef- or AdditionRef- if they want to refer to a new license before this crate updates.

Additional context
The Cargo team discussed it, and we'd like to see the support happening in spdx crate: rust-lang/cargo#15847 (comment). Thank you.

[Jake-Shadle]

I don't think this makes sense from a practical standpoint.

The license list doesn't update that frequently, roughly ~4 months or so, and it takes a few minutes to update this crate to the latest, so the likelihood of someone wanting to use a new license/exception within the 6 week window before cargo can update to the latest version of this crate is extremely unlikely. And as you point out, there is already a mechanism for adding licenses/exceptions outside of the SPDX lists, so if a user is so keen to use such a bleeding edge identifier, they can fallback to that until cargo can update.

I guess one other scenario would be a user wanting to use a newer identifier from an old version of cargo that uses an old license list, but the same fallback would apply there.

FWIW I've used this crate for years from cargo-deny and AFAIR the issue of someone wanting to use a bleeding edge identifier before I had updated the crate has never come up, though granted cargo would need to handle more crates than cargo-deny, theoretically.

[epage]

It sounds like the workaround is for them to refer to a license using different syntax. They would likely prefer to remove that extra syntax when it is no longer an issue.

For me, I see differences with the cargo-deny scenario

• Wider audience
• Different quality expectations
• Different bar for users to upgrade (their entire Rust toolchain)

imo we shouldn't require people to update their toolchain to get new licenses and I'd prefer we didn't require them to hack around the licenses.

[Jake-Shadle]

Ok, I personally don't think it's a realistic issue, especially when the user spec-compliant ways to use unknown identifiers outside the current SPDX list the crate uses, in addition to the license-file that cargo supports for more free form license attribution, I guess I can implement this. I'm not going to change the API for what I consider a niche use case, but cargo (unless I'm mistaken) doesn't need nor want to actually evaluate expressions, which means this can be a completely separate API that doesn't need to impact anything else.

[weihanglo]

Ok, I personally don't think it's a realistic issue, especially when the user spec-compliant ways to use unknown identifiers outside the current SPDX list the crate uses

Some data point. I work for a big-corp that has invested in and used Rust in production quite a lot. We have an internal license auditing system that keeps every usage of third-party library compliant. In that system

• There is a list of pre-approved licenses, and they are mostly hand-picked by dedicated open source policy experts.
• Usually only OSI-approved licenses are included in the list, and new licenses will need a scrutinization before getting in (probably at legal level). That mean the system is always behind SPDX list
• We reject everything else not in the list, and to use them it needs a extra review.

Given those, I largely agreed that it is not a realistic issue at least from where I am at. Also, my impression is people care more about OSI-approved license rather than new licenses. If we have to configure Cargo's behavior, a config for checking whether it is OSI-approved or copyleft is way more interesting than allowing arbitrary unknown licenses. And honestly we already have some useful methods in the spdx crate.

The other important point is licensing is more a legal stuff more than a build correctness thing. It is not a thing you changed and your program fails. People have plenty of options in Cargo to work around:

• The aforementioned package.license-file for free form license
• The LicenseRef- for inline-custom license, plus the upcoming AdditionRef- for exception / additional text.
• Turn off the proposed invalid_spdx_license_expression lint.

(IANAL) I don't see a reason these workaround lead to any legal issues. I can see the value of a more configurable spdx crate, though.