Open weights vs open source AI: what's actually released

The phrase "open source AI" is used constantly and is usually wrong. Models described that way, including the best known ones, generally do not meet the standard that the words have meant in software for decades, and the gap is not a technicality. It changes what you can verify, what you can rebuild, and increasingly what legal obligations you carry. Almost every model marketed as open source is open-weight, meaning you receive the finished parameters under a licence but not the training data or the code that produced them, so you can download, run, and adapt the model while being unable to reproduce or audit it, and the distinction stopped being pedantry once regulators began attaching legal exemptions to the word.

This guide sets out what each term actually means, the formal definition the software world settled on and why almost no model meets it, the Llama dispute with both sides stated fairly, what open weights actually buy you, why the terminology now has money attached, and the correction that openness is not the same thing as safety or quality. If you are choosing a model to build on, the useful question is not whether it is "open" but which specific components you were given and under what terms.

The distinction in one line

Open weights means you get the finished model. You can download the trained parameters, run them on your own hardware, fine-tune them, and deploy them without calling anyone's API.

Open source means you also get the recipe. The training code, the architecture and configuration details, and enough information about the data that a competent team could rebuild something equivalent from scratch, all under terms that do not restrict what you use it for.

The difference is between receiving a cake and receiving the recipe, the ingredient list, and permission to sell what you bake. Both are useful. They are not the same gift, and only one of them lets you check what went into it.

What open source means for AI

Software has had a settled definition of open source for a long time, built around freedoms rather than price: use it for any purpose, study how it works, modify it, and share it, without asking permission and without restrictions on who you are or what field you work in. Applying that to a trained model turned out to be difficult, because a model is not source code. Releasing the weights is closer to releasing a compiled binary than to releasing a program's source.

After a long consultative process, the Open Source Initiative published a formal Open Source AI Definition in late 2024. It requires three components. The weights, obviously. The complete code used for training and running the model, including data processing, configuration, and validation. And data information detailed enough that a skilled person could recreate a substantially equivalent system, meaning the sources used, how they were processed and filtered, and how the data can be obtained or licensed. All of it must come under terms that preserve the four freedoms, so a licence restricting your field of use, or revoking rights above a usage threshold, disqualifies a release regardless of what else it includes.

One compromise in that definition drew objections worth knowing about. It requires detailed information about the data rather than the data itself, because much training material is encumbered by copyright, contracts, or privacy law, and a requirement to publish it outright would make compliance impossible for nearly everyone. Free software advocates argued this concedes too much, since without the actual data you cannot truly reproduce the system. The definition therefore represents a negotiated position rather than a universally accepted one, which is worth remembering when anyone cites it as settled.

Why almost nothing meets it

Measured against that standard, the great majority of models presented as open source fall short, and usually on more than one count. Weights are released; training code often is not, with only inference code provided. Training data is described in general terms at best, and frequently not at all, since it is commercially sensitive and legally fraught. And licences are often custom documents written by the releasing company rather than standard permissive licences, containing acceptable-use policies and other conditions.

When the Open Source Initiative worked through candidate models during its definitional process, a handful of fully open research projects met the requirements, generally models released by academic and non-profit labs that published their data pipelines and training code alongside the weights. Several of the most widely used commercial releases did not, because required components or compatible legal terms were missing. That comparison is the substance of the argument: once fully open projects demonstrably exist, "open source" stops being a mood and becomes a standard that releases either meet or fail.

It is worth adding that licensing among open-weight models varies a great deal and has been moving in a more permissive direction. Some major releases now ship under standard permissive licences of the kind long used in software, which removes the field-of-use problem even though the data and training code questions remain. Others use bespoke licences with meaningful conditions attached. Because terms change from release to release and are sometimes revised, the only reliable move is to read the licence for the specific model and version you intend to use rather than assuming from the family name.

The Llama dispute, both sides

The clearest illustration is the argument over Meta's Llama family, which the company describes as open source and the definition-setting bodies do not.

The case against the label is concrete. The licence is a custom community licence rather than a standard open-source one. It requires organisations above a very large monthly-user threshold to request permission, which can be refused, and that alone is a restriction on who may use the software, which open-source definitions forbid. Its acceptable-use policy limits certain applications, which is a field-of-use restriction. Training data is not published and cannot be inspected. Training code is not provided. The Free Software Foundation has classified the licence as non-free, and the Open Source Initiative's position is that a release with those conditions is open-weight rather than open source.

