“Open” has become the most overloaded word in AI. Model cards say open. Press releases say open. Download pages say open. Yet two models wearing the same label can grant you wildly different rights: one lets you rebuild the entire system from scratch, the other hands you a sealed black box of numbers with a license that can evaporate the moment you get too successful. The difference has a name — open weights versus open source AI — and if you build on these models, it is a distinction worth being fluent in before you ship anything.
What you actually get in a weights-only release
When a lab “open-sources” a model in the loosest sense, what usually lands on the hub is the trained parameters: the final weights and biases of the network, plus inference code and a config. The Open Source Initiative’s explainer on open weights is blunt about what this includes and what it quietly leaves out. You get the finished artifact — enough to run it, fine-tune it, quantize it, distill it, deploy it. What you typically do not get, per the OSI, is the training code that produced it, the training dataset (or a meaningful description of it), and the data-processing pipeline: how the corpus was sourced, filtered, cleaned, and balanced.
That is not a small gap. It means you can use the model but not reproduce it. You cannot audit where its knowledge or its biases came from. You cannot verify the safety claims in the model card against the data that shaped it. The OSI’s page traces the formalization of this tier to Heather Meeker’s Open Weights Definition, published in 2023, which clarified what sharing final parameters permits — while highlighting that the process behind the model remains undisclosed.
None of this makes open weights bad. A weights-only release under a genuinely permissive license is enormously useful, and for most application builders it is all you will ever need. The problem is only the label: calling it “open source” borrows three decades of trust that the release does not actually honor.
What “open source AI” requires — the OSAID checklist
The OSI spent two years in an open drafting process answering the question “what would software freedom mean for an AI system?” and the answer is the Open Source AI Definition (OSAID) 1.0, finalized in October 2024. It transplants the classic four freedoms — use, study, modify, share, for any purpose, without asking permission — onto machine learning systems, and then gets specific about what you must be given for those freedoms to be real. The definition calls this the preferred form to make modifications, and it has three legs:
- Data information. Not necessarily the raw dataset, but sufficiently detailed information about the training data “so that a skilled person can build a substantially equivalent system”: the complete description of all data used, its provenance and scope, how it was obtained and selected, labeling procedures, and the processing and filtering methodology. Publicly available and third-party-obtainable data must be listed with pointers to where to get it.
- Code. The complete source used to train and run the system — data processing and filtering code, training code with the actual arguments and settings, validation and testing, supporting pieces like tokenizers, and inference code — under OSI-approved licenses.
- Parameters. The weights themselves, under OSI-approved terms.
Read that list against your favorite “open” model and the divide snaps into focus. Most headline open-weight releases satisfy leg three, part of leg two, and almost none of leg one. By the OSAID yardstick, they are open-weight models, not open source AI — a milestone in transparency, as the OSI puts it, that still stops short of what researchers and regulators consider essential for accountability.
Why the gap matters in practice
If the distinction feels academic, it stops being academic in four situations the OSI’s own analysis calls out:
- Reproducibility. Without training code and data documentation, nobody outside the original lab can replicate the model’s development, which means nobody can pinpoint where a bias or vulnerability entered the pipeline — or fix it at the source rather than patching over it with fine-tuning.
- Data opacity. Garbage in, garbage out applies with full force. If you cannot see how the corpus was constructed and cleaned, you are trusting the vendor’s word on data quality, consent, and representativeness.
- Regulatory exposure. Transparency mandates for AI in sensitive domains — finance, healthcare, public administration — increasingly ask for exactly the artifacts weight-only releases withhold. “We published the weights” may not satisfy an auditor asking how the training data was governed.
- Community ceiling. Full-pipeline openness is what lets outsiders retrain, ablate, and genuinely improve a system rather than merely adapt its surface. Weight-only releases cap community contribution at the fine-tuning layer.
How to read a model’s license like a builder
The practical skill is separating the artifact tier (what was released) from the license tier (what you may do with it). A workable habit:
Check the license identifier first. On Hugging Face, the license is declared in model-card metadata and is filterable hub-wide; the platform’s license documentation lists the full menu, from true open source licenses to a long tail of bespoke “community” and responsible-AI licenses. An Apache-2.0 or MIT-licensed model gives you the strongest position: patent grant (in Apache’s case), no field-of-use restrictions, no rug-pull clauses.
Read for the three trapdoors in custom licenses. Bespoke model licenses commonly carry some mix of: usage thresholds (terms that change above a certain scale of deployment or user count), field-of-use restrictions via acceptable-use policies (which OSI-approved licenses by definition do not impose), and naming or attribution obligations on derivatives. None of these necessarily make a model unusable for you — but each one is a dependency your product now has on the goodwill of the model’s publisher.
Pin the license version and keep a copy. Custom model licenses are living documents controlled by their publishers, and a hub page can be updated after you have already built on the model. Archive the exact license text you accepted alongside your dependency manifest, note the model revision hash you pulled, and treat any license change upstream the way you would treat a breaking API change: something to review deliberately, not absorb silently. Teams that skipped this step have discovered mid-audit that the terms they remember agreeing to are no longer the terms on the page.
Then ask the OSAID questions. Is there real data documentation, or a paragraph of vibes? Is the training code published, or just inference? Can a skilled team substantially recreate this system? If yes, you are looking at the rare genuine article. If no, budget accordingly: treat the model like a proprietary component with a generous evaluation license, and keep your abstraction layer thick enough to swap it out.
The honest bottom line
Open weights and open source AI are both legitimate — they are simply different promises. One says you may build on what we made; the other says you may know how we made it, and make it yourself. The label on the press release does not determine which promise you hold; the license text and the released artifacts do. The OSI’s definitions give you the checklist, and it fits in a pocket: use, study, modify, share — plus data information, code, and parameters. Ask for all seven before you call a model open source, and know exactly which ones you are doing without when you settle for fewer.
