You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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?)
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.
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.
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.
As long as we're getting everyone's consent we can remove MPL just fine
(the old releases will still be MPL of course)
I do think switching to dual is simpler.
On Mon, Jul 23, 2018, 5:54 PM Ben Brittain ***@***.***> wrote:
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?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#2885 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABivSEHFHtmK_Pr8oO_BpPxVHL-QXA1Lks5uJnBFgaJpZM4U-CZQ>
.
@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 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
Activity
oli-obk commentedon 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 commentedon 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:
mcarton commentedon 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 commentedon Jun 30, 2018
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 commentedon 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 commentedon Jul 24, 2018
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 commentedon 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 commentedon 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 commentedon Jul 24, 2018
Manishearth commentedon Aug 27, 2018
Opened the relicensing issues, it's being coordinated at #3093
Going with simple dual licensing.
est31 commentedon 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 commentedon Sep 13, 2018
To prove my point, these folks have been newly contributing under the old MPL license after the issues were opened:
Not making any claims that this list is exhaustive.
Manishearth commentedon Sep 13, 2018
@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
Relicense clippy
Relicense clippy
Relicense clippy
Relicense clippy
Relicense clippy