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

Licensing: It's unclear exactly what license text must be included in a Rust binary. #67014

Open
Lokathor opened this issue Dec 4, 2019 · 4 comments
Labels
A-licensing Area: Compiler licensing T-core Relevant to the core team, which will review and decide on the PR/issue.

Comments

@Lokathor
Copy link
Contributor

Lokathor commented Dec 4, 2019

Previous context: https://internals.rust-lang.org/t/does-the-standard-library-have-linking-exceptions-to-their-licensing/11377

Now obviously if you have [dependencies] from crates.io then you have to follow each appropriate license.

But if you just make a "no dependency" program, you're still including all sorts of code from std/alloc/core/libm/libc/compiler_builtins/hashbrown and possibly others I'm not even thinking of.

  • Can we please get a very clear, preferably single file, text to be included as the "attribution" for building a Rust program at all.
@Lokathor
Copy link
Contributor Author

Lokathor commented Dec 4, 2019

(I guess we could also try and start moving the various project components to using the Zlib OR Apache-2.0 combination instead of MIT OR Apache-2.0, but that would take ages, if we could even do it at all.)

@clehner
Copy link
Contributor

clehner commented Feb 20, 2021

This repo contains its licenses in the files COPYRIGHT, LICENSE-APACHE and LICENSE-MIT. But it also depends on external packages (such as hashbrown) from crates.io. Existing tools for analyzing crate dependency licenses based on traversing the filesystem and/or reading the output of cargo metadata, such as cargo-license, cargo-about, or cargo-lichking (Nemo157/cargo-lichking#63), could be used to gather license info for these (after checking out this repo and its git submodules). What would be helpful to know is which of these packages are included into builds, or at least which might be, for the purpose of determining license requirements. Is it just library/std from this repo as the entry point, or are there others? cargo-license calculates dependency license info for std as follows:

std $ cargo license --avoid-build-deps --avoid-dev-deps
Apache-2.0 OR Apache-2.0 WITH LLVM-exception OR MIT (1): wasi
Apache-2.0 OR MIT (10): cfg-if, compiler_builtins, dlmalloc, hashbrown, hermit-abi, libc, rustc-demangle, rustc-std-workspace-alloc, rustc-std-workspace-core, std
MPL-2.0 (1): fortanix-sgx-abi
N/A (5): alloc, core, panic_abort, panic_unwind, unwind

Edit: runtime crates are listed here:

/// These are the root crates that are part of the runtime. The licenses for
/// these and all their dependencies *must not* be in the exception list.
const RUNTIME_CRATES: &[&str] = &["std", "core", "alloc", "test", "panic_abort", "panic_unwind"];

Looks like std includes them all except test. Application binaries are probably not including the test runtime. So I think license requirements for distributing a Rust binary in general could be determined by analyzing the dependency tree of the application plus the std crate (assuming there isn't code being added in other places that I'm not aware of).

@MaulingMonkey
Copy link
Contributor

MaulingMonkey commented Mar 14, 2021

Rustup distributes those files with its docs:

  • %USERPROFILE%\.rustup\toolchains\1.6.0-x86_64-pc-windows-msvc\share\doc\rust\{COPYRIGHT, LICENSE-APACHE, LICENSE-MIT}
  • %USERPROFILE%\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\share\doc\rust\{COPYRIGHT, LICENSE-APACHE, LICENSE-MIT}
  • ${rustup show home}\toolchains\${rustup show active-toolchain}\share\doc\rust\{COPYRIGHT, LICENSE-APACHE, LICENSE-MIT}

COPYRIGHT has a bunch of old paths, and indirect references to files and crates... it'd be nice to clean that up and collate it into a single file or set of files (COPYRIGHT-RUNTIME?), and possibly generate it from files that can live alongside the source code they describe the licensing terms for to help combat future bitrot.

@MaulingMonkey
Copy link
Contributor

Doing an initial pass over COPYRIGHT:

LLVM

rust/COPYRIGHT

Line 26 in acca818

* LLVM. Code for this package is found in src/llvm-project.

rust/COPYRIGHT

Lines 53 to 57 in acca818

* Redistributions in binary form must reproduce the
above copyright notice, this list of conditions
and the following disclaimers in the documentation
and/or other materials provided with the
distribution.

🐛 Many/most rustc-generated binaries don't comply with this? But it's not the only license LLVM bits are distributed under - the runtime bits in particular tend to be (Apache-2.0 WITH LLVM-Exceptions) OR MIT OR ...legacy? with attribution for runtime binaries being, supposedly, unnecessary:

Binaries that include LLVM must reproduce the copyright notice (e.g. in an included README file or in an “About” box), unless the LLVM code was added as a by-product of compilation. For example, if an LLVM runtime library like compiler_rt or libc++ was automatically included into your application by the compiler, you do not need to attribute it.

https://llvm.org/docs/DeveloperPolicy.html#new-llvm-project-license-framework

[...] In addition to the UIUC license, the runtime library components of LLVM (compiler_rt, libc++, and libclc) are also licensed under the MIT License, which does not contain the binary redistribution clause. [...]

https://llvm.org/docs/DeveloperPolicy.html#legacy-license-structure

That said, I'm not sure LLVM's take on MIT not requiring binary redistribution is accurate:

What you need to do is include the license with your binary distributions, maybe as a text file, [...]

https://opensource.stackexchange.com/a/4061

LLVM Libs

rust/COPYRIGHT

Lines 75 to 77 in acca818

* Additional libraries included in LLVM carry separate
BSD-compatible licenses. See src/llvm-project/llvm/LICENSE.TXT
for details.

There are also some ISC licensed libs but I don't think they're used in LLVM-generated code. There's also Intel licensed OpenMP stuff, which I also don't think is included in generated Rust code, but I'm slightly less certain of that...

compiler-builtins

rust/COPYRIGHT

Lines 79 to 80 in acca818

* compiler-rt, in src/compiler-rt is dual licensed under
LLVM's license and MIT:

7e6c9f3 compiler-rt was moved to compiler-builtins
4c21a3b compiler-builtins was yeeted to crates.io

🐛 Should be rephrased? (Merged with other crates.io crates? But it's an oddball license...) Perhaps rephrased as:

* compiler-builtins, per https://github.com/rust-lang/compiler-builtins/blob/master/LICENSE.TXT,
  is dual licensed under LLVM's license and MIT: 

libbacktrace

rust/COPYRIGHT

Lines 195 to 198 in acca818

* libbacktrace, under src/libbacktrace:
Copyright (C) 2012-2014 Free Software Foundation, Inc.
Written by Ian Lance Taylor, Google.

🐛 I believe this section can be removed?

crates.io dependencies / MIT copyright notices

For distributing under Apache-2.0 license terms, the inclusion of LICENSE-APACHE should suffice.

🐛 For distributing under MIT license terms, some copyright attributions missing from LICENSE-MIT might need to be added - e.g.:

Copyright (c) 2017 The Rust Project Developers
Copyright (c) 2016 The Miri Developers
Copyright (c) 2014 Alex Crichton
Copyright (c) 2014 Jorge Aparicio
[...various places in rust-lang/rust/.../LICENSE-MIT]

Copyright (c) 2014 Alex Crichton
https://github.com/rust-lang/backtrace-rs/blob/c6e5bffdbe44cb9da250bda0a061ad5558673235/LICENSE-MIT#L1

Copyright (c) 2016 Amanieu d'Antras
https://github.com/rust-lang/hashbrown/blob/b50e258ba22e9d97cc8cbdfb7520e19d322827e4/LICENSE-MIT#L1

(list is incomplete, Cargo.lock is large...)

Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Mar 18, 2021
Add license metadata for std dependencies

These five crates are in the dependency tree of `std` but lack license metadata:
- `alloc`
- `core`
- `panic_abort`
- `panic_unwind`
- `unwind`

Querying the dependency tree of `std` is a useful thing to be able to do, since these crates will typically be linked into Rust binaries. Tools show the license fields missing, as seen in rust-lang#67014 (comment). This PR adds the license field for the five crates, based on the license of the `std` package and this repo as a whole. I also added the `repository` and `descriptions` fields, since those seem useful. For `description`, I copied text from top-level comments for the respective modules - except for `unwind` which has none.

I also note that rust-lang#73530 attempted to add license metadata for all crates in this repo, but was rejected because there was question about some of them. I hope that this smaller change, focusing only on the runtime dependencies, will be easier to review.

cc `@Mark-Simulacrum` `@Lokathor`
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Mar 19, 2021
Add license metadata for std dependencies

These five crates are in the dependency tree of `std` but lack license metadata:
- `alloc`
- `core`
- `panic_abort`
- `panic_unwind`
- `unwind`

Querying the dependency tree of `std` is a useful thing to be able to do, since these crates will typically be linked into Rust binaries. Tools show the license fields missing, as seen in rust-lang#67014 (comment). This PR adds the license field for the five crates, based on the license of the `std` package and this repo as a whole. I also added the `repository` and `descriptions` fields, since those seem useful. For `description`, I copied text from top-level comments for the respective modules - except for `unwind` which has none.

I also note that rust-lang#73530 attempted to add license metadata for all crates in this repo, but was rejected because there was question about some of them. I hope that this smaller change, focusing only on the runtime dependencies, will be easier to review.

cc ``@Mark-Simulacrum`` ``@Lokathor``
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Mar 19, 2021
Add license metadata for std dependencies

These five crates are in the dependency tree of `std` but lack license metadata:
- `alloc`
- `core`
- `panic_abort`
- `panic_unwind`
- `unwind`

Querying the dependency tree of `std` is a useful thing to be able to do, since these crates will typically be linked into Rust binaries. Tools show the license fields missing, as seen in rust-lang#67014 (comment). This PR adds the license field for the five crates, based on the license of the `std` package and this repo as a whole. I also added the `repository` and `descriptions` fields, since those seem useful. For `description`, I copied text from top-level comments for the respective modules - except for `unwind` which has none.

I also note that rust-lang#73530 attempted to add license metadata for all crates in this repo, but was rejected because there was question about some of them. I hope that this smaller change, focusing only on the runtime dependencies, will be easier to review.

cc ```@Mark-Simulacrum``` ```@Lokathor```
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Mar 22, 2021
Add license metadata for std dependencies

These five crates are in the dependency tree of `std` but lack license metadata:
- `alloc`
- `core`
- `panic_abort`
- `panic_unwind`
- `unwind`

Querying the dependency tree of `std` is a useful thing to be able to do, since these crates will typically be linked into Rust binaries. Tools show the license fields missing, as seen in rust-lang#67014 (comment). This PR adds the license field for the five crates, based on the license of the `std` package and this repo as a whole. I also added the `repository` and `descriptions` fields, since those seem useful. For `description`, I copied text from top-level comments for the respective modules - except for `unwind` which has none.

I also note that rust-lang#73530 attempted to add license metadata for all crates in this repo, but was rejected because there was question about some of them. I hope that this smaller change, focusing only on the runtime dependencies, will be easier to review.

cc `@Mark-Simulacrum` `@Lokathor`
@pietroalbini pietroalbini added the A-licensing Area: Compiler licensing label Jun 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-licensing Area: Compiler licensing T-core Relevant to the core team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants