Open Weight vs Open Source LLM: License Review
Open weight is not open source: weights can carry a 700M-user cap, an acceptable use policy and naming duties. Five license tiers compared, clause by clause.
An open-weight LLM publishes downloadable model weights under whatever terms its publisher chooses, while an open source LLM is released under a license (Apache 2.0, MIT) that grants use, modification and redistribution with no field-of-use restriction and no user-count cap. The gap between the two is where enterprise legal risk lives: acceptable use policies, scale thresholds, naming and attribution duties, and clauses that only bite when you redistribute. This guide gives you a five-tier license taxonomy, a clause-level comparison table for the families enterprises actually shortlist, and a ten-point procurement checklist.
This is engineering and procurement guidance from Teclops AI, not legal advice. Re-verify every fact below against the license text bundled with the exact model version you download, and clear it with your own counsel.
Is an open-weight LLM the same as an open-source LLM?
No. An open-weight LLM is one whose trained parameters are published for download; an open-source LLM is one released under terms that meet an open source definition. The Open Source Initiative’s Open Source Definition disallows discrimination against fields of endeavour, which is precisely why a model license carrying an acceptable use policy, a monthly-active-user cap, or a regional carve-out is not open source no matter how freely the weights are shared.
A second distinction trips up review boards. A model can carry an OSI-approved license on its weights and still not be “open source AI” under the OSI’s Open Source AI Definition, which additionally asks for the training code and enough information about the training data for a skilled person to rebuild an equivalent system. Most Apache 2.0 model releases publish weights and code but not data. For deployment purposes that is fine: the license on the weights is what governs your rights.
What are the five tiers of open-weight model licenses?
Enterprise license review gets faster once you sort a candidate into one of five tiers, because the tier predicts how much legal time it will consume:
- OSI-approved permissive (Apache 2.0, MIT). Commercial use, self-hosting, fine-tuning and redistribution allowed. Obligations are notice-keeping on distribution. Review effort: hours.
- Custom community licenses (Llama Community License, the Qwen License Agreement used on some Qwen2.5 sizes). Commercial use allowed, conditioned on an acceptable use policy, a scale threshold, and attribution or naming duties. Review effort: a real read by counsel.
- Behavioural-use licenses (OpenRAIL-style). Weights are freely usable except for an enumerated list of prohibited applications, which you must pass down to anyone you share the model with. Review effort: map the prohibited list against your use case and your customers’.
- Non-commercial (CC-BY-NC, research licenses such as the Qwen Research License). Evaluation and research only. Disqualified for production, full stop.
- No license, or an unclear one. Weights on a hosting site with no license file, or a license that contradicts the model card. Treat as unusable: you cannot document rights you cannot find.
Tiers 4 and 5 are eliminations. Tier 1 is a fast approval. Tiers 2 and 3 are where the actual work sits.
How do the licenses enterprises shortlist actually compare?
The table compares the open-weight license families most often shortlisted for on-premise deployment, on the clauses that decide approval. Verify each cell against the license file for the exact model and version, because publishers change terms between generations.
| License (typical models) | Type | Commercial use | Scale or use caps | Redistributing a fine-tune | Outputs to train other models | Attribution duty |
|---|---|---|---|---|---|---|
| Apache 2.0 (Qwen3, Mistral Small, Gemma 4) | OSI-approved permissive | Yes | None | Allowed: include the license, retain notices, state your changes | No restriction | License and NOTICE file kept on distribution |
| MIT (DeepSeek R1, V3.2) | OSI-approved permissive | Yes | None | Allowed: keep the copyright and permission notice | No restriction | Copyright and permission notice |
| Llama Community License (Llama 3.x, Llama 4) | Custom community | Yes, conditioned | 700M MAU threshold, acceptable use policy, version-specific regional clauses | Allowed: pass the agreement down, include the required notice, prefix the model name with “Llama” | Allowed from Llama 3.1 onward, subject to the “Llama” naming rule | “Built with Llama” plus a NOTICE text file |
| Qwen License Agreement (some Qwen2.5 sizes) | Custom community | Yes, conditioned | 100M MAU threshold | Allowed: terms and notice flow down | No dedicated output clause in the agreement text; re-check your version | Notice plus a statement of modifications |
| OpenRAIL-style | Behavioural-use | Yes | Enumerated prohibited uses | Allowed: the use restrictions must flow down | Yes, if the resulting model carries the same prohibited-use list | Prohibited-use list passed to downstream users |
| CC-BY-NC and research licenses | Non-commercial | No | Non-commercial only | Not for production | Not for production | Attribution |
Two details from that table are the ones teams get wrong. The Llama 700 million monthly-active-user threshold is a snapshot test measured on the release date of that Llama version, not a growth trigger you cross later, so almost every enterprise sits comfortably outside it. And Llama 3.0 forbade using its outputs to improve other large language models, a restriction Meta removed in Llama 3.1 in favour of the naming requirement, which matters if your plan involves synthetic data or distillation. Llama 3.2 also withheld multimodal rights from individuals domiciled in, and companies with a principal place of business in, the European Union, so check whether your version carries a comparable regional clause.
Does a fine-tuned or distilled model inherit the base model’s license?
Yes. A fine-tune, a distill or a merge inherits the terms of the base model it was derived from, so a permissive license on the repository you downloaded from does not overwrite a restrictive one upstream. The common failure is assuming a family-level license: a distilled model published in an MIT repository can still be governed by the base model’s community license, as set out in the DeepSeek distill section of the best open-weight LLMs for enterprise on-prem in 2026.
For a merged model the position is harder still, because the most restrictive parent’s terms generally govern the merged artefact. If you cannot name every parent model and its license, treat the merge as tier 5 and disqualify it. Record the lineage at download time, when it is one field to fill in, not at audit time, when it is an investigation.
What changes when you fine-tune and redistribute a model?
Almost every obligation in an open-weight license triggers on distribution, not on creation or internal use. Fine-tuning a model and serving it to your own employees inside your own network typically triggers nothing beyond keeping the original license and notice files alongside the weights. The obligations wake up as soon as the model, or a product containing it, reaches a third party.
| Scenario | Apache 2.0 / MIT | Llama Community License |
|---|---|---|
| Fine-tune, deploy internally, weights never leave your perimeter | Retain the license and notices with the files | Retain license and notices; whether an internal-only tool counts as a “product or service made available” is the ambiguity to put to counsel |
| Embed the model in a product or service you offer to customers | Retain notices; no naming rule | Terms reach products and services containing the materials, so plan for “Built with Llama” attribution |
| Publish or share the fine-tuned weights externally | Include the license, retain notices, state your modifications | Pass the agreement down, include the required notice text, prefix the derivative model’s name with “Llama” |
The practical control is a model bill of materials: for every model in production, record the exact model name and version, the license file you received with it and its hash, the download date, the base model lineage for any fine-tune, and the deployment scope (internal only, customer-facing, redistributed). That record is what an auditor asks for.
Why do Apache 2.0 and MIT licensed models simplify legal review?
Apache 2.0 and MIT models simplify enterprise legal review because they remove the three clauses that generate the questions: there is no acceptable use policy to map against your use cases, no user-count threshold to monitor, and no naming or field-of-use restriction to flow down to customers. Review collapses to notice-keeping.
Apache 2.0 is the stronger of the two for enterprise use because it includes an express patent grant from contributors, with that grant terminating if you bring patent litigation over the work. MIT has no express patent grant, which some legal teams flag even though the text is otherwise simpler. The 2026 landscape helps: the permissive tier now extends to frontier-scale models, so choosing a clean license rarely costs you capability.
What should legal check before approving an open-weight LLM?
Run these ten checks against the license text for the exact model and size you intend to deploy. Each is phrased as what good looks like, with the red flag beside it.
- Commercial use. Explicitly granted. Red flag: “research”, “non-commercial”, or silence.
- Self-hosting. The grant covers running the weights on your own infrastructure. Red flag: rights framed only around a hosted API.
- Scale thresholds. None, or a threshold you are far below and can evidence. Red flag: a cap you cannot measure.
- Acceptable use policy. Reviewed against your actual use cases, and noted as unilaterally updatable by the publisher if it is. Red flag: an AUP broad enough to read onto your product.
- Field-of-use and regional clauses. None applicable to your sector or jurisdiction. Red flag: version-specific carve-outs you did not know existed.
- Derivative works. Fine-tuning permitted, with redistribution conditions understood. Red flag: any consent requirement for derivatives.
- Outputs. Clear that you may freely use model outputs, including for training other models if that is your plan. Red flag: an output-use restriction that blocks distillation.
- Attribution and naming. Exact wording and placement obligations written into your release process. Red flag: discovering “Built with Llama” is required after launch.
- Termination. You know what ends your rights, typically an IP claim against the publisher over the model.
- Warranty and indemnity. Accepted as absent, and recorded on the risk register.
Point 10 deserves emphasis. Open-weight models are distributed “as is”: the license grants rights in the weights, makes no representation about the copyright status of the training data, and offers no IP indemnity. That is a risk to accept knowingly, not to discover. Export control and sanctions law apply independently of the license.
Who owns license compliance in an on-premise deployment?
License compliance is an owned engineering task, not a one-time legal sign-off, because open-weight models are re-versioned frequently and terms change with them. The team that pulls a new checkpoint re-reads the license file, updates the model bill of materials, and re-checks the deployment scope. Tie that to change control alongside model swaps, using the ordered selection method in how to choose an open-weight LLM for on-premise use, where license is the first and hardest filter.
Teclops AI builds AI systems that run inside the client’s own infrastructure, so model selection, license verification and offline serving are handled as part of the build. Samvad AI, our source-cited RAG assistant, answers only from your own documents, cites the exact source passage, says plainly when an answer is not in your sources, and deploys on-premise, air-gapped or hybrid, switchable by configuration. To have a shortlist reviewed against your own procurement constraints, see the AI product development and consultancy services from Teclops AI or write to teclops.ai@gmail.com.
Frequently asked questions
Can you use Llama commercially under the Llama Community License?
Yes for almost every enterprise. The Llama Community License permits commercial use including self-hosting, but it is a custom licence rather than an open source one: it incorporates an acceptable use policy, requires "Built with Llama" attribution and a specific notice on distribution, and requires a separate licence from Meta if your products exceeded 700 million monthly active users in the calendar month before that Llama version's release date.
Does an Apache 2.0 license make a model open source?
Apache 2.0 is an OSI-approved open source license, so the weights are distributed under open source terms, but that alone does not make the model open source AI. The Open Source Initiative's Open Source AI Definition also asks for training code and enough information about the training data to rebuild an equivalent system, which most Apache 2.0 model releases do not provide. For deployment, Apache 2.0 still gives you everything you need for commercial self-hosting.
Do open-weight LLM licenses restrict fine-tuning?
Permissive licenses such as Apache 2.0 and MIT place no restriction on fine-tuning. Custom community licenses generally allow fine-tuning but attach conditions to what you do next: passing the same terms to anyone you give the weights to, adding required attribution, and in Meta's case starting a distributed derivative model's name with "Llama". Research-only and non-commercial licenses forbid production use of the fine-tune entirely.
Is the Qwen license safe for enterprise commercial use?
Qwen3 is published under Apache 2.0, with no user-count cap and no field-of-use restriction, so it is straightforward for enterprise commercial use. Older generations were not uniform: some Qwen2.5 sizes shipped under a custom Qwen License Agreement with a 100 million monthly-active-user threshold, and the Qwen Research License permits non-commercial use only. Check the exact size and version you deployed, not the family.
Do you have to publish your fine-tuned model weights?
No. No mainstream open-weight license requires you to publish a fine-tune. Apache 2.0, MIT and the common community licenses attach obligations to distribution rather than to creation, so a model fine-tuned and served entirely inside your own network usually triggers nothing beyond keeping the original license notices with the files. Obligations appear when the weights reach a third party or ship inside an externally available product.