Open-Source Licensing in 2026: A Practical Guide for Developers

Open-source licensing has grown more complex and contentious over the past few years. The rise of cloud computing prompted several major projects to abandon traditional open-source licenses in favor of source-available alternatives. Developers who once could use anything on GitHub without thinking are now navigating a landscape where "open source" does not always mean what it used to.

At Git-Stars, we track license metadata whenever GitHub exposes it for an indexed repository. This guide explains the current state of open-source licensing, what the major licenses permit and restrict, and how to evaluate license compatibility for your projects.

Why Licensing Matters More Than Ever

In 2018, most developers could reasonably ignore licensing details for internal projects. The vast majority of popular libraries used MIT, BSD, or Apache 2.0—permissive licenses with minimal obligations. The ecosystem was simple.

Since then, several shifts have complicated the picture. Companies like MongoDB, Elastic, and HashiCorp moved to restrictive licenses to prevent cloud providers from offering their software as a service without contributing back. The Server Side Public License, Business Source License, and similar instruments created a new category—source-available but not open-source.

This matters for developers because license changes can retroactively affect your technology stack. When HashiCorp relicensed Terraform in 2023, every organization using Terraform had to evaluate their compliance posture. When Redis changed licenses, managed Redis offerings had to adapt or fork.

The Permissive Licenses

MIT License. The most popular license on GitHub by a wide margin. Permits commercial use, modification, distribution, and private use with minimal obligations—just include the copyright notice. Its brevity and clarity make it the default choice for most library authors.

Apache 2.0. Similar permissions to MIT but adds an explicit patent grant—contributors cannot later sue users for patent infringement related to their contributions. Also requires stating changes when distributing modified versions. Preferred by many corporate-backed projects for the patent protection.

BSD Licenses. The 2-clause BSD is functionally equivalent to MIT. The 3-clause BSD adds a non-endorsement clause preventing use of the author's name in promotional material. Both are permissive and commercially friendly.

The Copyleft Licenses

GPL v2 and v3. Require that derivative works also be distributed under the GPL. The definition of "derivative work" is where complexity lies—linking to a GPL library may or may not trigger the copyleft obligation depending on the nature of the link and which version applies. GPLv3 adds protections against patent claims and tivoization.

LGPL. A lighter copyleft that permits linking to the library from proprietary code without triggering copyleft—as long as the LGPL library itself remains redistributable in source form. Common for C libraries and some Java projects.

AGPL. Extends GPL's copyleft to network use—if you modify AGPL software and provide it as a service over a network, you must offer the source to users. This closes the "SaaS loophole" where cloud providers could modify and serve GPL code without distributing binaries.

The Source-Available Licenses

Server Side Public License (SSPL). MongoDB's creation, based on AGPL but with broader copyleft that requires releasing the entire service stack—not just the modified program—if you offer the software as a service. The Open Source Initiative does not consider it open-source.

Business Source License (BSL/BUSL). Permits use, modification, and redistribution with one restriction: a specified "additional use grant" limits certain commercial uses (typically running a competing service). The restriction automatically converts to a permissive license after a time period (usually 3-4 years).

Elastic License 2.0. Permits most uses but prohibits providing the software as a managed service and circumventing license key functionality. Simple and readable but not OSI-approved.

Evaluating License Compatibility

When combining dependencies with different licenses, compatibility determines what you can legally ship. Key rules:

Permissive licenses (MIT, Apache, BSD) are compatible with everything—you can include them in any project regardless of that project's license.

GPL code can incorporate permissively-licensed code, but the result must be distributed under GPL. The reverse is not true—you cannot include GPL code in a permissively-licensed project.

AGPL has the broadest reach—network interaction triggers disclosure obligations that surprise teams building internal services.

Apache 2.0 is incompatible with GPLv2 due to the patent clause (but compatible with GPLv3). This catches people who mix Apache-licensed and GPLv2-only dependencies.

Practical Recommendations

For library authors: MIT or Apache 2.0 maximizes adoption. Choose Apache 2.0 if patent protection matters for your domain.

For application developers: Check your full dependency tree, not just direct dependencies. Tools like FOSSA, Snyk, and GitHub's dependency graph help identify transitive license obligations.

For organizations: Establish a license allowlist. Most enterprises permit MIT, Apache 2.0, BSD, and ISC without review. LGPL requires case-by-case evaluation. GPL and AGPL require legal review. Source-available licenses require careful assessment of use restrictions.

Quick License Decision Matrix

Notable Relicensing Events (2023?026)

These events illustrate why tracking license metadata matters for long-term dependency management. For a broader framework on evaluating projects before adoption, see our safety checklist.

Repository profiles on Git-Stars display detected license metadata when it is available from GitHub. We highlight missing or ambiguous licenses and use license type as one input in search, ranking, and editorial analysis.

Our license tracking helps developers quickly identify when a project they depend on changes terms—an increasingly common event that warrants attention in your dependency management process.