AI Licensing: Code, Weights, and Datasets Are Three Different Contracts

AI Licensing: Code, Weights, and Datasets Are Three Different Contracts

An AI model is not one artifact. It's at least three — the code, the trained weights, and the training data — and each is a separate contract. A green light on one says nothing about the other two.

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.

I call the rule no magic green. An MIT or Apache-2.0 badge on a GitHub repository is like a "certified safe to eat" stamp on packaged food — it guarantees one ingredient, not everything on the plate. It green-lights the code, nothing else.

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 be the problem all by itself. Ultralytics YOLO — the most convenient object-detection package in the ecosystem — is AGPL-3.0 code. Serve a product built on it over a network and you're obligated to open-source that product, unless you buy the commercial license.

No weights or dataset analysis needed. The code license alone decides.

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, the foundation models half the recent reconstruction work builds on, 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 research-only license from its institute — while Apache-2.0 implementations of the same technique, such as gsplat, are safe to build on. Same algorithm, different artifact, opposite answer.

That's the pattern to internalize: the question is never "is this technique usable commercially" — techniques aren't licensed. 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, its terms follow the resulting weights.

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 costs minutes per model and turns due diligence from an excavation into a printout. 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. The teams that get burned are never the ones who misread a license — they're the ones who only read one of the three.