Open-Weight Models and What "Open" Actually Means

When a buyer says they want to deploy an "open-source AI model," they are using a term that has meant something specific in software for thirty years and means something different here. That gap is where conversations go sideways. If you understand what actually ships when someone "releases the weights," you can contribute to a buyer's architecture discussion. If you don't, you're nodding through it.

What Weights Are, Mechanically

A model's weights are numbers. Billions of them, stored in files, encoding everything the model learned during training. They are the end product. When Meta publishes the weights for Llama 4, they are publishing these parameter files so anyone can download them, load them into compatible inference software, and run the model locally.

The training process that produced those weights is a separate thing entirely. It includes the training dataset (tens of trillions of tokens of text), the training code, the hyperparameters, the data filtering pipeline, and the compute infrastructure that ran the optimization. None of that ships when the weights ship. You get the finished artifact. The factory — the data, the code, the compute — stays behind.

Three terms circulate in these conversations, and they don't mean the same thing:

Open-weight means the trained parameters are downloadable. You can run the model. Reproducing how it was made is a different story entirely.

Open-source, under the definition the OSI published in October 2024, means the weights, the training code, and sufficiently detailed information about the training data are all released under approved open licenses. This is a high bar. Almost nothing clears it.

Open-access means the model is publicly available, possibly behind an API, possibly with usage restrictions that would make a procurement lawyer twitch. When a vendor offers model access through an API endpoint, the licensing constraints live in terms of service rather than weight licenses. Different conversation.

• Weights: the learned numerical parameters you download and run. Open-weight means these are publicly available.
• Open-source: per the OSI definition, requires the weights plus training code plus training data information, all under approved licenses. Nearly every model called "open source" is actually open-weight.
• Open-access: publicly available, but restrictions may live in terms of service rather than open licenses.

What the Licenses Actually Say

Licenses on open-weight models fall into three practical categories. The distinctions matter the moment procurement or legal enters the conversation.

License	Models	Commercial use	OSI-approved	Key constraint
Apache 2.0 / MIT	Mistral, Gemma, DeepSeek, Qwen (smaller sizes)	Unrestricted	Yes	None on the weights. Training data still not released.
Llama 4 Community License	Meta Llama 4	Yes, with conditions	No	700M MAU threshold; incorporated AUP Meta can update.
Custom / vendor-specific	Qwen (flagship sizes), others	Varies	Usually no	Read the model card for the specific artifact, not the family press release.

Apache 2.0 and MIT. Models from Mistral, Gemma (Google), and DeepSeek ship under Apache 2.0 or MIT licenses. These are genuine OSI-approved licenses. No meaningful restrictions on commercial use, modification, or redistribution. If you're evaluating a model for enterprise deployment, Apache 2.0 or MIT on the weights is as permissive as it gets.

One wrinkle worth knowing: not all model sizes from a given family necessarily carry the same license. Qwen's smaller models ship Apache 2.0; larger flagship sizes have shipped under Alibaba's Tongyi Qianwen license, which is commercially permissive but not OSI-approved. Read the model card for the specific artifact you're deploying, not the press release for the model family.

Llama's custom license. Meta's Llama 4 ships under the Llama 4 Community License, which is not Apache, not MIT, and not OSI-approved. It is a bespoke license with two clauses that matter in enterprise conversations.

The MAU threshold: if your organization had more than 700 million monthly active users in the calendar month before Llama 4's release, you need a separate license from Meta, granted at Meta's "sole discretion." This targets hyperscaler competitors. For every public sector buyer and every enterprise seller reading this, the clause is irrelevant to their accounts. But it exists, and it means the license is conditional in a way Apache 2.0 never is.

The acceptable use policy: the license incorporates Meta's AUP by reference. A violation of the AUP is a license violation. Meta can update the AUP. This creates downstream compliance uncertainty that a general counsel's office will notice even if a technical team doesn't.

