Table of Contents
Legal questions have assumed a somewhat more prominent role in free software projects over the last decade or so. It is still the case that the most important things about your project are its the quality of its code, its features, and the health of its developer community. However, although all open source licenses share the same basic guarantees of freedom, their terms are not exactly the same in all details. The particular license your project uses can affect which entities decide to get involved in it and how. You will therefore need a basic understanding of free software licensing, both to ensure that the project's license is compatible with its goals, and to be able to discuss licensing decisions with others.
Please note that I am not a lawyer, and that nothing in this book should be construed as formal legal advice. For that, you'll need to hire a lawyer or be one.[132]
In any discussion of open source licensing, the first thing that becomes apparent is that there seem to be many different words for the same thing: free software, open source, FOSS, F/OSS, and FLOSS. Let's start by sorting those out, along with a few other terms.
Software that can be freely shared and modified, including in source code form. The term was first coined by Richard Stallman, who codified it in the GNU General Public License (GPL), and who founded the Free Software Foundation (https://www.fsf.org/) to promote the concept.
Although "free software" covers the same set of software[133] as "open source", the FSF, among others, prefers the former term because it emphasizes the idea of freedom, and the concept of freely redistributable software as primarily a social movement rather than a technical one. The FSF acknowledges that the term is ambiguous — it could mean "free" as in "zero-cost", instead of "free" as in "freedom" — but feels that it's still the best term, all things considered, and that the other possibilities in English have their own ambiguities. (Throughout this book, "free" is used in the "freedom" sense, not the "zero-cost" sense.)
Free software under another name. The different name is sometimes used to indicate a philosophical difference, however. In fact, the term "open source" was coined, by the group that founded the Open Source Initiative (https://www.opensource.org/), as alternative labeling for "free software". Their goal at the time was largely to make such software a more palatable choice for corporations, by presenting it as a development methodology rather than as a political movement.[134]
While any license that is free is also open source, and vice versa (with a few minor exceptions that have no practical consequences), people tend to pick one term and stick with it. In general, those who prefer "free software" are more likely to have a philosophical or moral stance on the issue, while those who prefer "open source" either don't view it as a matter of freedom, or are not interested in advertising the fact that they do. See the section called “"Free" Versus "Open Source"” for a more detailed history of this terminological schism.
The Free Software Foundation has an excellent — utterly unobjective, but nuanced and quite fair — exegesis of the two terms, at https://www.fsf.org/licensing/essays/free-software-for-freedom.html. The Open Source Initiative's take on it can be found at https://opensource.org/faq#free-software.
Where there are two of anything, there will soon be three, and that is exactly what is happening with terms for free software. Many people have started using "FOSS" (or, more rarely, "F/OSS"), standing for "Free / Open Source Software". Another variant gaining momentum is "FLOSS", which stands for "Free / Libre Open Source Software" (libre is familiar from many Romance languages and does not suffer from the ambiguities of "free"; see https://en.wikipedia.org/wiki/FLOSS for more).
All these terms mean the same thing: software that can be modified and redistributed by everyone, sometimes — but not always — with the requirement that derivative works be freely redistributable under the same terms.
Compliant with the Debian Free Software Guidelines (https://www.debian.org/social_contract#guidelines). This is a widely-used test for whether a given license is truly open source (free, libre, etc). The Debian Project's mission is to maintain an entirely free operating system, such that someone installing it need never doubt that she has the right to modify and redistribute any or all of the system. The Debian Free Software Guidelines are the requirements that a software package's license must meet in order to be included in Debian. Because the Debian Project spent a good deal of time thinking about how to construct such a test, the guidelines they came up with have proven very robust (see https://www.debian.org/social_contract#guidelines), and as far as I'm aware, no serious objection to them has been raised either by the Free Software Foundation or the Open Source Initiative. If you know that a given license is DFSG-compliant, you know that it guarantees all the important freedoms (such as forkability even against the original author's wishes) required to sustain the dynamics of an open source project. Since 2004, the Debian Project has maintained a list of known DFSG-compliant licenses at https://wiki.debian.org/DFSGLicenses. All of the licenses discussed in this chapter are DFSG-compliant.
Approved by the Open Source Initiative. This is another widely-used test of whether a license permits all the necessary freedoms. The OSI's definition of open source software is based on the Debian Free Software Guidelines, and any license that meets one definition almost always meets the other. There have been a few exceptions over the years, but only involving niche licenses and none of any relevance here.[135] The OSI maintains a list of all licenses it has ever approved, at https://www.opensource.org/licenses/, so that being "OSI-approved" is an unambiguous state: a license either is or isn't on the list.
The Free Software Foundation also maintains a list of licenses at https://www.fsf.org/licensing/licenses/license-list.html. The FSF categorizes licenses not only by whether they are free, but whether they are compatible with the GNU General Public License. GPL compatibility is an important topic, covered in the section called “The GPL and License Compatibility”.
The opposite of "free" or "open source." It means software distributed under traditional, royalty-based licensing terms, where users pay per copy, or under any other terms sufficiently restrictive to prevent open source dynamics from operating. Even software distributed at no charge can still be proprietary, if its license does not permit free redistribution and modification.
Generally "proprietary" and "closed-source" are synonyms. However, "closed-source" additionally implies that the source code cannot even be seen. Since the source code cannot be seen with most proprietary software, this is normally a distinction without a difference. However, occasionally someone releases proprietary software under a license that allows others to view the source code. Confusingly, they sometimes call this "open source" or "nearly open source," etc, but that's misleading. The visibility of the source code is not the issue; the important question is what you're allowed to do with it: if you can't copy, modify, and redistribute, then it's not open source. Thus, the difference between proprietary and closed-source is mostly irrelevant; generally, the two can be treated as synonyms.
Sometimes commercial is used as a synonym for "proprietary," but this is carelessness: the two are not the same. Free software is always commercial software. After all, free software can be sold, as long as the buyers are not restricted from giving away copies themselves. It can be commercialized in other ways as well, for example by selling support, services, and certification. There are billion-dollar companies built on free software today, so it is clearly neither inherently anti-commercial nor anti-corporate. It is merely anti-proprietary, or if you prefer anti-monopoly, and this is the key way in which it differs from per-copy license models.
Having no copyright holder, meaning that there is no one who has the right to restrict copying of the work. Being in the public domain is not the same as having no author. Everything has an author, and even if a work's author or authors choose to put it in the public domain, that doesn't change the fact that they wrote it.
When a work is in the public domain, material from it can be incorporated into a copyrighted work, and the derivative is thus under the same overall copyright as the original copyrighted work. But this does not affect the availability of the original public domain work. Thus, releasing something into the public domain is technically one way to make it "free," according to the guidelines of most free software certifying organizations (see https://opensource.org/faq#public-domain for more). However, there are usually good reasons to use a license instead of just releasing into the public domain: even with free software, certain terms and conditions can be useful, not only to the copyright holder but to recipients as well, as the next section makes clear.
A license that not only grants the freedoms under discussion here but furthermore requires that those freedoms apply to any derivative works.
The canonical example of a copyleft license is still the GNU General Public License, which stipulates that any derivative works must also be licensed under the GPL; see the section called “The GPL and License Compatibility” for more.
A license that grants the freedoms under discussion here but that does not have a clause requiring that they apply to distributed derivative works as well.
Two early and well-known examples of non-reciprocal licenses are the BSD and MIT licenses, but the more recent Apache Software License version 2 (https://www.apache.org/licenses/LICENSE-2.0) is also very popular — increasingly so — and somewhat better adapted to the legal landscape of modern open source software development.
[132] For a deeper understanding of how copyright law relates to free software, see https://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html, published by the Software Freedom Law Center.
[133] Technically, there are certain uncommon situations in which software can be distributed in a way that meets only one of the Free Software Definition and the Open Source Definition. These are very rare edge cases, however; they do not affect anything in this chapter, so I won't go into detail about them here. To learn more about them, one place to start is a conversation Alexandre Oliva and I had in 2020, at https://identi.ca/lxoliva/comment/FzE-8xdyS1au9z22QKA-TA, in which he gives some examples.
[134] Disclosure: Long after these events, I served as a member of the Board of Directors of the Open Source Initiative for three years, from 2011-2014. The ideological gap between the OSI and the FSF was much smaller by then than it was when the OSI was founded, in my opinion, and the two organizations have increasingly found common ground on which to cooperate. I remain a happy member of both, and urge you to join them too: https://opensource.org/join and https://fsf.org/join.
[135] There is one relatively new license, the Cryptographic Autonomy License, version 1.0 (https://opensource.org/licenses/CAL-1.0, approved by the OSI in 2020), that has unusual provisions regarding data portability and that has caused some disagreement over whether it truly meets the Open Source Definition. Two good overviews of CAL-1.0 are Heather Meeker's at https://heathermeeker.com/2020/02/15/cryptographic-autonomy-license-approved-by-osi/ and Jonathan Corbet's in Linux Weekly News at https://lwn.net/Articles/797065/.