12.5 License Compliance as a Parallel Concern¶

Security practitioners often encounter license compliance as an adjacent concern—sometimes welcomed, sometimes resisted as outside their scope. Yet license compliance and security share fundamental infrastructure: the same SBOMs that enable vulnerability management reveal license obligations; the same SCA tools that detect vulnerable dependencies identify license risks; the same governance processes that approve components for security should evaluate license implications.

This section explains why security teams should understand license compliance, not to become lawyers, but to recognize how license and security concerns intersect and to build unified governance approaches that address both.

Why License Compliance Matters for Security Teams¶

License compliance and security are often treated as separate concerns—legal owns licensing, security owns vulnerabilities. This separation creates inefficiencies and gaps.

Shared Infrastructure:

License and security scanning use identical foundations:

• Same inventory: Both require knowing what components you use
• Same SBOMs: License information is standard SBOM content
• Same tools: Most SCA tools perform both license and vulnerability detection
• Same workflows: Both require evaluation during development and procurement

Building separate processes for each wastes resources and creates inconsistency.

Overlapping Risk:

License violations create risks that affect security's mission:

• Legal injunctions: Courts can order you to stop distributing software
• Forced disclosure: Some licenses require source code release
• Reputational damage: Public license violations affect trust
• Acquisition barriers: License issues can block M&A transactions

These outcomes—service disruption, forced changes, reputational harm—parallel security incident impacts.

Governance Alignment:

Organizations increasingly recognize that component governance should be unified:

Leading organizations have moved from separate security and legal review gates to unified component approval processes, enabling teams to make better decisions using the same data and consistent governance frameworks.

Common Open Source License Types¶

Understanding major license categories helps security professionals participate in governance discussions.

License Categories:

Major License Comparison:

MIT License: - Extremely permissive - Requires only attribution (copyright notice) - No patent grant - Very short and simple - Most popular license on GitHub

Apache License 2.0: - Permissive with patent grant - Contributors grant patent license to users - Requires attribution and notice of changes - Includes contributor agreement - Common in enterprise and Apache projects

BSD Licenses (2-clause, 3-clause): - Permissive, similar to MIT - 3-clause adds "no endorsement" restriction - Requires attribution - No patent grant - Common in BSD operating systems and derivatives

GNU General Public License (GPL): - Strong copyleft - Derivative works must use GPL - Must provide source code to recipients - No "Tivoization" (GPLv3) - Different versions (v2, v3) have important differences

GNU Affero GPL (AGPL): - GPL plus network use trigger - Providing network access to AGPL software requires source release - Important for SaaS and cloud services - Often restricted by organizations

License Selection Guidance:

License Compliance Tooling¶

Multiple tools address license detection, often alongside security scanning.

Integrated SCA Tools:

Most SCA tools include license detection:

Dedicated License Tools:

FOSSA: - License-first design with security added - Deep license analysis including custom licenses - Policy engine for license approval - SBOM generation and analysis

Licensee: - Open source license detection - GitHub-native (used in repository insights) - Identifies license from files, not just metadata

ScanCode: - Open source toolkit - Detects licenses from source code patterns - Identifies copyrights and notices - Foundation for other tools

License Detection Approaches:

Tools identify licenses through:

1. Manifest analysis: Reading package.json, pom.xml license fields
2. License file detection: Finding LICENSE, COPYING, README
3. SPDX identifiers: Standard license identifiers in files
4. Pattern matching: Recognizing license text in source code
5. Heuristics: Inferring from project metadata and patterns

Detection Challenges:

License detection isn't always straightforward:

• Missing declarations: Some packages don't declare licenses
• Multiple licenses: Dual-licensing or different licenses for different files
• Custom licenses: Non-standard license text requires interpretation
• License versions: GPL-2.0-only vs. GPL-2.0-or-later distinction matters
• Transitive licenses: Dependencies bring their own license obligations

The Intersection of License and Security Scanning¶

Integrating license and security scanning creates efficiency and consistency.

Shared Workflow:

Developer adds dependency
        │
        ▼
┌───────────────────┐
│   SCA Tool Scan   │
│  ┌─────────────┐  │
│  │  License    │  │
│  │  Detection  │  │
│  └─────────────┘  │
│  ┌─────────────┐  │
│  │  Vulnerability│ │
│  │  Detection   │ │
│  └─────────────┘  │
└────────┬──────────┘
         │
         ▼
┌───────────────────┐
│  Policy Engine    │
│  - License rules  │
│  - Security rules │
└────────┬──────────┘
         │
    ┌────┴────┐
    │         │
    ▼         ▼
 Approved  Blocked/Review

Policy Alignment:

Unified policies address both concerns:

# Example unified policy
component-policy:
  approved:
    licenses: [MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause]
    max_vulnerability_severity: HIGH  # Block CRITICAL

  requires-review:
    licenses: [LGPL-2.1, MPL-2.0]
    min_vulnerability_count: 5

  blocked:
    licenses: [GPL-3.0, AGPL-3.0]
    any_vulnerability_severity: CRITICAL

