AGPL - what you can do and what you can't
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
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.
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.
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.
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.
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.
Like... wat... so now all those Android phones with their Linux kernels are illegal...
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.
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.
it is AGPL, but MongoDB's one is also AGPL from the side of the service. The API Client is GPL.
@Bozho Mongo DB drivers are all licensed under an Apache license (I'm citing the website you linked).
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 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.
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.