Open-Weight Model License Terms Are a Procurement Problem, Not a Footnote

A team ships a fine-tuned open-weight model into a customer-facing product. Six weeks later a prospect's legal team sends the standard AI addendum: name every model in the pipeline, confirm you have the right to commercialize outputs, and confirm you can indemnify against IP claims arising from the model. The engineering lead answers the first question in ten seconds. The second and third take five weeks, one outside counsel opinion, and a retraining run, because the base model's license had a clause nobody read and the fine-tune had already been trained on top of it.

That sequence is now common enough to be predictable. Open weights crossed the capability threshold where they belong in production paths, and the failure mode moved with them. It is not that the models underperform. It is that a research convenience with a text file attached became a contractual exposure that nobody put through procurement.

Four License Classes, Not Two

The mental model most teams carry is binary: proprietary API or open source. The actual market has at least four classes, and they behave differently in a deal review.

The class boundary is what matters, not the vendor's marketing. The Open Source Initiative published its Open Source AI Definition in late 2024 precisely because "open source model" was being applied to artifacts that met none of the traditional four freedoms. Under that definition, a model needs sufficient information about training data and process for a skilled person to build a substantially equivalent system. Almost nothing in the current leaderboard meets that bar. Apache 2.0 on the weights file is a statement about one artifact, not about the system.

Take one concrete case. Meta's Llama 3.1 Community License permits commercial use, permits using model outputs to improve other models (a change from earlier Llama terms, and a meaningful one if distillation is in your roadmap), and then attaches three conditions with product consequences: you display "Built with Llama," any derivative model name begins with "Llama," and if your product exceeds 700 million monthly active users you need a separate license from Meta. None of that is unreasonable. All of it is invisible in a benchmark table, and two of those clauses touch your naming and marketing, which are owned by teams that were never in the model selection meeting.

Google's Gemma Terms of Use illustrate the third class. Google reserves the right to update its prohibited use policy and to require you to stop using or distributing the model or a derivative if it believes the terms are being violated. You are agreeing to a policy whose text can change after your model is baked into a product. That is a normal SaaS term. It is unusual for something teams treat as a downloaded file.

The Five Clauses That Decide What You Can Build

Skip the full read on first pass. Five questions separate viable candidates from dead ends.

1. Output rights and distillation. Can you use generations from this model to train another model? Several vendors historically prohibited exactly that, because it undercuts their frontier business. DeepSeek-R1's MIT release explicitly permits distillation into smaller models, which is why so many small reasoning models trace back to it. If your architecture involves a large model generating training data for a cheap production model, this clause is the architecture decision.

2. Redistribution and naming. Do you ship weights to customers, or run them in your own cloud? Shipping weights inside an on-prem appliance triggers redistribution terms, attribution requirements, and the obligation to pass terms downstream. Running them in your own inference tier usually does not. Same model, different obligations.

3. Acceptable use riders that survive download. Most community licenses attach a use policy covering weapons, surveillance, medical advice, and similar categories. If you sell into defense, healthcare, or law enforcement, this is a bright-line filter that rules out models a benchmark would rank first.

4. Jurisdiction carve-outs. Some releases have excluded specific regions from the rights grant. Meta's multimodal Llama 3.2 release carried a carve-out affecting entities with a principal place of business in the EU. If you have European subsidiaries or European customers, read the grant clause geographically, not just functionally.

5. Patent grant and termination. Apache 2.0 section 3 grants a patent license and terminates it if you initiate patent litigation alleging the work infringes. MIT grants no express patent rights at all. For most buyers this is theoretical. For a company with an active patent portfolio and a litigation posture, it is a real term that in-house counsel will want to see.

Run those five against a candidate list and the field usually collapses fast. That is the point. License class should be the first filter, applied before evaluation cost is spent, not the last check applied after a fine-tune exists.

Nobody Indemnifies Your Self-Hosted Weights

This is where most teams find the gap, and it is the single most useful thing to internalize.

IP indemnification for generative AI is a commercial product feature attached to managed services. Microsoft's Customer Copyright Commitment covers specified Copilot and Azure OpenAI services when the customer uses the required mitigations and content filters. Google Cloud's generative AI indemnification covers training data and generated output for named services. Both are conditioned on running the model in the provider's environment, on the provider's covered list, with the provider's safety controls active.

Download the same weights, run them on your own H100s, and you have opted out of every one of those protections. The license file itself will tell you so in capital letters: Apache 2.0, MIT, and the community licenses all disclaim warranties and provide the work "as is." Nobody is standing behind that artifact.

The practical consequences show up in three places:

• Customer MSAs. If your contracts include a broad IP indemnity to your customers, self-hosted open weights mean you are absorbing a risk with no upstream counterparty. Legal will want either a carve-out or a documented provenance review.
• Insurance. Tech E&O and cyber policies are still catching up on generative AI exclusions. Bring the model inventory to the renewal conversation rather than discovering the exclusion during a claim.
• Provenance diligence. The NTIA's report on dual-use foundation models with widely available weights recommended active monitoring rather than restriction, which is the right policy posture and also a quiet admission that downstream users carry the diligence burden. You are the monitoring function for your own stack.

There is a version of this that works in your favor. The same model often exists in two legal forms at once: downloadable weights under a permissive license with no protection, and a hosted endpoint on a major cloud with contractual terms, uptime commitments, and in some cases indemnity. Teams treat these as the same decision because it is the same model name. They are two different contracts, and for regulated buyers the hosted version is frequently the correct choice even at higher unit cost. Cost modeling that ignores the indemnity delta is incomplete, which is worth reading alongside how you route traffic between models in production.

