Downloaded Model Weights Still Need Four License Checks

Use a support-ticket summarizer as the working case. It reads customer messages, drafts a summary inside a paid software product, and can run either on the developer’s servers or inside a customer’s private cloud. The team has downloaded the model weights, the learned numerical parameters that generate its output, from a public repository.

That download makes local testing practical. It does not settle whether the company can sell the feature, send the weights to customers, omit attribution, process a restricted category of content, or keep using the same terms after crossing a user threshold.

The release gate needs four passes. Each pass should produce a saved document, a short decision, and an owner. This is an engineering and procurement checklist, not legal advice; ambiguous or high-impact cases belong with qualified counsel.

Build a license packet before evaluating the model

Create one folder or release-ticket attachment for the exact model revision. Record the repository URL, model name, weight-file checksum or commit identifier, download date at month-level precision, and the product workflow that will use it. A link alone is weak evidence because repository files and hosted terms can change.

The packet for the support summarizer should have four rows:

| Pass | Document to capture | Release decision | |---|---|---| | Model | Weight license and acceptable-use policy | Use, attribution, modification, scale and distribution allowed | | Code | Licenses for inference code, tokenizer and copied examples | Deployment and redistribution obligations met | | Data | Model card and training-data disclosures | Publisher’s claims recorded; unresolved rights or privacy gaps escalated | | Service | API or hosting terms, if applicable | Inputs, outputs, retention and suspension terms fit the product |

Do not let a repository badge fill all four rows. A model card marked with a familiar license may sit beside code under another license, while the weights are governed by custom terms linked from a separate file.

Pass one: read the weight license against the deployment

Start with the grant. Search the license for commercial use, reproduction, modification, distribution, derivative works and sublicensing. Then test those words against the support summarizer’s real architecture, rather than writing “commercial use permitted” and moving on.

Self-hosting weights for an internal feature differs from placing them in a downloadable desktop application or copying them into a customer-controlled virtual private cloud. The second and third arrangements may count as redistribution, which can trigger notice, license-copy or downstream-use conditions even when charging customers is allowed.

Meta’s Llama 3.1 Community License illustrates why this pass cannot stop at the word “commercial.” Its documented conditions include attribution requirements and incorporation of the agreement when Llama materials or derivatives are distributed. Products or services using the materials must display “Built with Meta Llama 3” in a relevant interface or documentation.

A separate scale condition applies when the licensee’s products or services exceeded 700 million monthly active users in the previous calendar month: the organization must request a license from Meta, and the grant is not automatic.

That combination makes a paid support summarizer practical for many organizations, but it creates two release tasks that an Apache-style code review would miss. The product team needs an approved attribution location, and the business owner needs a user-scale check that can be rerun after growth or acquisition.

Read the acceptable-use policy next. These policies can restrict certain activities even though the base license grants broad rights to run or modify the model. Map each restriction to the actual inputs and outputs: customer complaints, account identifiers, payment disputes, health details, or regulated decisions are not interchangeable merely because all arrive as text.

Record the fallback. If the intended use conflicts with a restriction, the team can choose another model, narrow the workflow, obtain separate permission, or keep a human-only process. Hiding the conflict in a generic risk register does not create permission.

Pass two: separate the code from the weights

The model license does not automatically cover the software wrapped around it. The support summarizer may use an inference server, a tokenizer, a model-loading library, copied repository scripts and container images, each with its own license and dependency chain.

Apache License 2.0, which appears across AI infrastructure projects, generally permits commercial use and redistribution while requiring preservation of specified notices and license text. It also contains an express patent grant and a patent-litigation termination clause. Those mechanics differ from a custom weight license, even when both files appear in one download.

Run the normal software-composition scan, but inspect the files that scanners often classify poorly: model configuration code loaded from a repository, shell scripts copied into an image, tokenizer assets and optional performance kernels. Record whether the company distributes those components to customers or only runs them on its own servers, because distribution usually creates more notice work.

