An open-weight model makes its trained parameters available for download and self-hosting. An open source model, under the definition maintained by the Open Source Initiative, requires more: the training code, sufficiently detailed information about the training data, and the parameters, all under terms that preserve the freedom to use, study, modify, and share. Almost everything casually called an open source model, including Llama, DeepSeek, Qwen, and Gemma, is open-weight. Very few models meet the open source bar, and the gap between the two terms is not pedantry. It determines what you can verify about the thing you are deploying.
How the conflation happened
"Open" made it into the branding before anyone agreed what it covered. Model families shipped downloadable weights under bespoke licenses and were reported as open source because the download was free and the hub page was public. The Open Source Initiative responded by publishing its Open Source AI Definition in October 2024, and by that standard most of the popular "open" models do not qualify: OSI has said plainly that Llama's license, with its acceptable-use restrictions and its commercial threshold requiring a separate license above 700 million monthly users, does not meet the definition. None of that makes the models bad. It makes the label wrong, and wrong labels produce wrong assumptions.
What you actually get, side by side
| Component | Typical open-weight release | OSI open source AI |
|---|---|---|
| Model weights | Downloadable | Downloadable, open terms |
| Inference code | Usually available | Available, open terms |
| Training code and recipe | Rarely published | Required |
| Training data or detailed data information | Almost never published | Required |
| License freedoms | Custom terms, use restrictions common | Use, study, modify, share preserved |
The rows that stay empty in an open-weight release are the rows that would tell you what produced the model's behavior.
Why the difference is a security property, not a licensing footnote
The security story of open source software rests on inspectability: the code is readable, so flaws and backdoors are findable, and many eyes make them shallow. Neither half of that transfers to an open-weight model. Weights are billions of opaque numbers, not readable logic, so even fully open weights offer nothing like code review. And the withheld rows in the table above mean the inputs are unverifiable too: no training data to audit, no training process to reproduce, no way to independently establish what the model learned or from whom.
The practical translation is the distinction that anchors our full security guide: artifact identity can be verified, and training provenance usually cannot. You can prove you loaded the exact bytes you approved, by provenance record and hash. You cannot prove what those bytes will do in contexts you have not tested, and the research record says testing cannot close that gap. So the accurate mental model for an open-weight model is not open source software. It is an unauditable binary from a supplier you partially know, and it should be deployed the way careful enterprises have always deployed such things: verify the artifact, constrain the environment, and validate the outputs that matter.
The license deserves its own reading
One more consequence of "open" branding: teams skip the license because open things do not need legal review. Open-weight licenses routinely carry acceptable-use policies, field-of-use restrictions, commercial thresholds, and terms governing distillation and derivative models. A fine-tune your team builds inherits the base model's terms, which makes the license part of the intellectual-property posture of everything trained on top of it. Read it the way you would read any supplier agreement, because that is what it is.
Where to go next
The deployment consequences of this distinction are the subject of our full guide, open-weight model security, which covers verifying what you load, constraining the agents built on models you cannot fully audit, and operating the lifecycle. For the artifact-verification half specifically, see securing a self-hosted LLM inference server; for what happens when a model you deployed turns out to have a problem, see the enterprise model recall playbook.
