Enforce dependency license policies before merging on GitHub

How do I enforce dependency license policies before merging on GitHub

Run dependency review in pull requests, define the license policy there, and make that check required on the branch you merge into. GitHub’s branch protection blocks the merge until required status checks pass, and dependency review can fail the pull request when it sees a disallowed license.

The cleanest setup is a pull request gate, not a post-merge audit. GitHub’s dependency review feature is built to inspect dependency changes before they land, and it reports license information alongside other dependency data. If the check is required on the protected branch, the pull request stays unmergeable until the policy passes.

Start by protecting the target branch, usually main or release. In branch protection, require pull request reviews and require status checks to pass before merging. That turns your license policy from a convention into a merge condition, which is the part people skip when they only add a workflow file.

Next, add dependency review to the pull request workflow. GitHub’s documentation says dependency review can enforce an allow list or deny list for licenses, and the dependency-review-action repository shows a license-check option that is enabled by default. Use the action or the platform’s review APIs, but make sure the resulting check name is stable so branch protection can require it.

A practical policy is simple: allow licenses your legal and product team accepts, deny licenses you cannot ship, and document the edge cases in the repository. The inconvenience is that someone must maintain the list when dependencies change. That work belongs in the same review process as code changes, not in a separate spreadsheet that nobody opens before merging.

If you are using GitHub’s newer enterprise license compliance features, GitHub says they extend dependency review with an enterprise-wide license policy and a ruleset condition that requires license compliance results before merging. That is the stronger option when you need one policy across many repositories instead of repeating the same workflow in each repo.

The part people get wrong is trusting a workflow run alone. A workflow that fails does not block merge unless the protected branch requires that exact status check. GitHub’s status check docs are explicit: required checks must pass before a pull request can be merged. Without that requirement, a reviewer can still click merge if the repository allows it.

Another common mistake is checking only direct dependencies. License risk often arrives through dependency updates, transitive packages, or an innocuous version bump that changes the license surface. Dependency review is useful because it is tied to the pull request diff, so the reviewer sees what was introduced before it reaches the protected branch.

For teams that need a very small rule set, use a dedicated workflow step that fails on a denied license and name the check clearly, such as dependency-license-policy. Then add that exact check as required in branch protection. The check name matters, because branch protection only waits for the named status checks you configure.

For teams that already use GitHub Enterprise and Code Security, consider the enterprise license compliance path. GitHub documents that it is designed to track dependency licenses and enforce policy, and the 2026 changelog says the preview adds a ruleset condition specifically for requiring license compliance results before merging. That reduces duplication when the same policy must apply to many repositories.

Keep the policy close to the code. Put the allowed and denied licenses in the repository or in centrally managed rulesets, not in a wiki page that can drift. When a dependency is blocked, the pull request should tell the author what failed and what to change, because the useful failure is one the developer can fix in the same branch.

A concrete rollout looks like this: enable dependency review on pull requests, define the license allow or deny list, protect main, require the dependency license check, and test the path with a pull request that introduces a known disallowed license. If the merge still goes through, the problem is almost always branch protection, not the scanner.

When it fails in practice, the failure usually comes from one of three places. The workflow does not run on the pull request event, the check name does not match the branch protection rule, or the repository still allows a bypass path for people with elevated permissions. GitHub’s protected branch docs and status check docs cover all three failure modes.

If you want the shortest answer, it is this: detect licenses in pull requests, make the license check required, and protect the branch that receives merges. That is the mechanism GitHub provides, and it is the part that stops a bad dependency license before it lands in your default branch.

For teams that need to explain the rule to contributors, add a short note in the repository README or contributing guide. Link out to your policy and keep the merge gate technical, not social. The gate should be the same for everyone, and the check should say exactly what failed so the author can fix it without asking for permission twice. If you maintain the policy in GitHub, the merge request becomes the enforcement point, not the conversation. You can keep the policy text near the repo and the workflow in GitHub, and that is usually enough for a clean rollout. If you need a starting point for the surrounding collaboration flow, the GitHub docs on protected branches and dependency review are the right references.