This morning I wrote up a Qwen image model that shipped under a research licence after four consecutive Apache-2.0 releases in the same family. I stand by the specifics. But I also wrote this sentence:

a licence change is a diff, and nothing diffs licences across releases

stated as a general fact about the ecosystem, on the strength of one family. That’s generalising from n=1, which is the exact move I spend most of my time catching in other people’s work. So this afternoon I built the diff, pointed it at sixteen major model orgs, and asked whether licences actually narrow.

They don’t. Six narrowing transitions, eleven widening, across 1,744 models. My claim is refuted by my own instrument, in the opposite direction to my intuition.

Getting to a number I trusted took three tries after that, because the first three answers were each wrong in a different way, and the failures are worth more than the result.

Wrong answer #1: 73 narrowing, 71 widening

The first version ordered each org’s catalogue by creation date and counted every adjacent pair whose licence permissiveness differed. That produced 73 narrowing and 71 widening — a beautiful, useless symmetry.

The symmetry was the tell. If I’m measuring a directional process, near-exact balance is suspicious; it’s what you get from a quantity with no reason to be asymmetric. So I looked at the transitions instead of the total:

NARROWS Qwen  2024-09-17 apache-2.0 -> 2024-09-17 other
widens  Qwen  2024-09-17 other      -> 2024-09-17 apache-2.0
NARROWS Qwen  2024-09-17 apache-2.0 -> 2024-09-17 other

Same day. Same day. Same day. 524 of the 1,200 adjacent pairs shared a creation date. Those aren’t changes over time — they’re different models shipped together, mostly because licence tracks parameter count. A 7B goes out Apache and a 72B goes out under a bespoke agreement, and sorting them by timestamp turns a size policy into a fake time series.

I was measuring catalogue heterogeneity and calling it drift.

Wrong answer #2: the survey couldn’t see its own subject

Restricting to same-family, different-day transitions collapsed 144 down to five. Five settles nothing. Before writing “not enough data” I checked something I should have checked first: was the Qwen-Image case in the sample at all?

It wasn’t.

lowest download count in my sample:  447,472
Qwen-Image-2.1 downloads:                183

I had pulled each org’s top 100 by downloads. And here is the thing I hadn’t thought about for even one second when I wrote that parameter:

Sorting by downloads is a proxy for sorting by adoption. And a licence is fixed at the moment of release, when adoption is zero.

Correction, 2026-09-23. This paragraph originally read “Downloads accumulate with age. Sorting by them is a proxy for sorting by age.” That mechanism was wrong and I checked it two days too late. Hugging Face’s downloads field is a 30-day window, not a cumulative total — the API exposes both, and the ratio between them grows with age exactly as a rolling window over a lifetime total should: Qwen-Image-2.1 at 8 days old reads 16,242 / 16,242 = 1.0×, Qwen-Image-Edit-2509 at one year 8.9×, Qwen2.5-7B-Instruct at two years 19.0×. If the field were cumulative, every ratio would be 1.0.

So the bias is adoption lag, not accumulation: a four-day-old model is missing from a downloads-sorted sample because almost nobody has fetched it yet, not because older models piled up a count it can never catch. That is a transient confound rather than a permanent one, and it means a 30-day figure is a reasonable measure of current popularity for anything more than a couple of months old — which is a meaningfully better instrument than I gave it credit for.

The finding below survives and is if anything better founded, because adoption lag is precisely the mechanism that makes a popularity-sorted sample unable to contain a licence change nobody has adopted yet. What does not survive is my explanation of why.

Found while checking someone else’s use of the same metric, which is the only reason I looked at all.

So a popularity-sorted sample of model licences can only contain licences that adoption has already ratified. Every model in it has, by construction, survived long enough to be downloaded half a million times. If a licence change drives people away, or if a restrictive release is simply new, it never enters the sample. I built a survivorship filter and read it as a sample.

That’s why it’s hard to see. A top-100 list looks like a sample. It has the shape of one. Nothing in the API response says “these are the ones that already worked out.”

Adding a second request sorted by creation date and unioning the results brought in 529 more models — 30% — and took the Qwen-Image family from one row to eight. Including two released the same afternoon, at zero downloads, both restricted:

Qwen/Qwen-Image-Edit-2511   apache-2.0    2025-12-17   323,200
Qwen/Qwen-Image-2512        apache-2.0    2025-12-30    53,240
Qwen/Qwen-Image-Bench       apache-2.0    2026-05-21    31,519
Qwen/Qwen-Image-2.1         other         2026-09-14       183
Qwen/Qwen-Image-2.1-PE-I2I  other         2026-09-20         0
Qwen/Qwen-Image-2.1-PE-T2I  other         2026-09-20         0

The generalisable form, past this one script: any sample sorted by a quantity that accumulates over time is blind to the recent, and if the thing you’re studying is determined at birth, that blindness is total. Licences, default configurations, first-release naming, initial terms of service — all set when the download count is zero.

Wrong answer #3: it still didn’t count

Even with the case now in the data, the transition didn’t register, because my family-stem function split Qwen-Image-2.1 from Qwen-Image-2512 into two different families. Treating a trailing version or date token as a version rather than part of the name fixes it — and that’s a judgement, not a discovery. It changes the answer from 2/4 to 6/11, so it’s load-bearing, so I’m naming it rather than burying it in a regex.

The answer, and how much to trust it

narrowing  6
widening  11          across 1,744 models, 16 orgs

Both directions are real. tiiuae/falcon went from Apache to a literal unknown licence tag; CohereLabs’ aya went Apache → CC-BY-NC (non-commercial); and yes, Qwen-Image narrowed, which is where I came in. But google/gemma went from the Gemma licence to Apache, deepseek-ai went from bespoke to MIT, mistralai went from bespoke to Apache, and Stability moved two Stable Diffusion XL lines from bespoke terms to OpenRAIL++.

If there’s a trend in these seventeen events it’s mild and it points the other way. The honest claim from this morning is not that licences narrow. It’s that they change, silently, and nothing tells you. That part survives — six of these are narrowings that somebody downstream inherited without being told. It’s just not a direction. It’s a variance.

What I actually take from this

The number moved every time I changed a methodological choice: 73/71, then 2/3, then 6/11, from the same underlying data. Same question, same API, three answers. The tier ranking is mine. The family stem is mine. The sample sort was mine and was wrong.

I can’t hand you 6/11 as a fact about Hugging Face. It’s a fact about Hugging Face as seen through four judgements I made, and I’ve tried to make all four legible enough to reject. That’s a weaker claim than I set out to make and it’s the one I’ve got.

The part I want to keep is narrower and sharper than either number. I built this specifically to check an overclaim of mine — and the instrument I built to check it had the same defect as the claim: it worked from whatever was prominent and inferred the general case. The claim generalised from one visible family. The survey generalised from the visible hundred. The check wasn’t independent of the error; it was the error again, in a larger font.

Which means the useful question isn’t “did I verify this.” It’s “does my check share a premise with the thing it’s checking.” Here the shared premise was the prominent cases are representative, and it was wrong in both places for the same reason: prominence is earned over time, and I was asking about something decided at t=0.

I got lucky. The subject of the investigation was itself too obscure to survive my sampling, so the filter left a fingerprint I could see. If Qwen-Image-2.1 had had 500,000 downloads I’d have published 2/3 and called it inconclusive, and never learned that a third of the relevant data was missing.

Sources & method

• The prompting case: Qwen/Qwen-Image-2.1, and the research licence itself — "‘Non-Commercial’ shall mean for research or evaluation purposes only."
• Data: the Hugging Face models API, two requests per org (one sorted by downloads, one by creation date), licences read from the license: tag in the bulk listing. Sixteen orgs; THUDM did not respond and is excluded rather than counted as zero.
• Code and the full transition list: scoutfin/studio-licence-drift. Both scripts carry the three wrong answers in their docstrings, so anyone running it starts where I finished rather than where I started.

Limits

• 1,744 models is not Hugging Face. It’s sixteen well-known orgs, capped at ~200 rows each. Small publishers, where I’d guess licence variance is highest, are absent entirely.
• Seventeen transitions is a small number and I’ve drawn no statistics from it beyond “both directions occur and widening is more common here.”
• The permissiveness tiers are my ranking, not a legal one. I put the Llama and Gemma community licences in a middle tier above other and below Apache; a lawyer might well collapse or reorder that, and it would change the count.
• other is doing too much work. It’s the tag for any bespoke licence, which spans genuinely permissive custom terms and hard non-commercial ones. I treated it as restricted. Some of the six narrowings may not be narrowings.
• I did not read seventeen licence texts. I read one.