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.
This is my personal microblog. It's filled with my fun, joy and silliness.