AGPL-3.0 is a strong copyleft license whose network clause can require you to release the source of any application that serves an AGPL-covered model over a network, which is exactly how most computer vision gets deployed. For commercial teams, that turns a model choice into a legal and business risk that permissively licensed models such as Roboflow's RF-DETR avoid.
Most teams choose a vision model on accuracy and speed. License terms get a glance, if that. For computer vision specifically, that order is backwards. The license attached to the model you build on determines whether you can ship your product, whether you can keep your pipeline private, whether your deal survives legal review, and whether an acquirer discounts your company. AGPL-3.0 is the license where those questions go wrong most often.
This article explains what AGPL-3.0 actually requires, why computer vision is unusually exposed to it, the specific ways it creates risk, where it is genuinely fine, and what to use instead.
What AGPL-3.0 Actually Requires
AGPL-3.0 is the GNU Affero General Public License, version 3. It is a strong copyleft license, which means two things matter from the start.
First, reciprocity. If you modify AGPL-covered code or build a work that legally derives from it, your combined work generally has to be licensed under AGPL-3.0 as well, and you have to make the corresponding source available to the people you give the software to. Copyleft is designed to propagate. That is the point of it.
Second, and this is the clause that makes AGPL different from ordinary GPL, the network trigger. Section 13 of AGPL-3.0 closes what is often called the SaaS or ASP loophole. Under a normal GPL license, the obligation to share source is triggered by distributing the software. If you run modified GPL software on your own server and only let users interact with it over a network, you have not distributed anything, so the obligation never fires. AGPL removes that escape. If users interact with your modified AGPL program remotely over a network, you must offer them the corresponding source of your modified version, even though you never shipped them a binary.
In short: with AGPL, running the software as a service counts as the thing that obligates you to open your source. For most software that is a niche concern. For computer vision, it is the main way the technology gets used.
Why Computer Vision Is Unusually Exposed
Three properties of how vision models are built and deployed make AGPL-3.0 a sharper risk than it is for a typical desktop library.
Vision ships as a service. The dominant deployment patterns for computer vision are an inference API, a model served behind an endpoint, or an edge device streaming results to other systems over a network. Every one of those is a user interacting with the software remotely. That is precisely the fact pattern Section 13 is written to catch. The network clause that most software never trips is the default deployment shape for vision.
The derivative-work line is blurry for ML. With a normal application you can reason about whether you have created a derivative work. With machine learning the boundaries are genuinely unsettled, and unsettled means risk. Does your application become a derivative work because it imports and depends on an AGPL-licensed library to run inference? Are model weights produced using AGPL-licensed training code themselves covered? Reasonable engineers and lawyers disagree, and very little of it has been tested in court. When the scope of an obligation is ambiguous and the licensor takes an expansive view, you are the one carrying the uncertainty.
The licensor's interpretation is what bites, not the abstract law. You do not get to pick the most favorable reading of an ambiguous license. The party that holds the copyright does, and they can enforce it. When a vision model is published under AGPL-3.0 and the same vendor sells a separate commercial license to remove the AGPL obligations, that pricing structure tells you how the licensor reads the license: broadly enough that commercial users are expected to pay to get out from under it. The commercial license is the tell. It exists because the AGPL obligations are meant to reach you.
This is the situation for the most widely used YOLO implementations, which are published under AGPL-3.0 with a separate paid commercial license offered alongside. Building on them means either accepting the AGPL obligations or buying your way out.
The clearest example is the Ultralytics YOLO family. Ultralytics publishes its models under AGPL-3.0, code and weights alike, which covers the versions most teams reach for first: YOLOv5, YOLOv8, YOLO11, and YOLO26, along with their pose, segmentation, and oriented-detection variants, and the YOLO-World open-vocabulary models in the same repository. Ultralytics sells a separate commercial license to remove the AGPL obligations, which is the structure described above. AGPL is not unique to Ultralytics, and the broader YOLO landscape is a patchwork worth checking rather than assuming: some other popular detector repositories, including the original YOLOv7 and YOLOv9 code, are GPL-3.0, a related copyleft license that carries source-disclosure obligations of its own even without AGPL's network clause.
The Specific Downfalls of AGPL-3.0
1. You can be forced to open-source your pipeline
The asset in a production vision system is rarely the off-the-shelf model. It is everything around it: your preprocessing, your post-processing logic, your business rules, the integration glue that ties detections to your database and your operations. If a court or a licensor treats that surrounding code as part of an AGPL-covered combined work, the corresponding source you owe can extend to the proprietary pipeline you spent months building. The thing you considered your moat becomes the thing you have to publish.
2. The network clause matches exactly how vision is deployed
For ordinary libraries, the AGPL network clause is theoretical, because most software is not served to users over a network. Vision inverts that. Serving a model through an API, a hosted endpoint, or an edge runtime that other systems query is the standard architecture. The one trigger that makes AGPL stricter than GPL is the trigger your deployment hits by default. You do not have to distribute anything to incur the obligation. You only have to run it as a service, which is the plan.
3. The legal uncertainty is its own cost
Even if you would ultimately win an argument about whether your weights or your application are derivative works, the uncertainty has a price before any dispute. It shows up as legal review cycles, as conservative engineering decisions made to avoid a question no one can answer cleanly, and as a risk you cannot quantify on a balance sheet. Unquantified legal exposure sitting under your core product is exactly the kind of thing that surfaces at the worst time.
4. Many enterprises ban AGPL outright
You may be comfortable with the risk. Your customer's legal department may not be, and they decide whether your software clears review. A large number of enterprises maintain open-source policies that prohibit AGPL-licensed components anywhere in the stack, regardless of how it is used. Google's widely documented internal ban on AGPL is the best-known example, and many corporate OSS policies follow the same line. If AGPL code is in your product, you can fail a security or procurement review for a reason that has nothing to do with whether your product works. The deal dies in legal, not in the eval.
5. It shows up in due diligence and lowers your valuation
Acquirers scan the codebase. Open-source license review is a standard part of technical due diligence, and AGPL is one of the first things flagged. Its presence in a target's stack raises questions about whether proprietary code was obligated to be disclosed, whether the company has been operating in compliance, and what it would cost to rip the dependency out. At best that is remediation work. At worst it is a discount on the price or a reason to walk. A model license chosen for convenience in year one can quietly reduce what your company is worth in year four.
6. The commercial license escape hatch has its own costs
The vendor's answer to all of this is to sell you a commercial license that lifts the AGPL obligations. That is a real option, and for some teams it is the right one. But it converts an apparently free model into a recurring cost, ties you to a single vendor for the right to use the model commercially, and raises the question every subscription raises: what happens to what you built if you stop paying. A capability you depend on in production should not be one invoice away from a usage problem. Permissive licensing does not create that dependency in the first place.
What AGPL Is For
AGPL-3.0 is not a trap, and the people who wrote it were not acting in bad faith. It exists to protect software freedom in the network era. Its purpose is to make sure that improvements to free software stay free even when the software is delivered as a service rather than shipped as a binary, so that companies cannot take a community project, run it as a closed SaaS, and give nothing back. For a project whose authors want every downstream user, including SaaS providers, to share their modifications, AGPL is the correct and principled choice.
There are situations where building on an AGPL model carries no practical risk for you. If your use is internal research with no networked users, if your project is itself open source and you are happy to release your source under AGPL, or if you have bought the commercial license and the cost works for your business, the obligations are either not triggered or fully acceptable.
AGPL is a problem for a specific profile: a commercial team that wants to keep its pipeline proprietary and deploy vision as a networked service. That profile happens to describe most companies putting computer vision into production, which is why the risk is worth taking seriously rather than dismissing.
This is also not legal advice. Whether AGPL obligations attach to your specific architecture is a question for your own counsel, and license terms change over time. The point here is that the risk is real enough, and the ambiguity wide enough, that it belongs in the model decision rather than after it.
The Alternative: Permissive Licensing
The way to avoid all of this is to build on models released under permissive licenses. Apache 2.0, MIT, and BSD impose no copyleft and no source-disclosure obligation, and they let you use, modify, and deploy the software in proprietary, commercial, networked products without inheriting the license. Apache 2.0 goes a step further than MIT and BSD by including an explicit patent grant, which adds a layer of protection against patent claims from contributors. For commercial deployment, permissive licensing removes the entire category of problem this article describes.
This is the reasoning behind how Roboflow licenses RF-DETR, our state-of-the-art real-time detection architecture. The core models and code are released under the Apache 2.0 license, so you can train on your own data, deploy behind your own API or on your own edge hardware, and keep your pipeline private, with no AGPL network clause to trigger and no commercial license to buy back the rights you need. RF-DETR is also faster and more accurate than the current YOLO releases on standard detection benchmarks, so choosing the permissively licensed model is not a tradeoff against performance.
Beyond the model, the broader point is ownership. Roboflow is built so that your data and your models are yours to take anywhere, with first-class support for open formats and export at any time. Commercial-safe licensing is part of the same commitment: the goal is for the legal terms under your vision system to be a non-issue, not a liability you manage.
How to Audit Your Stack
Before you ship, it is worth knowing what licenses your vision pipeline actually depends on. A short checklist:
- Identify the license of every model and every model-serving library in your pipeline, not just the framework you train in. The risk lives in the inference path.
- Flag anything AGPL-3.0, and separately flag GPL-family licenses, which carry their own copyleft obligations even without the network clause.
- Map your deployment. If you serve inference over a network or at the edge, assume the AGPL network clause is in scope for any AGPL component and treat it accordingly.
- For anything flagged, decide deliberately: replace it with a permissively licensed equivalent, buy the commercial license with eyes open, or get written sign-off from your counsel that your specific use does not trigger the obligations.
- Prefer permissive licenses (Apache 2.0, MIT, BSD) for anything you intend to deploy commercially, so the question does not come back at procurement, at audit, or in due diligence.
AGPL-3.0 Conclusion
AGPL-3.0 is a well-designed license doing exactly what it was built to do, which is to keep networked software free. That design is the problem when your goals are the opposite: a proprietary pipeline, a networked deployment, and a clean answer for your customer's legal team. The network clause matches how vision ships, the derivative-work scope for models is unsettled, enterprises ban it, acquirers flag it, and the way out is a recurring license that recreates the dependency you were trying to avoid.
The simplest way to make the whole category of risk disappear is to build on permissively licensed models. RF-DETR is Apache 2.0, commercially safe, and at the top of the accuracy and latency curve, which means you can keep your pipeline private and your deployment open without giving anything up on performance.
This article is general information, not legal advice. For how these terms apply to your specific deployment, consult your own counsel.
Cite this Post
Use the following entry to cite this post in your research:
Contributing Writer. (Mar 10, 2026). Why AGPL-3.0 Is a Risk for Computer Vision Teams. Roboflow Blog: https://blog.roboflow.com/why-agpl-3-0-is-a-risk-for-computer-vision-teams/