For each model, record the declared license identifier, the license name and link if it is custom, the license of its base model, and the license of each training dataset you know about. Add the exact revision and the date you checked. A model inherits more than one set of terms.
Why one field is not enough
Software teams are used to one license per package. A model can have several layers: the weights, the code that runs them, the base model it was fine tuned from, and the data it was trained on. A license on the top layer does not erase the terms below it.
The Hub's model card metadata supports several of these links. A card can carry a license field, a base_model field listing the model it was derived from, and a datasets field listing datasets used for training. For custom terms, the card uses license: other, with license_name and license_link, or a LICENSE file in the repo.
A practical field list
| Field | Example value shape | Notes |
|---|---|---|
| model_id and revision | org/name at a full commit hash | Pin it, do not use a moving branch |
| license | A Hub license identifier | Copy exactly as declared |
| license_name and license_link | Only for custom terms | Save the text, not only the link |
| base_model | One or more identifiers | The relation can be finetune, adapter, merge or quantized |
| datasets | Hub dataset identifiers | Look up each dataset license too |
| reviewed_by and reviewed_on | Name and date | Shows the check was done |
The Hub documents that a base model relationship can be inferred as adapter, merge, quantized or finetune, and can also be set explicitly. That relationship matters: if a model is a merge of two bases, you owe attention to both licenses.
Steps
- Open the model card and copy the license metadata.
- If the value is other, open the license file and save a copy in your records.
- Follow base_model to the parent. Repeat for each parent in a merge.
- Follow each dataset listed. Note its license and any use limits.
- Record whether the use limits fit your product: commercial use, redistribution, field of use, and any attribution terms.
- Store all of it with the revision, so a later change to the card does not rewrite history.
Limits of this approach
The Hub is explicit that you should seek out and respect a project's license, and its license list is a convenience for tagging, not legal advice. Cards can be wrong or incomplete, and the dataset list is whatever the publisher chose to share. When a model matters to revenue, have counsel read the actual terms, and prefer sources that document training data.
Some licenses in the Hub list are community or research licenses with their own terms rather than standard open source licenses, so a familiar looking name is not a reason to skip reading.
Quick check
Does an Apache or MIT license on the weights cover the training data?
Not automatically. The license on the model file speaks for the model file. Training data may carry its own terms, and the card may or may not describe them.
Where should these records live?
Next to your SBOM or AI bill of materials, under version control, with the model revision. That way an audit or a customer question can be answered from a file.
Safeguard scans dependencies, generates SBOMs and checks license data for the packages in your repositories. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
