When software is released, it usually comes with a license that restricts the way it can be used.
This post enumerates the main software licenses that are common in the software industry, with a strong focus on free and open-source (FOSS) licenses.
The licenses are displayed on the post in descending permissiveness or ascending restrictiveness order.
Definition of Free and Open-Source Software (FOSS) Licenses
In the world of software, we can distinguished between open-source and closed-source software.
Open-source software is the one whose source code is accessible, modifiable and distributable by anyone, including users and third-party developers.
Close-source software is the one that is distributed only as compiled binaries, and users do not have access to the source code.
Though most current software is closed-source and it seems as the default option, historically the first software to appear was open-source and in the 1970s most of the software was distributed in this way.
Open-source licenses would be a very open term that encompass any software license that protect the developers’ rights over an open-source software. As there is no common agreement of what “open-source” means, it is difficult to provide a more accurate definition.
Open-source Licenses
The Open Software Initiative (OSI) is a non-profit organization founded by Eric S. Raymond and Bruce Perens in 1998. This institution holds a list of licenses that are considered open-source by the organization.
In this post, we refer to open-source licenses to those considered like this by the OSI.
You can find a list of all licenses consider open-source by the OSI on this external link.
Free Software Licenses
Free software license could means a lot of things, depending in what we consider that “free” means.
The Free Software Foundation (FSF) is a non-profit organization founded by Richard Stallman in 1985.
In this post, we refer to free software licenses to those that are considered free by the FSF, assessing whether these licenses can ensure the four essential freedoms formulated by the organization.
Free software licenses is a more restrictive term than open-source licenses. It means that all free software licenses are open-source, but not all open-source licenses are free software licenses.
A non-free open-source software license would be a program whose source code is available but it does not allowed to use, redistribute or modify it, or requires asking for permission, or it has very strong restrictions. An example would be the SAP R/3 source code.
You can find a list of all licenses considered free software licenses by the FSF on this external link.
Free and Open-source Software (FOSS) Licenses
Free and Open-source (FOSS) is a neutral term that groups all licenses considered free and open-source.
Aspects of Free and Open-Source Software (FOSS) Licenses
Aspects covered in licenses that may be considered when comparing different open source licenses:
- Disclose source
- License & copyright notice
- Patent grant : protection of licensees from patent claims, both from code contributors and licensees
- Sublicensing : whether modified code can be licensed in a different license
- Trademark use : whether the license claims trademark protection
- Private use
- Network use distribution
- Compatibility
You can check the criteria for comparison of software licenses on this external link.
List of types of Software Licenses
An important remark is that a software without license is not equivalent to public domain. A software without license would get the default copyright granted on a given country, and it is not a recommended practice, especially if the plan is to release the code as open source.
The types of software licenses described on this post are:
- Public domain & equivalents
- Permissive
- Copyleft
- Proprietary
Public domain & equivalents
Apart from public domain, there are licenses that are considered public-domain-equivalent licenses and are very short licenses that keep no rights on the software.
People considering releasing a software as public domain or equivalent should take into account that releasing a code into the public domain or equivalent could bring legal issues to its creators, like patent-related claims from contributors or third parties.
Most open-source projects go for permissive licenses instead on public domain or public-domain-equivalent licenses not by chance; they are seeking a minimal license that prevents the developers being sued.
Examples of public-domain-equivalent licenses:
- The Unlicense
- Creative Commons Zero 1.0 Universal
Public domain
Public domain would be at the top of permissiveness.
Anyone can modify and use a software under public domain without restrictions.
Some countries do not allow to put something on public domain. If you are really interested in releasing something under public domain, you should take a look at public-domain-equivalent licenses (that are sub-type of permissive licenses).
The Unlicense
The Unlicense is a public-domain-equivalent license.
It is compatible with GNU GPL licenses.
FSF recommends to use CC0 or CC Zero license instead of the Unlicense, stating that:
CC0 also provides a public domain dedication with a fallback license, and is more thorough and mature than the Unlicense.
Creative Commons Zero 1.0 Universal
Creative Commons Zero, commonly abbreviated as CC0, is a public-domain-equivalent license.
FSF does not recommend to use a license that gives up patent licenses, like CC0. As explained by FSF on this external link:
[CC0] For works of software it is not recommended, as CC0 has a term expressly stating it does not grant you any patent licenses.
Because of this lack of patent grant, we encourage you to be careful about using software under this license; you should first consider whether the licensor might want to sue you for patent infringement. If the developer is refusing users patent licenses, the program is in effect a trap for users and users should avoid the program.
Permissive
Permissive licenses are also known as BSD-style or Apache-style licenses.
They contain minimal requirements about how the software can be modified or redistributed.
Permissive licenses are better to ensure that code can be shared freely, is reusable and is compatible with other licenses.
On the other hand, they are more prone to be used in commercial projects or be patented than restrictive or commercial licenses.
Example of permissive licenses are:
- Boost Software License 1.0
- BSD 2-clause “simplified” license
- BSD 3-clause “new” or “revised” license
- MIT license
- Apache license 2.0
MIT license
MIT license is license developed in the MIT university.
It is probably the most popular permissive license. As it is a very short license, it ensures re-usability and license compatibility, though it is not the most protective for developers.
The FSF recommends to refer to it as X11 license, as according to them there is more than a license issued by MIT, for example the Expat license.
On the other hand, Wikipedia considers that X11 and Expat are variants of MIT license, and some organizations like Joinup.eu also uses the term “MIT” license. This post refers to this license as MIT License.
MIT license is compatible with GNU GPL licenses.
BSD 2-clause license
BSD 2-clause license is similar to MIT license.
BSD 3-clause license
BSD 3-clause license is more restrictive than BSD 2-clause license.
As of 2023, the 3-clause is the most frequent of the BSD clauses. It is derived from the original BSD 4-clause license.
Apache license, version 2.0
Apache license, version 2.0 is compatible with GNU GPL 3 license, but it is not compatible with GPL 2.
Among the most popular permissive licenses, it is probably the one that protects better the developers without being restrictive (i.e., forcing to keep using the same license).
On the other hand, it is not the most reusable and compatible. For example, according to the FSF, Apache 2.0 license is not compatible with GPL 2.0.
FSF recommends the Apache license over the other permissive licenses because it prevents “patent treachery”. You can read this opinion on this external link. With the term “patent treachery”, FSF refers to the practice of contributors suing for patent infringement, and Apache adds some clauses to hinder it.
You can read more about Apache license, version 2.0 on this post.
Copyleft
Copyleft licenses are also known as reciprocate, share-alike or restrictive licenses.
These licenses allow you to modify the licensed code and distribute new works based on it, as long as you distribute any new works or adaptations under the same software license.
Inside copyleft, some consider two different sub-types:
- Weak: code can be combined with other licenses, including commercial
- Strong: code cannot be combined with commercial licenses
Example of copyleft licenses:
- Weak copyleft
- Mozilla Public License (MPL)
- Eclipse Public License (EPL) 2.0
- European Union Public License (EUPL) 1.2
- LGPL v2.1
- Strong copyleft
- GNU GPL v2.0
- GNU GPL v3.0
- GNU Affero GPL (AGPL) v3.0
GNU GPL is the most popular one of copyleft licenses.
Take into account that all GPL licenses has two option: the “only” and the “or later”. If you choose the GPL “only” version, you only apply the selected version of the GPL license. If you choose the “or later” version, it means that it will be compatible and agree with future GPL versions.
FSF recommends that people choose the “or later” version because copyright lasts decades later than people deceases, and it is a difficult situation to handle.
You can find more information about what is copyleft on this external link.
Mozilla Public License (MPL) 2.0
Mozilla Public License (MPL) 2.0, shorten as MPL-2.0, is a copyleft license compatible to some extend with other copyleft or proprietary licenses.
You can distribute binaries under a proprietary license, as long as you make the source available under MPL.
Eclipse Public License (EPL) 2.0
Eclipse Public License (EPL) 2.0, shorten as EPL-2.0, is a copyleft license.
Binaries can be licensed under any license, as long as the source code stay available under EPL.
It is mostly used on projects by Eclipse foundation.
European Union Public License (EUPL) 1.2
EUPL was released in 2017.
The main reason for the European Union to create its own restrictive license instead of reusing an existing one:
- The licence should have equal legal value in many languages
- The terminology regarding intellectual property rights had to be conformant with the European law requirements
- To be valid in all Member States, limitations of liability or warranty had to be precise, and not formulated “to the extent allowed by the law” as in most licences designed with the legal environment of the United States in mind
It would be copyleft, as clarified on this external link:
the EUPL v1.2 is copyleft (or share-alike) for protecting the covered software only from exclusive appropriation, but it has no pretention for any “viral extension” to other software in case of linking.
Lesser General Public License (LGPL)
Lesser General Public License (LGPL) is considered a weak copyleft license.
It is derived from GPL license. In fact, LGPL is a set of additional permissions on top of the GPL.
LGPL allows you to link to open source libraries in your software. If you simply compile or link an LGPL-licensed library with your own code, you can release your application under any license you want, even a proprietary license. But if you modify the library or copy parts of it into your code, you will have to release your application under similar terms as the LGPL.
In conclusion, LGPL may be linked to proprietary code if no changes are applied to original code. In contrast, software with licenses strong copyleft GPL, for example, could never be linked to proprietary code.
General Public License (GPL) 2
GPL is the original GNU GPL family of licenses. It is probably the most popular family of copyleft or restrictive licenses.
Software that received under the GPL may be referred with the adjective “GLPed”.
GPL license is only triggered when software is distributed to users.
GPL licenses have a “viral” extension of licence coverage so other linked software will be GPLed. This viral aspect is part of the criticism against the license.
GPL 2 is not compatible with GPL 3, and vice versa, as they both are restrictive licenses that restrict each other mutually.
Linux was licensed as a GPL2-only. To know more about this and why Linus Torvalds dislikes GPL3, follow this external link.
General Public License (GPL) 3
GPL 3 offers stronger protection against patents than GPL 2.
GPL-3.0 is more compatible than GPL-2.0. For example, Apache-2.0 and CC BY-SA 4.0 is one-way compatible with GPL-3.0, while they are incompatible with GPL-2.0.
You can read more about CC BY-SA 4.0 and GPL-3.0 compatibility on this external link.
GPL-3.0 is not compatible with GPL-2.0-only, and vice versa. However GPL-2.0-or-later is one-way compatible with GPL-3.0.
Affero General Public License (AGPL)
Affero General Public License (AGPL) would be the same as GPL but adding a clause that adds the obligation to share the source code if it is run to offer service to a computer network. This was done to avoid a loophole on GPL license.
GPL license is only triggered when software is distributed. In web applications, software may be never distributed and it is run only from servers. This allows to run modified versions of GPLed software in servers without sharing the source code.
AGPL tries to avoid this situation by adding the extra clause.
This situation is explained by FSF on this external link.
GNU AGPL is not compatible with GPLv2.
Proprietary
Proprietary licenses are the most restrictive software licenses of all types.
Viewable Source
Viewable source or read-only open source software has a license that allow to see the code but not.
As it allows to access the code but not modify or distribute it, it is not considered free or open software. Because of this, I would not recommend to use the word “open” when describing this kind of software, as it may lead to confusion.
Viewable source license examples:
- Oracle Binary Code License Agreement
Oracle Binary Code License Agreement
Oracle Binary Code License Agreement allows users to view source code, but prohibits modification or redistribution of the code.
Some versions of the Java Development Kit (JDK) (like Oracle JDK) and JavaFX are released under this license.
Closed Source
Proprietary closed source is usually under the idea that all rights are reserved. It is generally used for proprietary software where the work may not be modified or redistributed.
If the rights to access, modify or distribute the source code is kept by the authors, then it cannot be open software.
Creative Commons are licenses that are thought to distribute creative works like images, music or written content. Nevertheless, they are sometimes used for software. These licenses do not necessarily allow to access, modify or distribute the source code.
When developing software, it is recommended to use a specific software license to distribute software it instead of Creative Commons.
Choosing an Open Source Software license
There is no a perfect open source licenses that can is suitable for all situations. It depends on the biggest concerns you have about the software.
In fact, you may consider that some components are released under different open source licenses because they have different needs or concerns.
As a general rule, the more permissive the license is, the more flexible, compatible and reusable it will be.
On the other hand, the more restrictive the license is, the more protection against being sued, used in commercial projects it will get.
As a conclusion, the open source licenses need to make a trade-off between flexibility and protection.
Resources to choose an Open Source Software License
There are some resources available that aid you to choose your open source license.
There is the web Choose a License. You can visit it on this external link.
Joinup Licensing Assistant (JLA) is a tool to select an open license developed by European Commission’s Joinup. You can find it on this external link.
The Open Source Guide includes one section that explains which license you should take. You can find it on this external link.
FAQs about Open Source Software Licenses
What does it mean when they say that a License is compatible with Another?
One license is compatible when you can take the code under one license, modify it, and re-license it under the other license. Usually is only unidirectional, converting the permissive license into the more restrictive license.
Two licenses are not compatible when you cannot convert the licenses in any way.
To check which licenses are compatible with GPL, please check this external link.
Does Licensed Code get into Public Domain once it expires?
Read this interesting external link about expiration of license code.
Why most Free and Open Source Software (FOSS) Projects are not Public Domain?
The FOSS initiative started as a reaction to big corporations trying to take advantage of existing open-source projects and claiming copyright over the modifications. The history of Unix and AT&T is a good example. Another situation that wanted to avoid is corporations appropriating open source projects and make them proprietary and closed-source.
The goal of the first FOSS supporters was enabling rights on free and open source software (FOSS) and ensuring the survival of the community. The objective of the FOSS initiative was never to give up rights on software rights, but exactly the opposite: to leverage the intellectual property laws to protect free access, modification and distribution to software.
UC Berkely designed the BSD license in 1988 with the aim of avoiding losing authorship and prevent other parties claiming the source code.
FSF went a step forward and designed the GPL license in 1989 with the goal of protecting the Four Essential Freedoms proclaimed in the Free Software Definition. This is why GPL is more restrictive.
There are different opinions about what these restrictions should be and whether they should exist or not, and these disagreements is one of the reasons why there are so many open source licenses.
In addition, supporters of restrictive license (for instance, the FSF) are of the opinion that if software is made not only public domain but permissive, corporations would take control of the software by adding some extra functionality, making it close source and proprietary and reclaiming all the attention and support that the open-source version was receiving.
There is a discussion about this topic on this external link.
What are the Risks of Developers giving up all Rights on Software?
The FSF does not recommend to use a license that gives up patent licenses, as the original developers could get sued because of patent infringement.
Why not to release software as Public Domain instead of using Licenses that are almost Public Domain?
There are licenses that are almost public domain, like the Unlicense or Creative Commons Zero (CC0).
A good question is why these licenses even exist, when something can be public domain.
Some countries, like Germany, do not allow to give up your copyright. To release a software under Public Domain would not be allowed. So if you want to make your software open-source, the closest you can do is release software under one the most permissive licenses.
You can find more information about this on this external link.
External references
- Synopsis Editorial Team; “5 types of software licenses you need to understand“; Synopsis; 2020-04-07.
- Snyk; “Open sources licenses: Types and comparisons“; Snyk
- tl;drLegal; “Software Licenses in Plain English“, tl;drLegal
- Aner Mazur; “Apache license 2.0, MIT license or BSD license : Who is the fairest of them all?“; Snyk; 2017-11-01.
- quorten; “CC0 or Unlicense?“; GitHub
[…] It is recommended that your software always have a license, specially if your purpose is sharing it. You can find more info about types of software licenses on this post. […]
[…] Open-source licenses […]
[…] It is recommended that your software always have a license, specially if your purpose is sharing it. You can find more info about types of software licenses on this post. […]