Repository navigation
Rust code copyright situation is unclear #63232
Description
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 ...).
Activity
brson commentedon Aug 3, 2019
Collecting a few Rust licensing infidelities:
gnzlbg commentedon Aug 3, 2019
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 commentedon Aug 5, 2019
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 commentedon Aug 5, 2019
Semi-duplicate of #39897
brson commentedon Aug 7, 2019
lol @ me
brson commentedon Aug 7, 2019
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 commentedon Aug 7, 2019
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 commentedon Aug 7, 2019
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 commentedon Aug 7, 2019
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:
-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
glibcinto 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 commentedon Aug 11, 2019
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:
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 commentedon Aug 30, 2019
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":
sunfishcode commentedon Aug 30, 2019
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:
nikomatsakis commentedon Sep 19, 2019
I want to add a link to #55993 here -- this is an issue concerning what the appropriate license would be the
apfloatlibrary. As described by @sunfishcode in that issue:@eddyb notes that the code in question has been recently relicensed to Apache 2:
But this seems like something to figure out.
1 remaining item
pnkfelix commentedon Nov 26, 2019
I'm temporarily tagging this with T-compiler (and leaving the nomination label) as a reminder to bring this up at this weeks triage meeting.
Also, I'm ranking this (or really, our general licensing issues across the project) as a P-high issue to resolve.
pnkfelix commentedon Jan 23, 2020
rust-lang/compiler-team#220 has been opened as a follow up task.
I am removing the T-compiler label; we currently don't have anything further to discuss on this matter amongst the compiler team, but I don't want to remove the nominated label while this still might be pending discussion amongst the core team.
[-]COPYRIGHT file is wildly out of date[/-][+]Rust code copyright situation is extremely unclear[/+]brson commentedon Nov 27, 2020
After reading some more unresolved linked threads and continuing to feel ashamed about this, I updated the title to better reflect that its not just the COPYRIGHT file that is incorrect, but that the copyright status of code all across the project is in an unclear state.
There are various links in this thread to problems with the Rust copyrights.
[-]Rust code copyright situation is extremely unclear[/-][+]Rust code copyright situation is unclear[/+]workingjubilee commentedon May 10, 2021
The strategy of using a dependency exceptions list in tidy as a "speedbump" has been successful at limiting the growth of this issue, I think, though I think I should provide an update on recent events, at least:
In #84498 I removed two dependency exceptions, which simplifies the copyright situation somewhat. But... it was also discovered that transitive dependencies do not require exceptions, which may be complicating our situation in a subtle way if we do not trust our dependencies. Obviously, if we think that auditing our transitive dependencies is unnecessary, then we're fine, but maybe we should ask our dependencies if they are in fact making sure their legal situation is okay.
In #84872, we gained a set of Cranelift exceptions, which all are licensed as Apache 2.0 with LLVM Exceptions, which is, as noted above, "the Apache License But In A Way We're Pretty Sure Is GPL Compatible", except for a BSD 2-clause license and ISC license.
tisonkun commentedon Oct 23, 2021
Hi @brson , I come to this issue when trying to see the copyright owner of rust project but fail to find in the LICENSE. What term do you use to name that?
Add tracing-tracy/-chrome deps to rustc_log