What It Takes to Use a YOLO Model Legally in a Commercial Product

· Savant Team
What It Takes to Use a YOLO Model Legally in a Commercial Product

YOLO (“You Only Look Once”) is the most widely deployed family of real-time object detectors in industry. It is also one of the most frequently misused from a licensing standpoint, because “YOLO” is a brand and an architecture lineage — not a single piece of software with a single license. Different YOLO releases ship under wildly different terms, ranging from fully permissive (do anything, including closed-source commercial products) to strong network copyleft (you may have to open-source your entire application) to weights that are flatly prohibited for commercial use.

This article lays out, fact by fact, what actually determines whether you can legally ship a YOLO model in a commercial product: how licenses work, what is and isn’t protected by copyright, which YOLO flavors are safe, which are traps, and how to build a clean detector you fully own. Every license claim below was checked against the project’s own LICENSE file or official documentation, and the primary sources are listed at the end.

Not legal advice. This is an engineering-and-business briefing based on published license texts. License terms change, and your specific deployment (on-device vs. SaaS, distribution model, jurisdiction) changes the analysis. Confirm anything material with a qualified IP attorney before shipping.

1. Restrictive vs. permissive licenses: the only distinction that decides your risk

Open-source licenses split into two broad camps, and which camp your YOLO falls into is the single most important fact about it.

Permissive licenses — MIT, BSD (2- and 3-clause), and Apache 2.0 — let you use, modify, and redistribute the code inside a closed-source, proprietary, commercial product. You keep your modifications private. The obligations are light: preserve the copyright notice and license text, and (for Apache 2.0) reproduce the NOTICE file and note any files you changed. Apache 2.0 additionally grants you an explicit, royalty-free patent license from contributors and includes a patent-retaliation clause — which is why it is the preferred permissive license for serious commercial ML work. Nothing in any of these licenses forces you to publish your own code.

Copyleft / restrictive licenses — GPL-3.0 and AGPL-3.0 — are the opposite. They are designed to keep derivative works open. Under GPL-3.0, if you distribute (“convey”) a product that incorporates GPL code, you must release the complete corresponding source of the entire derivative work under GPL-3.0. That includes your modifications and the surrounding application code that is combined with it. AGPL-3.0 goes one step further and closes the so-called “SaaS loophole”: its Section 13 (“Remote Network Interaction”) states that if users interact with your modified program over a network, you must offer them the corresponding source — even though you never shipped them a binary. In other words, with AGPL you can trigger the source-disclosure obligation simply by running the model behind an API. (LGPL is a third, “weak copyleft” category — it permits linking from proprietary code — but it is essentially absent from the YOLO ecosystem, so it does not come up in practice.)

For a commercial product the practical rule is blunt: permissive = safe to embed and keep closed; GPL/AGPL = either open-source your product or buy a commercial license to escape the copyleft.

A persistent source of confusion is whether the architecture of a model — its design, the arrangement of layers, the math described in the research paper — is itself something you can be sued over. For copyright, the answer is essentially no, and that fact is the foundation of the entire “build your own” strategy in Section 6.

Copyright protects a particular expression — the actual source code text someone wrote — not the underlying idea, procedure, method, system, or mathematical concept it expresses. This is a bedrock principle of copyright law (in the U.S. it is codified at 17 U.S.C. § 102(b)). A neural-network architecture is, for these purposes, a method and a set of mathematical relationships. The paper describing YOLOX or RT-DETR is copyrighted as a piece of writing, but the architecture it teaches is an idea you are free to implement yourself. This is exactly why MIT-licensed re-implementations of otherwise GPL-licensed YOLO versions can legally exist (see YOLOv9 below): a developer who writes new code from the published description, without copying the original repository’s code, owns that new code and may license it however they like. This technique is known as clean-room implementation, and it is a recognized defense against copyright-infringement claims precisely because functional behavior and ideas are not copyrightable.

Two important caveats keep this from being a free-for-all:

First, patents are a separate regime. Clean-room reimplementation defends against copyright claims; it is not a defense against patent infringement. If a specific technique inside a model is covered by a granted patent, independently reinventing it does not help you — you can still infringe. Algorithms in the abstract are generally not patentable, but a deep-learning method tied to a concrete technical application can be. In practice, patent exposure across mainstream object detectors has been low, but it is a real, distinct risk that copyright analysis does not address.

Second, trademarks. “YOLO” and specific version names are associated with their owners (Ultralytics actively brands its YOLO line). You can implement an architecture, but you should be careful about naming your product in a way that implies endorsement or origin you don’t have.

The bottom line: the architecture is the part you are most free to reuse. The legal risk almost always lives in the code and the weights you actually download — not in the design itself.

3. Model repository / SDK licensing: the license that actually binds you

Because architectures aren’t copyrightable but code is, the license that governs your real-world obligations is the one attached to the repository, SDK, and pretrained weights you download and run. That bundle is concrete, authored expression, and its license controls.

This distinction matters enormously for the Ultralytics line (YOLOv5, YOLOv8, YOLO11, and newer). Ultralytics releases its repository under AGPL-3.0, and — this is the part teams miss — it treats the AGPL as covering not just the training code but the trained models/weights produced with that code. Per Ultralytics’ own licensing materials, models trained with their software fall under AGPL-3.0 by default, and compliance means publishing the complete corresponding source of the larger application that uses them. Run such a model behind an API and AGPL Section 13 can require you to release your service’s source. Ultralytics’ answer is a paid Enterprise License that removes the copyleft obligations and lets you embed the code and models in a proprietary product. (If you do license it and want to run it efficiently in a pipeline, see our guide on preparing an Ultralytics model for use in Savant.)

So even though “the YOLOv8 architecture” is free as an idea, the YOLOv8 repository and its weights are not free for closed-source commercial use. When you evaluate any YOLO, look at three things, in order: (1) the license on the repository/SDK code, (2) the license on the pretrained weights (sometimes different and stricter than the code — see YOLO-NAS), and (3) the license on the training data behind those weights (Section 6).

Why restrictive code licensing is usually all the leverage a vendor needs

Here is the part that surprises people: a vendor does not need to win the unsettled legal argument about whether trained weights are copyrightable, and the freedom of the architecture does not actually help you escape. Copyleft on the training and inference code alone is, in practice, sufficient leverage to gate commercial use. There are several concrete reasons, and they compound.

Weights are inert without the code that runs them. A .pt checkpoint is just a blob of tensors. To get a prediction out of it you need the matching model definition (so tensor names and shapes line up), the forward pass, and — critically — the surrounding pipeline: image letterboxing and resizing, normalization, anchor/stride decoding, non-maximum suppression, and class-map handling. That pipeline is the vendor’s repository. So even where the weights’ copyright status is murky, you cannot actually use the weights without executing copyrighted code — and the moment you import or link that code, the copyleft obligation attaches. The vendor therefore sidesteps the hard legal question entirely and anchors on the one asset whose copyright is unambiguous: the source code.

Correctness lives in the reference implementation. YOLO accuracy is sensitive to getting the pre- and post-processing exactly right — the wrong resize, normalization, or NMS threshold silently degrades detection quality without throwing an error. The vendor’s code is the source of truth for those details, and matching it precisely from scratch is real, error-prone engineering. This is why teams reach for the official repo even when they know it is AGPL: it works correctly out of the box. The license rides along on that correctness.

Convenience is the actual product, and it is copyrighted. What companies adopt is not “the YOLO idea” — it is pip install, a one-line training call, built-in augmentation, export to ONNX/TensorRT/CoreML, tracking, and documentation. That polished, maintained tooling is the moat, and all of it is plainly copyrightable code. Restrictive licensing on the tooling means: use our convenience and accept copyleft, or pay to remove it. The free architecture buys you nothing until you do the substantial work of rebuilding the tooling yourself.

The breadth and uncertainty of “derivative work” is itself the lever. Copyleft reaches code that is combined with or links to the licensed code, and AGPL Section 13 extends that to network interaction. Whether your inference microservice is a “derivative work” of the imported package is exactly the kind of question companies do not want to litigate. Risk-averse buyers resolve that uncertainty by purchasing the commercial license — which is the outcome the vendor is selling. The ambiguity is not a bug in the strategy; it is the strategy.

