Are all Qwen model weights Apache-2.0, and which releases are not?

## Why this question is asked at senior level "Open-weight" is not a licence. It says you can download the parameters; it says nothing about what you may do with them. Getting this wrong is not a quality bug you can iterate on — it is a legal exposure that surfaces at the worst moment, usually during a customer security review or an acquisition diligence process, long after the model is embedded in a product. Senior engineers are expected to have checked, and to know that the answer varies inside a single vendor's family. ## What Apache-2.0 actually grants Apache License 2.0 is a permissive open-source licence. It grants commercial use, modification, redistribution and sublicensing of derivative works, with obligations that are mild: retain the licence and copyright notice, state significant changes, and pass along the `NOTICE` file if there is one. It also includes an explicit patent grant with a defensive termination clause. Crucially for model weights, it imposes **no** field-of-use restriction, no user-count threshold, no obligation to open your fine-tunes, and no requirement to name the upstream model in your product. When a Qwen checkpoint is Apache-2.0 — as the Qwen3 open-weight releases broadly are, including the specialist Coder, VL and Embedding lines — you can fine-tune it, quantise it, serve it commercially, and ship the derivative under your own terms, subject only to those notice obligations. This is why Qwen is a common answer when the requirement is "self-hosted, multilingual, and legally uncomplicated". ## The bespoke Qwen licence Some Qwen2.5-generation checkpoints, most visibly the 72B tier, carry a Qwen-specific licence agreement instead. It is a *source-available* commercial licence: broadly permissive in practice, but with added conditions Apache-2.0 does not have. The one that matters most in review is a **scale threshold** — above a stated number of monthly active users for the product incorporating the model, you must request a separate licence from Alibaba rather than relying on the default grant. There are also acceptable-use terms and attribution obligations of the kind that permissive OSS licences do not impose. For a startup this threshold is usually irrelevant; for a consumer product at scale it is a real gate that needs to be raised before launch, not after. Note also that a licence like this makes the checkpoint **not** OSI-approved open source, which matters if your organisation has a policy that only admits OSI-approved licences into the product. ## Research-only releases At least one Qwen2.5 tier shipped under a research licence that permits evaluation and academic work but prohibits commercial deployment. This is the most dangerous category precisely because the checkpoint downloads exactly like its siblings and performs well in a prototype. A team that benchmarks a family and picks the winner on quality alone can build a product on weights it is not allowed to ship. ## Closed tiers with no weights The Max tier of the family is API-only. There is no weight download, so licensing is replaced by the hosted service's terms of use and data-handling commitments. If your reason for choosing Qwen was self-hosting — data residency, air-gapped deployment, no third-party processor — then the Max tier does not satisfy the requirement at all, regardless of how well it benchmarks. This is a frequent source of confusion because Max appears alongside the open models in the vendor's catalogue and in comparison tables. ## The distribution-channel wrinkle The licence lives with the weights, not with the download path. A quantised community rebuild — GGUF, AWQ, GPTQ — inherits the upstream licence and may add the repackager's own terms on top. A checkpoint offered through a cloud marketplace comes with that marketplace's agreement layered over the model licence. When you are documenting compliance, record where you obtained the artefact as well as which licence it carried. ## Fine-tunes and derivatives Your fine-tune is a derivative of the base weights, so the base licence follows it. Under Apache-2.0 that is unproblematic: keep the notices and ship. Under a bespoke licence with a use threshold or acceptable-use terms, those conditions propagate to your adapter and to anything you distribute containing it. Teams sometimes assume that LoRA adapters — being small and separately distributed — escape the base licence. Treat that assumption as unsafe: the adapter is useless without the base model, and the terms are written to reach the combination. ## The practical procedure 1. For each checkpoint you intend to serve, open **that repository's** `LICENSE` file. Not the family's blog post, not a table on a hub page, not a summary in a comparison article. 2. Record the licence, the exact model id and the retrieval date in whatever inventory your organisation keeps for third-party components. 3. Flag anything that is not a standard permissive licence for legal review *before* the model reaches production, and specifically look for user-count thresholds, field-of-use limits and attribution requirements. 4. Re-check on every version bump. A new generation of the same size is a new artefact and may carry different terms. 5. If self-hosting is the actual requirement, verify that weights exist at all before designing around the model. The general direction across the family has been toward more permissive licensing over time, with the newer generation standardising on Apache-2.0. But "the trend is permissive" is not a compliance answer, and no interviewer will accept it as one.