Open Source Licensing Explained: MIT, GPL, Apache and More

Open Source Licensing Explained: MIT, GPL, Apache and More

The Strategic Importance of Open Source Licenses

Choosing an open source license is one of the most consequential legal decisions a developer or organization can make. A license dictates how others can use, modify, and distribute your code. It balances the freedom of the developer against the rights of downstream users, shaping entire software ecosystems. The Open Source Initiative (OSI) maintains a list of approved licenses, but the vast majority of projects gravitate toward a small handful: MIT, GPL, and Apache. Understanding the nuances between these and other licenses is essential for compliance, project adoption, and commercial strategy.

Permissive vs. Copyleft: The Fundamental Divide

All open source licenses fall into two broad categories: permissive and copyleft. Permissive licenses (MIT, Apache, BSD) impose minimal restrictions on redistribution. They allow users to incorporate the code into proprietary software, often without disclosing source code changes. Copyleft licenses (GPL, AGPL) require that derivative works remain under the same license, ensuring that modifications and linked software also stay open. This division reflects a philosophical split: permissive licenses prioritize developer freedom and adoption, while copyleft licenses prioritize user freedom and community protection.

The MIT License: Simplicity and Maximum Permissiveness

The MIT License is the most adopted open source license on platforms like GitHub. It is a short, terse document—roughly 200 words—granting users permission to “use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software.” The only condition is that the original copyright notice and permission notice appear in all copies or substantial portions of the software. There is no requirement to share modifications or credit beyond that notice. This makes MIT ideal for libraries, frameworks, and small utilities where the developer wants maximum adoption without legal overhead. Example projects: React, Node.js, jQuery. Risk: A competitor can take your MIT-licensed code, embed it in a proprietary product, and sell it without ever contributing back.

The GNU General Public License (GPL): Strong Copyleft Protection

The GPL, created by Richard Stallman and the Free Software Foundation, is the archetypal copyleft license. Version 2 (GPLv2) and Version 3 (GPLv3) are both common. The GPL requires that any derivative work distributed to the public must be licensed under the GPL itself. This “viral” or “reciprocal” effect ensures that improvements remain free. GPLv3 added specific protections against patent retaliation and hardware restrictions (Tivoization). A key nuance is the distinction between a mere “aggregate” (separate programs on the same storage medium) and a “combined work” (modules that link together). GPL is often chosen for operating system kernels, developer tools, and foundational infrastructure. Example projects: Linux kernel (GPLv2), WordPress (GPLv2), Git (GPLv2). Risk: If you distribute software that links to GPL code, you must release your entire application under the GPL, which can conflict with proprietary business models.

The GNU Affero General Public License (AGPL): Closing the “Application Service Provider” Loophole

Traditional GPL licenses contain a loophole for network-based software. If you modify a GPL program and run it on your server, you are not “distributing” it in the traditional copyright sense, so you are not required to release your modified source code. The AGPL closes this by explicitly stating that users interacting with the software over a network are receiving it in a manner equivalent to distribution. This forces companies using AGPL code in their SaaS products to release their modifications. AGPL is popular for web frameworks (MongoDB before its own SSPL license), social networking platforms, and server utilities where the developer wants to ensure that cloud providers contribute back. Risk: AGPL is often considered too restrictive for commercial adoption, potentially limiting your project’s user base.

The Apache License 2.0: Permissive with Explicit Patent Grants

The Apache License 2.0 is a permissive license similar to MIT but with critical additions: a clear patent grant and termination clauses. Under Section 3, each contributor grants a patent license for any patents they hold that cover their contributions. If a user initiates a patent lawsuit against the project, their patent license is automatically terminated. The license also requires a clear attribution of changes (a “NOTICE” file) and explicitly protects trademarks. This makes Apache 2.0 the preferred choice for corporate-backed projects and large enterprise software. Example projects: Kubernetes, TensorFlow, Android. Risk: While permissive, the notice requirement can add administrative overhead for downstream users, though it is generally minor.

BSD Licenses (2-Clause, 3-Clause, 4-Clause)

The BSD family of licenses is functionally similar to MIT but with historical variations. The 2-Clause BSD is almost identical to MIT. The 3-Clause BSD adds a “no endorsement” clause, prohibiting the use of the institution’s name to promote derivatives without permission. The 4-Clause BSD (rarely used today) included an “advertising clause” requiring all advertisements to acknowledge the University of California. BSD licenses are common in academic and research projects. Key difference from MIT: BSD licenses explicitly use “Redistribution and use in source and binary forms, with or without modification,” and the 3-Clause version explicitly blocks endorsement claims.

Mozilla Public License (MPL 2.0): A Weak Copyleft Compromise

The Mozilla Public License 2.0 occupies a middle ground between permissive and strong copyleft. It is a file-level copyleft license. If you modify a file that is under MPL, you must release that specific file under the MPL. However, you can combine MPL-licensed files with proprietary files in a larger work (like an executable), and the proprietary files do not need to be MPL’d. This makes MPL attractive for projects that want to ensure contributions are open but allow integration with proprietary systems. Example projects: Mozilla Firefox, LibreOffice. Risk: The file-level boundary can become ambiguous in languages with complex compilation models, and tracking modified files requires diligence.

