Our hope with the AGPL license is that it will make Triplit easily self-hostable while ensuring that anyone who makes modifications contributes those back to the community.
For the backend, that makes some sense. However, your frontend libraries and bindings are AGPL too, which means any site or app using them must be AGPL as well (since they would be derivative works). That makes it almost impossible for commercial products to use Triplit, which means there won't be companies putting development resources into the community.
Based on you making your frontend libraries AGPL, I believe any frontend using them would have to be generally compatible with the GPL family (so would also have to be *GPL licensed)
Yeah this seems like a major issue. I think the AGPL is strictly stronger than the GPL so if it was possible to use a GPL or AGPL library from non-GPL code then surely there would be no reason for the LGPL license to exist?
Yeah, unfortunately I think it's debatable whether LGPL is even OK for a closed-source project to use, since IIRC LGPL specifically talks about linking compiled binaries.
I guess there's the argument that transpiled, minified javascript program is a compiled binary? I'd love to know whether these things have been tested in various courts.
LGPL specifically talks about linking compiled binaries.
That's the context where LGPL is used most often, but the license itself is more general than that. In particular 4/d/0 in [1].
AFAIK, LGPL is about replaceability. If you distribute a compiled program (yes, a minified JS program should qualify) then you need to distribute the source of the LGPL part and document a way how the user can replace that LGPL part in your program with their own modified copy.
while ensuring that anyone who makes modifications contributes those back to the community
The AGPL doesn't really require this though. It requires the source code to be distributed to users, it does not require anyone to contribute those modifications back.
There's a chicken and the egg problem with this fear and approach to OSS. More permissive licenses (Apache, BSD) encourage adoption since it's hard to go afoul with them. At the same time, they allow someone like AWS to sell the DB as a hosted service.
People are trying to have their cake and eat it too with open-source DBs (and it's mostly DBs). Historically, OSS was either for anyone for anything, or it was a viral license trying to build a GNU ecosystem. The DBs playing licensing games have been using OSS as a growth hack, they doing a bait-and-switch once they're popular.
At least starting with the AGPL up-front is honest, but considering the client-server nature of this DB, it makes it a non-starter for me.
That article isn't right generally, by my understanding. It might be⁰ for their own use (a DB engine) but not for a library that might be more directly linked to an application.
AGPL is based on GPL, not LGPL, and like the GPL linking would be considered creating a derivative work which should then be made available as per the [A]GPL licence.
This won't stop me licensing my work using AGPL. If commercial interests don't want to use it then I'm fine with that¹. If they do want to use my stuff but don't want to use anything covered by AGPL then they can always contact me to try negotiate a different arrangement.
--------
[0] IANAL, hence “might be”. Whether loose coupling counts the same as linking is a grey area IIRC. This potential confusion is why some avoid GPL/AGPL, if only to be on the safe side from their PoV.
[1] Give the choice between “give us what we want with no come back and we'll use what we want and give nothing back” and “don't give us what we want, and we'll go away and leave you alone”, I'll take option two. I get nothing either way.²
[2] As the linked article says: “If you don’t use the AGPL[³], they’re just going to take your software and give nothing back. If you do use the AGPL, they’re just going to develop a solution in-house. There’s no outcome where Google pays you.”
[3] Here they are comparing AGPL to less restrictive licenses such as MIT.
Give the choice between “give us what we want with no come back and we'll use what we want and give nothing back” and “don't give us what we want, and we'll go away and leave you alone”, I'll take option two. I get nothing either way
This seems less fitting if it's true that what you're "giving" is some React bindings, and what they have to "give back" is their entire frontend application.
They don't have to give back if they don't use those bindings. They could use someone else's, or write their own.
They could also try negotiate an alternate arrangement, some authors may be willing to do that (assuming they have relevant permission from other contributors if it isn't a solo project, of course).
The example you give seems to be the unreasonable one IMO: “our thing is bigger, so we expect to use your smaller thing how we want”.
Your link confirms victor9000's point and contradicts your first sentence. The frontend libraries (the client-side database, the React and Svelte bindings, etc.) are AGPL, so your whole frontend that builds on them must be AGPL.
Can you point to which part in the license gives you the impression that using an unmodified version of AGPL code requires using AGPL for your entire application?
Either way your interpretation is not our intention so I'll make sure that's clarified.
AGPL is a "viral" or "strong copyleft" license [0], like GPL: if any part of a piece of software is AGPL, the entire software must be AGPL.
The license [1] says this in section 5:
5. Conveying Modified Source Versions.
You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:
[...]
c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
If you intended it to be non-viral (weak copyleft) and based on distributing modified versions of your files, the Mozilla Public License [2] may be a better fit for the frontend libraries. Then people could use them unmodified in software with any license, but they would have to release source code of modified versions of those files. This would not do what you want for the server software though, as the "release source code" only applies when distributing software (which is not happening if it's staying on the server).
I am not an expert, and it is not clear to me whether the frontend and backend constitute a single work according to the license. This is important to investigate. If they did count as a single work, rather than two separate works communicating, then the AGPL from the server software would apply to the client software and licensing the frontend libraries MPL wouldn't work. This says something about that in the other direction: https://www.gnu.org/licenses/gpl-faq.html#AGPLv3ServerAsUser
This always comes up with copyleft licenses. It's rarely 100% clear what's allowed, except maybe the LGPL where the intent of the license is obvious. Everything else is some amount of a viral license, and it's safest to just avoid it.
From my understanding, if someone were to create a private fork of Triplit Server add some modifications and then launch a hosted service (i.e. serving the modified Triplit Server over the internet) they wouldn't be compelled to open-source their modifications under GPL but would under AGPL.
But his wouldn't be the case even if MySQL was AGPL. The license would only apply to the database itself and not your backend or frontend code.
The difference would be if your code used a library that was GPL/AGPL. For server-side software, under the GPL, mere users wouldn't be entitled to the code, while under the AGPL they would be.
This also assumes that library was used in a way that counts as derivative work, which isn't always the case.
This also assumes that library was used in a way that counts as derivative work, which isn't always the case.
That's something a court would have to decide.
Whenever the AGPL comes up, people start arguing that in their opinion it doesn't cover certain things and therefore criticism of the license is fear mongering, but this misses the point that even if there is room to argue for that position, no company is going to want to touch AGPL software when the situation is ambiguous, since that creates a lot of risk, so that ambiguity is itself a fatal flaw of the AGPL license.
But none of these problems are relevant to GPL vs AGPL, they apply equally to both. Seriously, just diff the text of both licenses - the only difference is article 13, which is very clear and unambiguous:
Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.
Comments
Why did you choose to license this under the AGPL?
Our hope with the AGPL license is that it will make Triplit easily self-hostable while ensuring that anyone who makes modifications contributes those back to the community.
For the backend, that makes some sense. However, your frontend libraries and bindings are AGPL too, which means any site or app using them must be AGPL as well (since they would be derivative works). That makes it almost impossible for commercial products to use Triplit, which means there won't be companies putting development resources into the community.
Based on you making your frontend libraries AGPL, I believe any frontend using them would have to be generally compatible with the GPL family (so would also have to be *GPL licensed)
Is my understanding incorrect?
Yeah this seems like a major issue. I think the AGPL is strictly stronger than the GPL so if it was possible to use a GPL or AGPL library from non-GPL code then surely there would be no reason for the LGPL license to exist?
Yeah, unfortunately I think it's debatable whether LGPL is even OK for a closed-source project to use, since IIRC LGPL specifically talks about linking compiled binaries.
I guess there's the argument that transpiled, minified javascript program is a compiled binary? I'd love to know whether these things have been tested in various courts.
That's the context where LGPL is used most often, but the license itself is more general than that. In particular 4/d/0 in [1].
AFAIK, LGPL is about replaceability. If you distribute a compiled program (yes, a minified JS program should qualify) then you need to distribute the source of the LGPL part and document a way how the user can replace that LGPL part in your program with their own modified copy.
[1] https://www.gnu.org/licenses/lgpl-3.0.en.html
The AGPL doesn't really require this though. It requires the source code to be distributed to users, it does not require anyone to contribute those modifications back.
Right, that's a good clarification.
There's a chicken and the egg problem with this fear and approach to OSS. More permissive licenses (Apache, BSD) encourage adoption since it's hard to go afoul with them. At the same time, they allow someone like AWS to sell the DB as a hosted service.
People are trying to have their cake and eat it too with open-source DBs (and it's mostly DBs). Historically, OSS was either for anyone for anything, or it was a viral license trying to build a GNU ecosystem. The DBs playing licensing games have been using OSS as a growth hack, they doing a bait-and-switch once they're popular.
At least starting with the AGPL up-front is honest, but considering the client-server nature of this DB, it makes it a non-starter for me.
So you have to AGPL your product because of the database that it uses lol, hard pass.
I'm not a legal expert but my understanding is that your perspective is a common misconception.
I'd recommend reading this: https://drewdevault.com/2020/07/27/Anti-AGPL-propaganda.html
That article isn't right generally, by my understanding. It might be⁰ for their own use (a DB engine) but not for a library that might be more directly linked to an application.
AGPL is based on GPL, not LGPL, and like the GPL linking would be considered creating a derivative work which should then be made available as per the [A]GPL licence.
This won't stop me licensing my work using AGPL. If commercial interests don't want to use it then I'm fine with that¹. If they do want to use my stuff but don't want to use anything covered by AGPL then they can always contact me to try negotiate a different arrangement.
--------
[0] IANAL, hence “might be”. Whether loose coupling counts the same as linking is a grey area IIRC. This potential confusion is why some avoid GPL/AGPL, if only to be on the safe side from their PoV.
[1] Give the choice between “give us what we want with no come back and we'll use what we want and give nothing back” and “don't give us what we want, and we'll go away and leave you alone”, I'll take option two. I get nothing either way.²
[2] As the linked article says: “If you don’t use the AGPL[³], they’re just going to take your software and give nothing back. If you do use the AGPL, they’re just going to develop a solution in-house. There’s no outcome where Google pays you.”
[3] Here they are comparing AGPL to less restrictive licenses such as MIT.
This seems less fitting if it's true that what you're "giving" is some React bindings, and what they have to "give back" is their entire frontend application.
They don't have to give back if they don't use those bindings. They could use someone else's, or write their own.
They could also try negotiate an alternate arrangement, some authors may be willing to do that (assuming they have relevant permission from other contributors if it isn't a solo project, of course).
The example you give seems to be the unreasonable one IMO: “our thing is bigger, so we expect to use your smaller thing how we want”.
Your link confirms victor9000's point and contradicts your first sentence. The frontend libraries (the client-side database, the React and Svelte bindings, etc.) are AGPL, so your whole frontend that builds on them must be AGPL.
Can you point to which part in the license gives you the impression that using an unmodified version of AGPL code requires using AGPL for your entire application?
Either way your interpretation is not our intention so I'll make sure that's clarified.
AGPL is a "viral" or "strong copyleft" license [0], like GPL: if any part of a piece of software is AGPL, the entire software must be AGPL.
The license [1] says this in section 5:
If you intended it to be non-viral (weak copyleft) and based on distributing modified versions of your files, the Mozilla Public License [2] may be a better fit for the frontend libraries. Then people could use them unmodified in software with any license, but they would have to release source code of modified versions of those files. This would not do what you want for the server software though, as the "release source code" only applies when distributing software (which is not happening if it's staying on the server).
I am not an expert, and it is not clear to me whether the frontend and backend constitute a single work according to the license. This is important to investigate. If they did count as a single work, rather than two separate works communicating, then the AGPL from the server software would apply to the client software and licensing the frontend libraries MPL wouldn't work. This says something about that in the other direction: https://www.gnu.org/licenses/gpl-faq.html#AGPLv3ServerAsUser
[0] https://en.wikipedia.org/wiki/Copyleft#Strong_and_weak_copyl...
[1] https://www.gnu.org/licenses/agpl-3.0.html#license-text
[2] https://en.wikipedia.org/wiki/Mozilla_Public_License
This always comes up with copyleft licenses. It's rarely 100% clear what's allowed, except maybe the LGPL where the intent of the license is obvious. Everything else is some amount of a viral license, and it's safest to just avoid it.
What types of usage do you think the AGPL would prevent that the GPL license would have allowed? What situations were you trying to prevent?
From my understanding, if someone were to create a private fork of Triplit Server add some modifications and then launch a hosted service (i.e. serving the modified Triplit Server over the internet) they wouldn't be compelled to open-source their modifications under GPL but would under AGPL.
Why would your whole product need to be AGPL just because the database is ?
It's like saying that Oracle owns my product because I use MySQL.
The client libraries are also AGPL.
MySQL is GPL not AGPL. Very different.
But his wouldn't be the case even if MySQL was AGPL. The license would only apply to the database itself and not your backend or frontend code.
The difference would be if your code used a library that was GPL/AGPL. For server-side software, under the GPL, mere users wouldn't be entitled to the code, while under the AGPL they would be.
This also assumes that library was used in a way that counts as derivative work, which isn't always the case.
That's something a court would have to decide.
Whenever the AGPL comes up, people start arguing that in their opinion it doesn't cover certain things and therefore criticism of the license is fear mongering, but this misses the point that even if there is room to argue for that position, no company is going to want to touch AGPL software when the situation is ambiguous, since that creates a lot of risk, so that ambiguity is itself a fatal flaw of the AGPL license.
But none of these problems are relevant to GPL vs AGPL, they apply equally to both. Seriously, just diff the text of both licenses - the only difference is article 13, which is very clear and unambiguous: