core (meta)
Introduce a move to dual-MIT/Apache2 licensing terms to the Rust RFCs repo, by requiring them for all new contributions, and asking previous contributors to agree on the new license.
This RFC is not authored by a lawyer, so its reasoning may be wrong.
Currently, the Rust RFCs repo is in a state where no clear open source license is specified.
The current legal base of the the RFCs repo is the "License Grant to Other
Users" from the Github ToS*:
Any Content you post publicly, including issues, comments, and contributions to other Users' repositories, may be viewed by others. By setting your repositories to be viewed publicly, you agree to allow others to view and "fork" your repositories (this means that others may make their own copies of your Content in repositories they control).
If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to access your Content through the GitHub Service, and to use, display and perform your Content, and to reproduce your Content solely on GitHub as permitted through GitHub's functionality.
These terms may be sufficient for display of the rfcs repository on Github, but it limits contributions and use, and even poses a risk.
The Github ToS grant only applies towards reproductions through the Github Service. Hypothetically, if the Github Service ceases at some point in the future, without a legal successor offering a replacement service, the RFCs may not be redistributed any more.
Second, there are companies which have set up policies that limit their employees to contribute to the RFCs repo in this current state.
Third, there is the possibility that Rust may undergo standardisation and produce a normative document describing the language. Possibly, the authors of such a document may want to include text from RFCs.
Fourth, the spirit of the Rust project is to be open source, and the current terms don't fulfill any popular open source definition.
*: The Github ToS is licensed under the Creative Commons Attribution license
After this RFC has been merged, all new RFCs will be required to be dual-licensed under the MIT/Apache2. This includes RFCs currently being considered for merging.
README.md should include a note that all contributions to the repo should be
licensed under the new terms.
As the licensing requires consent from the RFC creators, an issue will be created on rust-lang/rfcs with a list of past contributors to the repo, asking every contributor to agree to their contributions to be licensed under those terms.
Regarding non-RFC files in this repo, the intention is to get them licensed as well, not just the RFCs themselves. Therefore, contributors should be asked to license all their contributions to this repo, not just to the RFC files, and all new contributions to this repo should be required to be licensed under the new terms.
The issue created should @-mention all Github users who have contributed, generating a notification for each past contributor.
Also, after this RFC got merged, all RFCs in the queue will get a comment in their Github PR and be asked to include the copyright section at the top of their RFC file.
The note in README.md should should inform new PR authors of the terms they put their contribution under.
This is additional churn and pings a bunch of people, which they may not like.
Other licenses more suited for text may have been chosen, like the CC-BY license. However, RFCs regularly include code snippets, which may be used in the rust-lang/rust, and similarly, RFCs may want to include code snippets from rust-lang/rust. It might be the case that the CC-BY license allows such sharing, but it might also mean complications.
Also, the swift-evolution repository is put under the Apache license as well.
Maybe for something like this, no RFC is needed. However, there exists precedent on non technical RFCs with RFC 1636. Also, this issue has been known for years and no action has been done on this yet. If this RFC gets closed as too trivial or offtopic, and the issue is being acted upon, its author considers it a successful endeavor.
Should trivial contributions that don't fall under copyright be special cased? This is probably best decided on a case by case basis, and only after a contributor has been unresponsive or has disagreed with the new licensing terms.