A Downloadable AI Model Can Still Block Your Paid API

Picture one deployment: a software company downloads a model, fine-tunes it on support tickets, places the resulting weights behind a paid API, then gives an enterprise customer an on-premises copy. The engineering work may be permitted at step one and restricted by step four, even though the same model was described as open, downloadable, or commercially usable.

That gap matters because “open model” has no single license meaning. An open-weight model, meaning one whose trained parameters can be downloaded, may arrive under Apache License 2.0, a vendor community license, research-only terms, or a custom agreement tied to an acceptable-use policy. Those documents grant different rights.

The practical change is straightforward. Model selection now needs a license gate before fine-tuning begins, rather than a compliance check after an API, derivative model, and customer delivery package already exist.

Download access is only the first permission

The support model’s first step, downloading weights onto a company server, answers one narrow question: the vendor has made the files available under stated terms. It does not settle whether the company can charge for inference, expose the model through an API, transfer a fine-tune to a customer, or use its outputs to train another model.

Apache License 2.0 offers a relatively permissive baseline. Models released under it, including Mistral AI’s Mistral 7B, can generally be used, modified, and redistributed commercially, subject to requirements such as preserving the license, retaining applicable notices, and marking modified files. The license also includes a patent grant but no trademark permission.

It does not add a model-specific behavioral policy by itself.

A hosted API usually does not hand customers a copy of the weights, so Apache redistribution duties may not arise in the same way they would for the support model’s on-premises package. That distinction makes an API-first product newly practical with less license administration, although separate rules covering data, outputs, export controls, or regulated uses can still apply.

Custom model licenses move the boundary. They may permit commercial deployment while attaching conditions to scale, branding, downstream access, prohibited uses, or the creation of another model. “Commercial use allowed” is therefore an incomplete answer. The useful answer identifies the exact product architecture that is allowed.

Hosted inference can count as distribution

Return to the paid support API. Engineers may assume that no redistribution occurs because the weights remain on company infrastructure, but a license can define distribution more broadly than sending a file.

Google’s Gemma Terms define distribution to include making Gemma or its functionality available through a hosted service, including API or web access. That documented definition pulls the support API into the license’s distribution provisions even though customers never download a checkpoint. The terms require downstream controls, including terms governing the customer’s use that are no less restrictive than Gemma’s use restrictions.

This changes the setup work. The company cannot review only the repository’s download button and a short model-card label; it must compare Gemma’s terms and prohibited-use policy with the API’s customer agreement, access controls, moderation design, and suspension process. If the product terms promise broader use than the model terms allow, adding a disclaimer after launch does not repair the mismatch.

Meta’s Llama 3.1 Community License takes another route. It permits commercial use but incorporates an acceptable-use policy, sets attribution requirements for distributing or making Llama materials and derivatives available, and applies an additional licensing condition to organizations above its stated monthly-active-user threshold. It also specifies naming requirements in certain cases where Llama materials or outputs are used to create or improve another AI model.

For the support workflow, the hosted API and the on-premises delivery therefore require separate readings. Keeping weights private may avoid some obligations triggered by making model materials available, while the acceptable-use policy still governs the deployment. Sending a fine-tuned checkpoint to the enterprise customer is the clearer redistribution event and brings notice, attribution, and downstream-license language into focus.

A fine-tune is not a licensing reset

Fine-tuning, which updates a pretrained model on a narrower dataset, changes the weights but rarely erases the original license. Custom licenses commonly define the result as a derivative model or derivative work, then require specified terms or notices to follow it downstream.

That matters at the third step of the support deployment. The company may own its training code, support-ticket dataset, and newly written adapter files while remaining unable to distribute the combined model under any terms it chooses. Ownership of the added material and permission to use the base model are different questions, and the customer receiving the checkpoint needs rights that reach the base model too.

The same issue appears when teams use outputs as synthetic training data. Llama’s community license contains a specific condition for using Llama materials or outputs to create or improve another AI model. A product team that treats generated examples as ordinary, restriction-free text can miss an obligation that sits in the model license rather than in the fine-tuning pipeline.

