A quiet entry on 13 August contains one of the more consequential numbers GitHub has published this year: the share of packages in its dependency graph with no known license fell from 45% to 24%.
That is 170 million packages, and it is the reason software bills of materials have been so much less useful than they sound.
What changed
GitHub now prioritises package registry metadata over the ClearlyDefined service when determining a license. Canonical registries are used for eight ecosystems: npm, NuGet, Python, Rubygems, Rust, Go, Maven and Dart.
The reasoning is straightforward once stated. A registry is where a package is actually published, so its metadata is the closest thing to an authoritative answer about what license that package shipped under. A third-party aggregation is a copy, and copies drift.
Version ranges instead of individual versions
The second change is less visible and arguably more important: the dependency graph now tracks license history based on version ranges rather than requiring an entry for each individual version.
GitHub's own example is Grafana, where the license changed across the project's life — Apache-2.0 through 7.5.17, then AGPLv3 from 8.0.0 onward. Under a per-version model, correctly answering "what license is this dependency under" requires having a record for the exact version you use. Under version ranges, the answer is derivable, including for versions that have not been released yet.
This is the part that matters for anyone who has had a compliance answer come back as "unknown" for a package they knew perfectly well the license of.
Where you will see it
The improved data flows into four places:
- The dependency graph
- Software bills of materials
- The open source license compliance feature in GitHub Advanced Security
- The dependency review action
Why 24% is still the story
Halving the gap is a real achievement and it leaves nearly a quarter of packages unresolved. That residue is what your compliance process still has to handle by hand.
It is worth being clear-eyed about what an SBOM with 24% unknowns is: a document that looks authoritative and is silent on one dependency in four. If your organisation files these for customers or regulators, the honest framing is that the tooling has got substantially better at the easy cases and the hard ones are still hard.
The useful action is to re-run the reports rather than trust the ones you filed last quarter. Updated license information became available immediately on 13 August, which means a report generated before that date understates what is known.