A common is not unowned land
The most persistent misreading of “open” is that it names an absence — of price, of owner, of restriction. An English common was never that. It was land over which particular people held particular rights: to graze a stated number of animals, to cut turf, to take bracken, and nothing else. The right was called a stint, and its size was specified. There was a gate, and it was hung. There was a pinfold, and something was put in it. The interesting questions were never whether the land was open, but who held a stint, what exactly it permitted, and who enforced it.
That is the correct frame for reading a model release. The word “open” on an announcement page compresses a bundle of separately granted permissions over separately releasable artefacts, and the compression is lossy in a way that matters legally and practically. This article takes the bundle apart.
The argument has three parts. First, that the distinction between open source as software has used the term for a quarter-century and open weights as the model industry uses it is substantive rather than pedantic, because the two grant different capabilities. Second, that the current definitional fight — over the Open Source Initiative’s 2024 definition of open source AI — is a genuine and unresolved disagreement rather than a settled matter with holdouts. Third, that even a maximally permissive release leaves large asymmetries in place, so the policy argument about openness cannot be settled by looking at licences alone.
Five artefacts, four capabilities
A trained model is not one thing that is either released or withheld. At least five artefacts can be released independently:
The weights — the fitted parameters, typically a few files of numbers. The inference code — what is needed to load those numbers and run them. The training code — data processing, filtering, the training loop, hyperparameters, the distributed configuration. The training data, or a description of it sufficient to assemble something equivalent. The evaluation and post-training recipe — what was measured, on what, and how behaviour was installed after pretraining.
Each supports different things, and confusing them is the source of most bad arguments. Consider four capabilities a recipient might want.
To run the model requires the weights and inference code, and nothing else. This is the capability nearly every so-called open release actually grants, and it is not trivial: it removes the API dependency, the rate limit, the silent version change, and the requirement to send data to someone else’s machine.
To modify the model requires the weights plus enough of the training stack to fine-tune. In practice the barrier here has collapsed. Dettmers and colleagues showed that a 65-billion-parameter model could be fine-tuned on a single 48 GB GPU by backpropagating through a frozen 4-bit quantised base into low-rank adapters, with their best model trained in 24 hours on one GPU [15]. Modification is therefore broadly available once weights are, which is precisely why the governance argument concentrates there.
To audit — to answer questions like “was my copyrighted work in the training set”, “what was filtered out”, “on what was this evaluated” — requires data or credible data documentation, and the recipe. Weights alone do not support it. You can probe a model’s behaviour, but behavioural probing is inference about a training process, not observation of it.
To reproduce — to build a substantially equivalent model from scratch and thereby verify a claim about how it was made — requires all five. This is the capability that maps most closely onto what source code provides for software, and it is the one almost never granted.
The Open Source Initiative’s page on open weights states the asymmetry directly: weights do not include training code, the training dataset, or comprehensive data transparency, and so “only provide a glimpse into the final state of the model” [3]. Whether that glimpse is enough is the whole argument.
It is worth stressing that the full release is possible, not merely theoretical. The Allen Institute’s OLMo 2 release covers weights at three scales alongside training data, training code, recipes, logs, and thousands of intermediate checkpoints [14], sitting on top of Dolma, a documented three-trillion-token pretraining corpus released with its curation toolkit [13]. The existence of that release matters to the debate: it removes “impossible” as an explanation for what other laboratories withhold, and leaves only “costly”, “legally exposed”, or “commercially unattractive” — which are different claims with different implications.
What a restrictive licence actually restricts
Two families of restriction appear in model licences, and they are worth separating because they fail the classic software test in different ways.
The first is the field-of-use restriction. The Open Source Definition addresses this in its sixth clause: “The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research” [2]. The rationale was practical rather than ideological — a licence that permits some uses and not others requires every downstream recipient to evaluate their own use against a policy written by the licensor, and to do so again whenever that policy changes.
Google’s Gemma terms illustrate the mechanism precisely. The agreement forbids the uses set out in a separately maintained Prohibited Use Policy, incorporated by reference; it requires distributors to include those use restrictions “as an enforceable provision” in agreements with their own recipients and to notify subsequent users; and it states that Google “reserves the right to restrict (remotely or otherwise) usage of any of the Gemma Services that Google reasonably believes are in violation of this Agreement” [5]. Every one of those is a coherent product decision. Together they also mean that the terms travel with the artefact through every fork and derivative, that they are defined by a document the licensor can revise, and that the licensor retains a residual claim on how a downloaded artefact is used.
The second family is the user-scale restriction. Meta’s Llama 3.1 Community License grants broad rights, then carves out an exception: a licensee whose products had more than 700 million monthly active users in the calendar month preceding the version release date “must request a license from Meta”, which Meta may grant or withhold at its discretion [4]. The same licence requires prominent display of “Built with Llama”, and requires that any model trained or improved using Llama materials carry “Llama” at the beginning of its name; an Acceptable Use Policy is incorporated by reference [4].
Read as engineering, none of this is onerous. Read as a licence, it fails the Open Source Definition twice over: clause 5 forbids discrimination against persons or groups, and clause 6 forbids restriction by field of endeavour [2]. The scale threshold discriminates against a specific and identifiable group of licensees, and the acceptable-use incorporation restricts fields of endeavour.
The reason this is substantive rather than pedantic comes down to what a recipient can plan around. Under a licence like Apache 2.0 — which OpenAI used for gpt-oss-120b and gpt-oss-20b [6] — a downstream builder can determine their obligations by reading a fixed document once. Under a licence that incorporates a revisable use policy and reserves a remote restriction right, they cannot; obligations depend on the licensor’s future conduct. That is a difference in kind, not degree, and it is exactly the difference the software definitions were written to capture. It is also why the vocabulary matters commercially: a firm that standardises on a model under such terms has accepted a counterparty relationship it may believe it has exited.
Note also what these licences do not do. None of them appears to reach the weights themselves as a matter of settled law — whether model parameters attract copyright at all is unresolved in most jurisdictions, and a contract-based restriction is only as strong as its enforceability against a party who never affirmatively accepted it. Treat that as an open legal question, not as a loophole to rely on.
The definition fight, characterised rather than settled
In October 2024 the Open Source Initiative published version 1.0 of an Open Source AI Definition. It frames openness as four freedoms — to use the system for any purpose without permission, to study how it works and inspect its components, to modify it for any purpose including changing its output, and to share it with or without modifications — and specifies three required components: the model parameters, including where applicable intermediate checkpoints and optimiser state; the complete source code used to train and run the system; and “data information”, meaning sufficiently detailed information about the training data “so that a skilled person can build a substantially equivalent system” [1].
The third component is where the disagreement lives, and it is a real one.
The stricter critique holds that data information is not data, and that a definition permitting the substitution has given away the thing that made “open source” meaningful. Bradley Kuhn, writing for the Software Freedom Conservancy on the day of publication, argued that the definition “fails to require reproducibility by the public of the scientific process of building these systems”, and that OSI published prematurely given how much harder the analogy to source code is for a system “built by collapsing data … into a table of floating point numbers” than for compiled software [19]. The empirical companion to this position is the open-washing literature: Liesenfeld and Dingemanse assessed roughly four dozen generative systems against fourteen separate dimensions of openness and found that many systems marketed as open source were open weight at best, with training and data-refinement practices routinely undocumented [10].
The more permissive critique runs the other way: that a single pass/fail bar excludes releases that deliver most of the practical benefit, and that a graded framework describes the landscape better. Benhamou and Reymond characterise the definition as a “take it or leave it” approach and note the risk that “only a subset of AI projects” will be compatible with it, pointing to tiered alternatives such as the Linux Foundation’s Model Openness Framework, which classifies releases by which components are provided under which licences rather than admitting one category [20, 12]. This position also has an empirical companion — Solaiman’s release gradient sets out six levels of access from fully closed through staged, hosted, cloud-based and downloadable to fully open, and argues that the interesting engineering and governance questions live between the poles rather than at them [11].
There is a substantive point of agreement worth naming, because it is easy to miss in the heat: both sides accept that openness is composite. Liesenfeld and Dingemanse argue explicitly that useful conceptions must be composite and gradient [10]; the Model Openness Framework operationalises exactly that [12]. The dispute is not really about whether openness has parts. It is about whether a binary label should be defended at a particular line, given that labels do regulatory and commercial work that gradients do not.
That regulatory work is now concrete. Under Article 53 of the EU AI Act, providers of general-purpose AI models released under a free and open-source licence are exempted from the technical-documentation and downstream-information obligations of paragraph 1(a) and 1(b) — but must still maintain a copyright-compliance policy and publish a sufficiently detailed summary of training content, and the exemption does not apply at all to models classified as carrying systemic risk [18]. Once a definition gates an exemption, the incentive to claim it exists independently of the engineering, which is what gives the open-washing charge its force regardless of which definitional line one prefers.
What weights in hand do not buy
Suppose the most permissive case: weights, code, data, and recipe, all under an unrestricted licence. Several asymmetries survive intact, and the failure to account for them is the most common analytical error in optimistic accounts of open release.
Compute to train, as distinct from compute to tune. The QLoRA result is real and important, but it is a result about adaptation, not creation [15]. Fine-tuning an existing model on one accelerator and pretraining a frontier model are separated by many orders of magnitude in capital. Widder, Whittaker and West make this the centre of their analysis: they identify transparency, reusability and extensibility as the genuine affordances of open models, and argue that these do not touch the underlying concentration, because the computational infrastructure, the data pipelines and the labour that produce frontier systems remain held by a small number of firms [9]. Their conclusion — that “openness alone does not perturb the concentration of power in AI” — is a claim about structure, and it is compatible with open weights being individually useful.
Data to evaluate. Auditing a model requires evaluation material the model has not seen, and constructing it is expensive and expires quickly. The Foundation Model Transparency Index scored ten major developers against one hundred indicators spanning upstream resources, model properties and downstream use, and reported that no developer disclosed significant information about the downstream impact of its flagship model — user numbers, affected sectors, or redress mechanisms [17]. Releasing weights does not produce that information; it is a different artefact entirely, and one that only the operator of a deployed service holds.
Expertise to align. Post-training behaviour is not a property that survives arbitrary modification. Qi and colleagues showed that safety alignment can be stripped from a strongly aligned model with roughly ten adversarial examples for under twenty US cents through a hosted fine-tuning interface, and — more surprisingly — that fine-tuning on entirely benign, commonly used datasets also degrades safety behaviour, though less severely [16]. Two things follow. Anyone modifying an open-weight model inherits a re-alignment problem they may not know they have. And, importantly for the governance argument, the mechanism was demonstrated against a closed model through an API, so it is not a property of open weights as such.
The governance argument, from both sides
This section characterises positions. It does not adjudicate between them.
The case for restricting availability rests on irreversibility and on the removability of safeguards. Once weights are distributed they cannot be recalled, patched, monitored or rate-limited; whatever refusal behaviour was installed can be removed cheaply by anyone with the file [16]. On this view, a capability judged acceptable behind a monitored API is a different object once it is a downloadable artefact, because the deployment controls were doing part of the safety work.
The case against restricting rests on marginal risk. Kapoor and colleagues propose assessing open foundation models not against a world with no such capability but against the counterfactual of what an adversary could already do with existing tools, and — surveying misuse domains including cyberattacks and biosecurity — report that the available evidence is insufficient to establish that open models meaningfully raise risk above that baseline [8]. On this view, restriction imposes certain costs to research access, competition, reproducibility and independent scrutiny in exchange for speculative benefits.
Both sides now cite the same class of evidence, which is a sign the argument is maturing. OpenAI’s own pre-release work on gpt-oss adopted the marginal-risk frame and tested it adversarially: the authors fine-tuned the model specifically to maximise biological and cyber capability, then compared the result against existing open models and against their own closed models, reporting that the maximised model “may marginally increase biological capabilities but does not substantially advance the frontier” and underperformed OpenAI o3 [7]. That is a vendor evaluation of a vendor’s own release, conducted before it, and should be read as such — the methodology is public and checkable, the incentives are not neutral, and the conclusion is specific to two models at one point in time. It is nonetheless the shape the empirical argument has taken: not “is this dangerous” but “is this more dangerous than what is already downloadable”.
What neither side has is a settled measurement. Kapoor and colleagues describe the gap as a failure of existing scholarship to characterise marginal risk adequately, and frame their contribution as clarifying the disagreement rather than resolving it [8]. Anyone claiming the question is closed in either direction is ahead of the evidence.
Questions that replace the label
The practical upshot is that “is it open” is not a usable question. Six replacements are, and each has a checkable answer.
Which artefacts shipped — weights only, or weights plus training code, data, and recipe? Under which licence is each artefact released, since they frequently differ? Does the licence restrict fields of use or classes of user, and does it incorporate a policy the licensor may revise? Do the restrictions bind downstream recipients of derivatives? What is the evaluation and safety documentation, and was it produced by the releaser or independently? And, if reproducibility matters to you: could a competent team rebuild a substantially equivalent model from what was published — which is the operative test in the OSI definition [1] and the axis along which the Model Openness Framework grades [12]?
Predictions, with disconfirmation conditions
These are forecasts, separated from the sourced analysis above. Horizon: 8 August 2029. They assume no major jurisdiction bans open-weight release of frontier models and no capability discontinuity that redraws the risk debate.
One. “Open weights” will continue to displace “open source” as the industry’s default term for weights-only releases, and major releasers will increasingly use it in their own announcements rather than only in critiques of them. Indicator: the phrasing on release pages from the five largest weight releasers. Disconfirmed if a majority of such releases in 2029 still describe weights-only distributions as open source.
Two. Bespoke community licences will not converge on a standard. The pressure runs the other way: each releaser’s terms encode its own commercial position, and a shared licence would forfeit that. Indicator: the count of distinct non-OSI-approved model licences in wide use. Disconfirmed if three or more of the largest releasers adopt a single common non-OSI licence text.
Three. Regulatory definitions, not community definitions, will settle the operative meaning of the term, because exemptions attach to them. The EU AI Act’s open-source carve-out is the current instance [18]. Indicator: whether compliance guidance and vendor legal documentation cite statutory definitions in preference to the OSI definition. Disconfirmed if the OSI definition is adopted by reference in the implementing guidance of a major jurisdiction.
Four. Fully open releases — weights, data, code and recipe together, in the manner of OLMo 2 [14] — will remain a minority of releases by count while becoming the standard for work that claims scientific reproducibility. Indicator: the proportion of accepted papers at major venues releasing training data alongside weights. Disconfirmed if fully open releases become the majority of significant model releases, or if reproducibility norms at major venues do not tighten.
The stint, not the gate
The gate on a common is not the interesting object; the stint is. A stint says how many beasts, of what kind, on which land, held by whom, enforceable by what mechanism when someone exceeds it. The gate merely enacts it.
Model releases are read the wrong way round for the same reason. The announcement describes the gate — open, closed, ajar — while the operative facts are in the stint: which artefacts, under which terms, revisable by whom, binding on which downstream parties, sufficient for which of run, modify, audit, reproduce. Those facts are all published. They are simply published somewhere other than the headline.
Two grazings, equal in right, produce visibly different ground when one party can put ten times the stock on it. That is not an argument against the common, and it is not an argument for it. It is the observation that the licence is one input among several, and that reasoning about openness from the licence alone will systematically mispredict what actually happens on the land.
