Rust code copyright situation is unclear

[brson]

Edit 2020/11/27 - I've updated the title of this post to reflect that Rust's copyright is generally a mess. There are links throughout this thread to further details.

Original text:

The COPYRIGHT file is out of date.

This file extends back to the beginning of time and has rarely been updated. It mostly exists to explain that while Rust is MIT/Apache, it also includes LLVM, which has its own license.

Today, the Rust distribution contains lots and lots of source code, under a wide variety of licenses. The COPYRIGHT file is quite insufficient to describe Rust's license soup.

Rightfully, Rust needs to reproduce the license of all its constituent components. In the meantime though, it would not be inappropriate to just delete this file, or to replace it with simpler temporary language along the lines of "Rust is mostly Apache / MIT, but some parts have a different license. Sorry, but at this time I can't tell you exactly which, figure it out yourself. TODO FIXME YOLO"

One notable aspect of this file is declaring that "portions of the FFI code for interacting with the native ABI is derived from the Clay programming language, which carries the following license." This language was added by myself from an abundance of caution with the very first x86_64 (probably) FFI commits. It is likely that the FFI source code has changed so much that it no longer carries any resemblance to the clay source code and this language can be dropped, but is probably worth investigating first. If not, then the license, which is just a 2-clause BSD with specific attribution, can be added directly to the x86_64 ffi source.

Since Rust's licensing is so complex I might suggest a new solution that, instead of reproducing entire licenses, describes which source code is licensed under which license, by name, e.g.

- [mdbook] - [MPL2]
- [openssl] - [BSD+advertising clause]
- src/foo/bar/x86_64.rs - [BSD 2-clause]
...

A good start for creating this list is the EXCEPTIONS list in src/tools/tidy/deps, though it is not complete for code that is not a rust crate (LLVM isn't included). The situation is complex enough that it probably shouldn't be done manually, but tooling added to deal with it, probably building off the src/tidy tooling.

It's important to be clear in any licensing documentation that the runtime (std/test) is purely Apache-2.0/MIT/$OTHER_PERMISSIVE_LICENSE (i.e. your code isn't "infected" by non-permissive licenses), but the tooling contains copyleft code. (Though note that per the EXCEPTIONS list, the fortanix target does include MPL runtime code ...).

[brson]

Collecting a few Rust licensing infidelities:

• Crate declares incorrect Apache/MIT license compiler-builtins#307
• Package is incorrectly licensed Apache/MIT libm#215
• backtrace-sys crate declares incorrect Apache/MIT license backtrace-rs#234
• Inconsistent licensing language sfackler/rust-openssl#1147
• deps.rs EXCEPTIONS needs to be re-triaged #63238

[gnzlbg]

What worries me the most is that no individual or team seems to be in charge of which licenses Rust or the run-time are using.

I wanted to add a dependency to the run-time which was "2-clause BSD-licensed" but that was something that nobody was able to tell whether it would be ok from a licensing perspective. I opened a couple of issues about the comments in the source files being incorrect and misleading, but some like #62620 were closed without really addressing the problem.

[cuviper]

I suspect the LLVM portion also needs updating for the relicensing in LLVM 9 to "Apache License v2.0 with LLVM Exceptions". I believe for now it is dual-licensed such that we can still release it under the legacy UIUC license, but this won't be true forever.

[steveklabnik]

Semi-duplicate of #39897

[brson]

Semi-duplicate of #39897

lol @ me

[brson]

I suspect the LLVM portion also needs updating for the relicensing in LLVM 9 to "Apache License v2.0 with LLVM Exceptions". I believe for now it is dual-licensed such that we can still release it under the legacy UIUC license, but this won't be true forever.

It hasn't be completed yet, so from my understanding LLVM can't be wholly distributed under Apache-2 yet.

I have only just now realized that (afaict) this will mean that rustc as a whole in the future will contain Apache-only code. As of now everything (i think) in rustc (but not all the other tools) is MIT-or-weaker. It's not a huge problem, just one more drop in the Rust licensing bucket. In practical terms it mostly means that rustc won't be able to be linked to GPL2 code.

[brson]

What worries me the most is that no individual or team seems to be in charge of which licenses Rust or the run-time are using.

It bothers me too :)

After posting these issues I started braindumping everything I know about Rust's licensing, incomplete draft here: https://gist.github.com/brson/48ede1b5365389a75f7d97e610ed694f

