Llama 4 for Engineers: Maverick, Scout, and the Community Licence Clause That Actually Matters

Llama 4 gets filed under "open source" in more casual conversations than any other model in this series, and it isn't — not in the OSI sense. Meta ships Llama 4 under the Llama Community License, a genuinely permissive licence for the overwhelming majority of teams, but with one specific clause that has real teeth: if your company (or its affiliates) has more than 700 million monthly active users, you need a separate licence directly from Meta. That single number is the most consequential fact in this entire post for anyone at real scale.

1. What you're actually buying​

Llama 4 ships as (at minimum) two named models — Maverick and Scout — both built on a Mixture-of-Experts architecture, continuing Meta's shift away from purely dense Llama models toward sparse activation for efficiency at scale. As with every MoE model in this landscape, the practical implication is the same: a large total parameter count with a much smaller active-parameter count per token, giving you access to more capacity without paying full dense-model compute cost per request.

The detail that separates Llama 4 from a purely open-source model is the Llama Community License. It is genuinely permissive for the vast majority of use cases — free commercial use, fine-tuning, and redistribution of derivatives are allowed under its terms — which is why it's colloquially treated as "open source" in most technical conversations. But it is not OSI-approved, because of two structural restrictions: usage/output restrictions (some licences in this family prohibit using Llama outputs to train competing models) and, most consequentially, a scale threshold: organisations exceeding 700 million monthly active users (including their affiliates) must request and obtain a separate commercial licence from Meta before using Llama 4. That threshold has been a stable feature of Meta's Llama licensing approach across generations, not a new Llama 4-specific term — but it's easy to forget until you're building a platform that could plausibly cross it.

2. When to reach for Llama 4 (and which model)​

Reach for Llama 4 Scout when you need a smaller, more efficient MoE model suited to focused tasks and constrained infrastructure — check Meta's published context-length and active-parameter specifications for the exact release you're targeting, since Meta has historically differentiated Scout and Maverick primarily on context handling and total scale rather than task specialisation.

Reach for Llama 4 Maverick for the more capable end of the family when your infrastructure can support the larger total parameter footprint and you need the strongest reasoning and generation quality Meta offers in this generation.

Reach for Llama 4 broadly when your organisation is comfortably below the 700M MAU threshold and you want a well-documented, widely-supported open-weight model with a large existing ecosystem of fine-tunes, quantisations, and community tooling built around the Llama family specifically — that ecosystem maturity is a real practical advantage over less-established model families.

Do not assume Llama 4 is licence-equivalent to Qwen 3.5 or Gemma 4 if you're a large platform, a subsidiary of a large platform, or building infrastructure that a large platform might redistribute — check the MAU threshold and the output-use restrictions against your actual corporate structure, not just your own product's user count.

3. Traps and gotchas​

Trap 1 — Not checking the MAU threshold against your parent company, not just your product. The 700M threshold applies to "you and your affiliates" — a small subsidiary of a large tech company can trigger the threshold even if the subsidiary's own product has a tiny user base. This is the single most-overlooked clause in Llama licensing conversations.

Trap 2 — Assuming Maverick and Scout have identical licence terms. Verify the licence text for the specific model and release you're deploying — Meta has adjusted licence terms across Llama generations, and assuming a previous generation's terms carry over exactly is a preventable legal review mistake.

Trap 3 — Using Llama outputs to train a competing foundation model without checking the output-use clause. Some Llama Community License versions restrict using the model's outputs to train other LLMs. If your pipeline involves any form of distillation or synthetic-data generation for training another model, review this clause specifically — it's easy to violate unintentionally in a data pipeline that wasn't designed with licensing in mind.

Trap 4 — Treating MoE sparsity as a free pass on infrastructure planning. Same trap as every other MoE model in this series: active-parameter count tells you about compute cost per token, not about the memory footprint needed to hold the full model resident across your serving cluster.

Trap 5 — Assuming Llama 4's ecosystem maturity substitutes for your own evaluation. A large community of fine-tunes and quantised variants is a genuine practical advantage, but community popularity is not evidence of quality for your specific task — validate any third-party fine-tune or quantisation against your own eval set before deploying it, since quality varies widely across community-produced artifacts.

Trap 6 — Not tracking licence changes across model updates. Meta has adjusted specific licence clauses across Llama generations before. If you're maintaining a long-lived deployment, re-check the licence text whenever you upgrade to a newer Llama 4 checkpoint, rather than assuming the terms you reviewed at initial deployment still apply unchanged.

