AI Model Licenses: What You Can Legally Ship

Can you use this model in a product you charge for? AI model licenses answer that question, and the answer is not the same across models that all describe themselves as open. A downloadable weights file tells you nothing about your rights. The license file next to it tells you everything, and the differences between them are large enough to change what you are allowed to build.

There are broadly three families in circulation. Knowing which one you are in takes about two minutes and saves a rewrite.

The three families of AI model licenses

Standard open source licenses

Apache 2.0 is the one to hope for. It grants use, modification, distribution, and sublicensing, adds an express patent grant, and asks in return for attribution and a note of what you changed. There is no user threshold, no acceptable use policy incorporated by reference, and no restriction on what you do with the outputs. It is an OSI-approved license, which means enterprise legal teams have already reviewed the text and will not need to review it again.

That last point is the practical benefit and it is easy to underrate. A license nobody has to think about is worth more than a slightly more permissive one nobody recognises. MIT behaves similarly, with a shorter text and no explicit patent grant, which matters to lawyers more than to engineers but does occasionally matter.

Community licenses

These are vendor-written documents specific to one model family. The Llama community license is the widely-copied template: commercial use is permitted, but products above 700 million monthly active users must negotiate a separate agreement, and there are restrictions on using the model to improve other large language models. Gemma's terms follow a similar shape, with a use policy attached.

For most small companies the user ceiling is theoretical. The genuine cost is that each of these is a bespoke document. Nobody has pre-approved it, so somebody has to read it, and if you ever sell to a company with a procurement process, they will read it again. Two clauses in this family cause the most trouble in practice: the restriction on using outputs to train another model, which quietly rules out distillation, and the incorporated acceptable use policy, which the vendor can revise without changing the license itself.

Research-only licenses

Some strong models are released for research use only. This means what it says, and it includes internal tools at a company that makes money, not only products you sell. If you are building anything commercial, filter these out at the shortlist stage rather than after you have built on one. The trap is that these models often benchmark well and are widely written about, so they show up in comparisons alongside models you can actually use.

Derivatives, fine-tunes and merges

The license follows the weights downstream, and this is where small teams get caught. If you fine-tune a model, the result is a derivative work and the original terms usually still apply to it. Under Apache 2.0 that is unremarkable: you can keep the fine-tune private, ship it, or sell access to it. Under a community license, several obligations travel with it, commonly a requirement to pass the same terms to anyone you distribute it to and sometimes a naming requirement on the derived model.

Model merges are murkier still. Combining weights from two models with incompatible licenses produces something whose status nobody can state confidently, and there is very little settled practice to lean on. If you merge, merge within one license family. If you are considering a fine-tune at all, what fine-tuning is in AI covers whether you need one before you inherit anyone's terms.

What AI model licenses do not cover

Two things people expect to find in the license and will not:

• Who owns the output. Model licenses generally govern the weights, not what the model generates. Ownership of generated material is a separate question with a separate answer, which we cover in who owns AI-generated code.

• What the model was trained on. A permissive license on the weights says nothing about the provenance of the training data, and it does not indemnify you if that becomes contested. Some commercial API providers offer an indemnity here; almost no open-weight release does.

There is also a difference between the license and the deployment terms. Running weights yourself puts you under the model license. Calling the same model through a hosted API puts you under that provider's terms of service, which can be more restrictive about what you may build, and which can change on notice. Check both if you are doing both, because the same model name can carry different obligations depending on how you reach it.

A two-minute check before you commit

1. Open the LICENSE file on the model repository. Not the README, not the blog post announcing it, and not a summary on an aggregator site.

2. If it says Apache 2.0 or MIT, you are done.

3. If it is a vendor-written document, search it for the words commercial, monthly active, train, distribute, and acceptable. Those five words locate almost every restriction that matters.

4. If it says research or non-commercial anywhere, stop and pick another model.

5. Check whether an acceptable use policy is incorporated by reference, and read that too. It is a separate document and it is where the substantive restrictions often live.

6. Save a copy of the license alongside your code, with the date you downloaded it. Terms are versioned, and being able to show which version you agreed to is worth the thirty seconds.

Do this before you build, not before you launch. The cost of switching models is small during a prototype and painful once your prompts, evaluations, and output formats have been tuned around one model's behaviour.

How much this should influence your choice

Licensing should be a filter, not a ranking. Rule out anything you cannot legally ship, then choose among what remains on capability, cost, and how it performs on your own tasks. Teams sometimes invert this and pick the most permissive model available, which is how you end up shipping a weaker product for a freedom you were never going to exercise.

The exception is when you expect to be acquired or to sell into regulated industries. In both cases somebody will audit your dependencies, a bespoke license becomes a line item in a diligence spreadsheet, and the value of a recognised license goes up considerably. If that is a plausible future for your company, weight it accordingly now rather than untangling it later.

FAQ

Does open weights mean open source?

No. Open weights means you can download the parameters. Open source is a specific set of freedoms defined by the Open Source Definition, and several popular open-weight models do not meet it.

Can I fine-tune a model and keep the result private?

Under Apache 2.0 or MIT, yes. Under community licenses it depends on the specific text, and some require you to pass the same terms down to anyone you distribute the fine-tuned model to.

Do I have to credit the model in my product?

Apache 2.0 requires you to retain attribution notices in your distribution, which for a hosted web product usually means a notices file rather than something on the interface. Community licenses often add a naming requirement, which is more visible.

What if the license changes after I start using it?

The version you downloaded under generally continues to apply to that copy, which is why keeping the license file with your code matters. Future versions may ship under different terms, and an incorporated use policy can be revised without the license text changing at all.

Is a license on a model hosting site the authoritative one?

Only if it is the publisher's own repository. Re-uploads frequently carry a tag that does not match the original terms, and the original publisher's stated license is what governs.

Licensing is one of three things worth checking before you adopt any model, alongside capability and cost. If you are also weighing where the model should run, open-weight versus closed models covers the trade that usually comes next, and how to vet an AI vendor covers the hosted side.