Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

share|improve this question

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.

share|improve this answer
4  
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
4  
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": 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 5:17
    
Debian actually has 3 separate repositories due to licensing. main consists of DFSG-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-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. – Kevin Brey Nov 3 '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 at 0:59

Reports of GPLv3 and AGPLv3 "virality" are greatly exaggerated

Case 1: If you

  • use a library X that comes under GPLv3 or AGPLv3,
  • use it as a library (that is, keeping it as a separate entity without copying source code from the library into your own source code),
  • and do not modify it,

you do not have to make available anything.

Case 2: If you

  • use a library X that comes under GPLv3 or AGPLv3,
  • modify its source code, but still
  • use it as a library (that is, keeping it as a separate entity without copying source code from the library into your own source code),

you have to make available the modified source code of X (but not any other part of your overall application) if you distribute your own application and X has GPL or AGPL. The same holds if you make available the service provided by your application via a network e.g. as a web application and X has AGPL.

Why is that so?

Both GPLv3 and AGPLv3 are based on the following definitions (in Section 0):

"The Program" refers to any copyrightable work licensed 
under this License. [...]

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.

The remainder of the licenses only talks about "the program", "the work", or "the modified work". It does not talk about your software that is merely using the work.

Subsequent terms of the licenses allow you

  • to modify the work (Section 2)
  • to distribute the source code of the modified or unmodified work (Sections 4 and 5)
  • to distribute object code of the modified or unmodified work (Section 6)

These subsequent terms of the licenses require you

  • to also make available the "Corresponding Source" of the work if you distribute object code of the modified or unmodified work (Section 6)
  • to even do this if you do not distribute a modified work at all, but rather only make its services available via a network (Section 13, AGPL only)

They do not require you to make available anything else, such as the source code of any software in which you hold the copyright.

Really???

Yes.

The above rules become critical only if you copy any source code from library X into your own software in such a way that the distinction of the two will blur. This is the only case when your software may be "infected" by the GPL/AGPL code.

The best short legal source I could find that confirms this view is Patrice-Emmanuel Schmitz' "Why viral licensing is a ghost". It explains that interfaces have long been recognized in law as suitable boundaries of copyright claims.

A note on "derivative works"

Note the above details are about version 3 of the GPL and AGPL only. The situation in those cases appears fairly clear.

However, GPLv1 and GPLv2 used the notion of "derivative work" in roughly the places where GPLv3 talks of "modified work". Much of the discussion regarding virality still uses that notion of "derivative work" (or sometimes falsely "derived work").

Are things different in case of GPLv1 or GPLv2?

No. "Derivative work" is a technical term from copyright law and refers to a work that is itself worthy of copyright. It does not apply to the combination of library X plus your own software using it:

  • Object code (if that is what you distribute) is in itself never worthy of copyright, because it is produced by mindless compilers and such, not human beings. Only the underlying source code is in itself the reason to consider copyright. (That copyright extends to the object code, but only to the respective parts.)
  • The same holds for "less binary" representations such as JAR files containing bytecode or even the ZIP files holding source code distributions for PHP, Python, or Ruby applications.
  • The source code of your software is worthy of copyright independent of library X: Take X away and the remainder is clearly and necessarily still a copyrightable work. So you have not derived from X, you have only combined with it. (Compare this to the image of Mona Lisa with a moustache: The moustache alone would not be a comparable work any more.)

See also lawyer Lawrence Rosen's explanation.

"But Richard Stallmann says..."

Yes, indeed: In light of this discussion, some of the statements one can find on the GNU/FSF website are misleading. When reading them, consider that for instance in C and C++, using a library means including its header files in your code.

Richard Stallman likes the idea that all software should be free, but he does not claim infectiousness of GPL code. He says "The GPL's domain does not spread by proximity or contact, only by deliberate inclusion of GPL-covered code in your program."

Stallmann considers the notion of GPL virality to be derogatory and indeed the term is highly misleading.

Disclaimer

When you encounter a sufficiently odd judge, your mileage may still vary.

share|improve this answer
    
For case1: how does one (practically) use a library without including any of its headers and therefore parts of its source? – kat0r Apr 6 at 14:08
1  
You don't, at least in some languages (such as C and C++). But that is not a problem, because interfaces (which is what those headers constitute) receive special treatment legally. Read the above "Why viral licensing is a ghost" for details. – Lutz Prechelt Apr 6 at 15:55

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, therefore you are distributing the app if someone else then 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.

share|improve this answer
    
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? – Let_Me_Be Sep 13 '11 at 14:56
2  
@Bozho Mongo DB drivers are all licensed under an Apache license (I'm citing the website you linked). – Let_Me_Be 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
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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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