Open Source License Compliance: A Practical Guide for Software Companies

The average commercial application contains 77% open-source code, spread across 500+ dependencies. Each dependency carries its own license with specific obligations. Violating these obligations exposes your company to lawsuits, forced code disclosure, and reputational damage. Yet most companies have no process for tracking or complying with open-source licenses.

This guide provides a practical framework for open-source license compliance, from license categorization to automated scanning and SBOM generation.

Key Takeaways

• Not all open-source licenses are the same: permissive licenses allow nearly anything, copyleft licenses require you to share modifications
• A Software Bill of Materials (SBOM) is becoming a legal requirement in government procurement (US Executive Order 14028)
• Automated license scanning in CI/CD prevents non-compliant dependencies from entering your codebase
• Copyleft "infection" risk is real: one GPL dependency can obligate you to open-source your entire application

---

License Categories

Permissive Licenses (Low Risk)

Safe for commercial use. Include the license text and copyright notice in your distribution. Apache 2.0 additionally requires noting any changes to the original code and includes a patent license.

Weak Copyleft (Medium Risk)

Use with caution. Keep LGPL libraries as shared (dynamic) libraries, not statically linked. Keep MPL-licensed code in separate files from your proprietary code.

Strong Copyleft (High Risk)

Highest risk for commercial software. Using GPL code in your application may require you to release your entire application under the GPL. AGPL extends this to server-side software --- even if you never distribute binaries, providing the software as a web service triggers the copyleft obligation.

---

Compliance Workflow

Step 1: Generate an SBOM

# For Node.js projects (using CycloneDX)
npx @cyclonedx/cyclonedx-npm --output-file sbom.json --spec-version 1.5

# For Python projects
pip install cyclonedx-bom
cyclonedx-py environment --output sbom.json

# For multi-language projects (using Syft)
syft . -o cyclonedx-json > sbom.json

Step 2: Scan for License Compliance

# Using license-checker for Node.js
npx license-checker --production --json --out licenses.json

# Using scancode-toolkit (comprehensive, all languages)
scancode --license --copyright --output-json scan-results.json .

Step 3: Categorize and Approve

Create an approved license list:

{
  "approved": [
    "MIT", "BSD-2-Clause", "BSD-3-Clause", "Apache-2.0",
    "ISC", "0BSD", "Unlicense", "CC0-1.0"
  ],
  "conditional": [
    "LGPL-2.1", "LGPL-3.0", "MPL-2.0", "EPL-2.0"
  ],
  "prohibited": [
    "GPL-2.0", "GPL-3.0", "AGPL-3.0", "SSPL-1.0",
    "EUPL-1.2", "OSL-3.0"
  ]
}

Step 4: CI/CD Integration

# .github/workflows/license-check.yml
name: License Compliance
on: [pull_request]

jobs:
  check-licenses:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - run: pnpm install --frozen-lockfile

      - name: Check licenses
        run: |
          npx license-checker --production --excludePackages "" \
            --failOn "GPL-2.0;GPL-3.0;AGPL-3.0;SSPL-1.0" \
            --summary

---

SBOM (Software Bill of Materials)

Why SBOMs Matter

• US Executive Order 14028 requires SBOMs for software sold to the US government
• EU Cyber Resilience Act will require SBOMs for software sold in the EU
• Supply chain security: SBOMs enable rapid vulnerability response (when log4j happens, you know if you are affected)
• Customer trust: Enterprise buyers increasingly request SBOMs during procurement

SBOM Standards

Recommendation: CycloneDX for most software companies. It is simpler, has better tooling support, and is becoming the industry default.

---

Common Compliance Scenarios

Scenario 1: Node.js Web Application

Typical node_modules directory contains 500-2,000 packages. The vast majority use MIT or ISC licenses. Common issues:

• Transitive dependencies using GPL (you did not add them directly)
• UNKNOWN license fields requiring manual investigation
• Multiple licenses on a single package (e.g., "MIT OR Apache-2.0")

Action: Run npx license-checker --production weekly. Investigate any non-permissive licenses. Replace GPL dependencies with permissive alternatives.

Scenario 2: Odoo Module Development

Odoo Community Edition is LGPL v3. Odoo Enterprise is proprietary. Your custom modules:

• Community modules: Must be LGPL v3 or compatible (if distributed)
• Private internal modules: Not distributed, so LGPL does not apply
• Enterprise add-ons: Must comply with Odoo Enterprise licensing terms

Scenario 3: SaaS with AGPL Dependencies

If your SaaS application uses AGPL-licensed code (e.g., MongoDB before they switched to SSPL), you must either:

1. Release your entire application source code under AGPL
2. Remove the AGPL dependency and use an alternative
3. Obtain a commercial license from the AGPL project (if available)

Server-side use of AGPL code triggers the copyleft obligation even though you never "distribute" binaries.

---

Frequently Asked Questions

Does using a GPL library in our API force us to open-source our API?

It depends on how you use it. If the GPL library is linked into your application (statically or dynamically), the FSF's position is that your application is a "derivative work" and must be licensed under GPL. If you communicate with the GPL software through a network API (e.g., using a GPL-licensed database server), that is generally not considered a derivative work. Consult a lawyer for your specific case.

What if a dependency changes its license?

You are bound by the license under which you obtained the code, not future license changes. However, if you update to a new version with a new license, the new license applies to that version. This is why SBOMs with version pinning are important --- they document exactly which version (and license) you are using.

How do we handle dependencies with "UNKNOWN" licenses?

Check the package's repository for a LICENSE file. If no license is specified, the code is technically under full copyright protection --- you have no right to use, modify, or distribute it. Either find the license (it may be in a non-standard location), request the author add one, or replace the dependency with a clearly licensed alternative.

Do we need to provide attribution for MIT-licensed packages?

Yes. MIT and most permissive licenses require you to include the copyright notice and license text when distributing the software. For web applications, this typically means including a THIRD-PARTY-NOTICES file or a page listing all open-source components and their licenses.

---

Building a Compliance Program

Quarterly Compliance Review

1. Regenerate SBOM for all projects
2. Scan for new dependencies added since last review
3. Check for license changes in updated packages
4. Review any "UNKNOWN" licenses that appeared
5. Update the approved license list if new licenses are encountered
6. Archive SBOM snapshots for audit trail

Compliance Roles

A lightweight compliance program takes 2-4 hours per quarter for a small team and prevents the much larger cost of discovering a compliance issue after product launch or during due diligence.

---

What Comes Next

License compliance is one aspect of software governance. Combine it with IP protection for your own code, SaaS agreement essentials for vendor software, and cybersecurity regulatory requirements for security compliance.

Contact ECOSIRE for open-source compliance auditing and SBOM generation services.

---

Published by ECOSIRE -- helping businesses use open source responsibly.