HackMDLicensing Meeting 2022-09-29
Meeting Notes
- we want there to be as few barriers as possible for contributions ((?) especially from paid contributors (?))
- our source code licensing situation is a bit of a mess
- we want our licensing situation to be as simple as possible, for the benefit of our contributors
- ideally, we'd like to aim for MIT/Apache 2.0 dual-licensed across the board
- but that is not realistic as an immediate short-term goal. (Potentially never able to reach it?)
- so: can we figure out what is blocking us from that in specific cases, and then figure out what to do in each such case
- Also: if we want to allow people to build and distribute their own binaries, don't we need a Licensing exception for the standard library?
- If we need to start asking contributors to libstd to make such an exception as part of their contributions, we need to address that ASAP.
- Q: Is such a Licensing exception necessary today, for someone who e.g. just builds hello-world atop libstd alone and ships it to their users.
- We probably need to talk to T-libs and maybe T-release about this.
- re triviality
- if we got a positive answer from legal, would that resolve a bunch of issues? (probably not)
- if we decided to attack problems by removing the code, what suffices?
- E.g. is it enough to just remove the code, even if remnants of it remain in the git history?
- Likewise, if we do remove the code, what kind of "clean room" effort would suffice to allow someone to reimplement the old thing?
- Do we have a contributor agreement? No.
- Felix: should we be adding a checkbox to the pull requests asserting that there was no improperly licensed content included in the PR? (Where was this previously discussed…)?
- Wesley: Well, what would that get us? And what are the stakes about fixing a violation after it is discovered? I.e. we can imagine pushback, especially from compiler code reviewers, saying they are not comfortable making that sort of assertion about a random contributor's code?
- Joel: If we were to take the approach of trashing the improperly-licensed code, how much engineering resources would it take to replace the things that were thrown away?
- Wesley: hard to say. We might manage to get some new volunteers engaged around the idea of contributing some small labor on replacing some small parts of the source code. But that might entirely fall flat, and we would have to fall back on paying someone to do it.
- unicode stuff
- felix wants to do more digging before we talk to a lawyer about this
- wesley notes that this is another instance of the stdlib incorporating 3rd party code; if we wanted to add a runtime-exception for the stdlib, that would have to be propogated backward
- wesley in any case, the problem with unicode-ident seems like a consequence of our need to check the licenses of things we pull into stdlib to ensure they are all MIT/Apache 2.0.
- re compiler-builtins, what is the right path forward?
- what are the right questions to ask the lawyer?
- what are minimal set of changes necessary to placate the ARM employee concerned about it?
- wesley: this seems very much analogous to the apfloat situation.
Action Items
- Felix will follow up on leadership chat about the stdlib licensing exception question
- Felix will look into unicode-xid to unicode-ident change, and what the implications of that are.
compiler-builtins
- References:
- https://github.com/rust-lang/compiler-builtins/issues/307#issuecomment-1211820833
- Inherent inconsistency: Cargo.toml license disagrees with LICENSE.TXT and README.md
- Inherent inconsistency: LICENSE.TXT points to non-existent CREDITS.TXT
- Red flag: LICENSE.TXT has not tracked copyright date changes in upstream copy (pnkfelix: is that "fine" if upstream work has not been otherwise incorporated?)
- Question for Felix+Wesley: repo originally derived from LLVM before latter relicensed to Apache-2.0. Do traces of NCSA/MIT-derived works remain?
- compiler-rt "Apache-2.0 WITH LLVM-exceptions" license text isn't included in compiler-builtins repository
- Question for Joel: Are (programming language) translations not subject to copyright (which is the claim made, according to infinity0, by the Debian copyright reviewers?)
- and, if that is true, removing the comments would suffice to enable relicensing.
- if we are relicensing the existing code as a translation, can we then drop the LLVM exception as part of that?
unicode-ident license
unicode-ident has Unicode-DFS-2016 as license due to the underlying unicode tables are licensed this way afaik. unicode-xid uses the same unicode tables afaik, so it should actually include it in the license identifier too.
libcore is probably also supposed to have this license
(presumably meaning "Unicode-DFS-2016", and presumably including libstd too? We don't current have distinct license text for library/ vs rest of rust-lang/rust)
Q: What do we need to do here?
trivality threshold?
https://github.com/rust-lang/compiler-builtins/issues/319
We have for years been wrestling about what to do w.r.t. some code that was contributed that explicitly attributed itself as being sourced from libgcc
See specifically: https://github.com/rust-lang/compiler-builtins/issues/319#issuecomment-903175560
- Q: Can we close this?
- If so, should we first replace the comment referencing libgcc with one that references this issue, to avoid future scans of the source replaying this whole argument? Or are we better off leaving the link to libgcc in place, and just add a comment pointing to this issue and/or explaining why the presence of this code is justifiable?
apfloat
Wesley has an open PR to attempt to clarify the situation with the rustc_apfloat crate in the COPYRIGHT file.
Backstory: https://github.com/rust-lang/rust/tree/master/compiler/rustc_apfloat is a Rust port of some old LLVM code from a time when LLVM was UIUC licensed. Licensing of this crate has been an ongoing problem (see https://github.com/rust-lang/rust/issues/63232#issuecomment-533191802). Our current understanding, from talking to Bec & legal, is that the port should be UIUC licensed but subsequent contributions were likely made by contributors under the assumption they were licensed via the overall Apache2/MIT licensing. Thus the current source is a combination of UIUC derived code and Apache2/MIT modifications to it.
The change in question is https://github.com/rust-lang/rust/pull/96784/commits/2d2fe77ecddb9a734fe6905cdb3328dbabec656d
Discussion is currently blocked on understanding what the most important thing to users is:
- an accurate, but neccesarily detailed, explanation of the licensing history of the source
- a more simplistic statement that the code is licensed under some combination of UIUC/Apache 2/MIT
Our current plan going forward wrt rustc_apfloat is to ask contributors explicitly to license their contributions under all of UIUC/Apache 2/MIT in the hope that one day we can relicense to just Apache 2/MIT or just UIUC if that is the most pragmatic.
Copyright Attribution
A discussion from a few years ago suggested that we might explicitly allow (encourage?) commit authors to explicitly indicate that they themselves do not hold sole copyright to the work they are contributing. Something along the lines of: "I grant XYZ Corp all rights to relicense the changes made in this commit"
Is 0BSD more strictly more permissive than MIT?
Q: Can we freely incorporate 0BSD work into the project without having to expand our licensing checking?
See discussions from 2020 and from 2022
