Wasmtime GitHub notifications bot (Aug 09 2022 at 19:22): Wasmtime GitHub notifications bot (Aug 09 2022 at 19:22):alexcrichton commented on issue #4664:
Personally I do not want to organize the repository like this. I don't think it's useful to have this copied all over the place and even with CI checking it that just seems like it'll be more annoying than anything else.
IIRC Cargo does processing of a
license-filedirective and puts it into the root crate, so could that be investigated instead of copying the files around?
Wasmtime GitHub notifications bot (Aug 09 2022 at 19:26):cfallin commented on issue #4664:
I tend to agree, but downstream packagers want this -- @decathorpe in #3761 needs LICENSE files in each crate (or at least the published ones) for packaging in Fedora (IIRC?).
@decathorpe, would it be acceptable instead to remove all LICENSE files except for the root one, and then update your packaging setup to refer to that?
Wasmtime GitHub notifications bot (Aug 09 2022 at 19:49):decathorpe commented on issue #4664:
If I understand correctly, "license-file" is only supposed to be used when using a non-standard license, i.e. the two fields in Cargo.toml are mutually exclusive:
https://doc.rust-lang.org/cargo/reference/manifest.html#the-license-and-license-file-fields
Concerning inclusion of the license text in individual crates: Lawyers / people who understand licenses better than me explained it this way: Some software licenses (including Apache-2.0 and MIT, the de-facto standard licenses for Rust projects), include a requirement that redistributed sources MUST contain a copy of the actual license text (i.e. the LICENSE file).
So, since you are _redistributing_ this project as individual crates on crates.io (and subsequently, Linux distributions might create and redistribute packages for those crates), they need to include license file(s) to be in compliance with the license that you yourselves have chosen for your project.
It also looks like you added copies of the LICENSE files in some places where they are actually not needed (for example, workspace directories that don't contain crates, or "internal" crates that are not published individually).
And, assuming that the operating system that "cargo publish" is run on for this project supports symbolic links, you don't actually need to include full copies of the file everywhere, but a symbolic link is sufficient for cargo to include it.
Wasmtime GitHub notifications bot (Aug 09 2022 at 20:16):alexcrichton commented on issue #4664:
I understand that
licenseandlicense-fileare typically mutally exclusive. Your packaging use case does not appear to respectlicense = "..."in the manifest and requires that some file is present. We do not want to removelicense = "..."for Rust-based tooling reasons. I'm proposing a compromise where, if you're willing to put in the work,license-fileannotations are added which all point to the rootLICENSEin the repository which I believe Cargo will then copy to the crate.
Wasmtime GitHub notifications bot (Aug 09 2022 at 20:43):decathorpe commented on issue #4664:
Your packaging use case does not appear to respect license = "..." in the manifest and requires that some file is present.
Our tooling for creating RPM packages does read the
package.licensevalue from Cargo.toml, and uses that value to populate the License field of packages.But even if that were not the case, and the license string was determined by asking an oracle, the problem is the missing license text / file:
c.f. https://choosealicense.com/licenses/apache-2.0/ at 4. Redistribution, (a):
You must give any other recipients of the Work or Derivative Works a copy of this License
I don't see a distinction between redistribution via crates.io and redistribution by linux distributions here (other than the fact that in the first case, you're violating your own license terms, while in the second case, it usually prevents linux distributions from redistributing your code), so the problem is definitely not specific to Linux distribution packages.
Wasmtime GitHub notifications bot (Aug 09 2022 at 23:42):github-actions[bot] commented on issue #4664:
Subscribe to Label Action
cc @cfallin, @fitzgen, @peterhuene
<details>
This issue or pull request has been labeled: "cranelift", "isle", "wasmtime:c-api", "wasmtime:docs"Thus the following users have been cc'd because of the following labels:
- cfallin: isle
- fitzgen: isle
- peterhuene: wasmtime:c-api
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
Wasmtime GitHub notifications bot (Aug 10 2022 at 03:14):cfallin commented on issue #4664:
@decathorpe understood that we need to include the license file, one way or another, in the tarball that is uploaded to crates.io. I think this is covered by what @alexcrichton was proposing:
I'm proposing a compromise where, if you're willing to put in the work, license-file annotations are added which all point to the root LICENSE in the repository which I believe Cargo will then copy to the crate.
I just checked locally with
cargo packagelocally and in a crate withlicenseandlicense-fileattributes, with the latter pointing out-of-tree (to the parent directory), the following happens:
- The package does include the license file; it is copied in by Cargo.
- However, Cargo emits a warning:
Packaging a v0.0.1 (/Users/cfallin/t/a) Verifying a v0.0.1 (/Users/cfallin/t/a) warning: only one of `license` or `license-file` is necessary `license` should be used if the package license can be expressed with a standard SPDX expression. `license-file` should be used if the package uses a non-standard license. See https://doc.rust-lang.org/cargo/reference/manifest.html#the-license-and-license-file-fields for more information.
and as @alexcrichton notes, we cannot drop thelicenseattribute for a bunch of reasons (tooling reads and depends on it).@alexcrichton, do you know if there is a way to suppress this warning?
Wasmtime GitHub notifications bot (Aug 10 2022 at 03:15):cfallin edited a comment on issue #4664:
@decathorpe understood that we need to include the license file, one way or another, in the tarball that is uploaded to crates.io. I think this is covered by what @alexcrichton was proposing:
I'm proposing a compromise where, if you're willing to put in the work, license-file annotations are added which all point to the root LICENSE in the repository which I believe Cargo will then copy to the crate.
I just checked with
cargo packagelocally and in a crate withlicenseandlicense-fileattributes, with the latter pointing out-of-tree (to the parent directory), the following happens:
- The package does include the license file; it is copied in by Cargo.
- However, Cargo emits a warning:
Packaging a v0.0.1 (/Users/cfallin/t/a) Verifying a v0.0.1 (/Users/cfallin/t/a) warning: only one of `license` or `license-file` is necessary `license` should be used if the package license can be expressed with a standard SPDX expression. `license-file` should be used if the package uses a non-standard license. See https://doc.rust-lang.org/cargo/reference/manifest.html#the-license-and-license-file-fields for more information.
and as @alexcrichton notes, we cannot drop thelicenseattribute for a bunch of reasons (tooling reads and depends on it).@alexcrichton, do you know if there is a way to suppress this warning?
Wasmtime GitHub notifications bot (Aug 10 2022 at 15:05):alexcrichton commented on issue #4664:
I don't know how to suppress that myself, and that sounds like an issue for upstream Cargo.
Wasmtime GitHub notifications bot (Aug 10 2022 at 16:21):cfallin commented on issue #4664:
This looks like rust-lang/cargo#8537, which is closed with a "we won't support this" disposition -- see this comment in particular. Their reasoning is that adding both keys (
licenseandlicense-file) could be ambiguous, and Cargo doesn't want the complexity, and tools on top of Cargo should be responsible for gathering license files for standard licenses.(As an aside, I bet there are a whole bunch of crates on crates.io that have a standard SPDX
licenseexpression and don't include the file itself; @decathorpe have you looked at this much for other crates?)The person who opened that Cargo issue cc'd tokio-rs/tracing#842 where the
tracingcrate had exactly the same discussion that we're having here, and concluded that they just needed to duplicateLICENSEinto every crate.So it seems that's kind of our only option to (i) satisfy legal requirements and (ii) work with Cargo. I'll pare this PR down to just adding
LICENSEin the two new crates, and I'll either see if I can find a way to hack the CI license-is-present check into the publish.rs script for just published crates, or omit it for now.
Wasmtime GitHub notifications bot (Aug 10 2022 at 16:24):cfallin edited a comment on issue #4664:
This looks like rust-lang/cargo#8537, which is closed with a "we won't support this" disposition -- see this comment in particular. Their reasoning is that adding both keys (
licenseandlicense-file) could be ambiguous, and Cargo doesn't want the complexity, and tools on top of Cargo should be responsible for gathering license files for standard licenses.(As an aside, I bet there are a whole bunch of crates on crates.io that have a standard SPDX
licenseexpression and don't include the file itself; @decathorpe have you looked at this much for other crates?)The person who opened that Cargo issue cc'd tokio-rs/tracing#842 where the
tracingproject had exactly the same discussion that we're having here, and concluded that they just needed to duplicateLICENSEinto every crate.So it seems that's kind of our only option to (i) satisfy legal requirements and (ii) work with Cargo. I'll pare this PR down to just adding
LICENSEin the two new crates, and I'll either see if I can find a way to hack the CI license-is-present check into the publish.rs script for just published crates, or omit it for now.
Wasmtime GitHub notifications bot (Aug 10 2022 at 16:53):cfallin commented on issue #4664:
@decathorpe I've modified this PR to add LICENSE files just to the six (!) crates we have added recently without LICENSE files, and to add a check to the
publish.rsscript that runs in our CI to verify publishability.Unfortunately it looks like
wasi-nnis missing a LICENSE file as well, and that's an upstream repo that would need a separate PR to fix and then a PR here to pull in a new submodule version. Would you be willing to do that legwork? If that's merged then CI here should pass and hopefully we can merge this.@alexcrichton thoughts on this new CI check?
Wasmtime GitHub notifications bot (Aug 15 2022 at 13:48):decathorpe commented on issue #4664:
Looks good to me, thank you.
Wasmtime GitHub notifications bot (Aug 15 2022 at 16:00):cfallin commented on issue #4664:
@decathorpe could you respond to the question:
Unfortunately it looks like wasi-nn is missing a LICENSE file as well, and that's an upstream repo that would need a separate PR to fix and then a PR here to pull in a new submodule version. Would you be willing to do that legwork? If that's merged then CI here should pass and hopefully we can merge this.
I unfortunately can't spend much more time on this either but if you are willing to drive this with the above effort, then I can rebase this and merge when that's done. Thanks!
Wasmtime GitHub notifications bot (Aug 15 2022 at 18:05):decathorpe commented on issue #4664:
Sorry, I missed that one.
I can try, but I'm not really interested in wasi-nn as it's dependencies don't look like they'd be available to be.
More important is wasi-common, which also has a problem like this, and it's been ignored for a while: https://github.com/bytecodealliance/wasmtime/issues/3912
Wasmtime GitHub notifications bot (Oct 12 2022 at 02:36):cfallin commented on issue #4664:
I'm cleaning up old PRs and am going to go ahead and close this for now; this has become out-of-date anyway (new crates in the meantime). @decathorpe please feel free to recreate a new version of the PR as you see fit.
Last updated: Dec 23 2024 at 13:07 UTC