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

RFC to put the RFCs repo under license terms #2044

Merged
merged 2 commits into from
Jul 24, 2017
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
162 changes: 162 additions & 0 deletions text/2044-license-rfcs.md
Original file line number Diff line number Diff line change
@@ -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: https://github.com/rust-lang/rfcs/pull/2044
- Rust Issue: https://github.com/rust-lang/rust/issues/43461

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