License the RFCs repo under the CC-BY 4.0 license

internals policy
#1

The issue being that currently, there is no license.

I have already done the work, I just need to open the PR. Any concerns?

It would be similar to this thread:

https://github.com/retep998/winapi-rs/issues/308

The COPYRIGHT would read:

EDITED (MIT/Apache)

Short version for non-lawyers:

All Rust RFCs are dual-licensed under Apache 2.0 and MIT terms, as documentation.

Longer version:

Rust RFCs, as well as supporting documentation, are copyrighted by their respective authors, and are 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. All Rust RFCs and supporting documentation carrying such notice may not be copied, modified, or distributed except according to those terms.

NOTE: This may be a reason to assign copyright? Or to have a Rust RFC writers? It seems a different group from the Rust Project developers, since, in this case, each RFC is a single thing, instead of being a part of a whole.

1 Like
#2

First concern: Although I agree with the CC-BY license, perhaps Mozilla should own the RFCs, in order to “hold” ownership for the Standard Rust Foundation (or whatever we call it), similar to https://isocpp.org/about.

Perhaps the COPYRIGHT file should read something like (ping Mozilla lawyers):

All files in this repository are owned by the Mozilla Foundation, and are
licensed under the Creative Commons Attribution 4.0 International license,
included in this repository as "LICENSE".
#3

Thanks @ubsan.

The issue here is that the repo does not declare a license.

@ubsan can you please describe in detail the process you envision for doing the license change? Why CC-BY 4.0? e.g. CC-BY-SA would also be a good choice.

#4

@brson It seems more in line with the rest of the Rust ecosystem, as the rest of the Rust ecosystem is MIT.

#5

Thanks again for the clarification @ubsan.

Before we go forward with this I would like to explicitly lay out the plan. This is an important matter, and it’s important that it be communicated clearly.

Here are some of the things that I expect, and the issues that need to be managed.

  • The message to contributors should be clear and detailed, explaining what is happening, why it is happening, what license is being chosen, what that license means in lay terms and why that license is being chosen.
  • It should contain precise instructions to contributors for how they should indicate their assent to the license change. For example, if the process is going to involve commenting on a PR, it should say so, and it should provide the exact text they should paste into the thread so that there is no ambiguity. An example might be “I agree to license all my prior contributions to the rust-lang/rfcs repository under the terms of the CC-BY-4.0 license.”
  • How will we deal with the outstanding PRs and the PRs that arrive between the time that we begin the relicensing process and complete it? We can’t assume that all existing PRs agree to the new terms. This is particularly tricky with the RFCs repo because there are so many in flight. We cannot simply get permission for past contributions, update the license then assume all authors of existing PRs agree to the new license. Offhand I am not sure the best way to deal with this, but there must be a clear sequence of events that ensures that all contributors have assented to the license terms, and it needs to be spelled out ahead of time.
  • If the relicensing process involves commenting on PRs then we must be concerned with the mutability and impermanence of GitHub comments. An author can seemingly retract their consent by deleting their comment. How will we mitigate this risk?
  • Not all contributors will agree to new terms. How will we handle these cases?

I’m happy to offer suggestions on how to deal with any of these issues, and find people who can lend an expert opinion, but I have not thought deeply about them just yet.

Please describe in detail the process here, and write, in this thread, the text of any communication you will send so that others can review.

Here are some links related to previous relicensing efforts that you can reference, though there may be aspects that we can or should do differently:

4 Likes
#6

Enforcing that would require some kind of copyright assignment agreement that contributors have to agree to, which would make contribution much harder (especially for folks in corporate environments, who would have to run it by their legal departments). In many jurisdictions, you can’t assign copyright without an explicit legal agreement; implicitly doing it by sending a patch doesn’t suffice. That also seems inconsistent with Rust itself, and the rest of the Rust ecosystem, none of which require copyright assignment or a CLA.

#7

Is there a strong reason to use a CC license, rather than using dual MIT/Apache 2.0 like the rest of the Rust ecosystem?

Documentation should use the same licenses as code, to allow freely copying it into and out of code without any extra complication. The author of an RFC might want to copy some production Rust code into the RFC to use as an example. And conversely, the author of Rust code may want to copy code or documentation from an RFC into their code.

I would advocate licensing the RFC repository under MIT/Apache 2.0, just like Rust itself.

Also, a couple of minor nits in the proposed COPYRIGHT wording: “respective writers” should be “respective writers and contributors” (since some RFCs incorporate contributions by others), and “owned by” should say “copyrighted by” or similar. And “All RFCs in this repository” wouldn’t apply to anything in the repository other than RFCs (such as the top-level documentation).

#8

IANAL, but the MIT license is as follows:

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: …

The RFCs not being software, it seems incorrect to license them as such.

One may argue that they are “associated documentation files”, but I don’t agree with that. They are written not as documentation but as prescriptive specification.

#9

The RFCs aren’t like the rest of the Rust ecosystem. Unlike the rest of the Rust ecosystem, the RFCs (mostly) aren’t a part of rustc. They’re a part of Rust itself, and will be taken up by the eventual specification and standardization processes.

#10

I’ve seen all sorts of things licensed under the MIT license, including specifications, standalone documentation, configuration files, images, audio, and arbitrary data files. Many software licenses mention “software”, but people regularly apply them to an arbitrary collection of bits.

As a random example with 30 years of history: the X protocol specification is licensed under (a variant of) the MIT license, with the same mention of ‘this software and associated documentation files (the “Software”)’. (Note to avoid confusion: the MIT/X license includes an additional term at the end. The rest of the license matches, though, which makes it relevant for this point.)

#11

That still introduces a barrier to contributing to RFCs. If anyone contributing to RFCs has to assign copyright (which, again, typically requires a formal legal agreement to do), that makes it much more difficult for people to participate in that process, and some people won’t be able to participate at all.

I also don’t see how it buys anything. If the RFCs are licensed under a permissive license, it doesn’t really matter who owns the copyright; anyone can do anything they like with them. Why would this matter for RFCs and not for Rust itself?

#12

Because, in a future standardization process, all copyright should, in my opinion, be owned by the Standard Rust organization; but again, this is just a thought.

rustc is just a Rust compiler, who minds if it’s owned by any specifc organization.

#13

What problem would that solve?

#14

I’m not sure. It just seems right. That’s why I made the original post, and then put a concern on it.

#15

Okay then, associated documentation is correct. I couldn’t personally find any examples.

I’ll switch it to MIT when I get home :slight_smile:

1 Like
#16

Thank you!

#17

Please see my RFC on this issue: https://github.com/rust-lang/rfcs/pull/2044

#18

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.