This post is an introduction to free and open source software (FOSS) licenses.
This post is part of the series of articles, whose main post is Software Licenses.
Definition of Free and Open Source Software (FOSS) Licenses
In the world of software, we can distinguish between free and open-source software (FOSS) and closed-source software.
Free and open-source software (FOSS) can be defined generally as the one whose source code is freely accessible, modifiable and distributable by anyone, including users and third-party developers.
Technically, the term FOSS should be used only to software that can be considered free software and open software at the same time. We are defining these two terms below.
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 the default option, historically the first software to appear was FOSS and in the 1970s most of the software was distributed in this way.
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.
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.
The Open Source Definition was a copy of the existing Debian Free Software Guidelines.
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 and Open-source Software (FOSS) Licenses
Free and Open-source (FOSS) is a neutral term that groups all licenses considered free and open-source.
Nevertheless, it must be told that the FSF prefers the use of the term free/libre and open-source (FLOSS), as they consider that the term libre removes the ambiguity of “free” within the sentence.
Personally, I agree that the term libre, though it does not exist in English, is more univocal to the intended meaning of “free” in this context (“free as in free speech”, not “free as in free beer”). Nevertheless, the term “free” has been used extensively by the FSF since its origins (even in the name of the organization), so if this term should be taken seriously we should revise all acronyms related to free/libre software and not only FOSS/FLOSS (for instance, the organization should be renamed as FLSF).
In addition, FOSS seems to be much more used in common language that FLOSS.
For these and other reasons, I opt to use the term FOSS instead of FLOSS on this post and blog.
Aspects of Free and Open-Source Software (FOSS) Licenses
Each license is different, and they have different characteristics.
There is no perfect license for all situations. Depending on the context and intended use of software, there will be some characteristics that are sought while others are avoided. So it is important to identify what are the need, and then check the needs against the characteristics of the candidate licenses.
You can find a detailed list of characteristics on this post.
Patent grant is a characteristic of license mentioned frequently on this post, so it is recommended to have a look at least to this characteristic.
You can check the criteria for comparison of software licenses on this external link.
Types of Free and Open-Source Licenses
There are 3 main types of free and open-source software licenses:
- Public domain & equivalents
- Permissive
- Copyleft
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 software cotributors and users, like patent-related claims from contributors or third parties.
Most FOSS 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 contributors or users being sued.
Examples of public-domain-equivalent licenses:
- The Unlicense
- Creative Commons Zero 1.0 Universal
You can read more about public-domain-equivalent licenses on this post.
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 or patented projects compared to restrictive licenses.
Example of permissive licenses are:
- Boost Software License 1.0
- ISC license
- MIT licenses
- BSD 2-clause “simplified” license
- BSD 3-clause “new” or “revised” license
- Apache license 2.0
You can read more about permissive licenses 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: source code can be combined with other licenses, including proprietary, without modifying the original license
- Strong: when source code is combined with other source code, the latter loses its original license and adopts the strong copyleft license
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
GPL licenses are the most popular 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.
You can read more information about copyleft software licenses on this post.
Choosing a FOSS license
You can find information and tools to choose a free and open source software (FOSS) license on this post.
Creating Policies for Free and Open-Source Software
You can find a list of links about free and open-source software policies on this external link.
FOSS Organizations
Feature FOSS organizations:
- Free Software Foundation
- Open Source Initiative
Free Software Foundation
Free Software Foundation (FSF)
Open Source Initiative
Open Source Initiative (OSI)
Open Source Software Zone
United Patents’ Open Source Software Zone (OSS Zone) is an association of companies like Linux Microsoft.
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 most permissive license into the most restrictive license.
Take into account that the most permissive should be more permissive or equal to the most restrictive license in all aspects. If there is an extra requirement in the most permissive license that is not included in the most restrictive license, they are not compatible.
For this reason, Apache 2.0 license is not compatible with GPLv2 license, because while Apache 2.0 is more permissive it contains the clause 3 “Grant of Patent License” that does not exist in GPLv2. GPLv3 included a similar clause, making Apache 2.0 compatible with this version.
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 not to release software as Public Domain instead of using Licenses that are Public Domain-equivalent?
There are licenses that are in practice very similar to public domain, like the Unlicense or Creative Commons Zero (CC0).
A good question is why these licenses even exist, when something can be released to the public domain.
Some countries, like Germany, do not allow to give up your copyright, so in some context it is not allowed to release a software under Public Domain. In this cases, if you want to make your software public domain the closest you can do is release it under a public domain-equivalent license.
You can find more information about this on this external link.
Why most Free and Open Source Software (FOSS) Projects are not Public Domain or Public Domain-equivalent?
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 Berkeley 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 FOSS 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.
Is there Free Software that is not Open Source, or viceversa?
Software licensed under the WTFPL http://sam.zoy.org/wtfpl/ is considered free (as in freedom), but not open-source (as it is not OSI approved).
Software licensed under the Artistic License 1.0 is considered open-source, but not free (FSF did not approved the text, considering it too vague).