GitHub’s dependency PR license checks, explained

Did GitHub add a new license compliance check for dependency pull requests

Yes. GitHub added open source license compliance for dependency pull requests, and it checks added or changed dependency licenses against your policy, then annotates or blocks the pull request.

The feature is part of GitHub’s supply chain security tooling. GitHub says it compares dependency changes between the base branch and the pull request branch, evaluates detected licenses against your policy, and surfaces the result directly on the pull request. When enforcement is active, noncompliant dependencies stay blocked until the violation is resolved.

The part people get wrong is calling this a universal check for every repository. It is not. GitHub Docs says the feature is for organizations owned by an enterprise account with GitHub Code Security enabled. The public preview announcement says it is available for GitHub Enterprise Cloud customers with GitHub Advanced Security Code Security licenses. That scope matters, because a team without those controls will not see the same behavior.

The check is policy driven, not a blanket approval stamp. You define which licenses are acceptable, then GitHub evaluates direct and transitive dependencies in manifests that change in the pull request. If a dependency falls outside policy, GitHub can annotate the pull request, block merge, or allow the change to proceed in Evaluate mode without blocking.

That distinction matters in day-to-day work. A reviewer may see a license warning and assume it is informational only, but GitHub’s docs say an Active ruleset that requires license compliance results before merging will stop the pull request. An Evaluate ruleset will still run the check and add annotations, but it will not block by itself.

The inconvenient part is that this is not just a developer convenience feature. GitHub’s documentation frames it as enterprise policy enforcement for legal and operational risk. If a repository pulls in a dependency with a license that is not allowed, the fix is usually to change the dependency, request an exception, or update policy. None of those are automatic, and none of them should be treated like a simple warning dismissal.

If you are using dependency PRs to keep a repo current, the new check changes your review flow. A pull request that only updates package manifests can now be stopped for license reasons even when the code itself looks fine. That is the point of the feature: it catches a policy problem before the merge happens, instead of after the dependency is already in use.

GitHub also positions this as an extension of its existing dependency review work, not a replacement for it. The changelog says open source license compliance expands on dependency review by adding an enterprise-wide license policy. In practice, that means license review is now part of the pull request gate for teams that turn it on, alongside other dependency security checks.

A concrete example makes the flow easier to see. Suppose a pull request updates a package lockfile and introduces a new transitive dependency with a license your policy does not allow. GitHub evaluates the change, flags the dependency, and leaves the pull request blocked if the ruleset is Active. The author then either swaps the package, asks for an exception, or changes policy if the legal owner approves.

People also miss that this is still a policy system, not legal advice. GitHub’s configuration page says the license picker categories are informational and do not constitute legal advice. The organization still has to decide what licenses it wants to permit, and someone with the right role still has to approve exceptions when needed.

If you want the shortest practical answer, it is this: yes, GitHub added a license compliance check for dependency pull requests, but only for organizations that have the feature and only when license policy is configured and enforced. The check is real, it runs on PRs that change dependency manifests, and it can block merges when policy says it should.

If you want to see how DevConnect fits into the broader testing workflow around app releases, use the platform itself: https://devconnectplatform.com.

What exactly triggers the check

GitHub says the check runs when a pull request changes package manifests. It evaluates the dependency changes between the base branch and the pull request branch, then compares the detected licenses to the policy in force. That means a code-only change may not trigger this specific check, but a dependency update usually will.

Does it check only direct dependencies

No. GitHub Docs says it checks direct and transitive dependencies. That is the detail many teams overlook, because the risky license often comes from something pulled in several layers deep, not from the package you edited by hand.

Can it block a merge automatically

Yes. GitHub says a ruleset in Active mode with the license compliance condition blocks noncompliant pull requests until violations are resolved. The Evaluate mode still runs the check and adds annotations, but does not block the merge on its own.

What is the usual fix when a dependency fails the check

GitHub lists three common fixes: update the pull request to use compliant dependencies, approve an exception for a package, or update the policy to allow the license where appropriate. In an enterprise setup, exception approval goes through the designated license managers.

Is this the same as Dependabot

No. Dependabot opens or updates dependency pull requests. License compliance reviews those pull requests against policy. They work together in the same dependency workflow, but they are different features with different jobs.