We Read the Licences on 2026 Open-Weight Models

This open-weight model licence audit scores 30 models that were publicly described as “open,” “open-weight” or “open-source” in 2026 on the licence actually governing the weights — not on the press release or the launch tweet. We queried Hugging Face’s model API for every row, and wherever the tag said “other” or conflicted with a linked page, we opened the governing licence text itself and read it.

The result is a census, not a takedown. A slim majority — 17 of 30 (57%, n=30) — ship an unmodified or functionally equivalent Apache-2.0 or MIT-style licence with no commercial strings attached, and those genuinely permissive releases deserve to be visible as such. But 11 of 30 (37%, n=30) carry a bespoke licence with a real condition, usually a revenue or user threshold that triggers mandatory branding or a separate agreement, and 2 of 30 (7%, n=30) had no public repository under the vendor’s own Hugging Face organisation at all despite being publicly discussed as open.

The word “open” is doing different work in different releases, and the licence text is the only place to find out which. Below: the full methodology, the complete 30-row table with every repository linked, the patterns in where restrictions cluster, and the single clearest proof point — one vendor shipping two sibling models 18 minutes apart under two different licences.

Everything in this census rests on one primary source per row: Hugging Face’s own model API, huggingface.co/api/models/{org}/{name}, which returns the licence tag, the gating status and the file count for any public repository. Where that tag read “other,” or where it conflicted with a linked licence page, we fetched and read the actual LICENSE file or linked licence document rather than trusting the tag. The full collection rules, exclusions and known limits are stated below, precisely enough that anyone can re-run the same calls and check our numbers.

Each row was scored against a three-way verdict scale defined before any row was classified into it:

Every row is below — including the ones that undercut any tidy thesis. The genuinely permissive releases are as much a finding as the restricted ones. Rows whose status could not be fully verified are shown as unverified rather than resolved by inference; the footnotes under the table carry each caveat. Download status: Public = downloadable with no gate; Gated (auto) = Hugging Face access-request form, auto-approved; Gated (manual) = access requests reviewed by the vendor; Not published = no repo found under the vendor’s own Hugging Face org.

Notes on unverified and proxy cells. (a) Kimi K2.5’s Hugging Face createdAt of 2026-01-01T06:06:03Z is almost certainly a registration placeholder rather than the announcement date — too round to be organic; no independently confirmed announcement date was found in this research, so both HF timestamps are reported for transparency. (b) The GLM-5.3 repo path returns the same HTTP 401 as a deliberately fake control repo — consistent with no public repo existing, and consistent with the vendor’s announced plan to gate public API and weights behind a safety review targeted around August 28, 2026. (c) Qwen3.8-Max is neither confirmed nor disproven: every tested official-org path failed, and a Hugging Face search returned zero repos under the official Qwen organisation — only third-party fine-tunes and quantisations. An internal tracking claim of an August 8 weights release could not be verified; absence of evidence is not evidence of absence, and this check covered Hugging Face only. (d) One secondary outlet claims a separate acceptable-use policy layered on Inkling-Small’s Apache-2.0 grant; the official Hugging Face blog announcement we fetched does not mention any such policy, so the claim is reported here as unverified, not adopted. (e) No press-confirmed announcement date was found for this row in this research; the repo createdAt is a proxy. (f) Scored on the verified licence grant — the linked Google licence page displays unmodified Apache License 2.0 text, and the same page separately links a Prohibited Use Policy and an Intended Use Statement that are not merged into the grant. (g) The repo’s machine-readable metadata carries no licence tag at all, but the README links a real bespoke licence document, which we read; the press framing of this specific model as open was not independently confirmed, and rests on the vendor’s consistent open-weight framing across its model family.

The headline split: 17 of 30 rows (57%, n=30) score OSI-style permissive, 11 of 30 (37%, n=30) score restricted bespoke, and 2 of 30 (7%, n=30) score not actually available. One stricter cut is worth stating separately: excluding the two Gemma-family rows — whose Apache-2.0 grant coexists with a separately published vendor use policy — 15 of 30 (50%, n=30) are both an unmodified permissive licence and free of any separately published vendor use policy found in this research.

Two things in that chart deserve emphasis because they cut against any cynical reading. First, genuinely permissive releases are the majority, and some of them are enormous: Meituan’s LongCat-2.0 is a 1.6-trillion-parameter mixture-of-experts model under unmodified MIT, and Mistral Large 3, the Nemotron pair, Hy3, Sarvam-105B, the Inkling pair and Meta’s Apache-2.0 Muse Glimmer release all resolve to clean permissive texts. Second, “restricted” usually does not mean “hard to get”: 7 of the 11 restricted rows are freely downloadable with no approval step. The other 4 are gated — the two FLUX.2 tiers behind an auto-approved access request, the two Llama 4 rows behind vendor review. For the majority, the restriction is contractual — what you may do with the weights — not access-based.

The trend this census actually documents is divergence. In the same eight-month window, unrelated vendors on three continents shipped weights under everything from unmodified MIT to non-commercial-only grants — while all of them were described somewhere with the same single adjective. The label has stopped carrying information; the licence text now carries all of it.

Across the 11 restricted rows (of 30, n=30), the conditions cluster into a small set of recurring shapes: a revenue or monthly-active-user threshold that triggers mandatory UI branding; a revenue threshold that triggers a separate written or paid agreement; an unconditional branding mandate; a non-commercial-only grant; and, in two cases, a manual approval gate on the download itself. Strikingly, the same threshold figures recur across otherwise unrelated vendors.

The details matter because two licences with the same threshold can impose very different obligations. Kimi K2.5’s trigger — more than 100 million monthly active users, or more than 20 million US dollars in monthly revenue — obliges only a prominent “Kimi K2.5” display on the user interface. Kimi K3 keeps that branding trigger and adds a stronger one: once aggregate revenue exceeds 20 million US dollars over any consecutive 12 months, the licensee must enter a separate agreement with Moonshot AI before any commercial use. We walked through that document when it shipped in our earlier read of Kimi K3’s licence terms; this census re-fetched the same LICENSE file and found no conflict with that reading.

At the other end of the restricted bucket sits the mildest case: Upstage’s Solar-Open2-250B licence adopts the provisions of Apache 2.0 including commercial use, imposes no revenue or user threshold at all, and adds only a branding rule — commercial deployments must display “Built with Solar,” and the licence states that “The name of such Derivative AI Model must begin with ‘Solar’.” It is scored Restricted because Apache-2.0 itself imposes no branding obligation, but it is the lightest-touch bespoke text in the dataset.

If a single data point demonstrates why the label cannot be trusted, it is rows 27 and 28. On January 14, 2026, Black Forest Labs created two sibling repositories on Hugging Face: FLUX.2-klein-9B at 13:24:26 UTC and FLUX.2-klein-4B at 13:42:59 UTC — 18 minutes apart. The 4B model is Apache-2.0 and ungated. The 9B model carries the FLUX non-commercial licence and an access gate. Same vendor, same model family, same day; the “open-weight” label attaches to three sibling FLUX.2 models in this dataset, and only one of the three is actually unrestricted.

The FLUX non-commercial licence itself contains the dataset’s most commercially consequential nuance. The weights of FLUX.2-dev and klein-9B are made freely available for non-commercial, non-production use — but the licence explicitly separates the weights from what they produce:

In practice: images generated with the model can be used commercially, even though deploying the weights themselves in a commercial or production setting requires a separate agreement. Teams routinely get this distinction wrong in both directions — assuming outputs are contaminated when they are not, or assuming a downloadable model is deployable when it is not.

The dataset also contains one licence that moved the other way. Tencent’s Hy3 shipped as a preview in April 2026 under what press describes as a bespoke community licence that excluded the EU, UK and South Korea from its terms; the final July 2026 release switched to unmodified Apache-2.0 with no geographic exclusion. It is the only row in this dataset where a licence became more permissive between preview and final release — proof that these classifications are snapshots of moving targets, in both directions.

A reasonable engineer might assume the machine-readable licence tag on a repository settles the question. This census found three ways it does not.

An “other” tag always meant a real bespoke document. All 12 of the 30 rows tagged “other” (40%, n=30) resolved, on reading the actual file, to a genuinely bespoke licence rather than a mislabelled standard one. In this dataset the tag was a reliable signal to dig further in every case tested — never a false alarm, never the end of the inquiry.

A clean apache-2.0 tag can still carry a separate policy. Google’s Gemma 4 12B and DiffusionGemma both carry the apache-2.0 tag, and the linked Google licence page does display standard Apache License 2.0 text without modification to the core terms. But the same page separately links a Prohibited Use Policy and an Intended Use Statement — distinct documents, not merged into the grant. Per this census’s stated methodology, both rows are scored on the verified grant (Permissive) with the separate policy disclosed as a real constraint layered on top. A tag-only scrape would never surface it. Both Gemma repos share the exact same licence-link URL, confirming one licence framework across Google’s Gemma line regardless of architecture.

And a repo can have no tag at all. MiniMax-Music3’s machine-readable metadata carries no licence tag whatsoever — yet a real, bespoke licence document exists at a file linked from the README, imposing an unconditional “MiniMax-Music3” branding requirement on commercial products, a written-authorisation threshold above $20 million in yearly revenue, and a 19-category acceptable-use prohibition list, against 5 categories for the same vendor’s text model. Hugging Face’s structured metadata undercounts this repo as licence-less; only reading the linked file reveals the terms.

Two rows — 2 of 30 (7%, n=30) — score “not actually available”: GLM-5.3 and Qwen3.8-Max. Both claims are narrow and precisely scoped. For GLM-5.3, announced August 14, 2026, the vendor-org repo path returns the same HTTP 401 that a deliberately fake control repo returns — consistent with no public repo existing — and the vendor’s announced plan gates public API and weights behind a safety review targeted around August 28, 2026. For Qwen3.8-Max, every tested official-org path failed and a Hugging Face search returned zero repositories under the official Qwen organisation, only third-party fine-tunes and quantisations from unrelated uploaders. A claim that its weights shipped on August 8 could not be verified in this research — and could not be disproven either. Both findings are Hugging Face-scoped: this census did not check ModelScope or vendor-hosted CDNs, which some vendors also use.

What makes these two rows more interesting than “some models are not public” is who they are. Both are flagship-tier releases from vendors whose smaller or earlier models in this very dataset are fully public: GLM-5.2 is MIT and downloadable; Qwen3-Coder-Next and Qwen3.6-27B are Apache-2.0 and downloadable. The pattern the data suggests — flagship-tier gating alongside commodity-tier openness — is a rational commercial strategy, and it is precisely the pattern a licence census needs to keep measuring, because it means the openness of a vendor’s back catalogue predicts nothing about the openness of its next flagship.

If that pattern holds, the practical forecast is uncomfortable for anyone whose architecture assumes “this vendor publishes weights”: each new flagship becomes a fresh licensing event to verify from scratch, and the verification has to happen at the repository and licence-text level, not at the level of vendor reputation. This census can be re-run — the API calls are in the methodology — and that is the point.

For a team selecting a model, the table compresses to a four-step check. First, find the repository under the vendor’s own organisation — not a mirror — and confirm it exists at all (rows 6 and 9 show why). Second, read the licence tag, then open the actual LICENSE file or linked licence page regardless of what the tag says (rows 24, 25 and 30 show why). Third, map your own revenue, user counts and product category against any thresholds, field-of-use lists and branding mandates in the text — the thresholds in this dataset cluster at $10 million/year, $20 million in various windows, and 700 million MAU. Fourth, check whether outputs are treated separately from weights, as the FLUX non-commercial licence does.

Licence fit is only one axis of a self-hosting decision — for the hardware and capability axis across many of these same models, see which of these are actually worth self-hosting. And because this dataset shows licence status changing between preview and release in both directions, any production dependency on a single vendor’s weights deserves a second-source failover plan rather than an assumption of continuity. Teams that want a structured evaluation of licence exposure across an existing AI stack can run the same method through an AI transformation engagement.