Improve the COPYRIGHT file and include mention of rustc_apfloat

[wesleywiser]

There are four changes with this PR and for ease of reviewing, I've put each in a separate commit. I would suggest reviewing the PR commit by commit as the overall diff isn't great.

The changes in this PR are:

1. Remove the compiler-rt section as we no longer vendor LLVM's compiler runtime library. The compiler runtime library is now brought in just like any other crate we use.
2. Remove the libbacktrace section as we don't use it at all anymore.
3. Include a reference to the rustc_apfloat crate. The licensing situation for this crate is currently rather complex as the original code is UIUC licensed but subsequent changes to it were likely contributed under the standard Rust licensing.
4. Update the LLVM section. LLVM is working to complete their relicense to Apache 2 with LLVM Exception. I've included a copy of their current licensing information in their section.

I think this is a reasonable improvement over the current content of the COPYRIGHT file but there are obviously still further changes that could be made.

Related to #55993 and #63232.

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[joshtriplett]

I think this is a substantial improvement; thank you!

However, I don't think we should just link to LLVM's license. One of the points of having the COPYRIGHT file up to date is to allow people to copy that file and use it to fully fulfill their license obligations. To do that, we do need to include full license texts.

[wesleywiser]

That's a good point, thanks for the feedback! I'll update this PR when I'm back from PTO next week.

[Mark-Simulacrum]

I think this is not quite right -- Rust's standard licensing requires that contributions are licensed under both Apache and MIT, not one of them at the contributor's option, right? Otherwise users cannot choose one or the other, if there's code under just one of them, presumably?

(But maybe I have misunderstood).

[wesleywiser]

So, I copied the wording from the top of this file:

rust/COPYRIGHT

Lines 16 to 19 in c067287

	Except as otherwise noted (below and/or in individual files), Rust is
	licensed under the Apache License, Version 2.0 <LICENSE-APACHE> or
	<http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
	<LICENSE-MIT> or <http://opensource.org/licenses/MIT>, at your option.

I believe the wording here is correct as we want contributions to rustc_apfloat to be contributed under all of Apache, MIT, UIUC and to then allow the user to decide what license they will comply with.

[Mark-Simulacrum]

I think the problem is the "Contributions to the" prefix -- that is, the code is licensed under (Apache 2.0 or MIT or UIUC), that's correct, but contributions must be licensed under that full set of licenses -- contributors can't choose to only license their changes under MIT, for example.

[wesleywiser]

Agreed! I'm just struggling to see what other word would be appropriate here. The issue is that I'm specifically trying to make a distinction between the initial port and subsequent changes to that code. I can say "Subsequent changes to the library ..." but to my mind that means the same thing so it doesn't solve the issue.

I'm interpreting "you" in this document to be a downstream user of Rust, not a contributor. As such, "at your option" is referring to options the user has not options a contributor has. Perhaps that's not the correct interpretation?

[Mark-Simulacrum]

Yeah. I think it makes sense from you = user perspective, but then it's not entirely clear to me what users are expected to do with the 'based on' language. It also seems like we're needlessly(?) repeating ourselves -- MIT and Apache 2.0 are both listed twice and seemingly under the same "or" grouping from user's perspective, right?

Maybe we can change to something like:

The rustc_apfloat crate, located in compiler/rustc_apfloat, is based on the APFloat library from a version of LLVM licensed under the UIUC license. Subsequent contributions to the rustc_apfloat crate are licensed under the Apache License, Version 2.0, the MIT license, or the UIUC license, at your option.

I think the subsequent to me helps a little, as does the simplification away from having repeated licenses -- it makes the sentence structure simpler and overall gets the same message across, I believe.

I think the takeaway here is probably that it's probably worth doing some work on providing a "contributor copyright" file of some kind that basically requests licensing from contributors under some set of licenses. If possible, I think ideally we'd structure things so that we could omit UIUC from the list here, so that the story for contributors to current rust-lang/rust would be consistently "license all changes under both Apache 2.0 and MIT (each separately)", which seems better than having some folders also require other licenses to be 'granted'.

[wesleywiser]

I think the subsequent to me helps a little, as does the simplification away from having repeated licenses -- it makes the sentence structure simpler and overall gets the same message across, I believe.

