The Ultimate Guide to the Affero General Public License (AGPL)

LEGAL DISCLAIMER: This article provides general, informational content for educational purposes only. It is not a substitute for professional legal advice from a qualified attorney. Always consult with a lawyer for guidance on your specific legal situation, especially when making decisions about software licensing for your business.

Imagine a community garden where everyone agrees to a simple rule: you can take any vegetables you want for free. You can use them to cook for your family, or even start a small food stand. If you develop a new, improved type of tomato plant based on one from the garden, you must share your new seeds with the community. This is the basic idea behind the standard gnu_general_public_license_(gpl). Now, what if you don't sell the tomatoes directly, but instead open a restaurant that serves a special tomato soup? People never get the tomatoes themselves, only the prepared soup. The standard GPL rule might not require you to share your recipe. The Affero General Public License (AGPL) closes this “restaurant loophole.” It says that if you use the community's tomatoes to offer a service (the soup), you must share the recipe (your source code) with anyone who eats at your restaurant (uses your service over a network). It's designed to ensure that the spirit of sharing and freedom extends to the world of web services and cloud computing.

• Key Takeaways At-a-Glance:
• Networked Sharing is Mandatory: The Affero General Public License (AGPL) is a copyleft license that requires you to make your application's source code available to users who interact with it over a network, closing a loophole found in other licenses.
• It Protects User Freedom in the Cloud: For an ordinary person using a web application, the Affero General Public License (AGPL) ensures they have the right to get the source code, modify it, and run their own version of the service, preventing a single company from having total control.
• Critical for SaaS Businesses: If you are building a saas business or any networked application, you must carefully check if any of your software components use the Affero General Public License (AGPL), as it has profound implications for your own source code.

The story of the AGPL is the story of how the internet changed software. In the early days of the open-source movement, the primary way to distribute software was to give people a copy they would run on their own computers. The free_software_foundation_(fsf), led by Richard Stallman, created the gnu_general_public_license_(gpl) to protect user freedoms in this environment. The GPL's core principle, known as copyleft, states that if you distribute a modified version of GPL-licensed software, you must also distribute it under the GPL, making your changes available to everyone. By the early 2000s, a new model was emerging: the Application Service Provider (ASP), the forerunner to today's saas model. Companies started running software on their own servers and allowing users to interact with it through a web browser. Suddenly, they weren't “distributing” the software to users' computers anymore. They were providing a service. This created what became known as the “ASP loophole.” A company could take GPL-licensed code, modify it heavily, run it on their servers, and never have to release their modified source code because no distribution, in the traditional sense, was taking place. To address this, the FSF, in collaboration with a company called Affero, Inc., released the original Affero General Public License (AGPL) in 2002. It was specifically designed to close the ASP loophole. When the FSF later released the gplv3 in 2007, they also released the GNU Affero General Public License version 3 (AGPLv3), making it compatible with GPLv3 and solidifying its place in the family of GNU licenses. The AGPL was born from the necessity to ensure that the user freedoms of inspection, modification, and redistribution would survive the monumental shift from desktop software to networked services.

The entire power of the AGPL is concentrated in a single, additional section that distinguishes it from the GPL. While the full license is a detailed legal document, its heart is Section 13. Section 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.”

Let's translate this from legalese into plain English:

• “If you modify the Program…“: This clause applies only if you've made changes to the original AGPL-licensed code. If you use it as-is, your obligations are different.
• ”…prominently offer all users interacting with it remotely…“: This is the trigger. If someone uses your software over a network (like using a web app, an API, or a game server), this clause kicks in. It doesn't apply to employees using it internally on a company intranet if the public can't access it.
• ”…an opportunity to receive the Corresponding Source…“: “Corresponding Source” means not just the original code, but all of your modifications, build scripts, and anything else needed to compile and run your version of the software.
• ”…from a network server at no charge…“: You must make it easy for them to download. A common way is to add a “Download Source” link in the footer of the web application.

This single section is a powerful legal mechanism that extends the philosophy of copyright_law and copyleft into the modern cloud era.

Choosing an open-source license can be daunting. The AGPL is often called a “strong copyleft” license, but how does it really stack up against the others? This table breaks down the key differences.

What does this mean for you? If you are a developer building a web service, using an AGPL library is a much bigger decision than using an MIT-licensed one. It could obligate you to release the source code for your entire service.

The AGPL, like any legal contract, imposes specific duties on you if you choose to use software licensed under it. Understanding these obligations is the key to compliant and stress-free use.

