Cargo allows invalid paths in license-file property, makes packages without identifiable license

[kornelski]

Cargo allows license-file = "../LICENSE" in Cargo.toml, but it does not include such out-of-tree files in the package when publishing. This leads to creation of .crate files on crates-io that have no licensing information.

For example:

https://github.com/PsichiX/Oxygengine/blob/2022ae7d9d1d95929527d34101fd2af8bd2405f3/oxygengine-ignite/Cargo.toml

crates-io shows "License: non-standard" https://crates.io/crates/oxygengine-ignite/0.6.0

and there's no LICENSE file in the crate tarball on crates-io.

There's a similar issue #3537 about enforcing inclusion of a license file in general. This is a more specific case where Cargo allows omission of license property believing that license-file provides that information instead, but fails to preserve that file.

READMEs are also affected by out-of-tree paths #5911, but they're uploaded separately to crates-io, at least they're not completely lost.

[joshtriplett]

I think it'd be reasonable to warn about (and in the future error on) packages where license-file refers to a file that doesn't get shipped in the crate.

Long-term, I'd love to have a mechanism where you can declare new mappings from license identifiers to licenses, but you always have to specify a license expression (which may use those new mappings). That would make it easier to say "here are two extra license files, the crate license is X OR Y WITH Z-Exception". But that's a long-term proposition, and one that would also need to take into account things like different parts of a crate using different licenses.

[ehuss]

I think it would be reasonable if the license-file has a path outside of the package (like ../LICENSE), it should be fine to copy the file into the root (and update the license-file path to be correct). cc #3537 which also mentions this.

On top of that, adding a warning (and transition to an error) if the path to license-file cannot be found sounds good, too.