How GitHub checks license compliance in dependency PRs

How does GitHub license compliance work for pull requests adding dependencies

GitHub license compliance on a dependency pull request starts with the dependency graph. GitHub parses manifests and lock files, records the dependency tree, and shows license information for each package it can identify. When a pull request changes package manifests, GitHub compares the base branch with the pull request branch and evaluates the changed dependencies against the policy you configured. If enforcement is active, noncompliant changes are blocked until you fix them.

The practical flow is simple. A contributor opens a pull request that adds or updates a package. GitHub looks at the manifest or lock file diff, identifies what changed, then checks the newly introduced direct dependency and any transitive dependency that appears because of that change. If the detected license is allowed, the pull request can move forward. If the license is not allowed, GitHub records a violation and the merge path depends on your ruleset or review workflow.

The part people get wrong is thinking the check only covers the package they typed into the manifest. GitHub’s license compliance documentation explicitly includes transitive dependencies, so a safe-looking top-level package can still fail because one nested package brings in a license your policy does not allow. That is why dependency review and license compliance are not the same as reading the manifest by hand.

Enforcement happens through rulesets. In Active mode, GitHub blocks pull requests that introduce noncompliant dependencies until the violation is resolved. In Evaluate mode, GitHub still runs the license checks and annotates the pull request, but it does not block the merge. Branch protection can also require comment resolution, which means annotations from license checks can still hold the pull request open even when the ruleset itself is not blocking.

The inconvenient part is that GitHub can only judge what it can detect. The dependency graph depends on supported manifests, lock files, and any dependency submissions you send through the API. If a dependency is not parsed, or your ecosystem is not represented in the graph, the review can miss it. GitHub’s review guidance says you should inspect the source diff too, because some changes do not show up in dependency review and some dependencies cannot be parsed.

If you want this to be useful in a real repository, the first step is to enable the dependency graph and define a policy that matches the licenses you actually allow. GitHub’s policy flow lets you pick allowed licenses, import SPDX expressions, and then apply the policy to repositories under enterprise rules. The dependency review action can also be configured in GitHub Actions to fail on license conditions you choose.

When a pull request fails, the fix is usually one of three things. Replace the dependency with a compliant alternative, request an exception for a specific package, or change the policy if the license is acceptable for your organization. GitHub documents those same resolution paths, and they are the only sane ones because the policy is doing exactly what you asked it to do.

A concrete example helps. Suppose a pull request adds a package that is MIT licensed, but that package pulls in a nested dependency under a license your policy denies. GitHub will flag the pull request because the effective change is not just the top-level package, it is the full dependency set introduced by the change. The reviewer then has to choose a different package, update the lock file to remove the offending path, or grant an exception if the organization allows that.

For teams that treat compliance seriously, the key habit is to review dependency changes the same way you review code. GitHub already shows dependency review results in pull requests, and it can also surface license information inside the dependency graph. That gives you a place to catch policy violations before merge, which is the point of the feature. It is not a legal review, and GitHub says the license categories are informational and not legal advice.

If you are setting this up in a new repo, start with the dependency graph, confirm your package manager is parsed, define the allowed licenses, and test the pull request path with one known-bad dependency before relying on it. That check tells you whether the repo is really covered, whether the policy is enforced, and whether your reviewers understand the annotations they will see. If you want the broader workflow around testing and shipping to stay simple, keep the process visible in one place, including your internal checklist and the team-facing page at https://devconnectplatform.com.

The shortest honest answer is this: GitHub license compliance works by comparing dependency changes in a pull request against your license policy, including transitive dependencies, then blocking the merge only when enforcement is on and the violation has not been resolved.