It seems people have a hard time understanding the implications of licenses, so I have written a something to help with that.
- 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.
Absolutely not! Avoid CC0! Stop spreading bad information. If you want a public domain dedication with fallback permissive license the best choice is (sadly) The Unlicense. It is the only public domain dedication with fallback permissive license approved by both FSF and OSI. It’s unfortunate because The Unlicense is still a crayon license.
If you don’t want to burden some stream projects with including copyright notices, just don’t enforce it if you find people who forgot.
https://www.gnu.org/licenses/license-list.html#CC0
If you want to release your non-software work to the public domain, we recommend you use CC0. For works of software it is not recommended, as CC0 has a term expressly stating it does not grant you any patent licenses.
Because of this lack of patent grant, we encourage you to be careful about using software under this license; you should first consider whether the licensor might want to sue you for patent infringement. If the developer is refusing users patent licenses, the program is in effect a trap for users and users should avoid the program.
“just don’t enforce it” probably isn’t enough for most companies and projects
If your company won’t let you use MIT licensed software I don’t know what to tell ya. If your company won’t let you use MIT code, which FSF and OSI endorse, but will let you use CC0 code, which FSF and OSI do not endorse, then I really don’t know what to tell ya.
AGPL and GPL v3 are explicitly compatible, IIRC. You can run into some trouble with v2.
What I mean is that you (IIUC) can’t use an AGPL library in a GPL app without relicensing the whole thing to AGPL. For many larger projects relicensing is a huge hassle and often a non-starter if there aren’t very good reasons for it.
You’re right, the explicit permission is only the other way around.
MIT - only good for tiny weekend projects like Xorg, Wayland, Mesa, Godot, Jenkins, MUSL, Node.js, Angular, Vue.js, React, Rust, Julia, F#, Rails, PyPy, Redox, and the Haiku Operating System.
AGPL - good for serious projects that you want to be super successful. Widely used software that started off as AGPL includes………. uhh………wait…….ummm……. lemmy and Mastadon I guess?
Oh, I’m so sorry I believe projects should use more explicit licences over short ones like MIT. Apache is just more explicit than MIT. The only benefit I see MIT having over Apache is if your code base is so tiny that the Apache license like doubles the file size.
I believe a lot of devs value MIT because it is simple, but that doesn’t necessarily make it good. Sometimes code needs to be complex. Licences are the same way. Prefer explicit licenses written by lawyers over simplistic licenses and crayon licenses.
Well, for specific licenses there are use cases for MPL, which is weak copy left. LGPL is trying to state that statical linking is not allowed, while MPL does. Also, EUPL have simmilar advantages over AGPL, plus that it have very clear defined legal juristiction. So, when it comes to specific licenses there are many reasons to use whatever licence you use. Just make sure you use a license that reflects your expectations.
You can statically link LGPL code so long as you provide the end user instructions on how to use a different version of the LGPL portion of your code.
http://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic
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.
These are good in a more hands on way, but it is hard there to understand the conceptual difference between MIT and EUPL. So, I deliberately didn’t go in to the details, since there are a lot of tools for that. I aimed for a higher level, since I find people often have missed that.
I just wanted to add an additional resource related to the topic.
I’ve been thinking about using business source license for my projects. Fuck MAGAF and other companies for taking advantage of opensource devs, making billions and not wanting to contribute back or even support the dev.
Once the Post-Open license is finalised, there’s a good chance it’ll become my default instead of AGPL or BSL.
There’s a lot more variance in the specifics, but I think for an overview like this it’s certainly missing dual-licensing and “business-open” licenses like “readable but limited now, but free software two years from now”.
But I guess with the specific target audience of this post the reduction for simplicity is a good thing.
