How "viral" is the Affero GPL? [duplicate]

Question

MongoDB is licensed under the AGPL, and interestingly, its licensing page says the following:

To make the above practical, we promise that your client application which uses the database is a separate work. To facilitate this, the mongodb.org supported drivers (the part you link with your application) are released under Apache license, which is copyleft free.

(Emphasis in the original.)

Is this possible? Could not a receiver of the services provided by a website that uses MongoDB argue that he uses a derived work of MongoDB and that he is entitled to its source code?

If it is in fact possible, I have two questions about it:

1. What is the point, then, of licensing MongoDB under the AGPL rather than the GPL? It seems to make the difference between the two moot.
2. Could I not then also write a simple AGPL'd "wrapper" around a similar library such as Berkeley DB and offer a similar Apache-licensed "driver" library to permit its use in websites that do not, then, need to have their source code published?

Also, how viral is the AGPL in general? If I take a GPL'd web application or other network server, and modify it to store its data in a Berkeley DB, would I be required to release the resulting source code (assuming, of course, that I allow public use of the service)? Likewise, how about a service that makes internal use of eg. OpenLDAP which uses Berkeley DB for storage but isn't itself AGPL'd? Where does one draw the line?

Answer 1

No, a receiver of services provided using MongoDB has no standing to enforce its license. Only a copyright holder can do that, and they've promised not to (which, at least in English law, means that they cannot), so there is nobody who is in a position to legally require you to comply with the actual text of the license. Effectively, the MongoDB team have created a situation similar to the glibc linking exception to the GPL -- they've given you an extra right that you otherwise wouldn't have, by promising that they won't consider a certain class of use of their software as derivative, even in cases where it clearly actually is.

You can't, however, use a scheme like this to get around the requirements of somebody else's AGPL license, because only the copyright holder can make such a promise.

As to the point of this licensing scheme, I'm not privy to the MongoDB authors' reasoning, but the only thing I can think of is that it prevents somebody modifying the server and then setting up a cloud database service using it without releasing their modifications. Perhaps this was something that concerned the original authors.

Answer 2

Jules' answer is exactly right. Allow me to intensify the final "why do it this way?" point.

AGPL says others cannot improve MongoDB privately, then offer services based on their "enhanced versions," without at least making those improvements available to MongoDB, Inc. (among others).

The AGPL is a response to criticism in the open source community that many cloud operators, Internet service providers, and some HPC and financal industry shops devote enormous resources to tuning, tweaking, and improving their open source deployments, yet because they never "distribute" products based on the code, are effectively immune to copyleft.

Distribution is the triggering event for when you have to share your improvements under GPL, yet many large, technically- and economically-important organizations are exempt from that. "Not fair!" thought the open source community. "You're taking advantage of our work, yet making limited or marginal contributions back to the community!"

The Free Software Foundation did not wish to radically change GPL when it moved from v2 to v3, and it already needed to make many changes regarding thorny IP issues--especially patents. But it still wanted to address the "service provider loophole." Thus the AGPL alternative. It's an option for those that fear that large service providers and customers will make improvements and not "give them back to the community" (or, for the more business-minded: "not give them back to those doing the primary development and investment").

AGPL results are mixed. There are not a lot of AGPL-licensed projects, at least in comparison to the gazillions of projects licensed under one of the other GPL variants, Apache, Mozilla, etc. Some large cloud shops respond, in effect: "Fine. We just won't use AGPL projects."

MongoDB is arguably the most important project under AGPL. As a cloud-generation document-oriented DBMS, it arguably has one of the strongest business cases for AGPL protections. UPDATE: In 2018, MongoDB moved away from AGPL to its own, very similar but not OSI-approved, Server Side Public License. Presumably because MongoDB, Inc. believed that in practice, AGPL was insufficient to protect its interests.