Skip to main content
Open source software is present in 96% of commercial applications, yet licence compliance remains one of the most misunderstood and poorly managed aspects of software development. Organisations routinely ship code containing undeclared open source components with conflicting licence obligations, creating legal exposure that goes undetected until it causes a problem. According to industry surveys, 80% of organisations experience release delays due to licence issues identified too late in the development cycle. Legal teams conducting final reviews must pause deployments whilst engineering teams investigate which components introduced the violations. At that stage, remediation is expensive and disruptive, requiring code refactoring, library replacement, or negotiation of licence exceptions under time pressure. Most organisations limit their compliance checks to declared dependencies. The more important question is: what open source software are we actually using, and what obligations does it carry?

​
The Challenge of Open Source Licence Compliance

Modern software development creates licence compliance complexity that traditional tools cannot address. Applications routinely incorporate hundreds or thousands of open source components, each carrying specific legal obligations that must be understood and fulfilled. These obligations are frequently:
  • Hidden in undeclared components: Package managers track only declared dependencies. Copied code snippets, AI-generated fragments, and transitive dependencies introduce licences that development teams are not aware of.
  • Conflicting across the dependency tree: A permissive MIT component may depend on a GPL library, creating copyleft obligations that propagate through the entire application.
  • Version-dependent: The same package may carry different licences across versions. Upgrading from 2.1.0 to 2.2.0 may introduce GPL obligations that were not present in the earlier release.
  • Misunderstood by developers: Many engineers cannot distinguish permissive from copyleft licences, or do not understand when GPL requires releasing proprietary source code.
  • Inadequately documented: Even when components are detected, mapping them to accurate licence information and understanding combined obligations requires specialised knowledge.
Consider a common scenario. A development team builds a proprietary SaaS application using React (MIT licence), which depends on a utility library (also MIT), which in turn depends on a GPL-licenced package three levels deep in the dependency tree. The GPL component goes undetected until a customer’s legal team reviews the Software Bill of Materials. The organisation must then either demonstrate that the GPL code does not create derivative work obligations under copyright law, or remediate the violation — either of which may constitute a breach of the customer contract. The fundamental challenge is visibility. Organisations cannot comply with obligations they are not aware of. Package-level scanning misses snippet-level copying. Manifest analysis ignores undeclared dependencies. Manual review does not scale. The gap between what teams believe they are using and what they are actually shipping creates persistent compliance risk.

​
Why Licence Compliance Matters Now

Multiple converging factors have made licence compliance urgent and unavoidable: Legal and Financial Risk: Licence violations create direct legal liability. Organisations face copyright infringement claims, breach of licence terms, and potential damages. GPL violations in proprietary software can trigger requirements to open source the entire application, converting significant proprietary IP value into public code. M&A Due Diligence: Acquisitions routinely uncover undisclosed open source licence violations during technical due diligence. These discoveries reduce valuations, create indemnification requirements (obligations to compensate the acquirer for any resulting losses), or cause deals to fail entirely. Buyers increasingly require comprehensive licence audits before closing, with violations treated as material adverse effects. Customer Contract Requirements: Enterprise customers and government agencies increasingly require Software Bills of Materials that accurately document all components and their licences. Contracts specify acceptable licence types, prohibit copyleft in certain contexts, and require regular compliance certification. Violations create contractual breach and financial penalties. Regulatory Pressure: Emerging regulations such as the EU Cyber Resilience Act require manufacturers to document software components and their licences. Compliance becomes a market access requirement, not merely a best practice. Organisations that cannot produce accurate SBOMs face regulatory barriers. Supply Chain Transparency: Customers, auditors, and partners increasingly require visibility into component sources and licence obligations. Organisations that cannot provide this information risk damaging business relationships and losing procurement opportunities. Open Source Community Trust: Serious licence violations damage relationships with the communities that produce the software on which organisations depend. Significant violations that become public can cause reputational harm that extends beyond legal consequences. AI-Generated Code Complications: AI coding assistants introduce a new compliance risk. Code generated by these tools may replicate open source implementations and carry associated licence obligations, even when it appears to be original. Traditional compliance approaches do not detect this source of risk.

​
Building a Strategy for Licence Compliance

Managing licence compliance requires comprehensive visibility across the entire software composition — not just declared packages, but every code fragment, regardless of how it entered the codebase. Modern DevSecOps teams need licence detection systems capable of identifying open source at the snippet level and mapping each component to accurate licence obligations. SCANOSS provides this capability through several complementary approaches: Snippet-level detection: Identifies open source code fragments — copied functions, utility classes, algorithm implementations — that do not appear in dependency manifests but carry licence obligations. Comprehensive licence knowledge base: Query against the SCANOSS licence dataset covering millions of open source components, mapped to SPDX (Software Package Data Exchange) standards with per-version licence metadata. Licence classification: Automatically classifies detected components as Permissive, Copyleft, Weak Copyleft, or Proprietary, enabling policy-based decisions without requiring legal review of every component. Conflict detection: Identifies incompatible licence combinations before they reach production — for example, GPL mixed with proprietary code, conflicting copyleft obligations, or missing attribution requirements. Transitive dependency analysis: Tracks licence obligations through the entire dependency tree, identifying indirect risks that package-level tools miss.

​
SCANOSS Solutions for Licence Compliance

The following tools and datasets are available for implementing licence compliance workflows. See the integration diagram below for guidance on which tool suits each use case.

​
Licence Dataset

The Licence Dataset delivers comprehensive licence metadata for millions of open source components, mapped to SPDX standards.

​
SCANOSS-PY

The SCANOSS-PY command-line scanner integrates licence detection directly into development workflows.

​
Pre-Commit Hooks

Automatically scans code before commits reach the repository.

​
SBOM Workbench

SBOM Workbench provides visual licence analysis and SBOM generation.

​
SCANOSS-CC

SCANOSS-CC detects hidden or risky open source code during active development.

​
SCANOSS API

Provides programmatic access to licence intelligence for custom integrations.

​
GitHub Actions

Automates scanning within CI/CD pipelines.

​
Next Steps

Licence compliance is a mandatory requirement for responsible software development and, increasingly, a prerequisite for market access. Organisations that address compliance reactively face violations discovered late, expensive remediation, release delays, and potential legal action. SCANOSS provides snippet-level open source detection, SPDX-mapped licence data, and CI/CD integration to help development teams identify and manage licence obligations throughout the development lifecycle. The goal is to give organisations the visibility needed to understand and fulfil their open source licence obligations — turning compliance blind spots into managed process.

​
Getting Started with Licence Compliance

Need help choosing the right tool? Contact our AI assistant