This is the central promise of the AGPL. If your modified AGPL software is used over a network, you must provide its “Corresponding Source.” This isn't just the code you wrote; it's the full package. Think of it like providing not just a cake recipe, but also details on the brand of flour you used, the oven temperature, and the specific techniques required to bake it successfully.

• What it includes:
  • All source code for the modified work.
  • Any modification files.
  • Interface definition files.
  • Scripts used to control compilation and installation of the executable.
• How to provide it: The most common method is a clear and “prominent” link on the user interface of your network service (e.g., in the footer of every page) that points to a downloadable archive (like a .zip or .tar.gz file) of the source code.

This is the most misunderstood part of the AGPL. The obligation to share source code is not universal; it is triggered by a specific event: remote interaction over a computer network.

• What IS a trigger?
  • A public website: If your website's backend is built on a modified AGPL framework (like a CMS or e-commerce platform), every visitor is “interacting remotely.”
  • A SaaS application: Customers logging into your cloud-based accounting software are interacting with it.
  • A public API: A developer making calls to your API service is interacting with it.
  • A multi-player game server: Players connecting to your server are interacting with it.
• What is LIKELY NOT a trigger?
  • Purely internal use: If you run a modified AGPL tool on your company's private network, and it's only accessible to your employees for internal tasks, you likely do not have an obligation to provide the source to the general public. The interaction is not with “all users” remotely. This is a critical distinction for businesses.
  • Batch processing: If the AGPL code runs a background task that has no user interface and doesn't respond to network requests, it's not interacting.
  • Separate programs: If an AGPL program communicates with your proprietary program through simple command-line calls or pipes, they may be considered separate works, not a single modified program. This is a legally gray area and requires careful analysis.

The term “viral license” is often used, sometimes with a negative connotation. A more neutral term is “reciprocal.” The AGPL requires that your modifications and, in many cases, the larger work they are part of, must be licensed under the AGPL as well.

• Hypothetical Example: You are building a new SaaS project management tool. You decide to use a cool AGPL-licensed charting library to display project timelines. Because your users will interact with these charts over the network as part of your service, the AGPL's terms are triggered. The charting library is an integral part of your application. As a result, the source code for your entire project management tool—your proprietary code included—must now be made available under the AGPL. This is the “viral” or reciprocal nature of the license in action. It ensures that the freedom given to you is passed on to your users.

• Software Developers: As a developer, you are on the front lines. Your decision to include an AGPL library in a project can have massive legal and business consequences. Your responsibility is to understand the license and clearly communicate the implications to your manager or client.
• Business Owners & CTOs: For business leaders, the AGPL is a strategic consideration. It is not inherently “anti-business,” but it is anti-proprietary for networked services. You must weigh the benefits of using powerful AGPL software against the business model implication of having to open-source your own value-add code.
• Open Source Project Managers: If you are starting a new open-source project, choosing the AGPL is a deliberate, often philosophical, choice. You are choosing it to ensure that your project's code remains free, even when used by large cloud providers, encouraging them to contribute back rather than creating a closed-source competitor.
• End Users: The AGPL makes you, the end user, the ultimate beneficiary. It grants you the right to see how the services you use work, to fix bugs, add features, and to host your own version if you are unhappy with the provider, ensuring the service cannot be taken away or changed in a way that harms you without recourse.

If you've discovered AGPL code in your project, don't panic. Follow a structured process to ensure you are compliant and can make an informed business decision.

1. Audit your codebase: Use automated tools (like Black Duck, FOSSA, or Snyk) or a manual audit to identify every open-source component and its license.
2. Check dependencies: Remember to check the licenses of not just the libraries you directly import, but also the licenses of *their* dependencies (transitive dependencies).
3. Note the version: Be specific. Is it AGPLv1 or AGPLv3? This matters for compatibility with other licenses like GPLv3.

1. Map user interaction: Create a diagram of your application. Who interacts with it? How?
2. Ask the key question: Will users who are not employees of my company interact with the AGPL-powered component over a network?
3. Segment your services: If the AGPL component is only used in a completely separate, internal-facing microservice, its impact may be contained. If it's in your core monolith web application, the impact is broad.

1. Consult a lawyer: This is the most crucial and legally complex step. The definition of a `derivative_work` in copyright law is nuanced.
2. General guidelines: Dynamically linking to an AGPL library typically creates a derivative work. Communicating with a separate AGPL program over an API *may not*, but this is highly fact-dependent. Your goal is to determine if your code and the AGPL code form a “single, combined program.”

