What does open-weight mean for an AI model, and is it the same as open source?

The distinction in one paragraph

Open-weight is a statement about distribution: the trained parameters exist as files you can download. Open source is a statement about rights and completeness: you get the freedoms to use, study, modify, and share, and you get the materials needed to actually exercise them. The Open Source Initiative's Open Source AI Definition 1.0 lists those materials explicitly as Data Information, Code, and Parameters. Publishing parameters alone satisfies one of the three.

This is why the two words are not interchangeable even when a model is genuinely useful and genuinely downloadable. A model can be excellent, freely available, and still not open source under that definition. That is not an accusation against the model; it is a description of what was released.

What an open-weight release usually does and does not include

In a typical open-weight release you get the weight files, an inference path or serving recipes, a model card with benchmark numbers, and a licence. That is enough to run the model on your own hardware, fine-tune it, and serve it.

What you usually do not get is the training code that produced those weights, the training dataset, or a full description of how the data was assembled, cleaned, and filtered. OSI's own write-up on open weights makes this concrete: in its comparison table, training code is Not Shared, intermediate checkpoints are Withheld, and the training dataset is Not Shared or Not disclosed. The practical effect is that you cannot reproduce the model, audit how it was trained, or independently verify claims about its data.

The Open Weights Definition project makes a related argument worth understanding: weights are not source code. They are large matrices of numbers that are not human-readable and not debuggable in the way source is, so the study and modify freedoms do not map onto them as cleanly as they map onto software. Reasonable people disagree about how much that matters, and this article does not try to settle that dispute.

The label does not tell you the licence

This is the part that causes real problems in practice. Open-weight describes availability, not permission. Two models that are equally downloadable can carry completely different terms.

Checked on 2026-08-29 via the Hugging Face model API, licence metadata across widely used downloadable models is genuinely mixed. Qwen3-235B-A22B, gpt-oss-120b, and Mistral-Small-3.2-24B-Instruct-2506 report apache-2.0. DeepSeek-V3.2-Exp reports mit. Those are standard, well-understood open source licences. But google/gemma-3-27b-it reports a custom gemma licence, meta-llama/Llama-4-Scout-17B-16E-Instruct reports other with the licence name llama4 and ships a separate USE_POLICY.md, and zai-org/GLM-5.3 reports other.

GLM-5.3 is a useful worked example because its release was widely described as open-weight. Its licence file grants broad rights to use, modify, fine-tune, redistribute, and sell copies. It also adds a condition: an organisation running a Model as a Service business whose affiliated revenue exceeds 10 billion US dollars over any consecutive 12 months must pass a Z.AI security review before commercial use. That condition affects almost no one reading this, which is exactly the point. The clause is narrow, the model is genuinely usable, and it is still not what an Apache-2.0 grant says. You only learn that by opening the file.

Why vendors and press coverage blur the two words

Some of the blurring is marketing, but not all of it. Open source carries enormous accumulated trust, so applying it to a model release is commercially attractive. There is also genuine ambiguity: the industry lacks a single settled vocabulary, OSI's definition is relatively recent, and no widely adopted certification mark distinguishes an open-weight release from an open source one at a glance.

The GLM-5.3 model card is a fair illustration rather than an outlier. Within the same section it calls the model the most capable open-weights model for coding and claims open-source state of the art on public benchmarks. Both phrasings appear side by side, which is precisely how the terms drift together in readers' heads.

Treat this as a reason to check rather than a reason to distrust. The right response to imprecise language is to read the licence, not to assume bad faith.

How to check a model in about five minutes

First, find the licence value on the model page or via the hub API. A value like apache-2.0 or mit is a standard licence you already understand. A value of other, or a vendor name such as gemma or llama4, means a custom licence you have to read.

Second, open the actual licence file rather than trusting the tag. On Hugging Face the raw file is usually reachable at the /raw/main/LICENSE path for the repository. Read it end to end; these files are typically one to two pages.

Third, look specifically for conditions attached to the grant: acceptable-use policies in a separate file, revenue or user-count thresholds, naming or attribution requirements, restrictions on using outputs to train other models, field-of-use limits, and any requirement to seek approval before commercial deployment. Any one of these means the model is not open source under the OSI definition, whatever the announcement said.

Fourth, check what else was published. If you need reproducibility or a data audit, look for training code and a described dataset. If they are absent, you have an open-weight release, and you should plan around not being able to reproduce or fully audit it.

Fifth, if the decision is commercial and the licence is custom, route it to whoever handles legal review at your organisation. A licence summary in a blog post, including this one, is not legal advice and is not a substitute for reading the terms that apply to you.

What this means in practice

For most individual users running a model locally, the distinction is mostly about accurate vocabulary. You can download, run, and fine-tune the great majority of open-weight models without ever touching a restricted clause.

The distinction becomes load-bearing in three situations. If you are shipping a model inside a commercial product, custom terms and acceptable-use policies are contractual obligations you inherit. If you need reproducibility or a data-provenance audit, for research or regulatory reasons, open weights alone will not get you there. And if you are making a long-term platform bet, a permissive standard licence is considerably more portable than a vendor licence whose terms the vendor can change on the next release.

One thing this article deliberately does not do is rank models or tell you which to pick. That is a different question with a different answer, and it depends on your workload rather than on your licence reading.

Limits of this answer

The licence values cited here were checked on 2026-08-29 and apply to the specific model repositories named. Vendors revise licences between releases, and a permissive licence on one model in a family says nothing about its siblings, so re-check the exact repository and revision you intend to use.

This article does not resolve whether the OSI definition is the right standard. It is the most widely cited one and it is written down, which makes it a usable reference point, but the Open Weights Definition project and others argue the framing should differ for model parameters. That debate is live and is described here rather than adjudicated.

Nothing here is legal advice, and no licence was evaluated by a lawyer for this article. The evidence is the licence text and the hub metadata as published, linked above so you can read them yourself.

A useful next action

Take the model you are currently using or are about to adopt, open its raw licence file, and read it once. Note whether the licence is a standard SPDX identifier or a custom vendor document, and note any condition attached to commercial use. That single five-minute pass is the difference between knowing what you are permitted to do and assuming it.