I have written a Java program designed to run server-side with a plain HTML web interface:

  • My app is based based on Apache Tomcat and I wrote a bunch of servlets.
  • I am reusing and I have integrated in this app one single third-party library that is licensed under the AGPLv3.
  • This library performs some file transformation and report creation of sorts using data that I feed it with when I call its methods.
  • This library is not part of code producing any of my web UI, though its output can be made available to users for download in my web app.
  • I use this library as-is and unmodified fetched straight from Maven Central: I am merely calling its methods in my own code.
  • This library does not have a corresponding source code download mechanism builtin (e.g. there is no mechanism as defined in the AGPLv3 Section 13 or in the AGPLv3 "How To").

In each of the following cases, would I have to redistribute the source code of my own application and of this library per the AGPLv3?

  1. When I run this application on a private company network and its is only available internally to my company employees?

  2. When I run this application on a public web site on the open internet?

  3. When I redistribute this application as a packaged software product to possible customers?

  4. What if in my case 2. the author of the library insist that the copyleft is triggered even if I am using the library unmodified and that I must redistribute the whole source code, including my own? [note: this is an addition following answers and comments]

  • 1
    Note: If you wonder why I created this question and posted a self-answer: this to cut short on the comments thread in this answer: opensource.stackexchange.com/a/663/947 and provide a more comprehensive explanation of my points – Philippe Ombredanne Jan 21 '17 at 23:46
  • Note that your interpretation creates a "Middleman Loophole" that turns the AGPL into LGPL. – Bruno Lowagie Jan 23 '17 at 5:01

There are several Q&A about the AGPLv3 on this site and some answers are sending vague or mixed signals. Here is a (hopefully) clear and definitive answer with references.

First the AGPLv3 is essentially the same license as the GPLv3 with the addition of Section 13 as you can see in this side-by-side diff of the two license texts:

  1. Remote Network Interaction; Use with the GNU General Public License.

Notwithstanding any other provision of this License, 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 by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. [...]

The intent of this new section is spelled out clearly in the preamble (bold emphasis is mine):

The GNU General Public License permits making a modified version and letting the public access it on a server without ever releasing its source code to the public.

The GNU Affero General Public License is designed specifically to ensure that, in such cases, the modified source code becomes available to the community. It requires the operator of a network server to provide the source code of the modified version running there to the users of that server. Therefore, public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version.

Now let's look at which parts of the AGPLv3 are triggered in your four cases:


You are using an unmodified exact copy of this library. Therefore this definition of Section 0 is relevant. You are not using a modified version if you are using an exact copy (bold emphasis is mine):

To "modify" a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a "modified version" of the earlier work or a work "based on" the earlier work.

Therefore per Section 2 in all three cases (bold emphasis is mine):

This License explicitly affirms your unlimited permission to run the unmodified Program.

And therefore since you did not modify it, the section 13 is not triggered.


  • In case 1, you certainly do not "propagate" the work: you are instead executing it on a computer.
  • In case 2 you may be "propagating" the work as you are somehow indirectly making it available to the public by running your public web server. Yet this is not 100% clear as you are not distributing a copy. I take a prudent point of view that you may be "propagating".
  • In case 3 you are clearly "propagating" the work as you [re]distribute the code.

(as defined in section 0)

To "propagate" a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.


You are clearly only conveying in case 3. In case 2, you are propagating but not conveying as there is no transfer of a copy.

(as defined in section 0) (bold emphasis is mine)

To "convey" a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.

Your further mention that as such this library does not have a built-in mechanism to offer a download of its corresponding source code as explained in the Section 13. Since this library does not have a built-in mechanism to self-download its corresponding source code, your propagation does not enables other parties to make or receive copies. Which further reinforces the fact that you are not "conveying" in case 2.

You also mention that this library takes your data and create some report format. I will assume that therefore the output is not subject to the license of the library itself and this part of Section 2 does not apply in your case:

The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work.

Finally, in all cases your application is combined and depends on the AGPL-licensed library and I would consider that its copyleft extends to your own source code.

But when is the copyleft effectively triggered in these cases? (and of course the copyleft requirement to eventually redistribute the source code of your own application?)

Since you are using the library unmodified, the key is whether you are either propagating or conveying or both

1. when I run this application on a private company network and its is only available internally to my company?

In this case, you are using the library internally unmodified, without neither conveying nor propagating: And per Section 2

This License explicitly affirms your unlimited permission to run the unmodified Program. [...] You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force.

This is all I have to say about your case 1: you do not have to make any source code redistribution of your own code using this library and of this library in this case.

2. when I run this application on a public web site on the open internet?

