RFC to put the RFCs repo under license terms

text/0000-license-rfcs.md

@@ -0,0 +1,162 @@
+<!---
+Copyright 2017 The Rust Project Developers. See the COPYRIGHT
+file at the top-level directory of this distribution.
+
+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. This file may not be copied, modified, or distributed
+except according to those terms.
+-->
+
+- Feature Name: license_rfcs
+- Start Date: 2017-06-26
+- RFC PR: (leave this empty)
+- Rust Issue: (leave this empty)
+
+# Summary
+[summary]: #summary
+
+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.
+
+# Disclaimer
+[disclaimer]: #disclaimer
+
+This RFC is not authored by a lawyer, so its reasoning may be wrong.
+
+# Motivation
+[motivation]: #motivation
+
+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](https://creativecommons.org/licenses/by/4.0/)
+
+[Github ToS]: https://help.github.com/articles/github-terms-of-service/#5-license-grant-to-other-users
+
+# Detailed design
+[design]: #detailed-design
+
+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].
+
+This puts a responsibility on anyone who is merging RFCs to check for a
+license header.
+
+`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.
+
+To signify the terms, each RFC document shall start with a comment header like:
+
+```
+<!---
+Copyright <year> The Rust Project Developers. See the COPYRIGHT
+file at the top-level directory of this distribution.
+
+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. This file may not be copied, modified, or distributed
+except according to those terms.
+-->
+```
+
+All new RFCs, including the ones in the queue as of when this RFC gets merged,
+should start with such a section, and the RFC template should be changed
+accordingly.
+
+As more contributors sign off on the opened issue, sections may be added
+to existing RFCs which have only contributors that have signed off.
+
+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.
+
+[considered for merging]: https://github.com/rust-lang/rfcs/pulls
+
+# How We Teach This
+[how-we-teach-this]: #how-we-teach-this
+
+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 and the header in the template should should inform new
+PR authors of the terms they put their contribution under.
+
+# Drawbacks
+[drawbacks]: #drawbacks
+
+This is additional churn and pings a bunch of people, which they may not like.
+
+# Alternatives
+[alternatives]: #alternatives
+
+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](https://github.com/apple/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.
+
+# Links to previous discussion
+
+* https://github.com/rust-lang/rfcs/issues/1259
+* https://github.com/rust-lang/rust/issues/25664
+* https://internals.rust-lang.org/t/license-the-rfcs-repo-under-the-cc-by-4-0-license/3870
+
+# Unresolved questions
+[unresolved]: #unresolved-questions
+
+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.