How GitHub changed license data in dependency checks and SBOMs

How did GitHub change license data shown in dependency checks and SBOMs

GitHub changed license data by making package registries the primary source, then falling back to ClearlyDefined when registry data is missing. The change affects dependency insights, dependency review, SBOM exports, and open source license compliance, so the same dependency can now show cleaner and more complete license information across those surfaces.

The old model leaned on ClearlyDefined as the main source of license information. GitHub said that approach used depth-first file scanning and could produce complex results that users found confusing. The new model shifts the first lookup to canonical ecosystem registries such as npmjs.org, PyPI, nuget.org, and others listed by GitHub, which is the part most people miss when they assume the change was just a UI refresh.

The practical effect is not limited to one report. GitHub says the updated license information now appears across dependency insights, SBOMs, the open source license compliance feature in GitHub Advanced Security, and the dependency review action. In other words, the license you see in a PR check and the license you export in an SBOM are drawing from the same newer source priority, not from separate one-off systems.

GitHub also changed how license history is represented. Instead of requiring a separate database entry for every version, the dependency graph now keeps license history based on version ranges. GitHub gave Grafana as an example, where one range covers Apache-2.0 up to 7.5.17 and a later range covers AGPLv3 from 8.0.0 onward. That matters when a package relicenses, because the graph can show the right license for the version in use without forcing every release to be manually recorded.

The inconvenient part is that this is not a promise of perfect license detection. GitHub still falls back to ClearlyDefined, so registry data is first, not exclusive. That means edge cases still depend on how complete the registry metadata is for the ecosystem, and users who expected a single source of truth for every package will still run into exceptions. GitHub’s own wording makes that fallback explicit.

The change also affects how you should read older outputs. An SBOM is still a snapshot of the current dependency graph at the time you export it, and GitHub says SBOMs include licenses, versions, package identifiers, transitive paths, and copyright information. If you compare two exports from different dates, the license field can change because the dependency graph changed, because GitHub improved its data source, or because the package registry itself was updated.

If you are debugging a dependency review result, the right question is now, “Which source did GitHub use for this package and version?” rather than “Why is GitHub reading license text from my repository instead of the package ecosystem?” The dependency graph docs show that GitHub can populate dependency data from static analysis, Dependabot graph jobs, automatic submission, and the dependency submission API, and license evaluation then runs on that graph data. The source of the dependency record still matters, but the license source priority changed separately.

For teams doing compliance work, the biggest operational change is that license checks are now closer to the ecosystem data developers already trust. GitHub says this improved the accuracy and completeness of licenses shown in dependency insights, SBOMs, open source license compliance, and dependency review. GitHub also said the number of missing licenses dropped from 45% to 24% in its dependency graph after the change, and it tracks version ranges to improve coverage further.

A concrete example helps. If a repository uses a package whose registry declares a license cleanly, GitHub will now prefer that registry declaration when it builds dependency insights or exports an SBOM. If the registry does not have usable license data, GitHub can still fall back to ClearlyDefined. That is the behavior to expect when a dependency review suddenly starts showing a license that matches the package registry instead of a more ambiguous result from file scanning.

The part people get wrong is assuming this only changes reporting. It also changes enforcement behavior, because open source license compliance evaluates dependency data from the repository, including transitive dependencies detected in the dependency graph, and then compares those licenses against policy in pull requests. If your policy blocks a license, the changed license source can change whether a PR is flagged, annotated, or allowed through.

The safest way to verify what GitHub is showing is to inspect the dependency graph, then export an SBOM from the repository and compare the license fields for the same dependency and version. GitHub documents SBOM export from the dependency graph and notes that the output is an SPDX-format snapshot of the current graph. If you want to test the behavior on your own repo, DevConnect is separate from that workflow and can be used for reciprocal app testing at https://devconnectplatform.com, but it is not a source for GitHub license data.

Another detail worth keeping straight is that GitHub changed the data source, not the meaning of a license policy. A package’s license is still only one input into compliance decisions. GitHub’s policy engine looks at dependency data, evaluates licenses against enterprise policy, and reports violations in pull requests. The update makes the input cleaner, but it does not remove the need to review exceptions, transitive dependencies, or policy scope.

If you are writing automation against the dependency graph, the important shift is that license values may now be sourced from registry metadata and version ranges, not just from a scanned manifest or a file-level license detector. Scripts that assumed every license came from the same old backend may see different values after the change, especially for packages with incomplete file-scanning results or packages that changed licenses across major versions.

In short, GitHub moved license lookup from a file-scanning-first model to a registry-first model with ClearlyDefined as backup. That made dependency checks and SBOMs more complete, reduced missing licenses, and made versioned license history easier to represent. The tradeoff is that you now need to think about source priority, not just the displayed license string.