Open Weights Is Not Open Source: What Llama and DeepSeek Licenses Permit

On October 28, 2024, at the All Things Open conference, the Open Source Initiative published version 1.0 of the Open Source AI Definition, the first formal attempt to say what "open source" actually means once the artifact is a trained model rather than a codebase (opensource.org). The definition arrived after a year-long global community drafting process. It also arrived too late to stop a habit that had already settled into model cards, press releases, and procurement decks: calling a downloadable set of weights "open source" because you can run it on your own hardware.

That habit is a procurement and legal exposure, not a semantic nuisance. A model card that says "open" tells you nothing enforceable; the license file attached to the weights is the document that binds you. Two of the most-deployed model families on the market right now sit on opposite ends of that gap. One ships under a custom corporate license with a user-count ceiling, a mandatory attribution string, and a carve-out that excludes a specific class of residents. The other ships under a license that is roughly two paragraphs long.

The definition most people skip

The OSI Definition sets a deliberately high bar, and the imprecision around it is exactly where the risk lives. An Open Source AI system must grant four freedoms: to use the system for any purpose without asking permission, to study how it works by inspecting its components, to modify it for any purpose including changing its output, and to share it with or without modifications (opensource.org). Those four freedoms echo the long-standing four-freedoms framing of free software, which is a useful tell: the OSI is not improvising a new philosophy for AI, it is applying an established one to a new kind of artifact.

The harder part is the component requirement. To deliver those four freedoms in practice, the OSI specifies three categories of materials that must all be available under OSI-approved terms (opensource.org):

• Data Information — sufficiently detailed information about the training data that a skilled person could build a substantially equivalent system. Not necessarily the raw dataset itself, but enough to reproduce the work.
• Code — the complete source code used to train and run the system.
• Parameters — the model weights and other numerical state, released under terms that permit all four freedoms.

Note what this list does to the marketing word "open." A weights download satisfies exactly one of the three categories, and only if the accompanying license is itself OSI-approved. Miss the data information, miss the training code, or attach a license with a commercial ceiling, and the system is not open source under the only formal definition that exists.

What "open weights" actually means

The OSI now maintains a dedicated position on this, and it is blunt. Open-weight releases are not open source because they do not provide the underlying training process, code, or comprehensive data details required for full use, study, modification, and sharing (opensource.org). The organization's sharpest technical point is about what weights alone let you do: they permit only superficial fine-tuning rather than in-depth improvement, because without the training pipeline you cannot retrain a model, you can only nudge one.

Open weights, then, is a capability claim, not a rights claim. It tells you that you can download the parameters and run inference locally. It says nothing about whether you may deploy commercially, at what scale, under whose name, or whether residents of your jurisdiction are permitted to use the result at all. Runtimes like Ollama make the capability trivial: you pull the weights and run them on a laptop. That ease is precisely why the capability and the rights get conflated, because the friction that used to remind you a license existed has been engineered away.

The distribution layer is where the license lives

Every model discussed below distributes through Hugging Face, and on every repository the LICENSE file sits one click from the download button. The single most reliable habit for anyone evaluating an open-weight model is to open that file before the model card. The card is written by marketing; the LICENSE is written by lawyers, and only one of those two documents can be enforced against you.

The permissiveness spectrum

Treating "open-weight models" as one category is the error. They fan out across a spectrum from genuinely permissive standard licenses to custom corporate grants with sharp restrictions. The table below maps four named families onto that spectrum using the clauses that actually decide whether you can ship.

Model family	License	Commercial use	Scale ceiling	Attribution / naming mandate
DeepSeek R1	MIT	Yes	None	None
Qwen3	Apache 2.0	Yes	None	None (NOTICE file only)
Mistral 3 (flagship)	Apache 2.0	Yes	None	None
Mistral MRL / MNPL models	Custom research	No	Non-commercial only	n/a (research-only)
Mistral Devstral 2	Custom commercial	Conditional	Under $20M monthly revenue	Not specified
Llama 4	Community License	Conditional	700M MAU ceiling	"Built with Llama" + "Llama-" prefix

