GitHub has made shared policy checks for external library licenses, or terms of use, generally available to enterprises. Development teams can automatically check whether new or changed libraries in selected repositories meet enterprise criteria. Coding agents can also query compliance when recommending or adopting packages.
1. Scope and policy configuration
Announced on October 16, 2026, the feature targets GitHub Enterprise Cloud customers, including those using data residency. Target repositories must have GitHub Code Security enabled. It is now generally available after a June public preview.
The feature extends existing dependency review workflows with enterprise-wide license policies. Dependencies are external packages used by a project. Shared enterprise criteria are established and linked to repository-level checks.
To apply a policy, select target repositories through a ruleset that groups check requirements. Use Require license compliance results before merging. This connects to repository rules much like existing code scanning requirements.
2. Violation notices and dismissal request reviews
When a developer opens a pull request adding or modifying dependencies, their licenses are checked automatically. Each noncompliant dependency triggers a message in the pull request, showing the developer which items need attention.
These messages must be addressed. The source lists removing or replacing the dependency, modifying the license policy, or creating a package exception as options. A violation notice does not necessarily mean abandoning the package.
A new predefined enterprise-level role is assigned to those reviewing and approving dismissal requests. Called Enterprise Open-Source License Manager, it can be assigned to individuals or teams. Reviewers receive email notifications of pending requests and can review them in the enterprise administration console.
3. Policy management and APIs for agents
Since the public preview, license information has also become available to customers using data residency. It appears in compliance checks, the dependency graph showing package relationships, and software bill of materials exports. A software bill of materials lists the components included in software.
License policy changes generate audit log events, recording changes for integration with external logging systems. APIs have also been added to download, update, or replace enterprise license policies.
A separate new package compliance API helps coding agents avoid recommending or introducing packages that violate enterprise license policies. Agents can use it to check policies during package selection, apart from pull request checks.
4. Separate automated checks from human judgment
The benefit is linking shared policies to repository change reviews. Checks can assess packages developers add or modify, but deciding whether to remove violations or change policies or exceptions remains. Automation benefits must be weighed against policy management and request review workloads.
When defining scope, distinguish enterprise-wide policies from repositories selected through rulesets. The source describes enabling checks for selected repositories, not automatic application across every repository in the enterprise.
The announcement links to detailed setup guidance and API documentation but provides no specific request or response formats or code examples. Consult those documents before deciding how to implement an integration.
The key change links license checks to shared enterprise policies and automation, rather than relying solely on developers' individual checks, while leaving policy changes and request approvals to designated reviewers.