You are using the library unmodified, and there is no built-in Section 13 corresponding source code download mechanism. In this case you are propagating but not conveying. Therefore none of the Section 4, Section 5 and Section 7 apply here. In this context, the AGPLv3 is not different from the GPLv3. This is like running an unmodified GPLv3 program that you call from your own code on a publicly accessible web server backend. The copyleft is NOT triggered in the sense you do not have to make any source code redistribution of your own code or of this library.

3. when I redistribute this application as a packaged software product to possible customers?

You are using the library unmodified and there is still no built-in Section 13 corresponding download mechanism (but that mechanism would not matter much in this case).

Here you are propagating AND conveying. Therefore the Section 4 applies. In this context, the AGPLv3 is still not much different from the GPLv3. You are redistributing an application that is based on the unmodified AGPLv3-licensed library.

And the copyleft is triggered: you have to make a redistribution of the corresponding source code of both your own code and this library. In this case, this could also cover Tomcat, though Tomcat may also be treated as a "System Libraries" per Section 1.

4. What if in my case 2. the author of the library insist that the copyleft is triggered even if I am using the library unmodified and that I must redistribute the whole source code, including my own?

In this special case you should never ignore this interpretation (even though it looks clearly incorrect based on the facts I presented here) and you have two options:

  1. You could consider that short of proper Additional Terms compliant with the Section 7 of the AGPL, the author is trying to make a modification to the AGPL which is not OK under this license as the first statement says Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.. You could discuss this with the author and if you want to take the high road involve the FSF in a private discussion at first to resolve the matter.

  2. Or you could take this author assertions and comments at face value and treat this as if it were part of the license. This is usually my approach. E.g in this case and if you do not want to redistribute your source code when using the library unmodified in your case 2. you could just pass using this library entirely if anything because of its possibly incorrect and unclear licensing. Or use it and adopt its author's interpretation of the AGPLv3 -- even if not based on license text facts.

Finally let me provide some additional quotes supporting this answer:

  • From Jeffrey Kaufman in his article Do I need to provide access to source code under the AGPLv3 license?:

    What is often misunderstood is that the source code requirement in AGPLv3 Section 13 is triggered only where the AGPLv3 software has been modified by "you" (for example, the entity providing the network service). My interpretation is that, so long as "you" do not modify the AGPLv3 code, the license should not be read as requiring access to the Corresponding Source in the manner prescribed by Section 13. As I see it, many unmodified and standard deployments of software modules under AGPL simply do not trigger Section 13, although making the source code available even if not required under the license is a good idea.

  • From @apsillers who relates his exchange with the Free Software Foundation in his answer to a very similar question: Do I have to offer the source of an AGPL (v3.0) licensed Web app even if I didn’t modify it?

    I wrote to the FSF's licensing team about this question:

    [...] Does this [section 13] mean that if I run a *completely unmodified* AGPL-licensed program as a network service, I am *not* required to offer the source code to network users?

    And I received this response (bracketed phrase added by me):

    [...] If you haven't modified the software then you are not required to add that functionality [i.e., to download the source]. Of course, if the functionality to download the source is already in the unmodified software, it will already be there for everyone to enjoy.

  • This exchange with the FSF is consistent with the Free Software Foundation article on Why the Affero GPL?:

    [...]Suppose you develop and release a free program under the ordinary GNU GPL. If developer D modifies the program and releases it, the GPL requires him to distribute his version under the GPL too. Thus, if you get a copy of his version, you are free to incorporate some or all of his changes into your own version.

    But suppose the program is mainly useful on servers. When D modifies the program, he might very likely run it on his own server and never release copies. Then you would never get a copy of the source code of his version, so you would never have the chance to include his changes in your version. [...]

    and (with my additions in brackets):

    If D runs his version [e.g. the version that he modified] on a server that everyone can use, you too can use it. Assuming he has followed the license requirement to let the server's users download the source code of his version, you can do so, and then you can incorporate his changes into your version. (If he hasn't followed it, you have your lawyer complain to him.)

  • Heather Meeker makes this consistent comment in her the book "Open Source for Business" on page 134 after quoting the AGPL section 13:

    Note that these requirements only exist if you modify the software. Mere users need not make the source code available. [...]

  • And she further makes related comments in her article AGPL: Out of the Shadows:

    [...]Not surprisingly, AGPL3 has been slower to propagate than GPL3; if GPL3 has gained acceptance slowly, AGPL3 has been tagging along behind like a younger sibling. But the license is not as scary as it seems. The network interaction provision only triggers source code offer requirements when you modify the Program. In fact, most open source software is used without modification from community versions.[...]

  • And yet another comment in her article The Gift that Keeps on Giving – Distribution and Copyleft in Open Source Software Licenses that highlights what "convyeing" means:

    A Clear Case in the Clouds [...] Ultimately, this variation was removed from GPLv3 and memorialized in an alternative form of the license known as the “Affero GPL.” The basic form of GPLv3 makes clear that ASP or SAAS use does not trigger copyleft requirements. In GPLv3, copyleft is triggering by “conveying” rather than distribution, and “To ‘convey’ a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.” Under US law, distribution requires actual transfer of a copy, in whatever form. Therefore, under US law, SAAS use – which involves the access of software without transfer of a local copy to the user – does not trigger copyleft requirements.

  • Dr. Miriam Ballhausen in the article OpenSaaS: Using Free and Open Source Software as Software-as-a-Service makes this comment, with a point view of Germany (emphasis is mine):

    According to Section 13 AGPL-3.0 the SaaS provider - as the person who offers his users to remotely interact with a program via a computer network - is obliged to license any modifications to software licensed under AGPL-3.0 also under AGPL-3.0. In particular, he must give all users (but not all third parties) the opportunity to obtain the corresponding source code of the software version made available via SaaS.

