Open Weights vs Truly Open: Licenses & Provenance

A model advertised as "open" can still forbid the exact thing you intend to build, or arrive with no verifiable account of how it was made. The confusion is not carelessness; it is that openness is really three separate axes — the availability of the weights, the freedom the license grants, and the provenance you can prove — and a release can score high on one while scoring zero on the others. Practitioners who conflate them inherit legal, security, and reputational risk they never priced in. This article separates the axes, shows the four license clauses that actually change your exposure, and explains why provenance is becoming the part that decides whether an open model is usable at all.

A release is a bundle, not a file

It is tempting to treat a model as a single object, the way a photograph or a compiled binary is a single object. It is not. A release is a package of separate artifacts, and each one can carry its own copyright status and its own terms: the weights (the learned numerical parameters), the inference code that runs them, the training code that produced them, the tokenizer that maps text to tokens, evaluation results, safety notes, and — sometimes — information about the training data.

Because the parts are separable, the terms are separable too. A vendor can publish weights under a restrictive community license while the inference code sits under permissive Apache 2.0, and disclose nothing at all about the data. The practical consequence is that the first question is never "is this model open?" but "which artifacts did I actually receive, and under which terms for each?" A team that skips that inventory tends to discover the binding clause only after it has shipped.

Three independent axes of open

Openness is not a single dial. It has at least three axes that move independently. Open weights means you can download the parameters and run or adapt the model yourself. Open source (in the classical sense) means the code and the license grant broad rights to use, modify, and redistribute without discrimination against people or fields of use. Open data means the training corpus, or a faithful description of it, is disclosed well enough to reproduce or audit the model.

A model can sit at any corner of this space. Downloadable weights with a non-commercial clause are open on one axis only. A permissively licensed model with undisclosed data is open on two. "Truly open" is the rare intersection where all three hold at once — and it is worth naming precisely, because most models marketed as open occupy only the weights axis.

Open weights are access, not freedom

Open weights are genuinely valuable: they reduce dependence on a single hosted service, make local and offline testing possible, and let engineers quantize, fine-tune, or optimize the model for a specific environment. But availability is a technical fact, not a legal permission. A model can have fully downloadable weights and still forbid commercial use, forbid redistribution, exclude certain industries or countries, or cut off organizations above a revenue threshold.

This is why casual speech misleads. Two models both called "open" can be legally opposite — one usable in a paid product and freely shareable, the other restricted to research on a personal machine. The weights being downloadable tells you nothing about which of those two you are holding. Only the license does.

Reading a license in four clauses

Most model licenses become legible once you look for four things. First, the grant: what you are actually permitted to do — use, modify, create derivatives, redistribute. Second, field-of-use restrictions: acceptable-use policies, banned sectors or applications, geographic or revenue limits. Third, redistribution and derivative terms: whether you may share the model or a fine-tune, and what you must carry with it — attribution, the same license, naming rules. Fourth, output and liability terms: who owns generated outputs, what warranties are disclaimed, and what obligations attach downstream.

The trap is the field-of-use clause, because it is where a model that looks open quietly stops being usable for your case. An acceptable-use policy that bans a category you operate in, or a "you may not use outputs to train a competing model" clause, can invalidate an entire architecture. Reading these four clauses takes minutes; discovering them in legal review after launch takes weeks.

1. Grant — use, modify, derive, redistribute?
2. Field-of-use — banned sectors, regions, revenue caps, acceptable-use policy?
3. Redistribution — may you share it, and what must travel with it?
4. Outputs & liability — who owns outputs, what is disclaimed?

The license landscape

Model licenses cluster into a few recognizable families, and it helps to place them on two axes that leaders actually care about: how freely you may redistribute, and how freely you may use the model commercially and build derivatives. Permissive licenses such as Apache 2.0 and MIT sit in the free-and-free corner: broad commercial use, redistribution, and derivatives with minimal obligations. Community or "source-available" licenses — the family used by several well-known weight releases — allow wide commercial use but attach conditions: naming requirements, revenue thresholds, or a bespoke acceptable-use policy.

Responsible-AI licenses (the RAIL family, for Responsible AI License) permit broad use but bind you to behavioral restrictions on harmful applications. Research-only or evaluation licenses sit in the restrictive corner: you may inspect and benchmark, but not deploy. None of these is "bad" — but only the permissive corner behaves the way most engineers assume "open" behaves, and mistaking a community or research license for a permissive one is the most common and most expensive error.

Provenance: can you prove where it came from

As open models move into regulated and security-sensitive settings, the deciding question shifts from "what may I do with it?" to "can I prove what it is?" Provenance is the verifiable account of a model's origin: which base model it descends from, what data it was trained on, who modified it and how, and whether the file you downloaded is the file the author published. Without it, an open model is an anonymous binary — and anonymous binaries do not pass modern supply-chain review.

The tooling here is maturing fast. Model cards document intended use, training data summaries, and evaluations. Data lineage records where a corpus came from and what was filtered out. An AI Bill of Materials (AIBOM) enumerates the components and their licenses, mirroring the software bill of materials teams already use. And cryptographic signing lets you verify that the weights were not tampered with in transit. A release that carries a signed AIBOM and a real model card is not just legally open — it is auditable, which is what a security or compliance owner ultimately needs.

Where teams get burned

The recurring failures are predictable. A team fine-tunes a model under a community license and redistributes the result without carrying the required naming or the original acceptable-use policy — a redistribution breach. A product trains a competing model on another model's outputs, violating an explicit clause. A regulated deployment adopts weights with no data disclosure and cannot answer an auditor's question about copyrighted or personal training data. Each of these is invisible while the model works and painful the moment it matters.

The defense is unglamorous but reliable: inventory the artifacts, read the four clauses, record the provenance, and keep the license text with the model in your own systems. Treat an open model exactly as you would a third-party dependency — because legally and operationally, that is what it is.

What to decide

For a practitioner, the choice of open model is a choice of obligations, not just capabilities. Before adopting one, decide three things: whether the license grant covers your actual use and distribution plan, whether the field-of-use restrictions leave your domain clear, and whether the provenance is strong enough to survive the review your industry will impose. If any answer is uncertain, the model is not yet a dependency you can build on — it is a risk you are carrying.

For a leader, the strategic frame is optionality against exposure. Permissive, well-documented, verifiably-sourced models buy freedom and auditability; restrictive or opaque ones can be cheaper or more capable today but constrain what you can build and how you can defend it later. The right default is to prefer provenance you can prove, and to make "which clauses bind us?" a standard gate before any open model enters production.

Glossary

Weights

The learned numerical parameters that let a model turn inputs into outputs.

Open weights

A release whose weights are available to download — a technical fact, not a grant of legal rights.

Open Source Initiative (OSI)

The body whose definition of open source sets the classical bar of broad, non-discriminatory use, modification, and redistribution rights.

Permissive license

A license such as Apache 2.0 or MIT that allows broad commercial use, modification, and redistribution with minimal obligations.

Responsible AI License (RAIL)

A license that grants broad use but attaches behavioral restrictions banning specified harmful applications.

Acceptable-use policy

A clause listing prohibited fields, sectors, or applications that can quietly make an otherwise-open model unusable for your case.

Provenance

The verifiable account of a model's origin — its base model, training data, modifications, and integrity.

AI Bill of Materials (AIBOM)

An enumeration of a model's components and their licenses, analogous to a software bill of materials.

Model card

A structured document describing a model's intended use, training data summary, evaluations, and limitations.