- Open weights and open source AI are different things. Almost every model marketed as open source is the first one.
- The Open Source AI Definition 1.0 requires three components: data information, the complete training and running code, and the parameters.
- It deliberately stops short of requiring the training dataset itself, asking instead for enough detail that a skilled person could build a substantially equivalent system.
- OSI states that open weights withhold the training code and the dataset, so the freedoms to study, modify and share cannot be fully exercised.
- Real licences carry clauses that can revoke your grant. Llama 3.1 requires a separate licence from Meta above 700 million monthly active users.
- The same licence requires you to display "Built with Llama" and to prefix any distributed derivative model name with "Llama".
- Read the licence before the product exists. Naming and attribution obligations are painful to retrofit into a shipped product.
You picked a downloadable model because it was open, built a product on it, and only now has somebody asked what the licence permits. That order is the wrong way round, and it is the usual order.
The confusion is not really your fault. Two terms are used interchangeably in announcements, in documentation and in conversation, and they describe materially different releases. One of them is a definition with requirements. The other is a distribution method with whatever terms the publisher chose to attach.
What does open source AI actually require?
Three components, all present, under terms that permit four freedoms.
The Open Source AI Definition 1.0 sets out what the preferred form for modifying a machine learning system has to contain. Data information, meaning sufficiently detailed information about the training data that a skilled person can build a substantially equivalent system. Code, meaning the complete source used to train and run the system. Parameters, meaning the weights and other configuration settings.
Data information is more demanding than it sounds. The definition asks for a complete description of all training data covering provenance, scope, characteristics and labelling procedures, a listing of publicly available training data and where to get it, and a listing of data obtainable from third parties including sources that charge a fee.
Over that sits the freedom test: use the system for any purpose without asking permission, study how it works and inspect its components, modify it for any purpose, and share it with or without modifications.
Why is the training data itself not required?
Because requiring it would mean almost nothing could ever qualify, and the definition made a deliberate compromise rather than becoming ornamental.
Foundation model training data is tangled in copyright, in contracts with data suppliers and in privacy law. A publisher that scraped the web cannot redistribute what it scraped. One that licensed a corpus is contractually barred from passing it on. Insisting on the dataset would have excluded every large model from the category permanently, which would have made the definition a statement of principle rather than a usable standard.
So the definition asks for the recipe rather than the ingredients. Enough detail to rebuild something equivalent, with unshareable data disclosed as unshareable. Reasonable people disagree about whether that compromise went too far, and it is worth knowing it was a compromise rather than an oversight.
So what are open weights?
The parameters, and usually nothing else, under a licence the publisher wrote themselves.
OSI is direct about the gap. Its page on open weights states that such releases do not include the training code, meaning the scripts or frameworks used to create and curate the dataset, nor the training dataset, nor full detail about sources, cleaning and balancing. Without the preferred form for making modifications and the practical means to use it, the freedoms to study, modify and share cannot be exercised in full.
Its verdict is measured rather than dismissive. OSI describes open weights as a lesser evil than completely proprietary AI while holding that accountability requires every part of the pipeline, from initial dataset to final parameters, to be open to scrutiny.
That framing is useful for a founder because it separates two questions people merge. Can I run this myself, privately, without asking anyone? Open weights usually give you that. Can I understand, reproduce or audit how it came to behave as it does? Open weights generally do not.
What clauses should you actually check?
Six, and each has a question that takes a minute to answer and a consequence that can take a year to unwind.
| Clause type | The question to ask | What it costs you if you miss it |
|---|---|---|
| Acceptable use policy | Is it incorporated by reference, and does my use case appear in it | A prohibited use voids the grant, and the policy can be updated without the licence changing |
| Scale threshold | Is there a user or revenue level above which I must ask for a separate licence | Success triggers a renegotiation at the moment you have least leverage |
| Naming of derivatives | Must a fine tuned model I distribute carry the vendor name | Your product name is partly chosen for you, and retrofitting it is a rebrand |
| Attribution display | Where exactly must the notice appear | A shipped interface needs changing, and compliance becomes a design constraint |
| Outputs used for training | May I use this model's outputs to train another model | A distillation strategy you planned may be barred outright |
| Indemnity and warranty | Is there any, and does it cover infringement claims | Almost always none, so the infringement risk sits entirely with you |
These are not hypothetical. Take one widely used licence as a worked example, because reading a real one beats reading a summary.
What a real model licence looks like
The Llama 3.1 Community License Agreement is instructive precisely because the model is commonly described as open source. Three of its clauses land directly on the checklist above.
Its Additional Commercial Terms provide that if, on the version release date, the monthly active users of products or services made available by or for the licensee exceeded 700 million in the preceding calendar month, the licensee must request a licence from Meta. That is a scale threshold, and while few readers will approach it, the pattern is what matters: a grant that stops applying at a size the publisher chooses.
Its attribution requirement obliges anyone distributing the materials to prominently display "Built with Llama" on a related website, user interface, blog post, about page or product documentation. That is a design constraint on your product, not a line in a file nobody reads.
Its naming requirement goes further. If you use the materials to create, train or fine tune an AI model that you then distribute, you must include "Llama" at the beginning of that model's name. A company that spends six months building a differentiated fine tune discovers its product name has a mandatory prefix.
None of this makes the licence unreasonable. It makes it a licence with terms, which is exactly the thing the phrase open source implies you do not have to worry about.
Why do publishers write their own licences at all?
Because a standard software licence answers questions a model does not raise, and raises none of the ones a model publisher worries about.
Apache 2.0 was written for source code. It has nothing to say about whether you may use a program to generate training data for a competing program, because that is not a question source code poses. It has nothing to say about capability misuse, because a library cannot be prompted to help with something dangerous. A model publisher facing both concerns either accepts that a standard licence covers neither, or writes a bespoke one that does.
Two motives sit behind most bespoke terms and they are worth separating, because they age differently. The first is competitive: scale thresholds and restrictions on training other models exist to stop a rival building directly on the release. The second is reputational and regulatory: acceptable use policies exist so the publisher can point at a document when the model is misused. The first kind tends to loosen as a market matures. The second tends to tighten.
Knowing which motive produced a clause helps you predict it. A restriction that protects a commercial position may be renegotiable if you ask. A restriction that exists so the publisher can demonstrate responsibility to a regulator will not be.
What changes if you only serve the model?
Most of the obligations fall away, and this is the single most useful lever in the whole area.
Distribution is the trigger in nearly every model licence. Handing someone the weights, publishing a fine tune, or shipping a model file inside a downloadable application puts you squarely inside the naming and attribution clauses. Running the model on your own servers and returning predictions over an interface usually does not, because you have distributed nothing.
That distinction is worth designing around deliberately. A team that planned to publish its fine tuned weights, and discovers the naming clause late, can often achieve the same commercial outcome by serving the model instead. The product looks identical to a customer. The compliance surface is materially smaller.
The caveat is that some licences reach further, attaching conditions to outputs or to hosted use specifically. That is exactly why the routine below starts with opening the file rather than assuming the common case applies to you.
Does any of this matter for a small business?
Three of the six clauses matter regardless of size, and they are not the ones that get attention.
The acceptable use policy matters immediately, because it is usually incorporated by reference and can be revised independently of the licence you agreed to. If your product sits near any boundary in that policy, you are exposed to a document that can change without your consent.
The attribution and naming clauses matter at any scale, because they attach to distribution rather than to revenue. A one person business shipping a fine tuned model is caught by them just as a large one is.
The rights over outputs matter if you plan anything clever. Using a strong model to generate training data for a smaller cheaper one is a standard technique, and whether it is permitted varies by licence. Check before designing around it.
The scale threshold, honestly, will not affect you. It is worth knowing about because it reveals the shape of the bargain, and because thresholds in other licences sit far lower than 700 million.
How does this compare with owning your application code?
They are separate questions and conflating them causes real mistakes.
A model licence governs the model. It says what you may do with the weights, with derivatives of them and sometimes with their outputs. It has nothing to say about the application you wrapped around it, which is yours under ordinary copyright as the author.
The distinction matters when you are assembling a product from parts. Your own code can be entirely yours while the model inside it carries obligations, and the reverse arrangement exists too. It is the same separation we drew for generated media, where a vendor clause about output ownership cannot change what copyright law says you actually hold in a generated image. Contract and copyright answer different questions.
For anyone building a storefront rather than a model, the practical implication is that ownership of what you ship is a property of how the thing was assembled. It is why we hand over the generated code outright when you build an online store with AI, and why the licence on any model in the chain is a separate item to check rather than something that ownership of the code resolves.
Why the label is worth fighting over
Because it is doing work that the terms underneath it do not support.
Open source carries thirty years of accumulated meaning in software procurement. A legal team that reads open source in a dependency list applies a set of assumptions: no usage restrictions, no revocation, no obligations beyond attribution of the licence text. Those assumptions are sound for an OSI approved software licence and unsound for most model licences.
The scale of the ecosystem makes the sloppiness expensive. Stanford's 2026 AI Index chapter on research and development records open source AI development continuing to scale, with 5.6 million projects on GitHub and Hugging Face uploads tripling since 2023. At that volume, a term that means two different things is not a semantic quibble. It is a category of procurement error repeated across a very large number of projects.
A practical routine before you commit
Open the licence file, not the announcement page. The blog post says open. The file says what you may do.
Search it for the words users, revenue, name, display, acceptable and outputs. Those six searches surface almost every clause on the table above in about two minutes.
Check whether the acceptable use policy is a separate document incorporated by reference, and if so, save a dated copy. Knowing what it said on the day you agreed is worth something if it later changes.
Decide whether you will distribute a fine tuned model or only serve it. Distribution triggers most of the obligations. Serving predictions from a model you host triggers far fewer, and that single design decision changes your compliance surface more than the choice of model does.
Finally, write down which model you chose and under which licence version. Model licences get revised between releases, and a year from now you will want to know which one you actually accepted. That record is also what makes it cheap to move, a point we made about planning for the model you use being deprecated. Portability is a licensing question as much as a technical one, and comparing candidates on their terms rather than only their benchmarks is part of the work we set out in the comparison of open models.
Some models genuinely are released under OSI approved licences such as Apache 2.0 or MIT, applied to the weights. That is a stronger position than a bespoke community licence, though it still does not make the release Open Source AI under the definition above unless the data information and training code accompany it. Two different bars, and a release can clear the lower one without approaching the higher.
The short version
Open source AI is a definition with three required components and four freedoms. Open weights is a downloadable file with terms attached. Most things called the first are the second.
That gap is manageable once you know it exists. Read the licence before you build, search it for the six clause types, and decide early whether you will distribute a derivative or just serve one. The cost of getting this wrong is not a fine. It is discovering that your product name, your interface and your distillation plan were all decided by a document you did not read.