A software license is a written or digital document accompanying the software the defines the terms and conditions to use it. It is based on copyright laws, that protects the source code behind software.
This post enumerates the main categories of software license that can be found in the industry, with a special focus on free and open-source software (FOSS) and source-available licenses.
When comparing software licenses, some are more permissive or restrictive than others, indicating that the limitations of use are more expanded or limited. These licenses are introduced on this post in descending order of permissiveness (or ascending order of restrictiveness).
This is the main article of a series of posts on software licenses. Click on the links below to jump to more specific posts about certain types of software licenses.
- Software licenses (you are here)
- Free and open source software (FOSS)
- Proprietary
- Source-available
- Open core
- Closed source
Software License Factors
Factors to review in a software license:
- Source visibility
- Permittivity
- Compatibility
- License Amendment
- Commercial use
- Attribution requirement
- Distribution requirements
- Patent grant
- Warranty and liability
- Termination conditions
- Governing law
- Case law support
- Popularity
Dynamic Aspects of Software License
This section covers the dynamic aspects of software licenses that provides it flexibility to update them, combine source code from different licenses, release source code under multiple licenses, or change the license assigned to a given source code or project.
The various types of software licenses offer different degrees of dynamism and flexibility, so it is interesting to understand these concepts before explaining all the categories.
Dynamic aspects of software license explained on this post:
- License versioning
- License upgrade
- License compatibility
- License switching
- Multi-licensing
License Versioning
Software licenses are not definitive and are reviewed over the time by their publishers or maintainers.
Reasons to review a license include:
Improve the license terms or address emerging legal issues.
- Improve the license terms
- Address emerging legal issues.
For example, the Free Software Foundation (FSF) maintains the GNU General Public License (GPL). This license was updated as GPLv2 in 1991 and as GPLv3 in 2007.
License Upgrade
The license upgrade, license amendment or “or-later” provision refers to a permission or allowance within the license that allows users to choose to distribute and use the covered software under the terms of the current version of the license or, at their discretion, any later version of the same license that the licensor may publish in the future.
A license having this characteristics can be called plus license.
This provision is often included to allow the ongoing evolution and improvement of FOSS licenses. When a licensor includes the “or-later” provision in a license, it means that users have the flexibility to benefit from updates or revisions to the license without having to seek permission each time. The intent is to enable the adoption of improved license terms or to address emerging legal issues.
Example of plus licenses are GPL, LGPL, Apache License 2.0 or Mozilla Public License.
Adopting the “or-later” provision to a license could be optional.
For example, Linux kernel has a GPLv2-only license, meaning that it cannot be updated to GPLv3 without permission from the authors.
Releasing software under a license that includes the “or-later” provision is an act of trust toward the individual or organization that maintains the license in the future.
License Compatibility
Software license compatibility is a property of some software licenses that allows to combine a source code under an original license with other source code that uses a different but compatible software license.
Conditions to check whether a license A is compatible with a license B:
- License B includes all terms and requirements included in license A
- License A allows license compatibility under certain or no conditions
- If license A requires certain conditions to enable license compatibility, they are met.
When all requirements are met, you do not need permission from the original project owners to integrate source code with the two software licenses within the same project .
Optionally, license B may include additional terms of use not included in the original license. When this is the case, there is no backward compatibility.
One-way compatibility means that a license A is compatible with B, but license B is not compatible A. In this context, license B is considered more restrictive than A.
For example, MIT is one-way compatible with GPLv2 (meaning that MIT source code can be used within a GPLv2 project). On the other hand, GPLv2 is not compatible with a MIT project because GPLv2 has restrictions that are not included MIT.
Two-way compatibility means that license A is compatible with B, and license B is compatible with A.
An example of two-way compatibility is MIT and Apache 2.0.
An important concept in software license compatibility is the license of the combined work. Even when a project contains source code from two or more different licenses, the combined work still has a single license. The most restrictive license among all becomes the license of the combined work.
When adding source code to a project with source code with different licenses, the compatibility of the added source code license must be assessed against the license of the combined work.
Rules to determine the license of the combined work:
- When combining one-way compatible licenses, the most restrictive license remains as the one of the combine work.
- When combining two-way compatible licenses, the license of the combine work could be any of the combined licenses. It is up to the project owner to choose their preferred license.
Examples of license of combined work:
- When a project contains source code under MIT and Apache 2.0 (that are two-way compatible), the license of the combine work would be either MIT or Apache 2.0, up to the project owner.
- When a project contains source code under MIT, Apache 2.0 and GPLv2, the license of the combine work would be GPLv2, as MIT or Apache 2.0 are one-way compatible with GPLv2.
- When a project contains source code under GPLv2-or-later license and GPLv2-only, the license of the combined work is GPLv2-only, as GPLv2-or-later is one-way compatible with GPLv2-only.
License Switching
It is always possible to switch the license on new versions of software (license switch) or release an existing software version under a different license (multi-licensing). This is possible even when these changes are not covered under a “or-later” provision of the license or license are not compatible.
The only requirement to switch to a new license is that all software owners formally agree.
Obtaining this consensus can be really challenging when there are unidentified contributors (e.g., using pseudonyms), a considerable amount of them, or when there is disagreement.
Project owners that want to ease license switching can apply any of these approaches:
- Copyright accumulation. Project owner requires contributors to sign a contributor license agreement (CLA) where they grant ownership to the project owner, so the project owner has more flexibility about switching the license. This has the drawback that some contributors will prefer not to sign a CLA at the expense of not participating in the project.
- Contribution refusal. Project owner may block or restrict the external contributions to retain all ownership. This has the drawback that project would not get one of the benefits of FOSS, that is external contribution.
- Permissive licenses. Project may use a permissive enough license to ensure compatibility with any of the future licenses without needing contributors agreement.
You can read more about CLAs on this post.
Example of license switching is the licensing change of products Elasticsearch and Kibana from Apache 2.0 to Server Side Public License (SSPL) in 2021.
Multi-licensing
Multi-licensing software is released simultaneously under difference software licenses, i.e. it is distributed under more than one set of term and conditions.
A dual license software is released under two licenses; it is one specific (and the most common) case of multi-licensing.
An example of use of dual licensing is MySQL, that is released under both GPLv2 and a proprietary license.
Do not confuse multi-licensing software with the open core type of license, though many sources use the term interchangeably, while they are different. The main differences are explained below:
- In multi-licensing, the same source code is released under different licenses, of any kind.
- In open coure, a project contains parts of code that are released under free and open source software (FOSS) licenses and other parts that are released under proprietary licenses.
The concepts of FOSS and open core is explained in more detail in the section “Types of software license”.
Types of Software License
As an overview, software licenses can be classified as:
- Free and open source
- Public domain or equivalent
- Permissive
- Copyleft
- Proprietary
- Source-available
- Open core
- Closed source
You can find an explanation about the different types of software licenses on this post.
Software Licenses ID
SPDX is a project dependent of the Linux Foundation that provides an ID (or SPDX code) to identify univocally a license.