What GitHub open source license compliance means

What is GitHub open source license compliance

GitHub open source license compliance is a policy system for dependency licenses. It lets an enterprise define which open source licenses are allowed in repositories, then checks pull requests against that policy before changes merge. GitHub documents it as a way to track dependency licenses and reduce legal and operational risk in the software supply chain.

The practical job is simple: GitHub reads dependency data from your repository, including transitive dependencies, compares detected licenses to the allowed set, and reports violations. If a pull request changes package manifests and introduces a disallowed license, the merge can be blocked or annotated depending on the ruleset mode.

This feature is for organizations owned by a GitHub Enterprise account with GitHub Code Security enabled. GitHub also says the feature is in public preview and subject to change, so teams should treat the exact workflow as product behavior, not a permanent legal process.

The part people get wrong is thinking license compliance is the same as adding a LICENSE file to the repo. A repository license tells other people how they can use that project. License compliance checks the licenses of the packages your project consumes, which is a different problem. GitHub’s own docs separate repository licensing from dependency license policy.

The policy starts at the enterprise level. GitHub lets you choose permitted licenses from a built-in list, or add a SPDX license identifier if the license is not listed. SPDX exists to standardize license identifiers, which makes compliance checks more reliable across tools and repositories.

In GitHub, enforcement happens through rulesets. A ruleset in Active mode with the condition “Requires license compliance results before merging” blocks pull requests that introduce noncompliant dependencies. An Evaluate mode ruleset still runs checks and shows annotations, but it does not block merges on its own.

The inconvenient part is that license compliance is not only about direct dependencies. GitHub evaluates direct and transitive dependencies, so a package several layers deep can still trigger a violation. That is the point of the system, because legal exposure often arrives through nested packages, not the ones a developer named directly.

When GitHub finds a violation, the normal fixes are limited and concrete: replace the dependency, approve an exception, or update policy to allow the license. GitHub says exceptions can apply to a package, a license, or a package pattern, and they are reviewed by Enterprise Open Source License Managers.

Another thing people miss is that license policy and branch protection can stack. GitHub notes that branch protection rules requiring comment resolution can still track annotations from license checks, even when the ruleset is only in Evaluate mode. That means a review workflow can stay blocked even before the license rule itself becomes Active.

A typical rollout uses three states: inactive, evaluate, and active. GitHub’s documentation suggests using repository custom properties to move repositories through those stages, so teams can test the policy before making it mandatory. That is the useful pattern for large orgs, because it keeps early noise out of critical repositories while the policy is being tuned.

A concrete example makes the workflow easier to see. Suppose a pull request adds a package with a license your enterprise policy does not allow. GitHub compares the dependency change, flags the violation in the pull request, and then either blocks merge in Active mode or leaves an annotation in Evaluate mode. A reviewer can then swap the package or request an exception.

If the team ignores the warning and merges anyway, the policy no longer protects the repository. That is why GitHub ties the feature to rulesets rather than just dashboards. The system is meant to stop noncompliant dependencies at the merge boundary, not to act as a report after the fact.

GitHub also points out that the license picker is only informational and does not constitute legal advice. That sentence matters because the tool can help enforce a policy, but it does not decide what your organization is legally comfortable shipping. The final policy belongs to the enterprise team, usually with legal review.

The shortest honest definition is this: GitHub open source license compliance is dependency license policy enforcement. It tells an enterprise which open source licenses are acceptable, evaluates dependency changes in pull requests, and either records or blocks violations according to the selected ruleset.

For teams building with DevConnect, the same logic applies on your own infrastructure and repositories, not on someone else’s account or platform. If you need a place to coordinate testing work around your own product, DevConnect is available at https://devconnectplatform.com, but the license rules themselves still come from GitHub and SPDX.

What the feature does not do is more important than the marketing name suggests. It does not replace legal review, it does not certify that a project is safe to ship, and it does not turn an unreviewed dependency policy into compliance by itself. It is a control for the merge path, and it works only when the policy behind it is correct.

A team should use it when dependency licensing is a real release concern, especially in enterprise repositories with many transitive packages. A team should not use it as a substitute for knowing what licenses are in the build graph. The tool helps enforce a decision, it does not make the decision for you.

FAQ

Is GitHub open source license compliance the same as Dependabot No. Dependabot updates dependencies. License compliance evaluates the licenses on dependency changes and compares them to policy. GitHub’s docs place both in supply chain security, but they solve different problems.

Does it check only direct dependencies No. GitHub says license evaluation uses dependency data from repositories, including transitive dependencies detected in the dependency graph. That means nested packages can trigger the same policy outcome as top-level packages.

What happens when a dependency is not on the allowed list GitHub reports a violation in pull request annotations, and an Active ruleset can block the merge until the violation is resolved. The usual resolution is to replace the dependency, request an exception, or expand the policy.

Can I use SPDX identifiers in policy Yes. GitHub says you can add licenses by built-in list or by manually adding a SPDX license identifier. SPDX is the standard GitHub references for machine-readable license naming.

Is this available for every GitHub account No. GitHub documents it for organizations owned by an enterprise account with GitHub Code Security enabled. It is an enterprise feature, not a general-purpose setting for every repository.