Dashboard

Open Weights vs Open Source AI: The Difference

Open weights vs open source AI: what the OSI definition actually requires, what a weights-only release gives you, and the licence clauses to check.

Carlo Zuercher
Carlo Zuercher
Staff Engineer, Platform
20 October 20261 min read

Open weights vs open source AI is a distinction with money attached. Open weights means you can download the trained model file and run it. Open source, as the term is formally defined for AI, means you also get the training code and enough information about the training data to rebuild something equivalent yourself. Almost every model marketed as open source today is only open weights. That is still useful, and for most builders it is enough, but it buys you less than the label suggests, and the licence attached to those weights can carry limits that no open source licence would.

The three things an open source AI release has to give you

The Open Source Initiative, the body that has maintained the definition of open source software since 1998, published version 1.0 of its Open Source AI Definition. It names three required components, and weights are only one of them:

  • Data Information. Details about the training data, including provenance, selection, labelling and processing, plus lists of publicly available and third-party sources. The definition asks for "sufficiently detailed information about the data used to train the system".

  • Code. The complete source used to train and run the system: data processing, training, testing, inference and the model architecture.

  • Parameters. The weights themselves, plus configuration such as intermediate checkpoints and the final optimizer state.

The point of requiring all three is the four freedoms the definition is built on: use the system for any purpose without permission, study how it works and inspect its components, modify it for any purpose, and share it with or without modifications. Studying a model is the one that weights alone cannot satisfy. A weights file tells you what the model concluded. It does not tell you what it read.

What a weights-only release actually lets you do

Plenty, which is why the distinction gets ignored. With weights you can run the model on your own hardware, fine-tune it on your own data, quantise it to fit a smaller GPU, serve it behind your own API, and keep every byte of inference traffic inside your own network. For a small team picking between an API and self-hosting, those capabilities are the whole decision, and the terminology is beside the point.

What you cannot do is reproduce the model. You cannot audit the training data for the licensed material, personal data or benchmark answers that may be sitting in it. You cannot retrain from scratch with one dataset removed. And you cannot verify any claim the vendor makes about what went in, because the evidence was never published.

The licence is the part that bites

Open source licences do not care who you are or how many users you have. Apache 2.0, one of the most common, grants each user "a perpetual, worldwide, non-exclusive, no-charge, royalty-free" copyright licence, with conditions on redistribution and a patent clause, and no cap on user count or field of use.

Weights shipped under a bespoke "community" or "responsible use" licence are a different instrument. The patterns worth checking before you build on one:

Clause to look for

Why it matters

Acceptable use policy

Bans specific applications. Your use case may be on the list.

User or revenue threshold

Above a stated size you need a separate commercial licence.

Naming or attribution requirement

You may be obliged to name the base model in your product.

Restrictions on training other models

Using outputs to train a competing model is often prohibited.

Licence for the weights vs the code

The repository can be Apache 2.0 while the weights are not.

That last row catches people most often. A GitHub repository with a permissive licence file sitting next to a weights download governed by something else is normal, not a mistake. Read both. We cover the specifics of what each licence family permits in AI model licences explained, and the narrower case of genuinely permissive weights in what an MIT licence on model weights means.

Why vendors use the looser word

Calling a release open source is better positioning than calling it open weights. It signals community, inspectability and the absence of lock-in, and it attracts the developers who build the ecosystem that makes a model worth adopting. The incentive is obvious and the cost of overstating it has so far been close to zero.

There is also a defensible version of the argument. Some training data cannot be republished without breaking the law, medical records being the clearest case, and a definition that demanded full data release would exclude work that is otherwise completely open. The OSI definition accommodates this by asking for information about the data rather than the data itself. Reasonable people disagree about whether that compromise still deserves the name.

How to tell which one you are looking at

Four checks, in the order that resolves fastest:

  1. Find the licence that governs the weights specifically. Not the repository licence, not the blog post. The file or model card attached to the download.

  2. Look for a training data section. If the model card describes the data only as "a diverse mixture of publicly available sources", you have weights, not open source.

  3. Look for training code. Inference code is almost always published. The training pipeline almost never is.

  4. Search the licence for a number. Any user count, revenue figure or date is a threshold you will eventually cross.

If checks two and three come up empty, the release is open weights. Use it anyway if it fits, but plan as though the vendor could change the licence on the next version, because nothing in a weights release stops them.

Does the distinction change what you should build?

For most teams, no. If your plan is to run a model you control, the practical questions are cost, latency and whether the weights licence permits your use case, which we work through in is self-hosting an open weight model cheaper than an API and in the wider trade-off between open-weight and closed models.

The distinction starts to matter when someone else has to trust your stack. Enterprise buyers, regulated sectors and anyone asking for a provenance statement will want to know what the model was trained on, and "open source" on a vendor page is not an answer you can pass along. At that point the gap between the two terms stops being pedantic and becomes a question you cannot answer.

FAQ

Is Llama open source?

Llama is released as open weights under Meta's own community licence, not an OSI-approved open source licence. The weights are downloadable, the licence carries use restrictions and a user threshold, and the training data is described rather than published.

Can I use open weight models commercially?

Usually yes, but it depends entirely on the specific licence. Weights under Apache 2.0 or MIT carry no commercial restriction. Weights under a bespoke community licence may restrict certain applications or require a separate agreement above a size threshold.

What is the difference between open weights and open source in one sentence?

Open weights gives you the finished model, open source gives you the finished model plus the recipe and the ingredient list.

Does open source AI mean the training data is public?

Not necessarily. The OSI definition requires sufficiently detailed information about the data, including its provenance and processing and lists of sources, rather than the dataset itself.

Why does the distinction matter if the model works either way?

Because you cannot audit, reproduce or fully defend a model whose training data was never described, and because a bespoke weights licence can be changed or capped in ways a real open source licence cannot. If you only need to run the thing, see how AI models work for the mechanics and stop worrying about the label.

How did this land?

About the author

Carlo Zuercher
Carlo Zuercher

Staff Engineer, Platform

Carlo works on the platform that turns prompts into running apps. He writes the engineering deep dives and the changelog notes worth reading.

Share

Get the next post in your inbox

One email a month. Product updates, engineering posts, and the best of Built with Swarmz.

I agree to receive emails about AI building tips and Swarmz product news. Unsubscribe any time.