Guides · ← All guides
AI Model Licenses Explained: Open Weights vs. Proprietary
Last updated: October 13, 2026 · 10 min read
This guide is informational, not legal advice.
"Open source AI" is one of the most abused phrases in the industry. A vendor releases model weights, calls the model "open," and half the press repeats it. But the license attached to those weights may restrict commercial use, forbid building competing products, or let the vendor change the terms for the next version. If you're building a business on someone else's model, the license isn't paperwork. The license is the product. Here's how to read it.
Weights are not a license
Releasing weights means you can download the numbers and run the model yourself. That's it. It does not automatically mean you can use it commercially, modify it freely, redistribute it, or fine-tune it for your product. The weights are the artifact; the license is the permission slip. We've watched teams pick a model from a launch blog post, build for three months, and only then discover the license prohibited their exact use case. Always read the license file in the repository, not the announcement.
This confusion is expensive because it compounds. Pick the wrong license and you don't just have a legal problem — you have an architecture problem. Migrating off a model you've fine-tuned, evaluated, and integrated is a rebuild, not a swap.
The three families of model licenses
1. Permissive licenses
Licenses like Apache 2.0 or MIT, applied to models or to model-adjacent code, let you use, modify, and commercialize with minimal conditions — typically attribution, and in Apache's case, an express patent grant. This is the safest foundation for a business. Your rights don't depend on the vendor's continued goodwill, and the terms can't be retroactively narrowed for the version you already have. When a model ships under Apache 2.0, the main thing to verify is what exactly the license covers: sometimes the code is Apache-licensed while the weights sit under separate, stricter terms. Read both files.
2. "Open-ish" community licenses
This is where most of the industry's "open" models actually live. These are custom licenses that look open — you can download, run, fine-tune, often use commercially — but carry restrictions that bite growing businesses:
- User-count thresholds. Meta's Llama community license, the template for this whole category, requires a separate license from Meta once your product exceeds 700 million monthly active users. You won't hit that on day one. But if you do hit it, you're negotiating from a position of total dependence.
- No competing models. Many community licenses prohibit using the model's outputs to train a competing model. That constrains one of the main ways teams improve their own systems — distillation and synthetic data generation from a stronger model.
- Acceptable-use policies. Usually incorporated by reference, and changeable by the vendor without a license change. Your permitted use cases can shrink while the license version number stays the same.
- Version-to-version changes. The license covers the version you downloaded. Nothing stops the vendor from shipping the next version under stricter terms — and your roadmap is now tied to an old checkpoint.
None of these restrictions are hidden. They're in the license text, in plain language. The problem is that teams read "open" in the headline and stop.
3. Proprietary licenses
API-only models and closed weights: you get access, not rights. The vendor can change pricing, restrict use cases, deprecate the model, or terminate your access under the terms. The tradeoff is real — frontier capability without infrastructure costs — but your business inherits the vendor's roadmap risk in full. A proprietary license deserves the same treatment as any critical vendor dependency: a migration plan, contractual commitments where you can get them (enterprise agreements can lock in deprecation notice periods), and a clear-eyed view of switching costs.
Open weights is not open source
The Open Source Initiative published its formal Open Source AI Definition in October 2024, and most "open" models don't meet it — typically because the training data isn't disclosed, or because the license restricts fields of use. This isn't pedantry. If your compliance team, your investors, or your enterprise customers ask whether your AI stack is open source, "the vendor called it open" is not a defensible answer. Check the license against the criteria your organization actually cares about — commercial use, modification, redistribution, patent rights — not the marketing label.
The practical test we recommend: can you fork it, sell it, and never talk to the vendor again? If yes, it's genuinely open for your purposes. If any step requires the vendor's permission, price that dependency.
The clauses that bite, annotated
Non-compete on training. "You will not use the outputs of the model to develop or improve a competing model." Common, and it quietly rules out distillation pipelines. If your ML roadmap includes training smaller models on a larger model's outputs, this clause is a wall.
Revocability. Can the vendor revoke the license? A revocable "open" license is a rental agreement with good PR. Check whether termination applies only to future versions or to your existing deployment.
Retroactive changes. Does the vendor reserve the right to update the terms for versions you've already downloaded? Most don't claim this explicitly, but acceptable-use policies incorporated by reference can achieve nearly the same effect.
Patent grants — or their absence. Apache 2.0 includes an express patent license. Most custom model licenses say nothing about patents at all, which leaves the question open in the worst way: unanswered, and answerable later by whoever holds the patents.
Attribution and branding. Some licenses require specific attribution text or prohibit implying endorsement. Minor, but the kind of thing that surfaces during enterprise procurement and delays a deal by two weeks.
A walkthrough: picking a model for a real product
Consider a hypothetical startup building a customer-support copilot. The team narrows it to three options: a permissively licensed smaller model, a prominent community-licensed model with better benchmarks, and a proprietary API with the best quality.
The permissive model needs more fine-tuning work but the license is clean — Apache 2.0, no user cap, patent grant included. The community-licensed model scores higher out of the box, but its license bars training competing models on its outputs, which kills the team's plan to distill a smaller on-device version later. The API is the best quality today, but the terms allow the vendor to deprecate the model version with 90 days' notice, and the startup's entire evaluation suite is tuned to that version's behavior.
There's no universally right answer here. But there's a wrong process: picking on benchmarks alone and reading the license after the architecture is set. The license review belongs in the evaluation phase, next to the eval scores — because it answers a different question than the benchmarks do. Benchmarks tell you what the model can do. The license tells you what you're allowed to do, and for how long.
FAQ
If weights are downloadable, can the vendor really enforce the license?
Yes. Copyright in the weights (and in many jurisdictions, the license as a contract) gives the vendor enforcement options regardless of how easy downloading was. "Everyone has a copy" is not a defense.
Can a vendor change a model's license after release?
For future versions, yes — and this happens. For the version you already downloaded under the old terms, generally no, but acceptable-use policies incorporated by reference can narrow your practical rights without a version bump. Track the policy pages, not just the license file.
Does "non-commercial" in a license mean I can't use it at work?
Effectively, yes, for most business uses — and "internal use at a for-profit company" usually counts as commercial. If your use case touches revenue, treat non-commercial licenses as off-limits and move on.
What about fine-tunes of licensed models?
Your fine-tune typically inherits the base model's license restrictions. A fine-tune of a community-licensed model doesn't wash out the 700M-user threshold or the no-competing-models clause. The restrictions travel with the weights.
What to do before you build on a model
- Read the actual license file in the repo — not the blog post, not the model card summary, the license text.
- Map every restriction against your business model: commercial use, redistribution, fine-tuning, distillation, user-count thresholds.
- Check whether the acceptable-use policy is incorporated by reference, and whether the vendor can change it unilaterally.
- For community licenses, note the version number and save a copy. Your rights are tied to that version's terms.
- Track the license page and the AUP. Vendors do change model licenses, and a quiet change can strand a roadmap that assumed the old terms.