Choosing the right open source license is one of the most consequential decisions a software project can make. The license determines how others can use, modify, and distribute your code, and it shapes the community and commercial ecosystem that grows around your project. Despite their importance, open source licenses remain widely misunderstood, even among experienced developers.
This guide breaks down the four most influential open source license families: MIT, Apache 2.0, GPL, and AGPL. By understanding the philosophy, legal mechanics, and practical implications of each, you can make an informed decision for your next project.
Understanding License Categories
Open source licenses generally fall into two broad categories: permissive and copyleft. Permissive licenses like MIT and Apache 2.0 impose minimal restrictions on how the software can be used, modified, and redistributed. Copyleft licenses like GPL and AGPL require that derivative works also be released under the same or a compatible license.
This distinction matters enormously in practice. A permissive license allows a company to take your code, modify it, and ship it as part of a proprietary product without releasing their changes. A copyleft license prevents this by requiring that modifications remain open source.
The MIT License
The MIT License is the most popular open source license in the world, used by projects like React, Node.js, Ruby on Rails, and jQuery. Its popularity stems from its simplicity: the entire license fits in a single short paragraph.
What MIT Permits
- Commercial use without restriction
- Modification of the source code
- Distribution of original or modified versions
- Private use in proprietary software
- Sublicensing under different terms
What MIT Requires
The only requirement is that the original copyright notice and license text must be included in all copies or substantial portions of the software. There is no requirement to share source code for derivative works.
Limitations
MIT provides no patent protection. If someone holds a patent that covers the software, they could theoretically allow you to use the code under MIT while still suing you for patent infringement. The license also provides no warranty and limits liability.
The Apache 2.0 License
The Apache License 2.0 is the second most popular permissive license, used by projects like Kubernetes, Android, TensorFlow, and Apache HTTP Server. It is more detailed than MIT and addresses some of MIT's gaps.
Key Differences from MIT
- Explicit patent grant: Contributors automatically grant users a royalty-free patent license covering their contributions. This is the single most important advantage over MIT.
- Patent retaliation clause: If you sue the project for patent infringement, your patent license is automatically terminated.
- Contribution clarity: The license defines what constitutes a "contribution," reducing legal ambiguity.
- NOTICE file requirement: If the project includes a NOTICE file, it must be preserved in redistributions.
When to Choose Apache 2.0 Over MIT
Apache 2.0 is generally the better choice for projects where patent concerns are relevant, particularly in enterprise software, machine learning frameworks, and infrastructure tools. The patent grant provides meaningful protection that MIT lacks. Google, Microsoft, and the Apache Software Foundation all favor Apache 2.0 for their open source projects.
The GNU General Public License (GPL)
The GPL is the most well-known copyleft license, created by Richard Stallman and the Free Software Foundation. It exists in three major versions: GPLv2 (1991), GPLv3 (2007), and the Lesser GPL (LGPL). Notable GPL projects include Linux (GPLv2), WordPress (GPLv2+), and GIMP (GPLv3).
The Copyleft Mechanism
The GPL's central requirement is that any software that incorporates GPL-licensed code must itself be released under the GPL when distributed. This is sometimes called the "viral" nature of the GPL, though the free software community prefers the term "copyleft."
Key GPL Requirements
- Source code availability: When you distribute GPL software (in binary or source form), you must make the complete corresponding source code available.
- Same license: Derivative works must be licensed under the GPL.
- No additional restrictions: You cannot impose restrictions beyond those in the GPL itself (e.g., you cannot add a non-commercial clause).
- Freedom to modify: Users must be free to modify the software for their own use.
The Distribution Trigger
A critical nuance: the GPL's copyleft obligations are triggered by distribution. If you modify GPL software but only use it internally within your organization, you are not required to release your modifications. This is sometimes called the "SaaS loophole" because companies can modify GPL software and offer it as a web service without distributing the modified source.
The GNU Affero General Public License (AGPL)
The AGPL was created specifically to close the SaaS loophole in the GPL. It adds a single additional requirement: if you run a modified version of AGPL software on a server and let users interact with it over a network, you must make the source code of your modified version available to those users.
AGPL in Practice
The AGPL is used by projects like MongoDB (before its switch to SSPL), Grafana, Nextcloud, and Mastodon. It is particularly popular among companies using the "open core" business model, where the core product is AGPL but commercial add-ons or hosted services are proprietary.
Corporate Attitudes Toward AGPL
Many large companies have policies restricting or prohibiting the use of AGPL software. Google, for example, bans AGPL code from its internal codebase. This corporate caution makes AGPL an effective tool for open source companies that want to encourage commercial licensing: organizations that do not want to comply with AGPL terms can purchase a commercial license instead.
License Compatibility
Not all open source licenses are compatible with each other. You cannot combine MIT-licensed code with GPL-licensed code and release the result under MIT, because the GPL requires the combined work to be GPL-licensed. However, you can combine MIT and GPL code and release the result under GPL, because MIT's terms are a subset of GPL's.
Common Compatibility Rules
- MIT is compatible with everything because it imposes almost no restrictions.
- Apache 2.0 is compatible with GPLv3 but not with GPLv2, due to the patent clause.
- GPLv2 and GPLv3 are not compatible with each other unless the project specifies "GPLv2 or later."
- AGPL is compatible with GPLv3 in one direction: you can combine AGPL and GPLv3 code, but the result must be AGPL.
Choosing the Right License
The best license depends on your goals. If you want maximum adoption and do not care about preventing proprietary use, choose MIT or Apache 2.0. If patent protection matters, lean toward Apache 2.0. If you want to ensure that improvements to your software remain open source, choose GPL. If your software is primarily used as a network service, choose AGPL.
Decision Framework
- Building a library or utility? MIT or Apache 2.0 maximizes adoption.
- Building an application or platform? GPL or AGPL ensures modifications stay open.
- Building a commercial open source product? AGPL + commercial license (dual licensing) is the most common approach.
- Working in a patent-heavy industry? Apache 2.0 provides the best protection.
Whatever you choose, choosing explicitly is what matters most. Projects without a license are not open source by default. Under copyright law, the absence of a license means all rights are reserved, and no one has permission to use, modify, or distribute the code.
