Open Weight vs Open Source Models
Downloadable weights are not the same as an open-source licence. Some popular models carry acceptable-use restrictions, user thresholds or non-commercial terms. Here is where the line falls.
The short answer
Nearly every model people call open source is open weight: you can download and run it, and the licence may still restrict what you do next. Genuinely open-source licences — Apache 2.0, MIT — impose no field-of-use restrictions. Bespoke licences such as Meta's Llama community terms and Google's Gemma terms permit commercial use with conditions attached, while FLUX.1 [dev] forbids commercial use outright. The distinction only bites when you ship something, which is exactly when it is expensive to discover.
Open weight
Weights you can download, under terms that may limit your use.
Open source
An OSI-style licence with no restrictions on field of use.
Open weight vs Open source at a glance
| Factor | Open weight | Open source |
|---|---|---|
| Can you download the weights | Yes | Yes |
| Commercial use | Depends on the licence — sometimes conditional, sometimes forbidden | Yes, unconditionally |
| Acceptable-use policy | Common — a list of prohibited applications | None |
| Conditions on scale | Some licences add terms above a user threshold | None |
| Attribution or naming | Sometimes required for derivatives | Standard copyright notice only |
| Training data and code | Rarely published | Rarely published either |
| Examples | Llama community licence, Gemma terms, FLUX.1 [dev] | Qwen (Apache 2.0), Mistral 7B (Apache 2.0) |
Why the distinction exists
Open source has a specific meaning: no restriction on who may use the software or for what. A licence that forbids certain applications, or that adds obligations above a commercial threshold, does not meet it — however freely the files are distributed.
Most well-known 'open' models sit on the other side of that line. Their licences permit broad use, including commercial, with an acceptable-use policy attached and sometimes conditions that activate at scale. That is a reasonable thing for a licensor to do and it is not open source, which is why 'open weight' became the accurate term.
There is a second sense in which almost none of these are open source: the training data and the training code are essentially never published. You get the artifact, not the means to reproduce it. Even Apache-2.0 models are usually open in licence rather than open in provenance.
Where it actually bites
Shipping. Running a model on your own machine is unlikely to trip any of these terms. Building it into a product, serving it to customers, or distributing a fine-tune is where the licence becomes a real constraint.
Three patterns cause most of the trouble. Non-commercial licences, where FLUX.1 [dev] is the common surprise — client work counts as commercial. Naming and attribution obligations on derivatives, which several bespoke licences impose. And thresholds, where a licence adds conditions once a product passes a stated scale.
Fine-tuning inherits terms. A LoRA trained on a restricted base is governed by the base model's licence, and the fact that your adapter is small and original does not detach it. Check before you train, not after you have a customer.
Choosing on licence rather than benchmark
If the work is commercial, start by filtering to permissive licences and pick the best model from what remains, rather than picking on capability and discovering the constraint later. The Apache-2.0 field is strong enough that this costs less than it used to.
Where a bespoke licence is the right call anyway — because the model is clearly the best fit — read the acceptable-use policy properly and confirm your application is not on the prohibited list. These lists are short and specific, and they are easy to check before you build.
And prefer verifying the licence on the model's own repository over trusting a summary, including ours. Terms change between releases within the same family, and the version you downloaded is the one that governs you.
Choose Open weight when
- Personal, research or experimental work where terms rarely bind
- The restricted model is clearly the best fit and your use is permitted
- You have read the acceptable-use policy and confirmed your case
Choose Open source when
- You are building a commercial product
- You will distribute a fine-tune or a derivative
- You need certainty without a legal review for each release
- You expect scale and do not want threshold conditions to activate
Work it out for your own setup
Common questions
- Is Llama open source?
- It is open weight. The community licence allows broad use including commercial, with an acceptable-use policy and conditions that apply at large scale, which means it does not meet the open-source definition. For most projects it is permissive enough; read it if you are shipping at scale.
- Which model families are genuinely open source?
- Several ship under Apache 2.0, including the Qwen releases and Mistral 7B. Apache 2.0 and MIT are the licences to look for when you want no field-of-use restrictions.
- Does a fine-tune inherit the base model's licence?
- Yes. Training an adapter on a restricted base does not free you from its terms, and some licences explicitly govern derivatives including naming requirements. Confirm before you train.
- Can I use a non-commercial model for client work?
- No. Client work is commercial use. This catches people most often with FLUX.1 [dev], whose licence forbids it — the permissively licensed schnell variant exists precisely for that case.
Guides that go deeper
Longer reads on the concepts behind this comparison.
- Running Giant Open Models LocallyHardware sizing for DeepSeek V4, Qwen3.8 and Llama 4.Read the guide
- Quantization Guide: Q4_K_M vs Q8_0 vs FP8What each quant level costs you in memory and quality.Read the guide
- Best Local LLM Runners: Ollama vs LM Studio vs Jan vs llama.cpp vs vLLMWhich runner suits your hardware and workflow.Read the guide