Trap 7 — Assuming redistribution terms cover your specific packaging. If you're shipping a fine-tuned Llama 4 derivative as part of a commercial product (rather than just using it internally), review the redistribution and derivative-naming clauses specifically — some Llama licence versions require derivative models to carry "Llama" in their name, which has real product-naming and marketing implications worth knowing before launch, not after.

4. Cost intuition​

The self-hosting cost logic mirrors Kimi K3 and Qwen 3.5: MoE sparsity reduces per-token compute relative to a dense model of similar total capacity, but you still provision for the full parameter set's memory footprint. Llama 4's specific cost advantage is ecosystem maturity — a wider range of pre-quantised checkpoints, optimised serving configurations, and community tooling reduces the engineering time needed to get an efficient deployment running, which is a real (if less quantifiable) cost saving relative to a newer, less-established model family.

5. How to evaluate Meta's claims​

• Read the actual licence text for the specific Llama 4 model and version you're deploying — don't rely on a general "Llama is basically open source" summary, since specific clauses (MAU threshold, output-use restrictions) have real legal weight.
• Cross-check any capability benchmark against independent, third-party reproductions where available — Llama's popularity means there's usually more independent verification available for this family than for less widely-adopted models, which is itself a reason to prefer well-established families when the choice is close.
• If your organisation is anywhere near the 700M MAU threshold, involve legal counsel before your engineering team commits to a Llama 4-based architecture — this is not a decision to make unilaterally at the engineering level.

6. Integration and team workflow notes​

Maintain a single, authoritative record of which Llama 4 licence version and clause set your legal team reviewed and approved, tied to the specific model checkpoint you deployed. When you upgrade checkpoints, treat the licence re-review as a required step in the upgrade process, not an optional one — this is the kind of governance detail that's cheap to maintain proactively and expensive to reconstruct after the fact during an audit or partnership due-diligence process.

If your organisation is a subsidiary, joint venture, or platform with complex corporate structure, get an explicit legal opinion on how the 700M MAU affiliate clause applies to your specific structure — this is genuinely ambiguous in some corporate structures and worth a real legal opinion rather than an internal engineering interpretation.

Take advantage of the ecosystem maturity by starting with well-vetted, popular community quantisations and fine-tunes rather than building your own from scratch, but re-validate any third-party artifact against your own eval set before production use — popularity is not the same as validated quality for your specific task.

7. A worked scenario​

Consider a mid-sized SaaS company building an AI-powered writing assistant feature, considering Llama 4 Scout for cost-efficient self-hosting. The company itself has well under 700M monthly active users, but it was recently acquired by a much larger technology holding company with several billion-user products elsewhere in the portfolio. Engineering, reasonably, assumes the MAU threshold doesn't apply because their specific product is well under it.

This is exactly the scenario the "affiliates" language in the Llama Community License is designed to catch — depending on the specific corporate and licensing structure, the parent company's user base could plausibly bring the whole group over the threshold, requiring a separate licence conversation with Meta before deployment. The fix isn't necessarily "don't use Llama" — it's "get a legal opinion before engineering commits infrastructure time," because the alternative (discovering the issue post-launch) is a far more expensive conversation.

Quick decision checklist​

Before committing to a Llama 4 deployment, confirm:

• Legal has reviewed the MAU threshold against your actual corporate structure, including parent companies and affiliates.
• The specific licence version for your target checkpoint has been reviewed and documented.
• Redistribution and derivative-naming clauses have been checked if you're shipping a fine-tuned model commercially.
• Any output-use restrictions have been checked against your data pipeline, especially if you do any distillation or synthetic-data generation.
• Community fine-tunes or quantisations are validated against your own eval set before production use.

8. Reading order​

1. Meta's official Llama 4 model card and the current Llama Community License text — read the licence directly, not a summary.
2. Meta AI's Llama 4 announcement blog post — for the Maverick/Scout positioning and architecture details.
3. The AI model landscape 2026 for how Llama 4 compares to Kimi K3, Qwen 3.5, and DeepSeek on architecture and licensing.
4. The Llama 4 engineering guide.

Verdict​

Llama 4 is a strong, well-supported open-weight choice for the vast majority of teams, with an ecosystem maturity advantage few competitors can match — but "vast majority" is not "all," and the 700M MAU threshold plus output-use restrictions are real legal facts, not open-source folklore. Check them against your actual corporate structure before treating Llama 4 as licence-equivalent to a true Apache 2.0 model.