None of these is OSI-approved open source, because none ships the full data-information and training-code stack the Definition requires. But the practical distance between the MIT row and the Llama row is enormous, and a benchmark score will never tell you which row you are in.

The permissive end: MIT and Apache 2.0

DeepSeek sits at the permissive extreme. Both the DeepSeek-R1 code repository and the use of the R1 models themselves are subject to the MIT License, which supports commercial use and, notably, distillation (huggingface.co). MIT is roughly two paragraphs: do what you want, keep the copyright notice, no warranty. There is no monthly-active-user ceiling, no revenue cap, no naming requirement, and no acceptable-use policy bolted on. Of every row in the table, MIT carries the fewest production obligations, with one consequential exception.

That exception survives a model-card skim and only surfaces when you go to deploy. DeepSeek's R1 distilled variants are not pure DeepSeek artifacts. They are built on other base models, namely the DeepSeek-R1-Distill-Qwen and DeepSeek-R1-Distill-Llama families, so the permissive MIT terms cover DeepSeek's own contribution while the underlying base model's license still governs the foundation underneath it (deepseekai.guide). A variant distilled on Llama is governed by Llama's restrictions on the base even though the repository is labeled "DeepSeek MIT." License inheritance through distillation is the single most under-read clause in the category, and it is the reason "MIT" on the repo header does not let you stop reading.

Qwen ships its entire Qwen3 series under the Apache 2.0 license, which permits unrestricted commercial use, modification, and redistribution at any scale with no user-count limitation (huggingface.co). Apache 2.0 adds an explicit patent grant and a NOTICE-file convention on top of MIT's bare permission, which is why enterprise legal teams often prefer it. The patent language reduces a specific class of downstream risk that MIT leaves silent.

Mistral AI is the instructive case, because it deliberately runs a two-tier strategy and you cannot reason about "Mistral's license" as a single thing. The flagship Mistral 3 family is released under Apache 2.0, allowing unrestricted commercial use (venturebeat.com). That is the permissive tier. The restrictive tier sits right alongside it in the same brand.

The restrictive end: research licenses and revenue ceilings

Mistral also maintains licenses that look open on a repository listing and are nothing of the sort in production. The Mistral Research License (MRL) limits use to personal, scientific, or academic non-commercial research and explicitly excludes revenue-generating activity, while the Mistral AI Non-Production License (MNPL) permits only non-commercial and research use (mistral.ai). A model under either of these can sit in the same Hugging Face organization as an Apache 2.0 sibling, behind the same download flow, with the opposite legal posture.

The newer pattern is more insidious because it does permit commercial use, just not necessarily yours. Mistral's Devstral 2 coding-agent license limits free use to companies with monthly revenue under $20 million; above that threshold a separate commercial license is required (thestack.technology). A startup that adopts the model at seed stage and builds a product around it does not face a static grant. The terms that applied when revenue was small stop applying once the company crosses the threshold, which turns a successful quarter into a licensing negotiation.

Llama 4: the custom license that anchors the debate

Llama is the family that made "open" a contested word, and the Llama 4 Community License is worth reading clause by clause because each restriction maps to a specific deployment decision.

The 700M MAU ceiling

The grant terminates for any company with greater than 700 million monthly active users in the preceding calendar month, who must then request a separate license from Meta, granted at Meta's sole discretion (llama.com). For most organizations this ceiling never binds. But it is structurally a competitor-exclusion clause: the only entities it touches are platform-scale companies, which means the license is doing market strategy and not just risk management. A standard open source license cannot discriminate by who you are; this one does, by design.

Mandatory attribution and naming

Two obligations bite at any scale. Licensees must prominently display "Built with Llama" on a related website, user interface, blog post, about page, or product documentation, and must include "Llama" at the beginning of the name of any AI model trained or fine-tuned on the materials that they distribute (llama.com). The first is a branding obligation on your product surface. The second forces your derivative to carry the Llama name, which is a meaningful constraint if you intended the fine-tuned model to wear your own brand. Neither MIT nor Apache 2.0 imposes anything close to either requirement.