In the past the policy was roughly - runtime is MIT-or-equivalent-or-weaker (plus Apache option for most of it); tools (that aren't rustc?) can reluctantly contain MPL code (this started w/ mdbook). There is tooling in-tree to try to enforce this, but I doubt many (or any) are paying attention to the fine details.

Note though that per my linked draft, the runtime seems to have managed to mostly be not just MIT-or-equivalent-or-weaker, but almost entirely MIT. The only exceptions to this are: libbacktrace, 3-clause BSD; the fortanix SGX runtime libraries, which are MPL and conditionally downloaded and compiled only for that target.

I don't know enough about the MPL to know if the fortanix code is a problem. I suspect it is not, as the MPL is a per-file license, and does not "infect" entire projects like the GPL (i think) does. But I don't know enough about the specifics of either the MPL or GPL to be confident about it.

cc @gnzlbg @cuviper

[brson]

Note though that per my linked post, the runtime seems to have managed to mostly be not just MIT-or-equivalent-or-weaker, but almost entirely MIT. The only exceptions to this are: libbacktrace, 3-clause BSD

Actually, on closer inspection, BSD-3-Clause appears to be more restrictive than MIT. It's kind of philosophically disappointing that the runtime contains more-restrictive BSD-3-Clause code, but from a practical standpoint probably insignificant.

[gnzlbg]

I don't know enough about the MPL to know if the fortanix code is a problem. I suspect it is not, as the MPL is a per-file license,

Thank you for working on this.

I think that we need to clarify what the policy is for the target platform C library. AFAICT, the only options we have here is whether we link it statically or dynamically - an option that sometimes users can override using -C target-feature+/-crt-static - or whether we re-implement it under a different license like Go does.

This last alternative is IMO out of scope, so I'll be fine with just documenting:

• the license of the platform C library,
• how is this library linked by default for each target (statically or dynamically),
• if the license is restrictive, what would the consequences of statically linking it be (e.g., by using -C target-feature=+crt-static).

For example, I don't really know how the GPLv3 works, but I'd be curious of the consequences of trying to statically link glibc into a Rust binary, e.g., I wonder if this would require me to release all source code of the binary including all run-time components under the GPLv3 which would be.. problematic.

[skade]

First, some words in advance: I'd prefer to keep the word "restrictive" out of here, it isn't a term used in licensing discussions. The GPL is copyleft to ensure that it isn't watered down. On the same note, let's avoid "viral", as the GPL isn't viral, it only has expectations on the distribution.

The platform libc question is kind of scope here, for 2 reasons:

• glibc is licensed under the the LGPL. That indeed has some particularities about static linking, specifically that while no source code must be provided, the program must enable the user to replace the library, either by using a different dynamic library or providing some way to relink.
• the glibc becomes a part of the resulting program, while the COPYRIGHT file should document the components and runtime components of the compiler distribution. How the libc is linked is both target and user-specific. We can provide documentation there for ease of use, but I don't think the COPYRIGHT file is the right place.

Note that GCC itself has an exception from its license for the runtime libraries the compiler links in: https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html

A declaration like this could make sense for our runtime components.

[brson]

I haven't been following this discussion but wanted to link to a musing about the ideal way to handle the desired runtime exception for std: bytecodealliance/wasi-rs#9 (comment)

This is in context of the rust-wasi license, which is currently "Apache-2.0/Apache-2.0+LLVM exception/MIT", and here's what I just said about how this might compare to "Apache-2.0/BSL-1.0/MIT":

Oh actually, there might be a reason to prefer BSL-1.0 over Apache+LLVM - the GPL 2 compatibility. Now, I don't remember why Apache 2.0 is not GPL 2.0 compatible, so caveat, but the Apache+LLVM/MIT license presumably implies that "you are allowed to use the runtime exception, unless you are linking to GPL 2 code". Though perhaps the LLVM exception fixes the GPL 2 problem, or it has since been determined that Apache 2 and GPL 2 are compatible.

[sunfishcode]

I'm not a lawyer, and the following isn't legal advice.

I'm told that dual-licensing is more complex than a single license, because dual-licensing doesn't automatically mean that end users get the union of all the rights. With a single license, it's clear what you get.

For the record, Apache-2.0 WITH LLVM-exception provides:

• GPLv2 compatibility,
• Clarity on what the license means for compiler output,
• Apache-2.0 patent protections,
• And vetting by many legal departments, large and small, specifically for use in compilers, runtimes, and libraries,
• In a single license.