Has anyone got any experience in relicensing a codebase from MIT to AGPL?
Ideally, an actually real case of it, with any of the complications or niggles that might arise.
@nicksellen the way you asked the question implies there are specific things that are causing concern.
The answer can be anything from "single git commit is all" to "never legally possible" and it depends on a few factors (number/contactability/agreeability of authors being a major one).
@Greg two separate cases actually:
with https://github.com/yunity/karrot-frontend we *might* be able to contact the authors, although now I look at the list, maybe not... lots of 1-time small contributors..
with https://github.com/FediHospEx/federated-trustroots it's a fork of an MIT project, and could likely not contact all authors. would also like to be able to pull (MIT) changes from upstream.
as MIT is so permissive, I thought they might be options to just change it to AGPL, but maybe need to keep some reference to MIT too....
The original codebase was MIT, and we relicensed when a commercial product and a community project were formed.
Here is where we announced it:
The discussion was among the most involved contributors, and then we asked everyone to sign them being OK with it:
@nicksellen @hedgedoc This becomes increasingly difficult with more contributors, of course, but that is - I think - a good thing. A license is a contract for everyone involved that sets the terms what will be done with their contributions. I think such a change _should_ be somewhat difficult.
This is also the reason why I do not like CLAs where developers (and other contributors!) give up their own rights to their code. I think this is putting too much power in to too few hands.
I think contributor agreement is unlikely for the forked project, this has 185 contributors (from "git shortlog -s -n") and we are a fork which itself was a fork from a starter project (including all those contributors). These 185 contributors are not even part of our project!
Given with MIT you can incorporate the code in a proprietary product, I wonder how to do that (distinguishing which code is MIT and which is proprietary), and whether that is an option...
Maybe this is a route though: if your proprietary code can be loaded as a plugin, you may just need to do very slight changes to the MIT Licensed part to load that plugin, and the plugin can be entirely closed off.
Again that's likely not the only way, It's just the only way that I _used_ before.
@nicksellen @claudius going AGPL from MIT license is actually not that complicated. MIT license allows sublicensing so while in Hedgedoc we got the OK from original authors, we wouldn't have needed it, as long as we are able to point out which code is under AGPL and which is under MIT license. AGPL's viral features would do the rest.
So you can relicense a project without asking all contributors, but do your best to point put which parts are under which license.
@sheogorath thanks! I think it's a promising direction...
...although the "point out which code is under AGPL and which is under MIT license" seems really tricky in practise.
if I change a line in an MIT licensed file, I'd want the change to now be AGPL, but most of the file would still be MIT.
the git history could somehow clarify (all commits since x are AGPL, .. but we also want to pull in upstream MIT changes).
am I just making it complicated? I just don't see an easy answer.
As long as you do your best to make clear from your side which parts are MIT and which are AGPL licensed you should be good.
While I'm not a lawyer, I have a hard time imagining that these efforts wouldn't be taken into account if it ever comes to a court case.
Get people on board with the change, do your best, and hope :)
@sheogorath @nicksellen With a large project and many years of development, you also couldn't get permission from people who might have died in the meantime. And yet that does not mean theit contributions have no strings attached any longer.
In my opinion, the "type" of change is also important. MIT -> AGPL might be less controversial than AGPL -> Proprietary. I mean this both in terms of debate among contributors _and_ if courts and lawyers got involved.
@nicksellen In my opinion you can do that. MIT is not copyleft, so it allows you to fork the project and put it under another licence. (Maybe there's a requirement about mentioning the former authors, but I'm not sure. Should be easy to find out.)
There could be patent issues though. The original copyright owners can sue you for patent infringement. (In contrast the Apache 2 licence says that the copyright owner will not sue you for that)
@t0k it seems a bit trickier than that:
https://opensource.org/licenses/MIT talks about "sublicenseing" and also says "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."
and actually a bit hard to find out! was drowning in stack overflow comments, thats why I was looking for some projects that had actually done it. getting some good engagement on here though 👍
@nicksellen en.wikipedia.org says: "MIT licensed software can be re-licensed as GPL software [...]". But yes, I think it is good to check.
As I understand MIT allows basically everything including sublicencing. There's the condition to include the copyright notice and permission notice (Wikipedia says that disappears on relicencing). I see no reason that would withhold you from publishing your own contributions under AGPL. If they are substantial, that practically makes the full project AGPL.
@nicksellen Is MIT incompatible with AGPL?
Is there a sole contributor / copyright holder, or are there multiple contributors / copyright holders?
Does the sole copyright holder, if there is one, support or oppose this decision?
If MIT is fully compatible with AGPL (and I believe it is, as with the 2-clause BSD license), then there is no problem.
If there is a sole contributor or copyright holder, then that entity holds copyright and can change licensing terms for future releases without limit. (Existing releases will remain licenced according to their earlier terms, doctrine of laches, etc.)
If the sole copyright holder does not support this, the first question remains operative. AFAIU MIT is compatible with AGPL, in the sense that MIT code can be incorporated into or relicensed such that the conditions of both licenses are preserved.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!