GitHub has changed how it labels the licenses behind the open-source code that flows through its dependency graph, and the result is a sharp drop in “we don’t know” entries. The platform now pulls license information from the package registries themselves — npmjs.org for JavaScript and PyPI for Python — rather than leaning on file-by-file scanning. According to GitHub’s changelog, the switch cut the share of packages with no detectable license from 45% of the 170 million packages in the dependency graph down to 24% GitHub Changelog.
The move matters because license data feeds several compliance surfaces developers already rely on: dependency insights, software bills of materials (SBOMs), the Open Source License Compliance feature in GitHub Advanced Security, and the dependency review action that flags risky additions in pull requests GitHub Changelog. Cleaner inputs mean fewer false alarms and fewer blind spots when a team tries to prove what it ships.
Until now, GitHub’s primary source of license truth was the ClearlyDefined service, which scans repositories depth-first. GitHub says that approach produced “complex results that users found confusing,” so it will still fall back to ClearlyDefined but now prioritizes registry metadata GitHub Changelog. The registry is the authority for a given ecosystem, so its license field is usually the one maintainers actually intend.
A second improvement reduces database sprawl. Instead of needing a dedicated entry for every version, the system now tracks license history by version range. GitHub uses Grafana as the example: after Grafana relicensed from Apache-2.0 to AGPLv3, the graph stores one entry for versions 1.0.0 through 7.5.17 and a second for 8.0.0 and newer, covering new releases automatically GitHub Changelog. That both trims storage complexity and extends coverage to versions published after the change.
The change is live across all of GitHub today, and the company is soliciting feedback in its community forum, where the Open Source License Compliance feature is in public preview GitHub Community discussion. For maintainers, the practical takeaway is to make sure their package metadata is correct at the source, since that registry field now carries more weight than ever.
Teams managing internal analytics on top of GitHub data may also want to revisit how they surface these signals; our coverage of GitHub’s Copilot-powered data analytics agent looks at plain-language querying of repository metrics.