| improve this answer | |
  • @apsillers I hope you do not mind if I quoted your exchange with the FSF – Philippe Ombredanne Jan 21 '17 at 23:48
  • 1
    You are interpreting an interpretation of an IP lawyer who works for a billion dollar company as if it were a fact. That's similar to denying climate change based on research by a single scientist paid for by OPEC. A judge might not agree with the difference between "conveying" and "propagating." Also: it goes against the spirit of free software that free software licensed under the AGPL could suddenly become part of non-free software. – Bruno Lowagie Jan 22 '17 at 10:32
  • @BrunoLowagie I do not think it is fair to summarize my answer as "interpreting an interpretation of an IP lawyer". I presented facts from the AGPL and I added quotes at the bottom that go in the same directions. – Philippe Ombredanne Jan 22 '17 at 11:20
  • 1
    @BrunoLowagie about your comment on the "spirit": I think the AGPL preamble and other FSF articles and commentaries (that I referenced in my answer) are what best represents this spirit. This preamble clearly spells out the case of modified vs. unmodified use as the main "spiritual" point of the copyleft impact of the AGPL. – Philippe Ombredanne Jan 22 '17 at 13:59
  • I'm still confused on how "using", "propagating" and "conveying" apply in this case. As I read it, the software in question is a library, not a stand-alone executable. So where do the different kinds of linking come into play? Why is the OP's software that depends on the (unmodified) AGPL library not considered derivative? – Mussri Oct 20 at 22:50

I'll answer only point 2 because this is the core of the question. Basically the question is: if I am building a public facing Java app on a private server and this app uses an AGPL library unmodified, am I impacted by section 13 of the AGPL license?

This section starts with "if you modify the Program" so it boils down to deciding whether use of a Java library inside a Java app counts as modification of the library. Your interpretation is that this is not modification because the library itself was not modified. I think this is an incorrect interpretation which is caused by the use of the term "modify" while section 5 of (A)GPL talks about "a work based on the Program". However these two must be interpreted exactly in the same way because they are defined in the same paragraph of section 0:

To "modify" a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a "modified version" of the earlier work or a work "based on" the earlier work.

Consequently, the usual consideration about what it means for a work to be based on another work applies and you very well know that the FSF's interpretation of this includes linking to a library.

I'll conclude by saying that Google probably agree with this answer because they have a special page dedicated to AGPL where we can read:

Using AGPL software requires that anything it links to must also be licensed under the AGPL.

| improve this answer | |
  • I feel that you may be conflating calling/using and modifying. How one could sustain a position that I am modifying a pre-built Java Jar fetched from Maven central when what I use is bit-for-bit identical to the one released by the project and I am just calling its code? I agree that the copyleft would flow to the caller... but I cannot fathom how one could argue that I modified anything. Aside from that the Google page is a nice find, but Google policy and interpretation is just theirs. – Philippe Ombredanne Apr 4 '17 at 23:17
  • 1
    I too find the terminology confusing but what I argue in my answer is that what the FSF is calling "modifying" is to be understood as synonymous of "making a derivative work" and you will agree that indeed calling an unmodified library is still making a derivative work (thus copyleft is triggered). – Zimm i48 Apr 5 '17 at 7:12
  • In any case, because section 0 of the license defines "to modify", you can't just use normal English understanding to interpret this word. – Zimm i48 Apr 5 '17 at 7:21
  • 1
    @Zimm Indeed, given the explicit definition, "to modify" is not just some English word any more. But obviously you need to obey the definition. And the definition includes the clause "other than the making of an exact copy". So exact copying is not modifying and hence the resulting overall work is then not "based on" the original work and hence copyleft is not triggered. – Lutz Prechelt Jan 16 '19 at 14:42
  • 1
    @Lutz Prechelt: OP isn't making an exact copy – they've added their own code in order to produce the software that's running on their server. To "modify" software doesn't just mean removing or replacing code. It can also mean adding code. So yes, all the bits they received from the library author are still there, but there are now also a lot of new bits that weren't there before. That these additions happened in a different jar does not matter according to my understanding of the GPL or AGPL. Only the LGPL would allow us to treat the library as its own separate thing. – Tordanik Mar 5 at 21:42