Export formats do not cleanly launder it. Converting to ONNX or TensorRT does not obviously sever the chain: you used the vendor’s exporter (their code) to produce the artifact, the weights were trained by their code, and you typically still reimplement or copy their pre/post-processing to run it. Vendors generally take the position that the exported model remains a derivative work, and most buyers are unwilling to bet a product on the contrary.

Diligence reality makes the threat credible. An AGPL/GPL dependency in the tree is a standard red flag in security reviews and especially in M&A and investor due diligence. The mere presence of the ultralytics package in requirements.txt can stall a deal. For most companies the cost of that uncertainty vastly exceeds the price of an Enterprise License, so they pay. This is the same dual-licensing / open-core playbook used historically by MySQL and Qt: copyleft is chosen not out of devotion to software freedom but because it is the mechanism that converts free users into paying customers — and AGPL specifically is chosen to close the SaaS escape hatch that plain GPL left open.

The takeaway for builders: do not assume “the weights might not be copyrightable” or “the architecture is free” gives you a usable loophole. As long as you run the vendor’s code to train, infer, or export, the code license governs you. Escaping it requires genuinely not using that code — i.e., the clean permissive stack and clean-room approach in Section 7 — not clever theories about weights.

4. YOLO flavors with permissive licenses (commercial-friendly)

These are the versions you can build into a closed-source commercial product with only light attribution obligations. All were confirmed against the projects’ own license files.

YOLOX (Megvii) — Apache 2.0. An anchor-free detector released in 2021, copyright Megvii Inc. The repository and its code are Apache-2.0 licensed, so you can modify it, keep your changes private, and ship it commercially while preserving the notice file. This is the cleanest “drop-in modern YOLO” for commercial use.

PP-YOLO / PP-YOLOE (Baidu, in PaddleDetection) — Apache 2.0. The entire PaddleDetection toolkit, which houses the PP-YOLO family, is Apache-2.0. Strong industrial-grade option if you can work in the PaddlePaddle ecosystem (or export to ONNX).

DAMO-YOLO (Alibaba) — Apache 2.0. Confirmed directly from the repository’s LICENSE (Copyright 2022–2023 Alibaba Group Holding Limited). Includes NAS backbones and modern detection techniques, fully usable commercially.

RT-DETR (Baidu / lyuwenyu) — Apache 2.0. Confirmed from the official repository LICENSE. Strictly speaking a real-time DETR (transformer) rather than a YOLO, but it is the most common permissively licensed “YOLO-beating” real-time detector and a frequent commercial substitute.

Original Darknet YOLO (v1–v4) — permissive / public-domain-style. Joseph Redmon’s original Darknet (YOLOv1–v3) and Alexey Bochkovskiy’s Darknet fork (YOLOv4) carry an informal, all-permissive notice rather than a standard OSI license. They are effectively free for any use, but because the license text is non-standard, many companies treat it cautiously and prefer a clearly-labeled Apache/MIT option for audit purposes.

MIT re-implementations of GPL versions — for example, MultimediaTechLab/YOLO, which provides an MIT-licensed implementation of YOLOv9, YOLOv7, and YOLO-RD. These exist precisely because the architecture is not copyrightable (Section 2): the authors rebuilt the models under MIT. If you want a recent YOLOv7/v9-class architecture without GPL strings, a clean MIT re-implementation is the path — but verify the weights it ships are also MIT and not derived from the GPL originals.

5. YOLO flavors with restrictive and commercial licenses (handle with care)

These versions either force copyleft on your product or restrict the weights outright. Using them in a closed commercial product without a separate license is the most common way teams get into trouble.

Ultralytics YOLOv5, YOLOv8, YOLO11, YOLO12, and newer — AGPL-3.0 + paid Enterprise License. This is the dominant, best-documented, easiest-to-use YOLO line — and the most legally loaded. AGPL covers the code and the trained weights, and applies even to network/SaaS deployments. To ship inside a proprietary product or service, you need the commercial Enterprise License from Ultralytics. (Note: YOLOv12 is AGPL-3.0; despite the name it is built in the Ultralytics framework. YOLOv10, from Tsinghua’s THU-MIG, is also AGPL-3.0 — confirmed from its repository LICENSE — because it was built on top of the Ultralytics package.)

