This article is journalism and analysis, not legal advice. Licenses are revised, and the terms attached to any specific model can change after publication. Read the primary license file yourself, record the date you accessed it, and consult qualified counsel before you deploy.
The claim that keeps repeating
A lab publishes a model. The announcement describes it as the best open source LLM available. The weights appear on a hosting platform. And then the argument starts — a developer reading the license file, an advocacy group, or a competing lab points out that the description may not match the paperwork.
Most coverage of these releases ranks models on benchmarks. This piece ranks nothing. It is a predeployment rights audit: the question that determines whether you can ship is not "how does it score?" but "what am I allowed to do with it?"
Three terms do most of the work in that question, and they are not synonyms:
- Open source is a term with an established meaning in software, maintained by the Open Source Initiative (OSI), covering rights such as free redistribution, access to source, permission for derived works, and non-discrimination in use; for AI systems, OSI has published a separate Open Source AI Definition that asks what must be available beyond the weights.
- Open weights means the trained parameters can be downloaded and run, under whatever terms the provider chose to attach — a statement about availability, not about rights.
- Open access (or gated download) means the weights exist and may be obtainable, but only after registration, acceptance of terms, approval, or a regional eligibility check.
A single release can be open weights and open access without meeting the software or AI definitions of open source, and a provider's marketing language does not settle which of the three you are dealing with. The license file does.
Why "open source" carries weight in AI marketing
The term "open source" was adopted in the software world in 1998, building on an older free software movement and older traditions of collaborative development. Whatever its precise history, the phrase now signals to most readers that a thing is inspectable, forkable, and free to build on.
That signaling value is the plausible reason — this is our analysis, not a documented statement of intent by any provider — that the phrase appears on releases whose terms are narrower than the phrase implies. Whether any given release deserves the label is a question about its license text and about what else the provider disclosed, not about its announcement copy.
What readers usually assume the label guarantees
In practice, most people hearing "open source model" assume four things: that they can download it, run it on their own hardware, change it, and sell a product built on it without asking permission. Some downloadable models grant all four. Others grant the first two and attach conditions to the rest.
The three rights that actually matter
Strip away the vocabulary and a license evaluation comes down to three questions. Can you modify the model — fine-tune it, quantize it, distill it, merge it? Can you redistribute it — hand the weights, or a derivative of them, to someone else? Can you commercialize it — use it in a product that earns revenue, at whatever scale you reach? A license can grant one, two, or all three, and it can attach conditions to each independently.
Open source, open weights, open access: the longer version
The software definition and the AI definition are not the same test
The OSI maintains the Open Source Definition, a set of criteria a software license must meet. Among them are free redistribution, availability of source code, permission for derived works, and no discrimination against persons, groups, or fields of endeavor. That definition governs licenses.
The Open Source AI Definition (OSAID) is a different instrument and asks a different question. It is addressed to an AI system, not only to a license, and it concerns whether the recipient is given the freedoms to use, study, modify, and share the system — which in turn requires access to the preferred form for making modifications to that system, not just the weights. The practical consequence for readers is important: applying an OSI-approved software license to a weights file does not by itself establish that the resulting AI system meets OSAID. Conversely, a system could disclose a great deal and still fall short if the accompanying terms restrict what recipients may do.
Before relying on either definition in a compliance argument, retrieve the current published text from OSI, note its version and publication date, and record the date you accessed it. Both documents are maintained and versioned, and this article does not reproduce their clause numbering.
Open weights in practice
Open weights describes the common case: the trained parameters are downloadable and runnable, but the governing terms are written by the provider rather than drawn from an established open source license. Those terms may be generous. They may also condition the grant on scale, use, naming, or downstream behavior. You cannot tell from the availability of a download link.
Open access and gated download
A gate does not by itself make terms restrictive. It does mean there is a document you agreed to. If you clicked through a form to obtain weights, you have entered into something, and you should know what it says and be able to produce a copy of it later.
Where training data, code, and recipes fit in
A release can include any subset of: weights, inference code, training code, data-processing scripts, evaluation harnesses, and the training data itself or a description of it. Weights-only releases are common enough that readers should expect them rather than be surprised by them.
The reasons providers give for withholding data vary. Copyright exposure over scraped corpora, third-party licensing on purchased data, privacy obligations, and competitive advantage in data curation all appear in public discussion of releases. This article does not attribute any particular motive to any particular provider. The practical effect, whatever the reason, is the same: you cannot fully reproduce, audit, or independently verify the model, and any claim you make downstream about what it was trained on rests on the provider's word.
The license families you will actually encounter
The categories below are recognition aids. They are not a ranking, and membership in a category tells you less than reading the specific document does.
Permissive OSI-approved licenses. The Apache License 2.0 and the MIT License are long-established, OSI-approved software licenses that appear on model releases. Apache 2.0 includes an express patent grant and a patent-retaliation provision; MIT is shorter and grants broadly with minimal conditions. Both permit commercial use, modification, and redistribution subject to notice requirements. Two qualifiers matter. First, this article makes no claim about how frequently each license appears across model releases; that would require a defined, reproducible survey we do not have. Second, check what the license covers in the specific release — a repository may apply one license to code and different terms to weights, documentation, or datasets, and a provider may publish a usage policy alongside a permissive license. Whether that policy forms part of your agreement depends on how the release documents connect it to the grant.
Custom community licenses. Several labs ship bespoke licenses written for their own release, often named after the model family. These typically grant broad rights and then add specific conditions — scale thresholds, naming requirements, use restrictions. They are readable, but they are not interchangeable with each other or with anything you reviewed for a different family. Read each one as a new document.
Responsible AI licenses. The Responsible AI License (RAIL) effort produced a family of licenses, not a single text, and the variants differ in what artifacts they cover and how broad the underlying grant is. What they share is the attachment of behavioral use restrictions — lists of prohibited applications — to the grant. Because the Open Source Definition disallows discrimination against fields of endeavor, use-restricted terms sit outside that definition by design rather than by oversight. If you are evaluating a RAIL-licensed release, identify the specific variant and read its restriction annex against your actual product.
Creative Commons licenses. CC licenses appear on models, datasets, and documentation. They span a wide range, from CC BY through non-commercial (NC) and no-derivatives (ND) variants that would block ordinary product use. "It's Creative Commons" tells you nothing until you know which CC license, and which artifact it attaches to.
Research-only and non-commercial terms. Some releases limit permitted use to research or evaluation. Whether a particular activity falls inside those limits depends entirely on how the governing terms define research, evaluation, commercial use, and internal use — and those definitions differ between releases. Do not reason from the general shape of the category. Compare the specific activity you have in mind against the specific definitions in the document, and take advice before using research-only materials in business operations. If your prototype has a plausible path to production, plan for the possibility that the model powering it cannot come along.
Seven clauses that can quietly limit you
Each of these clause types appears in real model licenses. This article describes the pattern and its business consequence; it does not attribute any specific clause number, threshold figure, or wording to any named model, because doing so requires the primary license file open in front of you. When you run the screen in the next section, the exercise is to find each pattern — or confirm its absence — in the document that governs your deployment, and to record where you found it.
1. Scale thresholds. Some licenses condition the grant on staying below a threshold, commonly expressed in monthly active users or revenue, above which the licensee must seek a separate commercial agreement from the provider. What happens above the threshold varies by document: some require a negotiated license before continued use, others describe a different consequence. The business consequence is the same in shape — your terms can change precisely when your product succeeds. Check whether the threshold counts your users or your customers' users, and what the document says must happen once it is crossed.
2. Acceptable-use policies referenced by the license. The license states that the grant is subject to a policy hosted at a separate URL. Whether that policy is effectively incorporated into your agreement, and whether the provider may revise it unilaterally, depends on the wording of both documents and on applicable law — this is a question for counsel, not a settled rule. Practically: treat the linked policy as governing, archive a copy on the date you accept it, and map its prohibited uses against what your product actually does. Consumer-facing deployments are where this bites first; the abrupt withdrawal of a shipped AI feature after public objection, as in Meta's removal of a controversial Instagram AI feature, illustrates how quickly acceptable-use questions become product questions.
3. Naming, branding, and attribution. Clauses that require you to display a notice, retain a legal notice file, or include the model family name in the name of a derivative you distribute. Cheap to comply with, expensive to discover during a launch review. If you fine-tune and rename, check whether the name is yours to choose.
4. Restrictions on training other models with outputs. Terms vary materially here. Some releases place no restriction on what you do with generated outputs. Others prohibit using outputs to train or improve other models, sometimes limited to competing models and sometimes drawn more broadly. If your roadmap includes distillation, synthetic data generation, or an eventual in-house model, locate this clause before you generate the first dataset — and note whether the restriction covers models you train for yourself as well as models you distribute.
5. Field-of-use and jurisdiction limits. Restrictions on application domains, or on availability in particular territories or to particular entities. Export control and sanctions obligations may apply independently of the license text and are not waived by a permissive license. Geopolitical constraints on AI distribution move fast — the regulatory path that shaped Apple Intelligence's approval in China with Alibaba's Qwen AI is a reminder that where a model may be offered is a separate question from what its license permits.
6. Termination and patent retaliation. Licenses commonly provide for termination of rights on breach; the trigger, notice, and cure provisions differ document to document. Apache-style patent retaliation ends the patent grant if the licensee initiates patent litigation over the licensed work. The practical question to answer before deployment is what your document says happens to systems already in production if the grant ends.
7. Terms that can change between releases. Two distinct things get conflated here, and they should not be. First, a provider may release a new version of a model under different terms; the terms you accepted continue to govern the copy you obtained under them. Second, a document referenced by the license — an acceptable-use policy, an annex — may be revised in place, and whether that revision reaches an existing deployment depends on the wording and on applicable law. This article does not assert that any named provider has retroactively changed terms. The defensible response to both possibilities is the same: archive the exact version of every document you accepted, on the date you accepted it.
How to run a predeployment license screen
Treat this as a 20-minute initial screen, not a legal review. Its purpose is to produce a record and to surface the questions that need counsel. Any of the following findings should escalate to legal before deployment: a scale threshold you might cross, a use restriction that touches your product's actual function, a redistribution requirement, an output-training restriction where your roadmap involves training, or an inability to determine which artifacts a license covers.
- Find the authoritative license file, not the blog post. Go to the official repository or model page and open the actual LICENSE, LICENSE.txt, or the license section of the model card. Announcement posts summarize; they do not govern. Record the URL and the date you accessed it. Where a repository carries commit history, note the commit or revision you are reading.
- Read the definitions section first. Bespoke licenses define terms such as "Licensee," "Derivative," "Output," and "Materials" in ways that change the meaning of every clause that follows. Time spent here prevents misreading everything downstream.
- Trace every document referenced by the license. Follow each linked policy, annex, and terms page. Save copies with the date. Note which of those documents the provider appears able to revise without issuing a new release, and flag that as a standing risk rather than a one-time check.
- Check what is missing. Is training data described? Is training code available? Are evaluation details published? Absence is not a violation, but it determines what you can honestly claim to your own customers and regulators.
- Compare against the previous version. If the model family has shipped before, compare the current license to the prior one using repository history or archived copies. Describe changes from documents, not from memory.
- Document your findings. Produce a short record: model and version, license name and URL, access date, the three core rights and their conditions, referenced policies, and open questions for counsel. Attach it to the procurement file alongside your software bill of materials. The record does not speed up legal review by any measured amount — we make no such claim — but it makes the review reproducible and preserves the basis on which approval was given.
When the label gets contested
OSI maintains definitions, and it has publicly engaged in the argument over how the term "open source" is applied to AI releases. Voices from the free software tradition, including the Free Software Foundation, have made related arguments about terminology. The structure of the objection is not that restricted releases are illegitimate; it is that describing them as open source drains the term of meaning. If you intend to quote either organization's position, quote it from their own published statement and date the reference — this article summarizes the shape of the dispute rather than putting words in anyone's mouth.
"Openwashing" is the label critics apply to that drain: presenting a restricted release in the vocabulary of an unrestricted one. The stakes are partly reputational and partly regulatory.
The EU AI Act contains provisions that treat AI components and general-purpose AI models released under free and open-source licenses differently from other releases, subject to conditions and to exceptions that preserve certain obligations. Those provisions are narrower than "open-source models are exempt," and this article does not paraphrase their scope. Before relying on any carve-out, read the official published text of the Regulation, identify the specific articles and recitals that address free and open-source AI, confirm which obligations continue to apply to your situation, and take advice. The point for a general reader is structural: once a regulatory distinction turns on the phrase, the boundary of the term stops being a community argument and becomes a compliance question.
Attribution matters throughout. Nothing in this article declares a particular model open source or not open source. That is a conclusion to be drawn from a clause, by a named party, with the clause cited.
What this means for your stack
Rather than a general rule, work through the questions below against the specific document you screened.
Does your modification produce something the license calls a derivative? Read the definitions section. Different licenses treat full fine-tunes of the weights, separately distributed adapters, merged models, quantizations, and distilled models differently — some sweep them all into one definition, others do not mention several of them. Training an adapter on top of someone else's weights does not automatically escape the terms, and it does not automatically fall inside them either. The answer is in the definition, not in the technique's name.
Are you distributing copies of the weights, or offering access to a service? Shipping an on-premises appliance, publishing a fine-tune to a public hub, or embedding weights in a downloadable product usually raises redistribution conditions: passing along the license, preserving notices, and in some cases binding recipients to the same terms. Operating a hosted service that your customers call over an API is a different question, and licenses treat the two differently. First confirm that redistribution is permitted at all; then confirm what must travel with it. Whether and how your recipients become bound depends on the license and on how you structure delivery — that is a question for counsel, not an assumption to build a product around.
What do you distribute that is not weights? Datasets generated from a model's outputs, evaluation results, and derived documentation may be governed by different clauses than the weights themselves. Check each artifact separately.
Are hosted variants governed by different terms? The same model offered through a cloud provider's API is governed by that provider's service agreement, which may be more or less permissive than the weights license. Deploying "the same model" two ways can mean accepting two different contracts, with two different sets of obligations flowing to your customers.
Is a permissive model worth a benchmark tradeoff? This is an analytical judgment rather than a rule, and it belongs to you. A model a few points behind the leader, under a permissive OSI-approved license, with no scale threshold and no output-training restriction, may be the cheaper choice once you price in legal review, renegotiation at scale, and the risk of a term change between releases. Capability claims move quickly — our coverage of releases such as Kimi K3 and the strategic questions around it shows how fast the leaderboard conversation turns over. Licensing moves more slowly and matters longer.
Have you accounted for the security surface as well as the license? License terms are one part of a deployment review. The operational questions — what a model touches, what it can be made to do, and how it fails — sit alongside them, and our reporting on what AI changes about cybersecurity work and on the industrialization of criminal tooling covers ground your risk register will need regardless of which license you land on.
Frequently asked questions
What is the difference between an open source LLM and an open weights model?
Open source refers to an established definition — OSI's for software, and its separate Open Source AI Definition for AI systems — covering redistribution, modification, and non-discrimination. Open weights simply means the trained parameters are downloadable. An open weights release may carry custom terms restricting scale, use, or redistribution.
Does "open source" mean I can use the model commercially?
A license that genuinely satisfies the Open Source Definition cannot bar commercial fields of endeavor, though commercial use may still carry notice, attribution, or redistribution conditions. The catch is that a release described as open source may not carry such a license, or the label may cover only part of the release. Read the grant clause and any linked policy.
Can a provider change license terms after I deploy?
The terms you accepted govern the copy you obtained under them. A later release can carry different terms, and a policy referenced by the license may be revised in place — whether such a revision reaches your existing deployment depends on the wording and applicable law. Archive every document on the date you accept it and re-check at each upgrade.
Does a fine-tuned version inherit the original license?
It depends on how that license defines derivative works and whether your modification falls inside that definition. Full fine-tunes, separately distributed adapters, merges, and quantizations are not always treated identically. Read the definitions section, which is where "Derivative" is given its operative meaning, before assuming either way.
Is an acceptable-use policy binding if it is only linked?
Incorporation by reference is a standard contracting technique, and licenses commonly state that the grant is conditioned on a linked policy. Whether a particular link achieves that, and whether the policy can be revised unilaterally, is a legal question for your counsel. Practically, treat it as governing and save a dated copy.
Can I use a model's outputs to train another model?
It depends entirely on the license. Some place no restriction; others prohibit using outputs to train or improve other models, with the scope varying from competing models to any model. If distillation or synthetic data generation is on your roadmap, find this clause before you start generating.
What happens if I redistribute the weights to customers?
First confirm redistribution is permitted. Where it is, licenses commonly require you to include the license text and preserve notices, and some require recipients to accept the same terms. How obligations reach your recipients depends on the license and your delivery structure. Where redistribution is not permitted, on-premises delivery may not be available to you.
Is a research-only license enough for an internal prototype?
Only the specific document can answer that. Compare your intended activity against how that license defines research, evaluation, commercial use, and internal use, and take advice before using research-only materials in business operations. If the prototype has a path to production, plan for a model swap.
Glossary
- Open source — Software or systems distributed under terms meeting an established definition covering redistribution, modification, and non-discrimination in use; for AI systems, OSI applies a separate definition addressed to the system as a whole.
- Open Source AI Definition (OSAID) — OSI's definition for AI systems, which asks whether recipients receive the freedoms to use, study, modify, and share the system, including access to the preferred form for making modifications.
- Open weights — A release in which trained model parameters are downloadable, regardless of how restrictive the accompanying terms are.
- Open access / gated download — Weights obtainable only after registration, approval, or regional eligibility checks.
- Model card — A structured document describing a model's intended uses, limitations, evaluation, and license.
- Acceptable use policy (AUP) — A list of prohibited applications, often hosted separately and referenced by the license.
- RAIL — Responsible AI License; a family of licenses, differing by variant, that attach behavioral use restrictions to the grant.
- Creative Commons — A family of public licenses spanning permissive attribution terms through non-commercial and no-derivatives variants; the specific variant determines what is permitted.
- Derivative work — A modified version of the model as defined by the governing license; which techniques count varies between documents.
- Weights redistribution — Distributing copies of model parameters to third parties, as distinct from offering access to a hosted service.
- Commercial use rights — Permission to use a model in revenue-generating activity, which may be unconditional, conditioned, or excluded.
- Training data disclosure — Publication of the data used to train a model, or of a description of it; frequently absent from weights-only releases.
- Openwashing — Presenting a restricted release using the vocabulary of an unrestricted open source one.
- License compatibility — Whether two licenses' obligations can be satisfied simultaneously in a combined work.
- Software bill of materials (SBOM) — An inventory of components in a system, increasingly extended to include models and their license terms.
The copy-paste predeployment license screen
MODEL LICENSE SCREEN (predeployment triage - not legal clearance)
Model + version:
License name:
License file URL:
Repository commit / revision:
Date accessed:
Artifacts covered by this license (code / weights / docs / data):
RIGHTS
[ ] Modify permitted? Conditions:
[ ] Redistribute permitted? Conditions:
[ ] Commercial use permitted? Conditions:
RESTRICTIONS
[ ] Scale threshold (users/revenue)? What happens if crossed:
[ ] Acceptable-use policy referenced? URL + dated copy saved?
[ ] Naming / attribution / notice requirements?
[ ] Output-based training restricted? Scope:
[ ] Field-of-use or territorial limits?
[ ] Termination / patent retaliation terms?
DEFINITIONS TO QUOTE VERBATIM
[ ] Derivative:
[ ] Output:
[ ] Materials:
DISCLOSURE
[ ] Training data described?
[ ] Training code available?
[ ] Evaluation details published?
CHANGE CONTROL
[ ] Prior version compared?
[ ] Archived copies stored with procurement file?
[ ] Re-check scheduled at next upgrade?
ESCALATE TO COUNSEL IF ANY OF:
[ ] Threshold you might cross
[ ] Use restriction touching your product's function
[ ] Redistribution required by your delivery model
[ ] Output-training restriction plus training on the roadmap
[ ] Unclear which artifacts the license covers
OPEN QUESTIONS FOR COUNSEL:
What to re-check at every upgrade
The license file, every document it references, the definitions section, and any scale threshold measured against your current numbers. Model upgrades are routine; license changes ride along with them and rarely get their own announcement.
Before your next model deployment, run the six-step license screen above and save the completed record with your procurement file. Then follow NewsForge for continuing coverage of AI licensing changes and model release terms.