Meta's case is also worth stating properly rather than dismissing. Releasing capable frontier weights at no cost delivers real and substantial public benefit: it lets anyone run, study the behaviour of, and adapt a system that would otherwise be reachable only through a paid interface, and it has seeded an enormous ecosystem of research and products. Meta argues the formal bar is drawn too narrowly for models, given that publishing training data at scale is legally impossible for most developers. The Open Source Initiative's reply is that if the alternative to a strict definition is calling everything open, the term loses meaning and the field is ceded to whoever markets most aggressively.

Both positions are defensible on their own terms, and the disagreement is real rather than a matter of one side acting in bad faith. What is not really contested is the factual description: the weights are open, the data and training code are not, and the licence carries conditions. You can decide for yourself what to call that, but you should know which components you are getting.

A spectrum, not a binary

Treating this as open versus closed obscures that model access runs along a range, and knowing the rungs is more useful than the label.

At the closed end sits a model available only through an API, where you send inputs and receive outputs and the weights never leave the provider. Next is gated access, where weights are available but only to approved parties under agreement. Then open weights with a restrictive custom licence: freely downloadable, with conditions on use. Then open weights under a standard permissive licence, which removes the use restrictions while still withholding data and training code. At the far end sits fully open source by the formal definition, with weights, code, and data information all released under unrestricted terms.

Each rung trades differently. Moving toward openness increases what outsiders can inspect, adapt, and verify, and reduces dependence on a single vendor. It also reduces the releasing party's ability to control how the system is used afterward. Neither end is simply correct, which is why serious discussions of release policy describe a spectrum with different risk and benefit profiles rather than a moral binary.

What open weights actually buy you

Even without qualifying as open source, open weights deliver most of the practical benefits people want, and it is worth being clear about which ones.

You can run the model on your own machines, which means your data never leaves your infrastructure, a decisive advantage for regulated or sensitive work. You can run it locally on hardware you control, and quantize it to fit what you have. You can fine-tune it on your own data to specialise it in ways an API rarely permits. You can pin a version and keep it indefinitely, avoiding the situation where a provider updates or retires a model your product depends on. Costs become predictable capital and compute rather than per-token fees, which at volume can be decisive. And you can inspect the model's actual behaviour in ways a metered interface makes awkward.

What you cannot do is equally clear. You cannot reproduce the model, because without the training code and data there is no path from scratch to those weights. You cannot audit what went into it, so questions about data provenance, copyright, personal information, and contamination are unanswerable from the outside. You cannot fully explain its behaviour, since the reasons a model believes or refuses something often lie in data you cannot see. And you may not be free to use it for anything you like, depending on the licence. Open weights give you operational independence. They do not give you epistemic access.

Why the terminology now has money attached

The reason this stopped being a vocabulary dispute is regulation. Several emerging legal frameworks treat open-source AI differently from proprietary AI, generally granting lighter documentation and disclosure obligations on the reasoning that a system whose components are public is already transparent. The European Union's AI Act contains exemptions along these lines, with conditions that limit them where a model is commercialised, and other jurisdictions have proposed definitions requiring everything needed to retrain a model from scratch.

That turns the definition into something with direct financial consequences. If calling a release open source removes compliance obligations, there is an obvious incentive to apply the label as widely as possible, and an equally obvious public interest in the term meaning something specific. This is the actual stake in a debate that can look like pedantry from outside: not what we call things, but which releases qualify for lighter regulatory treatment, and whether that treatment is justified by genuine transparency or merely claimed.

Open is not the same as safe, or good

Two corrections keep the picture honest, and they cut in opposite directions.

The first is that openness does not confer quality or safety. A fully open model can still be trained on harmful data, carry serious bias, ship weak safeguards, and produce unreliable output. What openness provides is the ability for outsiders to investigate and improve it, which is valuable precisely because it is a precondition for scrutiny rather than a substitute for it. Nobody is obliged to do that work, and often nobody does.

The second is that open weights really do weaken safety control, and this deserves stating without either alarmism or dismissal. Once weights are on someone else's machine, the safety training in them can be removed by further fine-tuning, and any acceptable-use policy becomes unenforceable in practice. A provider serving a model through an interface can refuse requests, monitor for misuse, and revoke access; a provider who has released weights can do none of these. This is the real trade at the heart of release decisions, and it sits alongside the jailbreaking problem, since a safety layer that can be talked around through prompting can be removed outright when the weights are in hand. Against that sits the case that open weights enable independent safety research, reduce concentration of power, and let far more people examine these systems, which are substantive benefits and not merely rhetorical ones. Reasonable people weigh these differently, and the honest position is that this is a real trade-off rather than a settled question.

The short version

