Skip to content

Commit 1c07d02

Browse files
aturonaturon
authored
Merge pull request #2044 from est31/master
RFC to put the RFCs repo under license terms
2 parents a099f17 + 87d23d3 commit 1c07d02

File tree

1 file changed

+162
-0
lines changed

1 file changed

+162
-0
lines changed

‎text/2044-license-rfcs.md

+162
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,162 @@
1+
<!---
2+
Copyright 2017 The Rust Project Developers. See the COPYRIGHT
3+
file at the top-level directory of this distribution.
4+
5+
Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
6+
http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
7+
<LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
8+
option. This file may not be copied, modified, or distributed
9+
except according to those terms.
10+
-->
11+
12+
- Feature Name: license_rfcs
13+
- Start Date: 2017-06-26
14+
- RFC PR: https://github.com/rust-lang/rfcs/pull/2044
15+
- Rust Issue: https://github.com/rust-lang/rust/issues/43461
16+
17+
# Summary
18+
[summary]: #summary
19+
20+
Introduce a move to dual-MIT/Apache2 licensing terms to the Rust RFCs repo, by
21+
requiring them for all new contributions, and asking previous contributors to
22+
agree on the new license.
23+
24+
# Disclaimer
25+
[disclaimer]: #disclaimer
26+
27+
This RFC is not authored by a lawyer, so its reasoning may be wrong.
28+
29+
# Motivation
30+
[motivation]: #motivation
31+
32+
Currently, the Rust RFCs repo is in a state where no clear open source license
33+
is specified.
34+
35+
The current legal base of the the RFCs repo is the "License Grant to Other
36+
Users" from the [Github ToS]`*`:
37+
38+
```
39+
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).
40+
41+
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.
42+
```
43+
44+
These terms may be sufficient for display of the rfcs repository on Github, but
45+
it limits contributions and use, and even poses a risk.
46+
47+
The Github ToS grant only applies towards reproductions through the Github
48+
Service. Hypothetically, if the Github Service ceases at some point in the
49+
future, without a legal successor offering a replacement service, the RFCs may
50+
not be redistributed any more.
51+
52+
Second, there are companies which have set up policies that limit their
53+
employees to contribute to the RFCs repo in this current state.
54+
55+
Third, there is the possibility that Rust may undergo standardisation and
56+
produce a normative document describing the language.
57+
Possibly, the authors of such a document may want to include text from RFCs.
58+
59+
Fourth, the spirit of the Rust project is to be open source, and the current
60+
terms don't fulfill any popular open source definition.
61+
62+
`*`: The Github ToS is licensed under the [Creative Commons Attribution license](https://creativecommons.org/licenses/by/4.0/)
63+
64+
[Github ToS]: https://help.github.com/articles/github-terms-of-service/#5-license-grant-to-other-users
65+
66+
# Detailed design
67+
[design]: #detailed-design
68+
69+
After this RFC has been merged, all new RFCs will be required to be
70+
dual-licensed under the MIT/Apache2. This includes RFCs currently being
71+
[considered for merging].
72+
73+
This puts a responsibility on anyone who is merging RFCs to check for a
74+
license header.
75+
76+
`README.md` should include a note that all contributions to the repo should be
77+
licensed under the new terms.
78+
79+
As the licensing requires consent from the RFC creators, an issue will be
80+
created on rust-lang/rfcs with a list of past contributors to the repo,
81+
asking every contributor to agree to their contributions to be licensed under
82+
those terms.
83+
84+
To signify the terms, each RFC document shall start with a comment header like:
85+
86+
```
87+
<!---
88+
Copyright <year> The Rust Project Developers. See the COPYRIGHT
89+
file at the top-level directory of this distribution.
90+
91+
Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
92+
http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
93+
<LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
94+
option. This file may not be copied, modified, or distributed
95+
except according to those terms.
96+
-->
97+
```
98+
99+
All new RFCs, including the ones in the queue as of when this RFC gets merged,
100+
should start with such a section, and the RFC template should be changed
101+
accordingly.
102+
103+
As more contributors sign off on the opened issue, sections may be added
104+
to existing RFCs which have only contributors that have signed off.
105+
106+
Regarding non-RFC files in this repo, the intention is to get them licensed
107+
as well, not just the RFCs themselves. Therefore, contributors should be asked
108+
to license *all* their contributions to this repo, not just to the RFC files,
109+
and *all* new contributions to this repo should be required to be licensed
110+
under the new terms.
111+
112+
[considered for merging]: https://github.com/rust-lang/rfcs/pulls
113+
114+
# How We Teach This
115+
[how-we-teach-this]: #how-we-teach-this
116+
117+
The issue created should @-mention all Github users who have contributed,
118+
generating a notification for each past contributor.
119+
120+
Also, after this RFC got merged, all RFCs in the queue will get a comment in
121+
their Github PR and be asked to include the copyright section at the top of
122+
their RFC file.
123+
124+
The note in README.md and the header in the template should should inform new
125+
PR authors of the terms they put their contribution under.
126+
127+
# Drawbacks
128+
[drawbacks]: #drawbacks
129+
130+
This is additional churn and pings a bunch of people, which they may not like.
131+
132+
# Alternatives
133+
[alternatives]: #alternatives
134+
135+
Other licenses more suited for text may have been chosen, like the CC-BY
136+
license. However, RFCs regularly include code snippets, which may be used in
137+
the rust-lang/rust, and similarly, RFCs may want to include code snippets from
138+
rust-lang/rust. It might be the case that the CC-BY license allows such
139+
sharing, but it might also mean complications.
140+
141+
Also, the [swift-evolution](https://github.com/apple/swift-evolution)
142+
repository is put under the Apache license as well.
143+
144+
Maybe for something like this, no RFC is needed. However, there exists
145+
precedent on non technical RFCs with RFC 1636. Also, this issue has been known
146+
for years and no action has been done on this yet. If this RFC gets closed as
147+
too trivial or offtopic, and the issue is being acted upon, its author
148+
considers it a successful endeavor.
149+
150+
# Links to previous discussion
151+
152+
* https://github.com/rust-lang/rfcs/issues/1259
153+
* https://github.com/rust-lang/rust/issues/25664
154+
* https://internals.rust-lang.org/t/license-the-rfcs-repo-under-the-cc-by-4-0-license/3870
155+
156+
# Unresolved questions
157+
[unresolved]: #unresolved-questions
158+
159+
Should trivial contributions that don't fall under copyright be special cased?
160+
This is probably best decided on a case by case basis, and only after a
161+
contributor has been unresponsive or has disagreed with the new licensing
162+
terms.

0 commit comments

Comments
 (0)