What open-source license lets you deploy Llama models commercially without paying Meta in 2027?

A deployment scenario that exposes the licensing trap

Imagine a mid-market SaaS company that ships an AI assistant inside its ticketing product. The engineering team prototypes on Llama 3.1 8B because it runs cheaply on a single A10G, then swaps to Llama 3.3 70B for the production tier. Legal asks one question before launch: can we ship this to paying customers without a royalty check to Meta?

The answer depends on three facts that rarely live in the same document. First, which Llama model family and version is actually deployed — Llama 2, Llama 3, Llama 3.1, Llama 3.2, Llama 3.3, and Llama 4 all carry their own license text with different thresholds and naming rules. Second, whether the company's own product exceeded the monthly active user threshold on the date Meta released that specific model. Third, whether the deployment is "commercially" permitted use or one of the carve-outs, such as training another large language model on Llama outputs.

That third point trips up more teams than the first two. A company can legally run Llama in production for customers and still violate the license by using Llama-generated outputs to train a competing foundation model. The license permits commercial deployment; it does not permit using Llama as a free data engine to build a rival.

The scenario also exposes a naming trap. "Open source" is a term of art with a formal definition maintained by the Open Source Initiative. The Llama Community License is not OSI-approved. It is a source-available, community license with usage restrictions, which is why some practitioners call it "open weights" rather than "open source." If your procurement or security review requires an OSI-approved license, Llama will fail that check even though it is free to deploy commercially.

So the honest framing for the scenario above is: yes, you can deploy Llama commercially without paying Meta, but you are accepting a bespoke license with a user threshold, an acceptable use policy, and a naming attribution requirement — not an OSI-approved open-source license. Teams that understand that distinction early avoid a painful re-architecture later.

How the Llama Community License mechanism actually works

The license operates as a conditional grant. Meta grants you a worldwide, non-exclusive, royalty-free license to use, reproduce, distribute, and modify the model and its derivatives, subject to conditions. If you comply, you owe nothing. If you breach a condition, the grant terminates automatically.

The most consequential condition is the monthly active user threshold. For the Llama 3 family, the threshold is 700 million monthly active users. If, on the date the model was released by Meta, your product or service had fewer than 700 million MAU, you may use the model commercially under the community license. If you had 700 million or more, you must request a license from Meta, and Meta has discretion over whether to grant it and on what terms.

The second condition is the attribution and naming requirement. You must display "Built with Meta Llama 3" or the appropriate version string prominently in your product documentation, about page, or user interface, and you must retain the license text and the "Notice" file in any distribution. This is a real obligation, not a formality — auditors and partners do check.

The third condition is the acceptable use policy, which is incorporated by reference. It prohibits uses including, but not limited to, violating law, harming minors, generating disinformation, and certain surveillance applications. This policy can be updated by Meta, which means your compliance surface can shift after you ship.

The fourth condition governs derivatives and distillation. You may create derivative works, including fine-tunes and merged models. You may distribute them under the same license. What you may not do is use Llama outputs to improve any non-Llama large language model. That clause is what prevents Llama from being used as a free teacher for a competitor's base model.

The diagram above compresses the decision path. In practice, the two branches that most often change a company's plan are the MAU threshold and the distillation clause. Everything else is documentation hygiene.

One more mechanical detail matters: the license is per-model, not per-company. If you deploy Llama 3.1 8B and Llama 3.3 70B, you are operating under two grants with two release dates and potentially two threshold calculations. A product that was small when 3.1 shipped but enormous when 3.3 shipped could theoretically be compliant on one model and non-compliant on the other. Most legal teams handle this by snapshotting MAU at each model's release date and documenting the number.

Finally, note that the license does not grant patent rights beyond what is expressly stated, and it includes a termination clause for patent litigation. If you sue Meta or its affiliates alleging that the model infringes your patents, your license terminates. That is a standard defensive termination provision, but it is worth flagging to your IP counsel before you build a product roadmap on top of Llama.

Real numbers, thresholds, and benchmarks that drive the decision

The headline number is 700 million monthly active users. That is the threshold in the Llama 3 family license. For scale, very few software products ever reach it. Meta's own family of apps does. Google Search, YouTube, WhatsApp, Instagram, and Facebook do. A B2B SaaS product with 50,000 seats does not. A consumer app with 20 million MAU does not. For the overwhelming majority of companies reading this page, the threshold is not the binding constraint.

The binding constraint is usually the distillation clause or the OSI-approval requirement in procurement. Consider the numbers that actually show up in deployment planning:

