rust-lang
Crate declares incorrect Apache/MIT license
The source code in this crate is derivative of LLVM's compiler-rt, the license of which is declared correctly in LICENSE.TXT, but not in Cargo.toml, and is the NCSA license (similar to BSD).
Cargo.toml needs to be updated to declare the NCSA license, and then the Rust tidy file in deps.rs to declare it as either an exception or an acceptable permissive license.
Note that LLVM is in the process of relicensing to add a runtime exception to its code (which Rust lacks), and this crate will not obviously benefit from that relicensing since it was derived prior to the relicense.
cc https://github.com/rust-lang/rust/issues/63232
This crate also includes a Rust port of MUSL's libm: https://github.com/rust-lang-nursery/libm, which also seems to incorrectly be described as Apache/MIT.
Oh, actually, compiler-rt is NCSA/MIT, so this crate can declare just "MIT" or "MIT/NCSA" or "MIT or NCSA". It just can't add the option of alternately distributing under the apache license (I think).
Please ignore my previous comments, I think they are obsolete and I have deleted them.
As I understand it, the files in src/** are all rust translations that do not appear in the original compiler-rt work, therefore it is a derivative work, which has been authorised by the license of compiler-rt at the time of derivation. Since it is a derivative work, the new copyright holders are free to chose a license for it, according to the restrictions of the original work (in this case there are no restrictions, either in NCSA/MIT/Apache), it does not have to be a copy of the old license. So it is fine to relicense as Apache/MIT.
However, you should then remove all references to the compiler-rt licenses for clarity. Or perhaps include them for reference, but make it clear that it is the license of compiler-rt an external project, and not the license of this project.
TL; DR - the presence of LICENSE.TXT is confusing, either delete it or move the contents into README.md under a section called "history of the project" and "for reference, this is the old license of compiler-rt".
For the record, the Debian package got uploaded some time ago with a description of the copyright situation explained, and now was rejected by our FTP-Masters team again.
I took a look at the LICENSE.TXT file, and it includes hints to the CREDITS.TXT file, which is not present in this project, but in compiler-rt. Even if the license file distribution was fixed as suggested by MR #343, this would probably be rejected by our FTP-Masters team, so I think it would in fact be better to move the information into README.md as suggested by @infinity0.
In case people can't be bothered reading the previous links, the TL;DR from the Debian copyright reviewers is that
- it's OK for the rust parts of the code to have a completely new license (in this case Apache/MIT), since it is a translation and the copyright holders of the original do not have copyright on the translation, as long as the relicensing is not prevented by the old license (and it is not, in this case)
- however, some comments are copied verbatim from the original, and so the original copyright holders have (retain) copyright on that, with the original license (a custom Sun license).
Makes sense to me, though ofc none of us are lawyers.
So to be extra clear, if we remove the comments but don't change the code at all that would be sufficient to use the standard MIT/Apache of other rust crates?
That would be consistent with the position as I understand it of the Debian copyright reviewers, yes.
Is there anything we as debian-rust can do to support progress here? This is one of a few serious issues that have stalled the packaging efforts of Rust crates inside Debian nearly down to zero, and I would love to get it resolved.
This is not a blocker for Debian, we can just document the license as (MIT or Apache) and Sun-Custom for now, as recommended by the copyright reviewer. I just haven't had time to do this yet.
The issues about SunCustom above actually only apply to the libm code, I can't see any similar comments in this crate. So this particular issue can be closed, after the obsolete mentions of the older NSCA licenses are corrected.
In addition to licensing, how is copyright documented in this repository? LICENSE.TXT refers to CREDITS.TXT (which isn't present here). The Git history can't be used, since the original LLVM authors won't show up there.
LICENSE.TXT is misleading and should just be removed from this repo.
In Debian we document the situation here: https://salsa.debian.org/rust-team/debcargo-conf/-/blob/master/src/compiler-builtins/debian/copyright
I'm a bit confused about the state of the licences on this repository, and it is preventing some of us (as Arm employees) from contributing to it.
This issue has a long history and a few things have changed since it began, but some problems remain (at least for us):
-
The Cargo.toml licence (MIT/Apache-2.0) disagrees with
LICENSE.TXTand the note at the bottom ofREADME.md(NCSA/MIT). -
LICENSE.TXTpoints toCREDITS.TXTfor copyright information, but this is not present. -
LICENSE.TXTalso seems to be an old copy. For example, it has not tracked copyright date changes in the upstream version. -
Much of the repository was originally derived from LLVM before LLVM relicensed to Apache-2.0. Are there any traces of NCSA/MIT-derived works remaining, or has it all been replaced by "Apache-2.0 WITH LLVM-exception"? @infinity0 suggested removing
LICENSE.TXT(NCSA/MIT) earlier in this thread, and doing so would clear up points 2-4 at least, assuming it's possible to do so. -
The
compiler-rt"Apache-2.0 WITH LLVM-exceptions" licence text isn't included with this repository, as far as I can see. (The licence requires that it is included, as they generally do.) -
"it's OK for the rust parts of the code to have a completely new license (in this case Apache/MIT), since it is a translation ..."
We see the translation as a derived work, which makes this a relicensing problem. My own knowledge of such matters stretches about as far as the well-known licence slide diagram, but the arrows between "Apache-2.0" and "MIT" go the wrong way for this purpose.
-
It's also not clear to me that it's Ok to drop the LLVM exception when relicensing.
- As an aside, the exception might even be useful here, though the rest of
stddoesn't have it.
- As an aside, the exception might even be useful here, though the rest of
No discussion of this nature is complete without an "I am not a lawyer" disclaimer, which is certainly true for me. However, I do need to explain to Arm's lawyers what licence(s) we would be contributing code under, and I have to do due diligence to check that things seem generally in order, and I have to admit that I'm struggling on both points! It would be much easier if it were consistently labelled as something obviously compatible with the source (e.g. "Apache-2.0 WITH LLVM-exceptions"), but I'm aware that doing that retrospectively involves quite a lot of hassle.
I am unfortunately not allowed to contribute patches in this state, but if there's anything else I can do to help unblock this, please let me know.
Also, I feel like people forget about the contributions to this crate. I have not examined this repo enough to verify that no similarities to LLVM code remain, so I'll just assume that's true. However, the README states that "The compiler-builtins crate is dual licensed under both the University of Illinois "BSD-Like" license and the MIT license. As a user of this code you may choose to use it under either license. As a contributor, you agree to allow your code to be used under both.", which implies that all contributors to this crate licensed their contributions under NCSA (and MIT) and not Apache. As such, changing this crates license to MIT or Apache would require their permission.
Nevertheless, all code in this crate is definitely licensed under the MIT license, so we could just drop the "or Apache" part until we figure it out.
Legally it is fine to relicense derivatives to be more restrictive, in fact outside of copyleft that is usually the point. The key aspect is that the original copyright owner does not hold copyright over the derivative.
the arrows between "Apache-2.0" and "MIT" go the wrong way for this purpose.
This is backwards. IANAL but in general my understanding is:
- A derivative work (including a translation) generates a new copyright owner. The copyright owner of the original work does not own copyright in the derivative.
- However, the original copyright owner does exercise control in his license conditions - the derivative work is only legal if the license for the original is adhered to when creating/distributing the derivative.
- There is no obligation by default under law for the derivative copyright holder, to re-license the derivative under the same license as the original. They can choose whatever license they want, as long as they do so adhering to (2). a. With copyleft licenses however, the conditions are that the derivative must re-license under the same license (which forgoes certain other copyright protections in favour of software freedom)
- None of the licenses being discussed in this issue are copyleft licenses. There is no obligation to re-license under the same license. The only obligation for re-licensing is (2). Of course, any more-restrictive conditions only cover the parts of the derivative that are not present in the original. The copyright in the original is still held by the original copyright holder and subject to the more permissive original license.
Re-licensing a derivative work under a more restrictive license, does not break the conditions of most licenses. That is the whole point (and controversy) of copyleft. If it was illegal to relicense (in a derivative work) MIT as Apache then copyleft wouldn't need to exist, and things like https://en.wikipedia.org/wiki/Cedega_(software) would not have happened.
I'm pretty sure that for derivative works, both the author of the original work and the author of derivative work holds copyright over the finished work. In the case of collaborative projects, every contributor holds the copyright to his own contributions. A work can only be used if every copyright holder agrees to it. A contributor only loses copyright when all of his work gets removed or replaced. In the case of this library, I doubt anyone except for a judge can decide if that happened.
I'm pretty sure that for derivative works, both the author of the original work and the author of derivative work holds copyright over the finished work.
Generally, no. The author of the original work only holds copyright over any part of the original work that appears in the finished work. The author of the derivative work only holds copyright over any parts of the derivative work that don't appear in the original work.
Only if it is not possible to separate these two parts in practice, then the situation turns into what you described, but not generally. As I said, if the case was as you described then the whole idea of copyleft would be redundant.
For translation into another language, the whole code is new, and therefore fully under the copyright of the derivative author. However the comments might have been copy-pasted and the original copyright still holds on that. That's how we're dealing with this crate in Debian, anyway. Someone with access to other lawyers are free to get a second opinion.
I've compared some bits of source code of compiler-builtins and compiler-rt. Some are significantly different, but others are near identical. Compare:
https://github.com/rust-lang/compiler-builtins/blob/master/src/x86_64.rs
https://github.com/llvm/llvm-project/blob/2e999b7dd1934a44d38c3a753460f1e5a217e9a5/compiler-rt/lib/builtins/x86_64/chkstk2.S
This is not limited to assembly, either:
https://github.com/rust-lang/compiler-builtins/blob/master/src/float/add.rs
https://github.com/llvm/llvm-project/blob/2e999b7dd1934a44d38c3a753460f1e5a217e9a5/compiler-rt/lib/builtins/fp_add_impl.inc
Thanks for your investigation - the examples you bring up gets into the finicky details of what is considered "identical" sure. It will depend on legal precedent, which I have no clue about. Personally I would find it reasonable to argue your examples are not identical as (1) the asm is wrapped in quotes for use in a rust program and (2) the syntax is slightly different again for use in a rust program. Just because C and rust happen to look similar, does not make the translation "identical"; the same conceptual thing has to be performed for any other language that doesn't look like C, such as python. However this is just my opinion and I have no idea how the law actually treats it. Nor do I care that much, and I don't honestly think the LLVM project is going to do anything to Rust.
I'm not a lawyer, but I'm pretty sure you can't get around copyright law by surrounding the work in question with quotes.
This ultimately doesn't matter all that much, as I'm pretty sure we could take advantage of LLVM relicensing if we wanted to switch to Apache.