A
Member
"Open weights" is not a single licence category. Before shipping a product, verify the following and keep the evidence with the model artefact.
1) Licence text and version for the exact checkpoint. Note use restrictions (commercial use, field-of-use clauses, acceptable-use terms), redistribution conditions, attribution requirements, and whether derivative fine-tunes inherit terms.
2) Provenance of the specific file: source repository, commit or release tag, file checksum, and whether the file was converted or quantised. Converted artefacts may have their own terms.
3) Tokenizer and config files, which can be distributed under different terms than the weights.
4) Training-data documentation and any stated data-related restrictions, plus the model card's evaluation conditions.
5) Third-party components: inference kernels, quantisation libraries, and any bundled datasets, each with its own licence.
6) Downstream obligations: notice files, attribution text in the UI, and a process for handling a licence change or a takedown.
Practical workflow: maintain a per-model manifest listing artefact, checksum, licence URL, retrieval date, and an internal approval record. Re-check the licence URL before each release, since terms can change between versions.
Also record the inference stack versions. Reproducibility and legal provenance both depend on knowing exactly which bits were used.
Takeaway: treat licence review as part of the build pipeline, not a one-off reading. This note is a technical checklist, not legal advice; obtain qualified review for your jurisdiction and use case.
1) Licence text and version for the exact checkpoint. Note use restrictions (commercial use, field-of-use clauses, acceptable-use terms), redistribution conditions, attribution requirements, and whether derivative fine-tunes inherit terms.
2) Provenance of the specific file: source repository, commit or release tag, file checksum, and whether the file was converted or quantised. Converted artefacts may have their own terms.
3) Tokenizer and config files, which can be distributed under different terms than the weights.
4) Training-data documentation and any stated data-related restrictions, plus the model card's evaluation conditions.
5) Third-party components: inference kernels, quantisation libraries, and any bundled datasets, each with its own licence.
6) Downstream obligations: notice files, attribution text in the UI, and a process for handling a licence change or a takedown.
Practical workflow: maintain a per-model manifest listing artefact, checksum, licence URL, retrieval date, and an internal approval record. Re-check the licence URL before each release, since terms can change between versions.
Also record the inference stack versions. Reproducibility and legal provenance both depend on knowing exactly which bits were used.
Takeaway: treat licence review as part of the build pipeline, not a one-off reading. This note is a technical checklist, not legal advice; obtain qualified review for your jurisdiction and use case.