Turn a model license into an operational checklist
Someone on the team pulls a GGUF off a community page, glances at the license file next to it, sees something permissive, and ships it into a customer-facing feature. Nobody reads the model card. Months later, in a legal review, it turns out the weights underneath that quantization inherit a stricter license from the base model, one with a cap on commercial use or a ban on certain applications. This has happened often enough that it barely counts as a cautionary tale anymore.
The card says more than the repo says
Local weights get you out from under an API vendor's terms of service, and that's real, worth having. But they don't get you out from under obligations tied to the artifact itself, and those obligations travel with derivatives whether or not the fork's license badge gets updated. The recurring mistake is checking the repository license and stopping there, ignoring the base-model terms the card references. A quantizer's own conversion scripts might be MIT. The weights they produced are still the original model's weights, reshaped, and the acceptable-use policy, the attribution requirement, and any commercial-use cap attached to the base model do not evaporate because someone ran a conversion script.
Fine-tunes and merges compound this: each hop adds its own layer of permissions on top of whatever the base model already required, and nobody upstream checks that the full chain still holds together. If your team treats every checkpoint swap as a model-migration-reality exercise judged only on quality, the license question deserves the same discipline. A step backward in permissiveness is as real a regression as a step backward in accuracy, and it won't show up in your eval harness.
What you actually need to write down
Treat the artifact the way you'd treat anything else you can't verify from memory: pin it, and pin the specific revision, not the model family name. Model cards get edited and licenses get relicensed, so a name that was fine to deploy six months ago is no guarantee about the file running today, the same instinct behind tracking local-model-updates instead of assuming a folder name means one fixed thing forever. The record needs an owner, a name attached to it, not a bookmark nobody opens twice.
| Field | What goes in it |
|---|---|
| Upstream model + org | who trained the base weights |
| Revision / commit | the exact snapshot the license applies to |
| Quantizer or fine-tuner | who produced this artifact, and their license claim |
| Base license terms | commercial-use limits, acceptable-use policy, attribution clause |
| Derivative license | what the converter or fine-tuner changed |
| Intended use | what you're deploying it for, plainly stated |
| Redistribution path | whether the weights or outputs leave your infrastructure |
| Approver + date | a name, not a channel, and when they signed off |
None of this is exotic. It's the same habit as recording phase-level detail instead of a single total: "checked, looks fine" tells you nothing in six months about what was checked.
Nothing errors when you're out of bounds
Local inference runtimes are good at one thing above all: staying up. They offload layers, swap in a slower kernel, page memory, and keep answering through conditions that would make a hosted API return an error. That tolerance applies to licensing too, except there's no equivalent of a rejected request for "you're not permitted to use this model this way." The tokenizer doesn't check your terms of service. A deployment can sit in clean, well-optimized, apparently fine production for a long stretch while being none of those things where it matters.
Change one thing at a time when you re-verify: don't wave through a new fine-tune and a new use case in the same review, because if something surfaces later you won't know which decision caused it. A merge or fine-tune is its own artifact requiring its own check, not a free pass inherited from an already-cleared parent. Convenience is not evidence of compliance, and an artifact that runs fine is not the same as one you're allowed to run.
Set the tripwire before you need it
The rule that holds up is boring on purpose: approve the complete lineage before anything ships, and write the conclusion down with the workload, the date, and the actual reasoning, not just a verdict. Then write down what should force a re-check, before you need it, while you can still think clearly instead of scrambling after a customer's legal team calls.
- a new major version or checkpoint of the upstream model
- a new use case, internal tooling graduating into a customer-facing feature
- a new party the weights or outputs get handed to
- crossing a scale threshold the original license cared about
Skip that list and the old approval quietly turns into folklore: "we checked this ages ago, it's fine," repeated by people who weren't in the room, about a file that may not be the one deployed now. A defensible decision decays into an assumption nobody would sign their name to twice.
Here's the tradeoff I've made peace with. This slows you down. No grabbing the newest fine-tune the day it tops a leaderboard and shipping it that afternoon, because someone has to sit with the license and the card first. You give up first-mover speed for the ability to say, exactly, what you're running and why you're allowed to. Some teams will decide that trade isn't worth it. I'd rather be slow and correct than fast and unable to answer that question with a straight face.