GitHub Cuts Missing License Data from 45% to 24% with Registry-First Approach

GitHub has updated how it determines license information across its dependency graph, switching the primary source from the ClearlyDefined scanning service to official package registries including npmjs.org, PyPI, NuGet, and six others. The result: missing license data fell from 45% to 24% across 170 million tracked packages. The change rolled out to all GitHub users and affects dependency insights, software bills of materials (SBOMs), the open-source license compliance feature in GitHub Advanced Security, and the dependency review action.

What happened

Detail	Value
Total packages in dependency graph	170 million
Missing licenses before	45%
Missing licenses after	24%
Previous primary data source	ClearlyDefined
New primary data source	Canonical package registries
Rollout	All GitHub users, available now

GitHub’s dependency graph tracks which open-source packages a repository depends on and shows each package’s license so teams can spot compliance risks. Until now, that license data came mainly from ClearlyDefined, a community service that scans package files for license text. GitHub says ClearlyDefined’s depth-first file scanning approach produced results that users found confusing, and coverage was incomplete.

The new approach treats the package’s own canonical registry as the authoritative source. Each ecosystem maps to one registry:

Package Manager	Registry
npm	npmjs.org
NuGet	nuget.org
Python	pypi.org
RubyGems	rubygems.org
Rust	crates.io
Go	pkg.go.dev
Maven	deps.dev
Dart	pub.dev
PHP	packagist.org

GitHub still falls back to ClearlyDefined when registry data is unavailable, and continues to contribute to that project.

Version ranges: why this matters beyond the headline number

The previous system required a separate database entry for every individual package version. The new system stores license data as version ranges, which means new releases inherit coverage automatically without waiting for a manual update.

GitHub gives a concrete example: Grafana relicensed from Apache-2.0 to AGPLv3 when it moved from version 7 to version 8. The database now holds two entries, one covering versions 1.0.0 through 7.5.17 (Apache-2.0) and one covering 8.0.0 and later (AGPLv3). This approach both compresses the database and handles future Grafana releases without any additional work. Because of this, GitHub notes the actual coverage improvement is higher than the headline shift from 45% to 24% suggests.

Why it matters for your projects

License compliance is increasingly a real business concern, not just a legal formality. Many enterprises and government contracts now require a software bill of materials (an SBOM is a machine-readable inventory of every component and its license in a piece of software). Inaccurate or missing license data in that SBOM can delay procurement, trigger audit findings, or create unexpected legal exposure if a copyleft license like AGPLv3 is embedded in a commercial product.

The dependency review action, which can block pull requests that introduce packages with disallowed licenses, is only as useful as the underlying data. Cutting missing data nearly in half means fewer false negatives where a risky license slips through undetected because GitHub simply had no information about it.

If your team uses AI-assisted development tools that pull in third-party packages rapidly, accurate license metadata is the safety net that keeps you from shipping a compliance problem without realising it.

Our take

This is a quiet but solid improvement. ClearlyDefined is a well-intentioned project, but asking a file-scanning service to be the canonical source of license truth when the package maintainer already declared the license in their registry metadata was always the wrong order of operations. Going to the source first is the right call.

The version-range approach is the more interesting engineering choice here. It solves a real operational problem: packages release constantly, and any system that requires manual per-version entries will always lag. The Grafana example also serves as a useful reminder that licenses change, and your tooling needs to track that history, not just the current state.

One caveat: registry metadata is only as accurate as what maintainers declare. A package author who sets the wrong SPDX identifier in their package.json will now propagate that error more efficiently. GitHub’s fallback to ClearlyDefined helps, but it is not a complete safety net. For high-stakes compliance work, a manual review of key dependencies remains worthwhile.

Teams managing open-source compliance across many repositories should check their GitHub service history and re-run any SBOM exports or dependency reviews that may have been generated before this update went live, since the underlying data has materially changed.

What to do about it

1. Re-export any SBOMs generated before August 2026 so they reflect the improved registry-sourced data.
2. Re-run your dependency review action on open pull requests to catch licenses that previously showed as unknown.
3. Check the dependency insights page for repositories with known compliance requirements and confirm license fields are now populated.
4. For packages still showing missing licenses, look up the package directly on its canonical registry to see whether the maintainer has declared a license there.
5. Flag any packages where the registry-declared license looks wrong (mismatched SPDX identifier) and consider contributing a correction upstream.

The data is better today than it was last week. Run your compliance checks again and update any SBOM exports you have shared with clients or auditors.

Source: GitHub Changelog