AI Model Licenses Explained: Apache 2.0, MIT, Llama Community, OpenRAIL and What Commercial Use Really Allows

A model you can download is not necessarily a model you can ship. Teams routinely pull a checkpoint from a hub, fine-tune it, wrap it in a product, and only discover months later that the weights came with a naming rule, a user-count ceiling, a use policy that binds their customers, or a clause that lets the licensor shut down a deployment. The word “open” in a press release tells you almost nothing about any of this. The ai model licenses attached to weights are a patchwork of software licenses, bespoke contracts, and behavioral-use agreements, and the differences are material to anyone building a commercial product.

This matters more in 2026 than it did two years ago because the open-weight field has filled up with strong models, and the license is now often the deciding factor between two checkpoints of similar quality. Some vendors have moved toward plain permissive terms; others keep custom agreements with thresholds and obligations. This post reads the actual license texts, clause by clause, and leaves you with a decision framework you can apply to any new release.

What this covers: the open source versus open weights distinction, what Apache 2.0 and MIT really grant, the Llama, Qwen and Gemma custom licenses, the OpenRAIL family and DeepSeek’s use-restricted license, how obligations travel through fine-tuning and distillation, and a decision matrix. This is engineering analysis, not legal advice.

Context and Background

Software licensing grew up around source code, where the thing being licensed is obvious: text a human can read and recompile. A model release is stranger. It bundles at least four separable artifacts: the training and inference code, the trained parameters (the weights), the training data, and the outputs the model generates. A license that was designed for one of these may say nothing coherent about another. Apache 2.0, for example, speaks of “Source” and “Object” form, concepts that map awkwardly onto a file of floating-point tensors.

That mismatch is why three families of terms coexist today. The first is the classic permissive software license, applied directly to weights: Apache 2.0 and MIT. The second is a bespoke “community” or “terms of use” agreement written by the model vendor, as Meta, Alibaba (for some Qwen releases) and, until its latest generation, Google did. The third is the Responsible AI License idea, where the license carries behavioral restrictions that must follow the model downstream. The BigScience project introduced that style with its OpenRAIL-M license, and later projects such as BigCode adapted it.

Against that backdrop sits the question of definitions. The Open Source Initiative published the Open Source AI Definition 1.0 in October 2024. It requires four freedoms (use, study, modify, share) and, for a machine-learning system, three kinds of access: sufficiently detailed information about the training data, the complete code used to train and run the system, and the parameters. Many widely used “open” models fail that bar because they publish weights but not data information or training code, regardless of how permissive the weight license is. Throughout this post, “open weights” means the parameters are downloadable under some license, and “open source AI” is reserved for releases that satisfy the OSI definition.

If you are tracking how the market got here, our analysis of the open-weight model flood in June 2026 covers the supply side. This article covers the legal surface a team has to cross to use that supply.

Why a license is a product requirement

For a company, a license is an interface contract with an upstream vendor you cannot negotiate with. It defines what you may do (the grant), what you must do (conditions such as attribution and notices), what you must not do (use restrictions), and how the arrangement can end (termination). Each of those four has direct engineering consequences. A naming rule changes your model registry. A notice-file requirement changes your packaging pipeline. A use policy that must be passed to customers changes your terms of service. A termination clause changes your risk assessment for any workload that cannot be quickly migrated.

Treat the license review the way you treat a dependency security review: it belongs in the model selection stage, before fine-tuning investment, and it should be recorded alongside the model’s provenance. The same discipline applies to supply-chain integrity, which we examine in AI model supply chain security and provenance.

The License Landscape: Four Families and Where Models Fall

The direct answer to “what can I do commercially with an open model” is this: with Apache 2.0 or MIT weights, you can use, modify, host and sell products built on them with only notice and attribution duties; with custom community licenses you can usually do the same but face extra conditions such as user-count thresholds, naming rules, use policies and termination rights; with OpenRAIL-style licenses you can do it provided you pass behavioral restrictions to everyone downstream. Always read the specific version shipped with your checkpoint.

Figure 1: Where a released model lands. Public weights are only the first gate; the license family decides what you can actually do.

Figure 1 shows the sorting logic. Publishing weights does not by itself make anything open source in the OSI sense. The license then places the release in one of four broad bins, and most commercial teams only need to distinguish the first three, because research-only and non-commercial terms rule themselves out.

Family 1: permissive software licenses (Apache 2.0 and MIT)

Apache 2.0 and MIT are the lowest-friction licenses in common use. Both grant broad rights to use, copy, modify and redistribute, and both disclaim warranty. They differ in the details that matter for a commercial team.

Apache 2.0 section 2 grants each contributor’s copyright license as perpetual, worldwide, non-exclusive, no-charge, royalty-free and irrevocable, covering reproduction, derivative works, public display, sublicensing and distribution. Section 3 adds an explicit patent license limited to claims necessarily infringed by the contributor’s contribution, and it terminates that patent license for anyone who files patent litigation alleging the work infringes a patent. Section 4 sets the conditions for redistribution: give recipients a copy of the license, mark modified files, retain existing notices, and carry forward the contents of any NOTICE file. Section 6 withholds trademark rights, and section 7 provides the work “AS IS”. You can read the full Apache License 2.0 text in a few minutes, and for a model release it is worth doing.

MIT is shorter. It grants permission, free of charge, to use, copy, modify, merge, publish, distribute, sublicense and sell, subject to one condition: the copyright notice and permission notice must be included in all copies or substantial portions. It carries the same “AS IS” disclaimer. What it lacks is an express patent grant and a patent-retaliation clause. In practice that is a modest difference for most users, but it is the reason some legal teams prefer Apache 2.0 for artifacts that may be implicated in patent disputes.

For model weights, one practical point dominates: neither license limits who can use the model, how many users you have, or what you build. Neither requires your product to carry the vendor’s name. Neither requires you to open-source your fine-tune. Neither gives the licensor a termination right for ordinary breach in the way the custom agreements below do, although a failure to meet the conditions means you are no longer within the grant.

Family 2: bespoke community licenses

Meta’s Llama licenses, Alibaba’s older Qwen license, and Google’s Gemma Terms of Use (for the generations they cover) are contracts written specifically for model distribution. They look like permissive licenses at first glance, because they grant a worldwide, royalty-free right to use, reproduce, modify and distribute. But they add layers: thresholds at which you must negotiate a separate license, naming and attribution rules that apply to derived models, acceptable-use policies incorporated by reference, and termination for breach. We go through each in the next section.

Family 3: OpenRAIL and behavioral-use licenses

Responsible AI Licenses treat the model as an artifact whose misuse should be contractually restricted. The BigScience OpenRAIL-M design grants free, royalty-free access and permits redistribution of the model and derivatives, but it attaches use-based restrictions in an attachment and requires that anyone who redistributes the model or its derivatives embed those restrictions, even if they use a different license for their own modifications. The “Open” in the name was added because the earlier RAIL label did not signal that access and redistribution were free.

Family 4: research-only and non-commercial terms

Many checkpoints, especially academic or early-access releases, are limited to research or non-commercial use. These are out of scope for a product team unless a separate commercial license is purchased. They are worth flagging because model hubs display them next to permissive ones, and an automated pipeline that pulls “the best open model” without a license filter can end up with a checkpoint it cannot legally deploy.

The Custom Licenses, Clause by Clause

The three most consequential custom agreements all share a skeleton: grant, redistribution conditions, use policy, thresholds or naming, and termination. The details diverge. What follows is based on the texts as fetched for this article; license texts change between model generations, so confirm the file shipped with the exact checkpoint you use.

The Llama Community License

