Open Source Licenses Explained: MIT, GPL, Apache and More
In This Guide
What Are Open Source Licenses?
An open source license is a legal agreement attached to software source code that grants users specific rights to view, modify, and redistribute that code. Without a license, source code defaults to standard copyright protections, meaning no one can legally copy, modify, or distribute it regardless of whether the code is publicly visible on a platform like GitHub.
The Open Source Initiative (OSI) maintains the official Open Source Definition, a set of ten criteria that a license must meet to qualify as genuinely open source. These criteria require that the license allow free redistribution, provide access to source code, permit derived works, and avoid discriminating against specific people, groups, or fields of use. Over 100 licenses have received OSI approval, though the vast majority of open source projects use one of about a dozen widely recognized licenses.
Open source licenses exist on a spectrum. On one end, permissive licenses like MIT and BSD impose minimal restrictions, essentially allowing anyone to do almost anything with the code as long as they preserve the copyright notice. On the other end, copyleft licenses like the GNU General Public License (GPL) require that derivative works also be released under the same or a compatible open source license, ensuring that the code and its descendants remain freely available.
The choice of license shapes how a project grows, who contributes to it, and how businesses can incorporate it. A permissive license makes adoption easy for companies building proprietary products, while a copyleft license protects against proprietary capture of community-developed code. Neither approach is universally better, and the right choice depends on a project's goals, its community, and the ecosystem it operates in.
Why Licensing Matters for Every Developer
Licensing is not just a legal formality that sits in a LICENSE file and gets ignored. It has direct, practical consequences for developers, companies, and the broader software ecosystem. Understanding these consequences is essential whether you are releasing your own code, contributing to someone else's project, or incorporating open source dependencies into a commercial product.
For project maintainers, the license determines who will use and contribute to your code. Choosing a permissive license like MIT tends to maximize adoption because it places almost no restrictions on downstream users. Large companies are more willing to build on MIT-licensed code because they can integrate it into proprietary products without worrying about disclosure obligations. Choosing a copyleft license like GPL v3, on the other hand, ensures that improvements stay in the open source ecosystem but may discourage commercial adoption by companies that do not want to open-source their own code.
For businesses that consume open source software, license compliance is a serious operational concern. Companies typically maintain a software bill of materials that tracks every open source dependency, its license, and any obligations that license creates. A single GPL-licensed library deep in a dependency tree can create obligations that ripple up through an entire product. Legal teams at major technology companies review license compatibility before approving the use of any open source component, and getting this wrong can lead to litigation, forced code disclosure, or expensive re-engineering to remove a problematic dependency.
For individual contributors, understanding licensing matters because your contributions to an open source project fall under that project's license. If you contribute code to a GPL-licensed project, your contribution becomes GPL-licensed code. Some projects also require contributors to sign a Contributor License Agreement (CLA) that grants the project additional rights over contributed code, sometimes including the right to relicense it. Knowing what rights you are granting when you submit a pull request is a basic part of responsible open source participation.
License disputes have real consequences. Courts have consistently ruled that violations of open source licenses constitute copyright infringement, reinforcing that these licenses are legally enforceable agreements. The Software Freedom Conservancy and the Free Software Foundation have both pursued legal action to enforce GPL compliance, and companies have paid settlements and been forced to release source code as a result. Treating licensing as an afterthought is a risk no professional developer or organization should take.
Permissive vs Copyleft: The Two License Families
Every major open source license falls into one of two broad categories: permissive or copyleft. Understanding this distinction is the foundation for understanding everything else about open source licensing.
Permissive licenses grant broad freedoms with minimal conditions. The typical requirements are simple: preserve the copyright notice, include the license text when redistributing, and sometimes include a disclaimer of warranty. Beyond these basic requirements, permissive licenses place no restrictions on what you do with the code. You can modify it, incorporate it into proprietary software, sell products built on it, and redistribute it under any license you choose. The MIT License, Apache License 2.0, and BSD licenses are the most prominent permissive licenses.
Copyleft licenses add one fundamental requirement on top of the freedoms that permissive licenses grant: if you distribute modified versions of the software, you must make your modifications available under the same license. This is sometimes called the "share-alike" condition, and it is the defining characteristic of copyleft. The GNU General Public License (GPL) is the most well-known copyleft license. The idea behind copyleft is that software freedom should be preserved through all derivative works, preventing anyone from taking open source code and making it proprietary.
Within the copyleft family, there are important distinctions in how strongly the share-alike requirement applies. Strong copyleft licenses like GPL v3 require that any software that incorporates GPL code must itself be released under the GPL. This extends to linking, meaning that a proprietary application cannot dynamically link against a GPL library without the entire application becoming subject to the GPL. Weak copyleft licenses like the GNU Lesser General Public License (LGPL) and the Mozilla Public License (MPL) are more limited in scope. The LGPL allows proprietary software to link against LGPL libraries as long as the library itself remains open source. The MPL applies copyleft at the file level, so modifications to MPL-licensed files must stay open source, but new files in the same project can use any license.
The practical impact of this distinction is significant. A company building a proprietary product can freely use MIT or Apache-licensed code as dependencies. It can use LGPL-licensed libraries if it links to them dynamically and keeps the library code accessible. But using GPL-licensed code in a proprietary product requires either open-sourcing the entire product or finding an alternative dependency. This is why license choice has such a direct effect on adoption patterns and why the copyleft vs permissive debate is one of the most consequential discussions in the open source world.
The Most Widely Used Open Source Licenses
While over 100 open source licenses exist, a small number dominate the landscape. According to analyses of public repositories on GitHub and GitLab, these licenses cover the vast majority of open source code worldwide. For a detailed side-by-side breakdown, see our open source license comparison chart.
MIT License
The MIT License is the most popular open source license by a wide margin. It is used by projects ranging from React and Node.js to Ruby on Rails and jQuery. The full license text is only about 170 words, making it one of the shortest and simplest licenses in use. It permits commercial use, modification, distribution, and private use with only two conditions: include the copyright notice and license text in copies, and acknowledge that the software comes with no warranty.
The MIT License's popularity comes from its simplicity and permissiveness. It is easy for developers to understand without legal training, and it places essentially no burden on users. Companies can incorporate MIT-licensed code into proprietary products without any obligation to share their own code. For project maintainers who want maximum adoption and do not need to control how their code is used downstream, MIT is usually the default choice.
Apache License 2.0
The Apache License 2.0 is the second most popular permissive license and is used by major projects including Kubernetes, TensorFlow, and Apache HTTP Server. It is significantly longer and more detailed than MIT, but it grants the same basic freedoms: use, modify, distribute, and sublicense the code for any purpose.
What sets Apache 2.0 apart from MIT is its explicit patent grant. Section 3 of the Apache License states that every contributor automatically grants users a royalty-free, perpetual, worldwide patent license covering any patents that the contribution necessarily infringes. This means that if a company contributes code to an Apache-licensed project and that code implements something the company has patented, users of the project get an automatic license to those patents. The license also includes a patent retaliation clause: if you sue anyone over patent claims related to the software, your patent license under Apache 2.0 terminates.
This patent protection makes Apache 2.0 the preferred license for enterprise software and projects backed by large corporations. Google, Microsoft, and the Apache Software Foundation all use it extensively. For a deeper look at how Apache compares to other top licenses, see MIT vs GPL vs Apache vs BSD.
GNU General Public License (GPL) v2 and v3
The GPL is the most prominent copyleft license and the license that defined the free software movement. Linux, WordPress, MariaDB, GIMP, and thousands of other foundational projects use the GPL. It grants the same freedoms as permissive licenses but adds the requirement that any distributed derivative work must also be released under the GPL with full source code.
GPL v2, released in 1991, is the version used by the Linux kernel and many older projects. GPL v3, released in 2007, addressed several issues that arose in the years after v2 was written. GPL v3 adds protections against tivoization (using hardware restrictions to prevent users from running modified software on devices), clarifies compatibility with other licenses, and includes stronger patent protection similar to Apache 2.0's patent grant. Some projects, including the Linux kernel, have deliberately stayed on GPL v2 because Linus Torvalds disagreed with certain provisions of v3, particularly the anti-tivoization clauses.
The GPL's copyleft requirement is often misunderstood. It only triggers when you distribute the software. If you modify GPL code and use it purely internally within your organization, you have no obligation to release your modifications. The distribution trigger is what makes the Affero GPL (AGPL) different: AGPL considers providing access to software over a network as distribution, closing the loophole that lets companies modify GPL code, run it on their servers, and never share their changes because they technically never distribute the software.
BSD Licenses (2-Clause and 3-Clause)
The BSD licenses are among the oldest open source licenses, originating from the University of California, Berkeley's Software Distribution in the 1980s. The 2-Clause BSD License (also called the Simplified BSD License or FreeBSD License) is functionally very similar to the MIT License: it permits almost everything as long as you include the copyright notice and disclaimer. The 3-Clause BSD License adds one additional condition prohibiting the use of the project's name or contributors' names to endorse derived products without written permission.
FreeBSD, NetBSD, and OpenBSD all use BSD licenses, as do many academic and research software projects. In practice, the difference between MIT and 2-Clause BSD is negligible, and the choice between them often comes down to tradition or community convention.
Mozilla Public License 2.0
The Mozilla Public License (MPL) 2.0 occupies a middle ground between permissive and copyleft licenses. It applies copyleft at the individual file level: if you modify an MPL-licensed file, your modifications to that file must be released under the MPL. However, you can combine MPL-licensed files with proprietary code in the same project, and the proprietary files are not affected. Firefox, Thunderbird, and LibreOffice (in part) use the MPL.
This file-level copyleft makes the MPL practical for companies that want some copyleft protection for their code while still allowing integration with proprietary software. It is also explicitly compatible with the GPL, meaning MPL code can be incorporated into GPL projects without conflict.
GNU Lesser General Public License (LGPL)
The LGPL is a weak copyleft license designed primarily for software libraries. It allows proprietary software to link against LGPL-licensed libraries without triggering the copyleft requirement for the proprietary code. The key condition is that users must be able to replace the LGPL library with a modified version, which in practice means the proprietary software must use dynamic linking (shared libraries) rather than static linking.
The GNU C Library (glibc), GTK, and Qt (in its open source edition) use the LGPL. The license is a practical compromise for library developers who want their code to remain open source while still allowing broad adoption by proprietary software.
How License Choice Affects Your Project
The license you choose for a project is one of the most consequential decisions you will make, and it is very difficult to change later because every contributor would need to agree to relicense their contributions. Here is how different license choices affect real project outcomes.
Projects that want maximum adoption, especially among commercial users, tend to choose MIT or Apache 2.0. This is why most modern JavaScript frameworks, cloud-native tools, and developer utilities use permissive licenses. React (MIT), Vue.js (MIT), Angular (MIT), Kubernetes (Apache 2.0), and Docker (Apache 2.0) all prioritized broad adoption and chose accordingly.
Projects that prioritize software freedom and want to ensure their code can never be made proprietary choose the GPL. This is common in operating systems (Linux), content management systems (WordPress), databases (MariaDB), and desktop applications (GIMP, Blender). The trade-off is that some companies will avoid GPL-licensed dependencies entirely, but the projects that use GPL tend to have strong community-driven development models that do not depend on corporate adoption for sustainability.
Projects backed by companies that want to monetize through dual licensing often start with a strong copyleft license like AGPL. The company offers the AGPL version for free but sells a commercial license to companies that do not want to comply with the AGPL's requirements. MySQL (GPL with commercial licensing from Oracle), Qt (LGPL and commercial dual license), and several database companies use variations of this model. If you are curious about the business side, our article on whether you can sell open source software covers this in detail.
The choice also affects contribution dynamics. Projects under permissive licenses tend to receive more corporate contributions because companies know their contributions will not create legal complications. Projects under copyleft licenses often attract more individual and community contributions from developers who are philosophically aligned with the free software movement. If you need help deciding, our guide to choosing an open source license walks through the decision step by step.
Understanding License Compatibility
License compatibility determines whether code from two different open source projects can be combined into a single work. This is one of the most complex aspects of open source licensing because different licenses have different requirements that may conflict with each other. For a full deep dive, see our dedicated article on open source license compatibility.
Permissive licenses are generally compatible with everything. MIT-licensed code can be included in a GPL project, an Apache project, or a proprietary product. The permissive license's conditions (attribution and disclaimer) are satisfied by including them alongside whatever other license the combined work uses.
Copyleft licenses are more restrictive. GPL code can only be combined with code under GPL-compatible licenses. This means you cannot combine GPL code with code under a license that adds restrictions the GPL does not allow, such as a clause requiring advertising credits. The Free Software Foundation maintains a list of GPL-compatible and GPL-incompatible licenses on their website.
One notable compatibility issue involves Apache 2.0 and GPL v2. The Apache License 2.0 includes patent retaliation and indemnification clauses that the FSF considers to be additional restrictions not present in GPL v2, making the two licenses incompatible. However, Apache 2.0 is compatible with GPL v3 because v3 was specifically designed to accommodate Apache 2.0's patent provisions. This incompatibility has practical consequences: you cannot combine Apache 2.0 code with GPL v2-only code (like the Linux kernel), but you can combine it with GPL v3 code.
When building software that incorporates multiple open source dependencies, the combined license obligations of all dependencies determine what licenses are available for the combined work. Tools like FOSSA, Snyk, and the OSS Review Toolkit can scan dependency trees and flag compatibility issues automatically, and most large organizations use these tools as part of their development pipeline.
Common Misconceptions About Open Source Licensing
Several persistent myths about open source licensing lead developers and companies to make poor decisions. Clearing up these misconceptions is important for anyone working with open source code.
The first misconception is that code without a license is free to use. The opposite is true. Under copyright law, the creator of a work has exclusive rights over it by default. If you publish source code on GitHub without a license, nobody has legal permission to copy, modify, or distribute it. GitHub's terms of service grant users the right to view and fork repositories, but that does not extend to using the code in their own projects. Always include a license file if you want others to use your code.
The second misconception is that open source means no commercial use. Every OSI-approved open source license explicitly permits commercial use. The Open Source Definition requires it. What varies is the conditions attached to that commercial use, such as whether you must share your modifications or whether you receive a patent grant.
The third misconception is that using a GPL library forces you to GPL your entire codebase. The reality is more nuanced. The GPL's copyleft requirement applies when you distribute software, and what counts as a derivative work depends on how you integrate the GPL code. Using a GPL library as a standalone process that your software communicates with via a well-defined interface (like a command-line tool or a network API) is generally not considered creating a derivative work. However, linking directly against a GPL library typically is. These distinctions matter enormously in practice, and when they are ambiguous, legal counsel should be involved.
The fourth misconception is that you can relicense open source code however you want. You can only relicense code that you have full copyright ownership of. If your project has accepted contributions from other developers, each contributor retains copyright over their contributions (unless they signed a CLA transferring copyright). Relicensing requires the agreement of every contributor, which becomes impractical for large projects with hundreds of contributors. This is why some projects require CLAs from the start.
The fifth misconception is that source-available and open source are the same thing. Licenses like the Business Source License (BSL), the Elastic License, and the Server Side Public License (SSPL) make source code visible and allow some uses but include restrictions that disqualify them from being OSI-approved open source licenses. These licenses typically restrict commercial use, competitive use, or use as a managed service. They serve legitimate business purposes, but calling them open source is inaccurate and has been a source of significant controversy in the developer community. Our guide to open source licenses to avoid covers several problematic or confusing licenses in more detail.