The Open-Weight AI License Trap: What Startups Building on Llama, Mistral, and Gemma Actually Agree To

Why "Open Source" AI Models Aren't Really Open Source

When your engineering team pulls down Llama 3 from Hugging Face, spins up a Mistral model for fine-tuning, or drops Gemma into a RAG pipeline, the last thing anyone thinks about is the license file. These models are labeled "open source" everywhere you look — on model hubs, in blog posts, even in Meta's own marketing. But the Open Source Initiative (OSI) has been crystal clear: Meta's Llama license "is still not Open Source", and the same is true for several other popular "open" AI models. The gap between what the community calls "open" and what the licenses actually permit is where startups get into trouble.

The problem isn't theoretical. Open-weight AI model licenses — the Llama Community License, Mistral's Apache 2.0 wrapper, and Google's Gemma Terms of Use — look like standard open-source licenses from a distance. But up close, they contain materially different obligations: acceptable use policies that restrict entire product categories, attribution and branding requirements that dictate what you can name your model, downstream pass-through duties that bind your customers, and liability provisions that leave you holding the bag for model outputs. If you're building a commercial product on any of these models, you need to understand what you've actually agreed to — because the traditional OSS compliance playbook doesn't cover any of it.

Meta's Llama Community License: The Most Restrictive "Open" Model

Meta's Llama 3 Community License Agreement is the most widely discussed — and most legally complex — of the three. The full license text is available on Meta's GitHub repository, and it contains several provisions that no standard open-source license would include.

The Acceptable Use Policy Trap

The Llama license incorporates an Acceptable Use Policy (AUP) by reference, meaning you agree to it automatically when you use the model. The AUP prohibits a broad range of uses — some obvious (violence, terrorism, exploitation of children) and others that map directly onto legitimate product categories. For example, the AUP prohibits "the unauthorized or unlicensed practice of any profession including, but not limited to, financial, legal, medical/health, or related professional practices." If your startup builds a tool that generates legal advice, financial recommendations, or health guidance using Llama — and you don't hold the relevant professional licenses — you may be in violation of the AUP, which means you're in violation of the license itself.

The AUP also prohibits using Llama to "engage in, promote, incite, or facilitate discrimination or other unlawful or harmful conduct in the provision of employment, employment benefits, credit, housing, other economic benefits, or other essential goods and services." If your product involves AI-driven hiring, credit scoring, or housing recommendations, the Llama AUP creates a compliance overlay that you need to navigate carefully — alongside the growing patchwork of AI-specific laws we've written about elsewhere.

The 700 Million User Threshold

Section 2 of the Llama license adds a commercial restriction: if your products or services have more than 700 million monthly active users, you must request a separate license from Meta, which Meta may grant or deny "in its sole discretion." For most early-stage startups, this threshold is irrelevant. But for startups building on Llama that could scale rapidly — or that are acquired by a larger company — this provision creates a conditional license that could be revoked or renegotiated at the worst possible time. It also means that if you're acquired by a company already over the threshold, your product's continued use of Llama depends on Meta's goodwill.

Attribution, Naming, and Branding Requirements

The Llama license requires you to prominently display "Built with Meta Llama 3" on any website, user interface, blog post, about page, or product documentation. If you create, train, fine-tune, or improve an AI model using Llama, you must include "Llama 3" at the beginning of the model name. These aren't suggestions — they're license conditions. Failure to comply means you're operating outside the license, which means you have no rights to use the model at all.

The No-Improvement Clause

Perhaps the most operationally significant restriction is Section 1(b)(v): "You will not use the Llama Materials or any output or results of the Llama Materials to improve any other large language model (excluding Meta Llama 3 or derivative works thereof)." This means you cannot use Llama's outputs to train or improve a competing model. If your startup's strategy involves distilling or using one model's outputs to train another, Llama's license flatly prohibits it.

OSI's Verdict: Not Open Source

The OSI's February 2025 analysis concluded that the Llama license fails the Open Source Definition on multiple grounds: it restricts freedom 0 (the freedom to use the software for any purpose), discriminates against certain users (the EU exclusion in newer versions), and restricts fields of endeavor (the AUP and the 700M MAU threshold). The OSI specifically called out Meta for "falsely promoting Llama as 'Open Source'" and urged the community to push back against what it calls "open washing."

For startups, the practical implication is straightforward: when investors, customers, or acquirers ask whether your product is built on "open source" AI, the honest answer is "no — it's built on a proprietary model released under a community license with significant restrictions." That distinction matters in due diligence, and we've seen it come up in SaaS terms of service and licensing discussions.

Mistral: Apache 2.0 With Strings Attached

Mistral AI takes a different approach. According to Mistral's own licensing FAQ, most of their open-weight models are released under the Apache 2.0 license — a genuine, OSI-approved open-source license that permits commercial use, modification, and redistribution without field-of-use restrictions. For most startups, this is the closest thing to true open source among the major model providers.

But there's a catch. Certain Mistral models are governed by a modified MIT license that adds a revenue threshold: companies with monthly revenue exceeding $20 million USD must either obtain a commercial license from Mistral or use the models via Mistral Studio (their hosted platform). This creates a scaling cliff — your startup can use these models freely until you hit $20M in monthly revenue, at which point you need to negotiate a separate commercial agreement.

The Apache 2.0 license itself is well understood and legally tested. It includes a patent grant, a contributions clause, and standard warranty disclaimers. If your startup is building on a Mistral model that's genuinely Apache 2.0, the compliance burden is much lighter than with Llama. But you still need to verify which specific model you're using and check the model card for the exact license terms, because Mistral uses different licenses for different models in their lineup.