YOLOv6 (Meituan) — GPL-3.0. Confirmed from the repository LICENSE (GNU GPL v3). You can use it commercially only if you are willing to release your derivative work’s complete source under GPL-3.0 when you distribute it; there is no official commercial-relicensing program. For most proprietary products this is a non-starter.

YOLOv7 (WongKinYiu) — GPL-3.0. Same constraint as YOLOv6: copyleft on distribution, no closed-source path without rewriting.

YOLOv9 (WongKinYiu) — GPL-3.0. The original release was initially unlicensed and later set to GPL-3.0. If you need YOLOv9-class accuracy in a closed product, use a clean MIT re-implementation (Section 4) rather than this repository.

YOLO-NAS (Deci, in SuperGradients) — split license, and the trap is the weights. The SuperGradients framework code is Apache-2.0, but the official YOLO-NAS pretrained weights are released under a separate non-commercial license that prohibits production/commercial use and even bars modifying or reverse-engineering the weights without Deci’s written consent. So “the code is Apache” is true and misleading: you cannot ship Deci’s pretrained YOLO-NAS weights commercially. (Deci was acquired by NVIDIA in 2024 and the repo is no longer actively maintained.) The only commercial path is to train YOLO-NAS weights yourself on data you have rights to, never using Deci’s released weights.

Quick-reference license table

YOLO flavor Maintainer License (verified) Closed-source commercial use?
YOLOv1–v3 (Darknet) J. Redmon Permissive / public-domain-style Yes (non-standard notice — audit)
YOLOv4 (Darknet) A. Bochkovskiy Permissive (“all-permissive”) Yes (non-standard notice — audit)
YOLOv5 / v8 / v11 / v12 Ultralytics AGPL-3.0 (+ Enterprise) No — buy Enterprise License
YOLOv6 Meituan GPL-3.0 No (unless you open-source)
YOLOv7 WongKinYiu GPL-3.0 No (unless you open-source)
YOLOv9 WongKinYiu GPL-3.0 No (use MIT re-impl instead)
YOLOv9 (re-impl) MultimediaTechLab MIT Yes
YOLOv10 THU-MIG (Tsinghua) AGPL-3.0 No — buy Enterprise License
YOLOX Megvii Apache 2.0 Yes
PP-YOLO / PP-YOLOE Baidu (PaddleDetection) Apache 2.0 Yes
DAMO-YOLO Alibaba Apache 2.0 Yes
RT-DETR Baidu / lyuwenyu Apache 2.0 Yes
YOLO-NAS Deci / NVIDIA Code Apache 2.0; weights non-commercial No (weights blocked)

6. The often-forgotten layer: pretrained weights and training data

Even a permissively licensed codebase can hand you a problem through its weights and the data they were trained on.

Pretrained weights inherit the license the distributor attaches. Ultralytics’ weights are AGPL; Deci’s YOLO-NAS weights are non-commercial; Apache-licensed repos’ weights are generally Apache. Always check the weights’ license separately from the code’s.

Training data is the sleeper risk. The near-universal benchmark, COCO, is split: its annotations are licensed CC-BY-4.0 (fine for commercial use with attribution), but the images are governed by Flickr terms and the original per-image licenses, some of which are non-commercial (Attribution-NonCommercial). The COCO consortium does not own the image copyrights. As a result, a model’s weights that were trained on COCO sit on legally mixed ground for commercial deployment, even if the architecture and code are clean. ImageNet similarly grants access for non-commercial research, not blanket commercial rights. The clean approach for a commercial product is to train (or at least fine-tune) on data you own or on datasets with clear commercial licenses (e.g., Open Images, which is CC-BY for annotations with per-image licenses to check), and to treat COCO/ImageNet weights as fine for research and benchmarking but to be replaced for production.

7. How to “cook” your own commercially clean YOLO

