Is YOLO Free for Commercial Products? AGPL-3.0, Enterprise Licences, and the Apache-2.0 Detectors You Can Ship
"It's open source, so we can ship it." That sentence has launched more product roadmaps than it has survived legal review. It is rarely said in bad faith. A team needs an object detector, someone installs a popular package with one command, a demo works in an afternoon, and the model's repository is public, so the licensing question feels answered before it is asked.
The belief to dismantle is that "open source" means "free to include in a closed commercial product." Open source describes a licence family, and the family contains very different terms. Permissive licences such as Apache-2.0 and MIT let you ship the code inside a proprietary product with modest conditions. Copyleft licences, of which the GNU Affero General Public License v3 (AGPL-3.0) is the strongest, attach conditions to the whole work built around the code, and those conditions can include publishing your own source.
The most widely used real-time object-detection family today, Ultralytics YOLO (YOLOv5, YOLOv8, YOLO11, YOLO26 and their siblings), ships under AGPL-3.0, with a paid Enterprise licence for commercial use that does not want to meet AGPL's terms. That single fact is the heart of a procurement and engineering decision that edge-AI teams meet in the middle of a project rather than at the start. This post lays out what the licence says, what it does and does not require, which detectors are available under permissive terms, and how to audit a codebase before the question arrives as a customer's legal questionnaire.
A note on what this is. Nothing here is legal advice. Licence interpretation depends on facts, on jurisdiction, and on how your software is built and delivered. Use this as an engineering briefing to bring to counsel, not a substitute for counsel.
Never choose a model architecture before you know the licence of its code, its pretrained weights, and its training data. Switching later means retraining, retesting, and re-certifying; reading a licence first takes an hour.
What the Belief Gets Right
Plenty of people are correct about open source in general. Large parts of any embedded stack are permissively licensed: the RTOS, the TCP/IP stack, the crypto library, the build system. You can ship those inside a closed product by respecting a short list of conditions: keep the copyright notice, reproduce the licence text, and in Apache-2.0's case, note changes and honour the patent grant.
Detectors trained from research code are often in that same permissive territory. Several well-known detection models carry Apache-2.0 terms, as the table below shows. The mistake is treating the most visible family as representative of all of them.
Code licence, weights licence and training-data terms are three separate questions.
What AGPL-3.0 Actually Asks
The AGPL-3.0 is a "strong copyleft" licence. Its two most important features for product teams are these.
First, the copyleft condition. If you convey a work based on AGPL-licensed software, you must make the complete corresponding source of that work available to recipients under the same licence. "Based on" is the operative phrase, and what counts as a single work, as opposed to separate programs that merely communicate with each other, is exactly the kind of question where lawyers earn their fees. A product that statically links or embeds the AGPL code in one program is the clear-cut case. A separate process that communicates over a documented interface raises different questions that depend on the details.
Second, the network clause. The ordinary GPL is triggered by distributing software. The AGPL adds a condition for software that users interact with over a network: if you modify the program and let users interact with it remotely, you must offer those users the source of your modified version. This closes the "software as a service" gap that the ordinary GPL left open. For a vision product delivered as a cloud API, the usual instinct ("we never distribute the code, so we are fine") does not hold under AGPL if the code is modified and users interact with it over the network.
Ultralytics describes its licensing in two options on its own site: AGPL-3.0, which it positions for students, researchers, and enthusiasts, and an Enterprise licence for commercial use that does not want to open-source the project. Its licence page adds three statements that matter. If you use Ultralytics code, models, architectures, training pipelines, or trained or fine-tuned models, you must either obtain an Enterprise licence or comply with AGPL (using YOLO only internally or for research is a separate case). All trained models fall under AGPL-3.0 by default. And an Enterprise licence covers the company's full portfolio during its term, including newer model releases.
Notice what that third group of statements implies for an embedded product. Your own fine-tuned model weights are covered too. Training a detector on your proprietary dataset using the framework does not move the resulting weights outside the licence's reach; under the vendor's stated position, the fine-tuned model is itself an AGPL-covered artefact unless you hold an Enterprise licence.
Where Teams Get Caught
Four scenarios account for most licence surprises in edge vision products.
Scenario one: the embedded camera product. A smart camera ships with a detector in its firmware image. Shipping the device conveys the software to the customer. If the detector code or weights are AGPL-covered and no Enterprise licence exists, the distribution triggers the licence's source-offer obligations for the work as a whole. The firmware, the application, and potentially the proprietary pre- and post-processing are all inside the argument.
Scenario two: the cloud API. A company runs the detector on a server and exposes it through a REST endpoint. No code is shipped to customers. Under the ordinary GPL this would sit outside the copyleft; under AGPL, the network-interaction clause applies when the software has been modified and users interact with it remotely. "We only run it ourselves" is not a safe assumption.
Scenario three: the research prototype that became a product. The demo was built with the framework "for a quick proof of concept." Six months later, the prototype's pipeline is the product's pipeline, and nobody recorded the licence at the start. This is the commonest scenario, and the most expensive, because the model is already trained, validated, and wired into the deployment.
Scenario four: the customer's legal review. A large enterprise or government buyer sends a software composition questionnaire. Their legal team's scanner flags AGPL in the dependency tree. The deal pauses until someone explains the position. That conversation is much easier with a prepared licence inventory than without one.
Which Detectors Can You Ship Under Permissive Terms?
Several mature detector families are available under Apache-2.0 or similar permissive licences. Licence status changes, and individual model variants can differ from their parent repository, so verify the exact code and weights you plan to use at the time you commit. The table reflects publicly reported licence information as of October 2026.
Model family | Maintainer | Code licence (reported) | Notes for commercial shipping |
Ultralytics YOLOv5, v8, YOLO11, YOLO12, YOLO26 | Ultralytics | AGPL-3.0, with a paid Enterprise licence | Trained and fine-tuned models are covered by default |
YOLOv10 | Tsinghua University group | AGPL-3.0 (reported) | Same considerations as the Ultralytics line |
YOLOX | Megvii | Apache-2.0 | Anchor-free real-time detector; older but proven; ONNX export tooling in the repository |
PP-YOLOE / PP-YOLO | Baidu PaddleDetection | Apache-2.0 | Part of the PaddlePaddle ecosystem |
DAMO-YOLO | Alibaba | Apache-2.0 | Efficient real-time detector |
RT-DETR (several versions) | Baidu and community | Apache-2.0 | Transformer-based detector with no non-maximum suppression step |
D-FINE and related DETR variants | Research groups | Apache-2.0 (reported) | Strong accuracy; check deployment tooling for your target |
RF-DETR | Roboflow | Apache-2.0 for the Nano, Small, Medium, and Large models; the largest variants use a separate licence | Published at ICLR 2026; verify which size you deploy |
YOLO-NAS | Deci / NVIDIA | Code under Apache-2.0, but pretrained weights under a non-commercial licence | A good example of code and weights carrying different terms |
LibreYOLO | Community project | MIT (reported) | A permissively licensed reimplementation of the YOLO family; evaluate maturity before depending on it |
Two lessons sit in that table. Code licence and weights licence are separate questions. YOLO-NAS is the cautionary example, with permissive code and weights that forbid commercial use. And permissive does not mean equal: accuracy, latency, and support for your edge accelerator's compiler vary considerably, and an architecture that quantises well on one toolchain may fall back to the CPU on another.
The Hidden Third Licence: The Training Data
A model's licence tells you what you may do with the code and the weights. It does not tell you what you may do with the data they were trained on. Pretrained detectors are typically trained on public datasets whose terms differ. Some dataset annotations are released under attribution licences while the underlying images come from many sources with their own rights; others restrict commercial use outright. For a commercial product, two practices reduce exposure:
Fine-tune on data you own or have clear rights to, and keep a record of provenance for each image source.
Check the pretrained weights' own documentation for training-data disclosures, and record what you find. If your legal team asks "what was this trained on," "a public dataset" is not an answer.
Many companies find that the cleanest position is a model trained mainly on their own data, starting from permissively licensed code, with the pretraining question documented and judged acceptable by counsel.
A scanner reads declared metadata. It cannot see copied code or weights downloaded at runtime.
A Licence Audit You Can Automate
The cheapest defence against licence surprises is a CI check that fails the build when a copyleft dependency appears in a product that should not contain one. For Python-based training and inference pipelines, the open-source pip-licenses tool lists every installed package with its declared licence:
# List licences of everything installed in the environment
pip install pip-licenses
pip-licenses --format=markdown --with-urls --order=license > LICENSES.md
# Fail the build if any AGPL package is present
pip-licenses --fail-on="GNU Affero General Public License v3 (AGPLv3)" \
--partial-match
For a container image or firmware root filesystem, scan the whole artefact rather than just the Python environment:
# Scan an image or directory and emit an SBOM with licence data
syft ./edge-vision-image.tar -o cyclonedx-json=sbom.cdx.json
# Query the SBOM for copyleft licences using jq
jq -r '.components[] | select(.licenses[]?.license.id | test("AGPL|GPL")) |
"\(.name) \(.version) \(.licenses[0].license.id)"' sbom.cdx.json
Treat automated scanning as a first filter, not a verdict. Scanners read declared metadata. They do not catch code copied into your tree, models downloaded at runtime from a model hub, or weights shipped as separate files with a licence in a README. Add a second layer: a hand-maintained third_party.yaml that lists every model, with its source, version, licence, and the date someone read the licence text.
# third_party.yaml -- model register (one entry per model shipped or used)
- name: detector-v3
family: RT-DETR
code_license: Apache-2.0
weights_origin: "trained in-house from scratch on proprietary dataset ds-2026-04"
weights_license: proprietary
training_data: "internal captures; provenance log: data/PROVENANCE.md"
reviewed_by: legal-contact
reviewed_on: 2026-10-12
Migrating Off an AGPL Detector Without Losing Six Months
Teams that discover the issue late want to know how costly a switch is. The answer depends on where the model sits in the pipeline, and a staged approach limits the damage.
Step 1, freeze the evaluation. Before touching the model, lock your validation set and metrics, including per-class precision and recall and latency on the target device. The replacement is judged against this baseline, and you cannot judge it without one.
Step 2, choose two candidates. Select two permissively licensed detectors with good export support for your target accelerator, for example an Apache-2.0 anchor-free detector and a transformer-based one. Check each against the target compiler's supported-operator list before training, because the largest rework risk is a model that does not compile cleanly on the edge device.
Step 3, retrain on the same data. Use identical splits, comparable augmentation, and matched input resolution. Expect different accuracy profiles: some architectures trade small-object recall for speed.
Step 4, export and quantise. For example, YOLOX exports to ONNX through the tooling in its repository:
# YOLOX: export a trained checkpoint to ONNX (run from the YOLOX repository)
python3 tools/export_onnx.py --output-name detector.onnx \
-n yolox-s -c yolox_s_custom.pth --opset 13 --no-onnxsim
Then apply the quantisation flow of your accelerator's compiler using a representative calibration set drawn from the field, not the training set.
Step 5, compare on the device. Measure accuracy, latency, power, and memory on real hardware under the conditions that matter. Record the comparison against the baseline and decide.
Step 6, plan the cut-over. Ship the replacement behind a configuration flag, run both in shadow mode for a period on a subset of devices, and compare their outputs in the field before retiring the old model.
A realistic effort for a mature vision pipeline is weeks, not days, and most of the time goes into calibration data, quantisation tuning, and field validation, not into the architecture swap itself.
What "Based On" Means in Practice: A Map of Integration Patterns
Counsel will ask how the detector is connected to the rest of your product, because the answer shapes the analysis. Engineers can prepare by drawing the actual architecture and labelling each boundary. The table lists the patterns that come up most in edge vision products, with the question each one raises. It is a way to organise the conversation, not a ruling on any pattern.
Integration pattern | What it looks like | Question to put to counsel |
Single binary or firmware image | Detector code linked into the same program as your proprietary application | Does the combined program count as one covered work, and what must be offered to recipients? |
Python application importing the package | Your inference service imports the framework as a library | Is the application a work based on the library, and does remote user interaction trigger the network clause? |
Separate process, documented interface | Detector runs in its own process; your application calls it over sockets or a message bus | Are these separate programs communicating at arm's length, and how is the interface designed? |
Separate container or service | Detector deployed as an independent service behind an API | Same question, plus how the network clause applies if you modified the service |
Training only, export to another runtime | Framework used to train; exported weights run in a different, permissively licensed runtime | Are the exported weights themselves covered by the licence, as the vendor states for trained models? |
Model as a customer-supplied file | Customers bring their own weights | Who is the licensee and distributor in that arrangement? |
The last two rows are the ones teams most often assume are safe. Training with a framework and exporting weights to another runtime does not by itself resolve the question when the weights are stated to be covered by the same licence, which is why the vendor's own position on trained models deserves a careful reading before any architectural workaround is designed.
Architectural cleverness is a weak substitute for a licence. Splitting a product into processes to avoid a copyleft condition is a legal strategy that needs a lawyer's sign-off, and a commercial product should not depend on an interpretation nobody has tested.
What an Enterprise Licence Should Cover
If the business decides to buy, the negotiation deserves engineering input, because the licence terms constrain how the product can evolve. Points to settle before signing:
Scope of the licence. Is it per company, per product, per deployed device, or per seat? A per-device model changes the unit economics of a camera shipping in thousands.
Which artefacts it covers. Code, pretrained weights, fine-tuned weights, and future model releases during the term. The vendor's statements describe some of this, and the contract should say it explicitly.
Delivery models. Embedded devices, hosted services, and on-premises customer installations can be priced and permitted separately.
Sublicensing and customer rights. Can your customers run the software on their own infrastructure? Can an integrator you work with use it?
Term and exit. What happens to shipped devices and fine-tuned models when the term ends or the vendor changes its terms? A product with a ten-year field life needs an answer, because the licence outlives the invoice.
Indemnification and warranty. Whether the vendor stands behind the provenance of the code and weights.
Audit rights. What the vendor can ask to inspect, and with what notice.
A licence that fits a prototype's volume may not fit the volume the product reaches in year three. Model the price at the volume you plan to reach, not the volume you ship at the pilot.
Comparing Candidate Detectors Fairly
When migrating, teams often compare candidates informally and pick the one that "felt good" in a demo. A short, disciplined protocol takes a day and prevents a month of regret.
Fix four things for every candidate: the same validation set, the same input resolution, the same post-processing thresholds (or thresholds tuned per model on a separate tuning split, not on the validation set), and the same target hardware. Then report a consistent set of numbers:
Measure | Why it matters |
mAP at IoU 0.5:0.95 and AP at 0.5 | Overall quality; the strict and the lenient view |
Per-class AP, and AP for small objects | Aggregate scores hide the classes your product depends on |
Latency at p50 and p95 on the target device | Average latency hides the tail that causes dropped frames |
Power during sustained inference | Thermal and battery budget |
Peak memory | Whether it fits alongside the rest of the application |
Accuracy change after INT8 quantisation | Some architectures lose far more than others |
Latency measurements need discipline. Warm up the device, discard initial runs, and report percentiles over a long run:
# latency_bench.py -- measure p50/p95/p99 latency on the target device
import time, statistics
def bench(infer_fn, sample, warmup=50, runs=1000):
for _ in range(warmup):
infer_fn(sample) # discard: caches, clocks, JIT settle
times = []
for _ in range(runs):
t0 = time.perf_counter()
infer_fn(sample)
times.append((time.perf_counter() - t0) * 1000.0)
times.sort()
pct = lambda p: times[int(p / 100.0 * (len(times) - 1))]
return {"p50_ms": pct(50), "p95_ms": pct(95), "p99_ms": pct(99),
"mean_ms": statistics.fmean(times), "n": len(times)}
Run it on the real device at its operating temperature, with the same pre- and post-processing the product uses. A benchmark on a development workstation tells you little about an edge accelerator behind a thermal-throttling enclosure. Make the decision on the table, with the licence column included, and archive the table with the model register.
A Canteen Camera and a Questionnaire
A representative composite, genericised: a team builds an edge camera for monitoring food-counter activity in institutional canteens. The prototype used a popular AGPL detector and trained a custom model on several thousand labelled frames. The product ships as a small edge computer running inference locally and a cloud dashboard.
Three weeks before a pilot with a large institutional customer, the customer's procurement team sends a software composition questionnaire. The team's scanner flags the AGPL dependency in the device image. The team now has to choose among three options, each with a price.
Option one: buy an Enterprise licence from the framework's vendor. That is a legitimate commercial route, and it is the fastest way to remove the AGPL question if the cost works for the product's margins and the vendor's terms fit the deployment. Option two: comply with AGPL by publishing the complete corresponding source of the device software and dashboard. That is unattractive for a proprietary product and is a commercial and strategic decision, not just an engineering one. Option three: migrate to a permissively licensed detector.
The team costs all three honestly. The licence fee has to be set against the per-unit margin and projected volume. Publishing the source conflicts with the product's differentiation. The migration takes about five weeks, including recalibration of confidence thresholds, because the replacement detector has a different score distribution. They choose migration, using an Apache-2.0 transformer-based detector retrained on their own data. Accuracy on their validation set comes within a point of the original on the main classes and trails on very small objects, which the camera mounting height makes rare. Latency on the edge accelerator is comparable. The customer's questionnaire is answered with a clean model register and a scan report.
The lesson the team writes into its engineering process is simpler than the story: the licence of every model is recorded on the day it is first used, not on the day a customer asks.
When AGPL Is the Right Answer
Choosing against an AGPL detector is not a universal rule.
Research, education, and internal tools. The vendor itself positions AGPL for non-commercial and open-collaboration uses. If your output is internal analytics that never reaches customers, and counsel agrees the use is internal, the position is simpler.
Products you intend to open-source anyway. A company building an open platform may be comfortable publishing its source, and AGPL then costs nothing.
When the Enterprise licence is cheap relative to margin and migration cost. For a product with high margins and low volume, paying the vendor can be the sensible engineering choice, because the family's tooling, export paths, and community support are strong. Buying is a reasonable business decision when it is made deliberately.
Prototyping. Using an AGPL tool to explore feasibility is fine as long as the prototype is not quietly promoted to production.
The failure mode is never the choice. It is the absence of one, a codebase where nobody remembers deciding.
Starting on Monday
Inventory every model. List every neural network in every product: detectors, classifiers, embeddings, speech models. Include models downloaded at runtime.
Record three licences per model: the code, the weights, and the training data's terms.
Run an automated scan on every build artefact and fail CI on unexpected copyleft licences.
Create the model register (third_party.yaml or equivalent), with a named reviewer and a review date for every entry.
Classify each product's delivery model: embedded in a shipped device, run as a hosted service, or internal-only. The licence obligations differ across these.
Take the flagged items to counsel with the register and the delivery models. Ask specific questions, not "are we safe?"
For flagged models, pick a path (buy, comply, or migrate) and put a date on the decision.
Add the licence check to the model-selection process, so that a new architecture cannot enter the training pipeline without an entry in the register.
The Hour That Saves the Quarter
The usual story ends with a migration squeezed into a few weeks before a deadline. The better version of the story involves an hour on day one: open the licence, read the section on commercial use, write the answer in the register. Open source is one of the great accelerants in edge AI, and permissive licences carry most of it. The AGPL detector everyone has heard of is a useful tool with a clear price of admission, and the price is worth knowing before you build on it.
EurthTech is an engineering-first product design and embedded systems company with a development center in Hyderabad. To discuss a project, write to connect@eurthtech.com or see https://www.eurthtech.com/case-studies.
Comments