Counterpoint: Drew DeVault's essay, "The falsehoods of anti-AGPL propaganda":
https://drewdevault.com/2020/07/27/Anti-AGPL-propaganda.html
https://drewdevault.com/2020/07/27/Anti-AGPL-propaganda.html
> You may not deploy it on a network without disclosing the full source code of your own applications under the AGPL license. You must distribute all source code, including your own product and web-based applications.
> It’s a legal violation to use iText Core/Community and our open source add-ons in a non-AGPL environment.
Rather than interpret Google's page[1] as some sort of psy-op, a simpler explanation is that there are many companies who use the AGPL license and want it to be totally viral even over network calls, and since the license has yet to be tested in court it's safest to just assume it has the strongest virality possible.
[0] https://itextpdf.com/how-buy/AGPLv3-license
[1] https://opensource.google/documentation/reference/using/agpl...
This page is just even more nonsensical than TFA. This is not "an interpretation of the AGPL that is as viral as possible", this is just a custom license that tries to masquerade itself as the AGPL. For example, the following term is batshit insane:
> When using iText Core/Community under AGPL, you must prominently mention iText and include the iText copyright and AGPL license in output file metadata, and also retain the producer line in every PDF that is created or manipulated using iText.
Yeah, no. If it was really AGPL, no one would forbid me from just removing all the watermarking code AND THEN publishing the non-watermark version to whoemever I wanted to.
There's a friggin reason 4-clause BSD is considered incompatible with the GPL. The advertising clause doesn't fit into any of the additional requirements that the GPL allows you to exceptionally introduce. A watermark is even a stronger requirement.
But in any case this is like trying to find problems in the GPL from a careful reading of the MS Public License. Sure the Ms-PL is a viral license from one of the "major software vendors of all history", but it is NOT the GPL.
If I write, say, a Java servlet that relies on an AGPL library, then by the same mechanics as effect GPL software, my servlet must now also be AGPL.
Now I host my service and the servlet runs, sending content to whoever made the request. Whoever made that request to the servlet over the network is now entitled to the source code of the servlet. This is what the AGPL does.
That whole effect stems from the original GPL, the AGPL just mucks with the new concept of network access being akin to the GPLs original use of distribution.
If the library was just a GPL library, now even though the servlet is, now too, GPLd, there’s no obligation for source code release because the servlet was not “distributed”. Simply used on site of the servlet developer.
Now if the original request is routed through a proxy, does the AGPL apply? Does the AGPL somehow “infect” the proxy? If not then a proxy is a simple AGPL firewall. If it does, let’s host some AGPL services and start make requests of AWS and Cloudflare for some of their source code.
Which sounds pretty silly.
The handwavey part is - what is "the application"? And they are not going into specifics there - it is, of course, only the application that you build it into. It doesn't virally extend to other things that interface with it over the network, and they're not going to say that part.
You naturally can thus build a minimal "wrapper app" that just provides this library-as-a-service according to some interface, so that you didn't have to release your whole program, but, it is not a misrepresentation that if you use iText core then at least this program will be bound by AGPL and must be distributed.
This is it.
I find it a compelling argument there is tremendous risk to AGPL if Google says so. They not only talk the talk but walk the walk: Google just indemnified AI (C) without limits putting 1.7 trillion dollars behind that statement. The same company said "nah, we are afraid of AGPL".
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.
I'm talking, of course, about the Class path exceptions.
Any derivative works of AGPL-licensed software must also use the AGPL.
Until AGPL is tested over and over in court, and all interpretations converge on Drew's interpretation here, it's not safe to have anywhere in your commercial stack.
There's a license that actually works this way, namely the eupl. If drew is especially interested in having a license that works this way, perhaps he should consider adopting that license instead?