OSS Review Toolkit (ORT): Automating License Compliance at Scale

Open source license compliance is one of those problems that sounds simple and turns out to be fiendishly complex. Your application uses 50 direct dependencies. Those dependencies pull in 300 transitive dependencies. Each has a license — or multiple licenses, or no declared license at all. Some licenses are permissive (MIT, Apache 2.0). Some are copyleft (GPL, AGPL). Some are incompatible with each other. And getting it wrong can mean legal liability, forced open-sourcing of proprietary code, or blocked product releases.

The OSS Review Toolkit (ORT), originally developed at HERE Technologies and now maintained as an open source project under the Linux Foundation, is one of the most comprehensive tools for tackling this problem at enterprise scale.

What ORT Does

ORT is a suite of tools that cover the full open source compliance workflow:

Analyzer

The Analyzer scans your project's build files and resolves the complete dependency tree, including transitive dependencies. It supports over 20 package managers including npm, pip, Maven, Gradle, Cargo, Go modules, CocoaPods, and more.

The output is a structured representation of every package in your dependency tree, including:

• Package name and version
• Declared license
• Source repository URL
• VCS (version control system) information
• Relationship to other packages (direct vs. transitive)

Scanner

The Scanner performs actual license detection by examining the source code of each dependency. This goes beyond declared licenses (what the package.json or pom.xml says) to detected licenses (what the actual source files contain). This distinction matters because:

• Some packages declare no license, but their source files contain license headers
• Some packages declare one license but contain files under different licenses
• Some packages have conflicting license information between the package metadata and the source code

ORT integrates with multiple scanning backends including ScanCode, a comprehensive open source license scanner, and FossID for commercial scanning.

Evaluator

The Evaluator applies rules to the analysis and scan results. This is where you encode your organization's compliance policies:

• Which licenses are acceptable?
• Which licenses require legal review?
• Which licenses are prohibited?
• Are there specific packages that have been manually reviewed and approved (or rejected)?
• What combinations of licenses are incompatible?

Rules are written in a Kotlin-based DSL that allows complex policy logic.

Reporter

The Reporter generates human-readable and machine-readable compliance documentation from the evaluation results. Output formats include:

• SPDX documents (SBOM format)
• CycloneDX BOMs
• Web-based reports with interactive dependency trees
• Notice files (the attributions document required by many open source licenses)
• Excel spreadsheets for legal review

Advisor

The Advisor checks dependencies against vulnerability databases (OSV, NVD) and provides security advisory information alongside license data. This makes ORT useful for both compliance and security workflows.

Why ORT Over Simpler Tools

If you just need license detection for a single JavaScript project, tools like license-checker or licensee might suffice. ORT's value becomes clear when you need to:

Handle multiple ecosystems. An enterprise with Java backends, React frontends, Python data pipelines, and Go microservices needs a single tool that understands all these ecosystems. ORT's multi-package-manager support is its strongest feature.

Enforce policies consistently. The Evaluator ensures that the same compliance rules apply across all projects, regardless of language or team. Policy-as-code means policies are versioned, reviewable, and auditable.

Scale to hundreds of projects. ORT can be run in CI/CD pipelines across all your repositories, providing continuous compliance monitoring rather than point-in-time audits.

Generate required documentation. Many organizations need to produce notice files, attribution documents, or SPDX SBOMs for their software products. ORT generates these automatically from its analysis data.

Setting Up ORT

Basic Analysis

ORT is distributed as a Docker image and as native binaries:

# Analyze a project
ort analyze -i /path/to/project -o /path/to/output

# Scan detected packages for license information
ort scan -i /path/to/output/analyzer-result.yml -o /path/to/output

# Evaluate against policies
ort evaluate -i /path/to/output/scan-result.yml \
  --rules-file /path/to/rules.kts \
  -o /path/to/output

# Generate reports
ort report -i /path/to/output/evaluation-result.yml \
  -o /path/to/output \
  -f WebApp,SpdxDocument,CycloneDx

Writing Policy Rules

ORT's rule engine is flexible. Here's a simplified example:

// Prohibit AGPL-licensed packages
fun RuleSet.noAgpl() = packageRule("NO_AGPL") {
    require {
        -isExcluded()
    }
    licenseRule("NO_AGPL", LicenseView.CONCLUDED_OR_DECLARED_AND_DETECTED) {
        require {
            +isSpdxLicense("AGPL-3.0-only")
        }
        error(
            "Package ${pkg.id.toCoordinates()} uses AGPL-3.0 license, " +
            "which is not allowed per company policy."
        )
    }
}

This rule checks every non-excluded package for AGPL-3.0 usage and generates an error if found. Real-world rule files are typically more complex, handling license exceptions, specific package approvals, and nuanced compatibility requirements.

ORT in CI/CD

For continuous compliance, integrate ORT into your CI/CD pipeline:

1. Analysis on every build. Run ort analyze as a build step to capture the current dependency tree.
2. Evaluation against policies. Run ort evaluate to check the dependency tree against your compliance rules.
3. Fail the build on violations. If the evaluator finds policy violations, fail the build with clear error messages.
4. Generate reports for releases. On release builds, generate SPDX documents and notice files.

The performance consideration is real: a full ORT scan (including source code license scanning) can take significant time for large projects. Many organizations run the full scan on a schedule (nightly or weekly) while running the faster analysis and evaluation steps on every build.

The License Compliance and Security Intersection

License compliance and security are often treated as separate concerns, but they're deeply connected in the supply chain context:

• Unmaintained packages are both a security risk (no vulnerability patches) and a compliance risk (license questions can't be resolved with the maintainer)
• License-incompatible dependencies may need to be replaced, which creates an opportunity to evaluate whether more secure alternatives exist
• SBOM requirements serve both compliance (what licenses are in use) and security (what components need vulnerability monitoring) purposes

ORT's ability to address both concerns in a single tool and workflow is one of its key advantages.

Limitations

ORT is powerful but not simple:

• Learning curve. Setting up ORT, writing policy rules, and integrating it into CI/CD requires significant initial investment.
• Scan performance. Full source code scanning is slow for large dependency trees.
• License ambiguity. Some packages have genuinely ambiguous licensing, requiring human judgment that no tool can fully automate.
• Maintenance burden. Policy rules, package curations, and scanner configurations need ongoing maintenance.

How Safeguard.sh Helps

Safeguard.sh complements tools like ORT by providing a managed platform for supply chain compliance and security. Our platform integrates with ORT's output formats (SPDX, CycloneDX) and extends the analysis with continuous vulnerability monitoring, VEX support, and policy enforcement. For organizations that want the compliance coverage of ORT without the operational overhead of managing the tooling themselves, Safeguard.sh provides a streamlined path to comprehensive supply chain governance.