Short answer: For most teams, using an AGPL-3.0 tool to build your own software does not make your software AGPL—the license covers the tool, not the code you write with it. The obligation that surprises people is the network clause: if you modify the tool and let others use your modified version over a network, you must offer them its source. This is general information, not legal advice; confirm your situation with counsel.
Open-source AI coding platforms increasingly ship under the GNU Affero General Public License v3.0. It is a strong copyleft license, and its reputation makes some engineering leaders nervous about adopting AGPL tools at all. Most of that fear comes from conflating two very different things: using the software, and modifying and redistributing it.
What AGPL-3.0 is—and what makes it different
AGPL-3.0 is the GPL family’s strongest network-era copyleft license. It carries the usual GPLv3 obligations—when you convey (distribute) the software or a modified version, you must provide the corresponding source under the same license—and adds one more trigger.
That addition is Section 13, “Remote Network Interaction.” Per the license text published by the Free Software Foundation, if you modify the program and let users interact with your modified version remotely through a computer network, you must give those users an opportunity to receive the corresponding source of your modified version. This is the network clause, and it is what closes the “SaaS loophole” that ordinary GPL leaves open.
The distinction that resolves most fear
Here is the part teams most often get wrong. Running a program is not the same as creating a derivative of it. Per the FSF’s GNU licenses FAQ, the output of a program is generally not covered by the program’s license unless the output itself contains parts of the program.
In plain terms: if you use an AGPL-3.0 coding platform as a tool to write your own application, your application is yours. The AGPL covers the platform’s source code, not the source code you produce with it. That is the same reasoning explored in who owns AI-generated code—the tool’s license and your output’s ownership are separate questions.
So the practical risk is not “adopting AGPL software will infect our codebase.” It is narrower and more specific: what happens if we modify the tool itself, and how do we distribute or expose that modified version?
When the obligations actually apply
Reasoning from the license text, three broad situations behave very differently. (Again: general information, not legal advice.)
- Internal, unmodified use. You run the tool inside your organization and do not modify or distribute it. This is the lightest case; the network clause is triggered by making a modified version available to outside users.
- You modify the tool. The moment you change the source, the copyleft obligations attach to those changes if and when you convey the modified version or expose it to remote users under Section 13.
- You offer it as a network service. If you host a modified version and let external users interact with it over a network, Section 13 requires you to offer them the corresponding source of your modifications.
The axis that matters is not “internal vs. external”—it is unmodified use vs. modifying-and-exposing.
A practical compliance checklist
- Inventory which AI tools in your stack are AGPL-3.0, including transitive components.
- Separate the tool from your product: confirm your application links to it as an independent service/tool, not by copying its source into yours.
- Track modifications. If you fork or patch an AGPL tool, keep those changes identifiable and under version control.
- Decide exposure. If you might offer a modified version to outside users over a network, plan to publish the corresponding source of your modifications.
- Preserve notices and license files; do not strip attribution or the LICENSE.
- Get a legal review before you rely on any of the above for a commercial deployment. See the direct answers on what AGPL-3.0 means for MonkeyCode and whether it can be used commercially.
Where MonkeyCode fits
MonkeyCode’s repository is licensed under GNU AGPL-3.0, which means the code is auditable and forkable with the obligations above. For most adopters who run it to develop their own software, that is a manageable, well-understood arrangement—the same profile as many open-source infrastructure tools. The license guide lays out the factual overview and the legal-review boundary, and what makes an open-source platform ready for teams covers the operational side of adoption.
Bottom line
AGPL-3.0 is stricter than MIT or Apache-2.0, but for the common case—using the tool to build your own product—it does not touch your code. The one place to be deliberate is modification plus network exposure, where Section 13 requires you to share the source of your changes. Inventory your AGPL tools, keep any modifications identifiable, decide your exposure model early, and have counsel confirm the specifics for your deployment.
Related guides in this series
- What makes an open-source AI coding platform ready for teams
- Who owns AI-generated code? A copyright and IP guide
- Self-hosted AI development platform: an evaluation checklist
Source boundary: AGPL-3.0 obligations are summarized from the license text and the GNU licenses FAQ published by the Free Software Foundation (checked 20 July 2026), interpreted as general educational information. This is not legal advice, and license interpretation depends on your specific facts—consult qualified counsel before relying on it for a commercial deployment. MonkeyCode’s license is stated in its public repository and should be confirmed against the current LICENSE file.