AGPL in Commercial Computer Vision: The Ultralytics Question

AGPL in Commercial Computer Vision: The Ultralytics Question
Ultralytics YOLO is AGPL-3.0. For a closed-source product, that license changes everything: your server can be forced to publish its source. Three legitimate exits exist — pay for a commercial license, open-source the product, or move to an Apache-2.0 model — and the decision is cheapest at pilot stage, not after launch. (Standard note: engineering guidance, not legal advice.)
Every commercial computer vision project reaches this fork, usually in the
first week. Someone runs pip install ultralytics, gets a working object
detector in five lines, and the demo sells the project. Then one question
decides whether the product is viable: what license did we just build on?
Why YOLO is the default reach
Ultralytics earned the position. It ships the best onboarding in the detection ecosystem — clean API, pretrained weights for detection, pose, and segmentation, one-line export to ONNX and TensorRT. The documentation actually answers questions.
Half the CV tutorials on the internet assume it. When a team needs a working detector by Friday, Ultralytics is the shortest path. That short path is exactly how it ends up load-bearing in architectures nobody audited.
What AGPL actually triggers
Classic GPL is like a library rule: once you copy the book and hand it out, you owe the original text too. Cloud software dodged that rule for years — you never "hand out" anything, you just serve it over the internet. AGPL closes that gap: letting users reach the software over a network already counts as handing it out.
A CV product is almost always a network service: cameras in, detections out, a dashboard on top. If Ultralytics code runs anywhere in that pipeline, the AGPL position is that your product's source belongs to your users. "We only use it server-side" is not a defense — server-side is exactly what AGPL was written for.
I covered the license tiers in the earlier licensing post. AGPL is the tier where commercial products get burned.
The three compliant options
Option one: buy the Ultralytics commercial license. Legitimate and simple. You pay, the AGPL obligation lifts, you keep the ergonomics. It suits teams already deep in the Ultralytics toolchain. Budget it as a recurring product cost, and archive the agreement where due diligence will find it.
Option two: open-source your product under AGPL. Compliant, but almost always wrong for client work — your deliverable's source becomes public. It fits internal tools and open-core plays, not typical closed products.
Option three: build on Apache-2.0 model families. Detection now has mature permissive alternatives: YOLOX, PP-YOLOE, RT-DETR variants, RF-DETR, D-FINE. Accuracy differences on a fine-tuned, domain-specific dataset are small. Every one of these families reaches production-grade results on typical industrial detection tasks.
What you give up is convenience — more assembly, less polish. What you gain is a stack with no license fee and no network-use trigger. The weights still need their own clearance: code, weights, and datasets are three different contracts.
A product decision, made at the right time
A PPE-compliance detection product I advised — cameras checking whether workers at industrial sites wear helmets and vests — hit exactly this fork. The pilot ran on Ultralytics pretrained weights, as pilots do. The demo is what won the project.
Before production coding began, the team put the license question on the table. They priced the commercial license against the integration cost of an Apache-2.0 family, then switched model families — before fine-tuning, before the training pipeline, before the deployment tooling hardened around one API.
That ordering is the entire lesson. The switch cost one week while the architecture was still soft. Twelve months later — after custom datasets, fine-tuned checkpoints, export scripts, and monitoring all shaped around one stack — the same switch becomes a re-platforming project, negotiated under pressure, with a shipped product in violation the whole time. License decisions do not get cheaper by deferring them. They compound.
Procurement: questions for any CV vendor
The trap also arrives pre-packaged. Analytics boxes, "AI camera" platforms, and NVR add-ons often run Ultralytics inside. Their AGPL exposure becomes yours the moment you integrate and resell.
Before signing, I ask every CV vendor four questions:
- Which detection stack and model family does the product run? "Our proprietary AI" is not an answer. A specific model family and version is.
- If Ultralytics or other AGPL code is inside, show the commercial license. The actual agreement, not an assurance.
- Who owns the fine-tuned weights, and what were they trained on? Dataset terms follow the weights into your product.
- Will you warrant license compliance in the contract? A vendor confident in their stack signs. A vendor who hesitates has answered.
The takeaway
Ultralytics is excellent software with a license that is incompatible with closed-source network products unless you pay. All three exits are legitimate — pay, open up, or build permissive — but only if chosen deliberately, early, and in writing. Decide at pilot stage. Register the decision. The question stays a line item instead of becoming a crisis.
Related Posts
Building something similar?
Hotel Management System Development
Custom ERP-style hotel management software: bookings, room status, invoicing, staff, and WhatsApp automation — built around how your hotel actually runs.
See how I can help