1d ago

What are the main differences between GPLv2, GPLv3, AGPL, and LGPL?

In my understanding, GPL is a copyleft license where your code can only be used in open-source projects (vs permissive licenses where your code can be used in closed-source projects).

Based on a few quick searches and my general understanding, it seems that AGPL is a more restrictive license where closed-source projects can’t depend on your code at all (?) and LGPL is a more permissive license where your code can be used in closed-source projects (?).

edit: After a bit more searching, I found that LGPL is still a copyleft license but a “weak” one. It looks like LGPL code used in other projects, if in their original form, can be closed-source but must be open-source if there are any changes. What constitutes as a change? Do ports count? How about updating syntax, like Python 2 to 3?

Also, it seems that AGPL might be almost the same as GPL (both are “strong” copyleft licenses) where AGPL just has a clause for source code sharing when it is shared over a network. In that case, why use GPL over AGPL, and vice versa? There seems to be many projects using GPL, so what is the downside to AGPL? Is the network sharing thing a bad restriction for some people, and why?

(back to original post from here)

I could be wrong on some or, more likely, all of those points. I also have a few questions. What is the difference between GPLv2 and GPLv3? If LGPL is more permissive, what are its differences compared to a license like MIT? Why would you go for one or another? And for AGPL, why would you prefer one over another? Is it simply how much (or really, how little) you want your code to be used in closed-sourced projects? And how do all these licenses interact with each other? Can you use GPL code in AGPL projects, and vice versa? What about LGPL code, is that too permissive for GPL or AGPL or can it be used in those projects?

10 comments

The other answers are really great, but I want to dig into the APGL a little.
The GPL said everyone you distribute your software to is also entitled to the code. This made sense in the pre-web-service era when software was some code you downloaded or got off a disk and ran on your own computer.
But with the internet it became common to run software on a server, which responded to distant users' requests. But that was a problem for the GPL because now the software wasn't distributed to the user, it was distributed to the server, which is controlled by me. So now I'm entitled to the code from my own changes, but the user has no such freedoms.
So the AGPL was created to try and close that loophole, and make it so that the internet users are protected as the license was originally intended to protect local users.
GPL = whenever you distribute software which contains GPL code or libraries, your code must also be distributed as GPL or compatible. V2 vs v3 differences are mostly in v3 clearing up some ambiguities.
AGPL = same as GPL, except it applies even if you simply provide your code as a network service
LGPL = same as GPL except it makes it possible to distribute closed source components (or with incompatible license) as long as the user is able to replace the LGPL libraries.
MIT = you can do whatever with the code
So, GPL only concerns you if you distribute your application as a binary to users, think like Photoshop or Microsoft Office. Your code is effectively GPL even if you don't distribute it, but there's no requirement to make the source available to everyone, only to those who you distribute the software to.
With AGPL even having the application accessible over the network is considered as distribution to users. You basically cannot have an effectively closed source application with AGPL.
LGPL is usually used with dynamically linked libraries where you can distribute your application easily as long as user can replace those. For example Qt is LGPL and you can sell your app without providing source code as long as the user can replace the Qt framework dll/so libraries.
And with MIT anything goes, you can use it in a closed source product, in fact of those four it's the only one that allows you to have a truly closed source codebase.
As for how they're compatible, the most strict license usually applies. All of these four are compatible to some degree, but you can't simply take a GPL code into a MIT codebase and make it more permissive suddenly.
Your code can be MIT, but the original still is GPL. Meaning that when you distribute the application, it's effectively GPL. Same with all license combinations.
As for why would you choose one or the other, it's pretty much about how much you want your users to give back.
With GPL, you want any modifications to be able to be included in your project. With LGPL as well, but you're not forcing people to open source their whole app, only direct modifications to your code. With AGPL you're basically forcing everyone to open source their app if they use your project at all. With MIT you don't care at all, you just give your code to the humanity to do whatever with it.
- Thanks for the thorough explanation, that was really helpful! So AGPL means it MUST be open-source and GPL means it only needs to be open-source for people you are “distributing” to (but not necessarily everyone). And if you make, for example, something like a webapp or website, then there is a clearer distinction between AGPL and GPL while it doesn’t really matter for standard binary apps.
  Interesting that the LGPL licensed parts of a project have to be “replaceable” (meaning updatable with a new version or fork? or does it mean something else?), even if the project in question is closed-source.
  And projects that include GPL code must be GPL licensed themselves or have a compatible license (like AGPL?). But what if you want to both use this set of GPL code but with a different license (either a permissive license like MIT or a different, non-GPL copyleft license), that would mean that you wouldn’t be able to use the code. I guess that’s the tradeoff between copyleft and permissive licenses.
  
  For your first paragraph: yes, exactly. For software you distribute in binary form to customers, GPL and AGPL are effectively the same thing. For SaaS you can easily use GPL and not share your source code. Though beware if your ever need to deploy your SaaS on the customer's premises.
  The point of these licenses is to not restrict user's rights, so LGPL doesn't want you to use their code and not let the user do whatever they want with it according to LGPL. So if I create an app and decide to not maintain it, you're still able to pull bug fixes etc. even without my involvement.
  Yes, GPL effectively makes your binary GPL as well. And if you provide a library for others using GPL code, projects using your library must be GPL-compatible as well.
  But the point is that you cannot restrict the user's rights, so if you distribute the source code you can choose a more permissive license (like MIT) for your code. That could in theory mean that if someone finds a replacement for your GPL dependency and remove it, they could release it under any MIT-compatible license (which is just about anything).
  GPL dependencies are often avoided in companies because of its spreading nature where it makes everything it touches effectively GPL. And even if you write SaaS, if you're B2B you'll eventually land a bigger customer with strict software policies and you'll have to deploy on customer's servers, thus having to legally distribute the source code as well.
  You don't have to provide it automatically, but shall they ask for it, you have to deliver. And relying on the customer never asking is not the best business decision. See for example here: https://boehs.org/node/truth-social
