Include license text in all published crates

[davide125]

The MIT license requires the license text to be included in all redistributed sources. Add symlinks to ensure it will be included in all published crates build from this repository.

[anastygnome]

You should copy the licence each time.
As far as git is concerned, only one blob would be used and windows would be less of a pain.

[sylvestre]

I think it is a bit overkill.
What the point of this change?

[davide125]

Right now, the license text is not included in crate packages (e.g. look at https://crates.io/crates/uucore), which technically violates the MIT license (see https://github.com/uutils/coreutils/blob/main/LICENSE#L10-L11). By adding a LICENSE file for each crate, we ensure that the next time the crates are published they'll include it, fulfilling the MIT provision.

[tertsdiepraam]

I have a couple of notes:

1. Law is complicated and can be interpreted multiple ways, so I think we need a little bit more than just your word.
2. If we are indeed currently in violation, then does this PR really solve it? Downloading a single crate will not give you the context of the rest of the project, so what is a relative link worth at that point?
3. I think it's more important that we specify the license in the various Cargo.toml files of the crates, so that the information shows up on crates.io. Nevermind, we already have this.

All that being said, I wouldn't be opposed to adding the license file to all crates. It adds a bit of noise, but it does make it clearer what license we are using on crates.io and other places. A quick scan of some other projects with multiple crates in one repository and whether they add a license file to each crate:

• ripgrep: yes (file is copied to each crate)
• nushell: sometimes (they're not consistent)
• swc: no
• tokio: yes (also copied files)
• actix-web: yes (with links like this PR)

[davide125]

Caveat: I'm not a lawyer. This came up in the context of attempting to package coreutils in Fedora (specifically in https://bugzilla.redhat.com/show_bug.cgi?id=1980205), cc @decathorpe; see https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text for how Fedora explains the problem.

The way cargo works, it'll resolve the symlink and include the actual file in the published crate. You can verify this by running cargo package and then inspecting the resulting crate (e.g. with tar xvzf). So both symlinks and copied files should work the same, and result in the actual file being included in the crate (I don't personally have a preference one way or the other -- happy to update this to copy files instead if that's what you want to go with).

[tertsdiepraam]

Thank you for the additional information! @sylvestre, I'm in favor of this, but I'll leave the final decision up to you.

[rivy]

Including the LICENSE widely seems reasonable, especially if it's cheap to implement.
In favor.

I'd also change the LICENSE header to...

Copyright (c) UUtils contributors
Copyright (c) Jordi Boggiano

The MIT License

[decathorpe]

Caveat: I'm not a lawyer. This came up in the context of attempting to package coreutils in Fedora (specifically in https://bugzilla.redhat.com/show_bug.cgi?id=1980205), cc @decathorpe; see https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text for how Fedora explains the problem.

I'm not a lawyer either :) But this is how it has been explained to me: Most popular licenses (including MIT and Apache-2.0) require redistributed sources to include a copy of the actual license test. Pages like choosealicense.com or the OSI also explain it this way.

So, since you're redistributing sources for individual crates (via crates.io), they should all include the license text. This is also the case for Fedora Linux RPM packages for Rust crates, which each redistribute one crate, and hence need a license file.

The way cargo works, it'll resolve the symlink and include the actual file in the published crate. You can verify this by running cargo package and then inspecting the resulting crate (e.g. with tar xvzf). So both symlinks and copied files should work the same, and result in the actual file being included in the crate (I don't personally have a preference one way or the other -- happy to update this to copy files instead if that's what you want to go with).

Caveat: As far as I know, doing it with a symlink does only work when running "cargo publish" on Unix-y systems, and not on windows.

[oech3]

Those symlinks in tarball cause many errors on Windows...