239

AGPL is a fairly new license that was meant to go GPL-over-networks. However, not being a lawyer, and actually not having read the whole license, I can't understand what exactly you can do freely and what not with AGPL.

My uncertainty is fed by this post about MongoDB (which is AGPL) and even more by the comments below.

If we follow the comments it turns out that you can use AGPL libraries with your closed-source, commercial server-side software, as long as you don't modify the library. Is that the case? Or you have to distribute your entire application when you use an AGPL licensed library?

The case with MongoDB is that it uses Apache license for the client code, which poses another question. What happens if you use AGPL software, but deploy it as a different application that your closed-source commercial one? For example, take iText - it is an AGPL library:

  • if you use it and modify it, do you have to open-source your entire application or you have to redistribute only the changes in iText?
  • if you use it and don't modify it, do you have to open-source your entire application?
  • If you wrap iText in another application that you start as a separate process, but use it from your main application, should you open-source everything, or just the wrapper application? (The wrapper application will be HTTP-based API that will take pdf files and will return the results of using iText as JSON). Can this be used to circumvent the AGPL license?

Note: The question is about AGPLv3

Bozho
  • 2,665
  • 3
  • 17
  • 12
  • 2
    See also this related answer: http://opensource.stackexchange.com/questions/5003/agplv3-source-redistribution-when-does-it-apply-to-my-code-for-a-server-side-ja – Philippe Ombredanne Jan 23 '17 at 17:19

2 Answers2

60

The AGPL is based on the GPL, not the LGPL. It does not contain any linking exceptions, and any work using AGPL code (linked or otherwise, modified or not) must also be AGPL licensed and distributed.

Using separate processes can circumvent the (A)GPL, but this is murky ground. If your end application depends on the external process, such that it wouldn't function properly without it, then it would be considered a derived work of the AGPL software.

In most cases where people use separate GPL applications in closed source programs, they provide the GPL work as an optional extension, or an alternative back-end to some other piece of code etc.

The (A)GPL work cannot be distributed alongside the final application even as a separate app (eg, putting them into the same archive or repository), although it's fine to provide instructions on where to find the GPL work and how to use it with your app.

Mark H
  • 2,470
  • 1
  • 19
  • 12
  • 15
    While what you say is true, the only diffrence between the GPL and the AGPL is the requirement for supplying code if it's used interactively over a network. However, the clause that covers this states that it only applies to "Modified versions" of the work, and "modified versions" is defined as any use that requires copyright. Merely running the unmodified version does not create a "modified version", because copyright only covers distribution. – Erik Funkenbusch Sep 27 '11 at 18:10
  • 13
    1. "linked or otherwise" is wrong. 2. "it would be considered a derived work" is wrong 3. I think "In most cases" is wrong. 4. "The (A)GPL work cannot be distributed alongside the final application even as a separate app" is totally wrong, e.g. Debian distributes stuff with all sort of different licenses together, not all of which is compatible to the GPL. Proprietary systems can also do this. Take a look at section 3 of this page, starting from "Questions have arisen": http://www.ghostscript.com/doc/current/Commprod.htm Don't read the rest, it is trying to trick you into buying it. – Sam Watkins Apr 29 '15 at 05:17
  • 3
    Debian actually has 3 separate repositories due to licensing. `main` consists of [DFSG](http://www.debian.org/social_contract#guidelines)-compliant packages, which do not rely on software outside this area to operate. These are **the only packages considered part of the Debian distribution**. `contrib` packages contain [DFSG](http://www.debian.org/social_contract#guidelines)-compliant software, but have dependencies not in main (possibly packaged for Debian in non-free). `non-free` contains software that does not comply with the [DFSG](http://www.debian.org/social_contract#guidelines). – Kevin Brey Nov 03 '15 at 15:09
  • Re: "cannot be distributed alongside" -- can you point to the specific license provision backing that? I completely understand why you wouldn't want to ship AGPL-licensed code in a consumer product, but that's a fairly narrow circumstance. – Charles Duffy Jan 22 '16 at 00:59
  • 2
    Like... wat... so now all those Android phones with their Linux kernels are illegal... – Antti Haapala Jun 25 '17 at 21:35
  • 6
    There is no requirement to *publicly* distribute the source of software that depends on AGPL code. There is only a requirement to distribute it to *users* of the software, which the AGPL defines slightly differently than the GPL. – Kevin Krumwiede May 25 '19 at 08:57
  • What about hosting an AGPL software on a subdomain and server of another webapp which links to it? Should be ok yes? – That Realtor Programmer Guy Sep 27 '22 at 14:38
20

AGPL is the same as GPL; therefore if your app is using AGPL code it has to be AGPL licensed.

What AGPL does on top of GPL is the redefinition of user. For GPL programs running on your server, you are the user, for AGPL, the real users of the app are the users of your website or service. Therefore you are distributing the app if someone other than you is using it. And that of course implies all the standard GPL requirements.

As for Mongo, I'm assuming that apps using it don't use it's code, only some API, which isn't AGPL licensed.

Mark Bailey
  • 103
  • 3
Šimon Tóth
  • 882
  • 6
  • 11
  • generally speaking, I'm not using the code of iText either - I'm using its API, which is binary java API rather than a JSON API in the case of Mongo. – Bozho Sep 13 '11 at 14:51
  • @Bozho And under what license is that API? – Šimon Tóth Sep 13 '11 at 14:56
  • it is AGPL, but MongoDB's one is also AGPL from the side of the service. The API Client is GPL. – Bozho Sep 13 '11 at 15:02
  • 2
    @Bozho Mongo DB drivers are all licensed under an Apache license (I'm citing the website you linked). – Šimon Tóth Sep 13 '11 at 15:05
  • 2
    well, that's dodgy - what do we clal an API and what an API client. Btw can you answer the three bullet questions above? – Bozho Sep 13 '11 at 15:44
  • @Bozho These are questions for lawyers not programmers. But here are some links: https://www.gnu.org/licenses/gpl-faq.html#MereAggregation https://secure.wikimedia.org/wikipedia/en/wiki/GNU_General_Public_License#Linking_and_derived_works What applies to GPL applies to AGPL as well. – Šimon Tóth Sep 13 '11 at 16:34
  • 2
    There is no question that a work that uses AGPL'd code is licensed under the AGPL (Except for GPLv3 code which is specifically allowed to intermingle without the AGPL terms applying to the GPLv3 code). The problem comes in the definition of the Network usage, which refers only to "Modified versions", and the definition of "Modified versions" in the definitions means that it only applies to something that requires copyright (ie, distributing). So it's still rather murky. – Erik Funkenbusch Sep 27 '11 at 18:13
  • This answer looks more applicable to the Affero GPL than the GNU AGPLv3. Granted, the latter was intended to replace the former, but that doesn't mean the terms are the same. – Charles Duffy Jan 22 '16 at 01:02
  • Its worth noting that outside the GPL3/AGPL3 special exceptions, AGPL is incompatible with the GPL because of the no restrictions rule in the GPL. The AGPL is pretty much a shareware license in practice. Its not used to "protect freedoms" its there to try and shake you down for a pay-for license, and it saddens me that RMS didn't see that coming..... – Shayne Sep 02 '21 at 15:51