Enforce License Checks Before Dependency PRs Merge

How do I enforce license checks before merging dependency pull requests

Use GitHub license compliance with an active ruleset, then require license compliance results before merging. GitHub evaluates pull requests that change package manifests, compares direct and transitive dependency licenses to your policy, and blocks merges when violations stay unresolved.

Start by defining the policy you actually want to enforce. GitHub lets you choose licenses from its built-in list or add SPDX identifiers manually, then apply that policy at the enterprise, organization, or repository scope. The policy belongs in the place where merge decisions are made, not in a separate spreadsheet that nobody checks.

Turn the policy on with ruleset enforcement, not evaluation only. In active mode, GitHub blocks a pull request that introduces a noncompliant dependency. In evaluate mode, GitHub only annotates the pull request, which is useful for rollout but does not stop a merge. Teams often stop at annotations and think they have a gate, then discover the merge button still works.

Make the ruleset check a merge requirement. GitHub documents a ruleset condition called “Requires license compliance results before merging,” and when that condition is active, noncompliant dependency pull requests stay blocked until the violation is resolved, approved as an exception, or the policy is changed. That is the actual enforcement point.

Scope the ruleset to the repositories where dependency changes matter. GitHub supports enterprise, organization, and repository scope, so you can start narrow and expand after you see how many pull requests fail. If your organization uses custom properties, GitHub can target repositories where a property value is active. If not, use repository patterns or explicit repository selection.

Keep dependency graph enabled on every repository you want checked. GitHub’s license evaluation uses dependency data from the repository, including transitive dependencies detected in the dependency graph. If the graph is missing or stale, the policy gate cannot judge what changed with confidence. That is the inconvenient part, because policy only works on data the platform can actually see.

Test the gate with a real pull request that changes a manifest. GitHub says to open a pull request, confirm that annotations show license compliance results, and then check whether a violating dependency is blocked. If the violation is unresolved, the pull request remains blocked. That test matters more than the policy screen, because the merge path is the thing you are trying to control.

Use exceptions sparingly and through the same policy system. GitHub supports package or license exceptions for approved cases, and Enterprise Open Source License Managers can review pending requests. That keeps the approval path visible, instead of letting someone bypass the gate by merging from memory, habit, or a quick chat in a side channel.

If you also rely on required status checks, make sure the workflow still reports on the events your merge path uses. GitHub notes that required checks must succeed on the latest commit SHA, and if you use merge queues you need the workflow triggered by merge_group as well as pull_request. A license gate that never reports is not a gate, it is a false sense of control.

Treat Dependabot pull requests the same way as human pull requests. GitHub’s dependency security features create update pull requests automatically, and those PRs still need to pass whatever branch protection or ruleset you enforce. That matters because dependency updates are exactly where license drift enters a codebase. The check should run before the merge, not after the release note.

A practical setup looks like this: define an allowlist of licenses your legal or platform team accepts, enable the policy in active mode, require license compliance results before merging, and confirm a violating test PR is blocked. Then document the exception process beside the policy so reviewers do not invent one on the fly. GitHub explicitly says to check with your organization’s legal team for policy guidance.

The part people get wrong is assuming dependency review and license compliance are the same control. Dependency review is used to surface dependency changes and can block vulnerable dependencies, while license compliance is the specific policy gate for allowed licenses. If you want to stop merges on license terms, enforce the license policy itself, not just a generic dependency scan.

Another common mistake is checking only direct dependencies. GitHub’s license compliance evaluation includes transitive dependencies, which is where many surprises live. A direct package may look fine, while one nested package brings in an unacceptable license and blocks the pull request when the policy is enforced.

If you do not use GitHub for enforcement, put the same rule into CI and then make the branch protection depend on that CI result. The control still needs to be a required check before merge, and it still needs to run on pull requests and merge-queue events if you use them. The implementation changes, the control point does not.

If your team needs a place to coordinate testers, jobs, or dependency review work without turning it into spam, DevConnect keeps that exchange on owned property and stays free to use: https://devconnectplatform.com. It is not the enforcement system, it is only a place to organize the work around it.

Once the gate is live, watch for two failure modes. One is a PR that looks blocked but is only annotated, which means the ruleset is not in active enforcement. The other is a required check that never appears, which usually means the workflow is not triggered on the event the merge path uses. Both are configuration mistakes, not policy exceptions.

The goal is simple: a dependency pull request should not merge until its license has passed your policy or received an approved exception. GitHub’s active ruleset enforcement does exactly that when it is configured on the right repositories, with the right policy, and with the right merge checks wired in.

FAQ

Can I block only certain licenses and allow the rest Yes. GitHub license compliance policies let you define which licenses are allowed, including built-in licenses and SPDX identifiers. Pull requests that introduce disallowed licenses are blocked when the ruleset is enforced.

Do transitive dependencies get checked too Yes. GitHub says license evaluation includes direct and transitive dependencies from the dependency graph, so nested packages can fail a pull request even when the top-level package looks acceptable.

Is annotation enough to stop a merge No. Annotation shows the result, but active ruleset enforcement is what blocks the merge. Evaluate mode is for visibility and rollout, not for prevention.

What if we use a merge queue Your required checks still need to run in the merge queue path. GitHub says workflows that back required checks should include the merge_group event, or the merge can fail because the check never reports.

Can I use a generic dependency scan instead Yes, but it answers a different question. Dependency review and code scanning help with vulnerable dependencies and other security issues, while license compliance enforces allowed license policy before merge. If license terms matter, make that the required check.

What happens when a violation is real GitHub keeps the pull request blocked until the issue is resolved, an exception is approved, or the policy changes. That is the point of enforcing the check before merge instead of after release.