Why license hygiene matters at GitHub scale
GitHub’s own engineering work — internal apps, platform code, and open source projects — runs on a huge volume of third-party dependencies. Every new dependency carries a license that defines what you may do with it, from simple attribution requirements to full source redistribution. A commercial, closed source product may need to steer clear of copyleft licenses, while an open source release might need to avoid commercial terms altogether.
Failing to respect those obligations can force expensive rewrites, trigger litigation, and damage reputation. Traditionally that review is a manual grind or relies on third-party tooling. GitHub’s License Compliance feature, available to GitHub Advanced Security customers, moves the check into the pull request itself, flagging new dependencies whose licenses don't match your policy while still allowing the policy to evolve.
GitHub’s Open Source Program Office (OSPO) spent two months migrating from the internal-only compliance tools it had built to this new product, giving feedback along the way to ensure it could stand up to the demands of large, fast-moving enterprises with complex compliance requirements.
Seeding the policy and rolling it out
Because GitHub already had internal license compliance tooling, the OSPO had a ready-made list of acceptable licenses to seed the initial policy. Common permissive licenses — MIT, Apache 2.0, BSD-3-Clause — are a solid starting point, as they cover most dependencies. The team first deployed the feature in Evaluate mode on an organization-wide ruleset, which produces annotations on pull requests without blocking merges. That let developers get used to the workflow without friction, while running the old and new tools in parallel to check for behavioral differences.
After about a month, alerts were mostly limited to packages with unusual, missing, or explicitly disallowed licenses, at which point the OSPO could trust the new checks in Active mode.
How the checks flow
License compliance is enforced via rulesets. Repositories are targeted through a custom property whose value toggles enforcement between Active and Evaluate modes. When a pull request in a targeted repository changes dependencies, a scan looks up the licenses of every new direct and transitive dependency. Permitted licenses and package exceptions pass silently; failures generate a comment on the pull request listing each problematic package.
Developers can respond to alerts in two ways. If the dependency is unacceptable, they edit the code or close the pull request. If they think the license or package should be allowed, they raise an exception request that notifies the organization's dedicated policy team for a decision.
The policy review team in practice
GitHub’s license policy team is made up of OSPO members and engineers with supply chain and license review expertise. Because the company is global, reviewers are spread across time zones to keep turnaround fast. An SLA for review requests is being formalized, but in practice triage usually takes no more than a few hours. Team members get email notifications for new requests and can see the full backlog on a dashboard.
Approvals involve two decisions: whether to permit the license or package, and whether that permission applies at the enterprise or repository scope. A safe license that simply hasn't appeared before gets added at the enterprise level, making it allowed everywhere at GitHub. A commercial license that a specific team has paid for cannot be authorized broadly, so that exception is scoped to the relevant repository. Package exceptions are especially useful for internal software that typically has no license metadata at all. The tool also supports wildcards, which is how the team permitted everything in the @github-ui/* React namespace without approving each package separately.
Keeping developers unblocked
The OSPO has documented how to contact them and set up an emergency break glass override process for critically time-sensitive pull requests. Because enforcement is tied to a ruleset that keys off a custom property, flipping the property value can suspend license checks temporarily to let a critical fix through. That option has only been needed once so far, but it was valuable when required.
Internal documentation and training emphasize why license compliance matters and reinforce that it is everyone's responsibility — with the policy team making the process as easy as possible.
A supply chain safety net
License compliance is a core part of securing the software supply chain. Catching issues at dependency selection time prevents costly rework and legal exposure later. GitHub has been testing and providing feedback on License Compliance for several months and is now watching wider adoption as the feature reaches public preview. Enterprise Cloud customers with an active GHAS Code Security license can use the feature across repositories.
