Open-Weight Model Licensing: What to Check Before You Deploy a Local LLM

Procurement teams know how to review a software licence. What they are less used to reviewing is a file — a few hundred gigabytes of weights pulled from a model hub, dropped onto a GPU node in the data centre, and treated downstream as though it were as neutral as a Linux kernel.

It is not neutral. An open-weight model arrives with an agreement attached, and the popular ones are not open source in the sense that legal and security functions usually mean when they say those words. The weights are free to download; the terms governing what you may do with them, what you must display, and what you must pass on to anyone you hand them to are specific, enforceable, and rarely read by the team that deploys them.

This matters more on-premises than in a hosted deployment. Consuming a model through an API means the provider’s terms govern a service. Downloading weights and running them on your own hardware means you have taken possession of the artefact, and every act you perform on it — copying, modifying, embedding in a product, giving it to a subsidiary — is an act the licence has something to say about.

The four families you will actually meet

Most models an enterprise considers fall into one of four groups, and the distinction is more useful than any per-model tally that will be out of date within a quarter.

Genuinely permissive. Apache-2.0 and MIT releases behave the way engineering expects: commercial use, modification, and redistribution permitted with attribution and licence inclusion, and no acceptable-use policy travelling with the file. Several major open-weight families ship at least some checkpoints under them.

Custom community licences. Free for the overwhelming majority of commercial use, but with bespoke conditions attached. The Llama Community Licence is the reference example: it requires you to display “Built with Llama” where the model is used, requires derivative model names to begin with “Llama”, requires a specified copyright notice on redistribution, incorporates Meta’s acceptable use policy by reference, and states that a licensee whose products exceeded 700 million monthly active users in the month before the version’s release must request a separate licence from Meta. That last clause excludes almost nobody — but the group-level calculation includes affiliates, which is worth knowing if you are part of a very large conglomerate.

Open weights with mandatory flow-down. Google’s Gemma Terms of Use permit internal commercial use, but distributing the model or a derivative requires you to include the use restrictions as an enforceable provision in the governing agreement, notify recipients that the restrictions apply, hand over a copy of the agreement, mark modified files with prominent notices, and carry the specified notice text. Google also reserves the right to restrict usage — remotely or otherwise — where it reasonably believes the agreement is being violated.

Research or non-commercial only. Some strong models are released for evaluation and research, with commercial deployment requiring a paid agreement. Perfectly reasonable to benchmark; entirely unsuitable to slip into a production workflow. Licences also change between releases within the same family, in both directions, so the family name tells you nothing — the check belongs to the specific checkpoint.

The clauses that create real work

Reading a model licence for the first time, four provisions tend to generate the actual internal effort.

Attribution and naming. A required visible acknowledgement lands on the interface your staff or customers use — not on a wiki page in the platform team’s space. A required name prefix constrains your internal model registry naming, which people will otherwise set to something like underwriting-assistant-v3.

Use-policy flow-down. An acceptable-use policy incorporated by reference becomes a term you owe onward. If you expose the model through an internal portal to thousands of employees, or to a customer through a product, the restrictions have to reach them in a form that binds. That is a contract-drafting task, not a deployment task.

Redistribution you did not think was redistribution. This is the one most often missed in a private deployment. Copying weights from the group’s central GPU cluster to a legally separate subsidiary in another jurisdiction may be distribution. Shipping a pre-loaded appliance to a client is certainly distribution. So is handing a fine-tuned adapter to an integration partner. Each triggers the notice, flow-down, and naming obligations that internal use alone might not.

No warranty, no indemnity. Open-weight licences disclaim warranties and limit liability; the Llama agreement does so in its disclaimer of warranty and limitation of liability sections, and Gemma is provided on an “as is” basis. Several commercial model providers offer some form of IP indemnity for outputs of their hosted services. When you self-host open weights, that cover is generally absent, and the risk sits with you unless it is addressed by other means. It is a legitimate cost of the deployment model, and it belongs in the business case rather than in a footnote.

None of this substitutes for your counsel reading the actual text of the specific licence for the specific checkpoint. The point is narrower: someone must do that reading, and the default is that nobody does.

Where fine-tuning changes your regulatory position

There is a second layer that has nothing to do with the licence. Under the EU AI Act, obligations for providers of general-purpose AI models have applied since 2 August 2025, and the Commission published guidelines on the scope of those obligations in July 2025. Those guidelines address the case that matters to enterprises directly: what happens when you modify someone else’s model.

The Commission’s position is that not every modification makes the modifier a provider of a new general-purpose model, but one that significantly changes the model’s generality, capabilities, or systemic risk may. As an indicative criterion, the guidelines point to a modification using training compute greater than one third of the original model’s.

For nearly all enterprise work — instruction tuning on internal documents, a LoRA adapter for a domain vocabulary, preference tuning on reviewed outputs — that threshold is nowhere close. The consequence is not alarm; it is record-keeping. Capture the base model and version, the licence it came under, the nature of the modification, and the compute used, at the moment the work is done. Reconstructing that eighteen months later, when a supervisory authority or an enterprise customer asks, is far harder than logging it once — the same discipline model governance across versions already requires operationally.

The register that makes this manageable

Licence compliance for local models fails for a structural reason: models enter the estate through engineering channels and never pass a gate where terms are assessed. The fix is not a policy document; it is a registration step that models cannot skip.

A workable model register records, per artefact: the model and exact revision, where the weights were obtained, the licence and a stored copy of its text as it stood at download, any incorporated acceptable-use policy, any attribution or naming obligation and where it is discharged, whether redistribution is permitted, which workflows are approved to use it, and — for anything fine-tuned — the base model and compute used.

That record is what lets a CIO answer, in one place, the question a customer’s due-diligence questionnaire or an internal audit eventually asks: which models are running, under whose terms, and who approved each one. It is the difference between a governed local LLM environment and a collection of downloaded files nobody owns.

What to avoid

Treating “open weights” as a clearance. The phrase describes availability, not permissions. An open-source review process that assumes no downstream obligations will pass a licence that has several — and terms vary between releases in the same family, so the decision attaches to the checkpoint, not the vendor name.

Letting the licence live with the engineer who downloaded the model. Attribution and flow-down obligations are discharged in product interfaces and customer contracts, and nobody in a platform team can execute them alone.

Reading the redistribution clauses after the architecture is committed. If your deployment model involves appliances, subsidiaries, or partner-hosted installations, those clauses shape the design.

How VDF AI helps

VDF AI treats a model as a governed asset rather than a file on a disk. Models are registered before they can be used — see adding and governing a local AI model — so the platform holds one inventory of what is deployed, in which version, and which workflows may call it. VDF AI Router enforces which model handles which class of request, so a model approved only for internal drafting cannot quietly become the one answering customer-facing traffic. Every inference is attributable to a registered model version in the audit trail, which makes a licence position demonstrable rather than asserted — and because the platform runs inside your own environment, the weights, the fine-tuning data, and the records of both stay within your boundary.