Google Gemma: Custom Terms With Remote Kill Switch

Google's Gemma presents yet another pattern. The Gemma model code on GitHub is wrapped in an Apache 2.0 LICENSE file, but the actual model weights and usage rights are governed by a separate Gemma Terms of Use — a custom agreement that is decidedly not Apache 2.0.

The Gemma Terms of Use include several provisions that create exposure for startups:

• Prohibited Use Policy: Like Llama, Gemma incorporates a Prohibited Use Policy by reference, which restricts categories of use that include generating content that facilitates illegal activity, creating deepfakes, and other categories defined in Google's policy.
• Downstream pass-through: If you distribute Gemma or model derivatives, you must include the use restrictions as an enforceable provision in any agreement governing downstream use. This means your customers' terms of service must carry forward Google's restrictions — creating a chain of compliance obligations that extends through your entire distribution stack.
• Remote restriction: Section 3.2 states that "Google reserves the right to restrict (remotely or otherwise) usage of any of the Gemma Services that Google reasonably believes are in violation of this Agreement." This is a remote kill switch — Google can disable your access to the model if it believes you're in violation. For a startup running critical infrastructure on Gemma, this is a business continuity risk that doesn't exist with truly open-source software.
• Model Derivatives definition: Gemma's definition of "Model Derivatives" is broad — it includes distillation methods, transfer of weight patterns, and any model created to "perform similarly to Gemma." This means the license's restrictions follow your derivative works, not just the original model.

Google does state that it claims no rights in outputs you generate using Gemma, which is helpful for startups concerned about output ownership. But the overall framework is a proprietary license dressed in open-source clothing.

EU AI Act GPAI Obligations: The Regulatory Overlay

On top of the license terms themselves, startups building on open-weight models need to understand how the EU AI Act's general-purpose AI (GPAI) obligations interact with model licenses. According to the European Commission's fact page on GPAI obligations, all providers of GPAI models must draw up technical documentation, implement a copyright policy, and publish a summary of the model's training content. Providers of GPAI models with systemic risk face additional obligations including risk assessment, incident reporting, and cybersecurity protections. These obligations entered into application on August 2, 2025.

For US startups, the critical question is whether you qualify as a "provider" of a GPAI model. If you're fine-tuning Llama or Gemma and distributing the resulting model, you may be stepping into the GPAI provider role under the EU AI Act — which means you inherit documentation, copyright policy, and transparency obligations that the original model's license never mentioned. The license gives you the right to create derivative works; the regulation tells you what you must do when you exercise that right. We cover this intersection in more detail in our EU AI Act compliance guide for startups.

Comparing the Three License Models

Here's how the three license frameworks stack up against the key compliance questions startups should be asking:

• Acceptable use restrictions: Llama and Gemma both impose AUPs that restrict product categories. Mistral's Apache 2.0 models do not — but their modified-MIT models may carry additional terms.
• Attribution and branding: Llama requires prominent "Built with Meta Llama 3" display and naming conventions. Gemma requires a Notice text file and downstream pass-through. Apache 2.0 requires standard NOTICE file attribution but no branding.
• Commercial thresholds: Llama has a 700M MAU threshold. Certain Mistral models have a $20M monthly revenue threshold. Gemma has no revenue threshold but retains a remote restriction right.
• Downstream obligations: All three require some form of license pass-through to downstream users, but Gemma's is the most explicit about requiring enforceable restrictions in downstream agreements.
• Output ownership: Llama and Gemma both disclaim rights in outputs but disclaim all warranties. Apache 2.0 (Mistral) follows standard OSS warranty disclaimers.
• Regulatory overlay: The EU AI Act's GPAI obligations apply regardless of which license you choose, but they interact differently depending on whether you're modifying and redistributing the model (provider obligations) or merely deploying it (deployer obligations).

Actionable Next Steps

Before you build your next product on an open-weight AI model, take these concrete steps:

1. Audit your model stack. Identify every open-weight model in your pipeline — including models used in RAG systems, fine-tuning workflows, and agentic architectures. For each, pull the actual license text (not the Hugging Face tag) and identify which model version you're using.
2. Map AUP restrictions to your use case. Cross-reference your product's intended use against the model's acceptable use policy. If you're building tools for regulated industries — legal, financial, medical, hiring — the Llama AUP may prohibit your use case entirely, and you need to know that before you build, not after you launch.
3. Build a license compliance checklist. For each model, document: attribution requirements, naming conventions, downstream pass-through obligations, revenue or user thresholds, and output ownership terms. This checklist should live alongside your SBOM or AI Bill of Materials.
4. Review your customer-facing terms. If you're using Gemma, your customer agreements must carry forward Google's use restrictions as enforceable provisions. If you're using Llama, your terms should reflect the AUP. This is not optional — it's a license condition.
5. Assess EU AI Act exposure. Determine whether your use of these models makes you a GPAI provider under the EU AI Act. If you're modifying and redistributing models, you likely have provider obligations that include documentation, copyright policy, and training content transparency.
6. Plan for the kill switch. For Gemma (remote restriction right) and Llama (termination on breach), build business continuity plans that account for the possibility that the model provider cuts off your access. This is especially important if the model is embedded in critical infrastructure.
7. Get a license review before you scale. The cost of a legal review of your model licensing stack is trivial compared to the cost of discovering a license violation during due diligence — or worse, after a product launch that the model provider decides violates its AUP.

Open-weight AI models are powerful building blocks, but they are not open source. The licenses that govern them create real, enforceable obligations that traditional OSS compliance frameworks don't address. Treat them like the proprietary licenses they are, and build your compliance posture accordingly.