License conflicts in commercial codebases hit 68% in 2026 — the largest single-year jump in the history of Black Duck’s annual open source risk report. Permissive licenses now hold 78% of all open source components, yet the Linux kernel remains locked to GPLv2 permanently. This article covers verified 2024–2026 data on license distribution across package managers, commercial codebases, and the Linux-specific software stack.
Open Source License Usage in Linux Projects: Key Statistics
- Permissive licenses account for 78% of all open source components as of 2024, up from 76% the year before.
- 68% of commercial codebases had license conflicts in 2026, the biggest year-over-year increase in OSSRA report history.
- MIT appears in 92% of commercial codebases, making it the most widely present license in enterprise software.
- 77.7% of GitLab repositories created between Q2 2019 and Q1 2020 had no license file at all.
- GPLv2 appears 34 times more often on GitHub than in package manager dependency data, reflecting the kernel/cloud split.
How Are Open Source Licenses Distributed Across the Linux Ecosystem?
Apache 2.0 peaked at roughly 30% of top licenses in 2021–2022, driven by the Cloud Native Computing Foundation’s mandate that hosted projects like Kubernetes use it, along with the rise of TensorFlow and PyTorch. By 2023, MIT spiked back upward while Apache usage dropped, though that shift partly reflects changes in dataset composition.
GPLv2 and GPLv3 combined held about 18% of top licenses in 2021, continuing a decline that stretches back to the early 2000s when restrictive licenses held over 70% of C-language projects. The GPL family’s combined copyleft share — including LGPL — sat at 22% in 2022.
| License | Share | Type | Key Characteristic |
|---|---|---|---|
| Apache 2.0 | ~30% (2021–22 peak) | Permissive | Explicit patent grant; standard for CNCF projects |
| MIT | ~26–32% | Permissive | Simplest permissive; widest adoption across ecosystems |
| GPLv3 | ~9% | Strong copyleft | Requires source release of all derivatives |
| GPLv2 | ~9% | Strong copyleft | Linux kernel license; used in older projects |
| BSD 3-Clause | ~7% | Permissive | Common in academic and networking code |
| LGPL (all versions) | ~3–5% | Weak copyleft | Allows proprietary linking; standard in system libraries |
| BSD 2-Clause | ~4% | Permissive | Minimal restrictions; widely compatible |
| All permissive combined | 78% (2024) | Permissive | Up from 76% the prior year |
Source: Mend.io analysis of 4 million+ open source packages; OSI 2024 pageview data
Open Source License Usage by Package Manager
Maven’s Java ecosystem is the most concentrated of any major package manager: 69.18% of components use Apache 2.0 alone. That reflects the Apache Software Foundation’s central role in Java infrastructure and the license preferences of large corporate contributors. npm skews heavily toward MIT at 53%, partly because npm’s initialization tool historically defaulted to the ISC license, which carries similar permissive terms.
PyPI is more fragmented. MIT leads at 29.14%, Apache 2.0 follows at 23.98%, and both BSD 2-Clause and GPLv3 each hold around 6%. Python’s scientific and data tooling heritage, which includes many GPL-licensed academic projects, explains the higher copyleft presence compared to JavaScript.
| Package Manager | Top License | Share | Second License | Share |
|---|---|---|---|---|
| npm (JavaScript) | MIT | 53% | Apache 2.0 | 14.76% |
| Maven (Java) | Apache 2.0 | 69.18% | MIT | 7.4% |
| PyPI (Python) | MIT | 29.14% | Apache 2.0 | 23.98% |
| NuGet (.NET) | MIT | 21.55% | Apache 2.0 | 13.37% |
Source: OSI citing ClearlyDefined 2023 dataset
How Common Are Missing Licenses in Open Source Repositories?
34% of GitHub repositories and 77.7% of GitLab repositories created between Q2 2019 and Q1 2020 had no license file. Without a license, default copyright law applies — users have no legal right to reuse, modify, or distribute the code. The ClearlyDefined project was created specifically to crowdsource license metadata for the millions of components in this state.
NuGet compounds this further: 26.76% of packages carry no license declaration, and another 31.95% carry a “NOASSERTION” field, meaning automated tools cannot determine license status. For developers building on .NET, more than half of NuGet packages require manual license review before compliance can be confirmed.
| Platform | Repos Without a License | Period |
|---|---|---|
| GitHub | 34% | 2018–2020 |
| GitLab | 77.7% | Q2 2019–Q1 2020 |
| NuGet (no license declared) | 26.76% | 2023 dataset |
| NuGet (NOASSERTION field) | 31.95% | 2023 dataset |
Source: EPAM SolutionsHub; OSI citing ClearlyDefined 2023 dataset
What Do the OSSRA 2025 and 2026 Reports Show About Commercial Codebases?
97% of commercial codebases contained open source components according to the 2025 OSSRA. The average application included 911 open source components, with 64% of those being transitive dependencies — packages pulled in indirectly through other packages. Transitive dependencies accounted for roughly 30% of all license conflicts detected.
The 2026 report put the license conflict rate at 68%, up from 56% the year before. Black Duck attributed the spike to AI code generation tools producing code derived from GPL-licensed sources without preserving the original license information. When that code enters a commercial codebase distributed under permissive terms, it creates a compliance violation that standard manifest scanning won’t catch.
| Metric | 2025 OSSRA | 2026 OSSRA |
|---|---|---|
| Codebases containing open source | 97% | No material change |
| Avg. open source components per app | 911 | 30% higher YoY |
| Open source files per app | 16,082 (vs. 5,386 in 2020) | +74% mean file growth |
| Codebases with license conflicts | 56% | 68% — largest YoY increase on record |
| MIT present in codebase | 92% | — |
| Transitive deps as % of open source | 64% | 65% |
| Components with no or custom license | 33% | — |
Source: Black Duck 2025 OSSRA; Black Duck 2026 OSSRA
GPL License Usage in Linux-Specific Contexts
The Linux kernel is permanently GPLv2. Linus Torvalds has explicitly declined to upgrade to GPLv3, citing concerns about hardware restrictions clauses. All kernel modules must be GPL-compatible, which makes GPLv2 structurally embedded in the Linux system development layer regardless of broader permissive trends.
The 34× difference between GPLv2 prevalence on GitHub versus package manager dependency data reflects the ecosystem split. GitHub hosts the kernel, kernel modules, and desktop Linux projects built on copyleft foundations. Cloud-native package registries — the repos that feed Kubernetes clusters and web backends — are overwhelmingly permissive.
A documented trend in 2025–2026 sees some GPL-licensed projects moving to AGPLv3, which closes the SaaS loophole. Under standard GPL, cloud providers can run software as a hosted service without triggering source-release obligations. AGPL requires disclosure even in that case. Signal and several cloud-focused projects have adopted this approach, though the aggregate license count shift remains too small to appear in the overall statistics yet.
| License | Context | Status / Trend |
|---|---|---|
| GPLv2 | Linux kernel | Permanent; GPLv3 upgrade explicitly declined |
| GPLv2 | WordPress | Strongest copyleft enforcement in CMS space |
| GPLv3 | Grafana (pre-relicense) | Several major projects migrated away in 2024 |
| AGPLv3 | Signal, some cloud tools | Growing adoption as SaaS loophole response |
| LGPL | FFmpeg, GNU C Library | Standard weak-copyleft option for Linux system libraries |
Source: RedMonk State of Open Source Licensing 2026; Wikipedia
Open Source License Statistics at a Glance (2024–2026)
| Metric | Figure | Source |
|---|---|---|
| Permissive license share (2024) | 78% | Mend.io |
| Copyleft share, GPL+LGPL (2022) | 22% | Mend.io |
| Apache 2.0 peak share (2021–22) | ~30% | Mend.io |
| OSI most-viewed license (2024) | MIT — 1.7 million views | OSI 2024 |
| npm MIT share | 53% | OSI / ClearlyDefined 2023 |
| Maven Apache 2.0 share | 69.18% | OSI / ClearlyDefined 2023 |
| Commercial apps containing open source | 97% | Black Duck 2025 OSSRA |
| Avg. open source components per app | 911 | Black Duck 2025 OSSRA |
| MIT in commercial codebases | 92% | Black Duck 2025 OSSRA |
| Codebases with license conflicts (2026) | 68% | Black Duck 2026 OSSRA |
| GitHub repos with no license | 34% | EPAM SolutionsHub |
| GitLab repos with no license | 77.7% | EPAM SolutionsHub |
| GPLv2 on GitHub vs. package managers | 34× more common on GitHub | RedMonk 2026 |
Sources: Mend.io; Black Duck 2025 and 2026 OSSRA; OSI; EPAM SolutionsHub; RedMonk 2026
FAQs
What is the most commonly used open source license in Linux projects?
MIT is the most widely present license, appearing in 92% of commercial codebases. Apache 2.0 dominates cloud-native projects. The Linux kernel itself uses GPLv2 exclusively and will not be upgraded to GPLv3.
Why did license conflicts in commercial software jump in 2026?
Black Duck’s 2026 OSSRA attributes the 68% conflict rate — up from 56% — to AI code generation tools producing GPL-derived code without preserving original license metadata, a pattern referred to as “license laundering.”
Are permissive or copyleft licenses more common in open source today?
Permissive licenses hold 78% of all open source components as of 2024. Copyleft licenses, including all GPL and LGPL variants, account for roughly 22%, down from over 40% historically.
How many open source repositories have no license at all?
34% of GitHub repositories and 77.7% of GitLab repositories created in the analyzed period had no license file. Without a license, users technically have no legal right to reuse or modify the code.
What license does the Linux kernel use and can it change?
The Linux kernel uses GPLv2. Linus Torvalds has explicitly stated it will not be upgraded to GPLv3, primarily due to concerns about the latter’s hardware anti-tivoization restrictions. This is effectively permanent.