Open weights and open source are different things. Open weights means you receive the trained parameters and can download, run, fine-tune, and deploy the model. Open source, under the formal definition published by the Open Source Initiative in late 2024, additionally requires the complete training and inference code and information about the training data detailed enough to rebuild an equivalent system, all under terms preserving the freedom to use, study, modify, and share without restriction. Almost every model marketed as open source, including the most widely used ones, is open-weight only: training code is usually withheld, training data is rarely described in reproducible detail, and licences are often custom documents with conditions such as user thresholds and acceptable-use limits that formal definitions disqualify. Model access is best understood as a spectrum from API-only through gated weights, restrictively licensed open weights, permissively licensed open weights, and fully open source. Open weights still deliver most practical benefits: self-hosting, data privacy, fine-tuning, version stability, and cost control. They do not allow reproduction or auditing, since the data and training pipeline remain invisible. The terminology matters because regulators attach lighter obligations to open-source systems, giving the label direct financial value, and because openness increases scrutiny while reducing a developer's ability to enforce safety controls after release.

The idea to hold onto is that the useful question is never whether a model is "open" but which components you were actually given, weights, code, data information, and under what licence, because open weights buy operational independence while only genuine open source buys the ability to verify what you are running. Read the licence for the specific model you intend to use, and treat the marketing word as a claim rather than a fact.

Common questions

What is the difference between open weights and open source AI? Open weights means the trained model parameters are released, so you can download, run, fine-tune, and deploy the model yourself. Open source means considerably more: alongside the weights, you get the complete training and inference code and enough information about the training data that a skilled team could rebuild a substantially equivalent system, all under a licence that does not restrict who may use it or for what purpose. The practical difference is that open weights let you use and adapt a model, while open source additionally lets you reproduce and audit it. Most models called open source are open-weight only.

Is Llama open source? Not by the standard definitions, though Meta describes it that way. The licence is a custom community licence rather than a standard open-source one, and it requires organisations above a very large user threshold to request permission, which is a restriction on who may use the software. Its acceptable-use policy limits certain applications, which is a field-of-use restriction. Training data is not published and training code is not provided. The Free Software Foundation has classified the licence as non-free and the Open Source Initiative treats such releases as open-weight. Meta argues the formal bar is too narrow given that publishing training data at scale is legally impossible for most developers.

What is the Open Source AI Definition? It is the formal standard published by the Open Source Initiative in late 2024 after a lengthy consultation, setting out what an AI system must provide to be called open source. It requires the model weights, the complete code used for training and running the model including data processing and configuration, and information about the training data detailed enough for a skilled person to recreate a substantially equivalent system. All of it must be under terms preserving four freedoms: to use for any purpose, study, modify, and share. Notably it requires detailed information about the data rather than the data itself, a compromise that some free software advocates have criticised as too permissive.

Why do so few models qualify as open source? Mainly because of training data. Publishing the data used to train a frontier model is often legally impossible, since it is encumbered by copyright, licensing agreements, and privacy law, and it is commercially sensitive besides. Training code is also frequently withheld as competitive advantage, with only inference code released. And many releases use custom licences containing acceptable-use policies or usage thresholds that formal definitions disqualify. A small number of research projects, typically from academic and non-profit labs that published their data pipelines and training code, do meet the standard, which is what makes the comparison meaningful.

What can you do with open-weight models? Most of what people actually want. You can self-host, so your data never leaves your infrastructure, which matters for regulated and sensitive work. You can run the model on hardware you control and quantize it to fit. You can fine-tune it on your own data in ways APIs rarely allow. You can pin a version indefinitely rather than depending on a provider not to change or retire it. Costs become predictable compute rather than per-token fees. What you cannot do is reproduce the model from scratch, audit what data went into it, or fully explain its behaviour, because the training data and pipeline remain invisible.

Are open-source AI models safer than closed ones? Openness and safety are separate properties, and the relationship runs both ways. Open release enables independent scrutiny, safety research, and adaptation by many more people, and it reduces the concentration of control, all of which are genuine benefits. But an open model is not automatically safer, fairer, or more accurate: it can still contain harmful data, serious bias, and weak safeguards, and openness only creates the possibility of investigation rather than guaranteeing anyone performs it. Open weights also remove a provider's ability to enforce guardrails after release, since safety training can be fine-tuned away and acceptable-use policies become unenforceable. This is a real trade-off rather than a settled question.

Why does the open source AI definition matter legally? Because several regulatory frameworks treat open-source AI more leniently than proprietary AI, generally reducing documentation and disclosure obligations on the reasoning that public components already provide transparency. The European Union's AI Act includes exemptions of this kind, with limits where a model is commercialised, and other jurisdictions have proposed definitions requiring everything necessary to retrain a model from scratch. That gives the label direct financial value, creating an incentive to apply it broadly and a corresponding public interest in it meaning something specific. The dispute is therefore about which releases earn lighter regulatory treatment, not merely about vocabulary.