SBOM Integration:

SBOMs capture both license and component information:

{
  "components": [
    {
      "name": "lodash",
      "version": "4.17.21",
      "licenses": [
        {
          "license": {
            "id": "MIT"
          }
        }
      ],
      "vulnerabilities": [...]
    }
  ]
}

The same SBOM serves both compliance and security use cases.

Operational Risks from License Non-Compliance¶

License violations create tangible business risks that security teams should understand.

Legal Risks:

Litigation Examples:

• Cisco/Linksys (2008-2009): FSF sued over GPL violations in router firmware; settled with source code release and compliance director appointment¹
• VMware (2015-2018): Linux developer sued over GPL compliance in VMkernel in German court; dismissed on procedural grounds without ruling on GPL merits²
• Artifex v. Hancom (2016-2017): US federal court ruled GPL constitutes an enforceable contract; case settled confidentially but established important precedent³

Enforcement Mechanisms:

• Copyright infringement lawsuits
• Injunctions stopping product distribution
• Damages and legal fees
• Required source code disclosure

Business Risks:

Real Business Impact:

Synopsys OSSRA reports find:⁴

• 53% of audited codebases contain license conflicts
• 31% contain code with no identifiable license
• License issues are discovered in 80%+ of M&A audits

Supply Chain Implications:

Your license obligations extend through your supply chain:

• If you distribute software containing GPL code, you inherit GPL obligations
• Transitive dependencies bring their licenses with them
• Vendor software may contain open source with problematic licenses
• SaaS consumption doesn't eliminate all license concerns

Integrating License and Security Governance¶

Unified governance serves both license and security objectives more effectively than separate processes.

Organizational Models:

Separate Teams (Traditional): - Legal handles license compliance - Security handles vulnerability management - Coordination often ad-hoc - Different tools, different data, different processes

Unified Team (Emerging): - Single "component governance" or "open source program office" function - Combined tooling and workflow - Consistent policy framework - Shared expertise and efficiency

Unified Process Design:

1. Single intake: One process for evaluating new components
2. Combined policy: License and security rules in same policy engine
3. Shared data: Same SBOMs and inventory serve both purposes
4. Coordinated approval: One approval addresses both concerns
5. Integrated reporting: Dashboard shows license and security status

Role Clarity:

Even with unified process, different expertise applies:

Governance Framework:

                    ┌─────────────────────┐
                    │   Risk Committee    │
                    │ (escalation, policy)│
                    └──────────┬──────────┘
                               │
         ┌─────────────────────┼─────────────────────┐
         │                     │                     │
         ▼                     ▼                     ▼
   ┌───────────┐       ┌─────────────┐       ┌─────────────┐
   │   Legal   │       │   Security  │       │ Engineering │
   │ (license  │       │ (vulnerability│      │  (tooling,  │
   │  interpret)│       │  assessment) │       │   process)  │
   └───────────┘       └─────────────┘       └─────────────┘
         │                     │                     │
         └─────────────────────┼─────────────────────┘
                               │
                    ┌──────────▼──────────┐
                    │  Unified Component  │
                    │    Governance       │
                    │   (SCA, SBOM, etc.) │
                    └─────────────────────┘

Recommendations¶

For Security Practitioners:

1. Learn license basics. You don't need to be a lawyer, but understanding permissive vs. copyleft helps you participate in governance discussions.

2. Enable license detection. If your SCA tool supports license scanning, enable it. Same data, minimal additional effort.

3. Coordinate with legal. Establish relationship with legal team handling open source. Share tooling and findings.

4. Include license in SBOMs. When generating or requiring SBOMs, include license information. It's standard practice for a reason.

For Engineering Managers:

1. Unify component approval. Create single process that addresses both license and security. Avoid requiring developers to navigate multiple approval workflows.

2. Automate where possible. Policy engines can automatically approve clearly acceptable components and flag only those needing review.

3. Provide clear guidance. Give developers simple rules: "These licenses are fine, these require review, these are blocked."

4. Track compliance continuously. Don't just approve at introduction—monitor for changes as dependencies update.

For Organizations:

1. Establish unified governance. Consider Open Source Program Office (OSPO) or similar function that spans license and security.

2. Define clear policies. Document approved licenses, restricted licenses, and the process for exceptions.

3. Budget for tools that do both. Evaluate SCA tools on license and security capabilities together.

4. Include license in M&A diligence. Technical due diligence should address license compliance alongside security (see Section 11.6).

License compliance and security share too much infrastructure to manage separately. Organizations that recognize this intersection—using the same SBOMs, same tools, and unified governance—manage both risks more effectively than those maintaining parallel processes. Security teams don't need to become license experts, but they should understand enough to collaborate effectively and build unified component governance.