MIT vs GPL vs Apache vs BSD

Overview of Each License

Before comparing the four licenses against each other, it helps to understand what each one is and where it comes from.

The MIT License was created at the Massachusetts Institute of Technology and is the most popular open source license worldwide. It is approximately 170 words long, fits on a single page, and imposes only two requirements: include the copyright notice in copies, and accept that the software comes without warranty. Everything else is permitted. React, Node.js, jQuery, Rails, Vue.js, and .NET all use the MIT License.

The GNU General Public License (GPL) was created by Richard Stallman and the Free Software Foundation. GPL v2 was released in 1991, and GPL v3 in 2007. The GPL grants the same freedoms as permissive licenses but adds the copyleft requirement: if you distribute software that includes GPL code, you must release the source code of the entire combined work under the GPL. Linux, WordPress, MariaDB, GIMP, and Blender all use the GPL.

The Apache License 2.0 was created by the Apache Software Foundation. It is a permissive license like MIT but is much more detailed (roughly 4,500 words) and includes an explicit patent grant and patent retaliation clause. Kubernetes, TensorFlow, Apache HTTP Server, Hadoop, and Android (in part) use Apache 2.0.

The BSD licenses originated at the University of California, Berkeley in the 1980s. The 2-Clause BSD is nearly identical to MIT in effect. The 3-Clause BSD adds a non-endorsement clause preventing the use of the project's name or contributors' names to promote derivative products. FreeBSD, NetBSD, OpenBSD, and many academic projects use BSD licenses.

Permissions Compared

All four licenses allow commercial use, modification, distribution, and private use. There is no restriction on what you can build with code under any of these licenses. The difference is entirely in the conditions attached to these permissions, not the permissions themselves.

With MIT and BSD, you can take the source code, modify it, incorporate it into a proprietary product, and sell that product. You can even sublicense the code under different terms. The only thing you must do is include the original copyright notice and license text.

With Apache 2.0, you have the same permissions as MIT and BSD, plus the additional benefit of an explicit patent grant. Every contributor to an Apache-licensed project automatically grants users a license to any of the contributor's patents that the contributed code necessarily infringes. This means you can use Apache-licensed code without worrying about patent claims from the contributors.

With GPL, you have the same permissions to use, study, and modify the code, but distribution is where the conditions diverge sharply. If you distribute a program that includes GPL code, the entire program must be released under the GPL with full source code. You cannot incorporate GPL code into a proprietary product and distribute it without making the whole product open source. This is the core trade-off: GPL gives you every freedom except the freedom to make derivatives proprietary.

Obligations and Conditions

This is where the four licenses differ most, and understanding these differences is critical for making the right choice.

Attribution

All four licenses require attribution. You must include the original copyright notice and a copy of the license text when you redistribute the code. MIT and BSD 2-Clause have essentially no other requirements. BSD 3-Clause adds that you cannot use the project's name for endorsement without permission. Apache 2.0 requires attribution plus a NOTICE file if one exists, and you must mark any files you have modified. GPL requires attribution plus full source code availability.

Source Code Disclosure

This is the biggest differentiator. MIT, BSD, and Apache 2.0 do not require you to disclose your own source code under any circumstances. You can build a closed-source commercial product on top of MIT-licensed code and never share a line of your own code. GPL requires the opposite: if you distribute software that incorporates GPL code, you must provide the complete source code of the combined work to anyone who receives the binary.

Patent Protection

Apache 2.0 provides the strongest explicit patent protection of the four. Its Section 3 grants users a perpetual, worldwide, royalty-free patent license from every contributor. Its Section 3 also includes a patent retaliation clause: if you initiate patent litigation against anyone over the software, your patent license under Apache 2.0 terminates immediately.

GPL v3 includes similar patent protection. Section 11 requires that each contributor grants a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims. GPL v2 does not include an explicit patent grant, though some legal scholars argue it contains an implicit one through its grant of rights to "use" the software.

MIT and BSD do not mention patents at all. Users rely on an implied patent license theory, which has not been extensively tested in court. For most small to medium-sized projects, this is not a practical concern. For enterprise software where contributors may hold relevant patents, the explicit grants in Apache 2.0 and GPL v3 provide significantly stronger protection.

Copyleft (Share-Alike)

MIT, BSD, and Apache 2.0 have no copyleft requirement. You can create derivative works and license them however you want, including under a proprietary license.

GPL's copyleft is its defining feature. Any derivative work based on GPL code must also be distributed under the GPL. This requirement applies when you distribute the software (including over a network for AGPL). Internal use within an organization without distribution does not trigger copyleft obligations.

Compatibility Between These Licenses

Compatibility determines whether code from projects under different licenses can be combined in a single work. This matters whenever you pull in dependencies from multiple open source projects.

MIT and BSD code can be combined with anything: other permissive licenses, GPL, LGPL, Apache, or proprietary code. Since these licenses only require attribution, their conditions are compatible with any other license's conditions.

Apache 2.0 is compatible with GPL v3 but not with GPL v2. This is one of the most important compatibility facts in open source licensing. The Apache License's patent retaliation clause and indemnification provisions constitute additional restrictions that GPL v2's terms do not permit. GPL v3 was specifically designed to accommodate Apache 2.0's provisions, so the two work together. If your project uses GPL v2-only code (like the Linux kernel), you cannot incorporate Apache 2.0 dependencies.

GPL code can only be combined with code under GPL-compatible licenses. Since MIT and BSD are compatible, and Apache 2.0 is compatible with GPL v3, this is usually not a problem in practice unless you are working with GPL v2-only projects.

When to Use Each License

Choose MIT When

You want the simplest possible license that maximizes adoption. MIT is the default choice for JavaScript libraries, developer tools, small utilities, and any project where you want people to use your code without thinking about legal obligations. If your primary goal is widespread use and you do not care whether someone turns your code into a proprietary product, MIT is the right choice.

Choose Apache 2.0 When

You want a permissive license with patent protection. Apache 2.0 is the better choice for enterprise software, projects backed by companies that hold patents, or any project where contributors might have patent portfolios. It is also the standard license for Apache Software Foundation projects, Cloud Native Computing Foundation projects, and many Google-sponsored open source efforts.

Choose GPL When

You want to ensure that your code and all derivative works remain open source forever. GPL is the right choice when you believe that anyone who benefits from the community's work should contribute back to the community. It is also the right choice for dual-licensing business models, where you offer the GPL version for free and sell a commercial license to companies that want to use the code without open-sourcing their own products.

Choose BSD When

You want a permissive license and have a preference for the BSD tradition, or you want the non-endorsement clause that 3-Clause BSD provides. In practice, BSD and MIT are interchangeable for most purposes, and the choice between them is usually a matter of convention within a particular community. Operating system projects (FreeBSD, OpenBSD, NetBSD) tend to prefer BSD. Most other projects default to MIT.