Open-Weight AI Licensing Risks: What Startups Building on Llama, Mistral, and Qwen Must Know

Open-weight AI models like Llama, Mistral, and Qwen use non-OSI-approved licenses with commercial caps, AUP flow-downs, and usage restrictions that can block enterprise deals. Here's what founders need to audit before shipping.

Abstract fresco: a deep navy geode opened on one side to reveal a teal crystal interior, small copper pins and a closed teal ring around it, with loose teal shards drifting free.
Loading AudioNative Player...

If your startup is building a product on Llama, Mistral, or Qwen, you're in good company. These open-weight models have become the backbone of AI-native product development, offering frontier-level performance without the per-token costs of proprietary APIs. But the licenses governing these models are not open-source licenses in any traditional sense — and the distinction matters more than most founders realize when enterprise procurement starts asking questions.

We've written about the broader open-weight license trap before. This article goes deeper into the specific licensing terms of the three most popular open-weight families — Meta's Llama, Mistral AI's models, and Alibaba's Qwen — and explains why these terms can block enterprise deals, create IP contamination risk, and force mid-stream architecture changes if you don't audit them before shipping.

"Open-Weight" Is Not "Open Source" — and OSI Says So

The Open Source Initiative (OSI) spent two years developing the Open Source AI Definition (OSAID) v1.0, released in October 2024 at the All Things Open conference. The definition establishes that for an AI system to be considered "open source," it must satisfy the four foundational freedoms — use, study, modify, and share — across all components, including model weights, training code, and training data.

When OSI evaluated popular models against this definition, the results were sobering for the "open-source AI" marketing narrative: LLaMA2 (Meta), Phi-2 (Microsoft), Mixtral (Mistral), and Grok (X/Twitter) all fell short of meeting the requirements. Models like OLMo (AI2), Pythia (Eleuther AI), and T5 (Google) passed. BLOOM, Starcoder2, and Falcon would pass if they changed their licenses.

The core problem? These "open" licenses impose usage restrictions — acceptable use policies, commercial thresholds, and behavioral-use flow-down clauses — that violate criterion 6 of the Open Source Definition, which prohibits discrimination against any person, group, or field of endeavor. Traditional open-source licenses like MIT and Apache 2.0 don't restrict how you use the software. Open-weight AI licenses do. That's the fundamental gap.

Meta's Llama Community License: The 700M MAU Trigger

Meta's Llama 3.1 Community License Agreement (the current version applicable to Llama 3.x and 4 releases) grants a "non-exclusive, worldwide, non-transferable and royalty-free limited license" to use, reproduce, distribute, and modify the Llama Materials. But the agreement contains several provisions that create real risk for startups:

The 700 Million MAU Commercial Threshold

Section 2 of the Llama 3.1 Community License Agreement states that if your products or services have greater than 700 million monthly active users in the preceding calendar month, "you must request a license from Meta, which Meta may grant to you in its sole discretion." Until Meta grants that license, you have no rights under the agreement.

For most early-stage startups, 700 million MAU sounds like a problem for Meta, Google, and TikTok — not for a seed-stage company. But the provision creates two issues that surface earlier than you'd expect:

  • Enterprise deal diligence: Large enterprise buyers — particularly those with global user bases — may ask whether your use of Llama complies with the 700M MAU cap at their level, not just yours. If your product is embedded in a platform that collectively exceeds the threshold, the analysis gets complicated fast.
  • Acquisition risk: If your acquirer has more than 700 million MAU, the Llama license rights may not transfer. We've seen this come up in M&A diligence, and it's covered in our AI product due diligence checklist for acquirers.

Acceptable Use Policy Incorporation

Section 1.b.iv of the Llama license requires that your use "comply with applicable laws and regulations" and "adhere to the Acceptable Use Policy for the Llama Materials," which is incorporated by reference into the agreement. This means the AUP is not a separate guideline — it's a binding contractual term. The AUP prohibits using Llama for malware generation, deepfakes, election interference, and other enumerated categories.

More importantly, the AUP creates a flow-down obligation. If you distribute Llama or derivative works, your downstream users are also bound by the AUP. This means your customer contracts need to pass through these restrictions, or you risk being in breach of the upstream license.

Attribution and Naming Requirements

