Follow

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.

Β· Β· 6 Β· 8 Β· 7

@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).

Say more?

@Greg two separate cases actually:

with github.com/yunity/karrot-front we *might* be able to contact the authors, although now I look at the list, maybe not... lots of 1-time small contributors..

with github.com/FediHospEx/federate 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....

@nicksellen @Greg the primary advantage of it being MIT is that you can get away with just leaving all the unowned pieces MIT and relicensing the rest.

Only way to remove the MIT license is to get all contributors to consent to the license change.

@rune @Greg thanks! my reply over here social.coop/@nicksellen/106556 has some follow-up questions... wondering how it works when wanting to make an AGPL change to an MIT file...

@nicksellen HackMD / CodiMD / @hedgedoc !

The original codebase was MIT, and we relicensed when a commercial product and a community project were formed.

Here is where we announced it:
github.com/hackmdio/codimd/iss

The discussion was among the most involved contributors, and then we asked everyone to sign them being OK with it:
github.com/hackmdio/codimd/pul

@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.

@nicksellen @hedgedoc I should mention that the AGPL3 community project now lives here: hedgedoc.org/

@claudius thanks!

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...

@hedgedoc

@claudius @hedgedoc

... also, whilst I'm here, thanks for hedgedoc, I use it multiple times a week across a couple of projects.. πŸ‘

@nicksellen @hedgedoc β™₯
Most of the love goes to the current developers and maintainers. I have to admit that I personally am struggeling to find the time to contribute at the moment. But I did forward your post to the current developers :-)

@nicksellen @hedgedoc that latter part is outside of my expertise, sorry. Other than "we're using this MIT-Licensed Library" (which is a very obvious boundary) I didn't have to separate code so far.

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.

@claudius @hedgedoc

thanks, yes, I guess that's the issue, finding a clear boundary.

(to clarify the "proprietary" bit was just as a comparison, given that happens a lot I think, in the project we want to re/sub-license as AGPL)

@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.

@claudius

@nicksellen @claudius well, what we did was pulling in most contributors. I think you could do the same :)

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:

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.

Sign in to participate in the conversation
social.coop

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!