Read the tag as a label that points you to the full text, not as the terms themselves. Sort it into permissive, copyleft, non-commercial, use-restricted or custom, then read the license file. For tags such as other or unknown, the Hub documentation says the license text should be in a LICENSE file in the repo.
What the Hub says about licenses
Hugging Face documents that you can add a license to any repository through the metadata section of the model card, in the README. It tells users to seek out and respect a project's license when considering using the code or data. The docs publish a list of license identifiers that can be used in a card.
For the special case of other, the docs say to add the license text to a LICENSE file in the repo and to set a name for it in the license name field. That means a custom license is expected to be written down somewhere, and your job is to go and read it.
Sorting the tags
The identifier list is long. You can group the entries by what they tend to mean for a commercial user.
| Group | Examples of identifier styles on the list | What to check |
|---|---|---|
| Permissive | apache-2.0, mit, bsd variants, isc | Notice and attribution duties |
| Copyleft | gpl and agpl families, lgpl, mpl, eupl | Whether your use triggers sharing duties |
| Non-commercial | cc-by-nc variants, research-use licenses | Usually rules out a product, confirm in the text |
| Use-restricted | the openrail family and its variants | The list of restricted uses, and flow-down |
| Custom or vendor terms | identifiers for specific community licenses, plus other | Read the full agreement, including thresholds and conditions |
| Unknown | unknown | Treat as no permission until clarified |
This sorting is a triage tool. The final answer always comes from the text.
Five checks on any custom license
- Who may use it, and how. Look for restrictions on commercial use, size thresholds on your user base, or limits by field of use.
- What you must do when you distribute. Attribution, naming rules, including the license text, notices.
- What happens to derivatives. Whether a fine-tune must carry the same terms, or be named in a particular way.
- Acceptable use rules. Whether there is a separate policy, and whether it flows to your customers.
- Termination. What ends your rights, and what you must do afterward.
Make the tag a gate
Put the decision in a table your team can use, with three outcomes: approved, needs legal review, blocked. Typical approved examples are permissive tags. Typical review examples are copyleft, use-restricted and custom. Typical blocked examples are non-commercial for a commercial product, and unknown.
Then enforce it where models enter. A check on pull requests can look for model identifiers in code and configuration, look up the tag, and ask for a review when the tag is outside the approved group.
Record what you decided
For each model, store the identifier, a copy of the license text at the time, the revision, the date and the decision owner. If the publisher changes the license later, your copy shows what you agreed to. A separate post on this blog covers which license fields to record for a model and its datasets, and another covers what to do when a model license says other or unknown.
Try it yourself
Click through it at your own pace, or open it full screen. Sort the license column into the groups above and note which rows would need review.
Quick check
Is a permissive tag enough to ship commercially?
Usually the terms are friendly, but notice and attribution duties still apply, and the training data may carry its own terms. Record both.
What if the tag and the LICENSE file disagree?
Treat that as a flag. Ask the publisher, and do not ship until you know which one governs. Keep your correspondence.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning with policies and gates, so license rules for packages can run in CI as a gate. A free scan lists the licenses in your repository.
Sources
- Hugging Face Hub documentation: Licenses, read 19 October 2026.
Last reviewed: 19 October 2026.
