Add repository license.

[ehuss]

This adds a license for the content in this repository.

There are a lot of licenses we could choose from. I am proposing MIT and Apache 2.0 to be consistent with the rest of the Rust project (and they are also popular choices outside of the project). I would like to ensure that content can be easily copied between other places (such as the RFC repo).

Rather than deliberate for a long time on choosing a license, I think it would be good to get something established soon, and then consider relicensing in the future if we desire.

Some other options that I consider:

• CC0 — This is a very permissive license, with no requirements of attribution.
• CC-BY — A relatively permissive license, but still requires attribution.
• Apache 2.0 with the LLVM exception — This is also a popular choice, avoiding the need for a dual license.

Summarizing some comments and concerns:

• There is some discomfort that these licenses aren't ideal for the kind of content that will be in this repo.
  • ehuss: This is understood and agreed. However, the primary motivation for these choices is to stay consistent and compatible with the rest of the rust-lang org, which should reduce friction and confusion. I'm concerned that most people won't follow the necessary process using different licenses.
  • In particular, the use of the phrasing "Software" seems incorrect for a mostly documentation-based repository.
    • ehuss: My understanding is that MIT also mentions "and associated documentation", and in general I understand from a legal standpoint that the license applies to any and all licensable content, not just software. Also, these licenses are used by other organizations for text-only content.
    • ehuss: Also, we may end up having some software in this repo if we decide to create tooling here.
• There are concerns about the relicensing process, since it requires tracking down all contributors. There are mixed opinions about how difficult that is. There is some desire to choose the correct license up front, rather than choosing something that is sub-optimal, and going through relicensing later.
• There isn't a clear process for contributors to assign or release their copyright (especially when the repo has no license), since there isn't a legal entity to assign that to (other than possibly the Foundation).
• There were concerns about the MIT license having the phrase "The above copyright notice", but the copyright notice has been removed. It was removed because there isn't a legal entity to hold the copyright. However, we would prefer to avoid modifying the text of the MIT license (because then it becomes a different, nonstandard license). This is how the rust-lang/rust repository works, and the primary motivation is to stay consistent with the rest of the rust-lang org. There is more discussion at https://github.com/rust-lang/rust/commit/2a8807e889a43c6b89eb6f2736907afa87ae592f#commitcomment-28375512 about why this was done, and the expected legality of it.
  • ehuss: This might be something that we should investigate later as a project-wide concern to clarify.

[ehuss]

I'm going to try rfcbot to get everyone's approval (so I don't need to manually make a list), and also to test if it is working. I think this should have unanimous consent, which rfcbot doesn't really support, but is good enough for generating a checklist.

@rfcbot fcp merge

[rfcbot]

Team member @ehuss has proposed to merge this. The next step is review by the rest of the tagged team members:

• [x] @Mark-Simulacrum
• [x] @carols10cents
• [x] @eholk
• [x] @ehuss
• [x] @jackh726
• [x] @jonathanpallant
• [x] @khionu
• [x] @m-ou-se
• [x] @rylev

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[thejpster]

Relicensing is only possible with the permission of the copyright holder. So we would also have to say something about contributions assigning copyright to the Rust Leadership Council so they have the rights to do that.

I would have gone for a Creative Commons myself as this is prose rather than code. Probably a with Source Attribution variant. But I take your point about compatibility with other repos. I'll need to think on it.

[Mark-Simulacrum]

Historically relicensing when wanted hasn't been too much hassle, especially for lower traffic repositories like this - we can track down contributors and ask permission if needed, without assigning copyright (which we've never done as a project afaik).

[m-ou-se]

So we would also have to say something about contributions assigning copyright to the Rust Leadership Council so they have the rights to do that.

I don't think that's possible, because the council is not a legal entity.

[m-ou-se]

I think this should have unanimous consent, which rfcbot doesn't really support, but is good enough for generating a checklist.

@ehuss I think you can use rfcbot poll to get a checklist without the FCP logic.

[thejpster]

we can track down contributors and ask permission if needed

That sounds really difficult, to be honest, and if someone leaves the project on bad terms they can just say no.

Let's try and get it right first time.

[ehuss]

@thejpster Is there a specific license you would like to use? Do you know if it would be compatible with copying content to other places that use MIT/Apache (such as the rest of the rust-lang org)?

(Just a note: we are adding content now without a license, so we need to get everyone's approval who has contributed to relicense to whatever we pick. Waiting to merge something is about the same as merging this now and relicensing later.)

[thejpster]

Probably CC-BY.

1. You must give appropriate credit and indicate if changes were made.
2. You may not prevent anyone from doing something the licence otherwise permits.

I'm paraphrasing as I'm on my phone, but that seems compatible with e.g. copying into the RFC repo. You'd just say:

"This was written by the Rust Leadership Council as CC BY 2.0 and then modified for use here"

The MIT just feels wrong because it's expressly about software.

[ehuss]

I would be concerned that retaining the CC-BY text usually won't happen. For example, let's say we draft an RFC here, and then copy it to the RFC repo, we then need to ensure that the correct license is retained in the document. I suspect people won't do that, especially in the longer future (and with transfers to other repos, like the forge). I'm also not confident about how sites like the forge or rfcs should then express their licensing terms if it contains a mix of licensed content.

The MIT license does apply to documentation and text as well. Although it uses the word "Software", that typically applies to all files in a repository.

I also think it is possible we will have software here. For example, for tooling we might want to add, we would then need to figure out licensing on that tooling each time we add it.

I agree MIT/Apache might not be the best license to use if we are working in isolation, and we don't want to ever include software here, but I think to reduce friction with integration with the rest of the rust-lang org, it fits well with that goal, and is also convenient for adding software.

If it is any consolation, I have seen other orgs use Apache for documentation-only projects.

[jonathanpallant]

OK, I gave my tick. If it's good enough for rust-lang/rust it's good enough for us.

[rfcbot]

:bell: This is now entering its final comment period, as per the review above. :bell:

[eholk]

Ugh, I meant to reply to this last week and had other things come up. I went ahead and checked my box because I'm happy with either MIT/Apache2 or one of the Creative Commons licenses.

I was a little hesitant because I didn't feel like I had a strong reason to pick one or the other and that's a situation that always makes me uncomfortable.

I think the advantage of MIT/Apache2 is primarily that it's culturally what we are already using across a lot of Rust projects and repos. That said, I share @jonathanpallant's feeling that it's kind of weird (though not unprecedented) to use a software license for what's primarily not software.

I proposed CC0 because it's essentially an international version of public domain. I was coming at that from the direction of asking what rights we'd want to retain to the things we create here? I don't think much of the documentation we create particularly needs to have any kind of copyright protection on it, but I could easily believe there are scenarios I'm not seeing.

I think @ehuss has a good point that we are likely to have some small tooling software in here at some point, and if we ever want to import code that will be easier if we use the same license most Rust code is already using. I suppose we could do something like "unless otherwise noted, everything is under a Creative Commons license" and then add exceptions for the directories that have code, but that seems overly complex.

[ehuss]

Thanks everyone for the comments! It is appreciated, and also highlights some things we may need to later investigate for the project as a whole (such as copyright assignment). I realize this is not the first choice for everyone, and I agree those alternates are also attractive choices, though I hope I clarified the reasoning I had. I put a summary up on the top comment of some of the things brought up.

@rylev (or anyone), now that all boxes are checked, can you approve and merge?