How did the Llama 3.1 licence change the rules on training other models with Llama outputs?

## The clause that used to block distillation The Llama 2 Community License contained a restriction in its use-limitations section to the effect that the licensee will not use the Llama Materials or any output or results of the Llama Materials to improve any other large language model, excluding Llama 2 or derivative works thereof. The Llama 3 agreement repeated the same structure for Llama 3. Read literally, that swept in a very common workflow: prompt the big model, collect its completions, and use them as supervised fine-tuning data for a smaller or different-architecture student model. If the student was not itself a Llama derivative, the workflow was outside the licence. It also cast doubt on softer variants — using Llama to generate evaluation sets, to synthesise instruction data, or to label training examples for a non-Llama model — because "improve any other large language model" is broad language. This mattered because output-based distillation is one of the cheapest ways to move capability from a large model into a small deployable one, and because a good deal of the open-model ecosystem was quietly doing it. ## What Llama 3.1 changed The Llama 3.1 Community License, issued with the July 2024 release, removed the prohibition and replaced it with an express grant: outputs may be used to improve other models, with synthetic-data generation and distillation called out explicitly. Meta paired the permission with the same naming discipline it uses elsewhere in the agreement — if you distribute a model created or improved with Llama outputs, its name must begin with "Llama", and the "Built with Llama" attribution applies to products using it. So the licence moved from *prohibition* to *conditional permission with an attribution tax*. Later releases in the 3.x line and beyond have kept the permissive posture, but the operative rule remains: the agreement governing the data is the agreement for the version that produced it. ## Why version pinning matters here more than anywhere else Most licence obligations attach to the artefact you ship. This one attaches to *data you generated in the past*. Three consequences follow. **Provenance must be recorded per generation run.** For every synthetic dataset, record which Llama version produced it, when, and under which agreement text. A corpus generated from a Llama 3 endpoint in early 2024 is governed by the Llama 3 agreement's restriction, and re-reading the 3.1 terms does not retroactively liberate it. Teams that mixed generations into one training set without provenance metadata cannot cleanly answer the question a due-diligence process will ask. **Mixed corpora inherit the strictest constituent.** If a dataset blends outputs from several sources, the training run that consumes it is only as clean as its most restricted component. Practically that means segregating generations by source model in storage, so you can rebuild a compliant subset rather than discarding the whole corpus. **The naming condition propagates into products.** A student model trained on permitted Llama outputs, if distributed, must carry the Llama-prefixed name. That is a product-branding decision, not just a repository label, and it is a reason some organisations choose not to distill from Llama at all: they do not want their flagship small model to be named after somebody else's family. ## The evaluation-and-labelling grey zone Under the older restriction, teams argued about whether using Llama to *score* or *label* data for a non-Llama model counted as "improving" it. The conservative reading said yes, and many organisations simply avoided the pattern. Under 3.1-and-later terms the argument is moot for those versions, since output use for improving other models is permitted outright. If your organisation still holds datasets built under the older terms, that grey zone is a live question for those datasets alone. ## What this tells you about the licence family generally The outputs clause is the clearest evidence for a rule you should carry into any Llama discussion: **the Llama Community License is not one document.** Each release ships its own agreement, and the differences between them have been material — the outputs restriction removed at 3.1, the attribution string changed at the same release, a regional carve-out for multimodal models introduced at 3.2. "We reviewed the Llama licence" is therefore an incomplete statement; the useful statement names the version and the date of the text reviewed. ## How to answer this in an interview State the change crisply — prohibition under Llama 2 and 3, express permission plus the naming condition from 3.1 — then show the operational instinct: per-version provenance on synthetic data, segregation of generations in storage, and awareness that the naming obligation follows a distilled model into your product branding. That combination is what separates a compliance recital from someone who has actually run a distillation pipeline in a company with a legal team.