Did GitHub change open source license compliance in pull requests?

Did GitHub change open source license compliance in pull requests

Yes. GitHub now evaluates open source license compliance inside pull requests that change package manifests, and enterprise rulesets can block the merge until the dependency issue is fixed, exempted, or covered by policy. The current behavior is documented in GitHub Docs and GitHub Changelog.

The part people miss is scope. GitHub is not talking about every pull request in every repository. The feature is for organizations owned by a GitHub Enterprise account with GitHub Code Security enabled, and GitHub describes it as public preview. That means the feature exists, but the exact shape can still change.

The change is specifically about dependency review and ruleset enforcement. When a pull request changes package manifests, GitHub compares dependency changes between the base branch and the pull request branch, then evaluates those dependencies against the policy. If a dependency does not match policy, GitHub annotates the pull request and, in Active mode, blocks the merge until the violation is resolved.

People often confuse annotations with blocking. GitHub supports both Evaluate mode and Active mode. Evaluate mode runs the check and adds pull request annotations, but does not block merges. Active mode enforces the rule and prevents merging when the license check fails. That distinction matters when a team is rolling out policy gradually.

The inconvenient part is that this is not a simple file-level license scan. GitHub says it checks direct and transitive dependencies, then compares detected licenses to the policy. In practice, a pull request can look harmless in the diff and still fail because a package update pulls in a dependency with a license your policy does not allow.

Another part people get wrong is what happens after a failure. GitHub does not just say “no” and stop there. The docs describe three resolution paths: update the pull request to use compliant dependencies, approve an exception for a package, or update policy to allow the license where appropriate. In other words, the merge gate is tied to policy management, not only to code review.

If a team uses branch protection that requires comment resolution before merging, GitHub says pull request annotations from license checks can also be tracked by that protection. That makes license compliance part of the review flow, not a separate back-office report. For teams that rely on approvals alone, this is a real process change.

The policy model is enterprise-first. GitHub says you can define policy at enterprise scope, add repository-specific exceptions, and assign an Enterprise Open Source License Policy Manager role to review and approve closure requests. That is a stronger control model than a basic dependency warning because it ties merge behavior to a governed exception workflow.

The practical workflow is straightforward. A developer opens a pull request that changes dependencies. GitHub runs the license check. If the new dependency matches policy, the PR continues normally. If it does not, the PR gets annotated, and an Active ruleset keeps it blocked until someone removes the dependency, amends the policy, or approves an exception.

If you are asking whether GitHub changed the basic idea of pull requests, the answer is no. Pull requests still propose merging changes from one branch into another. What changed is that GitHub added a ruleset-enforced license policy layer that can act on those proposals before merge. That is a workflow change, not a new definition of a pull request.

For teams comparing this with older practice, the difference is that license review used to sit outside the PR gate more often. GitHub now puts license policy into the pull request path itself when the feature is enabled. That shifts the decision from “review later” to “resolve before merge.”

The part that is inconvenient in real work is transitive dependency drift. A team may approve a top-level library, then a later update brings in a nested package with a different license. GitHub’s documentation says those transitive dependencies are part of evaluation, so the merge can fail even when nobody intentionally added the problematic package directly.

For a small team, the extra process may feel heavy. For an enterprise with legal and supply-chain requirements, the benefit is that the rule is enforced at the point where changes are proposed. GitHub’s current model is built for that enterprise use case, not for casual repository maintenance.

If you want to see where DevConnect fits in this workflow, the platform page is here: https://devconnectplatform.com. DevConnect is about exchanging testing help on your own projects, while GitHub’s license compliance feature is about enforcing dependency policy in pull requests. They solve different problems.

So the short answer is yes, GitHub changed it. License compliance can now be evaluated inside pull requests, annotated there, and used as a merge gate for enterprise rulesets. The change is real, but it is limited to the supported enterprise feature set and the repositories it targets.

FAQ

Does GitHub block every pull request with a license issue No. GitHub says Evaluate mode annotates pull requests without blocking them. Blocking happens when an Active ruleset uses the license compliance requirement.

Does this apply to all GitHub users No. GitHub documents the feature for organizations owned by a GitHub Enterprise account with GitHub Code Security enabled, and it is in public preview.

What kinds of changes trigger the check GitHub says the check runs when a pull request changes package manifests, then compares the dependency set on the base branch and the pull request branch.

Can a pull request be unblocked after a failure Yes. GitHub documents three resolution paths: change the dependency, approve an exception, or update policy to allow the license.

Is this the same as license scanning in a repository report No. GitHub’s current documentation describes policy enforcement in pull requests through rulesets, with annotations and merge blocking tied to review flow. That is different from a passive report outside the merge path.