Navigating AGPL:
Strategies for Small Business Success
Navigating AGPL:
Strategies for Small Business Success
Is AGPL a Scam? How Small Companies Can Maximize Benefits While Remaining Compliant
May 3rd, 2024
Why Large Companies Avoid AGPL
The Affero General Public License (AGPL) is notorious for its strict terms, which can be a deterrent for large companies. For instance, Google has explicitly banned the use of AGPL software on its corporate servers due to concerns about the license’s requirement for source code disclosure whenever the software interacts with a network. This policy stems from the risk of inadvertently exposing proprietary software due to the AGPL’s broad scope of application.
Understanding the Differences Between GPL and AGPL
The General Public License (GPL) and the Affero General Public License (AGPL) are both free software licenses, but they address different concerns particularly around network use. The main difference lies in the AGPL’s response to the “network use loophole” present in the GPL. Under the GPL, modifications need to be shared if distributed, but mere use over a network does not count as distribution. The AGPL extends these requirements to network interactions: if you modify AGPL software and run it on a server for others to interact with, the source must be made available to all users.
The Grey Area and Covered Work: The AGPL’s definition of covered work includes not only the program itself but any modifications and additional elements used to interact with it over a network, such as APIs. This is crucial for cloud applications, where even if you do not modify the original source code directly, integrating it into a larger system or application still subjects the entire system—or the “separate project”—to the AGPL. This means that creating new functionalities that interact with the original AGPL-covered software, even if in a separate project, can be considered as creating a derivative work, thereby requiring the distribution of the entire project under the AGPL. This broad scope of “covered work” under the AGPL aims to ensure transparency and freedom of use over networks, but it also poses significant implications for how companies structure and manage their software development.
Strategies to Avoid License Contamination
For companies wishing to use AGPL software without risking their proprietary code, certain strategies can be implemented:
- Separate Projects: Keep AGPL software and proprietary software in separate projects.
- APIs and Command Lines: Interface with AGPL software through APIs or command-line scripts, which can help maintain a boundary between different software components.
- Documentation and Disclaimers: Ensure that all API usage and the separation of the software are well-documented. Include legal disclaimers and user notifications about the use of AGPL software and what it entails.
Understanding Your Obligations
When using AGPL software, you must:
- Provide source code to users interacting with the software remotely through a network.
- Include a copy of the AGPL license and make it clear that the software is licensed under the AGPL.
You are not obligated to:
- Disclose your proprietary source code that is separate and not integrated with the AGPL-covered software in a manner that constitutes a derivative work.
- Provide support to network users of your project if your business model does not include offering professional services.
- Provide the version history of your project; however, you must supply the latest version currently in use.
Conclusion
The AGPL is not a scam but a legal tool that enforces the free use and distribution of software. It is stringent, designed to ensure that freedom and transparency extend to the user of software over a network. For small companies, navigating the complexities of AGPL can be beneficial with the right legal understanding and use strategies, allowing them to use open-source software while protecting their proprietary developments.
