Open Source License Comparison Chart

Quick Comparison Table

The table below summarizes the key attributes of the most popular open source licenses. Each row covers a major license, and the columns indicate whether specific rights are granted, whether conditions must be met, and what limitations apply.

Permissions in Detail

All ten licenses in this chart allow commercial use, modification, and distribution. The differences lie in the conditions each license attaches to these permissions. Understanding what you must do (not just what you can do) is where the real decision-making happens.

Attribution requirements are the most common condition. Every license in this chart except the Unlicense requires you to include the original copyright notice and license text when you redistribute the code. For permissive licenses like MIT and BSD, this is essentially the only obligation. You include the notice in your project's documentation or license file, and you are done. For copyleft licenses, attribution is the starting point, not the finish line.

Source code disclosure is the condition that separates permissive and copyleft licenses. The GPL family (GPL v2, GPL v3, AGPL v3, and LGPL v3) requires that when you distribute software built on their code, you must also make the complete corresponding source code available under the same license. For strong copyleft licenses like GPL v3, this applies to the entire program. For weak copyleft like LGPL v3, it applies only to the library itself. The MPL 2.0 takes the narrowest approach, requiring source disclosure only for the specific files that were originally licensed under the MPL.

Patent grants are included in Apache 2.0, GPL v3, LGPL v3, MPL 2.0, and AGPL v3. These grants protect users from patent infringement claims by contributors. The MIT and BSD licenses do not include an explicit patent grant, which means users technically rely on an implied license theory for patent protection. In practice, patent claims against MIT or BSD-licensed projects are extremely rare, but for enterprise software where patent risk is a real concern, the explicit grant in Apache 2.0 or GPL v3 provides stronger legal footing.

Conditions and Obligations

This section breaks down what each license requires you to do when you use, modify, or distribute the licensed code.

MIT License Obligations

Include the copyright notice and permission notice in all copies or substantial portions of the software. That is the entire list. The MIT License is roughly 170 words long and its obligations can be summarized in one sentence.

Apache 2.0 Obligations

Include the copyright notice, a copy of the license, and the NOTICE file (if one exists) in redistributions. If you modify the code, you must state that you changed the files. The patent grant is automatic: every contributor grants patent rights to users. If you file a patent lawsuit against someone over the software, your patent license terminates. Apache 2.0 is about 4,500 words long and is the most detailed of the permissive licenses.

GPL v3 Obligations

If you distribute software that includes GPL v3 code (whether modified or unmodified), you must make the complete source code of the entire combined work available under the GPL v3. You must include the full license text. You cannot impose additional restrictions beyond what the GPL allows. You must preserve all copyright, patent, trademark, and attribution notices. If the software interacts with users remotely, you do not have to provide source (that is what the AGPL adds). Internal use without distribution triggers no obligations at all.

LGPL v3 Obligations

If you use an LGPL library in your application, you must make the library's source code available but your own application code can remain proprietary. The catch is that users must be able to replace the LGPL library with a modified version, which generally means you must use dynamic linking. If you statically link an LGPL library into a proprietary binary, you need to provide object files or source that allow relinking with a modified version of the library.

MPL 2.0 Obligations

If you modify files that are under the MPL, the modified files must remain under the MPL and their source must be made available. New files you add to the project can be under any license you choose, including a proprietary one. This file-level copyleft is significantly less restrictive than GPL's project-level copyleft and makes the MPL popular for projects that want a middle ground.

BSD Obligations

The 2-Clause BSD requires attribution (copyright notice and disclaimer in redistributions). The 3-Clause BSD adds that you cannot use the project's name or contributors' names to endorse or promote derived products without written permission. The original 4-Clause BSD had an advertising clause requiring all advertising materials to credit the university, but this clause was removed in 1999 and the 4-Clause version is now considered obsolete.

Limitations and Disclaimers

Every open source license includes limitations on liability and warranty disclaimers. The software is provided "as is" with no warranty of any kind, and the authors cannot be held liable for damages arising from its use. This is universal across all licenses in this chart, from the Unlicense to the GPL v3. These provisions protect open source maintainers, most of whom are volunteers, from legal liability for bugs, security vulnerabilities, or data loss caused by their software.

Some licenses include a trademark limitation. The Apache License 2.0 explicitly states that the license does not grant permission to use the licensor's trade names, trademarks, or service marks. The 3-Clause BSD has a similar non-endorsement clause. MIT and GPL do not address trademarks directly, so trademark rights fall back to standard trademark law, which generally prohibits use of another party's trademarks in ways that imply endorsement or affiliation.

License Compatibility at a Glance

Compatibility determines whether code under two different licenses can be combined. Here is a simplified view of which licenses work together.

Permissive licenses (MIT, BSD, Apache 2.0) are compatible with almost everything. Code under these licenses can be absorbed into projects under any other license, including copyleft and proprietary. The only notable exception is that Apache 2.0 is incompatible with GPL v2 due to additional restrictions in Apache 2.0 that GPL v2 does not allow. Apache 2.0 is compatible with GPL v3, which was specifically designed to resolve this conflict.

Copyleft licenses are compatible with themselves and with permissive licenses, but not with each other unless explicitly stated. GPL v3 code and AGPL v3 code can be combined because the AGPL includes a provision for this. MPL 2.0 code can be combined with GPL code because the MPL includes a secondary license provision allowing conversion to GPL-compatible terms. For a deeper analysis, see our full guide to open source license compatibility.

Which License Is Used Most?

Based on analysis of public repositories across GitHub, GitLab, and package registries, the MIT License is the most widely used open source license, appearing in roughly 40 to 45 percent of licensed repositories. Apache 2.0 comes second at around 15 to 20 percent, followed by GPL v3 at roughly 8 to 10 percent. GPL v2, BSD, and ISC each account for smaller shares, with the remaining licenses collectively covering less than 10 percent of the total.

The trend over the past decade has been a steady shift toward permissive licenses. In 2012, GPL licenses collectively accounted for about 60 percent of licensed open source projects. By 2025, permissive licenses represented more than 70 percent. This shift reflects the growing influence of corporate open source, where companies prefer to release and consume code under licenses that do not restrict commercial use. The growth of cloud computing has also played a role, since traditional copyleft triggers based on distribution do not apply to software run as a service (a gap the AGPL was designed to close).