The AGPL and "Network Copyleft"

The AGPL is the best known of the "Network Copyleft" licenses. These licenses give everyone the right to run the software, but they modify the terms of distribution to include any interaction with the software over the network.

The AGPL requires that anyone using the software to run a service also offer an AGPL-licensed copy of the source code to each user that interacts with the software over the network - including the source code to any changes or updates that you have made to the software.

The specific language in the AGPL is this (emphasis added in bold ):

13. Remote Network Interaction; Use with the GNU General Public License.

Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) 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. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.

Derivative works and distributed applications

So what is "modify[ing]" the software? In the license itself, it says that "modifying" means:

.. to copy from or adapt all or any part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting derivative work is sometimes referred to as a "modified version" or we say that it is "based on" the earlier work.

Most people in the open source world are familiar with the idea that changing an application's source code creates a derivative work. This derivative work may need to also use the open source license. This is a known complexity, like any other open source software, including the GPL.

The microservices trap

What many people miss is the possible creation of derivative works when AGPL-licensed code is used in a networked, distributed application.

Normally, a "program" is a discrete thing. It has known limits. The copyright (and the open source license) usually stops at a process or network boundary.

But that is not necessarily true when the "application" is a distributed application. The common "microservices" architecture creates a single web application by coordinating the use of multiple services running on multiple servers. Each service handles one distinct aspect of the larger application (like authentication, or database access).

In this case, each individual service is its own, copyrightable work. But each service is also a sub-component of the larger application.

In this way, creating a multi-component distributed application is like taking a short story and including it with other stories to create a "Best stories of the year" compilation. Even if the AGPL-licensed software itself is not modified, the distributed application that includes the AGPL-licensed software has "adapted all" of the code, probably "in a fashion requiring copyright permission."

There are some applications that try to avoid this expansive reading of the AGPL by specifically disclaiming anything but the server itself - but this requires scouring each project's website and evaluating the strength of the disclaimer.

Internal use and contractors

The other way that AGPL software can be tricky to comply with is that it is possible to trigger obligations even when it is being run "internally." For almost all open source software, this is not an issue. Purely internal use can occur without imposing any obligations.

This is technically true for the AGPL as well. But the problem is that the AGPL starts imposing requirements when someone interacts with the software of the network. Many organizations allow certain vendors to act as if they are employees, even if they are not technically employed by the company. These can be independent contractors or employees of a staffing agency.

These "internal" contractors can trigger the AGPL's distribution obligations, even if the software never leaves the building.

Tread with care

The AGPL is good for many business purposes. But unlike most other open source licenses, it is not a license that you want to use unthinkingly or according to general rules of thumb. Every case needs to be considered individually. It may be difficult to fully comply without setting up business processes specifically made to handle AGPL-licensed source code.