Crates are published with no licenses (even though repo has license files).

[jacob-pa]

Issue

When you download the individual crates in this repo as a normal dependency using cargo, and then look at them on your local disk in the cargo cache, they have no licenses included. I think this might mean that legally they don't have a license, or at least it's a grey area that seems legally risky!

I came across this as I was writing a compliance tool to scrape all the licenses from cargo dependencies without going to the internet, but it doesn't work for all the crates in this repo.
Cause

The license files are in the repo, but only at the top level of the workspace, not in the individual crates.
Possible Fixes

• Copy the licenses into the top level of all the individual crates (annoying if you ever make changes due to the duplication).
• Use the Cargo.toml "include" field to include the files (downside is they will also need to specify all the other things like src etc).
• Automate with a script so that when publishing the licenses are copied in before publishing.

[cyqsimon]

So I did some research and at least theoretically, I believe your concern is valid. Here's a reddit post discussing this.

That being said, I think your issue is misdirected. "Barking up the wrong tree", if you will. I see that you have also posted the exact same issue in other repos: madsmtm/objc2#836 bytecodealliance/wasm-tools#2489. Feelings about this aside, this indicates to me that this is a problem with workspaced projects in general, and that you should take this issue up to the packaging tool, a.k.a Cargo.

Some further research turned up rust-lang/cargo#9941, which seems to be their current official position. The Cargo Book also states "If a license-file is specified, it is always included", but it doesn't seem to do anything like that with license.

Regardless, closing as not planned.

[jacob-pa]

Thanks for getting back to me! Much appreciated :) yeah I do agree I think it's a bit of an issue with the cargo tooling not handling workspaces very, seems to be a common issue with workspaces.

However, I do think it would be a good idea to change it in your repo. If you download the source in the normal way using cargo, you only get the source that was published, not the entire workspace (also visible here https://docs.rs/crate/documented/0.9.2/source/). This source does not have the licenses in it. So i think it's legally a bit of a grey area, even if the Cargo.toml says "MIT", because the actual shipped source does not have the MIT license in it verbatim.

I think particularly tricky lawyers might be able to make the case that this source code does not have any license, so would default to being very conservative. And as a corporate user of your (very useful) software, I think that might mean I'd have to be cautious using it. And the tooling I'm writing to grab licenses automatically would have to flag your crates as potentially (even if probably not) a possible issue.

One other piece of evidence is that most multi-crate workspaces do have the licenses in all the individual crates (e.g. tokio).

Would it be worth duplicating it in the crates just for the avoidance of doubt? I'd be happy to open a pull request?

[cyqsimon]

It wouldn't be that big of an issue to manage, I could just add symlinks in all the crates - I'd just rather not bother if I can avoid it.

I'm leaning towards closing this as "wontfix", though I'd be willing to reopen if you figure out something more official with Cargo?

Same.

I would prefer that you take it up with Cargo first, just so that whatever hack we're doing here aren't causing any unnecessary trouble with a "proper" solution.

[jacob-pa]

Yes I'll pursue it with cargo, looks like there is an issue here that would be half of the solution, combined with inheiriting licenses from workspaces (which I think might already be partially implemented?).

However, that will take a while (years maybe?), and in the meantime I think your crates might not be legally be licenses under MIT like you intended: I think there is a strong argument it would default to "all rights reserved" making it very difficult for anyone to use your crates. Here are some discussions from other crates that have fixed the problem manually for now like tokio in this issue and bytecodealliance in this issue and lalrpopl in this issue.

[cyqsimon]

However, that will take a while (years maybe?), and in the meantime I think your crates might not be legally be licenses under MIT like you intended: I think there is a strong argument it would default to "all rights reserved" making it very difficult for anyone to use your crates.

Well frankly, if there are lawyers out there who are dead set on this interpretation (instead of what's obviously intended), they are free to not use this library. Their loss not mine 🤷.

A friendly suggestion for you: I think you're trying to push a lot of people one by one to do what you think is correct (which you might well be), and that's always going to be difficult. At least I don't think you'll be able to convince everyone.

Personally, I agree with you that there is a problem; I do not agree with you on the proposed solution. I think you should either go to Cargo, or perhaps just make an escape hatch for your tool. If I were you, I would just code this tool to also accept the declared license in Cargo.toml in lieu of a licence file. Maybe put it behind a --relaxed flag or something like that. This is the solution that makes the most sense to me.

[jacob-pa]

Fair enough, it is your library! 😄

Yeah I agree, I'll never be able to convince everyone! Maybe I should try and get at least an official change to the docs through, if I can persuade the cargo team to agree with my viewpoint, that might help persuade a wider audience with less effort. And yes I also agree: I'm going to add an escape hatch to the tool to work around edge cases like this.

Have a great day, and thanks for engaging in the discussion anyway despite disagreeing! I'll leave you in peace.