The question I hear most from clients evaluating a model is whether it is open source or just free to download. The honest answer is usually on page three of a license file, and it is often neither of the things they expect. That question is the reason this chapter exists. For two years this site, like most of the industry, used “open source” and “open-weight” as if they meant the same thing. They do not, and the gap between them is where the practical risk lives.
This is chapter 2 of the Open Source AI Hub. It sets the definitions that the license chapter and the model landscape rely on. If you want the history behind the definitions, chapter 1 covers it.
Three terms that get mixed up
Open-weight means the trained parameters of a model are published for download. The license may still restrict who can use them and for what, and nothing about the training code or data is implied.
Open source AI means the system meets the Open Source Initiative’s Open Source AI Definition: you may use, study, modify and share it for any purpose without asking permission, and the code, the parameters and sufficiently detailed information about the training data are all available under terms that allow that.
Open data means the training corpus itself is released under an open license. It is the highest bar of the three and the rarest. A model can be open-weight without being open source, and open source without being open data.
What each actually gives you: open weights let you run the model on your own hardware and fine-tune it; open source additionally lets you understand how it was made, reproduce it, and fork it without anyone’s permission; open data lets you audit what it learned from. Most of the models on any leaderboard are in the first group only.
The OSI Open Source AI Definition
The Open Source AI Definition, version 1.0, was released by the Open Source Initiative on 28 October 2024 after a two-year public drafting process. It restates the four freedoms for AI systems: use the system for any purpose without permission, study how it works and inspect its components, modify it for any purpose including changing its output, and share it with or without modifications, again for any purpose. Those freedoms must apply to the whole system and to its discrete components.
The definition then says what “the preferred form for making modifications” means for a machine learning system, and it names three components. Data information: sufficiently detailed information about the data used to train the system, so that a skilled person can build a substantially equivalent system, including the provenance and selection of the data and, where the data can be shared, the data itself. Code: the complete source code used to train and run the system, including data processing, training and inference. Parameters: the weights and configuration, made available under OSI-approved terms.
Notice what it does not require. It does not require the training data itself to be released, only enough information to recreate an equivalent system. That was a deliberate choice, defended on the grounds that much training data cannot legally be redistributed, and it is the most contested part of the definition. The Free Software Foundation and a number of researchers argue that without the data you do not have the preferred form for modification, and that a model trained on a corpus you cannot see is not free in any meaningful sense. The OSI’s counter is that requiring the data would make almost no model open source, including many trained on data that was public but not licensed for redistribution.
My view: the OSAID is the best line anyone has managed to draw, and I use it as the test throughout this hub. I also keep “open data” as a separate, higher label, because the difference between “I could rebuild this” and “I can see what it read” is exactly the difference an auditor cares about.
The openness spectrum, with examples
Openness is a spectrum, not a switch, and it is easier to reason about with the actual models placed on it. These groupings are correct as of September 2026; check the license of the exact release you download, because families move.
Fully open
Weights, training code, data and often the training logs, all under open licenses. Ai2’s OLMo family is the reference case: Apache-2.0 weights and code, the Dolma training corpus published, and the intermediate checkpoints available. EleutherAI’s Pythia suite is the research equivalent, trained on the Pile with every checkpoint released under Apache-2.0. BigScience’s BLOOM documented its ROOTS corpus in detail but shipped under a RAIL license with use restrictions, which makes it open data without being open source, a useful reminder that the two axes are independent.
Open-weight, permissive license
Parameters under Apache-2.0 or MIT, so you may do what you like with them, but without the data information the OSAID asks for. This is the largest and most useful group for practitioners: Alibaba’s Qwen3 family (Apache-2.0), DeepSeek’s R1 and the later V3 releases (MIT), Mistral’s open line from Mistral 7B and Mixtral through Small and Devstral (Apache-2.0), OpenAI’s gpt-oss models (Apache-2.0), Microsoft’s Phi-4 family (MIT) and IBM’s Granite models (Apache-2.0, with unusually good data disclosure). You can build a business on any of these. You still cannot, strictly, call them open source AI, because you could not rebuild them.
Open-weight, restricted license
Parameters you can download under a license that limits who may use them or how. Meta’s Llama models under the Llama Community License and Google’s Gemma models under the Gemma Terms of Use are the important cases, along with anything under a RAIL license. These are proprietary licenses with generous terms. For many companies the terms are perfectly acceptable. They are not open source, and the reason is the same one Debian wrote down in 1997: the license discriminates by field of endeavor or by scale.
Closed
Available only through an API, with no weights to download. Most frontier models sit here. Nothing wrong with that as a business model; it is simply the opposite end of the spectrum, and worth naming so that “open” is measured against it.
For what it is worth, when the OSI published the definition it also published its own assessment of well-known models against it, naming Pythia, OLMo and a handful of others as conforming, and Llama 2, Grok, Phi-2 and Mixtral, as released, as not. The failures were for different reasons: use restrictions in one case, missing data information in another.
“Open washing”
Open washing is the practice of describing a restricted or partial release as “open source” in order to borrow the reputation of the term. The word was popularized in AI by Liesenfeld and Dingemanse’s 2024 paper for the ACM FAccT conference, “Rethinking open source generative AI: open-washing and the EU AI Act”, which graded dozens of models on their actual openness, and by the OSI’s public statements from 2023 onward that Llama 2 did not meet the definition. The Linux Foundation’s Model Openness Framework offers a graded alternative for people who want more than a pass or fail.
I will keep this factual rather than accusatory, here and throughout the hub. Whether a release is open source is decided by what the license text grants, not by what the launch announcement says and not by anyone’s intent. Quote the clause; judge the clause. Meta’s own position, stated in Mark Zuckerberg’s July 2024 letter “Open Source AI Is the Path Forward”, is that its releases are open source. The Llama Community License, read against the Open Source Definition, says otherwise, and both things can be true at the same time about the words and the artifact.
Why the distinction matters in practice
Auditability. If data information is published you can answer the questions a regulator, a customer or your own security team will ask: what did this model learn from, and is any of that a problem for us? With weights alone you are trusting the model card.
Reproducibility. With code and data information a skilled team can retrain or continue training. With weights alone you can fine-tune, which is a much narrower kind of modification.
Forkability. If the maker stops, changes direction or changes its terms, an open source system can be carried on by anyone. An open-weight model under a restricted license cannot be relicensed by its community, and the maker can attach new conditions to the next release.
No rug-pulls. Software has taught this lesson several times: HashiCorp moved Terraform to a source-available license in August 2023, Redis left its open license in March 2024 and returned to the AGPL in May 2025, and Elastic went to the SSPL in 2021 before adding an AGPL option in August 2024. In models, Meta withheld multimodal Llama 3.2 rights from EU users in September 2024, and Stability AI reversed its Stable Diffusion 3 license within weeks of a backlash in June 2024. A permissive license on the weights you already have cannot be revoked; a license on the next version can be anything the maker likes.
Fairness demands the other side too. Open weights, even under restricted terms, give you most of what a private deployment needs: local inference so data never leaves your network, fine-tuning on your own material, no per-token bill, and no dependency on a vendor’s uptime. That is why running LLMs inside a company network is possible at all, and why the on-premise versus cloud decision exists. Open-weight is a real and valuable category. It is just not the same category as open source, and the license chapter explains what each restricted license actually costs you.
A short glossary
Weights. The numerical parameters learned during training; the model itself, in the narrow sense.
Checkpoint. A saved snapshot of weights at a point in training; a release is one checkpoint.
Base model. A model trained to predict text, before any instruction tuning; good for further training, poor as a chat assistant.
Instruct model. A base model further trained to follow instructions and hold conversations; what you usually deploy.
Fine-tune. Continued training of an existing model on new data, usually a small fraction of the original compute.
Distillation. Training a smaller model to imitate a larger one’s outputs; how many “small” reasoning models are made.
Quantization. Storing weights in fewer bits to cut memory and speed up inference, at a small cost in quality; explained in chapter 4.
Gated model. Weights that require accepting terms or requesting access before download, usually on the Hugging Face Hub.
Model card. The maker’s structured description of a model: intended use, training summary, evaluations and limitations. Useful, but it is not the license.
System card. A broader document covering the deployed system, including safety testing; more common for closed models.
Next steps
Continue to chapter 3, Open Model Licenses Compared, which reads the Llama, Gemma, RAIL, Mistral and Apache-2.0 terms clause by clause. To see where the models named above sit by size and task, jump to chapter 4. And to find out which of them your own hardware can run, use AILane.