Better integration with cargo-deny?

[nbigaouette]

Is your feature request related to a problem? Please describe.
Right now, cargo-deny and cargo-about are two separate tools. This is fine, except that both tools will validate the license files used in the project.

As such, the list of accepted licenses needs to appear in both about.toml's accepted = [] and deny.toml's allow = [] arrays.

Describe the solution you'd like
The simplest solution I think would be for cargo-about to not need an accepted array and simply spit out all found licenses. Or at least having a flag to do so. This way, I could use cargo-about to generate the license file and cargo-deny to enforce license requirements.

Describe alternatives you've considered
Maybe the two configurations could be merged? For example cargo-about could read the deny.toml file and pick up the allowed licenses in there. about.toml contains more config options, so those would need to be moved to deny.toml. That's a large breaking change though.

[Jake-Shadle]

I agree it's a bit unfortunate to have this kind of duplication where there is overlap between the tools, but I'm not sure it's worth effort to try and find some alignment.

The first issue would just be that they are separate tools and using one doesn't mean the other is used, and the other is that the configs are different as you say, including in behavior, eg the ordering of the licenses matter in cargo-about as that determines which license is used for a crate if it is a compound expression such as the typical MIT OR Apache-2.0, which could lead to confusion if, say, the license list was pulled from the deny.toml config instead where the ordering doesn't matter.

And in that same vein, just spitting out all licenses found means that the output will be unnecessarily bloated since you'd then be licensing all crates under all their possible licenses even when not required (and potentially including non-compatible licenses), but also would mean the users that don't use something like cargo-deny to enforce their licenses could end up unintentionally using a license that they could have avoided by being specific, or just avoiding that crate altogether.

That being said, I suppose I could accept a PR to add a flag and config option to accept all licenses and not require a global accept list.

[stormshield-gt]

If I already use cargo deny for banning crate, is there any reasons I should prefer cargo about to check licensing?
By looking at the config files (about.toml and deny.toml), it seems that most of the open sourced crates of Embark prefer to use cargo deny.

[Jake-Shadle]

cargo-deny is explicitly for checking licenses quickly, cargo-about does this more slowly as it is more thorough, and the license checking is more incidental than its primary goal.

[stormshield-gt]

Thanks for your quick answer! If I understand well, we could imagine some rare cases where cargo about could detect an incompatible license and cargo deny wouldn't?

[Jake-Shadle]

Yes, if a license file was detected in a subdirectory (not root) that had a license that wasn't one of those in the crate's license field or the same (by kind, not by text) as a license file that was in the root.