Open source isn't a tactic anymore. It's the operating system of modern business. The 2026 State of Open Source Report from Perforce OpenLogic, OSI, and the Eclipse Foundation confirms what engineers already feel: OSS is now core enterprise infrastructure. But with adoption comes pressure — around sustainability, governance, funding, and licensing. If you're shipping code in 2026, you need to understand the license landscape cold.
Why Licenses Still Matter
Licenses aren't legal theater. They define who can use your code, how they must contribute back, and whether your project survives commercial pressure. The wrong choice kills adoption. The right one builds a moat. In 2026, three forces drive license decisions: supply chain compliance (SBOMs, SLSA), AI training data disputes, and the rise of source-available "fair code" licenses that look open but aren't OSI-approved.
| License | Type | Copyleft | Patent Grant | Best For |
|---|---|---|---|---|
| MIT | Permissive | No | No | Libraries, SDKs, max adoption |
| Apache 2.0 | Permissive | No | Yes | Enterprise projects, patent-heavy domains |
| GPL-3.0 | Strong Copyleft | Yes | Yes | Applications, forcing contribution back |
| LGPL-3.0 | Weak Copyleft | Library-level | Yes | Shared libraries, proprietary apps |
| BSD-3-Clause | Permissive | No | No | Kernel modules, standards bodies |
| MPL 2.0 | File-level Copyleft | Per file | Yes | Mixed proprietary/open codebases |
| AGPL-3.0 | Network Copyleft | Yes (SaaS) | Yes | Hosted services, preventing cloud strip-mining |
| BSL/SSPL | Source-Available | Varies | Varies | Commercial OSS (not OSI-approved) |
Permissive vs. Copyleft: The Real Trade-off
Permissive licenses (MIT, Apache, BSD) optimize for adoption. Anyone can bundle, modify, and sell your code without giving back. That's great for standards and infrastructure — think React, Kubernetes, Go. But it enables "strip-mining": cloud providers wrapping your project as a managed service without contributing upstream.
Copyleft (GPL, AGPL) forces derivatives to stay open. AGPL closes the SaaS loophole: if users interact with your code over a network, they must get the source. That's why MongoDB, Redis, and Elastic switched to SSPL/BSL — AGPL wasn't enough to stop AWS.
"The license is your project's constitution. Write it for the world you want, not the world you have.
— Heather Meeker, OSS Attorney
New Pressures in 2026
AI training is the new battlefield. Permissive code scraped into LLMs raises unresolved copyright questions. Some projects now add "no AI training" clauses — making them non-OSI-compliant. Meanwhile, SBOM mandates (EO 14028, EU CRA) mean enterprises audit every transitive dependency. A weird license blocks adoption in regulated sectors.
Funding models are shifting too. GitHub Sponsors, OpenCollective, and corporate backers (via OpenSSF) sustain maintainers. But burnout remains rampant. License choice signals intent: AGPL says "pay us or contribute." MIT says "take it, we'll figure it out."
💡
TipDefault to Apache 2.0 for new libraries. It gives you patent protection, clear attribution, and maximum enterprise adoption. Add a NOTICE file for third-party credits.
Decision Framework
Ask three questions:
- Is this a library or an application? Libraries → permissive. Apps → copyleft.
- Do competitors run this as a service? Yes → AGPL or BSL.
- Does your org require patent grants? Yes → Apache 2.0 or GPL-3.0.
Document the decision in CONTRIBUTING.md. Future maintainers will thank you.
Community Is the Real License
No license enforces itself. Community does. Projects with clear governance (BDFL, steering committee, meritocracy) survive license changes. Projects without it fork and die. The 2026 report shows 68% of maintainers cite "lack of contributors" as their top risk — not license confusion.
Invest in onboarding: good first issues, mentorship, codes of conduct. Make contributing easier than forking. That's how you keep the project alive, regardless of the license text.
✦
ℹ️
NoteWatch the 2026 State of Open Source webinar for the full data: https://ter.li/2kn3s1hb
