GitHub License Compliance vs Dependency Review Action: What Changes?
Your workflow already blocks dependencies with disallowed licenses. When a team needs an exception, who approves it, and does GitHub’s new feature change that?
- Dependency Review Action already supports license checks and shared configuration files.
- The newer feature connects enterprise policy, branch rulesets and a dedicated exception-review role.
- Evaluate mode does not itself block merging, but existing comment-resolution protection can still matter.
The difference is how policy and approvals are managed
You do not need the newer feature merely to start checking dependency licenses. Dependency Review Action already supports an allowed-license list, package exclusions and configuration files referenced from another repository.
GitHub’s October 16 general-availability release adds a dedicated enterprise policy and exception process. Administrators define a common baseline, target repositories through rulesets and assign reviewers who can approve exceptions.
| Decision | Dependency Review Action | License compliance |
|---|---|---|
| Where policy is configured | Workflow options or a referenced configuration file | Enterprise policy with scoped exceptions |
| How checks apply | A GitHub Actions job checks dependency changes | A branch ruleset requires license compliance results |
| How exceptions are handled | Options can exclude packages from license checks | A designated manager reviews requests and chooses their scope |
One detail matters when reusing an older Action configuration: its current README marks deny-licenses as deprecated for possible future removal. It also cannot be combined with allow-licenses. Check the current options rather than copying an old example unchanged.
The new feature has enterprise and repository requirements
License compliance is available to GitHub Enterprise Cloud customers, including data-resident deployments. The repository where policy is enforced needs a GitHub Code Security license.
The setup guide also requires an enabled dependency graph and access to manage enterprise policy and rulesets. Under the enterprise’s Policies → License compliance → Default policy, administrators select permitted licenses or enter SPDX identifiers.
When a PR changes package manifests, GitHub compares dependencies between its base and proposed branches. Evaluation includes transitive dependencies detected in the dependency graph. Choosing a LICENSE file for your own repository is a different task from accepting the licenses of packages it consumes.
Evaluate mode still interacts with other merge rules
An Active ruleset using Require license compliance results before merging blocks a PR until policy violations are resolved. An Evaluate ruleset runs checks and annotates the PR without imposing that merge block itself.
However, GitHub’s enforcement documentation says branch protection that requires comment resolution also tracks license-check annotations. Evaluate mode therefore does not guarantee that existing merge requirements will be unaffected.
For staged adoption, repository custom properties can identify rollout stages, with separate Evaluate and Active rulesets targeting them. Test a PR that changes dependencies and inspect both the annotations and whether it can merge.
A finding is not an automatic exception request
A developer can remove or replace a dependency that violates policy. If the dependency is needed, the developer supplies information for an exception request; the annotation does not submit that request automatically. Updating the permitted policy is another resolution path where appropriate.
An Enterprise Open-Source License Manager reviews the request and can choose a package, license or package-pattern exception at repository or enterprise scope. Approval closes the relevant alert, but another failing required check can still prevent the PR from merging.
The Action remains an option when workflow configuration and code review provide the policy management you need. The newer feature is a closer fit when multiple repositories need a dedicated approval process and an audit trail for enterprise policy changes. Decide on those operational requirements, rather than assuming license checks are available only through the newer product.