1. If triggered, comply fully: If you determine you are obligated to share your source, don't cut corners.
2. Automate the process: Set up a system where every time you deploy a new version of your application, a corresponding source code bundle is automatically created and uploaded to a public server.
3. Add a prominent link: Place a clear link, such as “Source Code” or “AGPL Source,” in the footer of your web application's user interface.

1. Is there an alternative? Can you achieve the same functionality with a library that has a more permissive license (like MIT or Apache 2.0)?
2. Dual-licensing: If you are the copyright holder of the AGPL code, you can offer it under a different, commercial license to customers who want to use it in a proprietary product. This is a common business model for companies that create AGPL software.

The AGPL is not just a theoretical document; its impact has shaped the strategy of some of the biggest names in the database and infrastructure world.

MongoDB, a popular NoSQL database, was originally licensed under the AGPL. They chose it specifically to prevent cloud providers like Amazon Web Services (AWS) from taking their open-source code, offering it as a paid service, and contributing nothing back to the project. However, MongoDB felt that some cloud providers were finding ways to “comply” with the AGPL without truly contributing back (e.g., by releasing the source code for their management tools but not their core infrastructure). In 2018, MongoDB moved away from the AGPL to a new license they created: the Server Side Public License (SSPL). The SSPL is even more aggressive than the AGPL, explicitly stating that if you offer the database as a service, you must release the source code of all software used to manage that service. This move was highly controversial, with many in the open-source community arguing the SSPL is not a true open-source license. For the average person, this case shows the intense battle between open-source projects and large cloud providers over the value of open-source code.

Google has a well-known internal policy that forbids the use of AGPL-licensed software in any of their products or services. Their reasoning, outlined in their open-source philosophy documentation, centers on the risk associated with the AGPL. They believe the “network interaction” trigger is a strong copyleft provision that presents a greater business risk than the GPL. This is not a legal ruling, but a business decision based on risk tolerance. Google's vast, interconnected infrastructure means that including even one AGPL component could have far-reaching and ambiguous consequences for their proprietary codebase. This stance highlights the corporate world's caution regarding the AGPL's powerful reciprocal obligations and why many large enterprises shy away from it.

The central debate around the AGPL today is the one that led MongoDB to create the SSPL: Is the AGPL strong enough to protect open-source projects from being exploited by hyperscale cloud providers? Proponents argue that the AGPL works as intended, forcing a choice between contributing back or building your own. Opponents argue that its terms are either too ambiguous or not broad enough to cover the full stack of a modern cloud service, allowing providers to comply with the letter, but not the spirit, of the license. This ongoing tension is leading to a new wave of “source available” but not truly “open source” licenses, like the Business Source License (BSL) and the Elastic License, further complicating the landscape.

The AGPL was designed for the web services of the 2000s. New technologies are already testing its limits.

• Artificial Intelligence (AI) and Machine Learning (ML): If an AI model is licensed under the AGPL and you offer it via an API, what constitutes the “Corresponding Source”? Is it just the inference code? Or does it include the massive training dataset and the training code, which is often the most valuable part? The legal system has not yet provided clear answers.
• Internet of Things (IoT): As everyday devices from thermostats to cars become networked, the AGPL could have a major impact. If a car's infotainment system uses modified AGPL code and communicates with the manufacturer's servers, does that trigger a source code release for the car's software?

The AGPL's core principle of ensuring user freedom in a networked world is more relevant than ever, but it will face continuing tests as the very definition of “software” and “network interaction” evolves.

• copyleft: A licensing mechanism that uses copyright_law to ensure that modified versions of a work remain free and open.
• derivative_work: A legal term for a new work based on one or more preexisting works.
• free_software_foundation_(fsf): A non-profit organization founded by Richard Stallman to support the free software movement.
• gnu_general_public_license_(gpl): A widely used free software license that guarantees end users the freedom to run, study, share, and modify the software.
• intellectual_property: A category of property that includes intangible creations of the human intellect, such as copyrights, patents, and trademarks.
• lgpl_(lesser_general_public_license): A “weak copyleft” license that allows proprietary software to link to open-source libraries without needing to be open-sourced itself.
• mit_license: A permissive free software license that places very few restrictions on reuse.
• open_source_license: A license that allows software to be freely used, modified, and shared.
• permissive_license: A type of open-source license with minimal restrictions, such as the MIT or Apache licenses.
• saas_(software_as_a_service): A software licensing and delivery model in which software is licensed on a subscription basis and is centrally hosted.
• source_code: The human-readable version of a computer program, written in a programming language.

• gnu_general_public_license_(gpl)
• open_source_licenses
• copyright_law
• intellectual_property
• mit_license
• apache_license_2.0
• software_licensing_agreements