Focused guide / AI Knowledge Hub
Read the licence attached to the exact weights
A practical worksheet for exact files, lineage, permissions, notices and unresolved rights questions.
Sources checked 5 October 2026
On this page
This worksheet supports a bounded decision; it does not provide legal clearance.
Before adopting downloadable weights, make a record that answers one question: what may our firm do with this exact artefact and its components?
A brand name, model family or repository badge is not precise enough. Record the checkpoint, files and revision you intend to use, then connect each planned action to the relevant terms.
The result should let another person see what was checked, what remains unknown and where the decision stops.
Start with the files you would actually use
Identify the publisher and distribution location. Record the exact checkpoint and revision, plus file names and available integrity information. Keep the model card and applicable terms tied to that identity.
A branch such as main can change. A link to today’s branch view should not be presented as an immutable record of the licence attached to a particular downloaded checkpoint.
This matters even when a repository looks familiar. The pinned DeepSeek-R1 main-model licence records one inspected revision.[B1-1] It is not a licence for every distilled checkpoint, derivative, component or hosted service. The publisher’s pinned model card, section 7, identifies distinct Qwen and Llama origins for distilled models.
Repository-card metadata is similarly a pointer. Hugging Face documents licence metadata and directs users to seek out and respect the project’s licence.[B1-2] A displayed label does not replace inspection of the exact applicable text and companion terms.
Copy this rights and lineage record
Complete one record per proposed artefact set. Use unknown, not checked or not applicable—with reason rather than leaving fields blank. This is a proposed working template, not a completed review.
Identity and evidence
| Field | Record |
|---|---|
| Record ID and purpose | [Internal identifier; task; intended users; data sensitivity] |
| Proposed activity | [Evaluation/internal production/client service/file distribution; boundaries] |
| Publisher and source | [Publisher; official distribution URL; any intermediary publisher] |
| Exact checkpoint | [Model/checkpoint ID; architecture where stated] |
| Weight files | [File names; format; file set; available digests] |
| Pinned revision | [Commit/release/version; explain any unpinned source] |
| Model card | [URL; revision; retained copy/reference; limitations and intended uses] |
| Evidence dates | [Retrieval date per source; person who checked; retained evidence location] |
Components and lineage
| Field | Record |
|---|---|
| Base model | [Exact upstream checkpoint/revision; evidence or unknown] |
| Adapter or fine-tune | [Publisher; files; revision; upstream relationship; terms] |
| Merge or distillation | [Inputs and relationships where documented; gaps; source of distillation material if supplied] |
| Conversion or quantisation | [Source checkpoint; transformation; publisher; output files; evidence] |
| Code | [Relevant repositories/revisions; component purposes; separate licences] |
| Runtime and dependencies | [Libraries, runtimes, adapters or datasets with relevant separate terms] |
| Data information | [Available development-data descriptions; provenance information; limitations] |
| Applicable licence text | [Exact file/URL; revision; licence name/version; retained text; covered components] |
| Companion conditions | [Acceptable-use terms; incorporated documents; scope; versions/dates] |
| Hosted-service terms, if relevant | [Exact service and applicable terms; otherwise explain why not applicable] |
Actions, obligations and decision
For every action, record the relevant passage or evidence reference—not merely “allowed”.
| Action or obligation | Planned scope, evidence and status |
|---|---|
| Internal and commercial use | [Defined business activity; terms reference; supported/unknown/conflict] |
| Modification | [Fine-tuning, merging, conversion or quantisation actually planned; evidence for each] |
| Client-facing access | [Delivery method; users; applicable conditions; status] |
| Redistribution | [Original/modified weights, adapters or other files; recipients; conditions; status] |
| Attribution and notices | [Exact material to retain, display or deliver; where it will appear; owner] |
| Restrictions | [Relevant use limits or other conditions; effect on proposed work] |
| Unknowns and conflicts | [Missing evidence; conflicting labels/text; affected action; next check] |
| Decision owner | [Accountable person; reviewer where needed] |
| Decision and boundary | [Proceed/seek qualified review/hold; permitted scope; excluded actions] |
| Review timing | [Decision date; next review date; change triggers] |
Retain the reviewed licence text, model card and relevant terms with the record where permitted. A URL alone may not preserve what informed the decision.
Follow the lineage, not just the final repository
A quantised file may have a different publisher from its base model. An adapter may rely on a separately obtained checkpoint. A repository can contain weights, code and documentation without one licence necessarily covering everything.
For each relevant component, identify the relationship, applicable terms and supporting evidence. Do not assume either that the final repository supersedes all upstream conditions or that every upstream condition applies identically to every downstream artefact. Resolve the actual scope.
If output reuse or distillation forms part of the proposal, record it as an explicit question. Using model outputs for training and distillation addresses that subject; it is not a substitute for evidence about the particular inputs and terms.
Worked record: an unresolved fictional checkpoint
Entirely fictional. No files, licences or systems described below were inspected. All names and dates in this example are illustrative.
A small advisory firm is considering the imaginary Paperbark-8B-Q4 checkpoint for classifying synthetic practice documents. It does not propose client access or distribution.
| Record item | Fictional entry |
|---|---|
| Checkpoint and publisher | Paperbark-8B-Q4; publisher shown as Example Model Studio |
| Revision and files | Repository description says “Q4 release”; commit, complete file list and digests not yet recorded |
| Lineage | Card claims conversion from Paperbark-8B; exact upstream revision and transformation evidence unknown |
| Licence metadata | Card says “permissive”; applicable licence text has not been obtained |
| Code and companion terms | Runtime not selected; acceptable-use terms not checked |
| Intended action | Internal business evaluation using synthetic documents; no redistribution or client service |
| Notices | Unknown until applicable terms are examined |
| Owner and review date | Operations owner; illustrative review due 5 October 2026 |
| Decision | Hold execution of the proposed evaluation pending identity and rights checks |
The owner does not convert “permissive” into “commercially cleared”. Nor does using synthetic documents resolve the missing licence evidence.
The next action is specific: establish the exact files and upstream identity, obtain the applicable licence and companion terms, and complete the action rows. Runtime selection then needs its own component checks.
If permission for the bounded evaluation is established, the owner can record a narrower proceed decision. That would not authorise later fine-tuning, confidential-data use or supplying files to clients.
Decide what happens next
Proceed within a defined scope when the artefact and relevant components are identified, applicable terms support the intended actions, obligations have owners and material rights gaps are resolved. Separate data, technical and task-fit gates still apply.
Seek qualified review when material language, component compatibility, upstream conditions or the proposed delivery arrangement cannot be confidently resolved. State the question and affected action so the reviewer has a bounded problem.
Hold the affected activity when essential terms are missing, identity or lineage is insufficient, evidence conflicts or an obligation cannot be met. Silence and missing files are not permission.
Revisit the record when the checkpoint, base, adapter, quantisation, provider, delivery method or intended use changes. Return to the master guide when the issue is which access arrangement to investigate, rather than what a particular artefact permits.
Sources and boundaries
- [B1-1] DeepSeek’s pinned main-model licence and pinned model card, section 7. They illustrate why exact revision and lineage matter; the fictional worksheet is not a completed permission review.
- [B1-2] Hugging Face licence documentation, on metadata and respecting the project’s licence.
Primary passages checked 5 October 2026. Interpretation and applicability to a real activity require the exact terms and relevant qualified review; no real deployment has been tested here.