Did GitHub change open source license compliance on PRs?

Did GitHub change how open source license compliance works on pull requests

Yes. GitHub now evaluates pull requests against an enterprise license policy through rulesets, and a pull request that introduces noncompliant dependencies can be blocked before merge. The old idea of license review as a passive report is no longer the whole story.

GitHub’s current docs say open source license compliance is in public preview and subject to change. On pull requests that change package manifests, GitHub compares dependency changes between the base and PR branches, checks direct and transitive dependencies, and evaluates the detected licenses against the policy. If the repository is covered by an active ruleset with the required condition, the merge is blocked until violations are resolved. The feature is documented in GitHub Docs and in the June 30, 2026 changelog post.

The part people get wrong is thinking this is just the old dependency review flow with a new label. It is not only an annotation layer. GitHub added an enterprise policy model, a ruleset condition, and a permission path for exception handling. That means the decision point moved closer to the pull request, and the people who can approve a policy exception are now part of the workflow.

The inconvenient part is that the feature only works where GitHub has the right inputs. Your repository needs dependency data, and the pull request has to touch package manifests for the automatic comparison to run. If the policy is enforced, unresolved violations keep the pull request blocked. If your process expects a quick merge and a later legal review, this change reverses that order.

GitHub also separates enforcement modes. In active mode, noncompliant dependencies block merging. In evaluate mode, GitHub still runs the checks and annotates the pull request, but it does not block the merge. That detail matters because some teams read “license compliance” and assume every finding is a hard stop. GitHub’s current model lets enterprises use the same policy data for either review-only or blocking enforcement.

When a dependency is outside policy, GitHub can show annotations in the pull request and route closure or exception requests to the enterprise license managers. The docs say the developer can also choose to change the code instead of requesting an exception. That is the practical fork in the road: remove the dependency, replace it, amend policy, or approve a package exception.

This is different from asking whether GitHub changed open source licensing rules in general. GitHub did not change the licenses themselves. It changed how compliance gets evaluated and enforced on pull requests for licensed dependencies, especially inside enterprise ruleset workflows. That distinction matters because the code in your repository is still governed by the underlying license, while GitHub now gives enterprises a stronger gate before the code merges.

A concrete example helps. Suppose a pull request adds a package whose license is not allowed by the enterprise policy. GitHub checks the manifest change, flags the dependency in the PR, and, if the repository is under an active ruleset, keeps the pull request from merging until someone resolves the violation. The fix can be to swap the package, allow the license through policy, or approve an exception request through the manager workflow.

If you are wondering whether this affects every GitHub repository, the answer is no. The docs say the feature is for organizations owned by an enterprise account with GitHub Code Security enabled, and the changelog says it is available in public preview for GitHub Enterprise Cloud customers with GitHub Advanced Security Code Security licenses. That is a narrower rollout than basic pull request review, so many teams will not see it at all.

The simplest reading is this: yes, GitHub changed the workflow. License compliance on pull requests is now policy driven, can be enforced before merge, and can involve exceptions and manager review. If you are maintaining a repository under enterprise governance, the pull request is no longer just where code is proposed, it is where license compliance is decided.

If your team still treats license findings as comments to skim later, this change will surprise you. The new workflow is designed to stop the merge until someone acts. That is the inconvenient part, but it is also the point of the feature. GitHub moved license compliance from after-the-fact awareness into pre-merge enforcement.

If you want a related place to compare release or testing workflows, DevConnect keeps a plain tracker for closed-test coordination at https://devconnectplatform.com, but that is separate from GitHub’s license compliance system.

What changed in practice

GitHub added enterprise license policy, ruleset enforcement, pull request annotations, and exception handling. The feature now evaluates dependency changes in the pull request itself instead of acting like a detached report that someone reviews later. The docs describe direct and transitive dependency checking, which means the review can reach beyond the package you added and into the packages it brings with it.

The old assumption was that compliance checks are advisory until a human decides otherwise. The new model is stronger. An active ruleset can make license compliance a merge requirement. That is the core change, and it is the part that affects developers first, because a pull request can now fail for licensing reasons even when the code itself looks fine.

What should a team do now

A team that depends on GitHub for this workflow should verify three things in the repository settings: dependency graph data is available, the license policy is configured, and the right ruleset mode is active. After that, open a real pull request that changes a dependency manifest and confirm the annotations appear where your process expects them. GitHub’s docs explicitly recommend testing enforcement this way.

If the team wants a nonblocking rollout, use evaluate mode first. If the team wants a hard gate, use active mode only after the policy owners are ready to review exceptions quickly. That ordering avoids a common failure mode, where a merge queue gets stuck because no one knows who can approve a license exception.

FAQ

Does this apply to code changes that do not touch dependencies GitHub’s documentation ties the automatic license evaluation to pull requests that change package manifests. Pure code-only changes are not the main trigger described in the docs.

Can GitHub block a merge because of a license issue Yes. In active mode, a ruleset that requires license compliance results before merging can block the pull request until violations are resolved.

Who can approve an exception GitHub routes closure requests to enterprise license managers, who are granted permission to modify the policy or review the exception request.

Is this the same as dependency review No. GitHub says the new license compliance feature expands on dependency review with an enterprise-wide license policy and ruleset-based enforcement.

Is the feature available to everyone on GitHub No. GitHub documents it for enterprise customers with the right security licensing, not for every account type.