AI Licenses: Check Code, Model Weights and Data

Before putting an AI model into a paid product, check three permissions: its code, trained weights and training data. Weights are the parameters learned during training; the dataset supplied that training material. A commercial-friendly code license does not clear the other two layers. Record the permissions for each version before promising it to customers.

In the earlier post in this series I walked through how open-source licenses behave in ordinary commercial software. AI products add a layer of trouble that catches even teams who did that homework.

A permissive repository badge describes the covered code. It does not establish permission for weights or training data.

Teams see the badge, run the pilot, promise the client a product — then discover during due diligence that the weights they deploy were released for research only. By then the model is wired into everything. (Usual note: engineering guidance, not legal advice.)

Layer one: the code

This is the license GitHub shows on the repository page, and the only one most engineers ever read. It covers the training scripts, the inference wrappers, the architecture definition. If it's MIT, BSD, or Apache-2.0, the code side is usually fine — keep the notices, ship the license text, done.

Code can also bring source obligations. Ultralytics YOLO is available under AGPL-3.0 and a commercial license. Assess modification, integration, distribution, and network access to identify the covered work; do not assume the entire business system must automatically be opened. If the obligations conflict with your product plan, evaluate commercial licensing or alternatives.

That answers the code layer only. Review weights and data separately before clearing the product.

Layer two: the weights

The trained parameters you actually deploy are distributed under their own terms — sometimes in the repository LICENSE, sometimes in a model card. Those terms are frequently more restrictive than the code around them.

The 3D-vision world supplies the clearest examples. DUSt3R and MASt3R are published under CC BY-NC-SA 4.0: non-commercial, share-alike. The code runs beautifully in your pilot. Putting those weights in a paid product without a separate license from the rights holder is a violation, full stop.

The original 3D Gaussian Splatting reference implementation ships under a license limited to noncommercial research or evaluation from its institutes — while Apache-2.0 implementations of the same technique, such as gsplat, permit commercial use of covered code subject to their terms. Same algorithm, different artifact, opposite answer.

That's the pattern to internalize: the question is never "is this technique usable commercially" — the general technique and a particular implementation are separate questions; patents may also need review. The question is "is this exact artifact, at this exact version, licensed for what I'm about to do."

Layer three: the training data

Weights are a function of their training data, and datasets carry terms too. Benchmark permission is not commercial-training permission: many academic datasets allow evaluation and research but restrict training models for commercial distribution. If you fine-tune on a dataset, check whether its terms restrict training, use, or distribution of the resulting weights. Dataset licenses do not all operate the same way.

Scraped images bring copyright and privacy exposure that no code license launders away. For anything customer-facing, the safe baseline is data you own, data you licensed, or data whose commercial-training terms are explicit and recorded.

The artifact registry

The fix isn't heroic legal analysis. It's bookkeeping: a registry with one row per artifact, filled in before the artifact enters the product path.

For every model version I record:

1. Artifact type — code, weights, dataset, Docker image. The license differs by type, so each gets its own row.
2. Source URL, version or commit, and checksum — "we downloaded it somewhere in March" doesn't survive an audit.
3. License name plus a link to the exact license file — the actual text you're bound by, not the badge in the README.
4. Commercial use and redistribution: yes, no, or unclear — written as an explicit answer, because "unclear" is a finding, not a gap.
5. Status: green, yellow, or red — green ships with normal notices, yellow needs review before shipping, red doesn't enter the product path.

The registry records versions, sources, terms, and unresolved questions for review. It also stops the quiet failure where a model gets upgraded to a new version whose terms changed — the new version gets a new row, and the row forces the question.

Clearing an artifact

Most artifacts land on yellow at first pass, and that's fine — yellow means "someone must look before this ships," which is exactly the discipline the badge-glancing workflow lacks.

The takeaway

Treat every model as three contracts: code, weights, data. Verify each at the exact version you deploy, write the answer down in a registry, and make the registry a release gate. Reading only the code license leaves weights and data questions unresolved.