Section 1.b.i requires that anyone distributing Llama Materials or products containing them must "prominently display 'Built with Llama'" on their website, UI, or documentation. If you use Llama to train or fine-tune another AI model that you distribute, you must include "Llama" at the beginning of that model's name. These aren't optional branding suggestions — they're license conditions, and noncompliance is a breach that can terminate your rights under Section 6.

Patent Retaliation Clause

Section 5(c) contains a patent retaliation provision: if you file any litigation alleging that Llama Materials infringe your intellectual property, all licenses granted under the agreement terminate immediately. This is a common provision in open-source licenses (GPLv3 has a similar clause), but it's worth noting because it means you can't simultaneously use Llama and sue Meta for patent infringement related to the model.

Mistral's Tiered Licensing: Apache 2.0 vs. Revenue Caps

Mistral AI's licensing landscape is more fragmented than Llama's. According to Mistral's own documentation, most of their open models are released under Apache 2.0, which is a genuinely OSI-approved open-source license with no usage restrictions. Mistral 7B v0.1 and Mixtral 8x7B, for example, carry Apache 2.0.

However, certain Mistral models — particularly their frontier and large models — are governed by a modified MIT license with a significant commercial restriction: companies with monthly revenue exceeding $20 million USD must either obtain a commercial license from Mistral or use the models exclusively through Mistral Studio. This is a revenue-based threshold, not a user-count threshold, which means it can trigger much earlier in a company's lifecycle than Llama's 700M MAU cap.

The $20M revenue threshold is particularly dangerous because:

  • It applies to your company's revenue, not the revenue attributable to the specific product using the model.
  • It may apply to your affiliates' revenue if you're part of a larger corporate structure.
  • Enterprise customers conducting vendor diligence may refuse to sign with you if they discover you're using a Mistral model without a commercial license, even if your current revenue is below the threshold — because they're buying into a compliance risk that activates as you scale.

Additionally, OSI's evaluation found that Mixtral fell short of the Open Source AI Definition despite being Apache 2.0 licensed — because the training data and training code were not made available. This means that even when a Mistral model carries an OSI-approved license on the weights, the system as a whole may not meet the full open-source AI standard that some enterprise procurement frameworks reference.

Mistral also maintains a Usage Policy that applies to all users of Mistral models, including those distributed under Apache 2.0. While Apache 2.0 itself doesn't impose use-based restrictions, Mistral's terms of service and usage policy create a parallel set of behavioral obligations that can affect your commercial relationships.

Qwen's License Maze: Size-Dependent Terms and Export Controls

Alibaba's Qwen family presents the most complex licensing landscape of the three. The license varies by model size and release generation:

  • Smaller and older Qwen models (like the original Qwen repo) are released under Apache License 2.0, which is genuinely open-source with no usage restrictions.
  • Larger and newer models — like Qwen2.5-72B — use a custom "Qwen LICENSE AGREEMENT" that closely mirrors the Llama Community License structure.

The Qwen License Agreement includes its own commercial threshold: if you are commercially using the Materials and your product or service has more than 100 million monthly active users, you must request a license from Alibaba Cloud. That's a significantly lower threshold than Llama's 700 million — meaning it will trigger for far more companies.

The Qwen license also requires prominent display of "Built with Qwen" or "Improved using Qwen" in product documentation when you use Qwen to create, train, or fine-tune another AI model. Like the Llama license, it includes a patent retaliation clause that terminates all licenses if you sue Alibaba for IP infringement.

Export Control Complications

Section 5 of the Qwen License Agreement explicitly states that the Materials "may be subject to export controls or restrictions in China, the United States or other countries or regions" and that you must "comply with applicable laws and regulations." This is not a theoretical concern. Commerce's January 2025 AI Diffusion Rule would have imposed controls on advanced model weights before BIS rescinded it in May 2025, and BIS has since issued guidance warning industry about PRC-origin advanced computing technology. Building on a model developed by a Chinese company — even one distributed under a permissive license — can still create export control, government-procurement, and investor-diligence complications for U.S. startups in defense-adjacent or dual-use markets.

How These Licenses Block Enterprise Deals

Enterprise procurement teams are increasingly conducting model-level license diligence as part of vendor review. We've seen this become a standard checklist item in 2025–2026, particularly for Fortune 500 buyers and regulated industries. When they ask "what model are you using, and under what license?" — they're not just curious. They're evaluating whether your technology stack creates compliance risk for them.

