License Type Overview
- Related Articles:
- Derivative Works
- Contracts or Licenses, Does it Matter?
- Enforceability of Open Source Licenses
- Copyright Primer (Fair Use Doctrine)
The information in this article is intended to assist anyone seeking a general, comparative understanding of the most popular open source licenses currently in use, and the implications of their use.
There are many different licenses for software that is collaboratively developed. Categorizing dozens of different licenses now in use is a daunting task. The Open Source Initiative has made an effort to categorize some licenses as “open” and others as not. See www.opensource.org.
For purposes of this discussion, three categories of open source licenses will be discussed: "academic," "reciprocal," or "hybrid." Although there are many varieties of open source licenses in use today, both end user software and custom software components or systems that contain open source software are likely to be licensed under one of these three regimes. The specific examples described in each category below identify some of the main legal issues that licensees of open source software face. Note that for any copyright-based license grants contained in a given open source license, the fair use doctrine may apply. In addition, according to the conventions of contract law, any ambiguities in a license may be interpreted against the drafter—in these cases the licensor—regardless of extrinsic evidence of the licensor's intent.
As used on this page, the following terms will mean:
- Original Developer is a developer who makes Original Code available as open source using one of the licenses below.
- Original Code is the software that an Original Developer has licensed with an open source license.
- Subsequent Developer is anyone who modifies Original Code to create Modified Code.
- Modified Code is the altered Original Code made by a Subsequent Developer.
The term "academic" for this category of licenses comes from their genesis in academic institutions. These licenses usually allow licensees to modify the open source software, and do not require making those modifications available as open source to anyone else. This means that a software developer using open source made available under an academic license could ultimately create a proprietary product. “Academic" licenses include the BSD, MIT and Apache licenses.
Example: Berkeley Software Distribution (BSD)
- If distributing source code licensed under the BSD, the source code must contain a copyright notice specified in the license.
- If distributing software in binary form embodying source code licensed under the BSD, the software must also contain a brief list of specified conditions and disclaimers, in addition to the copyright notice.
- The names of the copyright holders and contributors to the open source licensed under the BSD may not be used to endorse products made using the open source without written permission.
- Software provided under the BSD is "as-is," without any warranties.
Potential Legal Issues:
- The BSD does not mention patent rights. This means that if the Original Developer's own patents would be infringed by uses of the software that are licensed under the BSD license, it is unclear whether the license has provided an implied right to practice the patents, or whether the licensee must get separate permission from the Original Developer to either use or sublicense the patents. Law on the subject of implied patent licenses is sparse, unclear and contradictory. However, some advocates of FOSS contend that a patent license will be implied from the terms of the copyright grant. The scope of such an implied license, however, is far from clear.
- The BSD does not provide for liability of the Original Developer for infringement of a third party's patent, copyright, or other intellectual property rights. This means that if the Original Code infringes a third party's copyright, for example, any Subsequent Developer or end user of the Modified Code could be sued for copyright infringement. The Subsequent Developer or end user would not have recourse to the Original Developer for this infringement. This issue is, of course, not unique to open source software. Many licenses to software that do not bear royalties—whether the code is provided in source or executable form—disclaim liability for some or all intellectual property infringement. However, the collaborative nature of the open source development model is sometimes thought to increase the chance of infringing code creeping into a code base. This, combined with the fact that open source code is often provided on a non-commercial basis, presents a paradigm of increased copyright or trade secret infringement risk.
For further reading on the BSD license and other academic licenses, see:
- Lawrence Rosen, Open Source Licensing: Software Freedom and Intellectual Property Law (2005), Ch. 5, available at http://www.rosenlaw.com/Rosen_Ch05.pdf.
- Andrew M. St. Laurent, Understanding Open Source and Free Software Licensing (2004), Ch. 2.
Reciprocal licenses, which some authors may alternatively refer to as "copyleft" or "viral" licenses (depending on the writer's opinion of them), require that a licensee who distributes any open source software or derivatives thereof must license those derivatives under the same terms as the reciprocal license, but only if the licensee chooses to distribute the derivates to others. A main objective of the reciprocal license is to prevent licensees of open source from creating proprietary versions of the software, thereby decreasing the risk of “forking” that was historically the result of the privatization of UNIX.
In addition to the GNU General Public License ("GPL") discussed below, other widely used reciprocal licenses include the GNU Lesser General Public License ("LPGL"). The main distinction between the GPL and the LPGL is that the LGPL authors intend it for distribution with software "libraries." A software library is a sequence or set of source code that performs a specific function and can be "linked" to other software to create a more robust program. A software developer might write source code for a program, but will use an already-created library to add a function to the program without creating that particular function from scratch. Code embodying commonly used functions can also be fluidly created and destroyed when needed or not, or shared by multiple processes, thus sharing or conserving memory at run time. The LGPL allows dynamic linking to an open source library without a reciprocity requirement. But if the developer makes any modifications to the library, the developer has created a derivative work of the library, which requires that those changes be available under the LGPL. The LGPL does not require that the developer's proprietary code (linked to the library) be distributed as open source, but it does include other restrictions.
Example: GNU GPL 2.0
- The GPL grants a license to copy, modify, and distribute the code.
- Any distribution of derivatives must also be licensed under the GPL.
- Distributed derivatives must contain a notice in the software indicating that it is distributed, and may be redistributed, under the terms of the GPL
- Any distribution of either the original code or derivatives must be at no charge. The licensor may, however, charge for "transferring a copy" of the software, or for "warranty protection." The language of the GPL is broad enough to allow charging for materials distributed with the software and ongoing support services.
- The source code for any software licensed under the GPL, including distributed derivatives, must be made available to any part to whom the software is distributed.
- No warranties are provided for software licensed under the GPL, and liabilities are disclaimed. This means that there is no guarantee that the software under a GPL will work, or that the licensor can be held liable for anything.
Potential Legal Issues:
- The Free Software Foundation, which stewards the GPL, has taken a public position that a "work based on the Program" is co-terminus with the term of art "derivative work" in copyright law. However, the FSF has also taken positions about what constitutes a derivative work that are quite broad, and may not be supported by the sparse and conflicting case law on this issue. It is unclear whether a court will enforce the more broad definition. Read more about derivative works.
- The GPL is silent on whether other intellectual property that may be included in an open source software program—such as patent rights—is licensed under the GPL.
- The authors of the GPL assert that it is a license under copyright law, and not a contract, and that therefore no manifestation of a licensee's assent is necessary to enforce the provisions of the agreement, as is typically required by contract law. Among other implications of the GPL authors' argument is that the license grants automatically terminate if the licensee does not comply with the GPL's conditions (as opposed to the licensor needing to bring a breach of contract claim against the licensee). There are strong sentiments on either side of this "license vs. contract" debate, and the issue has not yet been litigated. Read more about licenses vs. contracts.
- If you are an end user of GPL-licensed software, and you make some Modifications to it for internal use, and then you provide the modified software to an independent contractor or a subsidiary company, or to a third party as part of a beta testing program, this may qualify as a "distribution" of the software, which would subject you to the requirement that you make available source to your modifications.1 Also, there is some question as to whether subsequent versions of the GPL will include providing access to software as a service (sometimes referred to as “ASP” or “SAS” use) within the definition of distribution. This would not comport with existing copyright law on the definition of distribution.
For further reading on the GPL and other reciprocal licenses, see:
- GNU GPL FAQ: http://www.gnu.org/licenses/gpl-faq.html
- Andrew M. St. Laurent, Understanding Open Source and Free Software Licensing (2004), Ch. 3.
The term "hybrid" is used for purposes of this discussion to describe licenses that contain elements of both academic and reciprocal approaches. Hybrid licenses allow for development of proprietary software products, so long as the specific files containing modifications of open source that was licensed under a hybrid license are, in turn, made available to all as open source.
Example: Mozilla Public License ("MPL")
- The MPL applies only to "Original Code" and "Modifications" (these terms are capitalized here because they are defined terms in the MPL itself). Original Code is code that was made available by original contributor of code made subject to MPL. Modifications are changes to Original Code (or changes to Modifications) made by a "Contributor"—someone other than the Original Code copyright holder. If a Contributor makes a Modification to either the Original Code or other Contributors' previous Modifications, the MPL requires that those changes be made available as open source, licensed under the terms of the MPL. This is not to say, however, that all files in the program must be open source. Rather, only those files that contain either Original Code or Modifications must be open source. Any files within the "Larger Work" that do not contain any Original Files or Modifications may remain proprietary. As a result, software programs developed with some code that is under the MPL may interact with proprietary elements.
- Both the Original Developer of the open source and any contributors grant explicit licenses to use, modify, and redistribute the code.
- Any patent licenses required to use the Original Code and subsequent Modifications are granted or combinations thereof. For more on this issue, see pp. 147-154 of Lawrence Rosen's book.
- A copy of the MPL must be distributed with any Original Code or Modifications.
- The source code of any Modification and documentation of the changes that you make to the source must be made available under the terms of the MPL (i.e., a "reciprocal" grant), and must be identified as being derived from the "Original Code."
- "Contributors" must provide explicit notice of any known third party intellectual property rights that must be exercised when using the contribution.
- Any warranty offered by a Contributor is on behalf of that specific Contributor only. If choosing to offer a warranty, the Contributor must also indemnify the Original Developer and other contributors for any liability arising out of that warranty.
- Agreement is governed by California law jurisdiction in federal courts of Northern District of California.
Potential Legal Issues:
- Licensees under the MPL who engage in any patent infringement claims against the Initial Developer or any subsequent Contributors may have their licenses revoked retroactively.
- If the licensee was, during download of the software subject to the license, not given the opportunity to accept the agreement, it may not be an enforceable contract. However, downloading software does not ordinarily confer any right to distribute, so a Contributor would find pressing this issue difficult.
For further reading on the MPL and other hybrid licenses, see:
For other web sites that compare the main license provisions of academic, reciprocal, and hybrid licenses, see:
- "Various Licenses and Comments about Them," GNU.org: http://www.gnu.org/philosophy/license-list.html
- Free Software Foundation: http://www.fsf.org/licensing/licenses/license-list.html
- Open Source License Comparisons: http://www.croftsoft.com/library/tutorials/opensource/
- "Choosing an Open Source License"--Chapter 10 from Larry Rosen's book available from his web site:
- Arne, Paul H. (2004), Open Source Licenses: Perspectives of the End User and the Software Developer, Morris, Manning, and Martin, LLP. Available at http://www.mmmlaw.com/articles/article_238.pdf.
- Gomulkiewicz, Robert (Spring 2004), Getting Serious About User-Friendly Mass Market Licensing for Software, 12 Geo. Mason L. Rev. 687.
- Scherzer, Dov H. (October 2004), Open Source Licensing, 1452 PLI/Corp 181. (Practising Law Institute, Corporate Law and Practice Course Handbook Series)
- Westermeier, J.T. (September 2004), Open Source Software, 801 PLI/Pat 421. (Practicing Law Institute, Patents, Copyrights, Trademarks, and Literary Property Course Handbook Series)
*Fair use doctrine in brief: The fair use defense to copyright infringement provides that a copyright-protected work may be used in a reasonable manner by someone other than the copyright holder, without that copyright holder's permission. In determining whether a use is reasonable and therefore fair, courts consider a variety of factors, including the purpose and character of the use, the nature of the copyrighted work, and the effect of the use on the potential market for the copyrighted work. Because the uses mentioned as potentially fair in the Copyright Act are largely non-commercial, courts often look to see whether the use was primarily for commercial benefit, or for private commercial gain. Commercial use does not foreclose the fair use defense, however.