Top Open Source Licenses Explained

An open source license is a binding legal contract between author and user that declares the certain conditions in which a piece of software can be used, which is especially relevant in commercial applications. This license is what turns software components into open source components, allowing developers to use that software so long as they keep the specific terms and conditions laid out in the license.

There are a lot of open source licenses, over 200 in fact. Luckily, nearly all available open source software falls under just a handful of licenses. Here’s a quick and dirty breakdown of each license to help you make broad decisions for your code. Be sure to follow the links in each section for more in-depth analysis of each license.

Types of software license: copyleft and permissive

Let’s first take a look at the general landscape of open source licenses. There are two main categories of licenses: copyleft and permissive. This division is based on the requirements and restrictions the license places on users.

When an author releases a program under a copyleft license, they make a claim on the copyright of the work and issue a statement that other people have the right to use, modify, and share the work as long as the reciprocity of the obligation is maintained. In short, if they are using a component with this kind of open source license, then they too must make their code open for use by others as well. Whether this applies to all of their code or just the modifications they’ve made to the licensed code depends on the license. A permissive open source license is a non-copyleft open source license that guarantees the freedom to use, modify, and redistribute, while also permitting proprietary derivative works. Permissive licenses place minimal restrictions on how others can use open source components. This type of license allows varying degrees of freedom to use, modify, and redistribute open source code, permitting its use in proprietary derivative works, and requiring nearly nothing in return with regard to obligations moving forward.

Top open source licenses explained

There are no good or bad licenses, and no one license is better than another. Anyone can create an open-source license that suits them, which is the reason that there are so many out there. This can make choosing an open source license a complicated business. To help narrow down the decision and make sense of it all, the Open Source Initiative (OSI) put together a list of approved licenses, consisting of a little over 80 open source licenses that are most commonly used.

GNU General Public License (GPL)

The most ubiquitous copyleft license and one that does sometimes strike fear into the hearts of legal teams, the GPL is a specific implementation of the “copyleft” concept created by Richard Stallman in order to prevent GNU software from becoming proprietary.

Because the GPL is a strong copyleft license, any software that is written based on any GPL component must be itself released as open source under the same license or a later version. Projects that use these components, no matter the percentage of total code, are legally required to release the complete source code plus all of the rights to modify and distribute that code. This includes other components your project might use, such as linked libraries, which means you cannot usually mix GPL’ed code with other copyleft licensed code.

The trigger for this reciprocity obligation is distribution. If you use or modify GPL’ed code but do not distribute it to the public, there is no legal requirement to make that source code available to the public. This creates something of a loophole when using GPL’ed code to create Software as a Service (SaaS) applications that are never actually distributed to the user. In all versions of the GPL up to v3.0, allowing users to interact with your software over a network is not considered distribution, though SaaS providers should still be cautious about using GPL’ed components. The Affero GNU General Public License (AGPL) closes that loophole and explicitly considers users interacting with software over a network to be distribution.

More permissive versions of the GPL exist, including the Lesser GNU Public License (LGPL) and the GPL with an added classpath exception clause. Implemented properly, you can use unmodified versions of software (usually libraries) falling under these weak copyleft licenses without an obligation to release the rest of your code under a GPL.

The Apache License

The Apache 2.0 License is a popular and widely deployed open source software license released by the Apache Software Foundation (ASF).

One of the most permissive open source software licenses, the Apache license allows you to release your modified version of an Apache-licensed product under any license you may choose. You are permitted to freely use, modify, distribute, and sell software under an Apache License whether your use case is personal, internal, or commercial.

Unlike other permissive licenses that are applicable only to copyrights and not patents, the Apache License explicitly grants rights to users that can be applied to both copyrights and patents. The rights given are perpetual, worldwide, and irrevocable, but also non-exclusive, meaning you can use the licensed work and so can anyone else.

To redistribute software with any Apache licensed components, you must include a copy of the license, provide a clear Apache License attribution, and add modification notices to any files you modify.

You can choose to release the modified or derived products under different licenses, but the unmodified parts of the software must retain the Apache License. Another rule is that you cannot name your modified version in any way that suggests that the final product is either endorsed or created by the ASF.

Lastly, if you want to add a copyright statement about all of the modifications you’ve done to any Apache-licensed software, you are free to do so. The Apache License doesn’t require you to release modified code under the same license so you can choose to add specific license terms and conditions that govern how others use, reproduce, or distribute your modified code.

Microsoft Public Licenses (Ms-PL)

The Microsoft Public License is a free and open source software license released by Microsoft for its own open source projects.

The Ms-PL is a short, concise, and straightforwardly written license that allows you to freely reproduce and distribute original or derivative works of any software that it governs. In doing so, however, you may not use any contributors’ names, logos, or trademarks. The Ms-PL also protects software authors by explicitly offering no express warranties or guarantees, meaning authors are not liable if their code doesn’t work well in some cases.

