An open-weight model licence is the document that decides whether the model you are about to fine-tune can be shipped, to whom, under what name, and with what obligations attached. Many teams read it after training, if at all. This post is about reading it first: which clauses matter, what the main families have been known to use, and how adapters and merged weights fit in. It is not legal advice; for a decision that matters, involve counsel.
Open weights are not open source by default
Open weight means the parameters are published and you can download them. It says nothing about what you may do with them. Some families release weights under a standard permissive software licence, with well-understood rights and obligations. Others publish under a custom licence written for that family, with terms a software licence never had: user-count thresholds, naming rules, policies about what the model may be used for.
The same family can do both. A release can carry a different licence from the previous one, a research variant can sit beside a commercial one under the same model name, and a licence can be revised between versions. The unit of analysis is the exact checkpoint you are downloading, on the day you download it.
The clauses in an open-weight model licence that matter
- Use restrictions and acceptable-use policies. A list of prohibited uses, sometimes in a separate document the licence incorporates by reference. Check whether it binds only you or must be passed on to the users of your product, and whether your use case is near any line on it.
- Attribution and naming of derivatives. A required notice in documentation, a "built with" statement, or a rule that a derived model's name must include or begin with the family name. Cheap to comply with, expensive to discover after a launch.
- User-count thresholds. A clause that grants the licence only below a stated number of monthly users, or requires a separate agreement above it, and may count users of the product rather than callers of the API.
- Redistribution of weights. Whether you may publish the tuned weights, whether the original licence must travel with them, and whether an adapter counts as redistribution of the base.
- Research-only variants. A non-commercial or research licence on some checkpoints of a family that has commercial terms on others. The model card, not the family name, tells you which you have.
- Patent terms. Some standard permissive licences, Apache 2.0 among them, carry an explicit patent grant and a termination clause if you sue over the covered patents; others say nothing about patents, and custom licences vary. This is the clause for whoever handles intellectual property at your company.
- Output clauses. Some licences have included terms about using the model's outputs to train other models. If your plan involves distillation, read for this specifically.
What the main families have been known to use
None of the following is a statement of current terms. Each family revises its licence, and the text on the licence page on the day you use the model is the only one that counts.
- Llama has been known to use a custom community licence with an acceptable-use policy, attribution and naming requirements for derivatives, and a monthly-active-user threshold above which a separate licence is needed. The licence and use policy for each release are in Meta's llama-models repository.
- Qwen has shipped different models under different terms: some releases under a permissive software licence, others under a custom licence with a user threshold and attribution. Check the licence file on the specific model card under the Qwen organisation on Hugging Face.
- Gemma has used its own terms of use with a prohibited-use policy that applies to derivatives and to redistribution. The terms are published on the Gemma Terms of Use page.
- Mistral has released some models under a permissive software licence and others under a research licence that limits production use. The licence is per model, not per family.
- DeepSeek has published code and weights under separate licences for some releases, with use-based restrictions in the model licence, and a permissive licence for others. The licence files in each release's repository are the reference.
Adapters, merged weights and what counts as a derivative
This is where fine-tuning teams get surprised. A LoRA adapter is a small set of weights trained against the base; a merged model is the base plus the adapter, folded into one set of weights. Most custom licences define a term along the lines of "derivative" or "model derivative" and attach obligations to it, and many of those definitions are written broadly enough to cover both the merged model and the adapter on its own.
Under a permissive software licence the questions are simpler but not absent: the merged model contains the licensed weights, so notice and attribution obligations follow it, and any patent clause applies to it. The mechanics of adapters and merging are in LoRA, QLoRA and full fine-tuning; the licence question is separate from the engineering one and should be settled before the engineering starts.
Where the model is served changes little. A model in your own account behind a dedicated endpoint, as described in single-tenant model serving, is still a use of the weights under the licence, and a product on top of it still has the users a threshold clause counts.
A reading checklist before training starts
- Record the exact checkpoint, the licence file it ships with, and the date you read it.
- Read the definitions section first: what the licence calls the materials, a derivative, and commercial use.
- Describe your deployment in one line: internal tool, product feature, or redistributed weights. The obligations differ for each.
- Count your users the way the licence counts them, and check the result against any threshold.
- Check your use case, and your users' likely use cases, against the acceptable-use policy.
- Note every attribution and naming obligation and put it in the release checklist now.
- Check the patent terms with whoever handles intellectual property.
- Check the licences of your training data as well; Runix Data records provenance and licence for every record because the model's licence is only half of the picture.
- Repeat the whole list when the base model version changes.
The questions a buyer would put to any AI vendor about data apply to a model supplier too; the data questions to ask an AI vendor is a reasonable companion to this list.
Runix Models works with open-weight families whose licences permit your use, for example Qwen, Llama, Mistral, Gemma and DeepSeek, and the licence is read against your use case before any training starts, with weights and access set in the engagement contract. It is in early access, by engagement.
Questions this raises
Is an open-weight model the same as an open-source model?
No. Open weight means the parameters are downloadable. Whether you may fine-tune, ship or redistribute them depends on the licence, which may be a standard permissive licence or a custom one with its own restrictions.
Does a LoRA adapter count as a derivative of the base model?
Often, under custom licences, because their definitions of derivative are written broadly, and a merged model certainly contains the base weights. Read the definitions in the specific licence; this is not legal advice.
How often should the licence be re-checked?
Every time the base checkpoint changes, and before any change in how the model is deployed, since terms vary by release and user thresholds depend on your product.