You can assemble a modern detector that you fully own, ship closed-source, and never owe royalties on. The strategy follows directly from the facts above: architectures are free ideas (Section 2); only code, weights, and data carry obligations (Sections 3, 6). So you reimplement the architecture from papers, build it on permissive tooling, and train on data you have rights to.

A proven, fact-based recipe:

  1. Pick an architecture from the published literature, not from a GPL repo. YOLOX, RT-DETR, DAMO-YOLO, and the various YOLO papers are all described in detail in their arXiv papers. The paper teaches the design; you owe nothing for using the idea.

  2. Start from a permissively licensed base, or clean-room the rest. The cleanest shortcut is to fork an already-permissive repo — YOLOX (Apache 2.0), RT-DETR (Apache 2.0), DAMO-YOLO (Apache 2.0), or PP-YOLOE (Apache 2.0) — which you are explicitly allowed to use commercially. If you want a feature from a GPL/AGPL version, reimplement it from the paper without copying that repository’s code; do not paste GPL/AGPL source into your tree.

  3. Build on a permissive deep-learning stack. All of the core tooling is permissive: PyTorch (BSD-3-Clause), torchvision (BSD-3-Clause, with detection ops like NMS, anchor utilities, and dataset loaders), TensorFlow/Keras (Apache 2.0), timm (Apache 2.0, for backbones), Albumentations (MIT, augmentation), OpenCV (Apache 2.0 in current versions), and ONNX / ONNX Runtime (MIT / Apache 2.0) for deployment. None of these impose copyleft. (For where a pure-PyTorch path fits versus a production pipeline, see Savant vs. PyTorch.)

  4. Train on data you have rights to. Use your own labeled data, commercially-cleared vendor datasets, or permissive public datasets — and avoid baking COCO/ImageNet images into production weights. The weights you train then belong to you and carry no upstream copyleft.

  5. Keep a license inventory and scan it. Maintain a software bill of materials (SBOM) and run an automated license scanner (e.g., ScanCode, FOSSA, or pip-licenses) in CI to catch any GPL/AGPL dependency that sneaks in transitively. The most common real-world violation is an engineer pip install-ing the ultralytics package “just to prototype” and leaving it in the dependency tree.

  6. Document provenance. For each component record: source repo, license, commit, and the data it was trained on. If you ever need to prove your detector is clean, this record is what does it — and it is also what a clean-room defense relies on.

The result is a detector whose code is under your chosen license, whose weights you trained yourself, and whose dependencies are all permissive — i.e., something you can legally embed in a proprietary product and ship without buying anyone’s commercial license.

8. The auto-labeling / distillation question: can you launder a copyleft model?

A specific scheme comes up constantly, so it deserves a direct answer. The plan:

  1. You have royalty-free images (cleared for commercial use and redistribution).
  2. You run a restrictively licensed model (e.g., AGPL Ultralytics, or GPL YOLOv7) to auto-label those images.
  3. You publish the labeled dataset under a permissive license.
  4. You train your own private model on that dataset and ship it commercially.

Short answer: Yes — for a copyleft (GPL/AGPL) model, this is generally possible, and it is a recognized technique (pseudo-labeling / knowledge distillation). But it is conditional, and for some licenses the answer flips to No. Here is exactly why, and where it breaks.

Why it works for GPL/AGPL. Three independent facts line up in your favor:

First, the license itself says outputs are not covered. GPL-3.0 and AGPL-3.0 contain identical wording in Section 2: “The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work.” Bounding boxes and class labels are factual data about your images — they do not contain the model’s source code — so the labels are not a derivative work of the code and do not inherit the copyleft. (Facts and data have little or no copyright protection in the first place.)

Second, mere private use never triggers GPL/AGPL copyleft. The copyleft obligation fires on conveying (distributing) the covered code, not on running it. The FSF is explicit that purely internal use — including internal copying and modification with no distribution — imposes no source-release requirement. Running the model on your own machines to label your own images is exactly that: use, not distribution. AGPL’s extra trigger (Section 13) only applies when you offer the modified program itself to users over a network; labeling a dataset in-house does not put the model in front of any third party, so even AGPL stays dormant.

