AGPL: Out of the shadows

What is AGPL?

If GPL3 is scary to private businesses, then AGPL is even scarier. Shortly after the release of GPL3, the FSF released Affero GPL 3, or AGPL. Among those participating in the community drafting process for GPL3, there were two philosophical camps: One held that GPL3 should incorporate new conditions to close the SaaS loophole in GPL2, and another held that it was best to avoid changing a licensing model that had become familiar after so long. In the end, the “don’t fix it” viewpoint prevailed, and GPL3’s copyleft conditions still turn on distribution (or “conveying” in the terms of the license). Using GPL software to provide SaaS, therefore, is not considered distribution (or “conveying”) under either version of GPL.

But, in a way, the other viewpoint also prevailed, in the time-honored model of open source: If you don’t like it, fork it. The alternative was called Affero GPL, based on a prior and non-standard open source license written by Affero that spearheaded this new licensing condition. AGPL contains an additional clause that treats SaaS (“Remote Network Interaction”) like distribution, for purposes of invoking the copyleft conditions.

13. [I]f you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network…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.

Changing the rules

Why was that so scary? As they say, capital is a coward, and this new licensing model promised to impose new costs on users of AGPL software. Most companies, over the early 2000s, had developed internal controls for open source compliance. Those controls were developed as companies played catch-up to remedy a landscape of rampant non-compliance. The policies were often developed in a panic, at great expense and managerial angst.

But most open source licenses impose no conditions on internal use of software. So, internal controls developed in the early 2000s usually relaxed—or eliminated—approvals and processes when the software was not distributed. These controls often treated SaaS use just like any other non-distributed use case, such as development, testing, or network monitoring. The scary element of AGPL was that most internal controls just weren’t set up to handle this new condition. So most companies looked into a long, dark tunnel of re-vamping their open source processes, cringed, and promptly put AGPL on their “never approved” list.

Ironically, this never should have happened. Relying entirely on absence of distribution for open source compliance is just not a good idea. In reality, suppliers of software often flip back-and-forth fluidly between on-premises distribution and SaaS. An on-premises product can suddenly change into a SaaS product and vice versa, depending on the needs of customers. Some customers require local instances of software for regulatory or security reasons. Others want to avoid transmitting data across national borders. If a SaaS supplier has the opportunity to sell to such a customer, no one wants to be the unfortunate soul who has to tell the head of sales: no, we can’t do that because on-premises deployment is distribution, and it breaks all of our open source compliance processes. So it’s always best to develop compliance processes that treat SaaS as if it might someday be distributed.

Two uses for AGPL

Just as industry has warmed up to GPL3, it has slowly begun to accept AGPL3 code. The acceptance has centered around two loci: MongoDB and dual licensing.

MongoDB was an early adopter of AGPL3, and it had two very important things going for it. First, MongoDB pioneered the “NoSQL” database. It was cheap, scalable and effective, and caught on like wildfire. Second, Mongo published guidance for how to comply with the AGPL, without compromising the proprietary rights in applications that used it. Mongo provided Apache 2.0-licensed connectors to interface with applications, and stated that using them would firewall the licensing of applications—almost like AGPL with a linking exception. Industry heaved a collective sigh of relief and changed its policies from “never use AGPL” to “never use AGPL except for MongoDB.”

This is a great illustration of the “estoppel” technique of open source licensing. Because open source licenses are standardized and used by many licensors, no one licensor has the right to say what the licenses mean—at least vis-à-vis all the others. However, any licensor releasing code under GPL can provide interpretational guidance for its own software. In law this is called a estoppel, which is like a waiver, a statement made unilaterally by one party to its own detriment, inviting others to rely on it. For example, if I release some software under a license like GPL, and make a public statement that I never intend to enforce my conditions under GPL, it would be foolish for me to sue someone for violating GPL. The court would read my statement and conclude that it was not fair for me to invite the world to violate my rights and then sue them. Such interpretational guidance is not unusual in open source licensing; it allows licensors to use standard licenses in non-standard situations, tweaking them slightly to fit.

The other use case for AGPL, perhaps ironically, was dual licensing. The dual licensing model was pioneered by MySQL, and consists of releasing software under a copyleft license, and offering an alternative proprietary license, for a fee, to those who did not want to comply with the copyleft conditions. Before 2008, the license of choice for the open source prong of dual licensing was GPL2. It imposed the most conditions of any standard open source license, so it had the most power to drive potential licensees toward proprietary license fees. But AGPL added a new and significant condition, so it is now the favorite for dual licensing. In other words, in dual licensing, the scariest license wins.

Enduring questions

Unfortunately, the language of the additional network use condition in AGPL leaves some questions unanswered. The most common question is how far “down the stack” the condition reaches. Suppose you are using AGPL software as an operating system or language component to serve up an application. The user interacts with the application, but not with this infrastructure element. The copyleft condition says you must offer source code to “users interacting with it [i.e. the Program] remotely through a computer network.” That seems to mean that infrastructure elements will never trip this condition, because any user interaction would be too indirect. Ironically, one of the reasons given for “closing the loophole” in GPL was that companies who run massive server farms were not required by GPL to share their changes to the Linux kernel. But AGPL would never apply to the kernel, and even if it did, may not have required anyone to share kernel changes. (And most of those companies shared their changes anyway—not because GPL made them, but because it was good business to share.)