Did GitHub change open source license merge blocking?

Did GitHub change how open source license checks block merges

Yes. GitHub’s open source license compliance flow now distinguishes between evaluation and enforcement, and only an Active ruleset with the license compliance merge condition blocks the pull request. An Evaluate mode ruleset still runs the check and annotates the pull request, but it does not stop the merge. GitHub documents this behavior in its license compliance guide and in its ruleset notes.

The part people get wrong is assuming every license warning is a hard stop. GitHub also says that required status checks on protected branches can block merging, but the license compliance feature is a separate ruleset condition with its own mode. In practice, the merge outcome depends on whether the repository, organization, or enterprise turned that license rule on in Active mode, not just on whether GitHub detected a license issue.

GitHub’s current documentation says open source license compliance is enforced through branch rulesets. When a pull request changes package manifests, GitHub compares dependency changes between the base and pull request branches, evaluates the detected licenses against policy, and reports violations. If the ruleset is Active and requires license compliance results before merging, noncompliant dependencies block the merge until the violations are resolved.

GitHub also says an Evaluate mode ruleset with the same condition runs license checks and annotates the pull request without blocking merges. That is the key change to understand. A team can use the same policy definition first to observe what would fail, then switch to enforcement only after it is comfortable with the impact on real pull requests.

This matters because the old mental model, one check equals one block, is too simple. Status checks and license compliance are both part of merge protection, but they are not identical. GitHub explains that required status checks must pass before a pull request can merge on a protected branch, and it also says required checks can be satisfied by success, skipped, or neutral results. License compliance now sits inside a ruleset path that can either enforce or only report.

A concrete example helps. Suppose a repository adds a dependency with a license that violates policy. In Evaluate mode, GitHub shows the violation and keeps the merge open. In Active mode, the same violation blocks the pull request until the dependency is removed, replaced, or approved through the policy process. The pull request author sees the same finding in both cases, but only one mode changes the merge button state.

The inconvenient part is that a blocked merge is not always a code problem. It can be a policy problem, a dependency graph problem, or a ruleset setup problem. GitHub says license evaluation uses dependency data from the repository, including transitive dependencies detected in the dependency graph, so a seemingly harmless manifest edit can surface a downstream license violation. That means teams need to check the whole dependency chain, not just the package they added directly.

Another thing people miss is source selection. GitHub says that when you add a required status check, you can select an app that has recently set that check as the expected source of status updates. If a repository also uses protected branches and required checks, a merge can fail for source mismatch, stale results, or missing updates even when the code itself is fine. License compliance problems add one more policy gate on top of that.

If you are trying to tell whether a specific repository has changed behavior, look for the ruleset mode and the exact license condition name. GitHub’s changelog for the public preview says the new condition is called “Require license compliance check results before merging.” That is the setting that turns license evaluation into a merge blocker. Without Active mode, the pull request can still merge.

The practical workflow is simple. Check the repository’s rulesets, confirm whether license compliance is in Evaluate or Active mode, open the pull request, and read the checks and annotations. If the merge is blocked, fix the dependency change or get the required approval through the policy path. If the merge is only annotated, the repository is in observe mode and the warning is informational, not a hard gate.

For teams that want the shortest answer, GitHub did change the behavior in the sense that license checks are no longer just informational by default in the new ruleset flow. They can block merges, but only when the ruleset is set to enforce them. That is the distinction that matters when a repository suddenly starts refusing to merge pull requests that add or modify dependencies.

If you are comparing this with older branch protection habits, do not assume the merge blocker came from the status check system alone. GitHub’s docs still treat required status checks, reviews, merge queues, and rulesets as separate controls. The license compliance feature now plugs into that system as its own enforcement condition, so the correct question is not “Did GitHub add another check?” It is “Is the license ruleset set to Active, and does it require results before merging?”

If you are documenting this for your team, the safest wording is: GitHub license compliance can block merges now, but only when the ruleset is enforced. That sentence matches the current docs, avoids confusing evaluation with enforcement, and explains why one repository may only show a warning while another rejects the same dependency change outright.