When distributing software under the Ms-PL, modified or unmodified, in whole or in part, you are not obligated to distribute the source code. You are, however, required to retain all copyright, patent, trademark, and attribution notices that were originally present. If you do choose to distribute any portion of the software, modified or unmodified, in its source code form, you must do so only under the Ms-PL by including a complete copy of the license in the distribution. If you instead choose to release the code in a compiled or object code form, you may release it under any compatible license.

 Berkeley Software Distribution (BSD)

BSD Licenses are a family of permissive licenses. A BSD License allows you to freely modify and distribute your software’s code in the source or binary format so long as you retain a copy of the copyright notice, list of conditions, and the disclaimer.

The original 4-clause BSD License contains an advertising clause requiring certain acknowledgement of previous authors in any advertising for software that makes use of BSD licensed code. The most commonly used BSD license, the 3-clause Modified BSD License, removes the advertising clause and the 2-clause FreeBSD License removes both the advertising and non-endorsement clauses.

Common Development and Distribution License (CDDL)

The CDDL is an open source license published by Sun Microsystems (now Oracle) to replace the Sun Public License (SPL) and is considered to be SPL version 2. It is inspired by the Mozilla Public License (MPL). The CDDL is often considered a cleaned-up version of the MPL and was made to facilitate reusability.

You are free to reproduce and distribute any original or derivative works of any software licensed under the CDDL but you must not remove or make any changes to any copyright, patent, or trademark notices present in the software. You must also retain any notices of licensing or any descriptive text that gives attribution to any contributor or the initial author.

When you distribute your software in any form other than source code, you are required to make the source code of any file containing CDDL’ed code, whether modified or in its original form, available under the CDDL and to include a copy of the license in the distribution. The executable form and any project files not containing CDDL’ed code may be released under the CDDL or any compatible licenses.

Additionally, for each modification that you make you must identify yourself as a modifier by including a notice in your modified files.

The CDDL is considered a weak copyleft license as its use does not grant downstream users of the program the same rights you received by requiring your entire code become open source, like with strong copyleft licenses such as the GPL. Only files including CDDL’ed code or modifications to CDDL’ed code are under any copyleft obligations. Other files and the executable of the whole program can be under any license that is compatible with the CDDL.

Eclipse Public License (EPL)

The Eclipse license is a weak copyleft license. If you modify code under the EPL and distribute the source code as part of your program, you’re required to license the modified code under the EPL. If you distribute such a program in its object code form, you’re required to state that the EPL’ed source code is available to the recipient upon request and to share the method for making that request.

The Eclipse Foundation makes it clear that “merely interfacing or interoperating” with an Eclipse plugin does not make your code a derivative work of the plugin. As with all weak copyleft licenses, if you wish to use a different license for the rest of your code, keeping the EPL’ed code in a separate file is the best practice, if not a requirement. The EPL version 1.0 is less clear about this but version 2.0 is explicitly a per-file copyleft license.

The EPL protects the author from possible lawsuits or damages caused if a company used their component in a commercial product. Any warranties made by a commercial contributor to EPL’ed code is theirs alone and not that of previous contributors. Like many other open source licenses, the EPL also includes an explicit patent grant.

 MIT License

The MIT License is one of the most permissive and popular licenses out there. There are actually two variants of the same license that are frequently called “The MIT License”:  the Expat License and the X11 License. Being the shorter and first variation, as well as the one the Software Package Data Exchange (SPDX) identifies as “MIT”, we will refer to the Expat License as the MIT License.

The MIT License includes language expressing that the software is presented as-is and without warranty. As a permissive license, there is no requirement that modifications to MIT Licensed code be also released under the MIT License making it a great choice for proprietary and commercial uses. The license’s only requirement of a user is that the license be included in “all copies or substantial portions of the Software”. At less than 200 words, that’s just a few lines of comments in the code. There’s a reason the MIT License accounts for nearly a third of all uses of open source licenses.

Know your open source licenses, or explain it to the judge

Nearly all software developers rely heavily on open source components, so it’s crucial to understand the basics of open source licensing, and the main differences between the popular open source licenses out there. This is why open source license management tools are a critical element for safeguarding your code, software, and applications, as well as reducing financial and legal risk for your organization. They reinforce the integrity of the components and dependencies you use, and ensure that your use of these components will neither compromise your organization nor the product that you create.

Additional guides on open source topics

Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of open source:

Open source licenses

Authored by Mend

Dual Licensing for Open Source Components: Yeah or Meh?

Top 9 GPL With The Classpath Exception Questions Answered

The SaaS Loophole in GPL Open Source Licenses

Open Source Licenses Trends and Predictions

Open source audit

Authored by Mend

• When’s The Right Time For An Open Source Audit?
• Tips And Tools For Open Source Compliance
• Manage Open Source Appsec Risk

Dependency management

Authored by Mend

• Maven Update Dependencies Automatically
• Dependency Management: Protecting Your Code
• What Is Patch Management & How To Get It Right

Apache Kafka

Authored by Instaclustr

• Apache Kafka on AWS: Features, pricing, tutorial and best practices
• Apache Kafka: Architecture, deployment and ecosystem [2025 guide]
• Apache Kafka tutorial: Get started with Kafka in 5 simple steps