How to Check Open-Source Licenses Across Your GitHub Repositories

Open-source packages help developers build applications without writing every component from scratch. A .NET application might use NuGet packages, a React project might depend on npm libraries, and a Python service might rely on packages published through PyPI.

However, every dependency can come with a license that defines how the software may be used, modified, and distributed. If your team does not review these licenses, you may introduce obligations that conflict with your company's policies or the way you distribute your application.

The challenge becomes more difficult when an organization maintains dozens or hundreds of repositories. Checking every dependency manually is time-consuming, and license information may be missing, inconsistent, or difficult to interpret.

GitHub provides tools that help developers identify dependencies and inspect repository information. You can combine these capabilities with software composition analysis tools and automated checks to build a repeatable license-review process.

In this article, you will learn how to check open-source licenses across GitHub repositories, inspect dependency license information, automate checks with CI/CD, and handle packages that require further review.

Why Should You Check Open-Source Licenses?

An open-source license explains the conditions under which others may use, modify, and distribute software. Different licenses grant different permissions and impose different obligations.

For example, the MIT License generally permits broad use, modification, and distribution, subject to its conditions. The Apache License 2.0 includes additional provisions, including express patent grants and requirements concerning notices. The GNU General Public License (GPL) includes copyleft conditions that can affect how covered software is distributed.

These differences matter when you build commercial products, distribute software to customers, or combine multiple dependencies into one application.

License review helps answer questions such as:

Which licenses are used by our application dependencies?
Are any licenses restricted by company policy?
Do we need to preserve copyright or license notices?
Are there dependencies whose licenses require legal review?
Have new dependencies introduced different licensing obligations?
Can we produce an accurate inventory of third-party software?

License compliance is not only a legal concern. It also helps engineering teams maintain an accurate software bill of materials and understand the components included in a release.

Step 1: Identify Dependencies Across Your GitHub Repositories

Before reviewing licenses, you need to know which packages your repositories use.

GitHub's dependency graph can identify dependencies from supported manifest and lock files. Depending on the repository and configuration, these may include:

Ecosystem	Common dependency files
.NET	`.csproj`, `.fsproj`, `packages.config`, `packages.lock.json`
JavaScript and TypeScript	`package.json`, `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`
Python	`requirements.txt`, `pyproject.toml`, supported lock files
Java	`pom.xml`, `build.gradle`, supported Gradle lock files
Ruby	`Gemfile`, `Gemfile.lock`
Rust	`Cargo.toml`, `Cargo.lock`

The exact files recognized depend on the ecosystem and GitHub's current support.

To inspect a repository, open its settings and locate the security configuration for dependency graph features. Availability and menu names may differ by repository type and GitHub plan.

Once enabled, review the dependency graph to understand which dependencies GitHub has identified.

Remember that the dependency graph is not a complete license audit. It may not identify every vendored library, manually copied source file, dynamically downloaded component, or dependency that is not represented in a supported manifest.

For an organization-wide audit, begin by listing the repositories in scope. Include application repositories, shared libraries, internal packages, and deployment tools where third-party software is used.

Step 2: Understand the Difference Between Dependency and License Information

A dependency inventory tells you which packages an application uses. License information tells you the terms under which those packages may be used.

These are related but different tasks.

For example, your .NET project might contain this package reference:

<ItemGroup>
  <PackageReference
    Include="Example.Json"
    Version="2.4.0" />
</ItemGroup>

This identifies a package and its version. It does not establish the license terms of that exact package release.

To review the license, check the package's metadata, license file, repository, and release information. Confirm that the information applies to the version you actually use.

A package's repository may have changed its license over time. The license displayed on the current default branch may not match the license for an older release.

For that reason, review the version resolved by your application rather than relying only on a repository's current license badge.

Step 3: Use GitHub to Review Repository License Information

GitHub can display license information when it recognizes a supported license file in a repository.

For a public repository, you can usually inspect the repository's license file or the license information displayed in its interface.

For an organization with many repositories, you can use the GitHub API or GitHub CLI to automate parts of the inventory process.

For example, the GitHub CLI can retrieve repository metadata.

First, authenticate:

gh auth login

Then retrieve the metadata for a repository:

gh api repos/OWNER/REPOSITORY \
  --jq '{name: .name, full_name: .full_name, license: .license.name}'

Replace OWNER and REPOSITORY with the appropriate values.

The command returns the repository name and the license GitHub identifies from the repository's metadata.

For example, the output might look like this:

{
  "name": "sample-library",
  "full_name": "example-org/sample-library",
  "license": "MIT License"
}

This example illustrates the output format; it is not a claim about a particular repository.

There is an important limitation: repository-level license metadata describes the repository's recognized license information. It does not automatically tell you the licenses of all third-party packages used by that repository.

A repository may have an MIT-licensed application while depending on packages distributed under different licenses. You must inspect those dependencies separately.

Step 4: Check Package Licenses in a .NET Project

For .NET applications, NuGet package metadata is a useful starting point.

NuGet packages may declare license information in their package metadata. Depending on the package, this may be a license expression or a reference to a license file.

For example, a package author might declare a license expression in a project file:

<PropertyGroup>
  <PackageId>Example.Library</PackageId>
  <Version>1.0.0</Version>
  <PackageLicenseExpression>MIT</PackageLicenseExpression>
</PropertyGroup>

This example shows how a package author can declare a license expression. It is not a substitute for checking the actual license of a published package.

For packages already installed in your project, inspect the package metadata and license files associated with the resolved versions.

You can list direct and transitive dependencies using the .NET CLI:

dotnet list package --include-transitive

This command helps identify packages brought into the project directly and through other dependencies.

However, it does not provide a complete license compliance report. You need an additional process or tool to map those packages to their license information.

For a larger application, consider a software composition analysis tool that can inspect the dependency graph, identify package licenses, detect known vulnerabilities, and generate a report suitable for review.

Do not assume that a package's license metadata is always present or correct. Missing or ambiguous information should be treated as an item for investigation.

Step 5: Automate License Checks in CI/CD

Manual review is useful for an initial audit, but it becomes difficult to maintain as repositories change.

A better approach is to include license checks in your development workflow.

A typical process looks like this:

A developer adds or updates a dependency.
A pull request triggers automated checks.
A license-scanning tool identifies the affected packages.
The tool compares detected licenses with the organization's policy.
The workflow reports violations or blocks the merge, depending on the configured policy.
A reviewer investigates exceptions and approves permitted changes.

You can implement the workflow using GitHub Actions and a license-scanning tool that supports your package ecosystems.

The following example illustrates the structure of a workflow that runs a scanner. It assumes that your organization has selected a compatible tool and configured its command-line interface.

name: License Compliance

on:
  pull_request:
    branches:
      - main

permissions:
  contents: read

jobs:
  license-check:
    runs-on: ubuntu-latest

    steps:
      - name: Check out repository
        uses: actions/checkout@v4

      - name: Restore dependencies
        run: dotnet restore

      - name: Run license scanner
        run: |
          echo "Run your configured license scanner here"
          echo "Fail the job when policy violations are found"

The scanner step is a placeholder, not an actual license scanner. Replace it with the installation and execution steps for your chosen tool, including its approved version and policy configuration.

For production use, pin third-party GitHub Actions to verified full commit SHAs according to your organization's supply-chain policy.

The most important part is the enforcement policy. A report that lists licenses can improve visibility, but it does not automatically prevent a restricted dependency from entering the codebase.

Define which findings should fail the workflow, which require manual approval, and which can be accepted without additional review.

Step 6: Create a License Policy for Your Organization

A license scanner needs a policy to determine which findings require action.

Without a consistent policy, different teams may make different decisions about the same dependency.

A practical policy can classify licenses into three groups.

Classification	Meaning	Typical action
Approved	The license meets the organization's requirements for the intended use	Allow the dependency, subject to applicable obligations
Review required	The license or usage scenario needs additional assessment	Request approval before merging or releasing
Restricted	The license conflicts with the organization's policy for the intended use	Block the dependency unless an authorized exception is granted

These categories should reflect your actual legal and business requirements.

For example, a company might allow MIT-licensed packages for most internal and commercial applications while requiring additional review for dependencies under certain copyleft licenses.

However, no license should be classified solely by its name without considering the intended use, distribution model, and applicable obligations.

A license that is acceptable for an internal tool may require a different assessment when the same software is distributed to customers.

Ask your legal or open-source compliance team to approve the policy, especially if your organization distributes commercial software.

Step 7: Generate a Software Bill of Materials

A software bill of materials, commonly called an SBOM, records the components included in a software product.

An SBOM can help teams identify third-party packages, track versions, investigate vulnerabilities, and support license compliance reviews.

For example, a release inventory might contain:

Component	Version	License	Review status
Example.Json	2.4.0	MIT	Approved after verification
Example.Logging	5.1.0	Apache-2.0	Approved after verification
Example.Native	1.8.2	Unknown	Review required

These are illustrative entries, not verified packages or license declarations.

An effective SBOM process should capture the components used by the release rather than only the dependencies declared directly in a project file.

Where appropriate, generate the SBOM during the build process and retain it with the release artifacts. Use a supported format, such as SPDX or CycloneDX, depending on your tooling and organizational requirements.

An SBOM is an inventory, not a legal approval. Its license fields must still be accurate, and unresolved findings need follow-up.

Common Mistakes to Avoid

Checking only the repository's main license

A repository's license file does not establish the licenses of every dependency it uses. Review third-party components separately.

Reviewing only direct dependencies

Transitive dependencies can introduce additional license obligations. Include the full resolved dependency graph in your audit.

Trusting license metadata without verification

Package metadata can be missing, incomplete, or incorrect. Verify the license against the relevant package version and its published terms.

Assuming a scanner makes the final legal decision

Automated tools help identify licenses and potential conflicts, but they cannot always determine whether a particular use complies with every applicable condition.

Ignoring changes after the initial audit

New packages and version updates can change your dependency inventory. Run checks during pull requests and releases rather than relying on a one-time report.

Best Practices for GitHub License Compliance

Start by establishing a complete inventory of repositories and dependencies. Identify which repositories contain applications, shared libraries, internal packages, or other components that may be distributed.

Next, define a license policy with clear approval categories. Choose a scanner that supports your package ecosystems, and integrate it into CI so that dependency changes are reviewed consistently.

Keep the dependency inventory and SBOM current. Record the license information associated with the package versions used by each release, and assign an owner to investigate missing or ambiguous metadata.

Finally, make exceptions traceable. Document why a dependency was accepted, who approved it, and whether the approval applies to a specific application or the organization more broadly.

Summary

Checking open-source licenses across GitHub repositories requires more than looking at repository license badges. You need to identify the complete dependency graph, verify license information for the versions you use, and compare the findings with an approved organizational policy.

GitHub's repository metadata, dependency graph, and automation capabilities can help establish the process. Package-specific inspection, license-scanning tools, and CI/CD enforcement provide additional coverage.

For larger organizations, generating an SBOM and maintaining a record of approved dependencies can make ongoing reviews more manageable.

The goal is to make license compliance part of normal development. When every dependency change is visible and reviewed consistently, teams can reduce surprises before releasing software.