Agreed, it is much simpler! I believe the problem though is that until now, we've not asked that changes to this code be triple licensed and the advice Felix and I were given said this likely means those contributions were done under the normal Rust license (ie, only MIT/Apache2 only). Going forward, we're going to require contributors to rustc_apfloat to triple license under MIT/Apache2/UIUC but that still leaves the contributions which have already been made. As such, I don't think saying "Subsequent contributions to the rustc_apfloat crate are licensed under the Apache License, Version 2.0, the MIT license, or the UIUC license, at your option." is entirely correct.

We could certainly try to go back and get permission from contributors to license their code this way and that would simplify things here. I didn't want to block these improvements on that happening and it's possible we may not get every contributor to sign off on that.

Per your other comment, I'm very much in agreement we should verify the specific changes with the Foundation but I'd like for us to decide what the changes should look prior to engaging with their lawyers again.

Looking to the future, I see two potential paths to simplify our licensing here:

1. If we can secure relicensing consent from past contributors, we could simplify the licensing here to simply say "The rustc_apfloat crate is licensed under the UIUC license". That isn't ideal as it still deviates from our standard licensing but at least it is easy to explain and understand.

2. We can perform a clean-room re-implementation of the rustc_apfloat crate based only on the type & function signatures of the current code. The code is quite self-contained and these should be quite feasible but Felix and I are not aware of anyone interested in taking this on. We'd also require some additional collaboration with the RF to make sure the re-implementation is done correctly and in a well documented way so there is no question as to the provenance of the code.

[Mark-Simulacrum]

Yeah, seems like a complex situation. I agree on the right process here before re-engaging, let's decide on what would make us happy and work to get it approved.

I think what may be helpful - perhaps something worth asking - is the extent to which documenting history here is important. My relatively uninformed assumption is that ultimately consumers of the source code here probably can't do anything useful with even the simplified version I suggested - maybe the approach we should take is to have roughly these sentences:

• Based on UIUC code from LLVM.
• Initial changes made under Apache or MIT (as standard for other parts of the Rust distribution).
• Since YYYY-mm-dd, changes are trilicensed under Apache or MIT or UIUC.

But it's not entirely obvious to me that this is worthwhile - presumably to a consumer they'd only care about what they need to do when modifying/using/redistributing the code, so maybe we can try to approach things from that angle, though I don't really know what that would mean. If we can't get to a point where the code is available under just Apache 2.0 or MIT terms (and potentially other terms, but those are our standard), then it seems like we should probably make a best effort to get this language (perhaps in the terms I suggest, with explicit dates or commit SHAs) and then suggest reimplementing or so.

[Mark-Simulacrum]

However, I don't think we should just link to LLVM's license. One of the points of having the COPYRIGHT file up to date is to allow people to copy that file and use it to fully fulfill their license obligations. To do that, we do need to include full license texts.

This probably is right, though I'll note we have ~100s of dependencies with licenses that we don't currently list in the COPYRIGHT file (many of them largely duplicates, but I don't know whether that's sufficient to be OK). It likely makes sense to include the LLVM license here in full regardless, since it's not a crates.io crate and so wouldn't get picked up if we do end up with automated inclusion of upstream licenses eventually (as seems not unlikely).

@wesleywiser -- I recall an email thread with the Foundation I was cc'd on, did we run these specific changes past the Foundation yet? I think given the relative rarity of making changes here it makes sense to get at least a brief sign-off on the diff.

[wesleywiser]

Thanks for the feedback @joshtriplett and @Mark-Simulacrum! I've updated the LLVM section to include a copy of the licensing text they provide directly.

[bors]

☔ The latest upstream changes (presumably #102558) made this pull request unmergeable. Please resolve the merge conflicts.

[jyn514]

It's been a while - what's the status of this PR? I'd love to get more clarify on rustc_apfloat so I can stop having to tell people not to touch it 😅

It sounds like you wanted to hear back from a lawyer through the Foundation - did that ever happen?

[wesleywiser]

It sounds like you wanted to hear back from a lawyer through the Foundation - did that ever happen?

Yes, they were helpful in understanding our options for digging ourselves back out of the licensing situation! Closing this in favor of #113843 which solves the licensing issue.