It seems people have a hard time understanding the implications of licenses, so I have written a something to help with that.
About the part on SaaS, the outcry is solely because the licences used by those projects weren’t approved neither by OSI or the FSF, they have clauses that specifically affect the economic aspect, and that can never fit in with either movement, but it is exactly that problem that the software authors want to tackle, preventing big corporations that already have the means to deliver a large scale service based on their software from making even more money than they already have, even if those corporations published possible modifications, the author would benefit little, because they most likely won’t have the infrastructure to run it on at the same scale and profiting from it.
Hot take: the real issue there is that those authors clearly don’t care for free software, because if they did, they’d have started off with AGPL or the like, instead they choose MIT exactly because of the possible economic prospect for themselves, when at some point they could implement vendor lock-in by baiting the users into believing that it was a community-run project at the start. Don’t get me wrong, they deserve to be paid for what they do, and corporations dropping by to profit from all that hard work feels wrong (but not illegal, and so it is fair), but exploiting the visibility and help of the community to reach popularity and credibility and eventually going private is a major dick move
- AGPL. Strictest. You want a strict license. Don’t let people take advantage of you. I see no good reason to pick GPL when AGPL exists.
- LGPL. If you want people to be able to use it (but not modify it) without their code having to be FLOSS as well. Still quite strict relatively with everything below.
- Apache. Permissive license. If you really want a permissive license, this is the one to go for.
- MIT. Permissive but less explicit. Okay for super short code.
Avoid at all costs CC0. CC0 explicitly does not give patent rights. MIT implicitly does.
A good reason to pick GPL is if you want to allow GPL software to integrate yours and you don’t care that much about the AGPL clauses (e.g. because your app isn’t a server).
CC0 might be a good fit for trivial template repos where you don’t want to burden downstream projects with having to include copyright notices.
you don’t care that much about the AGPL clauses (e.g. because your app isn’t a server).
I’ve been thinking about this recently… Let’s say you develop some local CLI. You think it’s not a server, so you license as GPL.
Later someone comes and offers your CLI as SaSS. They write the server piece that just calls your local CLI on their server and pipes the input and output between the user.
So… should you always prefer AGPL over GPL?
I have thought about this a lot and done some research on it. Bear in mind, I’m far from an expert, just a curious dev, but I’ve found no reasons to favor GPL over AGPL when AGPL exists. I personally see AGPL as closing a loophole GPL didn’t think of.
One thing I’d wondered if if maybe AGPL hasn’t been tested in court. It has. Not as much as GPL, and I don’t remember if it specifically was the online part, but I definitely found at least one court case involving AGPL code.
I like how you describe the Don’t Care licenses, aka permissive licenses. A lot of people fall for the narrative that more strict licenses are a burden for other open source developers, and then regret their decision when Evil Corp does what they usually do.
