Software licence description doesn't match AGPL licence limitations

Question

In my research of AGPL I have found that creating REST API around AGPL licensed library is enough to make it communication at arms length and as such it bypasses the need to publish all of your codebase.

If I use a public API endpoint that has its source code licensed under AGPL in my app, do I need to disclose my source?

Does using an AGPL 3.0 software via its REST API force to disclose source from calling software?

If I was interested in using iText (which is offered under AGPL and Commercial licence) for free in closed source commercial software without disclosing the source code to the user or public, creating REST API and putting it in docker container should be fine.

What I have noticed is that the text on their website describes license in a way that is contradictory to that statement. (Emphasis mine)

Buying a license is mandatory as soon as you develop commercial activities distributing the iText software inside your product or deploying it on a network without disclosing the source code of your own applications under the AGPL license.

https://github.com/itext/itext7

How to use the AGPL license correctly? The AGPL license comes with a couple of restrictions you should be well aware of.

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 Community and our open source add-ons in a non-AGPL environment.

https://itextpdf.com/how-buy/agpl-license

My question is how is this contradiction resolved? Are they offering it under a AGPL license only under additional conditions, are they altering the license or is that just useless flavor text which describes their (potentially wrong) understanding of AGPL.

Answer 1

When someone is in the dual-licensing business, it is in their interest to present the Open Source license as restrictive as possible, in order to convert more users into paying customers.

What iText is saying about the license is entirely correct, but vague enough to make you concerned that your usage might not be AGPL-compliant.

The relevant aspect of the AGPLv3 is Section 13. Excerpt:

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

Where the iText guidance confuses you it is about their talk of “source code” or “environment” which the AGPL refers to more clearly as “Corresponding Source”, and their talk about “deploying” whereas the AGPL talks more specifically about remote network interaction.

In many cases, there is no meaningful difference: if you deploy a web application that includes the iText library, then AGPL does require you to provide your application's source code to all users.

But your actual scenario is more nuanced, where you have wrapped the AGPL iText library in a REST API that is not publicly exposed.

• Section 13 will only trigger if users interact with the software remotely through a network. However, you are not letting users interact with the iText-derived application.

• Assuming that Section 13 does somehow trigger, we'd have to think about the scope of the Corresponding Source. Since AGPL is a copyright-based license, it will only affect programs or other creative works that are derived from the AGPL-covered component. REST APIs or command line interfaces can help draw a bright line that shows that two programs are clearly separate and not derived. If that is the case – but it's not necessarily the case – then the Corresponding Source would only cover the AGPL-covered library and the REST API wrapped around it, but not the clients that connect to the REST API.

Similarly to this iText-REST example, it is generally accepted that AGPL-covered database servers do not affect the licensing of software that connects to this server. For example, MongoDB was widely used in its manner before it changed its license to the non-Open Source SSPL.