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

Switch license to Rust license? #2885

Closed
Manishearth opened this issue Jun 30, 2018 · 13 comments
Closed

Switch license to Rust license? #2885

Manishearth opened this issue Jun 30, 2018 · 13 comments

Comments

@Manishearth
Copy link
Member

Especially given that uplifts are happening, we should consider switching over to Rust's MIT/Apache v2 license. If we want we can keep MPL to have it triple licensed.

The process involved pinging everyone who has committed to the project and asking them for consent.

Thoughts?

cc @oli-obk @llogiq @mcarton @flip1995 @phansch @birkenfeld

@oli-obk
Copy link
Contributor

oli-obk commented Jun 30, 2018

Feels like the safest variant. I hope we can reach everyone. This has been done before, are there any scripts around that could be used?

@mcarton
Copy link
Member

mcarton commented Jun 30, 2018

We have 204 contributors now, so it might get a little tricky. We don't need all of them to agree though, very small contributions (eg. typo fixing) aren't protected like that. But it's hard to choose between small contribution or not. Also, IANAL.
What we could at least do is switch the license for future commits. All contributions until now would stay on the single licence we have now, and all future contributions would be doubly licenced. This would at least cover most new lints.

Anyway, as I just happened to come here a few minutes after this was created, and I'm not as involved as before (and don't even have time to read the dozens of emails I get from GitHub everyday), I'd better speak now:

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

@mcarton
Copy link
Member

mcarton commented Jun 30, 2018

Some time ago, there has been a wave of issues opened all over Rust projects' GitHub about licence changes with a generated list of all contributors. I've seen the template evolve over time. Any idea who did that?
(Also, why was Clippy spared?)

@Manishearth
Copy link
Member Author

cmr did that.

I think we can ask for everyone to sign off and then if some folks don't look at their contribs then.

@CAD97
Copy link
Contributor

CAD97 commented Jul 16, 2018

When sorted by additions, the GitHub contributor list gets to #100 with 2++.

IANAL, but I'm thinking nobody will complain much if you manage to get all 100 of those contributors to OK a re-license.

@emberian
Copy link
Member

https://github.com/cmr/relicense-assistant is everything I used to make that wave. Clippy was spared because I only targeted MIT xor Apache-2.0 projects. I wasn't interested in getting people to substantially change their license.

@emberian
Copy link
Member

emberian commented Jul 24, 2018

Note that for changing the license, you'll want to change the text of the agreement to something along the lines of:

I license past and future contributions under the dual MIT/Apache-2.0 license, and MPL-2.0, allowing licensees to chose any at their option.

This keeps the MPL-2.0 status quo until you can actually switch. Once you switch, in the readme/wherever you decide to document it, I wouldn't keep the bit about MPL-2.0.

@benbrittain
Copy link

benbrittain commented Jul 24, 2018

I and some other interested parties were talking about this earlier today actually. I think it would make the most sense to make this MIT/Apache-2.0 if it's in the "core" rust ecosystem now. Should the script open an issue or add to this Issue?

I am also strongly against triple licensing w/MPL, since that would invalidate my usecase.

@Manishearth
Copy link
Member Author

Manishearth commented Jul 24, 2018 via email

@Manishearth
Copy link
Member Author

Opened the relicensing issues, it's being coordinated at #3093

Going with simple dual licensing.

@est31
Copy link
Member

est31 commented Aug 27, 2018

@Manishearth I suggest that you also add a note to the README to make any future contributions licensed under MIT/Apache 2.0. Otherwise, you'll be always playing catch-up with the new contributors that made a PR since you opened those issues.

@est31
Copy link
Member

est31 commented Sep 13, 2018

@Manishearth
Copy link
Member Author

@est31 I don't think we can, because MPL isn't as compatible with the Rust license. Which means that folks would be contributing triple licensed code to an MPL codebase and I don't really want to deal with figuring out the legality of that. I guess a readme note works but it's not 100% clear.

I'd rather have them go through the same process, or explicitly note that they allow the work to be relciensed. I plan on asking on their PRs soon, once we're close to done with the historical bunch

Manishearth added a commit that referenced this issue Oct 5, 2018
Documentation on relicensing in previous commit

Fixes #2885

Also fixes #3093, fixes #3094, fixes 3095, fixes #3096, fixes #3097, fixes #3098,
fixes #3099, fixes #3100, fixes #3230
Manishearth added a commit that referenced this issue Oct 5, 2018
Documentation on relicensing in previous commit

Fixes #2885

Also fixes #3093, fixes #3094, fixes 3095, fixes #3096, fixes #3097, fixes #3098,
fixes #3099, fixes #3100, fixes #3230
Manishearth added a commit that referenced this issue Oct 6, 2018
Documentation on relicensing in previous commit

Fixes #2885

Also fixes #3093, fixes #3094, fixes 3095, fixes #3096, fixes #3097, fixes #3098,
fixes #3099, fixes #3100, fixes #3230
Manishearth added a commit that referenced this issue Oct 6, 2018
Documentation on relicensing in previous commit

Fixes #2885

Also fixes #3093, fixes #3094, fixes 3095, fixes #3096, fixes #3097, fixes #3098,
fixes #3099, fixes #3100, fixes #3230
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants