The AGPL — a strong copyleft open source license — has been in the news in recent months due to alleged compliance violations committed by Truth Social (a planned social media site of the Trump Media and Technology Group).
But the license’s intrigue extends well beyond this recent controversy. The AGPL holds a unique place in the open source world because of its unique provisions around network deployment. Specifically, the AGPL includes a section (which isn’t found in the GPL/LGPL) that covers SaaS, managed services, and hosted services.
In this blog, I’ll discuss the practical implications of the AGPL’s network deployment provisions, how the AGPL compares to other members of the GPL family, and why the AGPL came to exist in the first place. And, if you’re interested in this topic, I’d also point you in the direction of the on-demand webinar Truth Social, AGPL, and OSS License Compliance for a more in-depth discussion.
Editor’s Note: Heather Meeker is one of the world’s foremost legal experts on open source software licensing and compliance. She’s authored the go-to book on the topic, Open Source for Business, and is a General Partner at OSS Capital.
Why the AGPL Was Created
Most open source licenses have conditions — ranging from license notice to source code delivery requirements — that are triggered by the distribution of software. And, distribution is actually a right under U.S. copyright law. It is one of the enumerated rights of copyright: If you distribute a copyrightable work, you need a copyright license to do that, which is how all open source licensing works. Because you need a copyright license to distribute software, the licensors under an open source license can impose conditions on that distribution.
However, as the world moved to the cloud, software became less and less frequently distributed. If you look at the way the world was in 1991 when GPL v2 was released, most software was on-premises distributed software. Then, we started moving into the cloud, and people in the open source world were concerned — and reasonably so — that the way technology changed was an end-run around the source code sharing conditions of GPL. People could use GPL-licensed code and not share their source code changes because they hadn’t triggered the distribution that was required to impose those conditions.
During the drafting of GPL v3, there was a lot of discussion about the potential inclusion of a source code sharing requirement for software used to provide a managed service, SaaS, or hosted service. Ultimately, division in the community caused that provision to be excluded, but an alternative license, AGPL 3, was published to address those deployment models.
Since that time, the AGPL has had a fairly slow adoption rate. In a certain way, it was radically different from what had come before, so a lot of people weren’t willing to accept it as part of the generalized open source model. Those that did were mainly in two very different categories.
One category included people who believed the loophole should be closed and all software should be free. They moved to the AGPL, particularly for the type of software that would be used to support hosted services.
The second category included those who were interested in a dual-licensing model. Dual-licensing was originally pioneered by MySQL. The idea was to create a piece of software and place it under a strong copyleft license — but to offer users unable to abide by the terms of the copyleft license an alternate license for a fee.
Section 13 of the AGPL: A Closer Look
It’s useful to look at the actual language that implements the network copyleft language of the AGPL, which can be found in Section 13. Other than Section 13, the AGPL is entirely identical to GPL v3 with only a few modest, conforming changes.
With the AGPL, there are two triggers that both have to occur for the source code sharing requirement to kick in:
- You’ve modified the program.
- You make the modified program available to people remotely through a computer network.
Modifying the program is pretty easy to understand. It’s generally thought to be code changes only, but there’s no specific guidance on that. (People do ask whether configuration changes and other kinds of changes that are not code changes are modifications, and that seems unlikely.)
The definition of making the modified program available remotely through a computer network is still murky in part because this license has not had extremely broad adoption. However, the general feeling is that it’s direct interaction. So, if you have something running at the core infrastructure level and then you have an application running on top of it, there’s a legitimate question whether that’s making it available for people to interact with over a network. But it is pretty clear that if you make it available as SaaS in the conventional use of that term, then you have triggered the source code sharing requirement if you modify the program.
Unfortunately, there is not a lot of writing and no case law on the AGPL’s source code distribution requirement, but what I’ve shared above articulates the general thoughts of what it means. Another important point is that if you do trigger the source code distribution requirements, you must make the corresponding source code available.
In this context, “corresponding” means the source code with your changes (along with build and installation instructions), from a network server, at no charge. In actual practice, people usually go about complying with this requirement by building a dashboard feature or an “about box” feature that offers the ability to download the software. (This is usually in the same place where people get access via the computer network to the software.)
Copyleft License Comparison: AGPL vs. GPL vs. LGPL
Now that we’ve covered why the AGPL is characterized as a network copyleft license, let’s discuss some of the differences between it and other members of the GPL family.
The canonical free software license is the GPL (GPL v2 and GPL v3 are the versions commonly used today). GPL is a license that’s suitable for entire programs. The GPL essentially says that if you distribute software, all the software that you distribute within the program has to be GPL or GPL-compatible. You cannot mix and match GPL software and proprietary software in a distributed program.
What’s really important to understand here is the definition of a program. A program has a moderately technical meaning, which is that it’s an executable process. So if you’re on your desktop and you’re using Microsoft Outlook, that’s a program. If you are using Microsoft Word, that’s another program. And you can get them to talk to each other, but they are different programs running at the same time, multitasking — you have to switch between one and another if you want to use them.
Now, the LGPL is a license for libraries, or pieces of programs. Its technical name is the Lesser General Public License, but it was originally called the Library General Public License, and it’s easier to remember that way.
A library is code that gets used as part of a program for a programming task that might be done in many different programs. So, let’s say you are using a word processor and you decide to print what you’re working on. The code that does the printing is a library, because it might work for all of the programs that you’re using on your computer, not just the word processor. So, if someone wants to write a good print routine, that would not be a whole program, that would likely be a library.
A library is something that gets used as needed. If you release a library under the GPL, it likely wouldn’t be broadly adopted because every program that uses said library would also have to be GPL. In short: LGPL is for parts of programs, GPL is for full programs
The AGPL is basically the same as the GPL, but with an extra provision about treating network deployment as distribution. So, the GPL and LGPL have source code delivery requirements of varying scope that are triggered by code distribution. But the AGPL can be triggered in the absence of distribution.
The difference between GPL and LGPL is about integration with other code. The difference between those two and AGPL is about what triggers source code sharing requirements.
Finally, it’s worth mentioning that there are subtle differences between multiple versions of each license. For example, the LGPL v3 is an amendment to the GPL v3. There’s the base document (GPL v3), and LGPL 3 has some additional permissions that allow you to deploy the code as a library with proprietary applications. Whether the code will be compatible with other code depends a little bit on these versions. For example, some people release code under GPL v2 or any later version, or just GPL 3. So make sure to pay attention to the license version along with the license name.
Get More Information on the AGPL
If you’re interested in learning more about the AGPL, I’d recommend you check out the on-demand webinar: “Truth Social, AGPL, and OSS License Compliance.” We cover more angles related to the AGPL, including some of the recent license compliance surrounding planned Trump Media and Technology Group social media site Truth Social.
