What a model licence actually governs
A licence attached to a weights release covers the artefact that was released. It does not describe the version a service sells, it does not settle what happens to the output, and its name alone does not tell you whether a derivative can be redistributed. As of 2026-09-12.
| Layer | Usually covered |
|---|---|
| Code | By a standard open licence |
| Derivatives | Sometimes, and the terms vary most here |
| Outputs | Often not addressed at all |
| Weights | By terms of their own beside the code |
Inclusion rule. Layers a release can license separately. Layers no release addresses are still listed, because silence is the finding. Order. Alphabetical by layer.
1The three layers a release can license separately
Weights, code and outputs are three different things and a release can treat them differently. The repository code is often under one of the standard open licences; the weights file sits beside it under terms of its own; and some releases add a paragraph about what may be done with generated material. Reading only the badge at the top of the repository collapses all three into one answer.
Where the vendor writes its own terms rather than adopting a standard one, this separation is usually the reason. A vendor-written licence exists because the vendor wanted to say something a standard licence does not say, which is exactly the part worth reading.
2A standard name is a shortcut, not a guarantee
A recognisable licence name is a strong signal because the text is fixed and widely understood, and that is its value: a reader does not have to interpret it again. But releases sometimes pair a standard licence with an acceptable-use file or a supplementary notice, and those add restrictions the licence name does not carry.
The practical habit is to look for extra files beside the licence rather than to stop at the licence. A repository with a standard licence and no additional notice is a different object from one that has both, and the two look identical from a distance.
3What a licence says about redistribution
Downloading and running is the easy case. Passing something on is where the terms start to bite: publishing a fine-tune, shipping weights inside a product, mirroring them for colleagues, or including them in a container image are all redistribution, and permissive licences generally allow it subject to attribution and to carrying the licence along.
Vendor-written terms vary far more here, including in whether a derivative inherits the same terms. If a plan involves handing the weights to anyone else in any form, this is the paragraph to read first rather than last.
4The output question is usually answered elsewhere
Most people arrive at a licence file wanting to know whether they can sell what the model generates. That question is frequently not answered there at all. Some releases address it explicitly, some are silent, and silence is not the same as permission or refusal.
Where the material is to be published or sold, the answer usually depends on more than the licence, and this register records only what the release itself states. Nothing here is a reading of anyone's obligations.
5A licence on the family is not a licence on the version being sold
This is the mistake most worth avoiding. A permissive licence attaches to the release it shipped with: a numbered version, at a point in time. The version a hosted service bills by the second may be a later generation from the same vendor with no published weights and therefore no public licence at all.
The register keeps model pages and hosted pages apart for this reason. A sentence like the family is open is true and unhelpful; which numbered releases are open is the answer that survives contact with a decision.
6Version numbers move and licences do not follow
A vendor can publish one version permissively and the next under different terms, or not at all. Nothing in the earlier licence constrains the later release, and nothing about a future release retroactively changes the earlier one: weights already published under a permissive licence stay published under it.
That asymmetry is worth holding onto. It means an open release is durable in a way a hosted rate is not, and it also means the openness of a family cannot be inferred from its most recent announcement.
7Record the version, the date and the file you read
Whatever the terms turn out to be, write down which version they attached to, when the page was read, and which file the sentence came from. Repositories are edited, licences are clarified, and a note that says the family is permissive will not survive a question six months later.
Every row in this register carries those three things for the same reason. It is not diligence theatre; it is the difference between a claim that can be rechecked in a minute and one that has to be researched again from scratch.
8What this does not settle
None of the above is a judgement about what any particular plan is permitted to do. Licence text interacts with the jurisdiction, with any agreement signed with a service, and with the material fed into the model, and none of those are recorded here.
What the register can do is keep the factual layer straight: which version, which licence file, which date, which repository. The rest belongs to whoever is accountable for the decision.
9Where the repository figures are kept
The techniques above are general. Which vendors have published what, under which licence and on what hardware, is recorded on the model pages, each figure quoted from the repository it was read from with its date.
- Wan — versions and licence as published
- LTX-Video — variants under one licence
- HunyuanVideo — a licence the vendor wrote itself
Craft notes on reading releases. No row here is attributed to a vendor, and nothing on this page is a reading of anyone's licence obligations. The sourced material is on the requirements page. Related: Planning hardware, Reading a licence.