// answer

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.

The harder question is who you do it with: Find collaborators

Do open source licenses now get checked before merging dependency pull requests on GitHub

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.

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 questions

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.

Know someone stuck on this? Send them the answer.

Sources

Every link here was fetched and confirmed to resolve before this page went live.

More on this topic: Open source

Related questions

Not the question you had?

Ask it. Every source gets fetched and checked before anything goes up, so it takes a day or two, and questions that cannot be answered honestly do not get a page at all.

No account, no email address needed.

Looking for someone to build it with?

People on DevConnect post what they are building and what they are missing. You can browse projects, or say what you want to work on and let people come to you.