Problem
A lot of crates that are published from workspace repositories have their licenses in the top level. This means that when the crates are published to crates.io, the license is not included in the shipped source. There are some interpretations of licensing laws that could maybe mean that these crates are not licensed, so could default to "all rights reserved" in some jurisdictions. This makes it tricky for conservative users to build software from these crates.
I have been trying to persuade a couple of other crate vendors to do it, but it requires a lot of repetition on my part, and having to make my case multiple times. A few of them have said to me that they want to see "official guidance" before doing it. Heres one example cyqsimon/documented#33.
Proposed Solution
I think that the cargo documentation should clearly advise users publishing from a workspace repository to include license files in each individual crate.
To be very clear, I'm NOT suggesting that cargo docs say "you must ship licenses with each crate". I'm suggesting a section that says something like "IF you publish crates from a workspace and IF you want to be very sure you have licensed it properly you SHOULD include the license file individually in each crate folder, not just at the top level".
I know this is not a cargo problem per-se, but documenting this stumbling block in the cargo docs in the licensing section would give an authoritative place for people like me to point to outlining the arguments. And this problem comes about because of how workspaces and cargo publish work.
Also the cargo config docs section on the "license" and "license_file" is a logical place to discuss things like this.
Notes
This is a common recurring stumbling block, and there is lots of discussion about it on various forums. Lots of big multi-crate workspace mono-repos (like tokio) have fixed this by putting the licenses in each crate. See discussion tokio in this issue and bytecodealliance in this issue and lalrpopl in this issue.
A more automated long term solution might be to have all license file paths documented in the workspace Cargo.toml, and they are automatically grabbed by cargo and shipped with individual crate publishing, but I that's outside the scope of this ticket and would require a lot more discussion (some of which is already ongoing elsewhere).
Problem
A lot of crates that are published from workspace repositories have their licenses in the top level. This means that when the crates are published to crates.io, the license is not included in the shipped source. There are some interpretations of licensing laws that could maybe mean that these crates are not licensed, so could default to "all rights reserved" in some jurisdictions. This makes it tricky for conservative users to build software from these crates.
I have been trying to persuade a couple of other crate vendors to do it, but it requires a lot of repetition on my part, and having to make my case multiple times. A few of them have said to me that they want to see "official guidance" before doing it. Heres one example cyqsimon/documented#33.
Proposed Solution
I think that the cargo documentation should clearly advise users publishing from a workspace repository to include license files in each individual crate.
To be very clear, I'm NOT suggesting that cargo docs say "you must ship licenses with each crate". I'm suggesting a section that says something like "IF you publish crates from a workspace and IF you want to be very sure you have licensed it properly you SHOULD include the license file individually in each crate folder, not just at the top level".
I know this is not a cargo problem per-se, but documenting this stumbling block in the cargo docs in the licensing section would give an authoritative place for people like me to point to outlining the arguments. And this problem comes about because of how workspaces and cargo publish work.
Also the cargo config docs section on the "license" and "license_file" is a logical place to discuss things like this.
Notes
This is a common recurring stumbling block, and there is lots of discussion about it on various forums. Lots of big multi-crate workspace mono-repos (like tokio) have fixed this by putting the licenses in each crate. See discussion tokio in this issue and bytecodealliance in this issue and lalrpopl in this issue.
A more automated long term solution might be to have all license file paths documented in the workspace Cargo.toml, and they are automatically grabbed by cargo and shipped with individual crate publishing, but I that's outside the scope of this ticket and would require a lot more discussion (some of which is already ongoing elsewhere).