Stability AI’s Community License shows a different commercial boundary. Its published terms allow free commercial use of covered core models and derivatives for individuals and organizations below a stated annual-revenue threshold, while organizations above that threshold need an enterprise license. A deployment can therefore remain technically unchanged yet cross into a different licensing requirement as the company’s revenue changes.

For procurement, that is a recurring check rather than a launch-day checkbox. The support model may be cleared during a pilot and require a different agreement later, without a new checkpoint, API version, or engineering release to alert the team.

The review should follow the product, not the label

A workable review starts with the actual support-model diagram: downloaded base weights flow into a fine-tuning job, the result sits behind a paid API, and one customer receives an on-premises copy. Counsel can then map each transfer and use to the license text.

Use this checklist to prepare that review:

1. Identify every governing document. Save the license, acceptable-use policy, model card, repository notices, and any separate commercial terms. Record the model name and repository revision because a vendor can publish several model families under different licenses.

1. Write down the commercial act. Charging for software, operating an internal tool, hosting inference, and transferring weights are not interchangeable. Describe who receives access, what they receive, and whether they can extract or modify the model.

1. Find the license’s definitions. Search for “distribution,” “derivative,” “commercial use,” “hosted service,” “affiliate,” and “user.” A custom definition can control the result; Gemma’s treatment of API access is the concrete example.

1. Trace the fine-tune. Note whether training produces a complete checkpoint, an adapter, or only prompts and retrieval indexes. Then check whether the license treats that artifact as a derivative and what terms must accompany it.

1. Test the intended use against policy restrictions. Acceptable-use rules can prohibit a deployment even when commercial use is generally permitted. Compare them with the product’s users, available features, moderation controls, and escalation path rather than relying on the sales description.

1. Check thresholds and continuing duties. Revenue or user thresholds can change the required license. Attribution, notice files, naming rules, and customer terms can also create work for product, legal, and release engineering after approval.

1. Plan the fallback. Record whether the team would switch to an Apache-licensed model, buy a commercial license, keep the service internal, or remove weight delivery. The fallback should be tested before fine-tuning costs and customer commitments make migration expensive.

The output should be a short decision record attached to the model artifact. It needs the reviewed document copies, the permitted deployment pattern, unresolved restrictions, and a named trigger for re-review, such as customer redistribution or crossing a contractual threshold.

Repository metadata is not enough

A repository’s license badge is useful routing information, not the complete review. Model cards can link to separate policies, vendors can publish different variants under different terms, and copied checkpoints may omit the context shown on the original page.

Keep a snapshot of the terms reviewed with the support model’s build record. If a vendor changes a policy page later, the company can establish which text informed the decision and ask counsel whether the update affects continued use. This takes minutes before training; reconstructing it during an enterprise security review can take far longer.

This is a license-review checklist for discussion with counsel, not legal advice. The engineering decision it enables is narrower and useful: whether this exact model can move through this exact download, fine-tune, API, and on-premises delivery workflow.

Questions people ask

Does

“commercial use allowed” mean I can sell API access?

Not by itself. Check whether the license defines hosted or remote access as distribution, as Google’s Gemma Terms do, and whether an acceptable-use policy governs customer activity. The API’s terms, moderation controls, and downstream restrictions may need to match the model license before paid access is permitted.

Can I give a fine-tuned model to a customer?

Only if the base license permits redistribution and you satisfy its conditions. Those conditions may include supplying the license text, preserving notices, adding attribution, passing restrictions to the customer, or using required naming. A fine-tune usually remains connected to the base model’s terms even when your company created the training data.

Is an Apache-licensed model unrestricted?

No. Apache License 2.0 grants broad commercial, modification, and redistribution rights, but it still requires preservation of license and notice material and does not grant trademark rights. Other law, dataset terms, privacy duties, and product-specific policies can also matter, so Apache is a permissive starting point rather than a universal clearance.

When should a team repeat the license review?

Repeat it before adding hosted access, transferring weights, creating a new derivative, entering a restricted use case, or crossing a revenue or user threshold. Also repeat it when changing model variants. Store the reviewed terms beside the build record so the next check starts from the exact document set used for approval.