Cargo: Feature request: "license-blacklist" key

[olson-dan]

Some licenses are viral and "infect" binaries in which they are statically linked. Two examples of these license are GPL and LGPL. For commercial, closed-source developers working in the rust ecosystem, this can present a large verification challenge as every crate and every dependency of every crate must be verified to not contain any incompatible licensing terms.

Cargo already has a "license" key for specifying the license of the crate. To resolve the above problem I suggest adding a "license-blacklist" key using the same syntax and parameters. If any crate in the dependency tree is encountered with a license that matches the license blacklist, the build would fail and notify the user of the issue.

I suggest that crates included as dependencies should have their blacklists ignored, and only the top-level Cargo.toml would decide which licenses are invalid, but this may not be the best implementation.

[kennytm]

You could use cargo lichking to list the license of the dependencies, there is no need to add this feature into Cargo.toml.

[est31]

I have been pondering about this since some while, since I have a very similar issue with one of my projects. Here I use a license (LGPL 2) that is incompatible with the Apache 2 license. As such I need to ban all crates that are AL2 only licensed (not dual licensed).

Some kind of automatic checking is needed. Just displaying the list of licenses is not enough, it needs to be something that you can gate PRs on with travis and similar.

In fact two high-tier projects, Servo and Rustc already have automated checking of that kind, but its custom implementations in both cases.

About why I think this should be integrated into Cargo: Literally every binary project has (or should have) a license policy for its dependencies. Cargo itself wouldn't probably accept PRs to add some GPL licensed project as dependency. The issue is though that the reviewers need to be aware of the situation (most times they aren't, let's be honest), and if they are they have to check the entire list of dependencies manually.

I didn't have the time yet to make a comprehensive request (RFC).

[kennytm]

cargo lichking check exits with error code 1 on incompatible license, so you could already gate on PR with a CI test using this subcommand.

$ cargo lichking check
warning: IANAL: This is not legal advice and is not guaranteed to be correct.
warning: Unknown whether package term_size with license Custom(MIT OR Apache-2.0) is compatible with MIT
error: Cannot include package pest, license MPL-2.0 is incompatible with MIT
error: Cannot include package unidecode, license BSD-3-Clause is incompatible with MIT
error: Incompatible license

$ echo $?
1

[est31]

@kennytm oh interesting! I still think it should be a cargo builtin.

[olson-dan]

I think there are still some arguments for its inclusion in cargo even though cargo-lichking exists.

• cargo is installed via rustup and does not require obscure build dependencies like cmake. Thus cargo-lichking is not out of the box functionality and requires jumping through hoops to install (like a lot of crates, unfortunately).

• cargo-lichking appears to try to work out which licenses are incompatible on its own, vs the license-blacklist suggestion which would allow developers to specify the behavior they desire.

• cargo-lichking may have a discoverability issue. As mentioned above two projects have implemented license checking in their own ways.

Admittedly these issues could be resolved with PRs to cargo-lichking, but I think the behavior is important enough that it warrants inclusion in cargo.

[nodakai]

Serious commercial users shouldn't try to save their time by skipping to install an external tool when verifying their legal validity.

A blacklist will not guarantee your software is free from components distributed under new copyleft licenses as SPDX recognizes more and more of them. You definitely need a whitelist approach. And yet, Cargo.toml supports an (essentially) free text field called license-file... An implementation which can address all these trickinesses would be too sophisticated to fit into the vanilla Cargo software.

[ssokolow]

Some licenses are viral and "infect" binaries in which they are statically linked.

Please don't perpetuate terminology that originated in Microsoft's FUD campaign against Linux.

Licenses like the GPL are "hereditary", not viral. (They won't actively seek out and infect other projects. They are simply inherited from whatever "ancestors" you use to engineer a project.)

[olson-dan]

Regardless of terminology GPL is unusable in my field of employment and I would prefer to have a way that is not opt-in to ensure that it is not carelessly invoked. The idea of hooking cargo-lichking up to CI is workable, but there are several other ecosystem fixes required to make it a convenient solution.

[carols10cents]

This sounds like it's possible to solve via tools in the ecosystem and doesn't have any reason it needs to be part of cargo itself, so I'm closing. These are some great ideas and could be a fun project for someone to implement to meet all of your requirements though!

[michaeleiselsc]

+1 for adding this feature. It's not actually supported via tools in the ecosystem.