Comment by lolinder | Hacker News Reader

Comment by lolinder | Hacker News Reader

Parent Full thread

Drew misses a huge cause of misunderstandings about the AGPL, which is that some of the companies that use AGPL would love for AGPL to be more complicated than Drew's simple version. For example, iText PDF's entire business relies on interpreting the AGPL as being as viral as possible [0]:

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

> Text PDF's entire business relies on interpreting the AGPL as being as viral as possible [0]:

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.

I'm inclined to agree that iText's position is bogus, but the point is that Google isn't inventing the idea of AGPL's virality out of whole cloth, they're using a definition that major vendors of AGPL software espouse. Interpreting it in the way that the vendors do is not a psy-op, it's just reasonable caution.

Major vendors of what? I had never heard of iText before (unless it is related to the 90s PalmOS software of the same name ? ) .

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.

The “viral” part of AGPL comes from the GPL itself.

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.

In iText's case this is not a misrepresentation - itext core is not a product like elastic or something that you interact with over the network, it's a library that you build into your program. And yes, in this case you would be bound by the license to release the programs you build it into, to the clients who interact with it over the network.

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.

Just because iText lies about what the AGPL requires doesn't mean that the AGPL is bad. If one company falsely claimed that their MIT-licensed product needed a different license for commercial use, would everyone start fearing the MIT license too?

I'm not arguing that the AGPL is bad, I'm just arguing that Google isn't responsible for the false narratives surrounding it. The vendors of AGPL software have a clear and immediate motivation to exaggerate its effects (more commercial contracts), whereas the motivation that Drew posits for Google is a much more elaborate long con. Occam's razor suggests that the vendors are at fault.

It sounds like iText wants a license that requires other developers to credit iText. Free advertising. But that's not the AGPL. Maybe the BSD license?

Reply on news.ycombinator.com