4 ms·
The AGPL is designed to infect code that isn't strictly "distributed" in the traditional sense. It considers deployment on internal infrastructure to be the sam
by giantrobot 3y ago
The AGPL is designed to infect code that isn't strictly "distributed" in the traditional sense. It considers deployment on internal infrastructure to be the same as distribution and requires code release. The core issue is what a court would consider derivative work.
I would not consider a DB schema or SQL running on a server to be derivative of the AGPL DB server's code. A judge/jury might however. Then all of my SQL and any wrappers calling it become infected.
This same question doesn't come up in a DB server licensed under the GPL, even v3. It's unlikely anyone could successfully argue that client node never publicly distributed could ever be considered distribution and therefore not derivative of the GPL code.
Because there's not much if any legal precedent it's not really propaganda to be concerned by AGPL projects. It doesn't matter what is technically true. It only matters what a judge or jury can be convinced of to ruin a business. The AGPL opens more uncertainty than the GPLv3 which opens more uncertainty than GPLv2 or less viral licenses.
- pritambaral 3y agoI don't see how this is any different from how Java has to deal with what is considered "derivative work" under the GPL for code that uses the JRE. Similarly, I see no reason the solution employed by Java wouldn't work for your example AGPL db. I'm talking, of course, about the Class path exceptions.