This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

License Scanning

Learn how to scan container images and filesystems for software licenses covering detection, compliance checking, and managing license obligations.

License scanning is the automated process of identifying and analyzing the licenses associated with software components in your projects. This is important because most software relies on third-party and open-source components, each with its own licensing terms that dictate how the software can be used, modified, and distributed, and failing to comply can lead to legal issues.

Grant is an open-source command-line tool designed to discover and report on the software licenses present in container images, SBOM documents, or filesystems. It helps users understand the licenses of their software dependencies and can check them against user-defined policies to ensure compliance.

1 - Getting Started

Use Grant to discover and analyze software licenses in your container images, directories, or SBOMs.

What is License Scanning?

License scanning is the process of automatically identifying and analyzing the licenses associated with software components in your projects.

  • For developers, it helps ensure license compliance early in development and understand the legal obligations of dependencies.

  • For organizations, it’s essential for managing legal risk, meeting compliance requirements, and avoiding license violations.

Grant is a CLI tool for discovering and analyzing software licenses in container images, SBOM documents, and filesystems. It categorizes licenses by risk level and helps verify compliance against your policies.

Installation

Grant is provided as a single compiled executable and requires no external dependencies to run. Run the command for your platform to download the latest release.

curl -sSfL https://get.anchore.io/grant | sudo sh -s -- -b /usr/local/bin
brew install grant

Check out installation guide for full list of official and community-maintained packaging options.

Discover licenses in a container image

Run grant list against a container image. Grant will analyze the image and display a summary table of all licenses found, categorized by risk level:

grant list alpine:latest
 LICENSE              PACKAGES  RISK
 GPL-2.0-only                8  High
 MIT                         5  Low
 Apache-2.0                  2  Low
 BSD-2-Clause                1  Low
 GPL-2.0-or-later            1  High
 MPL-2.0                     1  Medium
 Zlib                        1  Low

You can also get more information with the -o json flag to output the full details in JSON format:

grant list alpine:latest -o json

Grant categorizes licenses into three risk levels:

  • High: Strong copyleft licenses that may require source code disclosure
  • Medium: Weak copyleft licenses with more limited obligations
  • Low: Permissive licenses with minimal restrictions

License detection modes

Grant performs two types of license detection:

  1. SBOM-based detection: Analyzes package manifests and metadata to identify licenses associated with specific packages
  2. File-based detection: Searches the filesystem for standalone license files (LICENSE, COPYING, etc.) that may not be associated with any specific package

Use --disable-file-search to skip file-based detection when you only want licenses that are directly associated with packages:

grant check dir:. --disable-file-search

This can be useful for faster scanning or when you only care about package-level license data.

Group licenses by risk

Use --group-by risk to see an aggregated summary of licenses by risk category:

grant list alpine:latest --group-by risk
 RISK CATEGORY    LICENSES  PACKAGES
 Strong Copyleft         2         9
 Weak Copyleft           1         1
 Permissive              4         8

This view helps you quickly assess the overall risk profile of your dependencies.

View packages with specific licenses

To see which packages use a particular license, add the license name (or list of names) as an argument:

grant list alpine:latest MIT
 NAME                    VERSION      LICENSE    RISK
 alpine-keys             2.5-r0       MIT        Low
 alpine-release          3.22.2-r0    MIT        Low
 ca-certificates-bundle  20250911-r0  MIT, ...   Medium (+1 more)
 musl                    1.2.5-r10    MIT        Low
 musl-utils              1.2.5-r10    BSD-2-C... High (+2 more)

This view shows the package-level detail, including package names, versions, and all licenses associated with each package.

Get detailed package information

Use --pkg with a license filter to see detailed information about a specific package:

grant list dir:. MIT --pkg "github.com/BurntSushi/toml"
Name:     github.com/BurntSushi/toml
Version:  v1.5.0
Type:     go-module
ID:       go-module:github.com/BurntSushi/toml@v1.5.0
Licenses (1):

• MIT
  OSI Approved: true | Deprecated: false

Scan an existing SBOM for licenses

Grant can also scan an SBOM instead of a container image. The simplest approach is to pipe Syft’s output directly:

syft alpine:latest -o json | grant list

Alternatively, scan an SBOM file you’ve already generated:

grant list alpine.spdx.json

Check license compliance

Use grant check to verify that licenses comply with your organization’s policies. By default, Grant uses a “deny-all” policy, flagging any licenses found:

grant check alpine:latest

This command exits with:

  • Exit code 0: All licenses are compliant
  • Exit code 1: Non-compliant licenses detected or an error occurred

Find unlicensed packages

Use --unlicensed to identify packages that have no detected license:

grant list alpine:latest --unlicensed

Packages without licenses may indicate missing metadata or need manual investigation to determine their licensing terms.

FAQ

Does Grant need internet access?