- Thanks for that explanation, @rikudou@lemmings.world!
@grue@lemmy.world 's explanation is spot on. However, just to practice summaries, I'll write anyway.
Here are a few terms I'll use:
Project A
Project B
The GPL family of licenses are all copyleft. This means that any code used from Project A in Project B, for instance, makes the latter have the same license, along with not being able to make either Project A or B proprietary*. Furthermore, with copyleft licensed software, you have to give the corresponding source code, along with the compiled binary.
The difference between the v2 and v3 versions of GPL is that, with the former, Tivoization was possible. Tivoization makes you only able to use the “official” version of the software, rendering it proprietary. Now, here is the comparison between the GPL variants:
GPL: The first of the kind, not much to say here.
LGPL: It allows you to link (as in libraries) code from Project A to B, without making Project B use the license, too
AGPL: You've certainly heard of SaaS, which allows you to serve websites licensed under the GPL, for example, without giving the corresponding source code. The AGPL solves this.
*That is, if there are more contributors to Project A that have not given up their authorship. Also, the version of Project A that used the GPLv3 before can still be used under the same license.
I don’t really have answers for you, but you might find this website helpful
Permissive licenses (MIT, BSD) prioritize programmers' freedom, letting them do whatever they want with the code including keeping their own changes proprietary.
All variants of GPL are copyleft, which prioritizes end uaers' freedom to control the software they use.
LGPL is for people who want the subsystem they're working on to remain free, but don't mind it being incorporated into proprietary software.
GPLv2 is for people who want to preserve users' rights to control the whole program.
GPLv3 is resistant to Tivoization, i.e. to preserve users' rights to actually run the program on the hardware it was intended for.
AGPL is resistant to circumventing users' rights by using SaaS instead of letting them run it locally.
(BTW, everyone who thinks there's a good reason to prefer GPLv2 over v3 is shortsighted and wrong. GPLv3 vs AGPL is slightly more debatable, but IMO AGPL should generally be preferred, too.)

10 comments