GitHub's open-source license compliance feature is now generally available for GitHub Enterprise Cloud, including data-resident Enterprise Cloud, when GitHub Code Security is enabled for the repository. It turns license review from a late inventory task into a pull request decision.
The useful part is not a longer list of detected licenses. It is the enterprise-wide policy and ruleset connection. When a pull request adds or changes a dependency, GitHub can check the license against your policy before the change merges, while still giving teams a path to review and approve exceptions.
How the merge check works
The policy is activated through a ruleset condition called Require license compliance results before merging. Target the ruleset at the repositories that need the policy, then let GitHub evaluate each new or changed dependency in pull requests.
A noncompliant dependency is annotated in the pull request. The annotation is a decision point, not an automatic license verdict for the whole project. The team can remove or replace the dependency, amend the license policy, or create a package exception when there is a documented reason to allow it.
That gives developers feedback while the dependency change is still small. It also prevents a common failure mode where a security or legal team discovers a license problem months after the package became part of several releases.
Give policy decisions a real owner
GitHub adds a predefined enterprise role named Enterprise Open-Source License Manager. Assign it to the people or teams who review and approve closure requests. Policy managers receive email notifications for pending requests and can review them from the enterprise console.
Do not make the repository author the only license authority. A developer can explain why a package is needed, but the exception decision should be reviewable and owned by the group responsible for the organization's license policy.
Set an expiry or review date for exceptions in your own system of record, even if the GitHub policy stores the active decision. Packages change ownership, versions, and transitive dependencies. An exception that was reasonable for one release may not be reasonable forever.
Start with a narrow policy
Do not begin by blocking every license you have not classified. That turns the first rollout into a repository-wide queue and encourages emergency exceptions. Start with a short list of licenses or expressions that your legal and security teams already know how to evaluate.
Apply the ruleset to a representative set of active repositories. Include different languages, package managers, and release paths. Run the result in evaluate mode if your ruleset workflow supports it, classify the findings, and only then make the merge condition blocking.
Record the policy's scope, owner, approved license expressions, exception process, and escalation path. Developers should be able to answer “What should I do when this check fails?” without opening a separate investigation just to find the right team.
Use the new audit and API signals
License policy changes now emit audit log events. Send those events to the same system that tracks other security and governance changes, then correlate them with the actor, policy version, repository scope, and approval reason. A policy that changes silently is difficult to defend during an incident or an audit.
GitHub also provides API endpoints for downloading, updating, and replacing the enterprise license policy. Use them to keep a versioned copy of the policy in your normal change process. Review the policy as code, but do not put credentials or sensitive legal notes in the repository.
There is also an endpoint for checking whether packages comply with the policy. That is useful for internal developer tools and coding agents that want to avoid recommending a package that violates the organization's rules before it reaches a pull request.
License data is part of your dependency inventory
For GitHub Enterprise Cloud data-residency customers, license information now also populates the dependency graph and Software Bill of Materials exports. That makes the same license data useful outside the merge check, including procurement reviews, release inventories, and incident response.
Keep the sources separate in your mental model. A dependency graph tells you what the repository uses. An SBOM gives you an exportable inventory. The license policy says what your organization allows. A pull request check connects the policy to a change before it merges.
A practical rollout checklist
Name the policy owner and the people who can approve exceptions.
Start with a small approved-license set and a representative repository scope.
Run the ruleset, classify existing findings, and define the exception path before blocking merges.
Version the policy changes and forward audit events to your governance system.
Review exceptions on a schedule and compare dependency graph, SBOM, and pull request results.
What this does not replace
License compliance does not replace dependency review, vulnerability scanning, provenance checks, or legal review for unusual packages. A package can have an acceptable license and still be risky, abandoned, compromised, or incompatible with your product. Use the policy to answer one important question well, then keep the other supply-chain checks in place.
GitHub's license compliance announcement has the availability and feature details. The GitHub Docs setup guide covers the policy and ruleset flow, and the dependency graph API reference lists the programmatic endpoints.
The best time to review a dependency license is before the dependency becomes a release problem. Start with a narrow policy, connect it to a ruleset, give exceptions a clear owner, and keep the policy versioned and observable. That is enough to make license decisions part of normal development instead of a separate emergency process.