Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve the COPYRIGHT file and include mention of rustc_apfloat #96784

Closed
wants to merge 4 commits into from

Conversation

wesleywiser
Copy link
Member

@wesleywiser wesleywiser commented May 6, 2022

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.

The compiler-rt dependency was removed in
7e6c9f3 in favor of a vendored
dependency on rust-lang/compiler-builtins (dual UIUC and MIT licensed).
That vendored dependency was converted to a regular Cargo dependency in
4c21a3b.
Use of libbacktrace was removed in
06d565c where we switched to using the
gimili library instead. Note: the backtrace submodule located at
library/backtrace points to backtrace-rs which removed support for using
libbacktrace in rust-lang/backtrace-rs#423.
The rustc_apfloat crate is a port of LLVM's APFloat code and was
introduced in rust-lang#43554. At that
time, LLVM was licensed under the UIUC license.

Since that time, contributors have made changes to the code without
being advised of the UIUC licensing resulting in the code base being a
mixture of UIUC licensed code and Apache 2/MIT licensed code.

Going forward, the compiler team will be asking contributors to license
their contributions under all of Apache 2/MIT/UIUC licenses so that,
eventually, either we can relicense the crate as simply UIUC licensed or
create a new port that is Apache 2/MIT licensed which can use the
changes contributed on top of the UIUC base.
@rust-highfive
Copy link
Collaborator

r? @Mark-Simulacrum

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

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 6, 2022
@joshtriplett
Copy link
Member

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
Copy link
Member Author

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

on the APFloat library from a version of LLVM licensed under the UIUC
license. Contributions to the rustc_apfloat crate are licensed either
under the standard Rust licensing (Apache License, Version 2.0 or the
MIT license, at your option) or under the Apache License, Version 2.0,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@Mark-Simulacrum Mark-Simulacrum May 19, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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'.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

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.

LLVM has relicensed their codebase. Remove the old UIUC license text
from the LLVM section and include the licensing text used by LLVM
itself.
@wesleywiser
Copy link
Member Author

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.

@Mark-Simulacrum Mark-Simulacrum added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 27, 2022
@pietroalbini pietroalbini added the A-licensing Area: Compiler licensing label Jun 15, 2022
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Oct 2, 2022
…ulacrum,joshtriplett

Improve the COPYRIGHT file

This is a cutdown version of rust-lang#96784 which doesn't include the apfloat changes. At this point, the other 3 commits in this PR don't seem to be controversial and I'd like to go ahead and get those merged which will leave rust-lang#96784 with only the more complex apfloat related change.

r? `@Mark-Simulacrum` since you are the reviewer on that PR

cc `@joshtriplett` since you also had feedback in that PR
@bors
Copy link
Contributor

bors commented Oct 2, 2022

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

@jyn514
Copy link
Member

jyn514 commented Apr 27, 2023

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
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-licensing Area: Compiler licensing S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants