GitHub's open-source license compliance feature lets eligible GitHub Enterprise Cloud teams check dependency licenses against a shared policy in pull requests. The official GitHub Changelog still labels the feature as a public preview in its June 30, 2026 announcement, so check the current documentation and account entitlements before planning a company-wide rollout. The practical goal is to surface a license conflict before a dependency becomes part of a released product.
Check prerequisites first
The published availability is GitHub Enterprise Cloud customers with GitHub Advanced Security Code Security licenses. Confirm that the repositories you want to protect are covered, that dependency data is available, and that the people who will own policy decisions have the required enterprise or repository permissions.
Before creating a blocking rule, review the existing dependency-review process and identify which repositories, package ecosystems and branches should be included. Start with a small group of repositories that represents your main languages and build workflows. Do not assume that a detected license label answers every legal question about a package.
Define a policy that people can maintain
Use the supported license identifiers and policy options described in the current GitHub documentation. Keep the policy focused on the licenses your organization accepts, the licenses that need review, and the path for an exception. Assign an owner for policy changes and a separate review path for exceptions where your governance requires it.
Write down why each restriction exists. A rule that is impossible to explain will be hard for developers to follow and difficult to maintain when a package changes license or a new dependency is introduced. Keep the baseline as consistent as possible across repositories, then document the cases that need special handling.
Apply the policy through rulesets
GitHub's license-compliance check is connected to repository rulesets. Scope the ruleset to the repositories and branches where you want dependency checks to run, then add the license-compliance condition supported by the feature. Read the current GitHub documentation for the exact controls available in your account; preview features can change their interface and scope during rollout.
Where the ruleset supports an evaluation-only mode, use it before active enforcement. Review the pull-request annotations and check whether the findings reflect a real policy conflict, missing metadata or a package that needs an exception. Do not turn on merge blocking until the owners understand the results.
Test the workflow with a real pull request
- Choose a test repository. Use a non-critical repository with a normal dependency update process.
- Open a dependency-change pull request. Add or update a package with a known license from your approved test set.
- Check the result. Confirm that the rule runs, the pull request shows the expected status, and the package and license information are understandable.
- Test a policy conflict. Use a package that your test policy marks for review, then confirm the documented review or exception path.
- Verify the merge decision. Confirm that evaluation mode reports findings and that active enforcement blocks only the changes covered by the policy.
Keep a record of the repository, policy version, package, result and reviewer decision. This makes it easier to distinguish a policy problem from missing dependency data or a configuration error.
Make exception handling explicit
A package exception should have a reason, an owner, an approval and a review date where your process requires one. Limit exception permissions to people who can assess the trade-off. If the package is needed for a short-term migration, document that context instead of silently adding it to the global allowlist.
GitHub's preview includes an enterprise role for managing license-policy exceptions. Review the current role description before assigning it, and keep audit records of policy changes. Auditability helps explain who changed a control; it does not make the underlying legal interpretation correct.
Understand the limits
Automated license detection depends on the package metadata and dependency information available to GitHub. A detected license is a useful signal, but it cannot determine every obligation that may arise from modifying, linking, distributing or using a package in a particular product. Escalate ambiguous cases to your open-source program or legal team.
Also separate license policy from vulnerability scanning. A package can have an acceptable license and still contain a security flaw; a package with no known vulnerability can still violate a licensing rule. Use this control alongside dependency review, code scanning and your normal security review process.
For another part of GitHub's security workflow, see our overview of Agentic Autofix for code scanning. It addresses code-scanning alerts rather than dependency-license policy, so the controls complement rather than replace one another.
Sources
- GitHub Changelog: Open source license compliance is in public preview, June 30, 2026.
- GitHub Docs: About open-source license compliance.