Why none of these meet the OSI definition. The OSI's Open Source AI Definition requires three components: the parameters, the training and inference code, and sufficiently detailed data information to allow a skilled person to reproduce a substantially equivalent system. Every frontier model fails on the data requirement. Llama 4 was pretrained on roughly 40 trillion tokens including data from Facebook and Instagram interactions. Meta is not releasing that dataset. DeepSeek, Mistral, Google: same story. The training data for frontier models includes proprietary, licensed, or legally restricted content that the labs either can't or won't publish.

The models that actually pass OSI's validation are research-scale projects: Pythia (EleutherAI), OLMo (AI2), T5 (Google). Built for academic reproducibility, with full training data, code, and weights released under Apache 2.0. These aren't the models topping benchmarks or appearing in procurement conversations. The gap between compliant and capable is structural. It reflects the economics of training data, and those economics aren't shifting. OSI has signaled a definition update process targeting Q4 2026, but no draft is available yet.

So when someone says "open-source LLM," the accurate mechanical translation is: open-weight model under a permissive or semi-permissive license, with no access to training data or training code. That's still genuinely useful. It just isn't what the words have meant in software since 1998.

• Apache 2.0 / MIT: genuinely permissive, OSI-approved licenses on the weights. No commercial restrictions. But the weights alone don't satisfy the OSI definition of "open source."
• Llama 4 Community License: custom, non-OSI license with a 700M MAU threshold, attribution requirements, and an incorporated Acceptable Use Policy that Meta can update.
• OSI compliance: no frontier model meets the definition. The training data requirement is the structural gap, and it is not closing soon.

When You'll Need This

Federal procurement is where this vocabulary gap gets consequential. Three data points show the landscape.

GSA announced an agreement with Meta to make Llama available across the federal government, describing it as Meta's "open source AI model." It isn't, by the OSI definition. (That link goes to a BGR Group policy report from December 2025 summarizing the federal AI landscape; the GSA announcement itself is the underlying source.)

The White House AI Action Plan uses "open-weights" correctly in one passage, noting their "unique value" for innovation and flexibility. It is the only federal document I've found that gets the terminology right. (That link is a Freshfields law firm analysis of the Action Plan; I have not found the primary White House document at a stable URL.)

OMB memo M-26-04 (primary source, official OMB PDF) instructs agencies to avoid requesting sensitive technical data, such as specific model weights, during procurement, and to seek only enough information to assess risk management. This pulls in the opposite direction from what an open-weight procurement posture might require.

No federal guidance formally distinguishes "open-weight" from "open-source" in a procurement-classification sense. The terminology is loose at every level of government. Which means the buyer may not know exactly what they're asking for.

Picture the meeting. A federal CIO's office is evaluating on-premises AI deployment. The buyer says they want an "open-source model" because their security team requires inspectability and their procurement office wants to avoid vendor lock-in. Both are reasonable goals. But the phrase "open source" is doing more rhetorical work than technical work in that sentence. And "on-premises" carries its own weight: running a frontier model locally requires significant GPU infrastructure. Downloadable weights and deployable weights on existing hardware are two very different things.

The useful move is the follow-up question that separates the two things they might mean: "When you say open source, are you looking for inspectable weights you can host on your own infrastructure, or full reproducibility of the training process?"

The first is achievable today with several models under permissive licenses. The second does not exist at the frontier. Knowing which one the buyer actually needs changes the architecture conversation entirely. And if the license question surfaces, you can speak to it directly. Apache 2.0 or MIT on the weights means no commercial restrictions. Llama's license means attribution requirements and an acceptable use policy that legal should review. None of them mean "open source" the way your buyer's security team understands that term from two decades of running Linux.

• Federal procurement: uses "open source" loosely. No guidance formally distinguishes open-weight from open-source AI. GSA describes Llama as "open source." The White House AI Action Plan is the only federal document that uses "open-weights" correctly.
• The follow-up that matters: "Are you looking for inspectable weights on your infrastructure, or full reproducibility of the training process?" The first is available today. The second does not exist at the frontier.