The download button creates a powerful illusion. A company releases a model. The weights are available. Developers can run it locally, fine-tune it, quantize it, build products around it, and avoid sending every request back to the company that trained it. Then the marketing team reaches for the most flattering word available: Open. Sometimes it goes further and calls the model open source. That is where I start objecting.
The Open Weights vs Open Source distinction is not an argument over vocabulary for people with too much time and too many software licences. It determines what users are legally allowed to do, what researchers can inspect, whether the development process can be meaningfully studied, and how much private control the original company keeps after its supposedly open release.
Open weights are valuable. I do not want to dismiss what they have made possible. They have expanded local AI, private deployment, independent research, hardware optimization, fine-tuning, and competition with closed API providers.
But access to the finished parameters is not the same as access to the system’s source. A company can hand us the final model while withholding much of the machinery that shaped it. It can keep the training pipeline private, describe the data in broad categories, impose custom usage restrictions, and reserve the right to decide which users need separate permission.
That may be generous access. It is not automatically open source.
Open Weights vs Open Source Is Not Semantic Nitpicking
I understand why the distinction frustrates people. For a developer, the practical question may be simple: can I download the model and run it on my own hardware?
If the answer is yes, the release feels open compared with a model available only through a commercial API. The developer can inspect layers, change inference settings, apply adapters, fine-tune the weights, or serve the model without sending data to the original provider.
Those freedoms matter. But open source has never meant merely “more accessible than the closed alternative.”
It describes a set of rights and a development relationship. The Open Source Initiative’s current Open Source AI Definition centres on four freedoms: the freedom to use, study, modify, and share an AI system. Exercising those freedoms requires access to what it calls the preferred form for making modifications, including relevant code, model parameters, and meaningful information about the data used to create the system.
That standard is broader than downloading a checkpoint. The distinction becomes easier to see if I compare an AI model with a meal. Open weights give me the finished dish. I can taste it, reheat it, mix in new ingredients, portion it differently, and perhaps learn something about how it was made.
Open source should give me much more of the kitchen. I need the recipe, the preparation process, the tools, the settings, and enough information about the ingredients to understand why the result came out the way it did. The finished dish is useful. It is not the recipe.
The Open Weights Definition Stops at the Model’s Final State
The simplest open weights definition is this: the developer releases the learned parameters produced by training. Those parameters help determine how the model responds to input. They are why the model can predict the next token, classify an image, generate code, or follow an instruction.
Publishing them gives outsiders significant power. They can run the model without the original provider. They can study aspects of its behaviour. They can fine-tune it on new material, compress it, benchmark it, test it for bias, or adapt it to different hardware. What the weights do not automatically reveal is how the model reached that final state.
They do not provide a complete account of:
- Which training sources were included;
- How documents were filtered or weighted;
- How duplicates were handled;
- Which languages or communities were overrepresented;
- What preference and safety data shaped the final behaviour;
- Which training settings were used;
- What intermediate checkpoints looked like;
- Which experiments failed;
- Whether evaluation material leaked into training;
- How post-training changed the base model.
The Open Source Initiative describes open weights as incremental progress in transparency, but says they reveal only a fraction of what is needed for deeper accountability. Its distinction is straightforward: weights without the relevant training and data-processing components make meaningful replication, auditing, and study much harder.
That does not make the released model useless. It means the model is available while its origin story remains partly private.
Open Source Is About Freedom, Not Corporate Generosity
One reason this debate stays confused is that AI companies describe openness as a gift. The company could have kept everything closed. Instead, it released the parameters, published a model card, and allowed millions of developers to build with them. Surely that deserves to be called open source. I think it deserves credit. It does not deserve an inaccurate label.
Open source is not a medal awarded to a company for being less restrictive than its competitors. It requires users to receive specific freedoms without needing private approval from the original developer. A licence can be broad and useful while still falling short.
A company may allow commercial deployment but restrict certain fields of use. It may require compliance with a separate acceptable-use policy. It may treat very large organizations differently. It may control redistribution, derivative naming, geographic availability, or the use of its model to develop competing systems.
Some restrictions may be commercially rational. Some may be motivated by genuine safety concerns. Others may be designed to protect market power.
The motive does not settle the definition. A licence with private exceptions and discretionary permission requirements is not equivalent to a licence that grants everyone the freedom to use the system for any purpose.
“Available” and “open source” are not synonyms. Neither are “free of charge” and “free.”
The Llama Open Source Debate Exposed the Language Problem
Meta’s Llama releases provide the clearest example of how casually the AI industry has used the open-source label.
When Meta released Llama 3.1 in July 2024, it described the 405-billion-parameter model as the first frontier-level open-source AI model. It emphasized that developers could download the weights, customize the model, deploy it themselves, and avoid sending their data back to Meta.
Those were meaningful benefits. But the release was governed by Meta’s custom community licence, not a conventional open-source licence approved by the Open Source Initiative.
That licence did not grant identical freedom to everyone. Organizations above a specified scale had to request a separate licence from Meta. The terms also incorporated an acceptable-use policy that imposed restrictions beyond the normal conditions of an open-source software licence.
With Llama 4, Meta’s public terminology became more precise. Its official launch described Scout and Maverick as open-weight models rather than simply presenting them as open source.
I think that wording was an improvement. The underlying Llama 4 licence still grants broad and genuinely useful rights to use, reproduce, modify, and distribute the model materials. It also incorporates an acceptable-use policy and says organizations exceeding 700 million monthly active users must request a licence that Meta may grant at its discretion.
This is the heart of the Llama open source debate. The issue is not whether Meta has contributed something valuable. It clearly has. Llama accelerated local inference, model adaptation, research, and commercial competition. Many companies and independent developers gained access to capabilities that would otherwise have remained behind an API.
The issue is whether that contribution fits the established meaning of open source. If some users require the original company’s discretionary permission, the freedom is conditional. If use is restricted by a private policy, the freedom is bounded. If the model’s development pipeline cannot be meaningfully reconstructed from the released artifacts, the system is only partly open.
Calling that open weight is honest. Calling it fully open source asks the term to carry more than the release provides.
You Can Modify the Model Without Understanding Its Construction
The strongest argument for calling open-weight models open source is practical. Developers can modify them. They can apply low-rank adapters, continue training them, merge checkpoints, quantize them, prune them, change their system prompts, add retrieval, or optimize them for different devices.
That certainly looks like source-level control. But modifying a finished model and understanding how it was built are not the same task.
Suppose a researcher finds that a model performs poorly in a particular language. The weights may let that researcher fine-tune the model on better examples. What the weights may not reveal is why the original weakness emerged.
Was that language underrepresented? Was the data low quality? Did filtering remove useful material? Did tokenization make the language inefficient? Did post-training introduce the problem? Did safety tuning suppress legitimate responses? Did the model absorb conflicting representations from different sources?
Without data information and training-process visibility, the researcher can treat the symptom without being able to examine the cause. That limitation matters well beyond academic reproducibility.
It affects bias analysis, copyright disputes, consent questions, benchmark contamination, cultural representation, safety research, and scientific credibility. We can interrogate the finished model. We cannot necessarily interrogate the choices that produced it.
Why the Missing Training Pipeline Matters
AI companies often respond that releasing a full training pipeline is unrealistic. Frontier models may be trained with enormous internal systems, proprietary infrastructure, licensed data, sensitive information, and material that cannot legally be redistributed. Even the original developer may struggle to reproduce a training run exactly because large-scale machine learning contains randomness, infrastructure variation, and evolving code.
That counterargument is fair. Real open-source AI cannot require companies to violate privacy law, copyright agreements, or legitimate confidentiality obligations. It also should not pretend that every large model can be rebuilt cheaply by an independent researcher.
The Open Source AI Definition attempts to accommodate that reality. It does not demand that every raw training record always be redistributed. It distinguishes among open, publicly accessible, obtainable, and legally unshareable data. Where raw data cannot be shared, it requires detailed information about its characteristics, collection, processing, and role in the system.
That is an important nuance. Real open source does not have to mean dumping private medical files or licensed databases onto the internet.
It does mean giving downstream users enough information and tooling to study the system and make meaningful modifications without returning to the original company for secret knowledge.
I do not expect perfect reproducibility. I expect the release to contain more than the artifact left at the end of the process.
Openwashing AI Begins When Marketing Outruns the Release
I use the phrase openwashing AI carefully. It is not a settled legal offence. It does not mean every imprecise use of “open” is a calculated fraud. AI terminology evolved quickly, and the industry did not begin with one universally accepted definition.
But the term is useful when a company’s branding creates an impression of openness broader than the rights, information, and artifacts it actually provides. Openwashing can take several forms. A company may call a model open source because the weights are downloadable, even though the licence restricts who may use it or how.
It may release inference code but not the code used to assemble and filter the training data. It may publish a high-level data description that sounds transparent without giving outsiders enough detail to examine the model’s provenance.
It may release one repository under a permissive licence while keeping essential components proprietary, or publish enough documentation to look accountable without making the process meaningfully forkable.
Openwashing does not require a model to be completely closed. It only requires the label to be more open than the release. That is why this is not a complaint about imperfect transparency. Almost every model release involves practical compromises. It is a complaint about marketing those compromises as if they do not exist.
The Open-Source Label Carries Moral Value
Companies want to be associated with open source because open source has earned trust. That trust did not appear through branding. It came from decades of communities building software that users could inspect, modify, redistribute, maintain independently, and fork when the original project moved in a direction they opposed.
Open source changed the balance of power between users and vendors. Users did not merely receive access to a product. They received rights that survived changes in corporate leadership, pricing, strategy, or ownership. That history gives the phrase enormous moral and commercial value.
Calling a model open source suggests that the developer has surrendered a meaningful degree of control. It implies that the community can continue the work independently. It tells companies that they are not building on an artifact whose rules can be rewritten later by one private owner.
When an AI company keeps important pieces of that control but borrows the label anyway, it receives reputational credit for freedoms it has not fully granted. That is why terminology matters.
Open source is not just a technical adjective. It is a promise about power.
Open Weights Still Matter More Than Critics Admit
I do not want the criticism of openwashing to turn into another purity contest. Open weights have changed AI in ways that closed providers would not have delivered voluntarily.
They allow sensitive workloads to run locally. They reduce dependence on a single API provider. They let researchers evaluate safety and bias without waiting for access. They enable smaller companies to fine-tune specialized systems. They support offline use, private inference, quantization, distillation, and hardware experimentation.
They also put competitive pressure on closed-model companies. A model does not need to meet the strictest definition of open source to create public value. I would rather have a capable open-weight model under imperfect terms than no downloadable model at all.
The problem begins when we act as if there are only two categories: open and closed. There is a wide space between them.
A model can be more open than an API-only system while remaining less open than a reproducible research release. It can provide broad commercial rights while retaining usage restrictions. It can publish parameters while withholding data-processing code. It can be excellent for local deployment without being a fully independent foundation for community governance.
Recognizing those differences does not diminish open-weight models. It tells the truth about what they offer.
Fully Open Models Prove the Higher Standard Is Possible
Whenever I hear that releasing more than the weights is impossible, I look at projects designed around fuller transparency.
Ai2’s Olmo project releases far more of the model-development flow. The current Olmo 3 family provides access to weights, code, reports, checkpoints, training information, and artifacts across different stages of model construction. Its public interface lets researchers examine the model flow rather than only downloading the final checkpoint.
Earlier OLMo work was built on the same principle: data, training code, evaluation code, intermediate artifacts, and model parameters should be available for scientific study.
These releases do not prove that every commercial model can or should disclose every piece of raw data. They prove that openness can extend much further than weight access.
During the Open Source Initiative’s validation work, projects including OLMo, Pythia, Amber, CrystalCoder, and T5 met the requirements being tested. Llama 2, Grok, Phi-2, and Mixtral did not, because required components or compatible legal terms were missing. OSI describes those findings as part of its definitional process rather than permanent product certifications.
That is the comparison AI companies would prefer us not to make. Once fully open projects exist, “open source” stops being an aspirational mood. It becomes a standard against which releases can be measured.
Full Openness Does Not Guarantee a Good Model
There is another correction worth making. An open-source model is not automatically safer, fairer, more accurate, or more ethical.
Openness gives outsiders more power to investigate and change a system. It does not guarantee that anyone will perform that work well. A fully open model can still contain harmful data, weak safeguards, poor documentation, serious bias, or unreliable outputs.
Likewise, a closed model can be carefully tested and responsibly operated. Open source describes freedom and access. It does not certify quality. I make this distinction because the open-source label is sometimes treated as moral proof. It is not.
The value of openness is that users do not have to rely entirely on the developer’s claims. Researchers can inspect more of the system. Communities can test it, challenge it, modify it, and preserve it. Openness does not replace trustworthiness. It makes independent scrutiny more possible.
We Need Labels That Describe What Was Actually Released
The solution is not to spend another decade fighting over one word while every company invents its own definition. The industry needs clearer categories.
A practical vocabulary might include:
- Closed model: Parameters, training process, and source materials remain private.
- API-access model: Users can access capabilities through a hosted service but cannot download the parameters.
- Source-available model: Some code or artifacts are visible, but usage and redistribution rights remain restricted.
- Open-weight model: Model parameters are downloadable under stated terms, allowing local deployment and often adaptation.
- Open model: Architecture, parameters, supporting code, documentation, and meaningful data information are available under permissive terms.
- Fully open or reproducible AI system: The release includes extensive training data or data information, processing code, training code, checkpoints, evaluations, and artifacts across the development lifecycle.
No taxonomy will remove every edge case. That is not the goal. The goal is to make the label communicate more than the marketing department’s preferred emotional impression. A developer should be able to tell whether “open” means local inference, commercial freedom, redistribution rights, training transparency, or full model-flow access. Those are different promises. They need different words.
The Llama Debate Should Have Taught the Industry Something
The Llama story matters because it shows both the value and danger of broad openness language. Meta released powerful models that developers could download, customize, and deploy. That was a meaningful break from API-only access. It expanded the market and gave open-model ecosystems a major boost.
At the same time, calling those releases open source allowed a custom, conditional licence to borrow the reputation of a movement built around universal rights. The later shift toward “open weight” was not merely cautious public relations. It was more accurate. I wish more companies would follow that example.
Say the model is open weight if that is what it is. Explain the licence plainly. Describe which training artifacts are available and which are not. Tell users whether they can redistribute derivatives, train competing systems, deploy commercially, or operate above a scale threshold.
Let the release earn credit for its real freedoms. Do not manufacture extra credit through ambiguity.
Stop Calling Access Ownership
I keep returning to one simple question: Can the community continue the system independently of the company that released it? Not merely run the current checkpoint. Not merely fine-tune it within the original licence.
Can people study the development process, modify the meaningful components, share their changes, and fork the project without returning to the original owner for special permission?
If the answer is no, the system may still be useful, generous, accessible, and strategically important. It is not fully open source. That is the final lesson of Open Weights vs Open Source.
Open weights let us operate the result. Open source should give us meaningful freedom over the system.
The AI industry does not need to stop releasing open-weight models. It should release more of them. It should make the licences clearer, the documentation better, and the training process more transparent.
What it needs to stop doing is treating every downloadable checkpoint as proof that private control has disappeared. If a company gives us the weights but keeps crucial parts of the recipe, the development process, and the power to decide who needs permission, it has opened a model. It has not open-sourced the system.
