An Introduction to Free & Open-Source Licensing
As a coder who’s also a lawyer, I’m often asked by other programmers about free and open-source (“FOSS”) licenses. In particular, people want to know
- What do the various FOSS licenses mean?
- Is there a reason to use one license over another?
In this post, I’ll cover the basics of FOSS licenses and provide some useful links for further reading. My hope is that this will be helpful to you in learning about the different licenses. Note that what I can’t do is tell you that you need to use a particular license – that’s something only you can decide, preferably with the assistance of an attorney.* With that out of the way, let’s proceed!
What Are Software Licenses?
Essentially, licenses are just contracts – legally enforceable agreements between people and/or legal entities, like companies. Those who agree to be bound by a contract are called the “parties” to the contract. By “enforceable,” I mean that, if a party agrees to be bound by a contract and then breaks or “breaches” the contract (by, e.g., not doing something that party promised to do), the other party to the contract can sue the party who breached.
Software licenses are contracts that give a party certain rights relating to a piece of software. At this point, let’s define some additional useful terms: the party who created and/or owns the software outright we’ll call the “owner,” and we’ll refer to the one who gets the rights to the software through the contract as the “user.”
Any right granted to the user may be limited in time, space, or otherwise (e.g., for non-commercial use). Alternatively, the user could be granted an exclusive licenses that permits only that user to do something with the software. (Think of a deal that lets company X distribute software written by company Y). An owner can also transfer or assign rights to another (because sometimes, it’s better to sell out and move on). In addition, the owner can structure the license such that the user can grant another (“downstream”) user some rights, and the owner can control how that happens.
Now, you may wonder what rights one can give and get via FOSS licenses. However, before I discuss specific licenses, I should introduce a few categories of rights – it will make the discussion of FOSS licenses much easier.
Intellectual Property Rights in Software
You’re probably familiar with the term intellectual property, or IP. It refers to the rights conferred and protected in the U.S. by copyright, patent, trademark, and trade secret law. These regimes have different origins: while copyright and patent are federal law rooted in the U.S. Constitution (Art. I, Sec. 8, granting Congress the power “[t]o promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries”), trademarks are protected by both federal and state law, while trade secrets generally arise under state law only. Note that, although a good deal of the “law” here is codified in statutes and regulations, much of it is not; instead, it arises from and exists in the form of judicial opinions.
Software implicates all of these legal regimes. That is, the creator of software may have rights concerning that software arising from copyright, patent, trademark, and/or trade secret law. Thus, software license may grant a use certain of those rights. So what are they?
Very briefly, copyright protects authors’ original works by giving the author(s) of a work a number of exclusive rights, including those to
- reproduce the work;
- make derivative works (meaning, in the software context, to modify code);
- rent, lease, or sell copies; and
- perform the work.
You probably already associate copyright with books, and you may have noticed that the Constitution refers to “writings.” Nevertheless, the definition of “writings” has extended to include music, visual art, and, yes, software. Specifically, source code is protected by copyright. And, since the 1990s, copyright arises automagically as soon as a copyrightable (basically original) work is “fixed.” For software, that just means saving it.
As you’ll see below, FOSS licenses concentrate upon issues of copyright, particularly the rights to distribute verbatim copies of code and modifications of code.
Similarly, patents give an inventor the exclusive rights to make, use, or sell the invention. Unlike copyright, a patent must be granted by the government. Software patents were not an issue until the mid-1990s, when the Court of Appeals for the Federal Circuit (which hears patent cases appealed from lower federal courts) decided that programs were patentable. Since then, software patents have been the focus of much (well-deserved) consternation, but – at least for now – the U.S. Patent and Trademark Office grants software patents. Therefore, software licenses may also discuss patent rights.
Trademarks and Trade Secrets
Less commonly, software licenses may also include rights from trademark and trade secret law. Trademark law protects the investment put into building brands by granting the owner of a mark the limited right to use that mark in commerce. When marks are used to identify services rather than goods, they are called “service marks.” Trade secrets, on the other hand, protect confidential information that confers a business advantage that a business takes reasonable steps to keep secret.
Like other software licenses, FOSS licenses exist to define the scope of what a user can do with the software. They also serve to assert some control over how a user may grant rights to a downstream user, which can make or break the utility of a license for a given program.
This is the current version of one of the oldest free software licenses, commonly referred to as the GPL. It originally was devised to require free distribution of software that is based upon free software.
Among other things, the GPL grants user full rights to run, modify, and study the software and source code. The user can also
- sell unmodified code and offer support or a warranty for a fee;
- distribute modified source code with a notice showing when and how it was modified; and
- distribute non-source versions, so long as the user maintains and distributes or offers to distribute machine-readable source for that version.
Critically, any software based upon software originally distributed under the GPL must also be distributed subject to the GPL. The user can add only a limited number of terms, such as those
- disclaiming any warranty,
- requiring the downstream user to maintain notices,
- excluding trademarks and service marks, and
- requiring indemnification.
Aside from those, the user cannot add more terms when distributing to a downstream user. Thus, the GPL is “viral” in that it infects all software based upon GPL’d software. Needless to say, this feature has been the subject of much debate, with focus on whether owners should assert any control over downstream users and, if so, how much control to assert.
The GPL also exempts the software form the anti-circumvention provisions of the DMCA and the 1996 WIPO treaty. Its term is the same that for copyright (currently the lifetime of the author plus seventy years).
The aforementioned disagreement over the viral nature of the GPL led to the creation of of the GNU Lesser General Public License, or LGPL. This license serves as a compromise in that it permits libraries based upon free software to be used in proprietary software.
The LGPL incorporates the terms of GPL v3, except for the following:
- It does not require the user to exempt all code from anti-anti-circumvention clause of the DMCA/WIPO 1996 Treaty.
- The user can use material from free software header files in proprietary software with notice and copy of GPL & LGPL.
- The user can distribute a free library with a proprietary application with notice and copies of the GPL & LGPL.
It also includes a number of other technical conditions for distributing an application combining proprietary code with a free library, such as those requiring that it display the GPL/LGPL if it displays any copyright info and that it provide the source code for part of the application using the library or use a shared library mechanism to load a copy of library already on the downstream user’s system.
GPL & LGPL Considerations
Compliance with the GPL’s and LGPL’s mandates for public distribution of all or some source code is easy today, thanks to services like GitHub, BitBucket, and others. However, the significant number of technical requirements have led to a permutation of use cases that make the GPL and LPGL two of the more confusing licenses. By way of illustration, theGPL/LGPL FAQ is about 40 pages!
Furthermore, the viral nature of the GPL and the limited nature of the LGPL’s provisions for combined free and proprietary software poses a problem for many. Because it is not obvious how the GPL might operate in conjunction with other FOSS licenses, the publisher of the GPL maintains a web page detailing the GPL’s compatibility with those licenses. By “compatible”, the publisher of GPL means whether another license permits code released under that license to be combined with GPL code and, in turn, distributed under the GPL. That is, the GPL must be the license that survives a combination with code distributed under another license in order for that license to be deemed compatible. As that page make clear, the existence of code distributed under prior versions of the GPL adds to the complexity of resolving questions of compatibility with other licenses.
Obviously, if you use GPL/LGPL software in your application, your options are rather limited. But if you don’t, you still might want to use the GPL/LGPL if you’re committed to free software and want to ensure that downstream users treat modifications to your code as free software as well.
The quintessential “short and sweet” FOSS license, the MIT license is increasingly popular among FOSS programmers. Like the GPL family of licenses, it grants user all rights to use, study, and modify the software. Unlike the GPL, the MIT license also allows the user “to deal in the Software without restriction , including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies” (emphasis added). Additionally, the user may permit downstream users to do so.
The primary restriction is that downstream distribution of all or “substantial portions” of the software must be accompanied by the MIT license. If you’re not sure what “substantial portions” means in this context, that’s good, because it’s potentially ambiguous.
Thus, the MIT licenses permits mixing MIT-licensed software with proprietary software. It also allows downstream distribution of modifications under substantially different terms, so it is apparently also “compatible” with the GPL in the sense described above. The MIT license also includes a broad disclaimer of liability.
In sum, the MIT license is much simpler to implement than the GPL and permits downstream users to do what they will, so long as they indicate that their modifications are based upon MIT-licensed software. It is clear why MIT has become the license of choice for many authors (including myself, for the time being).
Under this version of the BSD License, the user may redistribute source or binary code, as originally acquired or as modified, but the user must include a copy of the BSD License and disclaimer of warranty. In addition, using licensor’s name in advertising requires written permission. This clause is meant to prevent users who use, distribute and/or modify BSD-Licensed code from suggesting that their endeavors are endorsed by the original owners or authors.
This is basically same as the above, 3-Clause BSD License without the advertising restriction. It’s nice and short, and it’s hard to see what’s different from the MIT license.
The Apache License is notable in that it explicitly grants copyright and patent rights to the licensee (in our terminology, the user). Of the rights bundled under copyright, the user acquires those to copy, distribute, display, perform, and prepare derivative works. As to any patents owned by any contributor to the software, Apache grants the user the rights to make, use, sell work with respect to those patent claims. However, the patent rights terminate if the user files a patent suit claiming the software or a contributor’s portion of the software.
Thus, the Apache License attempts to squelch patent lawsuits by those who contribute their patented software to an Apache-Licensed project by threatening to pull their rights to use portions patented by other contributors. A contributor who sues for patent infringement is therefore subject to patent suits by other contributors. This mechanism is less than ideal, if only because the threat of additional litigation often means little to someone already committed to filing a lawsuit; nevertheless, it’s nice to see a FOSS license address these issues.
Under the Apache License, the user can redistribute the software with notice of any modifications and a copy of the license. The user must maintain all relevant licenses in the derivative source code. Some additional formalities apply: if the program contains a “Notice” file, the user must include the relevant licenses in that file in human-readable form, in the source code files, in the accompanying documentation, or in a display within the program.
When distributing modified Apache-licensed software, a user can add terms that cover only the modifications. The license excludes trademarks, disclaims warranty and limits liability. A user may charge a fee to downstream user for support, warranty, and indemnification.
The Apache License is more explicit than the MIT License and permits users to control the terms under which their contributions are licensed. However, the Apache License remains in force over software originally distributed under the Apache License. In addition, it is, despite its length, less onerous than the GPL.
You should now have enough information to start asking the right questions about licensing for your next free or open-source software project:
- What do I want to let users of my code do?
- What do I want their users to be able to do to with modified versions of my code?
- Do I want to lock people into redistributing modifications as free software?
Please note that this is just a broad overview. In particular, intellectual property law and software licensing present numerous areas of inquiry, and entire careers are spent probing the intricacies of patent law alone.
For further reading, I recommend visiting the following:
- Open Software Initiative
- Free Software Foundation Licensing & Compliance Team
- Electronic Frontier Foundation
- Understanding Open Source and Free Software Licensing (a bit old, but a good introduction)
- Comparison of free and open-source software licenses
*Although I am a lawyer, this post does not constitute legal advice or attorney advertising; rather, it is meant as a starting point for further education and to foster discussion in the coding community.