Lesser General Public License (LGPL): Copyleft for Libraries

The LGPL was designed specifically for software libraries. It allows proprietary applications to link to the LGPL-licensed library without becoming subject to the GPL’s viral effect. However, if the user modifies the library itself, those modifications must be released under the LGPL, and users must be able to “re-link” the library with their proprietary application. The LGPL is common for system libraries (glibc) and widely used programming language standard libraries. Risk: The compatibility requirements for binary distribution (providing object files) can be cumbersome, and some interpretations blur the line with GPL.

Unlicense and CC0: Public Domain Dedication

The Unlicense and Creative Commons Zero (CC0) are not strictly licenses; they are tools to dedicate a work to the public domain. They waive all copyright rights to the maximum extent permitted by law. However, many legal systems do not recognize a complete waiver of moral rights or future copyright claims, which introduces legal uncertainty. These are suitable for very small code snippets, configuration files, or data sets. Risk: Because the dedication is not legally ironclad in all jurisdictions (particularly in Germany or France), many developers prefer MIT for simplicity and clarity, even if they intend their code to be effectively public domain.

How Licenses Interact: Compatibility and Mixing

One of the most complex aspects of open source licensing is license compatibility—whether code under one license can be combined with code under another. For example, MIT-licensed code can be incorporated into a GPL project, but GPL code cannot be placed into an MIT project because the GPL’s stricter terms must apply to the whole. Apache 2.0 code is compatible with GPLv3 but not with GPLv2 (due to patent termination clauses). LGPL code can be linked from non-GPL code, but the LGPL library itself must remain LGPL. AGPL is the most restrictive: it is incompatible with GPL if you want to incorporate AGPL code into a GPL project without specific workarounds. The Free Software Foundation and the OSI maintain compatibility charts, but consulting a lawyer is recommended for complex integrations.

Common Misconceptions and Pitfalls

Developers often assume that “open source” means “anyone can use it for free without any restrictions.” This is false. Every license imposes conditions, even if minimal. A common mistake is failing to include the license file or copyright notice in the distribution, which voids the license grant and makes the user vulnerable to copyright infringement claims. Another error is assuming that “viral” means you must release your entire company’s source code; the GPL only applies to the software you distribute, not internal use. Finally, many developers forget that trademarks are not covered by open source licenses—you cannot use the name “Apache” or “Python” on your product without permission.

Choosing the Right License for Your Project

The selection depends on your goals. If you want maximum adoption and minimal friction for commercial users, choose MIT. If you want to protect user freedoms and ensure contributions are shared, choose GPLv3. If you are building a corporate project with patent concerns, choose Apache 2.0. If you have a library that should be usable in proprietary software, choose LGPL or MIT. If you run a SaaS platform and want to prevent cloud providers from exploiting your code without contributing, choose AGPL. If you want balance with strong contributions but commercial compatibility, choose MPL 2.0. If you want a public domain declaration and accept the legal risks, choose Unlicense.

The Role of Dual Licensing and Business Models

Some projects use dual licensing to serve both open source and commercial users. For example, MySQL (GPLv2) and Qt (LGPL/GPL) offer the same code under a copyleft license and a separate proprietary commercial license. This allows companies to use the software for free under the open source license if they comply, or pay for a commercial license if they need to embed the code in proprietary products without releasing source code. Dual licensing requires the copyright holder to own all contributions (through Contributor License Agreements), which adds administrative complexity.

License Enforcement and Community Governance

Enforcement of open source licenses is rare but increasing. The most famous cases involve the GPL, such as the BusyBox lawsuits (2006–2010) and the VMware (now Broadcom) Linux kernel dispute. Usually, enforcement aims for compliance (releasing source code) rather than damages. Many projects also rely on community norms alongside licenses. A license cannot enforce contributions, code quality, or behavior; that requires a Code of Conduct and governance model. The license only governs copyright and patents.

The Impact of Forking and Permissions

A permissive license allows anyone to fork the project at any time without restriction. This is why React (MIT) can have multiple forks (Preact, Inferno). A copyleft license also allows forking, but all forks must remain under the same license. This prevents proprietary versions from forking Linux or GIMP and then closing the code. The business implication is significant: permissive licenses encourage ecosystem diversity but can fragment contributions; copyleft licenses ensure unified community investment but can limit commercial adoption.

The Future: SSPL, Elastic License, and Source-Available Models

Recent years have seen a shift away from traditional OSI-approved licenses. MongoDB created the Server Side Public License (SSPL) to close the AGPL’s perceived weaknesses for cloud providers. Redis Labs moved to the Business Source License (BSL) , which offers open source code with a time-limited commercial restriction. These “source-available” licenses are not classified as open source by the OSI but are widely used. They reflect the tension between the ideal of unrestricted software and the economic reality of cloud service providers profiting from open source projects without contributing. Developers should understand that using these licenses means your project will not be considered “open source” by the OSI definition, which can affect community perception and downstream tooling.