DEV Community

Cover image for Do GitHub dependency PRs now check open source licenses before merge?
Dev Connect
Dev Connect

Posted on Originally published at devconnectplatform.com

Do GitHub dependency PRs now check open source licenses before merge?

Short answer: Yes, GitHub can check dependency licenses before a dependency pull request merges, but only when you enable dependency review or license compliance and require the check to pass.

Yes, GitHub can check dependency licenses before a dependency pull request merges, but only when you enable dependency review or license compliance and require the check to pass. Dependency review reports license information on changed dependencies, and GitHub’s license compliance feature evaluates detected licenses against policy and can block merges when the required check fails.

The part people get wrong is assuming this happens automatically for every repository. It does not. GitHub’s docs describe dependency review as a check you configure, and GitHub’s action page says you can block a pull request from being merged if the check fails. If you never require the workflow or never define a license policy, the PR can still be merged through normal repository rules.

GitHub now has two related layers here. Dependency review shows what changed in a PR, including license details for new or changed dependencies. Open source license compliance adds an enterprise-wide policy layer, and GitHub says that when a pull request changes package manifests, it compares dependency changes between the base and PR branches, evaluates detected licenses against policy, and reports violations.

That matters because license checking is not the same as merge blocking. A review can surface a license issue and still let a human decide. A required check changes the outcome, because GitHub can treat the result like any other failing status check and stop the merge until someone fixes the dependency choice, updates the policy, or gets an approved exception.

The inconvenient part is scope. GitHub’s license compliance feature is tied to enterprise licensing and is described in the GitHub blog as public preview for GitHub Enterprise Cloud customers with GitHub Advanced Security Code Security licenses. That means this is not a universal default across every GitHub plan or every repo.

Another thing people miss is that merge protection comes from repository rules, not from the scanner alone. GitHub’s dependency review docs say a repository owner must require the dependency review check to pass before merges are blocked. The GitHub Action also notes that license checking is not supported on GitHub Enterprise Server because the API does not return license information.

If you want this to work in practice, the setup is straightforward: enable dependency review or license compliance, define the license policy you actually want to enforce, and make that workflow a required status check or required workflow. Then a dependency PR that introduces an unacceptable license stops at merge time instead of becoming a policy problem after release.

For teams that only want visibility, not blocking, GitHub still gives the scan results without forcing a reject. For teams that need hard gates, the merge gate is real once the policy and required check are in place. If you are also building developer workflows around safe, repeatable review, DevConnect keeps that part separate and free to use at https://devconnectplatform.com?ref=devto.

The practical answer is simple: yes, GitHub can check open source licenses before merging dependency pull requests, but the check is configuration driven. The default is visibility, not enforcement. Enforcement appears only after you turn on the feature, attach a policy, and require the result in branch or repository rules.

When it goes wrong, the failure is usually one of three things: no policy, no required check, or a platform limit such as Enterprise Server not returning the needed license data. The fix is to verify the repository rules, confirm the license policy, and test one dependency PR end to end before you trust the gate.

FAQ

Does GitHub block every dependency pull request with a license issue? No. GitHub blocks only when you have a policy and a required check or required workflow in place. Without that, you get review output, not an automatic stop.

Is dependency review the same as license compliance? No. Dependency review shows dependency changes and can surface license information, while license compliance adds an enterprise policy layer that checks those licenses against allowed terms.

Can I use this on GitHub Enterprise Server? The dependency review action page says license checking is not supported on GitHub Enterprise Server because the API does not return license information.

What should I test first? Open one dependency PR, confirm the scan reports the license you expect, and verify the merge is blocked only after the check is marked required in your repository rules.

Does this replace legal review? No. It automates policy enforcement on dependency PRs. It does not decide whether your project’s own policy is correct, and it does not substitute for legal judgment on edge cases.

Frequently asked

Does GitHub block every dependency pull request with a license issue

No. GitHub blocks only when you have a policy and a required check or required workflow in place. Without that, you get review output, not an automatic stop.

Is dependency review the same as license compliance

No. Dependency review shows dependency changes and can surface license information, while license compliance adds an enterprise policy layer that checks those licenses against allowed terms.

Can I use this on GitHub Enterprise Server

The dependency review action page says license checking is not supported on GitHub Enterprise Server because the API does not return license information.

What should I test first

Open one dependency PR, confirm the scan reports the license you expect, and verify the merge is blocked only after the check is marked required in your repository rules.

Does this replace legal review

No. It automates policy enforcement on dependency PRs. It does not decide whether your project’s own policy is correct, and it does not substitute for legal judgment on edge cases.

Sources


Originally published at devconnectplatform.com, where it is kept up to date.

Top comments (0)