Discussion: Clarifying AGPL Licensing

[KieranP]

Hello. I stumbled upon this project, and noticed the AGPL license. Though I'm not a copyright lawyer, and I firmly believe software engineers should be paid for their work on projects such as this, I wanted to start a discussion on what appears to be a very common misconception around AGPL, one which I've noticed on this repos README, namely this statement:

A commercial license is needed as soon as HexaPDF is distributed with your software or remotely accessed via a network and you don't provide the source code of your application under the AGPL. For example, if you serve PDFs on the fly in a web application.

This statement is not correct. AGPL was designed to prevent companies from taking GPL licensed work that receives/sends data over a network (like web servers, mail servers, or databases/cache/etc) and making private modifications or bug fixes that they do not contribute back to the public. Though not under AGPL themselves, software such as Nginx, Postgres, Redis and Memcache spring to mind when thinking of software in this space. Additionally, AGPL only requires the modifications to be released, not the source code of the rest of the application that uses it.

Therefore, If a commercial web application were to use an unmodified copy of HexaPdf, the APGL license would not require them to open source their entire application. And because HexaPdf is not designed to receive/respond to network requests, even if someone did make private modifications, they would not need to make their changes public.

In HexaPdfs case, under AGPL, the only time someone would need to make the modification changes public would be if they created a derivative work that they distributed (e.g,. if someone created a paid PDF desktop app that used HexaPdf, any changes they make to the HexaPdf source code to make it work would need to be made available or they would need to purchase a commercial license).

With this in mind, a SaaS application that happens to use HexaPdf for PDF generation of invoices would not be required to purchase a commercial license. They could freely use HexaPdf under the AGPL license, given that 1) HexaPdf is not solely designed to receive/respond to network requests, 2) Only modifications need to be made public, no modifications means no issues with licensing

If your intent is to allow open source software to use HexaPdf for free but anyone using it in any commercial system acquire a license, AGPL is not suited for this.

Sources:

https://en.wikipedia.org/wiki/GNU_Affero_General_Public_License

It is intended for software designed to be run over a network, adding a provision requiring that the corresponding source code of modified versions of the software be prominently offered to all users who interact with the software over a network.

https://www.gnu.org/licenses/why-affero-gpl.html

if you run a modified program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the modified version running there.

https://www.gnu.org/licenses/gpl-faq.html#AGPLv3InteractingRemotely

If the program is expressly designed to accept user requests and send responses over a network, then it meets these criteria. .... If a program is not expressly designed to interact with a user through a network, but is being run in an environment where it happens to do so, then it does not fall into this category

https://fossa.com/blog/open-source-software-licenses-101-agpl-license/

Under AGPL, however, that developer would need to make their modified source code available for download ... AGPL imposes no conditions on using the code in software that’s sold commercially.

https://opensource.com/article/17/1/providing-corresponding-source-agplv3-license

AGPLv3 Section 13 is triggered only where the AGPLv3 software has been modified

https://medium.com/swlh/understanding-the-agpl-the-most-misunderstood-license-86fd1fe91275

[gettalong]

So it all boils down to what a modified version is and when it is distributed.

Tl;dr: In almost all cases you need a commercial license if you want to use HexaPDF in a commercial setting when you don't want to publish the source code of your whole application.

Modified Version

The AGPL is written in terms of "program" which makes understanding it in context of a license more difficult. In case of HexaPDF as soon as you require "hexapdf" and use HexaPDF in your application, you are incorporating HexaPDF into your application (HexaPDF is run in the same application memory space), making it a combined work and one that is derived from HexaPDF because it would not work without it. So the application is indeed a modified version of HexaPDF since it uses it and modifies it to do something new, e.g. generating invoices.

Note that it doesn't matter whether HexaPDF itself is modified or an unmodified version of HexaPDF is used as the incorporation into an application creates a modified version of HexaPDF.

Distribution

As for distribution: The AGPL explicitly states in section 13 that use over a network is deemed distribution and therefore the source of the whole modified work needs to be provided.

This means that if a SaaS application incorporates HexaPDF and a user interacts with the SaaS application and receives a PDF created by HexaPDF, section 13 is activated.

[gettalong]

It definitely seems that AGPL terms are ambiguous in the case of distributed software libraries. To say that using the public API of a piece of software constitutes modifying the original source code seems to be stretch and would need more discussion by copyright lawyers. From what I can tell, it doesn't look like any AGPL license holders have ever tried to uphold the license in court in cases like this, so there is no conclusive precedent.

iText is a Java PDF library that is also dual-licensed AGPL and commercial. And has been for a long time. Relevant links for this discussion are https://opensource.stackexchange.com/questions/5003/agplv3-source-redistribution-when-does-it-apply-to-my-code-for-a-server-side-ja/5005#5005 and https://opensource.stackexchange.com/questions/5010/can-i-use-the-middleman-loophole-to-reduce-agpl-to-lgpl/5011. Note that the author of those answers is the creator of iText.

Actually, the decision for dual-licensing AGPL+commercial was also based on seeing that this model was already in use by big companies like iText.

So one could argue that a self-contained tool like HexaPdf, that can be used without network interaction, and is therefore not "expressly designed to interact with a user through a network", would not fall under the category of network distribution.

This is only true for HexaPDF but if you integrate HexaPDF into your SaaS, you are developing a modified/adapted version of HexaPDF which is interacted with through a network. So in this case section 13 will enter into force.

And yes, if you just install HexaPDF via Rubygems and only interact with the HexaPDF CLI, using it under the AGPL would be fine.

As I wrote before I think many things related to using the AGPL for a library are a bit unclear because of the term "program" in the license text.

[KieranP]

Interesting. Thank you for your time and the discussion. All the best with the commercial success of HexaPDF.

[gettalong]

Thanks and no problem!

[KieranP]

@gettalong Just some extra food for thought: I just came across Faktory (https://github.com/contribsys/faktory), a high performance background processor, which likewise uses AGPL, but the author of that library (@mperham) interprets the AGPL differently, namely, only modified code made to the Faktory source code need to open sourced. Use of Faktory in commercial SaaS application does not require the commercial application or the jobs that include it's Faktory's public API to be open sourced. They make this very clear by adding some clarification at the top of the LICENSE file (https://github.com/contribsys/faktory/blob/main/LICENSE). This interpretation is more inline with how I suspect most people would interpret the terms "modified" in the case of libraries.

[gettalong]

@KieranP From the top of the LICENSE file:

Faktory is AGPL licensed. What does this mean? In short:

If you fork Faktory, make changes and allow others to access your modified Faktory,
the source code for those changes must be made available to those users.

Note the Faktory client and worker libraries are NOT covered by this license, only the server is AGPL licensed.
You do NOT need to open source any business logic or code for your background jobs.
Please email [email protected] if you have further licensing questions.

As it is clearly stated the server is AGPL licensed but not the client and worker libraries. So this cannot really be compared to HexaPDF as Faktory is a standalone application and HexaPDF is a library included into a SaaS application. The worker libraries seem to be released under various licenses like LGPL and MPL.