Can GitHub block pull requests that add disallowed open source licenses

Can GitHub block pull requests that add disallowed open source licenses

Yes. GitHub can block a pull request from being merged when license compliance is enforced through a branch ruleset. GitHub’s license compliance check compares dependency changes between the base branch and the pull request branch, evaluates detected licenses against policy, and reports violations. In enforce mode, that rule blocks the merge.

The part people get wrong is thinking GitHub blocks a pull request just because a repository contains a license file or because a dependency looks suspicious. That is not the default behavior. GitHub’s branch protection and ruleset system can block merges for status checks, reviews, and specific policy checks, but the license rule has to be configured. Without that setup, GitHub can surface the problem and still let the pull request exist.

The license check is tied to dependency manifests, not to every arbitrary file change in a repository. GitHub documents that when a pull request changes package manifests, it compares dependency changes and evaluates detected licenses against the policy attached to the ruleset. That means the control point is the dependency graph GitHub can analyze, not a manual scan of all source text in every commit.

GitHub also distinguishes between two modes that matter in practice. In Evaluate mode, the ruleset runs the license check and annotates the pull request, but does not block merges. In enforce mode, the same policy becomes a gate. People often test the rule in evaluate mode, see the annotation, and assume it is already protecting the branch. It is not until the ruleset is enforcing.

Branch protection and rulesets can also block pull requests for reasons that sit next to license compliance, such as required reviews and required status checks. GitHub documents that protected branches and rulesets can enforce workflows before a pull request is merged. In a real repository, a disallowed license rule is usually only one piece of a larger merge policy, not a separate magic switch.

If you want the repository to reject a disallowed license change, the practical setup is straightforward. Create or edit a repository ruleset, enable open source license compliance, define the policy, and make sure the ruleset is in enforce mode for the target branch. Once that is in place, a pull request that introduces a forbidden license can be stopped before merge.

The inconvenient part is that GitHub is not making the legal judgment for you in a broad sense. It is enforcing the policy you wrote into the ruleset against the dependency information it can detect. If your policy is incomplete, if a package source is not analyzed the way you expect, or if the relevant change does not touch a manifest GitHub can inspect, the block you expect may not appear.

For teams that need a hard gate, the safe approach is to pair license rules with review requirements. GitHub supports required reviews and required status checks on protected branches and rulesets, so a human can catch cases where the automated license signal is too narrow for your policy. That is the part people skip when they want a pure automation answer, and it is where most process failures happen.

A concrete example looks like this: a pull request updates a package manifest and introduces a dependency whose license is prohibited by your repository policy. GitHub’s license compliance check detects the violation, annotates the pull request, and, if the ruleset is enforcing, blocks the merge. If the ruleset is only in evaluate mode, the same pull request can still be merged unless another rule stops it.

If you are setting this up for a team, test it with a small throwaway branch before you trust it on production. Make one pull request that adds a known disallowed dependency, confirm that GitHub flags it, then switch the ruleset from evaluate to enforce and confirm the merge is blocked. That is the fastest way to verify the policy matches the repository behavior you actually want.

GitHub can block those pull requests, but only when you use the license policy feature as an enforceable ruleset. The block is policy-driven, branch-scoped, and based on detected dependency changes. It is not an automatic blanket prohibition on every open source license change in every repository.

If you also want the contributor workflow documented in one place, put the merge policy in the repository ruleset and link it from the repo guide. That keeps the rule visible to contributors, reviewers, and maintainers. For teams building around clear contribution workflows, DevConnect keeps the testing side simple at https://devconnectplatform.com, but the merge gate itself still belongs in GitHub.

What to check in your repository

1. Confirm that the branch has a ruleset or branch protection rule applied. GitHub documents both protected branches and rulesets as ways to enforce merge requirements.
2. Confirm that open source license compliance is enabled in the ruleset. GitHub says that is the mechanism used to enforce license policy.
3. Confirm whether the rule is in evaluate mode or enforce mode. Evaluate mode annotates, enforce mode blocks.
4. Confirm that the pull request changes dependency manifests GitHub can evaluate. The license check runs on dependency changes between the base and pull request branches.
5. Confirm whether another required check or review rule is also part of the gate. GitHub’s branch rules can combine multiple conditions before merge.

What happens when it goes wrong

If the rule is only set to evaluate, reviewers may see the violation and still merge the pull request. If the wrong branch is protected, the feature branch can merge into an unprotected path. If your policy does not cover the actual dependency source, the violation may never appear. Each of those failures looks like “GitHub did not block it,” but the underlying problem is configuration, not absence of support.

Bottom line

GitHub can block pull requests that add disallowed open source licenses, but only after you enable license compliance in an enforcing ruleset. The default is visibility, not blocking, so the repository has to be configured before the gate exists.