I think your answer isn't complete. I will try to explain why using simple language (no legalese) and a specific example.

Let's say that you are using the AGPL library iText to create PDF documents. iText is a library that allows people to create PDF documents (in general) and you are using the iText jar to create PDF invoices (a very specific use case). By doing so, you have created a derived work. If you take away iText, your code doesn't make sense anymore: it no longer creates invoices. If you replace iText with something else (e.g. PdfBox), it doesn't work anymore either.

Do you need to disclose your own source code?

It depends.


Suppose that you are using your application in batch. Every day, you create all the invoices of the previous day, and you store them on a server. People who want to see their invoice can go online and get their invoice from that server.

In that case, you can use iText without the AGPL kicking in, because you are using the library in a completely isolated way: you are not distributing it at all, so there is no source code to distribute either.


You don't create the invoices in batch, but you create them on-the-fly: e.g. whenever a user buys something, he triggers a process that creates a PDF. That process involves iText code to be executed. If iText were GPL, you wouldn't have to distribute your code, because you are not distributing a copy, but since iText is AGPL, copyleft applies:

Copyleft gives every person who receives a copy of a work permission to reproduce, adapt or distribute the work as long as any resulting copies or adaptations are also bound by the same copyleft licensing scheme.

Your derived work (e.g. creating PDF invoices) is an adaptation of iText (creating PDFs) and your work is bound by the same copyleft license.


In court, a judge will look at the involvement of the user.

  • If the user doesn't trigger the copyrighted software in any way, you don't have to disclose the source code of your work.

  • If the user triggers the execution of the copyrighted software, the license applies. In case of the AGPL, you have to disclose your source code to the user.

This is not my opinion, this is how it has been taught to me by different lawyers such as (Crealaw, Stibbe, Portelio).

See for instance the following slides by CreaLaw:

Software is covered by copyright law. The GPLv3 grants rights to users if they meet specific conditions:

enter image description here

Merely running GPLv3 software doesn't "activate" the conditions:

enter image description here

However: integrating GPLv3 software into an application, distributing,... can only be done if the GPLv3 is accepted.

enter image description here

In other words: the copyleft kicks in, and the AGPL makes the copyleft kick in even if the application runs on a network:

enter image description here

In this case, you must distribute your application under the (A)GPLv3:

enter image description here

This is inherent to the concept of copyleft.

Suppose that what I wrote wasn't true, then it would be possible for AGPL software to become part of closed source software. That goes against the spirit of the FSF.

| improve this answer | |
  • 1
    Which references in the AGPL text do support your take? – Philippe Ombredanne Jan 22 '17 at 11:23
  • Note that I added a new sub-question 4. and also answered it in my answer. – Philippe Ombredanne Jan 22 '17 at 13:54
  • Note that my question is not specific to iText and the licensing riders that you use in github.com/itext/itextpdf/blob/… . There are two specifics there: 1. you have additional terms per th AGPL Section 7 and 2. you clearly spell out that you interpret that unmodified use triggers copyleft (and even if I disagree) this is something that I addressed in my subquestion 4. and its answer too, for the sake of clarity. – Philippe Ombredanne Jan 22 '17 at 14:31
  • 1
    @PhilippeOmbredanne I have created a new Q&A explaining how one could rmake the AGPL act as if it were LGPL if you were right (but you aren't): opensource.stackexchange.com/questions/5010/… If you were right, there would be a serious loophole in the AGPL (but there isn't). – Bruno Lowagie Jan 23 '17 at 5:35
  • 1
    Your point seems to hinge on the fact that you consider reusing a software package that is bit-for-bit identical to the one redistributed upstream means modifying it or adapting it in all cases, correct? I do not see anything in your references that would support this assertion. And FWIW the terms of the AGPL seem rather material when we discuss AGPL, isn't it? – Philippe Ombredanne Jan 23 '17 at 15:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.