• Model sizes and hardware. Llama 3.2 ships in 1B and 3B text variants plus 11B and 90B vision variants. Llama 3.1 ships in 8B, 70B, and 405B. Llama 3.3 ships as a 70B model. Llama 4 ships as Scout and Maverick mixture-of-experts variants. Each size implies a different serving cost, and serving cost is what determines whether commercial deployment is economically viable without a license fee.
• Serving cost ranges. A quantized 8B model can run on a single 24GB GPU. A 70B model at FP8 typically needs two 80GB GPUs or four 48GB GPUs. A 405B model needs a multi-node cluster. On rented cloud GPUs, the hourly cost spread between an 8B and a 405B deployment can be one to two orders of magnitude. That spread, not the license fee, is the real commercial variable.
• Fine-tuning cost. LoRA fine-tuning of an 8B model on a few thousand examples can complete in under an hour on a single A100. Full fine-tuning of a 70B model requires substantially more compute and is usually done with parameter-efficient methods. These costs are yours regardless of license.
• Latency budgets. Interactive products typically target sub-second time-to-first-token. That constrains model size more than license terms ever will. A 70B model served at low batch sizes may not hit that target without aggressive quantization or speculative decoding.
• Token economics. If you pay per token to a hosted inference provider, your gross margin is set by their price. If you self-host, your margin is set by GPU utilization. The license is royalty-free either way, so the decision is purely operational.

The benchmark that matters most for a licensing decision is not MMLU or HumanEval. It is the MAU figure your finance team reports to the board. Pull that number, pull the release date of each Llama model you intend to deploy, and compare. Document the comparison. That single artifact resolves most internal debates about whether you need a bespoke Meta license.

A second benchmark worth tracking is your own product's growth rate. If you are at 400 million MAU and growing 15% quarter over quarter, you will cross 700 million within a few quarters. At that point you need to either negotiate with Meta in advance or plan a migration to a model with a permissive OSI-approved license. Planning that migration takes months, so the trigger to start is well before the threshold, not at it.

Trade-offs and alternatives to the Llama Community License

The central trade-off is straightforward. Llama gives you strong model quality, broad ecosystem support, and zero royalty for commercial deployment, in exchange for a bespoke license with a user threshold, an acceptable use policy, and a distillation restriction. If those terms are acceptable, Llama is an excellent choice. If they are not, you have alternatives, and each carries its own trade-off.

Apache 2.0 models. Apache 2.0 is an OSI-approved permissive license. It has no user threshold, no acceptable use policy, and no distillation restriction. Models released under Apache 2.0 include Mistral's 7B and Mixtral 8x7B, Microsoft's Phi family, and several Qwen releases. The trade-off is model quality and ecosystem maturity relative to the largest Llama variants. For many tasks, an Apache 2.0 model is more than sufficient, and the legal simplicity is worth the quality delta.

MIT and BSD-licensed models. These are even more permissive in form, though fewer large models ship under them. The practical difference from Apache 2.0 is mainly the patent grant, which Apache 2.0 includes explicitly. If patent risk is a concern, Apache 2.0 is usually the better choice among permissive licenses.

Gemma Terms of Use. Google's Gemma models ship under a custom license that is also not OSI-approved and includes a use policy. It is a close analogue to the Llama Community License in structure, which means it carries similar procurement friction.

Fully proprietary hosted APIs. You can avoid the license question entirely by calling a hosted API. The trade-off is per-token cost, data residency constraints, and vendor lock-in. For low-volume products, this is often the cheapest path.

Training your own model. If none of the above works, you can train from scratch or from a permissively licensed base. The trade-off is cost and time, which for a competitive general-purpose model is measured in millions of dollars and months of engineering.

The decision framework that works in practice is: start with your procurement constraints. If OSI approval is mandatory, Llama is off the table and you should evaluate Apache 2.0 models first. If OSI approval is not mandatory and you need the strongest open-weights quality, Llama is usually the right call. If you are near the MAU threshold or growing fast, model the migration cost now rather than later.

There is also a hybrid pattern worth considering. Some teams deploy a small Apache 2.0 model for high-volume, low-complexity tasks and reserve a larger Llama model for complex tasks where quality matters most. This reduces exposure to any single license and often improves unit economics, because the cheap model handles the majority of traffic.

Common pitfalls and how to avoid them

Pitfall one: assuming "open source" means OSI-approved. The Llama Community License is not OSI-approved. If your security questionnaire, procurement policy, or customer contract requires OSI-approved open-source components, Llama will fail that check. Avoid this by reading the actual license text and classifying it correctly in your software bill of materials as source-available, not open source.

Pitfall two: ignoring the distillation clause. Teams routinely fine-tune Llama and then use the fine-tuned model's outputs to train a different base model. That is a license breach. Avoid it by documenting, in writing, that no Llama outputs flow into training any non-Llama model, and by enforcing that rule in your data pipeline with automated checks.

Pitfall three: missing the attribution requirement. The license requires a "Built with Meta Llama" notice and retention of the license and Notice files. This is easy to forget in a containerized deployment where the model weights are pulled at runtime. Avoid it by adding the attribution to your product's about page and by including the license files in your distribution artifacts.

