Downloading model weights answers one question: can the organisation obtain this artefact? It does not by itself answer whether the organisation may modify it, offer it through an API, put it inside a product, redistribute a quantised copy, train another model from its outputs, or operate it in every intended territory.
Those rights can differ even when two repository cards both say “open weight”. The model may have a custom licence, an incorporated acceptable-use policy, separately licensed code and data, attribution or naming duties, a user threshold, geographic limits, and terms that change when a derivative is distributed. A hosting platform's licence label is useful discovery metadata, not a substitute for the controlling text.
The release decision is therefore concrete: does the exact artefact-and-terms snapshot permit this exact deployment route, and can the team continue meeting every condition after the system changes? This guide separates facts in published licences and specifications from an AIEngine operating framework. It is not legal advice; counsel should resolve material ambiguity, intellectual-property exposure and jurisdiction-specific obligations.
Open weights, open models and open source are different claims
The Open Source Initiative's Open Source AI Definition 1.0 uses four freedoms: use, study, modify and share. It also says the preferred form for modification includes data information, the code used to train and run the system, and model parameters. Under that definition, publishing final weights alone does not establish that a complete AI system is open source.
That distinction is operational, not semantic housekeeping:
- Available weights mean a checkpoint can be acquired under some access process.
- Licensed weights mean terms grant specified rights over the checkpoint, subject to their conditions.
- An open model distribution may expose weights, architecture, inference code, documentation and selected data artefacts under one or several licences.
- Open Source AI, in the OSI sense, is the broader claim that the system supplies the freedoms and preferred form needed to use, study, modify and share it.
Do not force every release into one marketing category. Record the narrower facts: which files are present, which terms cover each file, what route is proposed, and which rights remain unknown. The result may still be commercially useful even when it does not satisfy an open-source definition.
Define the route before reviewing the licence
A licence review without an intended route produces a vague “approved” label that later gets reused for a different activity. Start with the operations the team actually plans.
| Proposed route | Rights and conditions to establish | Common hidden change |
|---|---|---|
| Internal inference | Right to use and reproduce; territory and field-of-use permitted; access terms retained | A contractor or affiliate operates the service |
| Fine-tuning | Right to modify or create a derivative; terms for training data and adapter artefacts | The adapter is later shared outside the entity |
| Customer-facing API | Hosted or service use permitted; incorporated use policy can be enforced | Customers gain a general-purpose endpoint rather than a bounded feature |
| Embedded product | Distribution or making-available terms; notices, attribution and downstream terms | Weights ship to customer-controlled devices |
| Model redistribution | Original and derivative distribution grants; licence copy, notices and naming | Quantisation or merging is assumed to erase obligations |
| Distillation or synthetic-data training | Terms for outputs and using them to improve another model | The resulting model is released under a new name or licence |
Record the legal entity, product, territories, users, delivery method, model transformation, downstream recipients and planned exit. “Commercial use” is too broad to serve as a route. Running a checkpoint on the organisation's own infrastructure and giving the checkpoint to customers are different acts.
The route record should travel with the release baseline in the model change-control process. A new delivery channel, affiliate, geography or derivative can reopen the licence decision even when model quality is unchanged.
Inventory the distribution, not just the checkpoint
Model repositories routinely combine weights, tokenizer files, inference code, custom kernels, evaluation data, example prompts, documentation and third-party packages. Each may have separate terms. Hugging Face's Hub licence documentation explains that a repository card can declare a licence identifier and lists both conventional software licences and model-specific families. It also tells users to find and respect the project's licence. A metadata value communicates a selection; it does not prove that every file in the repository is covered by it.
Build a manifest at the immutable commit or content digest actually evaluated:
- repository URL, commit, release tag and checkpoint digest;
- every downloaded model, code, data and documentation artefact;
- declared licence identifier and the exact licence text retained locally;
- incorporated policies, addenda, model cards and territory-specific terms;
- third-party components and the notices that accompany them;
- access evidence, including any click-through version accepted; and
- the approved deployment route, owner, review date and unresolved questions.
Use a standard identifier when one fits, but do not invent one for a custom agreement. The normative SPDX licence-expression specification supports recognised identifiers, custom LicenseRef values, exceptions and AND/OR composition. That makes licence state machine-readable without pretending a complex distribution has one simple label.
Connect this manifest to the wider AI dependency inventory. The model licence record answers permission and obligation questions; the dependency record also answers exposure, runtime location and incident ownership. Neither replaces the other.
Read the grant, conditions and termination as one control
Teams often stop at a broad grant such as use, modify and distribute. The conditions determine whether those verbs remain available in the proposed route.
Read at least these sections together:
- Covered material: weights only, or also architecture, code, data and documentation?
- Grant: use, reproduce, modify, create derivatives, serve, distribute, sublicense, sell and import.
- Conditions: attribution, licence copy, notices, naming, downstream terms, use restrictions and disclosure.
- Reserved rights: trademarks, patents, third-party material, training data, output and publicity rights.
- Termination: breach, patent or copyright claims, policy change and cure or deletion requirements.
- Scope: entity, affiliates, user thresholds, territory, field of use and governing law.
For example, Apache License 2.0 grants copyright and patent permissions subject to its terms, requires a copy of the licence on distribution, preservation of applicable notices, identification of modified files, and handling of a supplied NOTICE file. It does not grant general trademark permission. A repository that applies Apache-2.0 to weights may offer a permissive path, but the team must still confirm what the licensor actually placed under it and what separately supplied material is outside it.
Do not collapse “no charge”, “royalty free”, “perpetual” and “irrevocable” into one property. They answer different questions. Also preserve the accepted text rather than linking only to a mutable webpage; an investigation must be able to reconstruct the terms that governed the released copy.
Compare actual licence shapes, not friendly labels
Three published examples show why a yes/no open-weight field is inadequate. This table is a deployment-reading aid, not an exhaustive legal opinion.
| Published terms | Useful grant signal | Conditions or limits that change the route |
|---|---|---|
| Apache-2.0 | Use, modification and distribution with an express patent licence | Distribution copy and notices; changed files identified; patent termination; trademark rights reserved |
| OpenMDW-1.1 | Model-centred grant across model materials and covered copyright, patent, database and trade-secret rights | Distributed material keeps the agreement and applicable origin notices; third-party rights remain the user's due-diligence responsibility |
| Llama 4 Community License | Use, reproduce, modify and distribute Llama materials | Licence copy, notice and “Built with Llama” duties; naming rule for a distributed model trained from Llama materials or outputs; incorporated use policy; additional commercial and regional conditions |
The model-specific OpenMDW 1.1 text defines covered Model Materials as the model plus related artefacts provided under the agreement. It permits broad dealing in those materials, requires the agreement and applicable origin notices on distribution, says it imposes no output restrictions, and puts clearance of other people's rights on the user. Its companion site explicitly notes that the licence does not require a publisher to release every possible component.
Meta's Llama 4 Community License is a different shape. It grants use, modification and distribution rights, but it also carries product attribution, notice, model-naming and large-user terms and incorporates an acceptable-use policy. The current Llama 4 use policy also contains a regional restriction for the multimodal models. A team must evaluate the licence and incorporated policy together against its entity, model variant and route.
The lesson is not that one licence family is universally better. It is that the licence must match the intended freedom: internal operation, controlled service, redistributable product, derivative model or genuinely open collaboration.
Keep four unresolved-rights questions visible
A model licence can grant only rights held or controlled by the licensor and only for the material it covers. Keep separate findings for:
- Training and fine-tuning inputs: what is disclosed about provenance, reservations, consent and permitted reuse?
- Third-party components: which tokenizer, library, dataset, font, media or benchmark terms travel independently?
- Outputs: does the model agreement address output ownership or restrictions, and what third-party rights could still exist in a particular output or use?
- Regulation and [contract](/industries/legal): what sector, privacy, consumer, export, employment or customer duties apply regardless of the model licence?
Open source is not a regulatory waiver. The European Commission's current general-purpose AI model Q&A explains that a qualifying free and open-source release can remove specific documentation duties under Article 53(1)(a) and (b), but not the copyright-policy and public training-summary duties, and not the obligations for a general-purpose model with systemic risk. Downstream fine-tuning or integration can also create its own responsibilities. Teams operating in or serving the EU should determine the current position for their role and obtain advice rather than converting an “open” label into a compliance conclusion.
The same separation applies to infrastructure. A right to run locally does not prove that a cloud image, quantised conversion or hosted endpoint uses the same artefact and terms. Verify the complete data-residency and execution path when location or supplier control matters.
Turn licence review into a release gate
Create one route-specific record that engineering, procurement, legal and product owners can inspect. The gate should fail closed when the exact terms or covered artefacts cannot be established.
Before release, require:
- a verified artefact manifest and immutable licence snapshot;
- a route matrix with permitted, conditional, prohibited or unresolved for each planned act;
- implemented notices, attribution, naming and downstream delivery requirements;
- controls that enforce use, user, territory or field restrictions where applicable;
- a separate finding for training data, third-party components, outputs and regulation;
- counsel approval for material ambiguity rather than an engineer's interpretation;
- an exit plan for termination, supplier term changes or a prohibited future route; and
- a trigger list covering new versions, licences, policies, territories, affiliates, products and distribution methods.
Test the evidence, not only the document. Build the release package and verify that licence and NOTICE files are present. Inspect the product UI or documentation for required attribution. Attempt a disallowed route in policy or CI and confirm it is blocked. Reconstruct the checkpoint, terms, approvals and customer delivery from the retained record. Add the result to the AI assurance evidence pack without claiming that paperwork clears undisclosed rights.
Measure the percentage of deployed model artefacts with an exact digest and retained terms; routes with no unresolved rights; releases blocked before an incompatible distribution; notice and attribution defects; licence or policy changes detected; time to remove or replace a model; and customer packages whose obligations can be reconstructed.
Revisit the gate whenever the artefact, licence text, incorporated policy, component set, legal entity, territory, user scale, training method, output use or delivery route changes. The durable rule is simple: approve a model for a defined route under a defined terms snapshot—not for the organisation in general. Download access starts the review; it never finishes it.