The acceptable-use policy override

The license incorporates by reference an Acceptable Use Policy that licensees must adhere to, and the grant is described as a non-exclusive, worldwide, non-transferable, royalty-free limited license rather than an OSI-approved open source license (llama.com). The AUP is the clause most likely to override your specific use case, because it lives in a separate document that can govern entire categories of application. A license you have read in full can still forbid your product through a policy stapled to it that you have not.

The OSI has formally argued that the Llama license fails Freedom 0 (use for any purpose), discriminates against users under OSD point 5, and restricts fields of endeavour under OSD point 6 — specifically citing the exclusion of persons in the European Union from using the model without explanation (opensource.org).

That EU carve-out deserves its own pause. A residency-based exclusion is not a scale ceiling that only affects giants; it is a geographic field-of-endeavour restriction that can reach any team with European users. It is also the cleanest single demonstration of why "open weights" and "open source" are not synonyms. An open source license, by definition, cannot exclude a class of people from using the software at all.

A buyer worksheet for the license file

The decision a practitioner needs is not "is this model good," it is "may I ship this model, at my scale, under my name, for my use case." Turn the LICENSE file into five filled-in answers before adoption. Each row below is a blank to complete from the license text itself, not from the model card; the first answer that comes back "no" is where evaluation stops, regardless of benchmark rank.

1. Scale headroom. Write your current and projected metric next to the model's ceiling. Llama 4 binds at 700M MAU; Devstral 2 binds at $20M monthly revenue; MIT and Apache 2.0 leave this blank. If your projection crosses the ceiling inside your planning horizon, treat the model as conditional, not free.
2. Brand cost. Record what the license forces onto your product surface. Apache 2.0 wants a NOTICE file; Llama 4 wants "Built with Llama" displayed and a "Llama-" prefix on any distributed derivative. If your brand cannot carry that string, the answer is no before you run a single eval.
3. AUP delta. Open the acceptable-use policy as a separate document and write down which of your application categories it touches. The prohibition that disqualifies you usually is not in the license proper; for Llama it lives in the incorporated AUP.
4. Exclusion check. Note any geographic or class-based exclusion. The Llama EU carve-out is the canonical example, and a residency restriction can disqualify a model for an entire market regardless of technical fit.
5. Lineage trace. For any distilled or fine-tuned variant, list every license in the chain back to the base. A DeepSeek-R1-Distill-Llama model answers to Llama's terms on the base, not the DeepSeek MIT label on the wrapper.

Open questions the definition leaves unresolved

The OSI Definition is one year old and several genuinely hard problems remain unsettled. The Data Information requirement is the most contested: it asks for enough detail to build a substantially equivalent system rather than the raw training corpus, which is a pragmatic concession to the reality that much training data cannot be redistributed for copyright reasons. Whether that concession is principled or a loophole is an open debate, and it means a model could plausibly claim OSI compliance while withholding the dataset itself.

A second open question is enforcement. The OSI maintains the Definition and its public critiques, but it does not control the word "open" in the market. A vendor can call a model open source in its press release with no legal consequence, and the only available correction is reputational. The result is a formal definition on one side and unenforceable marketing on the other, which is why the burden of getting this right lands on the buyer rather than on a regulator.

The third is the trajectory of revenue-gated and scale-gated grants. Devstral 2's $20M ceiling and Llama's 700M MAU ceiling represent a license genre that is neither open source nor traditional proprietary licensing. If this genre proliferates, the binary of "open vs closed" stops being useful and the spectrum in the table above becomes the only honest way to describe the market.

The next time a model clears your benchmark and the team wants to ship, send the worksheet above to whoever owns legal sign-off and make them fill the five blanks from the license text. A model that passes evals but fails the scale-headroom row or the exclusion row is not a deployment you can defend later, and the leaderboard will not be the thing that gets cited when it breaks.