Choosing open-weight models: licences, lineage & residency
How to pick an open-weight model for a company: what 'open weights' does and does not mean, how licences differ, why a model's base-model lineage matters, and why where inference runs decides data residency far more than who trained the model.
Written and reviewed by Shreyash Prashu Last reviewed
What you'll learn
- The difference between open weights, open source and a hosted API
- How Apache 2.0, OpenRAIL-style and custom community licences restrict commercial use
- Why a fine-tune inherits behaviour from its base model, and how to record lineage
- Why the place inference runs, not the model's origin, decides where your data goes
- A short checklist for approving a model in a company
Before you start
“Open model” is used loosely, and the looseness causes real mistakes — a team ships a product on weights whose licence forbids it, or bans a model that could never have sent data anywhere while using a hosted API that does. This lesson separates the questions.
Three ways to use a model
A hosted API. You send text to the provider; their servers run the model and send back the answer. You never have the weights. Your data goes wherever the provider’s servers and policies say.
Open weights. You download the trained parameters and run them on hardware you control, with an inference engine you choose. Nothing is sent to the model’s creator. “Open weights” says nothing about whether the training data or training code is published.
Fully open. Weights plus training data, code and recipes. Rarer — Ai2’s OLMo family is the best-known example. This matters for research and audit, much less for running the model.
Licences: three families
| Family | Examples | What it means for a company |
|---|---|---|
| Permissive (Apache 2.0, MIT) | gpt-oss, Mistral 3, Granite, Gemma 4, OLMo | Commercial use, modification and redistribution allowed; keep the notices |
| Responsible-AI licences (OpenRAIL-style) | Some vision and OCR models | Use-based restrictions; some variants add revenue or competition limits |
| Custom community licences | Llama, earlier Gemma terms | Commercial use generally allowed but with an acceptable-use policy and, for Llama, conditions for very large companies |
Two traps catch teams repeatedly:
- Code and weights can have different licences. A repository may be Apache 2.0 while the weights it downloads are not. Datalab’s Chandra OCR is an example: Apache 2.0 code, weights under a modified OpenRAIL-M licence that requires a commercial licence above a revenue threshold.
- Licences change between versions. Gemma moved to Apache 2.0 with Gemma 4; earlier versions used Google’s own terms. Approve a specific version, not a model family.
Lineage: a model is often a fine-tune of another
Most open models you will meet are fine-tunes — a base model trained further on new data. The fine-tune inherits most of its base’s knowledge, quirks and safety behaviour, and often its licence obligations too.
Hugging Face model cards record this in a base_model field. Follow it
up the chain and you sometimes find surprises: Ai2’s olmOCR 2, from a
US non-profit, is a fine-tune of Alibaba’s Qwen2.5-VL-7B.
Lineage matters for behaviour questions — refusals, bias, political slant, possible backdoors — because those are inherited. It matters much less for the data question below.
Residency: where inference runs decides where data goes
This is the point most policy discussions get backwards.
A weights file is a list of numbers. When you run it locally with an inference engine such as vLLM or llama.cpp, the model can only produce text; it has no way to open a network connection. Whether anything leaves your machine is decided by your inference code and your network rules — not by who trained the weights. You can prove this by running the server in a container with networking disabled.
A hosted API is the opposite: every prompt is sent to the provider, whoever trained the model.
Only model B. Model A’s origin may still matter for behaviour and for contracts — but not for data leaving the building.
The genuine local risks are elsewhere: loading code (pickle
checkpoints and trust_remote_code=True can execute arbitrary Python —
see model supply-chain security) and
tool access (a model wired to email or HTTP tools can send data
out, because you gave it a way to).
An approval checklist
Before a model goes into production, record:
- Exact version and file hashes — not “Llama” or “Qwen”, but the specific checkpoint.
- Licence of the weights and the code, and whether your use is permitted.
- Lineage — the
base_modelchain back to the original. - Deployment mode — local, private cloud, or hosted API — and, for hosted, the provider’s data retention and training-use terms.
- Loading path — safetensors only, no remote code, pinned revision.
- Behavioural evaluation — your own tests for the task, plus red-teaming if the model is user-facing or uses tools.
- Contractual constraints — any customer or regulator rule about model origin, cited by name.
What to remember
- Hosted API, open weights and fully open are three different things.
- Downloadable weights can still carry restrictive licences; code and weights can differ; licences change by version.
- Fine-tunes inherit behaviour from their base. Record lineage.
- Local inference sends nothing anywhere; hosted inference sends everything. Residency follows deployment, not origin.
- Real local risks are loader code and tool access.