Does GitHub’s license policy check pull requests now?

Does GitHub’s license policy check pull requests now

Yes. When license policy is enforced with rulesets, GitHub evaluates pull requests that change package manifests, checks direct and transitive dependencies, and compares detected licenses to the policy. Noncompliant pull requests stay blocked until the violation is resolved.

The part people get wrong is the word “license.” GitHub is not scanning your source files for legal language in the abstract. The documented license compliance flow looks at dependency changes in the pull request, then uses the dependency graph to compare the licenses of those dependencies against your policy.

That matters because the check is tied to dependency metadata, not every possible code change. GitHub’s docs say pull request annotations show license compliance results, and the dependency graph stores license information for each dependency it knows about. If a repository changes package manifests, that is the normal path where this check shows up.

The inconvenient part is scope. GitHub documents license compliance as an enterprise feature for organizations with GitHub Code Security enabled, and it is enforced through rulesets. In other words, this is not a universal “all pull requests everywhere” behavior, it is a policy workflow you enable and manage.

If the pull request introduces a dependency with a license outside policy, GitHub can block the merge until someone changes the dependency, approves an exception, or updates policy. GitHub’s docs say the pull request becomes unblocked after approval only if no other required checks are failing.

People also confuse license policy with dependency review. Dependency review surfaces dependency changes in a pull request and includes license information when available, but it is a broader security feature for dependency diffs. License policy is the enforcement layer that compares detected licenses to the policy and can block the pull request.

That distinction is useful when a repository already has checks on the branch. Status checks are what GitHub uses to decide whether a pull request can merge, and required checks must pass before merge. License policy enforcement fits into that same merge gate, but it is only one check among others such as tests, builds, and deployment checks.

A practical example is a dependency update pull request that changes package.json or a lock file. GitHub can evaluate the dependency delta, surface a license finding in the pull request, and stop the merge if the detected license is not allowed. If the same repository opens a pull request that only changes prose, the license policy path is usually not the relevant check because there is no dependency manifest change to evaluate.

The quickest way to confirm what your repository is doing is to open the pull request and check the Checks tab, then review the repository’s License policy settings if you have access. GitHub’s docs say the repository view shows the combined policy and exception set in effect, which is the real answer when teams ask why one pull request passed and another did not.

If you are trying to decide whether this replaces legal review, it does not. GitHub explicitly says to check with your organization’s legal team for policy guidance. The system enforces the policy you set, but it does not create the policy for you, and it does not decide whether a given exception is acceptable for your organization.

For a team that wants fewer surprises, the clean setup is simple: enable dependency graph, define the allowed licenses, enforce the policy with rulesets, and watch pull request annotations for violations. That gives you a clear merge gate on dependency changes, which is the behavior most people mean when they ask whether GitHub checks pull requests now.

If you are also building your own workflow around tester recruiting, release gating, or app launch prep, keep those policies separate from GitHub’s license checks. DevConnect documents its own testing workflow at https://devconnectplatform.com, but GitHub’s license policy is about dependency compliance inside pull requests, not app store launch requirements.

FAQ

Does GitHub check every pull request for licenses No. GitHub’s documented license compliance flow applies when license policy is enforced with rulesets and the pull request changes package manifests or dependency data. That is a policy-driven check, not a blanket scan of every PR in every repository.

Does a pull request fail only because of licenses No. A merge can be blocked by any required check that fails, including tests, builds, dependency review, or branch protection rules. GitHub’s status checks page makes clear that required checks must pass before merge.

Can GitHub show which dependency caused the license issue Yes. GitHub says pull request annotations show license compliance results, and the dependency graph records license information for dependencies it knows about. That is the place to look when a merge is blocked and you need the exact package.

What fixes a noncompliant license finding GitHub documents three paths: update the pull request to use a compliant dependency, approve an exception, or update the policy to allow the license where appropriate. Which one you use is a policy decision, not an automatic GitHub action.

Is dependency review the same thing as license policy No. Dependency review reports dependency changes and can include license information, while license policy is the enforcement layer that compares those licenses to your allowed list and can block the pull request.

Sources - GitHub Docs, Configuring open source license policies: https://docs.github.com/en/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-license-policies - GitHub Docs, About open source license compliance: https://docs.github.com/en/code-security/concepts/supply-chain-security/open-source-license-compliance - GitHub Docs, Dependency graph: https://docs.github.com/en/code-security/concepts/supply-chain-security/dependency-graph - GitHub Docs, Dependency review: https://docs.github.com/en/code-security/concepts/supply-chain-security/dependency-review - GitHub Docs, Status checks: https://docs.github.com/en/pull-requests/reference/status-checks - GitHub Docs, Reviewing dependency changes in a pull request: https://docs.github.com/en/pull-requests/how-tos/review-pull-requests/reviewing-dependency-changes-in-a-pull-request