version v7.2.
For up-to-date documentation, see the
latest version.
License
6 minute read
Open Source licenses govern how software can be used, modified, and distributed. Understanding them — and the risks of getting them wrong — is essential to building software responsibly at scale.
Why License Risk Management Matters
The 2026 Open Source Security and Risk Analysis (OSSRA) Report documents a software landscape that has fundamentally changed:
- Mean open source components per codebase have grown to 1,180
- License conflicts have reached their highest levels in OSSRA history
- 98% of audited codebases contain open source components
- File counts have quadrupled over five years, driven in part by AI-assisted coding
This should not induce Fear, Uncertainty and Doubt (FUD).
The conclusion is not “Open Source is too dangerous, don’t use it”.
Quite the contrary: Open Source brings immense value and should be used responsibly.
According to the Harvard Business School Working Paper The Value of Open Source Software , firms would need to spend 3.5× more on software than they currently do if open source did not exist — with a demand-side value estimated at $8.8 trillion.
Since open source has become effectively universal, the real question is whether your organization has the visibility, intelligence, and processes to manage its license risk at this scale.
License Categories
Not all open source licenses impose the same obligations. The table below summarizes the main families, their key obligations, and their compatibility risk profile.
| Category | Examples | Key Obligations | Compatibility Risk |
|---|---|---|---|
| Permissive | MIT, Apache-2.0, BSD-2-Clause | Attribution only | Low |
| Weak Copyleft | LGPL-2.1, MPL-2.0, EUPL | Modifications to the library itself must be shared | Medium |
| Strong Copyleft | GPL-2.0, GPL-3.0 | Derivative works must be distributed under the same license | High |
| Network Copyleft | AGPL-3.0 | Extends copyleft to network use (SaaS) | High |
| Source Available | BUSL, SSPL | Source is visible but does not meet the Open Source Definition | Medium–High |
| No License | (none stated) | All rights reserved — do not use | Critical |
Having access to source code on GitHub or anywhere else does not mean it is Open Source. Without an explicit license, all rights are reserved and the software must not be copied, distributed, or modified. See No License .
License Definitions
Free Software
The Free Software Definition is published by the Free Software Foundation (FSF), which maintains a list of free software licenses .
Open Source
The Open Source Definition is published by the Open Source Initiative (OSI), which maintains a list of Open Source licenses .
The FSF and OSI lists overlap significantly in practice. Most popular licenses are approved by both, though a few exceptions exist.
Source Available
Open source doesn’t just mean access to the source code.
Access to source code is necessary but not sufficient. The Open Source Definition sets additional criteria around redistribution, modification, and non-discrimination. Software that provides source access without meeting these criteria is called source-available.
Examples include the Business Source License (BUSL) and the Server Side Public License (SSPL) .
Common Conflict Patterns
The 2026 OSSRA Report identifies four recurring conflict patterns in codebases:
Copyleft vs. proprietary distribution. Strong copyleft licenses like GPL require that derivative works be distributed under the same license terms. Including GPL-licensed code in proprietary software — without releasing the proprietary code under GPL — violates the license.
License version incompatibilities. GPL v2 and GPL v3 are not automatically compatible. Code licensed under “GPL v2 only” cannot be combined with code licensed under “GPL v3 or later” without violating one or both licenses.
Attribution requirement conflicts. Some licenses require specific attribution formats, placement, or prominence. When multiple components have conflicting attribution requirements, satisfying all of them may be impractical or impossible.
Component-to-component conflicts. Two open source components in the same application may have mutually incompatible licenses, even if neither conflicts with the application’s own licensing.
In addition, some licenses (notably AGPL) introduce two further dimensions:
- Network use as distribution — SaaS deployments are treated as distribution, meaning AGPL’s copyleft requirements apply even if the software is never shipped to a user.
- Express patent grant — contributors grant an explicit patent license, which has legal implications beyond copyright.
Open Source license compliance is enforced in court. Violations are not theoretical — litigation and formal notices are well-documented across the industry.
Example: GPL-2.0-only in a Proprietary Application
This example is for illustration only and does not constitute legal advice. For concrete decisions about GPL and proprietary software, request help .
To illustrate how license conflicts surface in practice:
| Step | Detail |
|---|---|
| Dependency added | A developer adds library-x, licensed under GPL-2.0-only |
| SCA scan detects it | The tool flags a conflict with the application’s proprietary license |
| Conflict assessed | GPL-2.0-only requires any derivative work to be distributed under GPL-2.0 |
| Options evaluated | (1) Remove the dependency, (2) Replace with a permissively-licensed alternative, (3) Seek a commercial license, (4) Consult the Software Compliance Team |
| Resolution | The Software Compliance Team reviews the use case and recommends the least-impact path |
“GPL-2.0-only” and “GPL-2.0-or-later” are distinct identifiers. A dependency licensed as “GPL-2.0-only” cannot be upgraded to GPL-3.0 compatibility, whereas “GPL-2.0-or-later” can.
How SCA Tools Use License Data
Software Composition Analysis (SCA) tools help organizations identify and manage license risk by combining multiple data sources:
- Component identification: Match components in your SBOM against license databases
- License Classification: Retrieve the standardized license identifier for each component
- Copyleft detection: Flag components with strong, weak, or network copyleft licenses
- Conflict analysis: Detect license incompatibilities between components, and between components and the application’s own license
- Policy enforcement: Apply organization-defined rules (e.g., Xray rules to “block Download of any AGPL dependency”)
License Indicators by Tool
The table below covers only indicators that are unambiguously documented for each tool. For a full comparison, refer to each vendor’s documentation linked below.
| Indicator | GitLab SCA | JFrog Xray | Black Duck |
|---|---|---|---|
| Classification | ✅ | ✅ | ✅ |
| Copyleft Classification | ❌ | ❌ | ✅ |
| Multi-license Components | ❌ | ✅ | ✅ |
| Policy Enforcement | ✅ | ✅ | ✅ |
Legend: ✅ Native feature | ⚠️ Partial or Workaround | ❌ Not available
SCA tools rely primarily on declared license metadata (e.g., package.json, pom.xml).
Coverage varies for licenses embedded in source files, dual-licensing arrangements,
and custom license texts. Verify each tool’s actual behavior in your environment
before relying on it for compliance decisions.
License Data Sources
License information comes from a layered set of sources, analogous to vulnerability databases:
- Normative definitions (authoritative license texts and classifications):
- OSI Approved Licenses — the canonical Open Source list
- FSF Free Software Licenses — FSF’s categorization, including compatibility notes
- Community enrichment (broader coverage and curation):
- ClearlyDefined — community-curated license data for open source components, covering cases where declared metadata is absent or ambiguous
- GitHub Advisory Database — includes license metadata for ecosystem packages
- Commercial enrichment (proprietary research and early detection):
- Black Duck KnowledgeBase — covers license obligations, compatibility, and dual-licensing arrangements, with independent analysis ahead of community sources
OSI and FSF define whether a license is considered Open Source or Free Software, but do not strictly dictate Thales internal policy.
Who Can Help
Thales has a Software Compliance Team that is available to help after you have performed a Software Composition Analysis (SCA) .
Contact: oss-query@thalesgroup.com
The team has processes and resources including:
- OSS Leaflet — a summary of rights and obligations for the most commonly encountered licenses.
- OSS Memo — a knowledge base of all licenses analyzed and categorized by the Software Compliance Team.