License? Copyright assignment?
Closed this issue · 9 comments
As it says in the title. We should probably have the MIT/Apache-2.0 license. I'd argue it should be copyright assigned to Mozilla Foundation, because it should at some point be transferred to the Standard Rust Organization, but /me shrugs. We should definitely get a license now though.
I believe the license files already exist in the repository, and have for some time:
What other changes would you suggest beyond those two files?
What other changes would you suggest beyond those two files?
Personally, I'd suggest two things:
- A "CONTRIBUTING" document, which explains in (slightly) more detail what the expectations are for contributions. I would suggest that this reference (and possibly inline) the Developer Certificate of Origin. Jonathan Corbet wrote a really good article on LWN summarizing a talk James Bottomley gave about it and its benefits.
- Institute a "Signed-off-by" discipline for commits, with that line indicating that the individual commit was contributed under the DCO.
This is the model the Linux kernel uses (and Git has in-built support for it, with git commit -s, and it is both minimal (contributions are under the outbound license; contributor has the right to contribute it) and powerful (with the MIT+Apache-2 licence we use, that covers patents, etc. in a
comprehensive manner).
When I suggested using this model to another project, one concern brought up was that people would "cargo cult" the Signed-off-by line without actually knowing what it meant.
A simple fix to that would be to maintain a .mailmap file in the repository (in sorted order, to reduce merge conflicts), with a header explaining that committing your email in that file indicates you understand the DCO<->Signed-off-by link. The project could then ask that people first send a commit adding themselves to that file, with their Signed-off-by.
That would even allow CI to validate that the policy is enforced, by requiring that the author/committer/both of each patch added a Signed-off-by and is present in .mailmap.
Combined with a Bors-style workflow, that would ensure clear licencing of everything that gets merged, with minimal overhead.
I'd also perhaps argue for putting our contributions to this repo underneath Mozilla, so that there can be a handoff to a future Rust committee, for standardization, etc. purposes.
@ubsan: I'm personally not especially fond of that idea - in particular, the license on it is sufficiently permissive that requiring copyright assignment would likely raise roadblocks to contribution without actually providing any useful benefit.
IMO, inbound=outbound should suffice for that - if not, I feel that either whatever group it's being handed off to has severe issues, or we're using the wrong licences.
One thing I forgot to link earlier is Bradley M. Kuhn's post on the sufficiency of the DCO, which covers a great deal.
Woah! That seems like a lot more steps than Rust itself does; as far as I know, all we do on the main Rust repo is just to have license files present. I feel like it doesn't make sense to have more policy here than on the compiler itself. I'm inclined to leave things roughly as they are, though adding a short license section to the README can't hurt.
@nikomatsakis: Not really "a lot more" steps unless someone is worried about people "cargo culting" - if that's a non-issue, it's just "use git commit -s instead of git commit" plus a little extra documentation.
In essence, the DCO is just a slightly more formal phrasing of the same concept having the licence files in the repo implies - that code must be contributed under those licences.
@nikomatsakis correct; this is far more formal than the Rust project, this is Rust-as-a-language, as opposed to rustc-the-compiler.
@eternaleye to me, deviating from the simplest possible git workflow feels like a non-trivial burden. I think we should adopt uniform policies across the rust repos, basically, so as to minimize the amount of time and trouble we impose on people who, for the most part, just want to leave a comment or correct a typo.