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.
Comments
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.