The specific deal-blocking scenarios we've encountered include:

  • AUP flow-down failures: Your customer's security team asks whether your model's acceptable use policy flows through to their end users. If you haven't built AUP compliance into your customer contracts, the deal stalls.
  • Commercial threshold uncertainty: A large enterprise buyer with global user base asks whether the Llama 700M MAU cap or Qwen 100M MAU cap applies at their level when they deploy your product. If you can't provide a clear compliance analysis, they walk.
  • Attribution requirements: Some enterprise customers object to mandatory "Built with Llama" or "Built with Qwen" branding in their white-labeled product, creating a conflict between your license obligations and their branding requirements.
  • Export control red flags: Defense contractors and national security-adjacent buyers may refuse to approve any product built on Qwen due to the China-origin export control risk, regardless of the license terms.

AUP Flow-Downs and IP Contamination Risk

The concept of "AUP flow-down" deserves special attention because it's the most commonly overlooked risk. When you build on an open-weight model with an acceptable use policy, that AUP doesn't just apply to you — it applies to everyone who receives the model or a derivative through you. This creates a chain of contractual obligations that must be reflected in your downstream contracts.

The OpenRAIL licensing framework, which introduced behavioral-use restrictions to AI licensing, formalized this flow-down concept. OpenRAIL licenses require that any redistribution or derivative work carry forward the original use-based restrictions — a "copyleft for behavior" that spreads the licensor's values downstream. While Llama, Mistral, and Qwen don't all use formal OpenRAIL licenses, their AUP incorporation clauses achieve a similar effect.

For startups, this means your customer contracts, terms of service, and acceptable use policies need to be drafted to pass through the upstream model's restrictions. If your customer agreement doesn't prohibit the same uses that Llama's AUP prohibits, you're in breach of your upstream license — and Meta (or Mistral, or Alibaba) can terminate your rights.

IP contamination risk works in the other direction. If you fine-tune a Llama model on your proprietary data and then distribute the fine-tuned model, the Llama Community License terms — including the attribution requirements, AUP, and commercial threshold — attach to your derivative work. Your proprietary improvements are now encumbered by Meta's license terms, which can complicate IP ownership claims in fundraising and M&A contexts.

Actionable Next Steps

Before you ship a product built on an open-weight model, take these steps:

  1. Conduct a model-level license audit. Document exactly which model version you're using, the specific license that applies to that version, and all material restrictions (commercial thresholds, AUP, attribution, export controls). Don't assume that "Mistral is Apache 2.0" — verify which specific model and which specific license.
  2. Map AUP flow-down obligations into your customer contracts. Your terms of service and enterprise agreements should explicitly prohibit the same use categories listed in your upstream model's acceptable use policy. This isn't a copy-paste exercise — it requires tailoring to your product context.
  3. Build a license compliance matrix for enterprise sales. Create a one-page document that answers the questions procurement teams will ask: What model? What license? What commercial threshold? What AUP? What attribution requirements? What export control considerations? Having this ready shortens sales cycles.
  4. Evaluate whether your model choice will survive acquisition. If a potential acquirer has a large user base, the Llama 700M MAU cap or Qwen 100M MAU cap may terminate your license rights post-acquisition. Consider this in your architecture decisions, especially if you're building with an exit in mind.
  5. Consider dual-model architectures for sensitive use cases. For customers who won't accept Qwen (China-origin risk) or who object to Llama branding requirements, maintaining a fallback model (like a truly open-source model such as OLMo) can keep deals alive without forcing an architecture rewrite.
  6. Get a legal review before you ship — not after. The cost of a license compliance audit before launch is a fraction of the cost of retrofitting your contracts, architecture, and customer relationships after an enterprise deal falls through or a license breach is discovered.

Open-weight models are a powerful foundation for AI-native products. But "open-weight" is a technical description, not a legal one. The licenses that govern these models impose real restrictions that can shape your commercial trajectory — and the startups that audit these terms early are the ones that close enterprise deals without mid-stream surprises.

Building on Llama, Mistral, or Qwen? Get a model license compliance review before your next enterprise deal — or your next funding round.

Book a consultation