Skip to content

Rust code copyright situation is unclear #63232

Open
@brson

Description

@brson
Contributor

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

added
T-coreRelevant to the core team, which will review and decide on the PR/issue.
on Aug 3, 2019
gnzlbg

gnzlbg commented on Aug 3, 2019

@gnzlbg
Contributor

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

cuviper commented on Aug 5, 2019

@cuviper
Member

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

steveklabnik commented on Aug 5, 2019

@steveklabnik
Member

Semi-duplicate of #39897

brson

brson commented on Aug 7, 2019

@brson
ContributorAuthor

Semi-duplicate of #39897

lol @ me

brson

brson commented on Aug 7, 2019

@brson
ContributorAuthor

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

brson commented on Aug 7, 2019

@brson
ContributorAuthor

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

brson commented on Aug 7, 2019

@brson
ContributorAuthor

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

gnzlbg commented on Aug 7, 2019

@gnzlbg
Contributor

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

skade commented on Aug 11, 2019

@skade
Contributor

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

brson commented on Aug 30, 2019

@brson
ContributorAuthor

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

sunfishcode commented on Aug 30, 2019

@sunfishcode
Member

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.

8 remaining items

removed
T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
on Jan 23, 2020
changed the title [-]COPYRIGHT file is wildly out of date[/-] [+]Rust code copyright situation is extremely unclear[/+] on Nov 27, 2020
brson

brson commented on Nov 27, 2020

@brson
ContributorAuthor

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.

changed the title [-]Rust code copyright situation is extremely unclear[/-] [+]Rust code copyright situation is unclear[/+] on Nov 27, 2020
workingjubilee

workingjubilee commented on May 10, 2021

@workingjubilee
Member

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

tisonkun commented on Oct 23, 2021

@tisonkun
Contributor

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?

added and removed
T-coreRelevant to the core team, which will review and decide on the PR/issue.
on Mar 20, 2025
added a commit that references this issue on Apr 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @steveklabnik@cuviper@ehuss@skade@brson

        Issue actions

          Rust code copyright situation is unclear · Issue #63232 · rust-lang/rust