Documentation Index
Fetch the complete documentation index at: https://docs.scanoss.com/llms.txt
Use this file to discover all available pages before exploring further.
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.
The Licence Dataset delivers comprehensive licence metadata for millions of open source components,
mapped to SPDX standards.
The SCANOSS-PY command-line scanner integrates licence detection directly into development workflows.
Automatically scans code before commits reach the repository.
SBOM Workbench provides visual licence analysis and SBOM generation.
SCANOSS-CC detects hidden or risky open source code during active development.
Provides programmatic access to licence intelligence for custom integrations.
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
