By ByteBot
GitHub shipped open source license compliance as generally available on October 16 for Enterprise Cloud customers — and unlike most “compliance” features, it doesn’t just warn you. In Active mode, pull requests that add dependencies with prohibited licenses are blocked from merging entirely. The feature graduated from public preview (launched June 30) with four significant additions: audit log events, new REST API endpoints, data residency support, and a dedicated Enterprise Open-Source License Manager role.
The License Drift Problem Has Been Getting Worse
The 2026 OSSRA report found that 68% of audited commercial codebases contain license conflicts — the highest figure ever recorded. That’s not a statistic to skim past. GPL and AGPL don’t just create compliance paperwork; they can force code disclosure, collapse acquisition deals, and expose engineering teams to legal liability that legal teams only discover after the damage is done.
For SaaS companies specifically, AGPL is the real landmine. Unlike GPL, which triggers copyleft obligations on binary distribution, AGPL triggers them when users access software over a network. That’s every SaaS product. A single AGPL transitive dependency buried four levels deep in your package tree can compromise your entire codebase’s licensing position.
Until now, teams enforcing license policies at scale had two choices: maintain per-repository dependency review action YAML files (brittle, inconsistent), or pay for third-party tools like FOSSA, Black Duck, or Snyk License. GitHub’s new feature folds that enforcement into the platform natively, with no separate tool to manage.
How It Works: Policy Meets the Merge Gate
The mechanism is straightforward. When a developer opens a pull request that modifies package manifests, GitHub evaluates the licenses of every new or changed dependency — both direct and transitive — against your enterprise policy. If a dependency fails the check, the PR is annotated. In Active mode, it’s blocked until the violation is resolved.
Resolution options: remove or replace the noncompliant dependency, amend the enterprise policy to allow that license, or add a package-level exception for a deliberate deviation. That last option matters — sometimes you need a GPL package and you know it. The exception system gives you the safety valve without loosening the entire policy.
The recommended onboarding path is Evaluate mode first. It runs the full check and annotates PRs but doesn’t block anything. Use it to measure how many of your current dependencies would fail, tune your policy, then flip to Active once the numbers look reasonable.
| Feature | Dependency Review Action | New License Compliance |
|---|---|---|
| Policy scope | Per-repo YAML | Enterprise-wide centralized |
| Merge blocking | Via Actions workflow | Native merge gate |
| Audit logging | No | Yes |
| API management | No | Yes |
| Data residency | No | Yes |
What’s New at GA
The June preview was functional but limited. Four additions shipped with the GA:
- Data residency support: License data is now available for GHEC data residency customers — a prerequisite some enterprises couldn’t work around until now.
- Audit log events: Policy changes emit structured events under the
license_compliance_policyprefix, streamable to your SIEM of choice. - REST API endpoints: Download, update, and replace your enterprise policy programmatically. There’s also a new check-a-package endpoint — more on that in the next section.
- Enterprise Open-Source License Manager role: A new predefined role for whoever reviews and approves exception requests, keeping that responsibility out of the full admin role.
The AI Coding Agent Problem Makes This More Urgent
Here’s the part of this story that doesn’t get enough attention: AI coding tools are now the primary vector for accidental dependency additions. Copilot, Claude Code, Cursor — all of them can suggest and scaffold code that pulls in packages the developer never consciously chose. The new check-a-package API endpoint exists specifically so those agents can verify license compliance before recommending a dependency, not after it’s already merged.
As agentic development grows, the surface area for accidental license violations expands proportionally. GitHub is threading compliance into the AI toolchain at the right layer — before the code gets written, not after. According to Black Duck’s open source license analysis, permissive licenses like MIT and Apache 2.0 are the safe defaults for commercial work, but AI tools don’t naturally discriminate between safe and risky picks.
Who Gets It and How to Start
The feature requires GitHub Enterprise Cloud with GitHub Code Security enabled. GitHub Enterprise Server is not supported yet — the API doesn’t return license data at that tier.
To enable: define your enterprise license policy, create a branch ruleset targeting your repositories, set the “Require license compliance results before merging” condition, and start in Evaluate mode. The full setup guide is in the GitHub documentation. When your policy looks stable and your team is prepared for the friction, switch to Active.
The friction is real and intentional. Active mode will block PRs developers didn’t expect to block. Brief your team before you flip the switch, make sure your exception workflow is in place, and treat the first week as calibration. The alternative — discovering a GPL violation during due diligence — is worse.
