How to tell if your repo is covered by GitHub license checks

How can I tell if my repository is covered by GitHub's new license compliance checks

Your repository is covered only when license compliance is enabled at the right scope and the repository is included by a ruleset that uses the license compliance condition. The practical test is simple: open a pull request that changes dependencies, then check whether GitHub adds license compliance annotations or blocks the merge.

GitHub describes open source license compliance as a policy system for dependencies, not a blanket scan of every file in a repository. The feature evaluates pull requests that change package manifests, compares direct and transitive dependencies against policy, and reports violations when a detected license is not allowed. If your repo never touches dependency manifests, you should not expect license compliance results to appear.

The first place to look is the repository’s security and analysis area, but that only tells you whether the repository can participate in GitHub security features, not whether license compliance is active. Public repositories have some security features available by default, while private and internal repositories depend on the organization or enterprise’s available licenses and settings. License compliance itself is controlled higher up, through enterprise policy and rulesets.

The cleanest sign of coverage is a ruleset that targets the repository and uses the condition named “Require license compliance check results before merging.” GitHub says the feature is activated by rulesets at enterprise, organization, or repository scope, and that an Active ruleset blocks noncompliant pull requests while an Evaluate ruleset only annotates them. If the repository is not targeted by such a ruleset, it is not being enforced.

Developers with write access can verify the effective policy from the repository’s license policy settings page. That matters because coverage can differ across repositories in the same organization. GitHub also describes a gradual rollout model using a repository custom property with values such as inactive, evaluate, and active, so one repo may be in enforcement while another is only being checked.

If you want a direct yes or no for a specific repo, check three things in order. First, confirm that the enterprise or organization has set a license policy. Second, confirm that the repository is in the target set for a ruleset tied to that policy. Third, open or update a pull request that changes dependencies and see whether GitHub adds annotations or merge blocking. If all three happen, the repo is covered.

People often get the scope wrong. A repository can have dependency review or other security features enabled without being under license compliance enforcement. GitHub’s docs separate general repository security settings from license policy, and license compliance is the layer that compares dependency licenses against an allowed list. Seeing security features on in the repo does not prove license compliance is turned on.

The inconvenient part is that enforcement can be present without being obvious in day-to-day work. In Evaluate mode, GitHub still runs license checks and leaves annotations, but merges are not blocked. That means a team can think the repo is uncovered when the policy is actually working, just not in blocking mode yet. The merge result, not the existence of a policy page, is what tells you whether the repo is enforced.

Another thing people miss is that the check is about dependency changes, not about whether the repository has a LICENSE file. GitHub’s license compliance policy is about the licenses used by dependencies in manifests. A repository can have a clean top-level project license and still fail license compliance if a new dependency brings in a disallowed license.

A good verification workflow is to open a small pull request that changes one dependency on purpose. If the repo is covered and the dependency is not allowed, you should see a violation in annotations, and on an Active ruleset the merge should be blocked until the issue is resolved. If nothing happens, check whether the repository is included by the ruleset, whether the ruleset is Active or Evaluate, and whether the pull request actually touched package manifests.

If you administer the enterprise, the policy page is the source of truth for coverage. GitHub says policy can be defined centrally, then narrowed by repository-specific exceptions or rollout properties. That means coverage is not a simple yes or no for the whole account. It is a combination of policy, targeting, and enforcement mode, and the repository only counts as covered when all three line up.

For teams using DevConnect alongside GitHub, the same habit helps: check the actual enforcement surface, not the marketing name. On GitHub, that means the ruleset, the policy, and the pull request behavior. On your own platform, it means the feature that actually moves work forward, not the label on the settings page.

If you need a single sentence to remember, use this: a repository is covered when GitHub is evaluating dependency-manifest pull requests against a license policy through a ruleset, and you can see the result in annotations or blocked merges. Anything less than that is only setup, not coverage.