Why Getting This Wrong Is Expensive: Irreversibility

A bad library choice costs you a refactor. A bad model license choice costs you a retraining run, a re-evaluation cycle, and possibly a customer commitment you can no longer honor.

Once a base model is selected, it propagates. Fine-tuning data is curated for its prompt format. Evaluation suites are calibrated against its behavior. Latency budgets, GPU reservations, quantization strategy, and guardrail thresholds all get tuned to that specific artifact. Swapping the base model after the fact is not a config change. It is a rerun of the entire adaptation pipeline plus a fresh accuracy argument to whoever signed off on the last one.

The clean way to price this: the cost of a license review is a few hours of counsel time before selection, and somewhere between four and twelve weeks of engineering plus deal delay after deployment. The ratio is not close, and it is the same argument that applies to choosing open-source LLMs for business automation in general. The technical comparison is the easy half.

Regulation adds a second irreversibility. The EU AI Act includes exemptions for models released under free and open-source terms, but those exemptions narrow sharply for general-purpose models with systemic risk and do not apply the same way once a model is monetized. Article 53 obligations on general-purpose model providers include technical documentation and a copyright policy. If you fine-tune substantially and place the result on the market, you may be standing in the provider role rather than the deployer role, which changes your documentation burden entirely. That determination depends on your modifications, so it cannot be made by whoever downloaded the weights.

The Procurement Gate: A One-Page Model Intake

You do not need a governance program. You need one page in the path between "we evaluated this model" and "it is in the build."

Required fields:

• Model name, exact version, and artifact hash
• License class (permissive, community, custom, research) and a link to the license file at that version
• Deployment mode (self-hosted, managed endpoint, shipped to customer) and the terms that apply to that mode
• Output rights: may outputs train other models, yes or no
• Threshold clauses: user counts, revenue caps, naming and attribution obligations
• Jurisdiction restrictions relevant to your entities and customers
• Indemnity position: who covers an IP claim, or an explicit "nobody, accepted by [name]"
• Approver names from engineering, legal, and security

Required artifacts, stored, not linked:

Archive a copy of the license text and the model card as of the version you trained on. Vendors edit model cards. Repositories get relicensed and occasionally get taken down. When a customer asks in 2028 what terms applied when you trained, a dead URL is not an answer. A hash and a stored PDF is.

The triage rule:

Research and non-production licenses stop at the gate unless someone is actively negotiating a commercial agreement. Custom terms with a living use policy require a named owner who re-checks the policy quarterly. Community licenses require the naming and threshold clauses to be routed to product marketing and finance, because those are the teams who will trip them. Permissive licenses pass the license check and then still need the provenance and indemnity conversation, because permissive is not the same as protected.

One person can run this in about twenty minutes per model. The gate exists so that the twenty minutes happen before the fine-tune, not after the customer's counsel asks.

What This Looks Like on a Real Selection

A support automation build we scoped last quarter is representative. Three candidates cleared the accuracy bar within noise of each other, which is normal now that open models have closed most of the gap on practical tasks.

Candidate A ranked highest and carried a community license with a user threshold plus a derivative naming requirement. The client sells a white-labeled product, so a naming obligation on the model was a direct conflict with the product brand. Ruled out on a marketing constraint, not a technical one.

Candidate B was Apache 2.0 and self-hostable. It passed the license check and failed the indemnity check, because the client's enterprise MSA carries a broad IP indemnity and their counsel would not accept an uncovered position on a customer-facing generation path.

Candidate C was the same weight class, available both as a download and on a managed endpoint with contractual coverage. They took the managed endpoint at roughly 30% higher inference cost, kept the self-hosted variant for internal tooling where the indemnity exposure is nil, and documented the split.

The right answer was the third-ranked model in two different deployment modes. No benchmark would have produced that decision, and this is the same pattern showing up across enterprise AI strategy after model performance parity: when capability stops being the differentiator, the constraints that decide are contractual and operational.

How OpenNash Can Help

Most of this work is unglamorous and one-time. We run it as part of the audit and design phases before any model touches a production path: build the candidate list, apply the license class filter first, map deployment mode against the terms that actually attach to that mode, and hand back a one-page intake per model with the approver trail already filled in. Then the build proceeds on a base model that will still be defensible when a customer's legal team asks.

Teams with a strong in-house counsel function and a stable model set should run this internally. It is not complicated once the checklist exists. Teams shipping multiple models into customer-facing paths, or shipping weights inside a customer-deployed product, usually want an outside pass, because the redistribution obligations are where self-review misses things. Teams still in prototyping should skip the process entirely and just avoid research-licensed models, so nothing needs unwinding later.

If you are moving an open-weight model from a prototype into a revenue path, book a call and we will map the license gate to your workflow and your contract terms before the fine-tune locks the decision in.

The next model you evaluate, open the license file before the benchmark table. It takes twenty minutes and it changes the shortlist more often than the scores do.

---

Note, separate from the post: `_posts/2026-08-11-eu-ai-act-*.md` is corrupted (duplicate `layout:`/`title:` keys and a degenerate repeated slug), so I left it out of the internal links. Several other posts have the same repeated-slug filename pattern. Worth a cleanup pass if you want.