What Are the Different Types of Open Source Licenses?

The Five License Categories

While over 100 individual open source licenses exist, nearly all of them fit into one of five categories based on the conditions they impose on users. Understanding these categories is more useful than memorizing individual licenses because once you know which category a license belongs to, you already know its most important characteristics.

Type 1: Permissive Licenses

Permissive licenses grant broad rights with minimal obligations. You can use, modify, and redistribute the code for any purpose, including incorporating it into proprietary software, as long as you meet a few simple conditions. These conditions typically include preserving the copyright notice, including the license text when redistributing, and accepting that the software comes with no warranty.

Permissive licenses are the most popular category, representing more than 70 percent of all licensed open source projects. They are the default choice for JavaScript libraries, developer tools, cloud-native infrastructure, and any project that prioritizes adoption over controlling downstream use.

Key permissive licenses:

The MIT License is the single most popular open source license. It is about 170 words long and requires only attribution and a warranty disclaimer. React, Node.js, Vue.js, jQuery, Rails, and thousands of other major projects use MIT.

The Apache License 2.0 is the second most popular permissive license. It provides the same freedoms as MIT but adds an explicit patent grant (contributors automatically license their relevant patents to users) and a patent retaliation clause (your patent license terminates if you sue over the software). Kubernetes, TensorFlow, and Hadoop use Apache 2.0.

The BSD licenses (2-Clause and 3-Clause) are functionally similar to MIT. The 3-Clause version adds a non-endorsement clause. FreeBSD and OpenBSD use BSD licenses.

The ISC License is a simplified version of the 2-Clause BSD, functionally equivalent to MIT. OpenBSD prefers ISC for new code, and npm uses ISC as its default license.

Type 2: Strong Copyleft Licenses

Strong copyleft licenses grant the same freedoms as permissive licenses but add the requirement that any work that incorporates the licensed code must itself be distributed under the same license with source code available. This is the "share-alike" or "reciprocal" condition, and it is the defining feature of copyleft.

Strong copyleft means that the copyleft requirement extends to the entire program, not just the modified files. If you link your proprietary code against a GPL library, the GPL considers the entire combined work to be a derivative work that must be GPL-licensed. This broad scope is what makes strong copyleft licenses controversial in commercial contexts.

Key strong copyleft licenses:

The GNU General Public License v2 (GPL v2) is the classic copyleft license, released in 1991. Linux, WordPress, and Git use GPL v2. Many GPL v2 projects include the "or any later version" clause, which allows the code to be used under GPL v3 terms as well.

The GNU General Public License v3 (GPL v3) was released in 2007 and addressed several issues in GPL v2, including anti-tivoization protections (preventing hardware restrictions on modified software), an explicit patent grant, and improved compatibility with Apache 2.0. MariaDB, GCC, and Bash use GPL v3.

The GNU Affero General Public License v3 (AGPL v3) is GPL v3 with one addition: providing access to the software over a network counts as distribution, triggering the copyleft requirement. This closes the so-called SaaS loophole that allows companies to modify GPL software, run it on their servers, and never share their changes because they never technically distribute binaries. Grafana, Nextcloud, and MongoDB (before it switched to SSPL) used the AGPL.

Type 3: Weak Copyleft Licenses

Weak copyleft licenses apply the share-alike requirement to a narrower scope than strong copyleft. Instead of requiring the entire combined work to be open source, they limit copyleft to the licensed component itself, allowing proprietary code to coexist alongside the open source component under certain conditions.

Key weak copyleft licenses:

The GNU Lesser General Public License (LGPL v2.1 and v3) was designed for software libraries. Proprietary software can link against an LGPL library without triggering copyleft for the proprietary code, as long as users can replace the library with a modified version. In practice, this means using dynamic linking (shared libraries) rather than static linking. Modifications to the LGPL library itself must remain open source. The GNU C Library (glibc), GTK, and Qt (open source edition) use the LGPL.

The Mozilla Public License 2.0 (MPL 2.0) applies copyleft at the file level. If you modify a file that is under the MPL, your modified version of that file must remain under the MPL with source available. However, new files you add to the same project can use any license, including a proprietary one. This makes the MPL the narrowest copyleft license in common use. Firefox, Thunderbird, and LibreOffice (in part) use the MPL.

The Eclipse Public License 2.0 (EPL 2.0) is similar to the MPL in scope. It applies copyleft to the module level and allows proprietary modules to coexist with EPL modules in the same application. The Eclipse IDE and many Java ecosystem projects use the EPL.

Type 4: Public Domain and Public Domain-Like Licenses

Public domain dedications waive all copyright and related rights, placing the code as close to "no restrictions whatsoever" as legally possible. They go further than permissive licenses by removing even the attribution requirement.

True public domain dedication is complicated by the fact that not all legal jurisdictions recognize the concept of voluntarily placing work in the public domain. Some countries' copyright laws do not allow authors to waive their moral rights, and the legal status of a public domain dedication may be uncertain in those jurisdictions.

Key public domain and public domain-like licenses:

The Unlicense attempts to place software in the public domain and includes a fallback permissive license for jurisdictions where public domain dedication is not recognized. It explicitly waives all copyright and related rights and does not require attribution, warranty disclaimers, or any other conditions. SQLite (which uses its own public domain dedication) is the most prominent project to waive all rights, though it does not use the Unlicense specifically.

Creative Commons Zero (CC0) is another public domain dedication tool, created by Creative Commons. CC0 is more legally robust than the Unlicense because it was drafted with international copyright law in mind and includes explicit waivers of moral rights where applicable. CC0 is commonly used for data sets, documentation, and creative assets. Some developers use it for code, though Creative Commons recommends using a proper software license instead.

The MIT-0 (MIT No Attribution) license is the MIT License with the attribution requirement removed. Unlike the Unlicense and CC0, MIT-0 is structured as a traditional license grant rather than a rights waiver, which may provide stronger legal footing in some jurisdictions. AWS developed MIT-0 for its code samples and examples.

Type 5: Source-Available Licenses (Not Open Source)

Source-available licenses make source code visible and allow some uses, but they include restrictions that disqualify them from being open source under the OSI definition. These licenses are important to understand because they are frequently confused with open source, and using source-available software without understanding the restrictions can create serious legal problems.

Key source-available licenses:

The Server Side Public License (SSPL) requires that anyone offering the software as a service must open-source the entire service infrastructure. This goes far beyond any OSI-approved license. MongoDB uses the SSPL.

The Business Source License (BSL) restricts production or commercial use for a set period (usually three to four years), after which the code converts to a genuine open source license. HashiCorp (Terraform, Vault), Sentry, and CockroachDB use the BSL.

The Elastic License 2.0 (ELv2) prohibits offering the software as a managed service and prohibits circumventing access controls. Elastic uses ELv2 for parts of the Elastic Stack.

The Functional Source License (FSL) is a newer source-available license that restricts competitive use for two years, then converts to Apache 2.0 or MIT. It was designed to be simpler and more predictable than the BSL.

None of these licenses are OSI-approved open source. They serve legitimate business purposes, but they should not be called open source, and code under these licenses cannot be freely combined with code under genuine open source licenses. For more detail on why these licenses cause problems, see our guide to open source licenses to avoid.