A feature works, the demo lands, and a launch date is announced. Then, days before the release, legal or the security team asks one question — "which model is this, and under what licence are we using it?" — and the answer stops the launch. The model card carries a research-only, non-commercial or bespoke community licence, and the product is commercial. Nothing in the code failed. No test went red. The symptom is a calendar slipping, not a stack trace, and it usually arrives with a second question the team cannot answer either: what was this model trained on, and can we say so to a customer? Teams often discover the problem twice — first in a security review, then again when a client's procurement questionnaire asks for the licence of every third-party component.
Any team that picked a checkpoint from a search box. A fresher searches the Hub for the task, sorts by downloads, takes the top result, and it works, so nobody looks further. The Hub hosts models under many different licences side by side: Apache-2.0 and MIT permit commercial use with attribution, some checkpoints are released for research only, several well-known families ship custom licences with their own conditions, and a large number of repositories carry no licence field at all. A missing licence is not a permissive one — it is an unanswered question, and procurement treats it as a no. This bites hardest in Indian services firms and GCCs, where the client contract, not the team, decides what may be shipped. Linked modules: 2.10 (Hugging Face ecosystem), 2.6 (transfer learning, where the borrowed backbone carries its own terms), 3.10 (fine-tuning, where a derivative of a restricted model inherits the restriction), 3.11 (safety and DPDP).
Start from the artifact, not from memory. List every model the product loads,
with its exact repository name and revision, because two checkpoints with similar
names can carry different terms. For each one, open the model card and read four
fields in this order: the licence tag in the metadata, the licence text or link in
the card body, the intended-use and out-of-scope sections, and the training-data
description. Then check whether the card's licence tag and its prose agree, since
a tag saying other with a link to a bespoke licence is common and means you must
read the linked document. Ask three questions of that document. Does it permit
commercial use? Does it restrict the field of use — no medical, no surveillance,
no competing service? Does it place conditions on outputs, on redistribution, or
on naming the source model in your own materials? Do the same for the dataset the
model was fine-tuned on, because a permissive model trained on a
non-commercial dataset is a second, quieter version of this problem. Finally,
check what you built on top: a fine-tune, an adapter and a distilled copy are all
derivatives, and a derivative cannot have fewer restrictions than its parent.
The immediate fix is a swap, not an argument. For nearly every ordinary task there is a permissively licensed checkpoint of similar size and quality — the distilled and base encoder families are the usual answer for classification, retrieval and extraction work. Pick two or three candidates, verify the licence first and the score second, and re-run your evaluation before anything else changes. If no permissive equivalent exists, the choices are to buy a commercial licence from the publisher, to use a hosted API where the provider carries the terms, or to drop the feature; pick one openly rather than hoping nobody asks. Then repair the process that let it through. Record, for every model in the product, the repository name, the pinned revision, the licence, the source of that licence text, and the date it was checked — a five-column file in the repository is enough and it is the artifact procurement wants. Keep an approved-models list that a fresher may pick from without asking, and a short route for adding to it. Where a bill of materials is generated for the build, put models in it beside the Python packages, because to a customer they are the same kind of dependency.
Check the licence at selection time, before the first line of integration code. Make it the first row of your model-comparison table, above accuracy and speed, so an unusable model is eliminated in the first minute rather than the last week. Pin a revision, since a repository's licence can change between commits and an unpinned load is a promise about a moving target. Treat a blank licence field as blocked until someone gets an answer in writing. Teach the derivative rule once — what you fine-tune from, you inherit from — and it will save an adapter project later. In a review, ask for the licence line in the same breath as the score; a model card screenshot in the pull request costs nothing and settles the question for the next reader.
Q: "You want to use an open model from the Hub in a product we sell. What do you check before you write any code?" Strong answer: name the licence first and say why it comes before accuracy — a model you may not ship is worth nothing however well it scores. Walk the four fields of a model card: licence, intended use, out-of-scope use, training data. Say that a missing licence is a blocker rather than a permission, and that a custom licence must be read, not assumed. Add the derivative point, that a fine-tune of a research-only checkpoint stays research-only, since this is where most candidates stop. Finish with the artifact you would leave behind — a pinned revision, a five-column model inventory, and an approved-models list a junior can use without a lawyer in the room.