Java and AGPL 3: how far does license extend into web app?

Question

I want to use a java library released by someone else having an AGPL3 license. I'm not modifying their library, but I do link to it using

import com.theirlibrary.methodABC;

in one of my java classes (e.g. MyClass1.java). Thus, I assume the compiled java class is AGPL obligated, and if I use it, I must make it public.

My question is, how far does the AGPL3 obligations extend into my web application?

My application file structure is:

myapplication
    WEB-INF
        web.xml
        FLEX
            remoting-config.xml
            services-config.xml
            messaging-config.xml
            proxy-config.xml
        CLASSES
            COM
                MYCOMPANY
                     MyClass1.java  (uses AGPL3 library)
                     MyClass1.class (uses AGPL3 library)
                     MyClass2.java
                     MyClass2.class
                     SERVLET
                         MyServlet1.java
                         MyServlet1.class
                         MyServlet2.java
                         MyServlet2.class

The web.xml file includes java servlets:

<servlet>
    <servlet-name>MyServletA</servlet-name>
    <servlet-class>com.mycompany.servlet.MyServlet1</servlet-class>
</servlet>
<servlet>
    <servlet-name>MyServletB</servlet-name>
    <servlet-class>com.mycompany.servlet.MyServlet2</servlet-class>
</servlet>
...

The remoting-config.xml file looks like:

<service id="remoting-service" class="xxx">
...
<destination id="myDestination1">
    ...
    <properties>
        <source>com.mycompany.MyClass1</source>
        <scope>application</scope> 
    </properties>
</destination>
<destination id="myDestination2">
    ...
    <properties>
        <source>com.mycompany.MyClass2</source>
        <scope>application</scope> 
    </properties>
</destination>
...

Note that only MyClass1.java depends on the AGPL3 library. Also, each class and servlet is completely independent of each other (they don't call each other or depend on each other's existence to function). A separate code base running in the client browser calls these classes and servlets.

Is it sufficient to only make MyClass1.java public?

Or, do I need to make MyClass2.java public as well?

What about the servlets?

What about my code sitting in the client's browser, which calls the classes and servlets depending on the user's choices?

How far into the application do I need to make public with AGPL3 license?

Answer 1

First there is no such thing as "infection". A bona-fide piece of FLOSS software is NOT a virus. There are only license obligations and requirements. Therefore a proper question should have been instead:

My question is, how far does the AGPL3 obligations extend into my web application?

The general theory is that when my program calls a function of a library using an A/L/GPL license, I am creating a work "based on the program" e.g. a derivative work and therefore the copyleft obligations (including eventual source code redistribution) extend to my program.

The LGPL licenses provide an exception to this when the library is used unmodified and the call is done through some dynamic linking. Some exceptions to the GPL (such as the Classpath exception) have the same effect and address specific linking (be it dynamic or static).

Short of such an exception, the copyleft would extend to the code that calls functions of copyleft-licensed code. Read also this answer more details on how copyleft terms and dependencies relate.

Now copyleft is triggered by redistribution. Running a public web backend app on some private server does not typically constitutes redistribution.

But the AGPL has a specific and somewhat unique section 13 that extends what is considered redistribution to certain public networks deployment such as a public web application:

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. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.[...]

As long as I do not modify the library, this paragraph has no impact on my web application as long as I do not redistribute the code for this web application and I am just merely running it: here the effective impact of the AGPL is not different from the impact of using GPL-licensed code on the server-side private backend of a public web application and I do not have specific source code redistribution obligations.

Additional answer elements, based on comments to this answer:

(1) MyClass1.java is a "derivative" work and copyleft obligations extend to my program; (2) these obligations get triggered when MyClass1.java is redistributed; (3) hosting MyClass1.java on a public web backend app on a private server is not considered redistribution in AGPL3 unless I modify the source code in the original AGPL3 library; (4) merely using the original AGPL3 code using java import does not quality as modifying the AGPL3 java library; (5) I have no code redistribution obligations for AGPL3. Is that correct?

Yes, that's my take.

I'm looking at different companies explanation of AGPL3 with their software, and I can't find confirmation regarding "unmodified" derived software being allowed to serve from public web app in private server. [...] makehuman.org/license_explanation.php [...]

Perhaps more clearly stated, this Q&A says:

You can not use iText in a web application without making the full source code of your web application available through that web application. This is why people often refer to the AGPL as a viral license: all the software that touches an AGPL library such as iText needs to be free too.

There are many ways to interpret licenses. I simply refer to the text of the license. The AGPL is rather simple and clear on this topic and the key trigger of its extra copyleft terms is modification. I can appreciate a different interpretation, but modifying is rather explicit and consistent in the way it is defined in the AGPL and in other FSF licenses such as the GPL 3.0 (where the terms are identical):

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.

Calling an existing library in Java redistributed as its own Jar is using and it can be neither copying nor modifying in anyway I can reasonably fathom.

When I see an interpretation of an FSF license markedly different from the what the text says, there are two possibilities to me:

1. I consider this interpretation --how flawed it may be-- to be part of the license and respect and comply with this interpretation.

2. I can ignore a flawed interpretation if I am confident of what its flaws are and may eventually seek legal advice to confirm this.

As a side note, several (but not all) companies using a dual licensing scheme with AGPL and commercial licensing often suggest that any network usage even if unmodified is redistribution and triggers the AGPL copyleft. I can appreciate the quid-pro-quo to entice the purchase of a commercial license but I think this is wishful thinking not grounded in any sane interpretation of the license text. I also personally think this is contrary not only with the letter but also with the spirit of the extra network-related terms of the AGPL that thrive to ensure that modifications are eventually shared but that unmodified usage without redistribution is not restricted otherwise.

Not all companies using a dual licensing scheme agree with a flawed approach that unmodified network usage is a redistribution. Take for instance MongoDB reading of the AGPL:

Our goal in selecting the AGPL v3.0 as our open source license is to require that enhancements to MongoDB be released to the community.

which is consistent with the license text.