The Llama 3.1 Community License is the best-known template. Section 1(a) grants a non-exclusive, worldwide, non-transferable and royalty-free limited license to use, reproduce, distribute, copy, create derivative works of, and modify the Llama Materials. The word “limited” and the phrase “non-transferable” signal that this is a contract with conditions, not a permissive software license.

The monthly active user (MAU) threshold. If, on the Llama 3.1 release date, the monthly active users of your products or services, or those of your affiliates, exceeded 700 million in the preceding calendar month, you must request a license from Meta. Meta may grant or refuse that request in its sole discretion, and you have no rights under the agreement until it does. Note the test date: it is measured at the release date of that Llama version, not continuously. For nearly every company this clause is irrelevant, but it matters for a handful of hyperscale competitors, and for acquisition due diligence, since an acquirer with a large user base may be affected.

Attribution and naming. If you distribute Llama Materials, derivatives, or a product that contains them, you must prominently display “Built with Llama” on a related website, user interface, blog post, about page or product documentation. If you distribute an AI model that you created, trained, fine-tuned or improved using the Llama Materials or their outputs, the name of that model must include “Llama” at the beginning. This is the clause that surprises people most. It means a distilled model trained on Llama outputs and then published must carry a Llama-prefixed name. The agreement also requires an attribution notice in a Notice text file, stating that the version in question is licensed under its Community License with Meta’s copyright.

Redistribution and use policy. You must give recipients a copy of the agreement, comply with applicable laws including trade compliance, and comply with the Acceptable Use Policy, which the agreement incorporates by reference. The Llama 4 policy, for instance, prohibits categories such as violating laws or others’ rights, activities risking death or bodily harm (including military and weapons uses and operating critical infrastructure), deception (including fraud, disinformation and presenting AI output as human generated), and failing to disclose known dangers of your AI system to end users.

Regional carve-out in Llama 4. The Llama 4 use policy contains a notable exception: for the multimodal models included in Llama 4, the rights granted under section 1(a) of the Llama 4 Community License are not granted to individuals or companies with a principal place of business in the European Union. The text states that this restriction does not apply to end users of products or services that incorporate these models. Practically, an EU-based company that wants to build on those multimodal checkpoints needs another route, while an EU consumer using a US vendor’s app is not caught.

Termination, patents, governing law. Meta may terminate for breach, after which you must delete the Llama Materials and stop using them. Your licenses also end if you sue Meta or another entity alleging that the Llama Materials or their outputs infringe your intellectual property. California law governs, with exclusive jurisdiction in California courts, and the contracting entity is Meta Platforms Ireland Limited for EEA and Swiss users or Meta Platforms, Inc. elsewhere.

The Qwen license (older generations) and the shift to Apache 2.0

Alibaba’s Qwen family has used different terms across sizes and generations. The Qwen LICENSE AGREEMENT released in September 2024, which accompanied Qwen2.5-72B, grants a non-exclusive, worldwide, non-transferable, royalty-free license. Its commercial threshold is 100 million monthly active users: above that, you must request a license from Alibaba Cloud and cannot exercise your rights without express authorization. Redistribution requires a copy of the agreement, prominent notices on modified files, and a Notice file stating that Qwen is licensed under the Qwen LICENSE AGREEMENT. If you use the materials or their outputs to create, train, fine-tune or improve a distributed or publicly available AI model, you must prominently display “Built with Qwen” or “Improved using Qwen” in the product documentation.

Two clauses deserve attention because they differ from Meta’s. First, the agreement requires you to defend and indemnify Alibaba against third-party claims arising from your use or distribution, which is an unusual burden for a “free” model. Second, governing law is Chinese law with exclusive jurisdiction in the People’s Courts of Hangzhou. Export-control compliance covers China, the United States and other countries.

At the same time, other Qwen checkpoints have been released under plain Apache 2.0. The Hugging Face model card for Qwen3-235B-A22B lists Apache-2.0 in its header. The lesson is that “Qwen” is not a license; each repository carries its own file, and a family can span several. Our write-up on Qwen 3.6 architecture and benchmarks notes the model-level details, but always check the license file in the repo you pull.

Gemma: from Terms of Use to Apache 2.0

Google’s Gemma Terms of Use were a custom agreement with several distinctive features, and they still govern the models listed in that document’s appendix. The agreement defines Model Derivatives broadly: changes to Gemma, works built on it, and other models trained to mimic Gemma by transferring its weights, parameters, operations or Outputs, which expressly includes distillation and training on Gemma-generated synthetic data. It says Outputs themselves are not Model Derivatives, and Google claims no rights in Outputs you generate, leaving responsibility for them with you and your users.

Redistribution of Gemma or Model Derivatives requires passing the use restrictions to recipients in an enforceable agreement with notice, providing the agreement, marking modified files, and, for non-hosted distributions, including a Notice file. The use restrictions live in a separate Gemma Prohibited Use Policy incorporated by reference. The most discussed clause is the remote restriction right: Google reserves the right to restrict, “remotely or otherwise,” usage it reasonably believes violates the agreement, to the extent the law allows. Termination is available on breach, and on termination you must delete all copies you control and stop using and distributing them. For the older generation, see our Gemma 3 architecture and benchmarks analysis.

The important update is that the Terms of Use page states they apply to the models in its appendix, which does not include Gemma 4 or later. The page linked as the Gemma 4 license presents the Apache License 2.0, and press coverage at launch described the move to Apache 2.0 as the headline change. For a team, this is a real shift: a Gemma 4 derivative no longer inherits the prohibited-use pass-through or the remote-restriction clause of the earlier terms, while a Gemma 3 derivative still does. The same family name now spans two incompatible legal regimes, which is exactly why checking the per-checkpoint file matters.

DeepSeek: MIT for recent weights, a use-restricted license before that

DeepSeek-R1’s Hugging Face card states that the code repository and model weights are licensed under the MIT License, that the series supports commercial use, and that it allows “any modifications and derivative works, including, but not limited to, distillation for training other LLMs.” That is about as permissive as a frontier-class release gets.

Earlier DeepSeek releases used the DeepSeek License Agreement, version 1.0 dated 23 October 2023, which is an OpenRAIL-style document. It grants a perpetual, worldwide, non-exclusive, royalty-free copyright license, with a patent license that terminates if you sue over the model. Its use-based restrictions (Attachment A) bar unlawful activity, military use, exploiting or harming minors, generating false information intended to harm, unauthorized personal data, defamation and harassment, fully automated decisions that adversely affect legal rights, and several forms of discrimination. Hosting or distributing the model or its derivatives requires embedding those restrictions as an enforceable provision, supplying the license, and marking changes. Its definition of derivatives expressly reaches distillation and training on synthetic data generated by the model. Governing law is PRC law, and section 7 lets DeepSeek restrict violating usage “remotely or otherwise.”

If you need to check where a recent DeepSeek checkpoint stands, read the repository’s license file rather than inferring from the brand; our DeepSeek V4 deep dive and V4.1 Flash write-up cover the models themselves, not their legal terms, and I have not verified the license text of those specific checkpoints for this article.

OpenRAIL in detail

An OpenRAIL license is a hybrid: it contains a copyright license, usually a patent license, and conditions on use. Using BigCode’s adaptation as an example, its documentation describes a contractual agreement with those three parts, and says compliance with the restrictions in Attachment A is a condition to the use of the model or modification of the model. Attachment A items include use that violates applicable law, generating or disseminating malware, verifiably false information to harm others, publishing generated content without clearly disclaiming that it is machine-generated, impersonating humans to deceive, and fully automated decisions affecting legal rights without a machine-generated disclaimer. The BigCode page notes the list is not exhaustive of possible harms.

Two engineering details matter. Downstream propagation: whoever shares the model or modifications must include the responsible-use terms, either Attachment A or a similar set of restrictions. “Modifications” are defined to include quantization, fine-tuning, prompt-tuning, adapters, distillation, and models trained on synthetic data generated by the model, and modified versions must come with explanatory documentation of the same or better quality. And authority: BigScience’s design lets the licensor seek case-specific authorization when a user believes a restricted use is harmless, and lets the licensor restrict use, including remotely, when the license is violated.

How Obligations Travel Through Fine-Tuning and Distillation

The real work of license compliance happens after you start modifying a model. Fine-tuning, quantization, merging and distillation all create new artifacts whose license status depends on the upstream grant.

Figure 2: Obligations attach to the base model and flow outward. Notice files, naming and use policies follow the weights, while end users of a hosted product are usually not parties to the redistribution terms.

Figure 2 maps the flow. Three kinds of obligation ride along with the artifact: documentation duties (license copy, notice file, change markings), naming and branding duties (such as “Built with Llama” and the Llama prefix), and use-policy duties (restrictions you must flow to your recipients). A fourth, the threshold or authorization rule, sits with you rather than with the artifact: it depends on your user base.

Hosted use versus distribution

Almost every custom license distinguishes between using a model and distributing it. Running a model behind your own API, serving your own customers, is “use” in the sense that you operate the weights. You must follow the acceptable-use policy and any naming requirements that apply to products, but you are not handing the weights to a third party. Distribution, by contrast, includes publishing a fine-tune on a hub, shipping an on-device model inside an app, or giving weights to a customer for on-premises deployment. Distribution triggers the heavier conditions: license copy, Notice file, change markings, and the pass-through of use restrictions to the recipient in an enforceable agreement.

This distinction has direct architecture consequences. An on-device or on-premises product distributes weights; a SaaS product does not. If you plan to ship a model inside a mobile app under the Llama or older Gemma terms, you need a mechanism to deliver the license and the notice and to bind the user to the use policy, which is a product and legal design task, not only a packaging task.

Distillation and synthetic data

The sharpest legal question in 2026 is whether training a new model on a licensed model’s outputs creates a derivative. The licenses answer differently. Meta’s agreement applies its “Built with” and naming conditions when you use the Llama Materials or their outputs to create, train, fine-tune or improve a distributed AI model. Qwen’s 2024 license has an analogous “Built with Qwen” or “Improved using Qwen” rule. Gemma’s Terms of Use treat models trained to mimic Gemma via its outputs as Model Derivatives, while saying Outputs themselves are not. The older DeepSeek license and the OpenRAIL definition of modifications both name distillation and synthetic-data training explicitly. DeepSeek-R1’s MIT terms, in contrast, expressly allow distillation for training other LLMs.

The practical rule is: if your training pipeline ingests outputs from a licensed model, treat that upstream license as part of your training data’s provenance record. A distilled model released commercially may inherit naming rules, pass-through restrictions, or both.

A related complication appears in distilled releases themselves. The DeepSeek-R1 card notes that its distilled Qwen-based models derive from Qwen2.5, originally Apache 2.0, and that the Llama-based distillations derive from Llama 3.1 and Llama 3.3, which carry those Llama licenses. The same repository family therefore contains a model whose weights are described as MIT-licensed alongside distillations with upstream base-model licensing considerations. The lesson generalizes: a permissive label on the new adapter or fine-tune does not erase the license of the base weights underneath.

Adapters, merges and quantization

LoRA adapters are small, but they are usually derivative works of the base model in the license sense when they are trained against it and only meaningful with it. Whether the adapter alone is a “derivative” can be debated, but the safest handling is to carry the base model’s notice and name rules into any published adapter. Quantized files are straightforward: they are modifications of the weights, and the BigCode definition names quantization explicitly. Model merges combine multiple upstream licenses, and the most restrictive upstream condition generally governs the result; if one parent has a naming rule and another has a use policy, you inherit both. Our guide to LoRA, QLoRA, full fine-tuning and distillation explains the technical differences between these methods; the legal point is that none of them launders the license.

A Worked Compliance Walk-Through

Consider an illustrative scenario. A mid-sized company wants to fine-tune an open model for contract summarization, serve it from its own API, and also ship a compressed version inside an on-premises appliance for a regulated customer. The numbers below are hypothetical and exist only to show how the analysis proceeds.

Figure 3: A practical decision flow. Start with the license family, then check thresholds and regions, then separate hosted use from distribution.

Step one is the license family. If the checkpoint is Apache 2.0 or MIT, the walk-through is short: include the license and notices when you ship the appliance, keep copyright notices, and mark your modifications if you redistribute source-like artifacts. There is no threshold and no naming rule. Step two applies only to custom licenses: check the MAU threshold against your own and your affiliates’ user base (illustratively, a company with 20 million users is far below either the 100 million Qwen or 700 million Llama figures), and check whether the company’s principal place of business falls in a region carved out of the grant, as with the Llama 4 multimodal models and the EU.

Step three is the hosted-versus-distributed split. Your API serves outputs, so you comply with the acceptable-use policy and display any required branding. The appliance distributes weights, which triggers redistribution conditions: give the customer a copy of the license, include the Notice file, flow the use restrictions into your customer agreement as an enforceable provision, and if the license requires it, name the fine-tuned model with the required prefix. Step four is documentation: record the base model, its exact license file hash and version, the date retrieved, and the obligations you determined apply. This record is your defense in diligence and audits.

A minimal license inventory script

The following Python snippet shows one way to inventory the license metadata exposed by the Hugging Face Hub for a list of candidate models. It reads the declared license tag and the repository’s license file name where present. It is a screening aid only; the declared tag can be missing or wrong, and the file text is what binds you.

from huggingface_hub import HfApi

api = HfApi()
candidates = ["Qwen/Qwen3-235B-A22B", "deepseek-ai/DeepSeek-R1"]

for repo in candidates:
    info = api.model_info(repo, files_metadata=False)
    declared = [t for t in (info.tags or []) if t.startswith("license:")]
    license_files = [
        s.rfilename for s in (info.siblings or [])
        if s.rfilename.lower().startswith("license")
        or s.rfilename.lower() in ("notice", "notice.txt", "use_policy.md")
    ]
    print(repo, declared or ["license: undeclared"], license_files)

Treat the output as a triage list. Anything declared as “other”, “llama” or similar custom tags needs a human to read the text. Anything undeclared is a stop sign. Store the retrieved license text and its hash with your model registry entry so you can prove which terms applied on the day you adopted the weights.

Decision Matrix: What Commercial Use Really Allows

The table below summarizes the verified points for the licenses discussed. It simplifies, and each cell reflects a specific version noted in the text above, so confirm against the checkpoint you use.

Dimension	Apache 2.0	MIT	Llama 3.1 Community	Qwen License (2024)	Gemma Terms of Use	OpenRAIL-M family
Commercial use	Yes	Yes	Yes, with conditions	Yes, with conditions	Yes, with conditions	Yes, with conditions
User-count threshold	None	None	700M MAU, request license	100M MAU, request license	None found in terms reviewed	None
Naming or attribution rule	Keep notices, NOTICE file	Keep copyright notice	“Built with Llama”, Llama prefix on derived models	“Built with Qwen” or “Improved using Qwen”	Notice file for non-hosted distribution	Include use restrictions and docs
Use restrictions passed downstream	No	No	Acceptable Use Policy by reference	Not as a behavioral list; export and law compliance	Prohibited Use Policy, enforceable agreement	Yes, mandatory
Express patent license	Yes, with retaliation	No	Termination if you sue over IP	Termination if you sue over IP	Not reviewed in detail	Usually yes
Licensor termination or restriction right	No general right	No	Terminate on breach	Terminate on breach	Terminate on breach, remote restriction	Restrict use on violation
Distillation treatment	Unrestricted	Unrestricted	Naming rule triggered	Attribution rule triggered	Counts as Model Derivative	Counts as Modification
Governing law	Not specified	Not specified	California	China, Hangzhou courts	Not reviewed in detail	Varies by license

Which license for which use case

For a startup building a hosted product, an Apache 2.0 or MIT model removes most legal review. For an enterprise shipping on-premises appliances, permissive terms also simplify matters, because distribution under a custom license forces you to build a pass-through mechanism. For a research lab that wants to publish a fine-tune, permissive base licenses are again simplest; under Llama or older Qwen terms you must rename and attribute. For a regulated or safety-sensitive deployment, a use-restricted license may actually be useful: it gives you a contractual basis to prohibit misuse by downstream customers.

Trade-offs, Gotchas, and What Goes Wrong

The most common failure is assuming that a hub label equals the license. Model cards sometimes display a short tag while the repository contains a longer agreement with additional terms. The reverse also happens: a family name implies a license that the specific checkpoint does not carry, as with Qwen and Gemma, each of which now spans multiple regimes.

A second failure is mixing sources. Training a model on outputs from several licensed models creates stacked obligations, and a naming rule from one upstream can conflict with the naming rule of another. Meta requires a Llama-prefixed name; Qwen requires a “Built with Qwen” notice; there is no legal ordering that makes a single model name satisfy both prefixes in an obvious way, so teams often avoid training on more than one restricted upstream.

A third failure is ignoring termination and remote-restriction clauses. These are rarely exercised against ordinary commercial users, and I am not aware of a verified case in which a licensor has remotely disabled a downstream deployment of downloaded weights; the technical enforceability of remote restriction against a self-hosted model is doubtful. But the clause matters for risk assessment: it signals the licensor’s reserved power, and a contractual termination for breach means you must delete copies and stop using them, which for a production workload is a serious continuity event. Where continuity is critical, prefer permissive terms or keep a tested fallback model.

A fourth failure is the “open source” trap. Marketing may call a custom-licensed model open source. Under the OSI definition it is not, because the license restricts field of use or imposes thresholds, and because many releases omit data information and training code. This matters when a customer contract or procurement policy requires “open source” components; you may need to say “open weights” and describe the actual terms. Calling something open source when it is not can also create reputational risk.

A fifth failure concerns outputs. Most vendors say they claim no rights in outputs, and Gemma’s Terms of Use expressly leave responsibility for outputs with you. But output ownership as a license matter is separate from whether outputs infringe third-party rights, which licenses disclaim. BigCode’s documentation notes that code outputs may be subject to third-party rights or other open-source licenses and points to a dataset search tool. A permissive weight license does not clear the rights in what the model emits.

Finally, license drift. A vendor can change terms between model versions, as the Llama texts differ across generations and Gemma moved from custom terms to Apache 2.0. Your inventory should record the version, not just the family, and your upgrade process should include a license diff alongside the benchmark comparison. If the upgrade changes the license, treat it as a change request with legal review.

Figure 4: The chain of custody for terms. The developer passes weights, license copy and use restrictions to downstream users; a breach at the end of the chain can lead the licensor to terminate or restrict use.

Figure 4 shows why a breach by your customer can become your problem. Under the pass-through licenses, you are contractually responsible for flowing the restrictions to recipients in an enforceable form. If a downstream user violates the use policy and you did not bind them, you may be the party in breach with the licensor.

Practical Recommendations

Start by treating the license as a first-class selection criterion. When two models are close in quality, choose the one with simpler terms, because the saved legal and operational effort is real. Prefer Apache 2.0 or MIT where capability allows, and treat custom licenses as a cost you accept deliberately.

Build a license inventory into your model registry. For every model and adapter, store the repository URL, commit hash, retrieved license text, license hash, retrieval date, and a short “obligations” note covering notices, naming, thresholds and use-policy pass-through. Update it when you upgrade. This turns a vague worry into a queryable record and makes customer security questionnaires straightforward.

Separate hosted use from distribution in your product plan. If you only ever serve through your own API, many conditions do not bite. If you intend to ship weights, design the license delivery, notice packaging and customer-agreement flow-down from the beginning. Decide your naming convention early, since renaming a published model later is disruptive.

Be conservative with distillation. If you plan to train on a licensed model’s outputs, read the relevant clause first, and prefer teachers whose licenses expressly permit distillation, such as an MIT-licensed model whose card states it. Keep generation logs showing which teacher produced which training data.

Finally, involve counsel for anything with real exposure. This article summarizes publicly available text and is not legal advice; jurisdiction, contract formation, and enforceability vary, and I have not verified every clause of every license mentioned.

Read the license file in the exact repository and commit you use.
Record license text, hash and date in your registry.
Check MAU thresholds and regional carve-outs against your corporate group.
Decide hosted versus distributed before you fine-tune.
Flow use policies to customers in enforceable contract terms.
Apply naming and notice rules to every published derivative and adapter.
Re-run the license check on every model upgrade.

Frequently Asked Questions

Is an open-weight model the same as an open source model?

No. Open weights means the parameters are downloadable under some license. Under the Open Source AI Definition 1.0, an open source AI system must grant four freedoms (use, study, modify, share) and provide information about training data, the complete code, and the parameters under OSI-approved terms. Many releases with permissive or custom licenses publish weights but not detailed data information or training code, so they are open weights rather than open source AI in the OSI sense.

Can I use the Llama Community License for a commercial product?

Generally yes. The Llama 3.1 agreement grants a worldwide, royalty-free limited license to use, modify and distribute, with conditions: show “Built with Llama,” start the name of any distributed derived model with “Llama,” include the Notice file, and follow the Acceptable Use Policy. Companies whose products exceeded 700 million monthly active users on the release date must request a license from Meta. Llama 4 multimodal models carry a separate carve-out for EU-based principal places of business.

Does Apache 2.0 let me fine-tune a model and keep my version closed?

Yes, as far as the license is concerned. Apache 2.0 permits derivative works and lets you add your own terms for your modifications, provided you meet the redistribution conditions: give recipients the license, mark changed files, keep notices and carry forward any NOTICE content. It does not require you to publish your fine-tune. Check that the training data and the base model’s other components do not add separate obligations.

What is an OpenRAIL license and does it allow commercial use?

OpenRAIL is a family of Responsible AI Licenses that grant free access and redistribution but attach use-based restrictions, which must be included whenever the model or its modifications are shared. Commercial use is allowed provided you comply with the restrictions, for example no malware generation, no deceptive impersonation, and no fully automated decisions affecting legal rights without a disclaimer. The restrictions are conditions of use, so a violation puts you outside the license.

Can I train my own model on outputs from a licensed model?

It depends on the teacher’s license. Meta and Qwen’s 2024 terms apply naming or attribution rules when you use outputs to train a distributed model. Gemma’s Terms of Use treat models trained to mimic Gemma as Model Derivatives. The DeepSeek-R1 card expressly permits distillation under MIT. Read the clause for your teacher, keep records of what data came from which model, and consult counsel for commercial releases.

What changed with Gemma 4 licensing?

Google’s Gemma Terms of Use cover the models in that document’s appendix, which does not include Gemma 4 or later. The page linked as the Gemma 4 license presents the Apache License 2.0. That removes the Prohibited Use Policy pass-through and remote restriction clause of the earlier terms for Gemma 4 derivatives, while Gemma 3 and earlier remain under the Terms of Use. Always confirm against the specific checkpoint’s license file.

AI Model Licenses Explained: Apache 2.0, MIT, Llama Community, OpenRAIL and What Commercial Use Really Allows (2026)