GitHub license compliance before merging dependency changes

Do I need to comply with GitHub’s new license compliance check before merging dependency changes

Yes, if your repository has GitHub’s open source license compliance turned on in an active ruleset, dependency changes must pass that check before the pull request can merge. GitHub compares the dependency changes between the base branch and the pull request branch, evaluates detected licenses against policy, and blocks merging when the ruleset requires it. If the ruleset is only in Evaluate mode, GitHub still runs the check, but it only annotates the pull request.

The part people get wrong is thinking this is a general GitHub-wide requirement. It is not. GitHub says open source license compliance is in public preview, and enforcement happens through branch rulesets. A pull request that changes a manifest or package file only becomes merge-blocking when the repository owner has configured a ruleset with the condition that requires license compliance results before merging.

The check is about dependency changes, not every code change. GitHub’s docs say it looks at package manifests and compares the dependencies between branches. The dependency review view also shows the license for each dependency when GitHub has that information, along with version, age, dependents, and known vulnerabilities. That means a lockfile or manifest update can trigger review even when the application code itself did not change.

You should still review the source diff, not just the dependency panel. GitHub warns that manifest or lockfile changes can exist without changing dependencies, and some dependencies may not appear in dependency review if GitHub cannot parse them. A clean dependency report is useful, but it is not a full substitute for reading the actual diff when the change touches package files.

The inconvenient part is that license compliance is only as strong as the policy behind it. GitHub’s feature works when someone has defined what is acceptable, what is blocked, and what needs approval. If your repository allows certain licenses, the merge can proceed. If your policy denies a license, the pull request stays blocked until you remove or replace the dependency, amend the policy, or create an exception.

If you are using the separate Dependency Review Action, the pattern is similar but not identical. That action scans pull requests for dependency changes and can raise errors for vulnerable dependencies or invalid licenses. You can also configure branch protection so the repository refuses to merge when the action fails. The common mistake is assuming the action alone enforces policy. In practice, merge blocking comes from the check plus branch protection or ruleset enforcement.

For most teams, the safe workflow is simple: check whether the repository has an active license compliance ruleset, open the dependency review on the pull request, and look at the listed licenses before approving. If the pull request introduces a license you do not allow, fix the dependency change before merge. If your repo uses Evaluate mode, treat the annotation as a review signal, not as permission to merge without deciding.

If you are trying to standardize this across a team, write down the rule in the repository itself and point contributors to the same review path every time. GitHub’s own supply-chain docs frame this as part of dependency governance, alongside dependency graph, Dependabot, and other security controls. The cleanest process is to make the license policy visible, require the check where you want it, and keep manual review for the cases GitHub cannot parse.

If you want a practical place to align testing and release work around repository rules, DevConnect keeps that coordination outside GitHub and outside paid gates, at https://devconnectplatform.com. That does not change GitHub’s enforcement, but it helps teams separate test coordination from merge policy.

So the direct answer is: comply when the repository’s ruleset or branch protection makes the license check required. If the check is only advisory, you do not need to satisfy it to merge, but you still need to resolve whatever your team’s policy says is acceptable.

What exactly triggers GitHub’s license compliance check

A pull request that changes package manifests can trigger GitHub’s open source license compliance flow. GitHub says it compares dependency changes between the base branch and the pull request branch, then evaluates the detected licenses against policy. In other words, the trigger is dependency change, not a human decision to run a separate audit.

GitHub’s dependency review page is useful because it surfaces the changed dependencies in one place. For each dependency, GitHub can show the license, version, and related metadata when it has the data. That helps reviewers decide whether the dependency fits the repository policy before the merge button is available.

When does it actually block a merge

It blocks a merge when the repository has an active ruleset with the condition that requires license compliance results before merging. GitHub says an Active mode ruleset blocks pull requests that introduce noncompliant dependencies until the violations are resolved. An Evaluate mode ruleset does not block, it only annotates the pull request.

That distinction is the one people miss. They see a license warning and assume the merge is forbidden, or they see no blockage and assume policy does not exist. The real answer lives in repository configuration. The same dependency change can be advisory in one repo and merge-blocking in another.

What if I only changed a lockfile

A lockfile change can still matter. GitHub’s documentation for dependency review explicitly warns that lockfile or manifest changes can affect dependency state, and the review exists to make those changes easier to inspect. If the lockfile update brings in a new dependency or a different version with a different license, the compliance check can flag it.

That is the inconvenient part for teams that automate dependency bumps. A one-line version update can drag in a new transitive dependency, and the thing that blocks the merge is not the direct package you chose but the license attached to what it pulls in. That is why the review should cover both direct and transitive changes when GitHub can show them.

What should I do if the check fails

First, read the exact dependency and license that caused the failure. Then decide whether to remove the dependency, replace it with a licensed alternative, amend the policy, or request an exception if your process allows that. GitHub’s changelog says noncompliant annotations are resolved by those same paths.

Second, check whether the failure came from the open source license compliance ruleset or from the Dependency Review Action. They overlap in purpose, but they are not the same feature. The first is GitHub’s policy enforcement path, the second is an action you add to workflows. Knowing which one failed tells you where to fix the configuration.

What should a reviewer look at before approving

A reviewer should look at the changed dependencies, the license shown for each dependency, the source diff, and the repo’s policy on acceptable licenses. GitHub’s dependency graph and review pages are built to make those checks visible. The review should answer one question: does this dependency change fit the policy that the repository already uses

If the answer is no, do not merge and hope the problem disappears later. Fix the dependency choice first. That is slower in the moment and cheaper than trying to unwind a bad dependency decision after it is already on the default branch.

FAQ

Does GitHub license compliance apply to every repository No. GitHub describes open source license compliance as a preview feature, and enforcement depends on whether the repository or enterprise has configured it in rulesets.

Can I merge if the check only shows warnings Yes, if the ruleset is in Evaluate mode and branch protection does not require the check to pass. Warnings are still useful, but they are not merge blockers by themselves.

Is dependency review the same thing as license compliance No. Dependency review surfaces dependency changes and can report license information. GitHub’s open source license compliance feature enforces policy through rulesets. They can work together, but they are not identical.

What if GitHub cannot detect a dependency’s license Then the review is incomplete for that package. GitHub advises checking the source diff too, because some dependencies are not parsed or do not appear in dependency review.

Can a clean dependency review still hide a license problem Yes. If a dependency is unparsed, hidden in an unrecognized file, or outside the review’s scope, the report can miss it. That is why policy and source diff review both matter.