Selecting commercial licenses for open-weight LLMs: treating Apache 2.0 / Llama / Qwen / Gemma as a 'design decision'

Let me state the conclusion first. Even an "open-weight" LLM is not necessarily unconditionally free for commercial use. "Open-weight ≠ open-source ≠ free to use" — these three are different things. Even when the weights are published, the conditions of use differ greatly by license, and some carry conditions like "a cap on monthly active users," "an attribution obligation," "naming rules for derivative models," and "passing usage-restriction policies downstream." Putting this off as "I'll check it later" leads to facing a license violation or unexpected constraint right before production launch or at the moment of business expansion. A license should be treated as a 'design decision' made at the very first stage of choosing a model.

This article, based on my experience running quantized open models (Qwen3 on vLLM, 4-bit quantized Llama, etc.) in a commercial product (the #1-ranked AI video platform on CrowdWorks), organizes the selection axes for open-weight LLM commercial licenses from the perspective of buyers and decision-makers.

Important disclaimer: this article is not legal advice. The exact terms of licenses are revised. Before actually adopting, confirm each model's latest license text and consult legal counsel/an attorney as needed. This article provides a map of "what to check."

1. The trap of the word "open-weight"

First, let's get the terms exact. The three that get conflated are entirely different concepts.

Many "open-weight LLMs" adopt proprietary licenses that publish the weights but are not OSI-approved open source. These are called "community licenses," "terms of use," etc., and while permitting commercial use, they impose specific conditions. Not jumping to "free to use" from the ring of the word "open" is the key to avoiding the first pitfall.

2. The five axes that separate commercial licenses

Open-weight LLM licenses can be evaluated on the following five axes. It's a checklist buyers and adopters should confirm.

1. Commercial permissibility — is commercial use allowed, or research-only.
2. Scale cap (MAU, etc.) — does exceeding a certain user scale require separate licensing.
3. Attribution obligation — is a notice like "Built with X" or retention of license/notices required.
4. Treatment of derivatives — naming rules and redistribution conditions for fine-tuned derivative models.
5. Usage-restriction policy — is there a prohibited-use (acceptable-use) policy, with an obligation to pass it downstream.

Organizing these in a machine-readable form makes selection clear. Expressing them as a type lets you compare without omissions.

/** ライセンスの義務を機械可読に表す。採用判断を構造化し、確認漏れを防ぐ。
 *  ※ 値は記事執筆時点の一般的な理解。採用前に必ず最新の正文を確認すること（法的助言ではない）。 */
interface LicenseProfile {
  readonly family: string;
  readonly license: string;
  readonly osiOpenSource: boolean;          // OSI承認のオープンソースか
  readonly commercialUse: "permitted" | "permitted-with-conditions" | "research-only";
  readonly scaleCap?: string;               // 例: 月間アクティブユーザー数の上限
  readonly attributionRequired: boolean;    // 帰属表示の義務
  readonly derivativeNaming?: string;       // 派生物の命名規則
  readonly acceptableUsePolicy: boolean;    // 利用制限ポリシーの引き継ぎ義務
}

// 代表例（執筆時点の一般的理解。正確性は各正文で要確認）
const PROFILES: readonly LicenseProfile[] = [
  {
    family: "Qwen3（多くの dense モデル）",
    license: "Apache 2.0",
    osiOpenSource: true,
    commercialUse: "permitted",
    attributionRequired: true,              // ライセンス・通知の保持
    acceptableUsePolicy: false,
  },
  {
    family: "Llama（Meta）",
    license: "Llama Community License",
    osiOpenSource: false,
    commercialUse: "permitted-with-conditions",
    scaleCap: "月間アクティブユーザー7億超は別途許諾が必要",
    attributionRequired: true,              // "Built with Llama" 等
    derivativeNaming: "派生モデル名に 'Llama' を冠する規則",
    acceptableUsePolicy: true,
  },
  {
    family: "Gemma（Google）",
    license: "Gemma Terms of Use",
    osiOpenSource: false,
    commercialUse: "permitted-with-conditions",
    attributionRequired: true,
    acceptableUsePolicy: true,              // 禁止用途を下流へ引き継ぐ義務
  },
] as const;

3. A practical reading of the major licenses

Apache 2.0 / MIT family (the freest)

Many Qwen3 (dense) models and some of Mistral's published models adopt Apache 2.0. This is OSI-approved open source, where commercial use, modification, and redistribution are broadly permitted, and there's no user-scale cap either. The obligation is mainly about "retaining the license and copyright notices."

For commercial projects that want to avoid lock-in, the Apache 2.0 / MIT family is the first candidate. One reason I adopted Qwen3-family for translation in the AI video-localization platform was that its licensing constraints are light and it was easy to embed in a commercial product. In the sense of "minimizing future constraint risk," license freedom is a legitimate tech-selection axis.

Llama Community License (commercial OK, with conditions)

Llama (Meta) permits commercial use, but several conditions apply. The representative ones are:

• Scale cap — if your product's monthly active users exceed a certain scale (700 million), you need a separate license from Meta. (Effectively irrelevant for many companies, but it bites for ultra-large-scale services.)
• Attribution — a "Built with Llama" notice, or retention of the license terms.
• Derivative naming — adding a prescribed prefix to the name of a derivative model fine-tuned using Llama.
• Acceptable-use policy — prohibited uses are defined.

These are conditions many can meet in practice, but you should recognize the point that it's "not OSI-approved open source." "Llama is free to use" is inaccurate; "Llama can be used commercially with conditions" is accurate.

Gemma and others (commercial OK, usage-restriction pass-through)

Gemma (Google) also permits commercial use, but it carries an obligation to pass the usage-restriction policy (prohibited uses) downstream, and the terms reach the handling of outputs too. This too is not OSI-approved open source. For redistribution, or embedding it in your own product and offering it to third parties, you need to watch this pass-through obligation.

4. Treating a license as a "design decision" (license-as-architecture)

The most important practical lesson is to treat a license not as a confirmation item bolted on later but as a design decision made first. There are three reasons.

1. Changing later is high-cost — discovering a license issue after production launch and swapping to another model is a big job of re-evaluation, re-verification, and re-deployment.
2. It bites during business expansion — scale conditions like an MAU cap become a problem at the very moment the business succeeds.
3. It's entangled with data sovereignty and output rights — a license also relates to the rights of generated outputs and the handling of data.

On the implementation side, by making the model swappable with a provider abstraction, you can keep the option of "if the license terms change, move to another model." This is lock-in-avoidance design continuous with the API vs self-hosting decision.

Implication for buyers: ask the vendor embedding AI in your business "what is the license of the open-weight model you adopt" and "how will you satisfy the conditions of commercial use, scale, attribution, derivatives, and usage restrictions." A vendor who can't answer this immediately may be overlooking license risk.

FAQ

Q. Are open-weight LLMs free for commercial use?

It depends on the license. "Open-weight (weights published)" and "free for commercial use" are different things. Apache 2.0 (many Qwen3 models, etc.) is broadly free including commercial use, but the Llama Community License and Gemma Terms of Use permit commercial use while imposing conditions like a scale cap, attribution, and usage-restriction pass-through. Confirm each license's text before adopting.

Q. Can Llama be used commercially?

It can, but with conditions. The Llama Community License permits commercial use, while imposing conditions such as: if your product's monthly active users exceed a certain scale (700 million) you need a separate license from Meta, a "Built with Llama" attribution, derivative-model naming rules, and compliance with the acceptable-use policy. These are conditions many companies can meet, but note that it's not OSI-approved open source.

Q. If I want to avoid lock-in or constraints, which license should I choose?

The Apache 2.0 / MIT family is the first candidate. These are OSI-approved open source, where commercial use, modification, and redistribution are broadly permitted, with no user-scale cap. The obligation is about retaining license/copyright notices. Many Qwen3 (dense) models and some of Mistral's published models adopt Apache 2.0. It suits commercial projects that want to minimize future constraint risk.

Q. Does the license also reach a fine-tuned derivative model?

It does. The original model's license is inherited by derivatives, and depending on the license there are derivative-model naming rules (e.g. prefixing the name with the original model's name) or an obligation to pass on the usage-restriction policy. The Apache 2.0 family is relatively free in its treatment of derivatives too, but the community-license family needs its conditions checked.

Q. When should I check the license?

At the very first stage of choosing a model. Treat a license not as a confirmation item bolted on later but as a design decision (license-as-architecture). Discovering a license issue after production launch causes a large rework of swapping to another model. Since scale conditions like an MAU cap become a problem when the business succeeds, it's important to evaluate it first.

Summary: a license is a design decision made first

To not lose out on open-weight LLM commercial use, here's what to grasp.

1. "Open-weight ≠ open-source ≠ free to use" — published weights and commercial freedom are different things.
2. Evaluate on five axes — commercial permissibility, scale cap, attribution, derivative naming, and usage-restriction policy.
3. The Apache 2.0 / MIT family is the freest — the first candidate for commercial projects that want to avoid lock-in.
4. Llama, Gemma, etc. are commercial OK but with conditions — watch the MAU cap, attribution, and usage-restriction pass-through.
5. A license is a design decision made first — make it swappable with a provider abstraction and localize the risk.

"Which open model may I use commercially?" / "I'm unsure whether I can meet the license terms" — that judgment governs your business's expansion potential and lock-in risk. From model selection through license evaluation to a swappable implementation, I take it on at production-operations quality (the final judgment on specific license compliance is coordinated with legal counsel as needed).