Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Published crates should include LICENSE file #3537

Closed
raphlinus opened this issue Jan 12, 2017 · 5 comments · Fixed by #7905
Closed

Published crates should include LICENSE file #3537

raphlinus opened this issue Jan 12, 2017 · 5 comments · Fixed by #7905
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-publish

Comments

@raphlinus
Copy link
Contributor

I'd like for published crates to include the text of the LICENSE along with the code. For our use case (making a repo of vendored crates), the cargo-vendor tool is populating the vendor directory with lots of packages that are missing LICENSE. There are basically two reasons for this:

  1. The LICENSE file is present in the source repository, in the same directory as the Cargo.toml config file, but the config file doesn't include the LICENSE in the list of files to be uploaded (because of an explicit "include" keyword). Examples include dtoa and serde.

  2. The LICENSE file is present in the source repo (typically in the repo root), but the crate is published from a subdirectory. Examples include num-traits and xi-core-lib.

There are (at least) two things "cargo publish" could do to mitigate this problem:

  1. The publish tool could do a lint check that an appropriate license file is present. There's a small amount of client-side sanity-checking now (checking that a license file exists if specified), and I believe the crates.io server also checks the spdx string.

  2. Automatically including LICENSE files from the repo root if publishing from a subdirectory.

I'll get around this for the time being by making my vendoring script do the latter at vendoring time, but I think it would be better if every stage in the chain precisely matched the exact contents.

@joshtriplett
Copy link
Member

There's a third possibility that needs to be covered: the crate source cites a well-known license and intentionally does not include a license file. That's not necessarily a bug.

If the crate does include a license file, I'm entirely in favor of having cargo make sure it gets included.

@ghost
Copy link

ghost commented Jan 11, 2018

And some licenses can be found in a COPYING file too. There are also PATENTS files that can change the meaning of a license to something else entirely. :(

@stale
Copy link

stale bot commented Sep 17, 2018

As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it.

I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect?

The team would be especially grateful if such a comment included details such as:

  • Is this still relevant?
  • If so, what is blocking it?
  • Is it known what could be done to help move this forward?

Thank you for contributing!

(The cargo team is currently evaluating the use of Stale bot, and using #6035 as the tracking issue to gather feedback.)

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!

@stale stale bot added the stale label Sep 17, 2018
@joshtriplett
Copy link
Member

This issue still exists.

Would someone be interested in contributing to this? In particular, making cargo package check for a file named "LICENSE" or "COPYING" (or a few other patterns) and automatically including it in the .crate file?

@stale stale bot removed the stale label Sep 17, 2018
@dwijnand dwijnand added the C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` label Sep 18, 2018
@richardwhiuk
Copy link

cargo publish does do this doesn't it - but cargo package doesn't?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-publish
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants