LICENSE files in package subdirs

[schwa423]

Background:

Hello, the Fuchsia project vendors crates from crates.io, and in order to do so we require explicit license files alongside the source code. Here is the policy: https://fuchsia.dev/fuchsia-src/contribute/governance/policy/open-source-licensing-policies?hl=en#licenses_and_tracking . In particular, reading the SPDX package/license field from the crate's Cargo.toml is not good enough.

Request:

Could you please add LICENSE-* files to the package subdirectories? We care particularly about wgpu, wgpu-core, wgpu-hal, and wgpu-types but you might as well do the other subdirs while you're at it, e.g. wgpu-info.

Regarding the versions that we need updated, we're just about to start using wgpu (as soon as we can work through all these licensing issues, including for downstream dependencies), so bumping the latest versions of all crates would work for us.

I'd appreciate if you're able to do this, since I have to file similar issues for many other crate dependencies. But if you don't have the bandwidth to address this issue, please let me know and I'll find time to submit a pull request (although of course I won't be able to upload anything to crates.io)

[kvark]

Thanks for reaching out!

Here is what Cargo says about licenses:

The license field contains the name of the software license that the package is released under. The license-file field contains the path to a file containing the text of the license (relative to this Cargo.toml).
crates.io interprets the license field as an SPDX 2.1 license expression.
If a package is using a nonstandard license, then the license-file field may be specified in lieu of the license field.

IANAL, but to me this reads like a correct Rust project can specify its license by just naming it. If it's a name recognized by "SPDX 2.1", then the file doesn't even need to be there (for the purposes of Cargo/Crates, that is. We still place it there for Git/Github and friends). And since you are trying to associate licenses with crates projects, I don't fully understand why you need files.

I.e. based on the Cargo documentation, your license search could just look at the "license" field. If it's set, then do a dictionary lookup for the actual text, and done. If "license" is not set, then look for "license-file", and this relative path (I assume) is included into Cargo package.

Is there a reason you don't trust "license" records of the packages?

[schwa423]

Hi Kvark! Thanks for all of your work in the various ecosystems (Vulkan, Rust, gfx/wgpu) in recent years!

My understanding is that the only expression of licensing that has been blessed by our lawyers is to have explicit LICENSE files. However, maybe we just didn't ask them the question the right way, because I agree it seems like the packages/license field of the Cargo.toml seems like a sufficient expression of the crate authors' intent. I'll double-check.

[schwa423]

Here is the relevant policy text that Fuchsia uses: https://fuchsia.dev/fuchsia-src/contribute/governance/policy/open-source-licensing-policies?hl=en#licenses_and_tracking

I just verified with a more knowledgeable team member: our lawyers have explicitly not OKed SPDX as a sufficient expression of licensing intent.

[kvark]

Thanks for clarification!
I think I see where my expectations diverge from your workflow now.
Before we jump into action here, I'd like to ask you one more question.

Would it be possible on your side to process the results of cargo vendor in an automated way, with tooling, such that licenses are always present? I.e. the algorithm would be as follows:

1. read the toml file (using any toml parser), extract the license
2. parse the SPDX license expression (there appear to be a few libraries for parsing that)
3. download the SPDX licenses as files

Presumably, this would happen after cargo vendor and before you check in the modified sources into the repository on your side.

This seems quite doable, and would provide you with a universal solution for the whole Rust ecosystem, not requiring any maintainers attention. If such (non-advanced) technology/tooling existed, would you be able to use it?

[schwa423]

Hi, sorry for the lapse in conversation. In parallel to reaching out to crate maintainers, I proposed exactly your solution to our legal folks. Unfortunately this is not allowed (too bad, it would be a great solution, technically!). For whatever esoteric legal reasons, they want literal LICENSE files to exist alongside the source code.

[kvark]

Alright, I suppose we are out of options then. Let's add those files to each crate sub-directory (that you are interested in).

[schwa423]

Thanks! If nobody steps up to do, I'll find time to make a PR.