Only for downloading container images if you’re scanning containers directly. Scanning SBOM files or local directories works completely offline.

What license data does Grant use?

Grant uses SPDX (Software Package Data Exchange) license identifiers and categorizes them based on copyleft strength and common usage patterns.

Can I use Grant in CI/CD pipelines?

Absolutely! Grant is designed for automation. Use grant check to fail builds when non-compliant licenses are detected.

What data does Grant send externally?

Nothing. Grant runs entirely locally and doesn’t send any data to external services.

Next steps

Now that you’ve scanned for licenses, here are additional resources:

  • Configure policies: Run grant config to generate a sample configuration file with allowed licenses and packages to ignore
  • Scan for vulnerabilities: Use Grype to find security issues in your containers
  • Generate SBOMs: Learn about SBOM generation with Syft for comprehensive software analysis

2 - Policies

Configure license compliance policies to automatically enforce allowed licenses and flag violations in your software supply chain.

Grant policies let you define which licenses are acceptable in your projects and automatically flag violations when running grant check.

Default behavior:

  • Deny all licenses except those explicitly permitted in the allow list
  • Deny packages without licenses when require-license is true (the default)
  • Allow non-SPDX licenses when require-known-license is false (the default)

You customize this behavior by specifying allowed licenses and other options in a configuration file.

Grant categorizes licenses by risk level based on their copyleft strength:

RiskLicense typeExamplesImplication
HighStrong copyleftGPL-3.0, AGPL-3.0May require source disclosure
MediumWeak copyleftLGPL-2.1, MPL-2.0Obligations for modifications
LowPermissiveMIT, Apache-2.0, BSDAttribution only

License types affect how software can be used, modified, and distributed. Understanding these categories helps you create effective compliance policies:

  • Strong copyleft (also called “reciprocal” or “restrictive”) licenses require that derivative works are distributed under the same license. Any modifications or software that incorporates the code must have its source code made available.
  • Weak copyleft licenses balance permissive and restrictive terms. They allow linking to open source libraries with limited obligations, making them practical for library code.
  • Permissive licenses have minimal restrictions on how you can modify or redistribute software. They typically only require you to retain copyright notices and attribution.

Create a policy file

Grant searches for configuration in this order:

  1. File specified with -c or --config flag
  2. Current directory: grant.yaml, .grant.yaml
  3. XDG config: ~/.config/grant/grant.yaml
  4. Home directory: ~/.grant.yaml

If no configuration is found, Grant uses a deny-all default.

Policy options

OptionTypeDefaultDescription
allowstring[][]License patterns to permit
ignore-packagesstring[][]Package patterns to skip
require-licensebooltrueDeny packages with no license
require-known-licenseboolfalseDeny non-SPDX licenses

allow

Specifies which licenses pass compliance checks. Supports glob patterns with * as a wildcard. Matching is case-sensitive.

allow:
  - MIT # Exact match
  - Apache-* # Matches Apache-1.0, Apache-1.1, Apache-2.0
  - BSD-*-Clause # Matches BSD-2-Clause, BSD-3-Clause
  - CC0-* # Matches CC0-1.0

A package passes if any of its licenses matches the allow list. With an empty allow list, all licenses are denied.

ignore-packages

Skips license evaluation for specific packages. Use this for internal packages or known exceptions you’ve reviewed. Supports glob patterns with *:

ignore-packages:
  - "internal-*" # Packages starting with internal-
  - "legacy-component" # Exact match

Ignored packages appear with status “ignore” in output and don’t affect the exit code.

require-license

When true (the default), packages with no detected license are denied. This catches packages with missing metadata that may need investigation.

require-license: true

Set to false if you want to allow packages without license information.

require-known-license

When true, only SPDX-recognized license identifiers pass. Custom or unrecognized license strings are denied.

require-known-license: true

This catches packages with unusual license declarations like “See LICENSE file” or custom proprietary licenses that need review.

Example policies

Permissive-only for commercial software

For a SaaS product where you want to avoid any copyleft obligations:

# .grant.yaml
allow:
  - MIT
  - Apache-2.0
  - BSD-2-Clause
  - BSD-3-Clause
  - ISC
  - 0BSD
  - Unlicense
  - CC0-1.0

require-license: true
require-known-license: true # Catch unexpected license strings

This policy ensures all dependencies use permissive licenses with no source disclosure requirements.

Internal tooling with exceptions

For internal tools that aren’t distributed, you can allow weak copyleft and ignore internal packages:

# .grant.yaml
allow:
  # Permissive
  - MIT
  - Apache-2.0
  - BSD-*-Clause
  - ISC

  # Weak copyleft (OK for internal use)
  - LGPL-*
  - MPL-2.0
  - EPL-*

ignore-packages:
  - "github.com/yourcompany/*"
  - "@yourorg/*"

require-license: true

Next steps