Enforce a license allowlist

[epage]

What it does

Require the user to enumerate the licenses they allow within the project

See also https://embarkstudios.github.io/cargo-deny/checks/licenses/index.html

Advantage

Provide an opportunity to explicitly verify license compatibility

Drawbacks

Users must manually manage license compatibility

Example

N/A

[epage]

The question is what to operate on

• lockfile
  • check on one platform and you are good everywhere
  • but an unused feature or unused platform could cause problems (Allow specifying a set of supported target platforms in Cargo.toml #6179 can help)
• unit graph
  • limited to exactly what will be included in the build
  • but you now need to lint it for every platform

There is also the question of what to do about build dependencies.

[joshtriplett]

I would expect the allowlist to apply to dependencies and build dependencies. cargo-deny offers the option to exclude dev-dependencies, which could make sense, but we may want to defer that until it's specifically requested.

I do think we need "exclude packages in the workspace" or "exclude unpublished path dependencies", though.

Enforcing for the entire lockfile seems like the right answer, so that it only needs to run once. We can support excluding targets in the future. (But if a crate's feature isn't used on any target, dependencies pulled in by that feature shouldn't be checked.)

[epage]

Note: I would expect us to lint on a per-package basis meaning that all dependencies reachable for a given workspace member must have an allowed license. This would allow different workspace members to have different license sets or to turn this lint off entirely.

This will be annoying until we have the ability to override inherited lints.

[Mark-Simulacrum]

https://github.com/rust-lang/rust/blob/main/src/tools/tidy/src/deps.rs is probably useful prior art to consider - I suspect Cargo may not want all of the complexity that supports, but good to be aware of what use cases are being left out or can be included (e.g., the list of allowed packages independent of license may be something a bit out of scope but possibly useful to consider).

[epage]

That does make me think of the "inheritable groups" feature: instead of there just being workspace = true, there is workspace = "tools" and workspace = "runtime".