How to — check a model's license before you ship on it

You want to know, before you ship, whether the weights you downloaded oblige you to ask anyone's permission — and whether that answer survives your fine-tune, your hosting plan, and next quarter's version bump. It's a reading job with a fixed set of questions, and it takes about fifteen minutes.

The reason to do it now rather than when legal asks: the terms moved this quarter. GLM-5.2 shipped under plain MIT; its successor GLM-5.3 shipped under a custom license that gates commercial use for Model-as-a-Service operators above $10 billion in trailing revenue. Kimi K3 added its own thresholds, plus a duty to print the model's name on your interface. Nothing in the model names told you that — only the license files did.

1. Find the license that actually applies.

The license tag on the download page, the model card in the repo, and the license file are three different things, and only the file is the terms. Open the license file itself and read its first few lines: it should name the grant and the copyright holder. If a repo has weights but no license file at all, you haven't been granted anything — absent a grant, the default is all rights reserved, no matter how loudly the release was called open.

Save that file alongside the exact model version you pin. Model families change terms between releases: same lab, same name lineage, different deal. And read the license on your copy, not the one you remember — a permissive license on the previous release is not a promise about this one.

2. Sort it into one of three buckets.

Almost every open-weight release lands in one of three places, and knowing which bucket you're in saves reading the rest of the document closely.

The first is a standard permissive grant — MIT or Apache 2.0 and friends. Use it, modify it, sell what you build, keep the copyright notice. Check it against the Open Source Initiative's approved list and you're done in one step.

The second is a custom community license that is permissive until a scale trigger fires. Llama 4 requires you to request a license from Meta if your products pass 700 million monthly active users. GLM-5.3 requires a security review from the vendor before any commercial use, but only for Model-as-a-Service operators whose group revenue exceeds $10 billion over any twelve consecutive months. Kimi K3 requires a separate agreement with Moonshot AI for Model-as-a-Service operators above $20 million in trailing revenue, and requires the name "Kimi K3" prominently displayed if your product passes 100 million monthly users or $20 million in monthly revenue. Permissive in practice for most teams, custom by construction.

The third is a non-commercial grant. Mistral's Research License permits research purposes only, and its definition is deliberately broad: it excludes a company's employees using the model in their daily tasks, and it excludes any proof-of-concept that's intended to generate revenue, hosted or not.

If a release calls itself "open source" and you can't find its license on the OSI list, you're in bucket two or three. The OSI's Open Source AI Definition, which requires the data information and training code as well as the weights, is the reference point for that claim — if you want the longer version of the distinction, AI 101 — What are open-weight models? covers it.

3. Answer the four questions that decide your case.

Read with a fixed order, because most licenses answer the first question generously and the second one narrowly. Can you use it commercially? Can you host it — that is, give third parties access to the model itself, rather than shipping the model's output inside your own feature? What attribution, naming or notice duties apply? And do the limits follow into derivatives, meaning your fine-tune?

The hosting question is where custom licenses concentrate their conditions, and both GLM-5.3 and Kimi K3 define the trigger term explicitly: giving a third party access to inference or fine-tuning in a way that lets them control the inputs, parameters or training data. Both then carve out end-user products where the model sits inside a specific feature, and both carve out simply relaying requests to a model someone else hosts. That definition is the whole ballgame — a wrapper around a hosted API is not a model service.

4. Name your own deployment shape before you read the thresholds.

The same license is fine for one company and gated for another, so classify yourself first. Internal-only: your people use the outputs and the model is never exposed to third parties. Embedded: the model powers a feature of your product. Hosting: you serve the model itself to others.

That classification is not a formality. Kimi K3's conditions explicitly do not apply to internal use, and GLM-5.3's clause bites only on the hosting shape, at a revenue level only a handful of companies clear. Write down your shape and your own numbers, honestly: $20 million in trailing revenue is a real mid-sized business, $10 billion is hyperscaler territory. Most teams find they're the embedded shape, and the clause that alarmed them was never aimed at them.

5. Follow the restrictions into your fine-tune.

Fine-tuning feels like it makes a model yours. Licenses rarely agree. The Mistral Research License states that derivatives — explicitly including customized or fine-tuned versions — stay subject to the same usage limitation, requires prominent notices that you modified the model, and requires you to keep its notice text in distributed copies. That's the pattern to look for in any custom license: a derivatives clause that carries the original restrictions forward, plus a notice duty. If you're still deciding whether to fine-tune at all, How to — decide if your model needs fine-tuning is the prior question, and it's cheaper to answer first.

6. Put the naming and notice duties on the launch checklist.

Attribution requirements are the ones that quietly survive into production, and they land on teams that aren't reading licenses — marketing, docs, design. Llama 4 asks for "Built with Llama" prominently displayed on a related website, user interface, blog post, about page, or product documentation, and requires "Llama" at the front of the name of any model you train or fine-tune from its materials and distribute. Kimi K3 requires the model's name on your UI above its thresholds. These are cheap to satisfy at planning and expensive to retrofit once a brand, a pricing page, and a screenshot library exist.

One last thing worth noticing: custom licenses aren't always stricter in every direction. GLM-5.3's, for instance, carries no acceptable-use policy at all — the only condition on the grant is the review clause. Absence of a use policy is not permission. It just means nobody wrote the use terms down.

Don't do this: don't treat the license tag, the launch blog, or the previous version's terms as the terms.

"Open weights," "open source," and "MIT-style" are marketing descriptions until you've read the grant. Repos carry license metadata that doesn't always match the file, families change terms between releases, and a license that was permissive last quarter has no obligation to stay that way. The only authoritative artifact is the license text shipped with the version you downloaded — so read that one, and keep it with the pin.

How you'll know it worked: you can answer, in one sentence and without hedging, whether shipping your feature needs anyone's permission — and you have the license file saved next to the exact model version you deploy. When a lawyer, a procurement reviewer, or a customer's security questionnaire arrives, the note you wrote does the work: bucket, deployment shape, thresholds checked, obligations listed, and the file to prove it. Nobody has to re-derive it, and nobody discovers the clause at launch.

Have you ever shipped on weights and only later read the license clause that applied to you — what did it turn out to be? Tell us in the comments.