Pitfall four: not snapshotting MAU at the release date. The threshold is evaluated as of the model's release date, not today. If you do not record that number when a new Llama version ships, you cannot later prove compliance. Avoid it by maintaining a simple table of model versions, release dates, and your MAU on each date.

Pitfall five: assuming the acceptable use policy is static. Meta can update the policy. A use case that is permitted today could become restricted. Avoid it by subscribing to Meta's Llama communications and by reviewing the policy at each model upgrade.

Pitfall six: treating the license as company-wide rather than model-specific. Each model version has its own grant. Avoid it by tracking licenses at the model-version level in your SBOM, not at the vendor level.

Pitfall seven: overlooking the patent termination clause. If you assert patents against Meta, your license terminates. Avoid it by routing any IP dispute involving Meta through counsel before filing.

Pitfall eight: forgetting that derivatives inherit the license. If you fine-tune Llama and distribute the fine-tune, the derivative must carry the same license. Avoid it by including the license text with every distributed artifact, including internal ones that might later be shared externally.

The meta-pitfall is treating licensing as a one-time legal review. It is an ongoing operational process. Assign an owner, review at every model upgrade, and keep the evidence trail current.

Related questions

Is the Llama Community License OSI-approved open source?

No. It is a source-available community license with usage restrictions, including a monthly active user threshold and an acceptable use policy. The Open Source Initiative does not list it as approved. Treat it as open weights, not open source, in procurement and SBOM records.

Can I fine-tune Llama and sell the fine-tuned model?

Yes, you can fine-tune Llama and deploy the derivative commercially, provided you stay under the MAU threshold, comply with the acceptable use policy, and distribute the derivative under the same license. You may not use Llama outputs to train a non-Llama model.

What happens if my product crosses 700 million MAU?

You must request a license from Meta. The community license no longer covers your use. Meta has discretion over whether to grant a license and on what terms. Plan the negotiation and a potential migration well before you reach the threshold.

Which Llama versions use the 700 million MAU threshold?

The Llama 3 family license uses 700 million monthly active users. Llama 2 used a different threshold of 700 million as well, and Llama 4 carries its own license text. Always read the specific license shipped with the model version you deploy.

Can I use Llama in a product that competes with Meta?

The license does not prohibit competing with Meta in general. It prohibits using Llama outputs to improve non-Llama large language models and prohibits uses barred by the acceptable use policy. A competing product that simply uses Llama for inference is generally permitted.

FAQ

Does deploying Llama commercially require paying Meta anything?

No, provided you comply with the Community License. The grant is royalty-free for commercial use when your product had fewer than 700 million monthly active users on the model's release date. There is no per-token fee, no revenue share, and no seat-based charge. The cost you incur is infrastructure, not licensing.

Is the Llama Community License the same as open source?

No. Open source has a formal definition maintained by the Open Source Initiative, and the Llama Community License does not meet it because it imposes usage restrictions. It is more accurately described as a source-available or open-weights license. This distinction matters for procurement, security review, and customer contracts that require OSI-approved components.

Can I redistribute Llama models to my customers?

Yes, you can distribute the model and derivatives under the Community License, but you must include the license text and the Notice file, and you must display the "Built with Meta Llama" attribution. Your customers then operate under the same license terms, including the MAU threshold and acceptable use policy.

What is the distillation restriction in plain terms?

You may not use Llama or its outputs to train or improve any large language model that is not itself a Llama model. Fine-tuning Llama is allowed. Using Llama to generate synthetic data for a competitor's base model is not. This clause is what prevents Llama from being used as a free teacher for rival foundation models.

Do I need a separate license for each Llama version I deploy?

Each model version ships with its own license grant and its own release date for the MAU calculation. In practice you should track compliance per model version. If you deploy Llama 3.1 and Llama 3.3, you are operating under two grants and should document MAU at both release dates.

What is the safest alternative if I need an OSI-approved license?

Apache 2.0 models are the most common OSI-approved alternative. Mistral's 7B and Mixtral 8x7B, Microsoft's Phi family, and several Qwen releases ship under Apache 2.0. They carry no MAU threshold, no acceptable use policy, and no distillation restriction, at the cost of some model quality relative to the largest Llama variants.

Sources

• Meta Llama license and acceptable use policy
• Meta Llama models on Hugging Face
• Open Source Initiative definition of open source
• Open Source Initiative approved licenses list
• Apache License 2.0 text
• Mistral AI models and licenses
• Google Gemma terms of use
• Hugging Face model license documentation

Related on PULSE

• How to classify open-weights models in a software bill of materials
• Apache 2.0 vs community licenses for production LLM deployment
• Managing monthly active user thresholds across model versions
• Building a model-version licensing tracker for RevOps
• When to migrate from Llama to a permissively licensed model
• Acceptable use policies and their impact on product roadmaps