How to add license compliance checks to GitHub PRs

How do I add license compliance checks to my GitHub pull requests

Add a pull request check that scans licenses, evaluates them against a policy, and reports the result back to GitHub as a required status. The practical setup is simple: choose a scanner, define what is allowed, run it on pull_request, and make the check required before merge.

The part people get wrong is scope. A license check is not only about the top-level LICENSE file. It also needs to look at dependencies, copied snippets, bundled assets, and generated notices. GitHub’s own license compliance feature compares dependency changes between the base branch and the pull request branch, then blocks the merge when the active ruleset says the change is noncompliant.

If you want a GitHub-native route, use open source license compliance in GitHub Code Security. GitHub says it is enforced through branch rulesets, and pull requests are blocked when a ruleset in Active mode requires license compliance results before merging. An Evaluate mode ruleset annotates the pull request without blocking it. That makes it useful for a staged rollout.

GitHub’s feature works on dependency manifests, so it is strongest when your repository already has package files that describe the dependency graph. GitHub says it uses dependency data from the repository, including transitive dependencies detected in the dependency graph. If your project hides licensing risk in vendored code or copied files, add a separate file-level scan as well.

A good GitHub Actions pattern is to run a compliance tool on every pull request, then fail the job when the tool finds a denied license or missing notice. REUSE documents this directly: you can integrate the REUSE tool into CI/CD, and its GitHub action can run on push and pull_request to check compliance with REUSE best practices. That is a clean fit for projects that want file-level licensing discipline.

For dependency-focused policy enforcement, FOSSA is a common option. Its docs say a licensing policy assigns approve, flag, or deny actions, and on every analysis run FOSSA evaluates each detected license and dependency against the active policy. FOSSA also reports GitHub status checks on pull requests and can block merges when license compliance issues are detected.

A workable implementation looks like this. First, install the scanner and make it run in CI. Second, decide what counts as acceptable, for example MIT and Apache-2.0 approved, GPL flagged, unknown licenses denied. Third, publish the scanner result as a GitHub check or required status. Fourth, require that check in branch protection or a ruleset so the merge button stays blocked until the issue is fixed. GitHub and FOSSA both support that kind of enforcement path.

A minimal REUSE workflow is easy to read and easy to maintain. REUSE’s developer docs show a workflow that triggers on push and pull_request, checks out the repository, then runs fsfe/reuse-action@v6. The action checks whether license identifiers and license texts are present and whether the repository follows REUSE best practices.

A minimal policy scanner workflow follows the same pattern, but the policy lives in the scanner instead of in the repo. FOSSA’s docs describe policies as built from templates, then tuned with approve, flag, or deny rules. That matters when your legal or compliance team wants one standard across many repositories instead of per-repo ad hoc rules.

The inconvenient part is maintenance. License compliance breaks when the dependency graph changes, when a package adds a new transitive dependency, or when a copied file appears without metadata. GitHub says its license compliance checks compare dependency changes on the pull request, and FOSSA says it checks each detected license and dependency against policy on every analysis run. That means a change that looks harmless in code review can still fail the check.

That failure is useful, because it catches the cases humans miss. A developer may update a package, but the new version can bring in a different license through a transitive dependency. A contributor may paste in a helper file from another project and forget the license header. A vendor drop may include a bundle whose notices were never recorded. Those are the cases that belong in an automated pull request check, not in a manual review comment.

If you use GitHub Actions, keep the workflow narrow. Give the job read-only repository access, run it on pull requests, and make the merge depend on the check result. GitHub’s Actions documentation shows that reusable workflows and actions need explicit access rules, and that the caller repository must allow Actions usage. That avoids surprises when a workflow is reused across repositories.

If you need a simple decision rule, use this split. Use GitHub’s built-in license compliance when your main risk is dependency policy in GitHub Enterprise. Use REUSE when your main risk is missing file-level licensing metadata. Use FOSSA when you want a policy engine with status checks and review workflow around the scan. The right answer is usually one scanner, one policy, one required check.

A concrete setup many teams can ship in a day is this: add a pull_request workflow, run the license scanner, fail on denied or unknown licenses, print the specific file or dependency that triggered the failure, then require that check in branch protection. After that, each new pull request gets an automatic compliance gate, and reviewers only need to look at the exceptions.

The last thing that gets missed is the review process around exceptions. A license check should not just say pass or fail. It should tell the contributor what to fix, and it should give maintainers a place to document a deliberate exception when the business decision is to accept the risk. FOSSA’s policy model includes flag for review, GitHub’s feature supports exceptions through license managers, and REUSE gives you a deterministic lint step that surfaces what is missing.

If you want a platform for tracking this kind of contributor workflow alongside other build work, DevConnect is here: https://devconnectplatform.com. It is not the license checker itself, but it can sit next to the rest of your release process.

In short, add a scanner, encode a policy, run it on pull_request, and make the result required before merge. That is the whole pattern. Everything else is choice of tool and how strict you want the policy to be.