Allow adding extra licenses

[nbigaouette]

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

I need to provide licenses for non-crate code that is being included in a project. The code is in C and is wrapped in a -sys FFI crate. Right now, cargo-about will see the -sys crate and include its license, but cannot go further and find the wrapper C code's license.

Describe the solution you'd like

I don't expect cargo-about to be able to track the C code license as it does for Rust crates, but it would be nice if I could manually add "extra" licenses to include in the final report. I think the about.toml config file might be the best place that information.

Describe alternatives you've considered

The final report could be manually edited but that brings us back to scripts to build the license file

[repi]

cargo-about does have a concept of workarounds which is meant to tackle crates that do not correctly define their licenses that I think can be used here. Though best is to fix it upstream in the crate so it properly declares all of its licenses and has its license texts available for inclusion in the summary.

In general I think -sys crates that depend on C/C++ code that uses a different license should declare that in their Cargo.toml license field. for example if your Rust -sys crate uses the standard MIT OR Apache-2.0 license but the C code uses MPL-2.0 as license then your crate license really should be (MIT OR Apache-2.0) AND MPL-2.0.

There was a recent similar example to this with the unicode-ident that only had specified the license of its Rust code but not the Unicode-specific license of the source it was generated from which was fixed in:

• Explain Unicode license agreement dtolnay/unicode-ident#9

Believe there are many more -sys crates esp. that do not fully describe their licenses correctly.

That said, it may get a bit extra tricky also with how to include the license texts for such a crate, would have to include all the ones selected and have the text for the ones in the wrapped C library be available

[nbigaouette]

Unfortunately, there is two reasons that I cannot change the -sys crate's license:

• This is not something I can do; the crate is controlled by another group. While the crate is mostly a bindgen-automatically-generated one, the crate's license provided is an "internal only" license. This makes it difficult to change...
• I am using an internal crate registry where we publish our internal crates. We do not want to publish licenses for those closed source crates, so I'm using the private = { ignore = true, registries = ["internal-crate-registry"] } configuration. This means that all crates from that registry that I use in the project will not show up in the generated license. This means that even if I could change the -sys crate's license, it would be hidden from the final license file...

I don't see how I could make sure the proper license file gets included without having a generic way to add extra licenses that is outside of cargo's world. For now the only solution I can think of is to append the content manually to the file after its generation... :(

My ideal solution would be a section in about.toml where I could specify the package name, its version and its license. Something like this:

extra = [
    { package = "oss-library-name1", license-file = "./path/to/license1.txt" },
    { package = "oss-library-name2", license-file = "./path/to/license2.txt" },
]

[Jake-Shadle]

https://embarkstudios.github.io/cargo-about/cli/generate/config.html#the-clarify-field-optional

[nbigaouette]

If I understand correctly, the clarify field allows clarifying what a crate's license is. It's like an overwrite of what cargo-about found.

I cannot use this though because the code I am trying to include the license of is not a crate, so cargo-about cannot know about it. That's why I'm saying that I don't see how I can set a cargo-about configuration to achieve what I need: the code is just hidden from the cargo dependency tree.

[repi]

but the code that is not a crate, must surely be used by a crate? like a -sys crate. so one could override the license of that crate and add the additional license and files to it?

that said, it would show up as the sys crate then but likely the license file has the full project name in it (if it is not a genric one where they don't care about it).

that said, I could see some other similar needs of adding full free form licenses to cargo-about, for example our binary includes a free but licensed .ttf font, that is most definitely not a crate and we would want to include that as a named asset/project with a specific license. assuming that license requires attribution.

and for that one could have a mechanism similar to what you described

[nbigaouette]

Yes exactly, as you mention, some use case cannot be supported since the license apply to something that does not appear in cargo's dependency tree and hence cargo-about cannot know about it.

I don't mind contributing that functionality. Would the list of objects as shown here #200 (comment) be a good format?

[repi]

I will let @Jake-Shadle make the call still as he is the maintainer and code owner, but is currently out on vacation and should not be replying here :) but he is back next week so can follow up then!

[Rodrigodd]

I am also interested in this.

My use case would be to include some non-rust-related licenses, like font licenses (which @repi already give as example) and android library licenses. My current approach is to hard-code the license inside the handlebars source file, but this is not very maintainable.

[Sydius]

For now I'm using a bit of a hack where I'm creating an empty crate just to reference the license for a font I'm using. This works, and I was able to specify the repository in the empty crate to point where the link should go etc.