By ByteBot
GitHub shipped Open Source License Compliance into public preview on June 30 — three days ago. It scans every pull request for dependency license violations, and if your enterprise enables Active mode, it blocks the merge until the issue is resolved. This is the first native, enterprise-wide license policy enforcement built directly into GitHub’s PR workflow, and it matters: the 2026 OSSRA report found that 68% of commercial codebases already contain license conflicts — the highest rate in that report’s history — and most teams won’t find out until an M&A deal unravels or a lawyer walks in.
The Part Most Teams Will Miss: Transitive Dependencies
The scanner doesn’t just check what you added to package.json or requirements.txt. It evaluates the full dependency graph — direct and transitive. A GPL-licensed library buried three levels deep in a dependency you pulled in can flag your PR even though you never consciously chose GPL software.
This is the silent killer. Most license violations in enterprise codebases come from transitive dependencies the team never audited. When GitHub’s compliance check comments on your PR, it shows the full path through the dependency tree — so you can see exactly how the noncompliant license got in. That changes the conversation from “who broke this?” to “which dep do we swap?”
Two Modes: One for Learning, One for Enforcing
GitHub ships the feature with two enforcement modes, and the distinction matters a lot for how you roll it out.
Evaluate mode annotates pull requests with license alerts but doesn’t block merges. Developers see the problem and can choose to act. This is the right starting point — you’ll quickly discover whether your existing policy covers common edge cases or whether you’ve accidentally blocked Apache 2.0 somewhere.
Active mode blocks merges on noncompliant licenses. No approved exception means no merge. Turning this on without first running in Evaluate mode is a reliable way to halt your team’s velocity while you sort out the policy gaps.
GitHub recommends starting in Evaluate, which is sound advice. Run it for a few weeks, review what gets flagged, update your policy, then flip to Active once you have a realistic picture of your dependency landscape.
The Exception Workflow Is New Process Overhead
When a dependency is flagged, developers have two choices: swap the dependency, or submit an exception request. Exception requests go to an Enterprise Open Source License Policy Manager — a new predefined enterprise role GitHub is introducing alongside this feature.
The manager decides whether to permit the license enterprise-wide or just for a specific repository. This is correct governance, but it also introduces a bottleneck. If your organization doesn’t have a designated OSPO or someone with the legal knowledge to evaluate license risk, exception requests will pile up and block developer work.
Assign the role before you enable the feature. Don’t make it one person.
The Uncomfortable Part: The GHAS Paywall
License Compliance requires a GitHub Advanced Security Code Security license: $30 per committer per month, on top of GitHub Enterprise Cloud. The free Dependency Review Action provides some license visibility but no centralized policy enforcement and no enterprise-wide rollout.
The companies most exposed to license risk — startups moving fast, small shops where no one’s auditing the dep tree — are the ones least likely to have GHAS. OSSRA’s data on license conflicts doesn’t sort by company size. The risk is distributed; the protection isn’t.
That’s a real limitation. GitHub will likely expand License Compliance to lower tiers eventually — it’s the pattern with GHAS features — but for now, if you’re not on Enterprise Cloud with an active Code Security license, the best you can do is run the Dependency Review Action manually and handle policy enforcement yourself.
How to Prepare Right Now
If you have GHAS and want to move quickly, here’s the practical path:
- Seed your policy with permissive licenses: MIT, Apache 2.0, and BSD-3-Clause are the uncontroversial starting point. Add from there based on what your real PRs flag.
- Assign the Enterprise Open Source License Policy Manager role before enabling the feature. Ideally this is a team, not one person.
- Enable Evaluate mode first. Run it for two to four weeks. You’ll probably find GPL or LGPL in transitive deps you didn’t know about.
- Audit your copyleft exposure before switching to Active. AGPL in particular has strict network-access obligations — if you’re running AGPL software as a service, you may need to publish modified source code.
- Plan the exception workflow. Who reviews requests? What’s the SLA? A blocked PR waiting on a license exception is a developer experience problem.
The Verdict
License compliance at the PR gate is the right place to catch this problem. Waiting until M&A due diligence or a lawyer flags it is dramatically more expensive than a merge block. The feature itself is well-designed — the two-mode rollout, the transitive dependency visibility, the enterprise-wide policy management — this is what the Dependency Review Action should have been years ago.
The GHAS paywall is frustrating but not surprising. Enable it in Evaluate mode today if you have access. If you don’t, the Dependency Review Action is free and provides a starting point while you make the case for GHAS. Full documentation is available in the GitHub docs.