Third, the student model is trained on data, not on the teacher’s code. Your private model never incorporates a line of the copyleft repository. It is independently written code, trained on a dataset of (royalty-free image + factual label) pairs. It therefore carries no copyleft from the teacher — the same idea/expression principle that makes clean-room reimplementation legal (Section 2).

The conditions you must actually meet (miss any one and the scheme can fail):

  • The images must truly permit commercial use and redistribution. “Royalty-free” is not the same as “redistributable.” You can only publish the dataset if the image license (e.g., CC0, CC-BY, or your own photos) allows redistribution and commercial use. If the images are CC-BY-NC, the published dataset cannot be commercial. This is precisely why COCO-derived data is risky (Section 6).
  • You must only run the model, never distribute its code or weights, and never expose a modified copy as a network service. If you ship the AGPL inference code or host a modified version for outside users, copyleft fires regardless of the labels.
  • Train the student with a permissive stack (PyTorch/torchvision/timm — Section 7), not the vendor’s copyleft trainer. If you fine-tune the student with the Ultralytics package, your training pipeline is back under AGPL and Ultralytics asserts the resulting weights are AGPL too. The data is clean; don’t re-contaminate it at the training step.
  • You can only license what you own. You publish the annotations under your chosen permissive license; you cannot relicense the underlying images beyond their own terms. Distribute the dataset as “images under their original license + annotations under (your permissive license).”

Where the answer becomes No. The blocker is almost never copyright — it is a contract term in the model’s license or terms of service that restricts outputs or field of use, something the GPL/AGPL pointedly do not contain:

  • YOLO-NAS: its pretrained weights are under a non-commercial license. Using them to label data for a commercial product is a commercial use of the weights, so the scheme violates the weights’ license before you ever publish anything. No.
  • Hosted APIs and many proprietary/commercial model EULAs include explicit anti-distillation / no-competing-model clauses (OpenAI, Anthropic, Meta Llama, and others forbid training competing models on their outputs). Those are enforceable as contract terms independent of copyright. If your “restrictive model” is one of these, No — even though the labels themselves may not be copyrightable.
  • CC-BY-NC / CC-BY-NC-ND model or data licenses likewise bar the commercial or derivative step.

So the deciding question is not “are the labels copyrightable” (generally they are not) but “does the model’s license or ToS restrict what I may do with its outputs or for what purpose I may run it?” Plain AGPL/GPL impose no such output or field-of-use restriction — in fact GPL Section 7 forbids adding “further restrictions” — which is the quirk that makes this laundering route legitimate for those licenses specifically. A commercial EULA, a non-commercial weights license, or an API anti-distillation clause does impose one, and there the route is closed.

One caveat that applies regardless: this analysis is about copyright and contract, not patents. As in Section 2, distillation is not a defense against a patented technique. And the safest posture remains the Section 7 approach — start from a permissively licensed model so you never have to rely on the output-laundering argument at all.

9. Practical decision summary

  • Want the easiest, best-supported YOLO and can pay? Use Ultralytics (YOLOv8/YOLO11/YOLO12) and buy the Enterprise License. Don’t ship the AGPL version in a closed product.
  • Want commercial use for free, today? Use a permissive flavor — YOLOX, PP-YOLOE, DAMO-YOLO, or RT-DETR (all Apache 2.0) — and retrain on your own data.
  • Like a GPL version’s architecture (v6/v7/v9) but need it closed? Use a clean MIT re-implementation, or reimplement from the paper yourself. Never copy the GPL repo’s code.
  • Tempted by YOLO-NAS? Remember the weights are non-commercial; only self-trained weights are shippable.
  • Whatever you choose, separately verify the license on the code, the weights, and the training data — all three must be commercially clean.

The architecture is never the hard part. Legal cleanliness in a commercial YOLO product comes down to disciplined choices about which code you copy, which weights you ship, and which data you train on.

Sources

License terms verified against primary repository LICENSE files and official documentation:

Licenses can change; re-verify the current LICENSE file for any project before relying on it, and consult an IP attorney for deployment-specific questions.