For the customer-cloud version of the summarizer, package the required notices with the deployment artifact. For the hosted version, retain them in the internal bill of materials even if customers never receive the container. The same model now has two compliance paths because the delivery method changed.

Pass three: treat training-data statements as claims, not clearance

A model card may describe broad training-data categories, filtering methods, cutoff periods or exclusions. Save that disclosure and note what it does not say. “Publicly available,” for example, describes accessibility; it does not by itself establish copyright permission, privacy compliance, contractual rights or suitability for every downstream use.

This pass is less binary than the license review. The team should document the publisher’s provenance claims, any named datasets, known opt-out or removal processes, and the absence of detail where disclosure is limited. It should also distinguish pretraining data from the company’s own prompts, retrieval documents and fine-tuning examples.

For the support summarizer, the immediate controllable risk sits in customer tickets. Set a retention period, restrict who can export examples for evaluation, remove unnecessary identifiers, and verify that fine-tuning data came from accounts whose contracts permit that use. None of those controls repairs an unknown upstream training-data chain, but they prevent the deployment from adding a second undocumented dataset.

A publisher’s indemnity, warranty disclaimer or liability cap also belongs in the packet if present. These clauses do not measure technical quality. They identify who bears the cost if a claim arrives, which can change whether self-hosting is worth the procurement burden.

Pass four: check the service that runs the model

Hosted access adds a separate contract. API terms can govern prompt retention, provider training on submitted data, output ownership, geographic processing, rate limits, suspension and prohibited uses. They may change independently of the downloadable-weight license.

This matters when the support summarizer uses the same named model through an API during development and self-hosts it in production. The API’s terms govern the development traffic sent to that provider; the weight license governs the production copy. A test ticket containing real customer data can therefore breach an internal data rule even if the eventual self-hosted deployment is acceptable.

Capture the service terms and privacy documentation in effect when the account is approved. Check whether enterprise settings alter retention or model-training defaults, and save evidence of the selected configuration rather than relying on a sales page. If the provider can revise terms or suspend access, define a fallback model and confirm that prompts, evaluations and retrieval indexes can move without copying restricted assets.

Self-hosting removes the model API contract, not every service condition. Cloud-platform terms, container-registry rules and third-party telemetry still apply, while the model’s own acceptable-use policy may continue to bind the deployment.

Turn the four passes into a release control

The final record should name the approved model revision, deployment modes, attribution text, prohibited workflows, redistribution status, user-scale trigger and next review event. Tie that record to the artifact checksum so a silent model swap cannot inherit approval from a different license.

Rerun the gate when the model version changes, the product starts shipping weights, a provider changes its terms, the workflow moves into a new content category, or company scale approaches a contractual threshold. The support summarizer that passed as an internally hosted drafting tool should not automatically pass after it begins making account decisions or arrives as a customer-downloadable appliance.

A useful stop condition is concrete: no production release until all four packet rows contain a source document, an owner and a written disposition. “Open model” is not a disposition.

Questions people ask

Does downloadable access mean I can use the model commercially?

No. Download access proves that the weights are obtainable, while the license determines permitted use. Some licenses allow paid products but still require attribution, restrict specified activities, regulate redistribution, or apply a scale threshold. Match the exact license revision to the product’s workflow and delivery method.

Is the repository’s license badge enough for approval?

Usually not. A badge may describe repository code while the weights use separate terms, and linked acceptable-use policies can add conditions. Save the weight license, inspect licenses for code and assets, capture the model card, and review hosted-service terms if any prompts leave your infrastructure.

Do

I need a new review if I switch from an API to self-hosting?

Yes. Self-hosting can remove the API provider’s data-retention and service conditions, but it introduces possession of the weights, local security work and possible redistribution duties. The model license and acceptable-use policy still apply, while cloud, container and dependency licenses become part of the deployment record.

What should happen when the license language is unclear?

Pause the affected release path and record the ambiguous clause, intended use, distribution method and business deadline. The practical fallbacks are to narrow the feature, choose a model with clearer terms, seek permission, or request legal review. Keep the unresolved model checksum out of the production allowlist.