% gpl-lgpl.tex -*- LaTeX -*- % Tutorial Text for the Detailed Study and Analysis of GPL and LGPL course % % Copyright (C) 2003, 2004, 2005, 2006 Free Software Foundation, Inc. % Copyright (C) 2014 Bradley M. Kuhn % License: CC-By-SA-4.0 % The copyright holders hereby grant the freedom to copy, modify, convey, % Adapt, and/or redistribute this work under the terms of the Creative % Commons Attribution Share Alike 4.0 International License. % This text is distributed in the hope that it will be useful, but % WITHOUT ANY WARRANTY; without even the implied warranty of % MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. % You should have received a copy of the license with this document in % a file called 'CC-By-SA-4.0.txt'. If not, please visit % https://creativecommons.org/licenses/by-sa/4.0/legalcode to receive % the license text. % FIXME-LATER: I should make a macro like the Texinfo @xref stuff for places % where I'm saying ``see section X in this tutorial'', so that the extra % verbiage isn't there in the HTML versions that I'll eventually do. % Maybe something like that already exists? In the worst case, I could % adapt @xref from texinfo.texi for it. \newcommand{\defn}[1]{\emph{#1}} \part{Detailed Analysis of the GNU GPL and Related Licenses} {\parindent 0in \tutorialpartsplit{``Detailed Analysis of the GNU GPL and Related Licenses''}{This part} is: \\ \begin{tabbing} Copyright \= \copyright{} 2003--2007 \hspace{.1mm} \= \kill Copyright \> \copyright{} 2014 \> Bradley M. Kuhn \\ Copyright \> \copyright{} 2014 \> Anthony K. Sebro, Jr. \\ Copyright \> \copyright{} 2003--2007 \> Free Software Foundation, Inc. \end{tabbing} \vspace{1in} \begin{center} Authors of \tutorialpartsplit{``Detailed Analysis of the GNU GPL and Related Licenses''}{this part} are: \\ Free Software Foundation, Inc. \\ Bradley M. Kuhn \\ David ``Novalis'' Turner \\ Daniel B. Ravicher \\ Tony Sebro \\ John Sullivan \vspace{.3in} The copyright holders of \tutorialpartsplit{``Detailed Analysis of the GNU GPL and Related Licenses''}{this part} hereby grant the freedom to copy, modify, convey, Adapt, and/or redistribute this work under the terms of the Creative Commons Attribution Share Alike 4.0 International License. A copy of that license is available at \verb=https://creativecommons.org/licenses/by-sa/4.0/legalcode=. \end{center} } \bigskip \bigskip \tutorialpartsplit{This tutorial}{This part of the tutorial} gives a comprehensive explanation of the most popular Free Software copyright license, the GNU General Public License (``GNU GPL'', or sometimes just ``GPL'') -- both version 2 (``GPLv2'') and version 3 (``GPLv3'') -- and teaches lawyers, software developers, managers and business people how to use the GPL (and GPL'd software) successfully both as a community-building ``Constitution'' for a software project, and to incorporate copylefted software into a new Free Software business and in existing, successful enterprises. To successfully benefit of from this part of the tutorial, readers should have a general familiarity with software development processes. A basic understanding of how copyright law applies to software is also helpful. The tutorial is of most interest to lawyers, software developers and managers who run or advise software businesses that modify and/or redistribute software under the terms of the GNU GPL (or who wish to do so in the future), and those who wish to make use of existing GPL'd software in their enterprise. Upon completion of this part of the tutorial, successful readers can expect to have learned the following: \begin{itemize} \item The freedom-defending purpose of various terms in the GNU GPLv2 and GPLv3. \item The differences between GPLv2 and GPLv3. \item The redistribution options under the GPLv2 and GPLv3. \item The obligations when modifying GPLv2'd or GPLv3'd software. \item How to build a plan for proper and successful compliance with the GPL. \item The business advantages that the GPL provides. \item The most common business models used in conjunction with the GPL. \item How existing GPL'd software can be used in existing enterprises. \item The basics of LGPLv2.1 and LGPLv3, and how they differs from the GPLv2 and GPLv3, respectively. \item The basics to begin understanding the complexities regarding derivative and combined works of software. \end{itemize} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % END OF ABSTRACTS SECTION %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % START OF DAY ONE COURSE %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{What Is Software Freedom?} Study of the GNU General Public License (herein, abbreviated as \defn{GNU GPL} or just \defn{GPL}) must begin by first considering the broader world of software freedom. The GPL was not created in a vacuum. Rather, it was created to embody and defend a set of principles that were set forth at the founding of the GNU project and the Free Software Foundation (FSF) -- the preeminent organization that upholds, defends and promotes the philosophy of software freedom. A prerequisite for understanding both of the popular versions of the GPL (GPLv2 and GPLv3) and their terms and conditions is a basic understanding of the principles behind them. The GPL family of licenses are unlike nearly all other software licenses in that they are designed to defend and uphold these principles. \section{The Free Software Definition} \label{Free Software Definition} The Free Software Definition is set forth in full on FSF's website at \verb0http://fsf.org/0 \verb0philosophy/free-sw.html0. This section presents an abbreviated version that will focus on the parts that are most pertinent to the GPL\@. A particular program grants software freedom to a particular user if that user is granted the following freedoms: \begin{itemize} \item The freedom to run the program, for any purpose. \item The freedom to study how the program works, and modify it \item The freedom to redistribute copies. \item The freedom to distribute copies of modified versions to others. \end{itemize} The focus on ``a particular user'' is particularly pertinent here. It is not uncommon for the same version of a specific program to grant these freedoms to some subset of its user base, while others have none or only some of these freedoms. Section~\ref{Proprietary Relicensing} talks in detail about how this can unfortunately happen even if a program is released under the GPL\@. Many people refer to software that gives these freedoms as ``Open Source.'' Besides having a different political focus than those who call it Free Software,\footnote{The political differences between the Free Software Movement and the Open Source Movement are documented on FSF's Web site at {\tt http://www.fsf.org/licensing/essays/free-software-for-freedom.html}.} Those who call the software ``Open Source'' are often focused on a side issue. Specifically, user access to the source code of a program is a prerequisite to make use of the freedom to modify. However, the important issue is what freedoms are granted in the license of that source code. Software freedom is only complete when no restrictions are imposed on how these freedoms are exercised. Specifically, users and programmers can exercise these freedoms noncommercially or commercially. Licenses that grant these freedoms for noncommercial activities but prohibit them for commercial activities are considered non-free. Even the Open Source Initiative (\defn{OSI}) (the arbiter of what is considered ``Open Source'') also rules such licenses not in fitting with its ``Open Source Definition''. In general, software for which most or all of these freedoms are restricted in any way is called ``non-Free Software.'' Typically, the term ``proprietary software'' is used more or less interchangeably with ``non-Free Software.'' Personally, I tend to use the term ``non-Free Software'' to refer to noncommercial software that restricts freedom (such as ``shareware'') and ``proprietary software'' to refer to commercial software that restricts freedom (such as nearly all of Microsoft's and Oracle's offerings). Keep in mind that the none of the terms ``software freedom'', ``open source'' and ``free software'' are known to be trademarked or otherwise legally restricted by any organization in any jurisdiction. As such, it's quite common that these terms are abused and misused by parties who wish to bank on the popularity of software freedom. When one considers using, modifying or redistributing a software package that purports to be Open Source or Free Software, one \textbf{must} verify that the license grants software freedom. Furthermore, throughout this text, we generally prefer the term ``software freedom'', as this is the least ambiguous term available to describe software that meets the Free Software Definition. For example, it is well known and often discussed that the adjective ``free'' has two unrelated meanings in English: ``free as in freedom'' and ``free as in price''. Meanwhile, the term ``open source'' is even more confusing, because it appears to refer only to the ``freedom to study'', which is merely a subset of one of the four freedoms. The remainder of this section considers each of each component of software freedom in detail. \subsection{The Freedom to Run} \label{freedom-to-run} The first tenet of software freedom is the user's fully unfettered right to run the program. The software's license must permit any conceivable use of the software. Perhaps, for example, the user has discovered an innovative use for a particular program, one that the programmer never could have predicted. Such a use must not be restricted. It was once rare that this freedom was restricted by even proprietary software; but such is quite common today. Most End User License Agreements (EULAs) that cover most proprietary software typically restrict some types of uses. Such restrictions of any kind are an unacceptable restriction on software freedom. \subsection{The Freedom to Change and Modify} Perhaps the most useful right of software freedom is the users' right to change, modify and adapt the software to suit their needs. Access to the source code and related build and installation scripts are an essential part of this freedom. Without the source code, and the ability to build and install the binary applications from that source, users cannot effectively exercise this freedom. Programmers directly benefit from this freedom. However, this freedom remains important to users who are not programmers. While it may seem counterintuitive at first, non-programmer users often exercise this freedom indirectly in both commercial and noncommercial settings. For example, users often seek noncommercial help with the software on email lists and in user groups. To make use of such help they must either have the freedom to recruit programmers who might altruistically assist them to modify their software, or to at least follow rote instructions to make basic modifications themselves. More commonly, users also exercise this freedom commercially. Each user, or group of users, may hire anyone they wish in a competitive free market to modify and change the software. This means that companies have a right to hire anyone they wish to modify their Free Software. Additionally, such companies may contract with other companies to commission software modification. \subsection{The Freedom to Copy and Share} Users share Free Software in a variety of ways. Software freedom advocates work to eliminate a fundamental ethical dilemma of the software age: choosing between obeying a software license and friendship (by giving away a copy of a program to your friend who likes the software you are using). Licenses that respect software freedom, therefore, permit altruistic sharing of software among friends. The commercial environment also benefits of this freedom. Commercial sharing includes selling copies of Free Software: that is, Free Software can be distribted for any monetary price to anyone. Those who redistribute Free Software commercially also have the freedom to selectively distribute (i.e., you can pick your customers) and to set prices at any level that redistributor sees fit. Of course, most people get copies of Free Software very cheaply (and sometimes without charge). The competitive free market of Free Software tends to keep prices low and reasonable. However, if someone is willing to pay billions of dollars for one copy of the GNU Compiler Collection, such a sale is completely permitted. Another common instance of commercial sharing is service-oriented distribution. For example, some distribution vendors provide immediate security and upgrade distribution via a special network service. Such distribution is not necessarily contradictory with software freedom. (Section~\ref{Business Models} of this tutorial talks in detail about some common Free Software business models that take advantage of the freedom to share commercially.) \subsection{The Freedom to Share Improvements} The freedom to modify and improve is somewhat empty without the freedom to share those improvements. The Software freedom community is built on the pillar of altruistic sharing of improved Free Software. Historically it was typical for a Free Software project to sprout a mailing list where improvements would be shared freely among members of the development community\footnote{This is still commonly the case, though today there are other or additional ways of sharing Free Software.}. Such noncommercial sharing is the primary reason that Free Software thrives. Commercial sharing of modified Free Software is equally important. For commercial support to exist in a competitive free market, all developers -- from single-person contractors to large software companies -- must have the freedom to market their services as improvers of Free Software. All forms of such service marketing must be equally available to all. For example, selling support services for Free Software is fully permitted. Companies and individuals can offer themselves as ``the place to call'' when software fails or does not function properly. For such a service to be meaningful, the entity offering that service needs the right to modify and improve the software for the customer to correct any problems that are beyond mere user error. Software freedom licenses also permit any entity to distribute modified versions of Free Software. Most Free Software programs have a ``standard version'' that is made available from the primary developers of the software. However, all who have the software have the ``freedom to fork'' -- that is, make available nontrivial modified versions of the software on a permanent or semi-permanent basis. Such freedom is central to vibrant developer and user interaction. Companies and individuals have the right to make true value-added versions of Free Software. They may use freedom to share improvements to distribute distinct versions of Free Software with different functionality and features. Furthermore, this freedom can be exercised to serve a disenfranchised subset of the user community. If the developers of the standard version refuse to serve the needs of some of the software's users, other entities have the right to create a long- or short-lived fork to serve that sub-community. \section{How Does Software Become Free?} The previous section set forth key freedoms and rights that are referred to as ``software freedom''. This section discusses the licensing mechanisms used to enable software freedom. These licensing mechanism were ultimately created as a community-oriented ``answer'' to the existing proprietary software licensing mechanisms. Thus, first, consider carefully why proprietary software exists in the first place. Proprietary software exists at all only because it is governed by copyright law.\footnote{This statement is admittedly an oversimplification. Patents and trade secrets can cover software and make it effectively non-Free, and one can contract away their rights and freedoms regarding software, or source code can be practically obscured in binary-only distribution without reliance on any legal system. However, the primary control mechanism for software is copyright, and therefore this section focuses on how copyright restrictions make software proprietary.} Copyright law, with respect to software, typically governs copying, modifying, and redistributing that software (For details of this in the USA, see \href{http://www.copyright.gov/title17/92chap1.html#106}{\S~106} and \href{http://www.copyright.gov/title17/92chap1.html#117}{\S~117} of \href{http://www.law.cornell.edu/uscode/text/17}{Title 17} of the \textit{United States Code}).\footnote{Copyright law in general also governs ``public performance'' of copyrighted works. There is no generally agreed definition for public performance of software and both GPLv2 and GPLv3 do not restrict public performance.} By law (in the USA and in most other jurisdictions), the copyright holder (most typically, the author) of the work controls how others may copy, modify and/or distribute the work. For proprietary software, these controls are used to prohibit these activities. In addition, proprietary software distributors further impede modification in a practical sense by distributing only binary code and keeping the source code of the software secret. Copyright is not a natural state, it is a legal construction. In the USA, the Constitution permits, but does not require, the creation of copyright law as federal legislation. Software, since it is ``an original works of authorship fixed in any tangible medium of expression ... from which they can be perceived, reproduced, or otherwise communicated, either directly or with the aid of a machine or device'' (as stated in \href{http://www.law.cornell.edu/uscode/text/17/102}{17 USC \S~102}), is thus covered by the statute, and is copyrighted by default. However, software, in its natural state without copyright, is Free Software. In an imaginary world with no copyright, the rules would be different. In this world, when you received a copy of a program's source code, there would be no default legal system to restrict you from sharing it with others, making modifications, or redistributing those modified versions.\footnote{Note that this is again an oversimplification; the complexities with this argument are discussed in Section~\ref{software-and-non-copyright}.} Software in the real world is copyrighted by default and is automatically covered by that legal system. However, it is possible to move software out of the domain of the copyright system. A copyright holder can often \defn{disclaim} their copyright. (For example, under USA copyright law it is possible for a copyright holder to engage in conduct resulting in abandonment of copyright.) If copyright is disclaimed, the software is effectively no longer restricted by copyright law. Software not restricted by copyright is in the ``public domain.'' \subsection{Public Domain Software} In the USA and other countries that are parties to the Berne Convention on Copyright, software is copyrighted automatically by the author when she fixes the software in a tangible medium. In the software world, this usually means typing the source code of the software into a file. Imagine if authors could truly disclaim those default control of copyright law. If so, the software is in the public domain --- no longer covered by copyright. Since copyright law is the construction allowing for most restrictions on software (i.e., prohibition of copying, modification, and redistribution), removing the software from the copyright system usually yields software freedom for its users. Carefully note that software truly in the public domain is \emph{not} licensed in any way. It is confusing to say software is ``licensed for the public domain,'' or any phrase that implies the copyright holder gave express permission to take actions governed by copyright law. Copyright holders who state that they are releasing their code into the public domain are effectively renouncing copyright controls on the work. The law gave the copyright holders exclusive controls over the work, and they chose to waive those controls. Software that is, in this sense, in the public domain is conceptualized by the developer as having no copyright and thus no license. The software freedoms discussed in Section~\ref{Free Software Definition} are all granted because there is no legal system in play to take them away. Admittedly, a discussion of public domain software is an oversimplified example. Because copyright controls are usually automatically granted and because, in some jurisdictions, some copyright controls cannot be waived (see Section~\ref{non-usa-copyright} for further discussion), many copyright holders sometimes incorrectly believe a work has been placed in the public domain. Second, due to aggressive lobbying by the entertainment industry, the ``exclusive Right'' of copyright, that was supposed to only exist for ``Limited Times'' according to the USA Constitution, appears to be infinite: simply purchased on the installment plan rather than in whole. Thus, we must assume no works of software will fall into the public domain merely due to the passage of time. Nevertheless, under USA law it is likely that the typical disclaimers of copyright or public domain dedications we see in the Free Software world would be interpreted by courts as copyright abandonment, leading to a situation in which the user effectively receives a maximum grant of copyright freedoms, similar to a maximally-permissive Free Software license. The best example of software known to truly be in the public domain is software that is published by the USA government. Under \href{http://www.law.cornell.edu/uscode/text/17/105}{17 USC 101 \S~105}, all works published by the USA Government are not copyrightable in the USA. \subsection{Why Copyright Free Software?} If simply disclaiming copyright on software yields Free Software, then it stands to reason that putting software into the public domain is the easiest and most straightforward way to produce Free Software. Indeed, some major Free Software projects have chosen this method for making their software Free. However, most of the Free Software in existence \emph{is} copyrighted. In most cases (particularly in those of FSF and the GNU Project), this was done due to very careful planning. Software released into the public domain does grant freedom to those users who receive the standard versions on which the original author disclaimed copyright. However, since the work is not copyrighted, any nontrivial modification made to the work is fully copyrightable. Free Software released into the public domain initially is Free, and perhaps some who modify the software choose to place their work into the public domain as well. However, over time, some entities will choose to proprietarize their modified versions. The public domain body of software feeds the proprietary software. The public commons disappears, because fewer and fewer entities have an incentive to contribute back to the commons. They know that any of their competitors can proprietarize their enhancements. Over time, almost no interesting work is left in the public domain, because nearly all new work is done by proprietarization. A legal mechanism is needed to redress this problem. FSF was in fact originally created primarily as a legal entity to defend software freedom, and that work of defending software freedom is a substantial part of its work today. Specifically because of this ``embrace, proprietarize and extend'' cycle, FSF made a conscious choice to copyright its Free Software, and then license it under ``copyleft'' terms. Many, including the developers of the kernel named Linux, have chosen to follow this paradigm. \label{copyleft-definition} Copyleft is a legal strategy and mechanism to defend, uphold and propagate software freedom. The basic technique of copyleft is as follows: copyright the software, license it under terms that give all the software freedoms, but use the copyright law controls to ensure that all who receive a copy of the software have equal rights and freedom. In essence, copyleft grants freedom, but forbids others to forbid that freedom to anyone else along the distribution and modification chains. Copyleft is a general concept. Much like ideas for what a computer might do must be \emph{implemented} by a program that actually does the job, so too must copyleft be implemented in some concrete legal structure. ``Share and share alike'' is a phrase that is used often enough to explain the concept behind copyleft, but to actually make it work in the real world, a true implementation in legal text must exist. The GPL is the primary implementation of copyleft in copyright licensing language. \subsection{Software and Non-Copyright Legal Regimes} \label{software-and-non-copyright} The use, modification and distribution of software, like many endeavors, simultaneously interacts with multiple different legal regimes. As was noted early via footnotes, copyright is merely the \textit{most common way} to restrict users' rights to copy, share, modify and/or redistribute software. However, proprietary software licenses typically use every mechanism available to subjugate users. For example: \begin{itemize} \item Unfortunately, despite much effort by many in the software freedom community to end patents that read on software (i.e., patents on computational ideas), they still ultimately exist. As such, a software program might otherwise be seemly unrestricted, but a patent might read on the software and ruin everything for its users.\footnote{See \S\S~\ref{gpl-implied-patent-grant},~\ref{GPLv2s7},~\ref{GPLv3s11} for more discussion on how the patent system interacts with copyleft, and read Richard M.~Stallman's essay, \href{http://www.wired.com/opinion/2012/11/richard-stallman-software-patents/}{\textit{Let’s Limit the Effect of Software Patents, Since We Can’t Eliminate Them}} for more information on the problems these patents present to society.} \item Digital Restrictions Management (usually called \defn{DRM}) is often used to impose technological restrictions on users' ability to exercise software freedom that they might otherwise be granted\footnote{See \S~\ref{GPLv3-drm} for more information on how GPL deals with this issue.}. The simplest (and perhaps oldest) form of DRM, of course, is separating software source code (read by humans), from their compiled binaries (read only by computers). Furthermore, \href{http://www.law.cornell.edu/uscode/text/17/1201}{17 USC~\S1201} often prohibits users legally from circumventing some of these DRM systems. \item Most EULAs also include a contractual agreement that bind users further by forcing them to agree to a contractual, prohibitive software license before ever even using the software. \end{itemize} Thus, most proprietary software restricts users via multiple interlocking legal and technological means. Any license that truly respect the software freedom of all users must not only grant appropriate copyright permissions, but also \textit{prevent} restrictions from other legal and technological means like those listed above. \subsection{Non-USA Copyright Regimes} \label{non-usa-copyright} Generally speaking, copyright law operates similarly enough in countries that have signed the Berne Convention on Copyright, and software freedom licenses have generally taken advantage of this international standardization of copyright law. However, copyright law does differ from country to country, and commonly, software freedom licenses like GPL must be considered under the copyright law in the jurisdiction where any licensing dispute occurs. Those who are most familiar with the USA's system of copyright often are surprised to learn that there are certain copyright controls that cannot be waived nor disclaimed. Specifically, many copyright regimes outside the USA recognize a concept of moral rights of authors. Typically, moral rights are fully compatible with respecting software freedom, as they are usually centered around controls that software freedom licenses generally respect, such as the right of an authors to require proper attribution for their work. \section{A Community of Equality} The previous section described the principles of software freedom, a brief introduction to mechanisms that typically block these freedoms, and the simplest ways that copyright holders might grant those freedoms to their users for their copyrighted works of software. The previous section also introduced the idea of \textit{copyleft}: a licensing mechanism to use copyright to not only grant software freedom to users, but also to uphold those rights against those who might seek to curtail them. Copyleft, as defined in \S~\ref{copyleft-definition}, is a general term this mechanism. The remainder of this text will discuss details of various real-world implementations of copyleft -- most notably, the GPL\@. This discussion begins first with some general explanation of what the GPL is able to do in software development communities. After that brief discussion in this section, deeper discussion of how GPL accomplishes this in practice follows in the next chapter. Simply put, though, the GPL ultimately creates an community of equality for both business and noncommercial users. \subsection{The Noncommercial Community} A GPL'd code base becomes a center of a vibrant development and user community. Traditionally, volunteers, operating noncommercially out of keen interest or ``scratch an itch'' motivations, produce initial versions of a GPL'd system. Because of the efficient distribution channels of the Internet, any useful GPL'd system is adopted quickly by noncommercial users. Fundamentally, the early release and quick distribution of the software gives birth to a thriving noncommercial community. Users and developers begin sharing bug reports and bug fixes across a shared intellectual commons. Users can trust the developers, because they know that if the developers fail to address their needs or abandon the project, the GPL ensures that someone else has the right to pick up development. Developers know that the users cannot redistribute their software without passing along the rights granted by GPL, so they are assured that every one of their users is treated equally. Because of the symmetry and fairness inherent in GPL'd distribution, nearly every GPL'd package in existence has a vibrant noncommercial user and developer base. \subsection{The Commercial Community} By the same token, nearly all established GPL'd software systems have a vibrant commercial community. Nearly every GPL'd system that has gained wide adoption from noncommercial users and developers eventually begins to fuel a commercial system around that software. For example, consider the Samba file server system that allows Unix-like systems (including GNU/Linux) to serve files to Microsoft Windows systems. Two graduate students originally developed Samba in their spare time and it was deployed noncommercially in academic environments\footnote{See \href{http://turtle.ee.ncku.edu.tw/docs/samba/history}{Andrew Tridgell's ``A bit of history and a bit of fun''}}. However, very soon for-profit companies discovered that the software could work for them as well, and their system administrators began to use it in place of Microsoft Windows NT file-servers. This served to lower the cost of running such servers by orders of magnitude. There was suddenly room in Windows file-server budgets to hire contractors to improve Samba. Some of the first people hired to do such work were those same two graduate students who originally developed the software. The noncommercial users, however, were not concerned when these two fellows began collecting paychecks off of their GPL'd work. They knew that because of the nature of the GPL that improvements that were distributed in the commercial environment could easily be folded back into the standard version. Companies are not permitted to proprietarize Samba, so the noncommercial users, and even other commercial users are safe in the knowledge that the software freedom ensured by GPL will remain protected. Commercial developers also work in concert with noncommercial developers. Those two now-long-since graduated students continue to contribute to Samba altruistically, but also get paid work doing it. Priorities change when a client is in the mix, but all the code is contributed back to the standard version. Meanwhile, many other individuals have gotten involved noncommercially as developers, because they want to ``cut their teeth on Free Software,'' or because the problems interest them. When they get good at it, perhaps they will move on to another project, or perhaps they will become commercial developers of the software themselves. No party is a threat to another in the GPL software scenario because everyone is on equal ground. The GPL protects rights of the commercial and noncommercial contributors and users equally. The GPL creates trust, because it is a level playing field for all. \subsection{Law Analogy} In his introduction to Stallman's \emph{Free Software, Free Society}, Lawrence Lessig draws an interesting analogy between the law and Free Software. He argues that the laws of a free society must be protected much like the GPL protects software. So that I might do true justice to Lessig's argument, I quote it verbatim: \begin{quotation} A ``free society'' is regulated by law. But there are limits that any free society places on this regulation through law: No society that kept its laws secret could ever be called free. No government that hid its regulations from the regulated could ever stand in our tradition. Law controls. But it does so justly only when visibly. And law is visible only when its terms are knowable and controllable by those it regulates, or by the agents of those it regulates (lawyers, legislatures). This condition on law extends beyond the work of a legislature. Think about the practice of law in American courts. Lawyers are hired by their clients to advance their clients' interests. Sometimes that interest is advanced through litigation. In the course of this litigation, lawyers write briefs. These briefs in turn affect opinions written by judges. These opinions decide who wins a particular case, or whether a certain law can stand consistently with a constitution. All the material in this process is free in the sense that Stallman means. Legal briefs are open and free for others to use. The arguments are transparent (which is different from saying they are good), and the reasoning can be taken without the permission of the original lawyers. The opinions they produce can be quoted in later briefs. They can be copied and integrated into another brief or opinion. The ``source code'' for American law is by design, and by principle, open and free for anyone to take. And take lawyers do---for it is a measure of a great brief that it achieves its creativity through the reuse of what happened before. The source is free; creativity and an economy is built upon it. This economy of free code (and here I mean free legal code) doesn't starve lawyers. Law firms have enough incentive to produce great briefs even though the stuff they build can be taken and copied by anyone else. The lawyer is a craftsman; his or her product is public. Yet the crafting is not charity. Lawyers get paid; the public doesn't demand such work without price. Instead this economy flourishes, with later work added to the earlier. We could imagine a legal practice that was different --- briefs and arguments that were kept secret; rulings that announced a result but not the reasoning. Laws that were kept by the police but published to no one else. Regulation that operated without explaining its rule. We could imagine this society, but we could not imagine calling it ``free.'' Whether or not the incentives in such a society would be better or more efficiently allocated, such a society could not be known as free. The ideals of freedom, of life within a free society, demand more than efficient application. Instead, openness and transparency are the constraints within which a legal system gets built, not options to be added if convenient to the leaders. Life governed by software code should be no less. Code writing is not litigation. It is better, richer, more productive. But the law is an obvious instance of how creativity and incentives do not depend upon perfect control over the products created. Like jazz, or novels, or architecture, the law gets built upon the work that went before. This adding and changing is what creativity always is. And a free society is one that assures that its most important resources remain free in just this sense.\footnote{This quotation is Copyright \copyright{} 2002, Lawrence Lessig. It is licensed under the terms of \href{http://creativecommons.org/licenses/by/1.0/}{the ``Attribution License'' version 1.0} or any later version as published by Creative Commons.} \end{quotation} In essence, lawyers are paid to service the shared commons of legal infrastructure. Few citizens defend themselves in court or write their own briefs (even though they are legally permitted to do so) because everyone would prefer to have an expert do that job. The Free Software economy is a market ripe for experts. It functions similarly to other well established professional fields like the law. The GPL, in turn, serves as the legal scaffolding that permits the creation of this vibrant commercial and noncommercial Free Software economy. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{A Tale of Two Copyleft Licenses} \label{tale-of-two-copylefts} While determining the proper methodology and criteria to yield an accurate count remains difficult, the GPL is generally considered one of the most widely used Free Software licenses. For most of its history --- for 16 years from June 1991 to June 2007 --- there was really only one version of the GPL, version 2. However, the GPL had both earlier versions before version 2, and, more well known, a revision to version 3. \section{Historical Motivations for the General Public License} The earliest license to grant software freedom was likely the Berkeley Software Distribution (``BSD'') license. This license is typical of what are often called lax, highly permissive licenses. Not unlike software in the public domain, these non-copyleft licenses (usually) grant software freedom to users, but they do not go to any effort to uphold that software freedom for users. The so-called ``downstream'' (those who receive the software and then build new things based on that software) can restrict the software and distribute further. The GNU's Not Unix (``GNU'') project, which Richard M.~Stallman (``RMS'') founded in 1984 to make a complete Unix-compatible operating system implementation that assured software freedom for all. However, RMS saw that using a license that gave but did not assure software freedom would be counter to the goals of the GNU project. RMS invented ``copyleft'' as an answer to that problem, and began using various copyleft licenses for the early GNU project programs\footnote{RMS writes more fully about this topic in his essay entitled simply \href{http://www.gnu.org/gnu/thegnuproject.html}{\textit{The GNU Project}}. For those who want to hear the story in his own voice, \href{http://audio-video.gnu.org/audio/}{speech recordings} of his talk, \textit{The Free Software Movement and the GNU/Linux Operating System} are also widely available}. \section{Proto-GPLs And Their Impact} The earliest copyleft licenses were specific to various GNU programs. For example, \href{http://www.free-soft.org/gpl_history/emacs_gpl.html}{The Emacs General Public License} was likely the first copyleft license ever published. Interesting to note that even this earliest copyleft license contains a version of the well-known GPL copyleft clause: \begin{quotation} You may modify your copy or copies of GNU Emacs \ldots provided that you also \ldots cause the whole of any work that you distribute or publish, that in whole or in part contains or is a derivative of GNU Emacs or any part thereof, to be licensed at no charge to all third parties on terms identical to those contained in this License Agreement. \end{quotation} This simply stated clause is the fundamental innovation of copyleft. Specifically, copyleft \textit{uses} the copyright holders' controls on permission to modify the work to add a conditional requirement. Namely, downstream users may only have permission to modify the work if they pass along the same permissions on the modified version that came originally to them. These original program-specific proto-GPLs give an interesting window into the central ideas and development of copyleft. In particular, reviewing them shows how the text of the GPL we know has evolved to address more of the issues discussed earlier in \S~\ref{software-and-non-copyright}. \section{The GNU General Public License, Version 1} \label{GPLv1} In January 1989, the FSF announced that the GPL had been converted into a ``subroutine'' that could be reused not just for all FSF-copyrighted programs, but also by anyone else. As the FSF claimed in its announcement of the GPLv1\footnote{The announcement of GPLv1 was published in the \href{http://www.gnu.org/bulletins/bull6.html\#SEC8}{GNU'S Bulletin, vol 1, number 6 dated January 1989}. (Thanks very much to Andy Tai for his \href{http://www.free-soft.org/gpl_history/}{consolidation of research on the history of the pre-v1 GPL's}.)}: \begin{quotation} To make it easier to copyleft programs, we have been improving on the legalbol architecture of the General Public License to produce a new version that serves as a general-purpose subroutine: it can apply to any program without modification, no matter who is publishing it. \end{quotation} This, like many inventive ideas, seems somewhat obvious in retrospect. But, the FSF had some bright people and access to good lawyers when it started. It took almost five years from the first copyleft licenses to get to a generalized, reusable GPLv1. In the context and mindset of the 1980s, this is not surprising. The idea of reusable licensing infrastructure was not only uncommon, it was virtually nonexistent! Even the early BSD licenses were simply copied and rewritten slightly for each new use\footnote{It remains an interesting accident of history that the early BSD problematic ``advertising clause'' (discussion of which is somewhat beyond the scope of this tutorial) lives on into current day, simply because while the University of California at Berkeley gave unilateral permission to remove the clause from \textit{its} copyrighted works, others who adapted the BSD license with their own names in place of UC-Berkeley's never have.}. The GPLv1's innovation of reuable licensing infrastructure, an obvious fact today, was indeed a novel invention for its day\footnote{We're all just grateful that the FSF also opposes business method patents, since the FSF's patent on a ``method for reusable licensing infrastructure'' would have not expired until 2006!}. \section{The GNU General Public License, Version 2} The GPLv2 was released two and a half years after GPLv1, and over the following sixteen years, it became the standard for copyleft licensing until the release of GPLv3 in 2007 (discussed in more detail in the next section). While this tutorial does not discuss the terms of GPLv1 in detail, it is worth noting below the three key changes that GPLv2 brought: \begin{itemize} \item Software patents and their danger are explicitly mentioned, inspiring (in part) the addition of GPLv2~\S\S5--7. (These sections are discussed in detail in \S~\ref{GPLv2s5}, \S~\ref{GPLv2s6} and \S~\ref{GPLv2s7} of this tutorial.) \item GPLv2~\S2's copyleft terms are expanded to more explicitly discuss the issue of combined works. (GPLv2~\S2 is discussed in detail in \S~\ref{GPLv2s2} in this tutorial). \item GPLv2~\S3 includes more detailed requirements, including the phrase ``the scripts used to control compilation and installation of the executable'', which is a central component of current GPLv2 enforcement . (GPLv2~\S3 is discussed in detail in \S~\ref{GPLv2s3} in this tutorial). \end{itemize} The next chapter discusses GPLv2 in full detail, and readers who wish to dive into the section-by-section discussion of the GPL should jump ahead now to that chapter. However, the most interesting fact to note here is how GPLv2 was published with little fanfare and limited commentary. This contrasts greatly with the creation of GPLv3. \section{The GNU General Public License, Version 3} RMS began drafting GPLv2.2 in mid-2002, and FSF ran a few discussion groups during that era about new text of that license. However, rampant violations of the GPL required more immediate attention of FSF's licensing staff, and as such, much of the early 2000's was spent doing GPL enforcement work\footnote{More on GPL enforcement is discussed in \tutorialpartsplit{a companion tutorial, \textit{A Practical Guide to GPL Compliance}}{Part~\ref{gpl-compliance-guide} of this tutorial}.}. In 2006, FSF began in earnest drafting work for GPLv3. The GPLv3 process began in earnest in January 2006. It became clear that many provisions of the GPL could benefit from modification to fit new circumstances and to reflect what the entire community learned from experience with version 2. Given the scale of revision it seems proper to approach the work through public discussion in a transparent and accessible manner. The GPLv3 process continued through June 2007, culminating in publication of GPLv3 and LGPLv3 on 29 June 2007, AGPLv3 on 19 November 2007, and the GCC Runtime Library Exception on 27 January 2009. All told, four discussion drafts of GPLv3, two discussion drafts of LGPLv3 and two discussion drafts of AGPLv3 were published and discussed. Ultimately, FSF remained the final arbiter and publisher of the licenses, and RMS himself their primary author, but input was sought from many parties, and these licenses do admittedly look and read more like legislation as a result. Nevertheless, all of the ``v3'' group are substantially better and improved licenses. GPLv3 and its terms are discussed in detail in Chapter\~ref{GPLv3}. \section{The Innovation of Optional ``Or Any Later'' Version} An interesting fact of all GPL licenses is that the are ultimate multiple choices for use of the license. The FSF is the primary steward of GPL (as discussed later in \S~\ref{GPLv2s9} and \S~\ref{GPLv2s14}). However, those who wish to license works under GPL are not required to automatically accept changes made by the FSF for their own copyrighted works. Each licensor may chose three different methods of licensing, as follows: \begin{itemize} \item explicitly name a single version of GPL for their work (usually indicated in shorthand by saying the license is ``GPLv$X$-only''), or \item name no version of the GPL, thus they allow their downstream recipients to select any version of the GPL they chose (usually indicated in shorthand by saying the license is simply ``GPL''), or \item name a specific version of GPL and give downstream recipients the option to chose that version ``or any later version as published by the FSF'' (usually indicated by saying the license is ``GPLv$X$-or-later'')\footnote{The shorthand of ``GPL$X+$'' is also popular for this situation. The authors of this tutorial prefer ``-or-later'' syntax, because it (a) mirrors the words ``or'' and ``later from the licensing statement, (b) the $X+$ doesn't make it abundantly clear that $X$ is clearly included as a license option and (c) the $+$ symbol has other uses in computing (such as with regular expressions) that mean something different.} \end{itemize} \label{license-compatibility-first-mentioned} Oddly, this flexibility has received (in the opinion of the authors, undue) criticism, primarily because of the complex and oft-debated notion of ``license compatibility'' (which is explained in detail in \S~\ref{license-compatibility}). Copyleft licenses are generally incompatible with each other, because the details of how they implement copyleft differs. Specifically, copyleft works only because of its requirement that downstream licensors use the \textit{same} license for combined and modified works. As such, software licensed under the terms of ``GPLv2-only'' cannot be combined with works licensed ``GPLv3-or-later''. This is admittedly a frustrating outcome. Other copyleft licenses that appeared after GPL, such as the Creative Commons ``Share Alike'' licenses, the Eclipse Public License and the Mozilla Public License \textbf{require} all copyright holders chosing to use any version of those licenses to automatically accept and relicense their copyrighted works under new versions. Of course ,Creative Commons, the Eclipse Foundation, and the Mozilla Foundation (like the FSF) have generally served as excellent stewards of their licenses. Copyright holders using those licenses seems to find it acceptable that to fully delegate all future licensing decisions for their copyrights to these organizations without a second thought. However, note that FSF gives herein the control of copyright holders to decide whether or not to implicitly trust the FSF in its work of drafting future GPL versions. The FSF, for its part, does encourage copyright holders to chose by default ``GPLv$X$-or-later'' (where $X$ is the most recent version of the GPL published by the FSF). However, the FSF \textbf{does not mandate} that a choice to use any GPL requires a copyright holder ceding its authority for future licensing decisions to the FSF. In fact, the FSF considered this possibility for GPLv3 and chose not to do so, instead opting for the third-party steward designation clause discussed in Section~\ref{GPLv3s14}. \section{Complexities of Two Simultaneously Popular Copylefts} Obviously most GPL advocates would prefer widespread migration to GPLv3, and many newly formed projects who seek a copyleft license tend to choose a GPLv3-based license. However, many existing copylefted projects continue with GPLv2-only or GPLv2-or-later as their default license. While GPLv3 introduces many improvements --- many of which were designed to increase adoption by for-profit companies --- GPLv2 remains a widely used and extremely popular license. The GPLv2 is, no doubt, a good and useful license. However, unlike GPLv1, which (as pointed out in \S~\ref{GPLv1}), which is completely out of use by the mid-1990s. However, unlike GPLv1 before it, GPLv2 remains a integral part of the copyleft licensing infrastructure for some time to come. As such, those who seek to have expertise in current topics of copyleft licensing need to study both the GPLv2 and GPLv3 family of licenses. Furthermore, GPLv3 can is more easily understood by first studying GPLv2. This is not only because of their chronological order, but also because much of the discussion material available for GPLv3 tends to talk about GPLv3 in contrast to GPLv2. As such, a strong understanding of GPLv2 helps in understanding most of the third-party material found regarding GPLv3. Thus, the following chapter begins a deep discussion of GPLv2. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{Running Software and Verbatim Copying} \label{run-and-verbatim} This chapter begins the deep discussion of the details of the terms of GPLv2\@. In this chapter, we consider the first two sections: GPLv2 \S\S 0--2. These are the straightforward sections of the GPL that define the simplest rights that the user receives. \section{GPLv2~\S0: Freedom to Run} \label{GPLv2s0} GPLv2~\S0, the opening section of GPLv2, sets forth that the copyright law governs the work. It specifically points out that it is the ``copyright holder'' who decides if a work is licensed under its terms and explains how the copyright holder might indicate this fact. A bit more subtly, GPLv2~\S0 makes an inference that copyright law is the only system that can restrict the software. Specifically, it states: \begin{quote} Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. \end{quote} In essence, the license governs \emph{only} those activities, and all other activities are unrestricted, provided that no other agreements trump GPLv2 (which they cannot; see Sections~\ref{GPLv2s6} and~\ref{GPLv2s7}). This is very important, because the Free Software community heavily supports users' rights to ``fair use'' and ``unregulated use'' of copyrighted material. GPLv2 asserts through this clause that it supports users' rights to fair and unregulated uses. Fair use (called ``fair dealing'' in some jurisdictions) of copyrighted material is an established legal doctrine that permits certain activities regardless of whether copyright law would other restrict those activities. Discussion of the various types of fair use activity are beyond the scope of this tutorial. However, one important example of fair use is the right to quote portions of the text in larger work so as to criticize or suggest changes. This fair use rights is commonly used on mailing lists when discussing potential improvements or changes to Free Software. Fair use is a doctrine established by the courts or by statute. By contrast, unregulated uses are those that are not covered by the statue nor determined by a court to be covered, but are common and enjoyed by many users. An example of unregulated use is reading a printout of the program's source code like an instruction book for the purpose of learning how to be a better programmer. The right to read something that you have access is and should remain unregulated and unrestricted. \medskip Thus, the GPLv2 protects users fair and unregulated use rights precisely by not attempting to cover them. Furthermore, the GPLv2 ensures the freedom to run specifically by stating the following: \begin{quote} ''The act of running the Program is not restricted.'' \end{quote} Thus, users are explicitly given the freedom to run by GPLv2~\S0. \medskip The bulk of GPLv2~\S0 not yet discussed gives definitions for other terms used throughout. The only one worth discussing in detail is ``work based on the Program''. The reason this definition is particularly interesting is not for the definition itself, which is rather straightforward, but because it clears up a common misconception about the GPL\@. The GPL is often mistakenly criticized because it fails to give a definition of ``derivative work''. In fact, it would be incorrect and problematic if the GPL attempted to define this. A copyright license, in fact, has no control over what may or may not be a derivative work. This matter is left up to copyright law and the courts --- not the licenses that utilize it. It is certainly true that copyright law as a whole does not propose clear and straightforward guidelines for what is and is not a derivative software work under copyright law. However, no copyright license --- not even the GNU GPL --- can be blamed for this. Legislators and court opinions must give us guidance to decide the border cases. \section{GPLv2~\S1: Verbatim Copying} \label{GPLv2s1} GPLv2~\S1 covers the matter of redistributing the source code of a program exactly as it was received. This section is quite straightforward. However, there are a few details worth noting here. The phrase ``in any medium'' is important. This, for example, gives the freedom to publish a book that is the printed copy of the program's source code. It also allows for changes in the medium of distribution. Some vendors may ship Free Software on a CD, but others may place it right on the hard drive of a pre-installed computer. Any such redistribution media is allowed. Preservation of copyright notice and license notifications are mentioned specifically in GPLv2~\S1. These are in some ways the most important part of the redistribution, which is why they are mentioned by name. GPL always strives to make it abundantly clear to anyone who receives the software what its license is. The goal is to make sure users know their rights and freedoms under GPL, and to leave no reason that users might be surprised the software is GPL'd. Thus throughout the GPL, there are specific references to the importance of notifying others down the distribution chain that they have rights under GPL. Also mentioned by name is the warranty disclaimer. Most people today do not believe that software comes with any warranty. Notwithstanding the \href{http://mlis.state.md.us/2000rs/billfile/hb0019.htm}{Maryland's} and \href{http://leg1.state.va.us/cgi-bin/legp504.exe?001+ful+SB372ER}{Virginia's} UCITA bills, there are few or no implied warranties with software. However, just to be on the safe side, GPL clearly disclaims them, and the GPL requires redistributors to keep the disclaimer very visible. (See Sections~\ref{GPLv2s11} and~\ref{GPLv2s12} of this tutorial for more on GPL's warranty disclaimers.) Note finally that GPLv2~\S1 creates groundwork for the important defense of commercial freedom. GPLv2~\S1 clearly states that in the case of verbatim copies, one may make money. Redistributors are fully permitted to charge for the redistribution of copies of Free Software. In addition, they may provide the warranty protection that the GPL disclaims as an additional service for a fee. (See Section~\ref{Business Models} for more discussion on making a profit from Free Software redistribution.) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{Derivative Works: Statute and Case Law} We digress for this chapter from our discussion of GPL's exact text to consider the matter of derivative works --- a concept that we must understand fully before considering GPLv2~\S\S2--3\@. GPL, and Free Software licensing in general, relies critically on the concept of ``derivative work'' since software that is ``independent,'' (i.e., not ``derivative'') of Free Software need not abide by the terms of the applicable Free Software license. As much is required by \S~106 of the Copyright Act, 17 U.S.C. \S~106 (2002), and admitted by Free Software licenses, such as the GPL, which (as we have seen) states in GPLv2~\S0 that ``a `work based on the Program' means either the Program or any derivative work under copyright law.'' It is being a derivative work of Free Software that triggers the necessity to comply with the terms of the Free Software license under which the original work is distributed. Therefore, one is left to ask, just what is a ``derivative work''? The answer to that question differs depending on which court is being asked. The analysis in this chapter sets forth the differing definitions of derivative work by the circuit courts. The broadest and most established definition of derivative work for software is the abstraction, filtration, and comparison test (``the AFC test'') as created and developed by the Second Circuit. Some circuits, including the Ninth Circuit and the First Circuit, have either adopted narrower versions of the AFC test or have expressly rejected the AFC test in favor of a narrower standard. Further, several other circuits have yet to adopt any definition of derivative work for software. As an introductory matter, it is important to note that literal copying of a significant portion of source code is not always sufficient to establish that a second work is a derivative work of an original program. Conversely, a second work can be a derivative work of an original program even though absolutely no copying of the literal source code of the original program has been made. This is the case because copyright protection does not always extend to all portions of a program's code, while, at the same time, it can extend beyond the literal code of a program to its non-literal aspects, such as its architecture, structure, sequence, organization, operational modules, and computer-user interface. \section{The Copyright Act} The copyright act is of little, if any, help in determining the definition of a derivative work of software. However, the applicable provisions do provide some, albeit quite cursory, guidance. Section 101 of the Copyright Act sets forth the following definitions: \begin{quotation} A ``computer program'' is a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result. A ``derivative work'' is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a ``derivative work.'' \end{quotation} These are the only provisions in the Copyright Act relevant to the determination of what constitutes a derivative work of a computer program. Another provision of the Copyright Act that is also relevant to the definition of derivative work is \S~102(b), which reads as follows: \begin{quotation} In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work. \end{quotation} Therefore, before a court can ask whether one program is a derivative work of another program, it must be careful not to extend copyright protection to any ideas, procedures, processes, systems, methods of operation, concepts, principles, or discoveries contained in the original program. It is the implementation of this requirement to ``strip out'' unprotectable elements that serves as the most frequent issue over which courts disagree. \section{Abstraction, Filtration, Comparison Test} As mentioned above, the AFC test for determining whether a computer program is a derivative work of an earlier program was created by the Second Circuit and has since been adopted in the Fifth, Tenth, and Eleventh Circuits. Computer Associates Intl., Inc. v. Altai, Inc., 982 F.2d 693 (2nd Cir. 1992); Engineering Dynamics, Inc. v. Structural Software, Inc., 26 F.3d 1335 (5th Cir. 1994); Kepner-Tregoe, Inc. v. Leadership Software, Inc., 12 F.3d 527 (5th Cir. 1994); Gates Rubber Co. v. Bando Chem. Indust., Ltd., 9 F.3d 823 (10th Cir. 1993); Mitel, Inc. v. Iqtel, Inc., 124 F.3d 1366 (10th Cir. 1997); Bateman v. Mnemonics, Inc., 79 F.3d 1532 (11th Cir. 1996); and, Mitek Holdings, Inc. v. Arce Engineering Co., Inc., 89 F.3d 1548 (11th Cir. 1996). Under the AFC test, a court first abstracts from the original program its constituent structural parts. Then, the court filters from those structural parts all unprotectable portions, including incorporated ideas, expression that is necessarily incidental to those ideas, and elements that are taken from the public domain. Finally, the court compares any and all remaining kernels of creative expression to the structure of the second program to determine whether the software programs at issue are substantially similar so as to warrant a finding that one is the derivative work of the other. Often, the courts that apply the AFC test will perform a quick initial comparison between the entirety of the two programs at issue in order to help determine whether one is a derivative work of the other. Such a holistic comparison, although not a substitute for the full application of the AFC test, sometimes reveals a pattern of copying that is not otherwise obvious from the application of the AFC test when, as discussed below, only certain components of the original program are compared to the second program. If such a pattern is revealed by the quick initial comparison, the court is more likely to conclude that the second work is indeed a derivative of the original. \subsection{Abstraction} The first step courts perform under the AFC test is separation of the work's ideas from its expression. In a process akin to reverse engineering, the courts dissect the original program to isolate each level of abstraction contained within it. Courts have stated that the abstractions step is particularly well suited for computer programs because it breaks down software in a way that mirrors the way it is typically created. However, the courts have also indicated that this step of the AFC test requires substantial guidance from experts, because it is extremely fact and situation specific. By way of example, one set of abstraction levels is, in descending order of generality, as follows: the main purpose, system architecture, abstract data types, algorithms and data structures, source code, and object code. As this set of abstraction levels shows, during the abstraction step of the AFC test, the literal elements of the computer program, namely the source and object code, are defined as particular levels of abstraction. Further, the source and object code elements of a program are not the only elements capable of forming the basis for a finding that a second work is a derivative of the program. In some cases, in order to avoid a lengthy factual inquiry by the court, the owner of the copyright in the original work will submit its own list of what it believes to be the protected elements of the original program. In those situations, the court will forgo performing its own abstraction, and proceed to the second step of the AFC test. \subsection{Filtration} The most difficult and controversial part of the AFC test is the second step, which entails the filtration of protectable expression contained in the original program from any unprotectable elements nestled therein. In determining which elements of a program are unprotectable, courts employ a myriad of rules and procedures to sift from a program all the portions that are not eligible for copyright protection. First, as set forth in \S~102(b) of the Copyright Act, any and all ideas embodied in the program are to be denied copyright protection. However, implementing this rule is not as easy as it first appears. The courts readily recognize the intrinsic difficulty in distinguishing between ideas and expression and that, given the varying nature of computer programs, doing so will be done on an ad hoc basis. The first step of the AFC test, the abstraction, exists precisely to assist in this endeavor by helping the court separate out all the individual elements of the program so that they can be independently analyzed for their expressive nature. A second rule applied by the courts in performing the filtration step of the AFC test is the doctrine of merger, which denies copyright protection to expression necessarily incidental to the idea being expressed. The reasoning behind this doctrine is that when there is only one way to express an idea, the idea and the expression merge, meaning that the expression cannot receive copyright protection due to the bar on copyright protection extending to ideas. In applying this doctrine, a court will ask whether the program's use of particular code or structure is necessary for the efficient implementation of a certain function or process. If so, then that particular code or structure is not protected by copyright and, as a result, it is filtered away from the remaining protectable expression. A third rule applied by the courts in performing the filtration step of the AFC test is the doctrine of scenes a faire, which denies copyright protection to elements of a computer program that are dictated by external factors. Such external factors can include: \begin{itemize} \item The mechanical specifications of the computer on which a particular program is intended to operate \item Compatibility requirements of other programs with which a program is designed to operate in conjunction \item Computer manufacturers' design standards \item Demands of the industry being serviced, and widely accepted programming practices within the computer industry \end{itemize} Any code or structure of a program that was shaped predominantly in response to these factors is filtered out and not protected by copyright. Lastly, elements of a computer program are also to be filtered out if they were taken from the public domain or fail to have sufficient originality to merit copyright protection. Portions of the source or object code of a computer program are rarely filtered out as unprotectable elements. However, some distinct parts of source and object code have been found unprotectable. For example, constant s, the invariable integers comprising part of formulas used to perform calculations in a program, are unprotectable. Further, although common errors found in two programs can provide strong evidence of copying, they are not afforded any copyright protection over and above the protection given to the expression containing them. \subsection{Comparison} The third and final step of the AFC test entails a comparison of the original program's remaining protectable expression to a second program. The issue will be whether any of the protected expression is copied in the second program and, if so, what relative importance the copied portion has with respect to the original program overall. The ultimate inquiry is whether there is ``substantial'' similarity between the protected elements of the original program and the potentially derivative work. The courts admit that this process is primarily qualitative rather than quantitative and is performed on a case-by-case basis. In essence, the comparison is an ad hoc determination of whether the protectable elements of the original program that are contained in the second work are significant or important parts of the original program. If so, then the second work is a derivative work of the first. If, however, the amount of protectable elements copied in the second work are so small as to be de minimis, then the second work is not a derivative work of the original. \section{Analytic Dissection Test} The Ninth Circuit has adopted the analytic dissection test to determine whether one program is a derivative work of another. Apple Computer, Inc. v. Microsoft Corp., 35 F.3d 1435 (9th Cir. 1994). The analytic dissection test first considers whether there are substantial similarities in both the ideas and expressions of the two works at issue. Once the similar features are identified, analytic dissection is used to determine whether any of those similar features are protected by copyright. This step is the same as the filtration step in the AFC test. After identifying the copyrightable similar features of the works, the court then decides whether those features are entitled to ``broad'' or ``thin'' protection. ``Thin'' protection is given to non-copyrightable facts or ideas that are combined in a way that affords copyright protection only from their alignment and presentation, while ``broad'' protection is given to copyrightable expression itself. Depending on the degree of protection afforded, the court then sets the appropriate standard for a subjective comparison of the works to determine whether, as a whole, they are sufficiently similar to support a finding that one is a derivative work of the other. ``Thin'' protection requires the second work be virtually identical in order to be held a derivative work of an original, while ``broad'' protection requires only a ``substantial similarity.'' \section{No Protection for ``Methods of Operation''} The First Circuit has taken the position that the AFC test is inapplicable when the works in question relate to unprotectable elements set forth in \S~102(b). Their approach results in a much narrower definition of derivative work for software in comparison to other circuits. Specifically, the First Circuit holds that ``method of operation,'' as used in \S~102(b) of the Copyright Act, refers to the means by which users operate computers. Lotus Development Corp. v. Borland Int’l., Inc., 49 F.3d 807 (1st Cir. 1995). In Lotus, the court held that a menu command hierarchy for a computer program was uncopyrightable because it did not merely explain and present the program’s functional capabilities to the user, but also served as a method by which the program was operated and controlled. As a result, under the First Circuit’s test, literal copying of a menu command hierarchy, or any other ``method of operation,'' cannot form the basis for a determination that one work is a derivative of another. As a result, courts in the First Circuit that apply the AFC test do so only after applying a broad interpretation of \S~102(b) to filter out unprotected elements. E.g., Real View, LLC v. 20-20 Technologies, Inc., 683 F. Supp.2d 147, 154 (D. Mass. 2010). \section{No Test Yet Adopted} Several circuits, most notably the Fourth and Seventh, have yet to declare their definition of derivative work and whether or not the AFC, Analytic Dissection, or some other test best fits their interpretation of copyright law. Therefore, uncertainty exists with respect to determining the extent to which a software program is a derivative work of another in those circuits. However, one may presume that they would give deference to the AFC test since it is by far the majority rule amongst those circuits that have a standard for defining a software derivative work. \section{Cases Applying Software Derivative Work Analysis} In the preeminent case regarding the definition of a derivative work for software, Computer Associates v. Altai, the plaintiff alleged that its program, Adapter, which was used to handle the differences in operating system calls and services, was infringed by the defendant's competitive program, Oscar. About 30\% of Oscar was literally the same code as that in Adapter. After the suit began, the defendant rewrote those portions of Oscar that contained Adapter code in order to produce a new version of Oscar that was functionally competitive with Adapter, without have any literal copies of its code. Feeling slighted still, the plaintiff alleged that even the second version of Oscar, despite having no literally copied code, also infringed its copyrights. In addressing that question, the Second Circuit promulgated the AFC test. In abstracting the various levels of the program, the court noted a similarity between the two programs' parameter lists and macros. However, following the filtration step of the AFC test, only a handful of the lists and macros were protectable under copyright law because they were either in the public domain or required by functional demands on the program. With respect to the handful of parameter lists and macros that did qualify for copyright protection, after performing the comparison step of the AFC test, it was reasonable for the district court to conclude that they did not warrant a finding of infringement given their relatively minor contribution to the program as a whole. Likewise, the similarity between the organizational charts of the two programs was not substantial enough to support a finding of infringement because they were too simple and obvious to contain any original expression. In the case of Oracle America v. Google, 872 F. Supp.2d 974 (N.D. Cal. 2012), the Northern District of California District Court examined the question of whether the application program interfaces (APIs) associated with the Java programming language are entitled to copyright protection. While the court expressly declined to rule whether all APIs are free to use without license (872 F. Supp.2d 974 at 1002), the court held that the command structure and taxonomy of the APIs were not protectable under copyright law. Specifically, the court characterized the command structure and taxonomy as both a ``method of operation'' (using an approach not dissimilar to the First Circuit's analysis in Lotus) and a ``functional requirement for compatability'' (using Sega v. Accolade, 977 F.2d 1510 (9th Cir. 1992) and Sony Computer Ent. v. Connectix, 203 F.3d 596 (9th Cir. 2000) as analogies), and thus unprotectable subject matter under \S~102(b). Perhaps not surprisingly, there have been few other cases involving a highly detailed software derivative work analysis. Most often, cases involve clearer basis for decision, including frequent bad faith on the part of the defendant or overaggressiveness on the part of the plaintiff. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{Modified Source and Binary Distribution} \label{source-and-binary} In this chapter, we discuss the two core sections that define the rights and obligations for those who modify, improve, and/or redistribute GPL'd software. These sections, GPLv2~\S\S2--3, define the central core rights and requirements of GPLv2\@. \section{GPLv2~\S2: Share and Share Alike} \label{GPLv2s2} For many, this is where the ``magic'' happens that defends software freedom upon redistribution. GPLv2~\S2 is the only place in GPLv2 that governs the modification controls of copyright law. If users modifies a GPLv2'd program, they must follow the terms of GPLv2~\S2 in making those changes. Thus, this sections ensures that the body of GPL'd software, as it continues and develops, remains Free as in freedom. To achieve that goal, GPLv2~\S2 first sets forth that the rights of redistribution of modified versions are the same as those for verbatim copying, as presented in GPLv2~\S1. Therefore, the details of charging money, keeping copyright notices intact, and other GPLv2~\S1 provisions are in tact here as well. However, there are three additional requirements. The first (GPLv2~\S2(a)) requires that modified files carry ``prominent notices'' explaining what changes were made and the date of such changes. This section does not prescribe some specific way of marking changes nor does it control the process of how changes are made. Primarily, GPLv2~\S2(a) seeks to ensure that those receiving modified versions know the history of changes to the software. For some users, it is important to know that they are using the standard version of program, because while there are many advantages to using a fork, there are a few disadvantages. Users should be informed about the historical context of the software version they use, so that they can make proper support choices. Finally, GPLv2~\S2(a) serves an academic purpose --- ensuring that future developers can use a diachronic approach to understand the software. \medskip The second requirement (GPLv2~\S2(b)) contains the four short lines that embody the legal details of ``share and share alike''. These 46 words are considered by some to be the most worthy of careful scrutiny because GPLv2~\S2(b), and they can be a source of great confusion when not properly understood. In considering GPLv2~\S2(b), first note the qualifier: it \textit{only} applies to derivative works that ``you distribute or publish''. Despite years of education efforts on this matter, many still believe that modifiers of GPL'd software \textit{must} to publish or otherwise share their changes. On the contrary, GPLv2~\S2(b) {\bf does not apply if} the changes are never distributed. Indeed, the freedom to make private, personal, unshared changes to software for personal use only should be protected and defended.\footnote{Most Free Software enthusiasts believe there is an {\bf moral} obligation to redistribute changes that are generally useful, and they often encourage companies and individuals to do so. However, there is a clear distinction between what one {\bf ought} to do and what one {\bf must} do.} Next, we again encounter the same matter that appears in GPLv2~\S0, in the following text: \begin{quote} ``...that in whole or part contains or is derived from the Program or any part thereof.'' \end{quote} Again, the GPL relies here on what the copyright law says is a derivative work. If, under copyright law, the modified version ``contains or is derived from'' the GPL'd software, then the requirements of GPLv2~\S2(b) apply. The GPL invokes its control as a copyright license over the modification of the work in combination with its control over distribution of the work. The final clause of GPLv2~\S2(b) describes what the licensee must do if she is distributing or publishing a work that is deemed a derivative work under copyright law --- namely, the following: \begin{quote} [The work must] be licensed as a whole at no charge to all third parties under the terms of this License. \end{quote} That is probably the most tightly-packed phrase in all of the GPL\@. Consider each subpart carefully. The work ``as a whole'' is what is to be licensed. This is an important point that GPLv2~\S2 spends an entire paragraph explaining; thus this phrase is worthy of a lengthy discussion here. As a programmer modifies a software program, she generates new copyrighted material --- fixing expressions of ideas into the tangible medium of electronic file storage. That programmer is indeed the copyright holder of those new changes. However, those changes are part and parcel to the original work distributed to the programmer under GPL\@. Thus, the license of the original work affects the license of the new whole derivative work. % {\cal I} \newcommand{\gplusi}{$\mathcal{G\!\!+\!\!I}$} \newcommand{\worki}{$\mathcal{I}$} \newcommand{\workg}{$\mathcal{G}$} \label{separate-and-independent} It is certainly possible to take an existing independent work (called \worki{}) and combine it with a GPL'd program (called \workg{}). The license of \worki{}, when it is distributed as a separate and independent work, remains the prerogative of the copyright holder of \worki{}. However, when \worki{} is combined with \workg{}, it produces a new work that is the combination of the two (called \gplusi{}). The copyright of this combined work, \gplusi{}, is held by the original copyright holder of each of the two works. In this case, GPLv2~\S2 lays out the terms by which \gplusi{} may be distributed and copied. By default, under copyright law, the copyright holder of \worki{} would not have been permitted to distribute \gplusi{}; copyright law forbids it without the expressed permission of the copyright holder of \workg{}. (Imagine, for a moment, if \workg{} were a proprietary product --- would its copyright holders give you permission to create and distribute \gplusi{} without paying them a hefty sum?) The license of \workg{}, the GPL, states the options for the copyright holder of \worki{} who may want to create and distribute \gplusi{}. GPL's pregranted permission to create and distribute derivative works, provided the terms of GPL are upheld, goes far above and beyond the permissions that one would get with a typical work not covered by a copyleft license. (Thus, to say that this restriction is any way unreasonable is simply ludicrous.) \medskip The next phrase of note in GPLv2~\S2(b) is ``licensed \ldots at no charge.'' This phrase confuses many. The sloppy reader points out this as ``a contradiction in GPL'' because (in their confused view) that clause of GPLv2~\S2 says that redistributors cannot charge for modified versions of GPL'd software, but GPLv2~\S1 says that they can. Avoid this confusion: the ``at no charge'' \textbf{does not} prohibit redistributors from charging when performing the acts governed by copyright law,\footnote{Recall that you could by default charge for any acts not governed by copyright law, because the license controls are confined by copyright.} but rather that they cannot charge a fee for the \emph{license itself}. In other words, redistributors of (modified and unmodified) GPL'd works may charge any amount they choose for performing the modifications on contract or the act of transferring the copy to the customer, but they may not charge a separate licensing fee for the software. GPLv2~\S2(b) further states that the software must ``be licensed \ldots to all third parties.'' This too yields some confusion, and feeds the misconception mentioned earlier --- that all modified versions must made available to the public at large. However, the text here does not say that. Instead, it says that the licensing under terms of the GPL must extend to anyone who might, through the distribution chain, receive a copy of the software. Distribution to all third parties is not mandated here, but GPLv2~\S2(b) does require redistributors to license the derivative works in a way that extends to all third parties who may ultimately receive a copy of the software. In summary, GPLv2\ 2(b) says what terms under which the third parties must receive this no-charge license. Namely, they receive it ``under the terms of this License'', the GPLv2. When an entity \emph{chooses} to redistribute a derivative work of GPL'd software, the license of that whole work must be GPL and only GPL\@. In this manner, GPLv2~\S2(b) dovetails nicely with GPLv2~\S6 (as discussed in Section~\ref{GPLv2s6} of this tutorial). \medskip The final paragraph of GPLv2~\S2 is worth special mention. It is possible and quite common to aggregate various software programs together on one distribution medium. Computer manufacturers do this when they ship a pre-installed hard drive, and GNU/Linux distribution vendors do this to give a one-stop CD or URL for a complete operating system with necessary applications. The GPL very clearly permits such ``mere aggregation'' with programs under any license. Despite what you hear from its critics, the GPL is nothing like a virus, not only because the GPL is good for you and a virus is bad for you, but also because simple contact with a GPL'd code-base does not impact the license of other programs. A programmer must expended actual effort to cause a work to fall under the terms of the GPL. Redistributors are always welcome to simply ship GPL'd software alongside proprietary software or other unrelated Free Software, as long as the terms of GPL are adhered to for those packages that are truly GPL'd. \section{GPLv2~\S3: Producing Binaries} \label{GPLv2s3} Software is a strange beast when compared to other copyrightable works. It is currently impossible to make a film or a book that can be truly obscured. Ultimately, the full text of a novel, even one written by William Faulkner, must presented to the reader as words in some human-readable language so that they can enjoy the work. A film, even one directed by David Lynch, must be perceptible by human eyes and ears to have any value. Software is not so. While the source code --- the human-readable representation of software is of keen interest to programmers -- users and programmers alike cannot make the proper use of software in that human-readable form. Binary code --- the ones and zeros that the computer can understand --- must be predicable and attainable for the software to be fully useful. Without the binaries, be they in object or executable form, the software serves only the didactic purposes of computer science. Under copyright law, binary representations of the software are simply derivative works of the source code. Applying a systematic process (i.e., ``compilation''\footnote{``Compilation'' in this context refers to the automated computing process of converting source code into binaries. It has absolutely nothing to do with the term ``compilation'' in copyright statues.}) to a work of source code yields binary code. The binary code is now a new work of expression fixed in the tangible medium of electronic file storage. Therefore, for GPL'd software to be useful, the GPL, since it governs the rules for creation of derivative works, must grant permission for the generation of binaries. Furthermore, notwithstanding the relative popularity of source-based GNU/Linux distributions like Gentoo, users find it extremely convenient to receive distribution of binary software. Such distribution is the redistribution of derivative works of the software's source code. GPLv2~\S3 addresses the matter of creation and distribution of binary versions. Under GPLv2~\S3, binary versions may be created and distributed under the terms of GPLv2~\S1--2, so all the material previously discussed applies here. However, GPLv2~\S3 must go a bit further. Access to the software's source code is an incontestable prerequisite for the exercise of the fundamental freedoms to modify and improve the software. Making even the most trivial changes to a software program at the binary level is effectively impossible. GPLv2~\S3 must ensure that the binaries are never distributed without the source code, so that these freedoms are passed through the distribution chain. GPLv2~\S3 permits distribution of binaries, and then offers three options for distribution of source code along with binaries. The most common and the least complicated is the option given under GPLv2~\S3(a). GPLv2~\S3(a) offers the option to directly accompany the source code alongside the distribution of the binaries. This is by far the most convenient option for most distributors, because it means that the source-code provision obligations are fully completed at the time of binary distribution (more on that later). Under GPLv2~\S3(a), the source code provided must be the ``corresponding source code.'' Here ``corresponding'' primarily means that the source code provided must be that code used to produce the binaries being distributed. That source code must also be ``complete''. GPLv2~\S3's penultimate paragraph explains in detail what is meant by ``complete''. In essence, it is all the material that a programmer of average skill would need to actually use the source code to produce the binaries she has received. Complete source is required so that, if the licensee chooses, she should be able to exercise her freedoms to modify and redistribute changes. Without the complete source, it would not be possible to make changes that were actually directly derived from the version received. Furthermore, GPLv2~\S3 is defending against a tactic that has in fact been seen in GPL enforcement. Under GPL, if you pay a high price for a copy of GPL'd binaries (which comes with corresponding source, of course), you have the freedom to redistribute that work at any fee you choose, or not at all. Sometimes, companies attempt a GPL-violating cozenage whereby they produce very specialized binaries (perhaps for an obscure architecture). They then give source code that does correspond, but withhold the ``incantations'' and build plans they used to make that source compile into the specialized binaries. Therefore, GPLv2~\S3 requires that the source code include ``meta-material'' like scripts, interface definitions, and other material that is used to ``control compilation and installation'' of the binaries. In this manner, those further down the distribution chain are assured that they have the unabated freedom to build their own derivative works from the sources provided. Software distribution comes in many forms. Embedded manufacturers, for example, have the freedom to put GPL'd software into mobile devices with very tight memory and space constraints. In such cases, putting the source right alongside the binaries on the machine itself might not be an option. While it is recommended that this be the default way that people comply with GPL, the GPL does provide options when such distribution is infeasible. GPLv2~\S3, therefore, allows source code to be provided on any physical ``medium customarily used for software interchange.'' By design, this phrase covers a broad spectrum --- the phrase seeks to pre-adapt to changes in technology. When GPLv22 was first published in June 1991, distribution on magnetic tape was still common, and CD was relatively new. By 2002, CD is the default. By 2007, DVD's were the default. Now, it's common to give software on USB drives and SD card. This language in the license must adapt with changing technology. Meanwhile, the binding created by the word ``customarily'' is key. Many incorrectly believe that distributing binary on CD and source on the Internet is acceptable. In the corporate world in industrialized countries, it is indeed customary to simply download a CDs' worth of data quickly. However, even today in the USA, many computer users are not connected to the Internet, and most people connected to the Internet still have limited download speeds. Downloading CDs full of data is not customary for them in the least. In some cities in Africa, computers are becoming more common, but Internet connectivity is still available only at a few centralized locations. Thus, the ``customs'' here are normalized for a worldwide userbase. Simply providing source on the Internet --- while it is a kind, friendly and useful thing to do --- is not usually sufficient. Note, however, a major exception to this rule, given by the last paragraph of GPLv2~\S3. \emph{If} distribution of the binary files is made only on the Internet (i.e., ``from a designated place''), \emph{then} simply providing the source code right alongside the binaries in the same place is sufficient to comply with GPLv2~\S3. \medskip As is shown above, Under GPLv2~\S3(a), embedded manufacturers can put the binaries on the device and ship the source code along on a CD\@. However, sometimes this turns out to be too costly. Including a CD with every device could prove too costly, and may practically (although not legally) prohibit using GPL'd software. For this situation and others like it, GPLv2\S~3(b) is available. GPLv2~\S3(b) allows a distributor of binaries to instead provide a written offer for source code alongside those binaries. This is useful in two specific ways. First, it may turn out that most users do not request the source, and thus the cost of producing the CDs is saved --- a financial and environmental windfall. In addition, along with a GPLv2~\S3(b) compliant offer for source, a binary distributor might choose to \emph{also} give a URL for source code. Many who would otherwise need a CD with source might turn out to have those coveted high bandwidth connections, and are able to download the source instead --- again yielding environmental and financial windfalls. However, note that regardless of how many users prefer to get the source online, GPLv2~\S3(b) does place lasting long-term obligations on the binary distributor. The binary distributor must be prepared to honor that offer for source for three years and ship it out (just as they would have had to do under GPLv2~\S3(a)) at a moment's notice when they receive such a request. There is real organizational cost here: support engineers must be trained how to route source requests, and source CD images for every release version for the last three years must be kept on hand to burn such CDs quickly. The requests might not even come from actual customers; the offer for source must be valid for ``any third party''. That phrase is another place where some get confused --- thinking again that full public distribution of source is required. The offer for source must be valid for ``any third party'' because of the freedoms of redistribution granted by GPLv2~\S\S1--2. A company may ship a binary image and an offer for source to only one customer. However, under GPL, that customer has the right to redistribute that software to the world if she likes. When she does, that customer has an obligation to make sure that those who receive the software from her can exercise their freedoms under GPL --- including the freedom to modify, rebuild, and redistribute the source code. GPLv2~\S3(c) is created to save her some trouble, because by itself GPLv2~\S3(b) would unfairly favor large companies. GPLv2~\S3(b) allows the separation of the binary software from the key tool that people can use to exercise their freedom. The GPL permits this separation because it is good for redistributors, and those users who turn out not to need the source. However, to ensure equal rights for all software users, anyone along the distribution chain must have the right to get the source and exercise those freedoms that require it. Meanwhile, GPLv2~\S3(b)'s compromise primarily benefits companies who distribute binary software commercially. Without GPLv2~\S3(c), that benefit would be at the detriment of the companies' customers; the burden of source code provision would be unfairly shifted to the companies' customers. A customer, who had received binaries with a GPLv2~\S3(b)-compliant offer, would be required under GPLv2 (sans GPLv2~\S3(c)) to acquire the source, merely to give a copy of the software to a friend who needed it. GPLv2~\S3(c) reshifts this burden to entity who benefits from GPLv2~\S3(b). GPLv2~\S3(c) allows those who undertake \emph{noncommercial} distribution to simply pass along a GPLv2~\S3(b)-compliant source code offer. The customer who wishes to give a copy to her friend can now do so without provisioning the source, as long as she gives that offer to her friend. By contrast, if she wanted to go into business for herself selling CDs of that software, she would have to acquire the source and either comply via GPLv2~\S3(a), or write her own GPLv2~\S3(b)-compliant source offer. This process is precisely the reason why a GPLv2~\S3(b) source offer must be valid for all third parties. At the time the offer is made, there is no way of knowing who might end up noncommercially receiving a copy of the software. Companies who choose to comply via GPLv2~\S3(b) must thus be prepared to honor all incoming source code requests. For this and the many other additional necessary complications under GPLv2~\S\S3(b--c), it is only rarely a better option than complying via GPLv2~\S3(a). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{GPL's Implied Patent Grant} \label{gpl-implied-patent-grant} We digress again briefly from our section-by-section consideration of GPLv2 to consider the interaction between the terms of GPL and patent law. The GPLv2, despite being silent with respect to patents, actually confers on its licensees more rights to a licensor's patents than those licenses that purport to address the issue. This is the case because patent law, under the doctrine of implied license, gives to each distributee of a patented article a license from the distributor to practice any patent claims owned or held by the distributor that cover the distributed article. The implied license also extends to any patent claims owned or held by the distributor that cover ``reasonably contemplated uses'' of the patented article. To quote the Federal Circuit Court of Appeals, the highest court for patent cases other than the Supreme Court: \begin{quotation} Generally, when a seller sells a product without restriction, it in effect promises the purchaser that in exchange for the price paid, it will not interfere with the purchaser's full enjoyment of the product purchased. The buyer has an implied license under any patents of the seller that dominate the product or any uses of the product to which the parties might reasonably contemplate the product will be put. \end{quotation} Hewlett-Packard Co. v. Repeat-O-Type Stencil Mfg. Corp., Inc., 123 F.3d 1445, 1451 (Fed. Cir. 1997). Of course, Free Software is licensed, not sold, and there are indeed restrictions placed on the licensee, but those differences are not likely to prevent the application of the implied license doctrine to Free Software, because software licensed under the GPL grants the licensee the right to make, use, and sell the software, each of which are exclusive rights of a patent holder. Therefore, although the GPLv2 does not expressly grant the licensee the right to do those things under any patents the licensor may have that cover the software or its reasonably contemplated uses, by licensing the software under the GPLv2, the distributor impliedly licenses those patents to the GPLv2 licensee with respect to the GPLv2'd software. An interesting issue regarding this implied patent license of GPLv2'd software is what would be considered ``uses of the [software] to which the parties might reasonably contemplate the product will be put.'' A clever advocate may argue that the implied license granted by GPLv2 is larger in scope than the express license in other Free Software licenses with express patent grants, in that the patent license clause of many of those other Free Software licenses are specifically limited to the patent claims covered by the code as licensed by the patentee. In contrast, a GPLv2 licensee, under the doctrine of implied patent license, is free to practice any patent claims held by the licensor that cover ``reasonably contemplated uses'' of the GPL'd code, which may very well include creation and distribution of derivative works since the GPL's terms, under which the patented code is distributed, expressly permits such activity. Further supporting this result is the Federal Circuit's pronouncement that the recipient of a patented article has, not only an implied license to make, use, and sell the article, but also an implied patent license to repair the article to enable it to function properly, Bottom Line Mgmt., Inc. v. Pan Man, Inc., 228 F.3d 1352 (Fed. Cir. 2000). Additionally, the Federal Circuit extended that rule to include any future recipients of the patented article, not just the direct recipient from the distributor. This theory comports well with the idea of Free Software, whereby software is distributed amongst many entities within the community for the purpose of constant evolution and improvement. In this way, the law of implied patent license used by the GPLv2 ensures that the community mutually benefits from the licensing of patents to any single community member. Note that simply because GPLv2'd software has an implied patent license does not mean that any patents held by a distributor of GPLv2'd code become worthless. To the contrary, the patents are still valid and enforceable against either: \begin{enumerate} \renewcommand{\theenumi}{\alph{enumi}} \renewcommand{\labelenumi}{\textup{(\theenumi)}} \item any software other than that licensed under the GPLv2 by the patent holder, and \item any party that does not comply with the GPLv2 with respect to the licensed software. \end{enumerate} \newcommand{\compB}{$\mathcal{B}$} \newcommand{\compA}{$\mathcal{A}$} For example, if Company \compA{} has a patent on advanced Web browsing, but also licenses a Web browsing software program under the GPLv2, then it cannot assert the patent against any party based on that party's use of Company \compA{}'s GPL'ed Web browsing software program, or on that party's creation and use of derivative works of that GPL'ed program. However, if a party uses that program without complying with the GPLv2, then Company \compA{} can assert both copyright infringement claims against the non-GPLv2-compliant party and infringement of the patent, because the implied patent license only extends to use of the software in accordance with the GPLv2. Further, if Company \compB{} distributes a competitive advanced Web browsing program that is not a derivative work of Company \compA{}'s GPL'ed Web browsing software program, Company \compA{} is free to assert its patent against any user or distributor of that product. It is irrelevant whether Company \compB's program is also distributed under the GPLv2, as Company \compB{} can not grant implied licenses to Company \compA's patent. This result also reassures companies that they need not fear losing their proprietary value in patents to competitors through the GPLv2 implied patent license, as only those competitors who adopt and comply with the GPLv2's terms can benefit from the implied patent license. To continue the example above, Company \compB{} does not receive a free ride on Company \compA's patent, as Company \compB{} has not licensed-in and then redistributed Company A's advanced Web browser under the GPLv2. If Company \compB{} does do that, however, Company \compA{} still has not lost competitive advantage against Company \compB{}, as Company \compB{} must then, when it re-distributes Company \compA's program, grant an implied license to any of its patents that cover the program. Further, if Company \compB{} relicenses an improved version of Company A's program, it must do so under the GPLv2, meaning that any patents it holds that cover the improved version are impliedly licensed to any licensee. As such, the only way Company \compB{} can benefit from Company \compA's implied patent license, is if it, itself, distributes Company \compA's software program and grants an implied patent license to any of its patents that cover that program. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{Defending Freedom on Many Fronts} Chapters~\ref{run-and-verbatim} and~\ref{source-and-binary} presented the core freedom-defending provisions of GPLv2\@, which are in GPLv2~\S\S0--3. GPLv2\S\S~4--7 of the GPLv2 are designed to ensure that GPLv2~\S\S0--3 are not infringed, are enforceable, are kept to the confines of copyright law but also not trumped by other copyright agreements or components of other entirely separate legal systems. In short, while GPLv2~\S\S0--3 are the parts of the license that defend the freedoms of users and programmers, GPLv2~\S\S4--7 are the parts of the license that keep the playing field clear so that \S\S~0--3 can do their jobs. \section{GPLv2~\S4: Termination on Violation} \label{GPLv2s4} GPLv2~\S4 is GPLv2's termination clause. Upon first examination, it seems strange that a license with the goal of defending users' and programmers' freedoms for perpetuity in an irrevocable way would have such a clause. However, upon further examination, the difference between irrevocability and this termination clause becomes clear. The GPL is irrevocable in the sense that once a copyright holder grants rights for someone to copy, modify and redistribute the software under terms of the GPL, they cannot later revoke that grant. Since the GPL has no provision allowing the copyright holder to take such a prerogative, the license is granted as long as the copyright remains in effect.\footnote{In the USA, due to unfortunate legislation, the length of copyright is nearly perpetual, even though the Constitution forbids perpetual copyright.} The copyright holders have the right to relicense the same work under different licenses (see Section~\ref{Proprietary Relicensing} of this tutorial), or to stop distributing the GPLv2'd version (assuming GPLv2~\S3(b) was never used), but they may not revoke the rights under GPLv2 already granted. In fact, when an entity looses their right to copy, modify and distribute GPL'd software, it is because of their \emph{own actions}, not that of the copyright holder. The copyright holder does not decided when GPLv2~\S4 termination occurs (if ever); rather, the actions of the licensee determine that. Under copyright law, the GPL has granted various rights and freedoms to the licensee to perform specific types of copying, modification, and redistribution. By default, all other types of copying, modification, and redistribution are prohibited. GPLv2~\S4 says that if you undertake any of those other types (e.g., redistributing binary-only in violation of GPLv2~\S3), then all rights under the license --- even those otherwise permitted for those who have not violated --- terminate automatically. GPLv2~\S4 makes GPLv2 enforceable. If licensees fail to adhere to the license, then they are stuck without any permission under to engage in activities covered by copyright law. They must completely cease and desist from all copying, modification and distribution of the GPL'd software. At that point, violating licensees must gain the forgiveness of the copyright holders to have their rights restored. Alternatively, the violators could negotiate another agreement, separate from GPL, with the copyright holder. Both are common practice, although \tutorialpartsplit{as discussed in \textit{A Practical Guide to GPL Compliance}, there are }{Chapter~\ref{compliance-understanding-whos-enforcing} explains further } key differences between these two very different uses of GPL. \section{GPLv2~\S5: Acceptance, Copyright Style} \label{GPLv2s5} GPLv2~\S5 brings us to perhaps the most fundamental misconception and common confusion about GPLv2\@. Because of the prevalence of proprietary software, most users, programmers, and lawyers alike tend to be more familiar with EULAs. EULAs are believed by their authors to be contracts, requiring formal agreement between the licensee and the software distributor to be valid. This has led to mechanisms like ``shrink-wrap'' and ``click-wrap'' as mechanisms to perform acceptance ceremonies with EULAs. The GPL does not need contract law to ``transfer rights.'' Usually, no rights are transfered between parties. By contrast, the GPL is primarily a permission slip to undertake activities that would otherwise have been prohibited by copyright law. As such, GPL needs no acceptance ceremony; the licensee is not even required to accept the license. However, without the GPL, the activities of copying, modifying and distributing the software would have otherwise been prohibited. So, the GPL says that you only accepted the license by undertaking activities that you would have otherwise been prohibited without your license under GPL\@. This is a certainly subtle point, and requires a mindset quite different from the contractual approach taken by EULA authors. An interesting side benefit to GPLv2~\S5 is that the bulk of users of Free Software are not required to accept the license. Undertaking fair and unregulated use of the work, for example, does not bind you to the GPL, since you are not engaging in activity that is otherwise controlled by copyright law. Only when you engage in those activities that might have an impact on the freedom of others does license acceptance occur, and the terms begin to bind you to fair and equitable sharing of the software. In other words, the GPL only kicks in when it needs to for the sake of freedom. While GPL is by default a copyright license, it is certainly still possible to consider GPL as a contract as well. For example, some distributors chose to ``wrap'' their software in an acceptance ceremony to GPL, and nothing in GPL prohibits that use. Furthermore, the ruling in \textit{Jacobsen v. Katzer, 535 F.3d 1373, 1380 (Fed.Cir.2008)} indicates that \textbf{both} copyright and contractual remedies may be sought by a copyright holder seeking to enforce a license designed to uphold software freedom. \section{Using GPL Both as a Contract and Copyright License} \section{GPLv2~\S6: GPL, My One and Only} \label{GPLv2s6} A point that was glossed over in Section~\ref{GPLv2s4}'s discussion of GPLv2~\S4 was the irrevocable nature of the GPL\@. The GPLv2 is indeed irrevocable, and it is made so formally by GPLv2~\S6. The first sentence in GPLv2~\S6 ensures that as software propagates down the distribution chain, that each licensor can pass along the license to each new licensee. Under GPLv2~\S6, the act of distributing automatically grants a license from the original licensor to the next recipient. This creates a chain of grants that ensure that everyone in the distribution has rights under the GPLv2\@. In a mathematical sense, this bounds the bottom --- making sure that future licensees get no fewer rights than the licensee before. The second sentence of GPLv2~\S6 does the opposite; it bounds from the top. It prohibits any licensor along the distribution chain from placing additional restrictions on the user. In other words, no additional requirements may trump the rights and freedoms given by GPLv2\@. The final sentence of GPLv2~\S6 makes it abundantly clear that no individual entity in the distribution chain is responsible for the compliance of any other. This is particularly important for noncommercial users who have passed along a source offer under GPLv2~\S3(c), as they cannot be assured that the issuer of the offer will honor their GPLv2~\S3 obligations. In short, GPLv2~\S6 says that your license for the software is your one and only copyright license allowing you to copy, modify and distribute the software. \section{GPLv2~\S7: ``Give Software Liberty or Give It Death!''} \label{GPLv2s7} In essence, GPLv2~\S7 is a verbosely worded way of saying for non-copyright systems what GPLv2~\S6 says for copyright. If there exists any reason that a distributor knows of that would prohibit later licensees from exercising their full rights under GPL, then distribution is prohibited. Originally, this was designed as the title of this section suggests --- as a last ditch effort to make sure that freedom was upheld. However, in modern times, it has come to give much more. Now that the body of GPL'd software is so large, patent holders who would want to be distributors of GPL'd software have a tough choice. They must choose between avoiding distribution of GPL'd software that exercises the teachings of their patents, or grant a royalty-free, irrevocable, non-exclusive license to those patents. Many companies have chosen the latter. Thus, GPLv2~\S7 rarely gives software death by stopping its distribution. Instead, it is inspiring patent holders to share their patents in the same freedom-defending way that they share their copyrighted works. \section{GPLv2~\S8: Excluding Problematic Jurisdictions} \label{GPLv2s8} GPLv2~\S8 is rarely used by copyright holders. Its intention is that if a particular country, say Unfreedonia, grants particular patents or allows copyrighted interfaces (no country to our knowledge even permits those yet), that the GPLv2'd software can continue in free and unabated distribution in the countries where such controls do not exist. As far as is currently known, GPLv2~\S8 has very rarely been formally used by copyright holders. Admittedly, some have used GPLv2~\S8 to explain various odd special topics of distribution (usually related in some way to GPLv2~\S7). However, generally speaking, this section is not proven particularly useful in the more than two decades of GPLv2 history. Meanwhile, despite many calls by the FSF (and others) for those licensors who explicitly use this section to come forward and explain their reasoning, no one ever did. Furthermore, research conducted during the GPLv3 drafting process found exactly one licensor who had invoked this section to add an explicit geographical distribution limitation, and the reasoning for that one invocation was not fitting with FSF's intended spirit of GPLv2~\S8. As such, GPLv2~\S8 was not included at all in GPLv3. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{Odds, Ends, and Absolutely No Warranty} GPLv2~\S\S0--7 constitute the freedom-defending terms of the GPLv2. The remainder of the GPLv2 handles administrivia and issues concerning warranties and liability. \section{GPLv2~\S9: FSF as Stewards of GPL} \label{GPLv2s9} FSF reserves the exclusive right to publish future versions of the GPL\@; GPLv2~\S9 expresses this. While the stewardship of the copyrights on the body of GPL'd software around the world is shared among thousands of individuals and organizations, the license itself needs a single steward. Forking of the code is often regrettable but basically innocuous. Forking of licensing is disastrous. (Chapter~\ref{tale-of-two-copylefts} discusses more about the various versions of GPL.) \section{GPLv2~\S10: Relicensing Permitted} \label{GPLv2s10} GPLv2~\S10 reminds the licensee of what is already implied by the nature of copyright law. Namely, the copyright holder of a particular software program has the prerogative to grant alternative agreements under separate copyright licenses. \section{GPLv2~\S11: No Warranty} \label{GPLv2s11} Most warranty disclaimer language shout at you. The \href{http://www.law.cornell.edu/ucc/2/2-316}{Uniform Commercial Code~\S2-316} requires that disclaimers of warranty be ``conspicuous''. There is apparently general acceptance that \textsc{all caps} is the preferred way to make something conspicuous, and that has over decades worked its way into the voodoo tradition of warranty disclaimer writing. That said, there is admittedly some authority under USA law suggesting that effective warranty disclaimers that conspicuousness can be established by capitalization and is absent when a disclaimer has the same typeface as the terms surrounding it (see \textit{Stevenson v.~TRW, Inc.}, 987 F.2d 288, 296 (5th Cir.~1993)). While GPLv3's drafters doubted that such authority would apply to copyright licenses like the GPL, the FSF has nevertheless left warranty and related disclaimers in \textsc{all caps} throughout all versions of GPL\@\footnote{One of the authors of this tutorial, Bradley M.~Kuhn, has often suggested the aesthetically preferable compromise of a \textsc{specifically designed ``small caps'' font, such as this one, as an alternative to} WRITING IN ALL CAPS IN THE DEFAULT FONT (LIKE THIS), since the latter adds more ugliness than conspicuousness. Kuhn once engaged in reversion war with a lawyer who disagreed, but that lawyer never answered Kuhn's requests for case law that argues THIS IS INHERENTLY MORE CONSPICUOUS \textsc{Than this is}.}. Some have argued the GPL is unenforceable in some jurisdictions because its disclaimer of warranties is impermissibly broad. However, GPLv2~\S11 contains a jurisdictional savings provision, which states that it is to be interpreted only as broadly as allowed by applicable law. Such a provision ensures that both it, and the entire GPL, is enforceable in any jurisdiction, regardless of any particular law regarding the permissibility of certain warranty disclaimers. Finally, one important point to remember when reading GPLv2~\S11 is that GPLv2~\S1 permits the sale of warranty as an additional service, which GPLv2~\S11 affirms. \section{GPLv2~\S12: Limitation of Liability} \label{GPLv2s12} There are many types of warranties, and in some jurisdictions some of them cannot be disclaimed. Therefore, usually agreements will have both a warranty disclaimer and a limitation of liability, as we have in GPLv2~\S12. GPLv2~\S11 thus gets rid of all implied warranties that can legally be disavowed. GPLv2~\S12, in turn, limits the liability of the actor for any warranties that cannot legally be disclaimed in a particular jurisdiction. Again, some have argued the GPL is unenforceable in some jurisdictions because its limitation of liability is impermissibly broad. However, \S 12, just like its sister, GPLv2~\S11, contains a jurisdictional savings provision, which states that it is to be interpreted only as broadly as allowed by applicable law. As stated above, such a provision ensures that both GPLv2~\S12, and the entire GPL, is enforceable in any jurisdiction, regardless of any particular law regarding the permissibility of limiting liability. So end the terms and conditions of the GNU General Public License. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{GPL Version 3} \label{GPLv3} This chapter discussed the text of GPLv3. Much of this material herein includes text that was adapted (with permission) from text that FSF originally published as part of the so-called ``rationale documents'' for the various discussion drafts of GPLv3. The FSF ran a somewhat public process to develop GPLv3, and it was the first attempt of its kind to develop a Free Software license this way. Ultimately, RMS was the primary author of GPLv3, but he listened to feedback from all sorts of individuals and even for-profit companies. Nevertheless, in attempting to understand GPLv3 after the fact, the materials available from the GPLv3 process have a somewhat ``drinking from the firehose'' effect. This chapter seeks to explain GPLv3 to newcomers, who perhaps are familiar with GPLv2 and who did not participate in the GPLv3 process. Those who wish to drink from the firehose and take a diachronic approach to GPLv3 study by reading the step-by-step public drafting process GPLv3 (which occurred from Monday 16 January 2006 through Monday 19 November 2007) should visit \url{http://gplv3.fsf.org/}. \section{Understanding GPLv3 As An Upgraded GPLv2} Ultimately, GPLv2 and GPLv3 co-exist as active licenses in regular use. As discussed in Chapter\~ref{tale-of-two-copylefts}, GPLv1 was never regularly used alongside GPLv2. However, given GPLv2's widespread popularity and existing longevity by the time GPLv3 was published, it is not surprising that some licensors still prefer GPLv2-only or GPLv2-or-later. GPLv3 gained major adoption by many projects, old and new, but many projects have not upgraded due to (in some cases) mere laziness and (in other cases) policy preference for some of GPLv2's terms and/or policy opposition to GPLv3's terms. Given this ``two GPLs world'' is reality, it makes sense to consider GPLv3 in terms of how it differs from GPLv2. Also, most of the best GPL experts in the world must deal regularly with both licenses, and admittedly have decades of experience of GPLv2 while the most experience with GPLv3 that's possible is by default less than a decade. These two factors usually cause even new students of GPL to start with GPLv2 and move on to GPLv3, and this tutorial follows that pattern. Overall, the changes made in GPLv3 admittedly \textit{increased} the complexity of the license. The FSF stated at the start of the GPLv3 process that they would have liked to oblige those who have asked for a simpler and shorter GPL\@. Ultimately, the FSF gave priority to making GPLv3 a better copyleft in the spirit of past GPL's. Obsession for concision should never trump software freedom. The FSF had many different, important goals in seeking to upgrade to GPLv3. However, one important goal that is often lost in the discussion of policy minutia is a rather simple but important issue. Namely, FSF sought to assure that GPLv3 was more easily internationalized than GPLv2. In particular, the FSF sought to ease interpretation of GPL in other countries by replacement of USA-centric\footnote{See Section~\ref{non-usa-copyright} of this tutorial for a brief discussion about non-USA copyright systems.} copyright phrases and wording with neutral terminology rooted in description of behavior rather than specific statue. As can be seen in the section-by-section discussion of GPLv3 that follows, nearly every section had changes related to issues of internationalization. \section{GPLv3~\S0: Giving In On ``Defined Terms''} One of lawyers' most common complaints about GPLv2 is that defined terms in the document appear throughout. Most licenses define terms up-front. However, GPL was always designed both as a document that should be easily understood both by lawyers and by software developers: it is a document designed to give freedom to software developers and users, and therefore it should be comprehensible to that constituency. Interestingly enough, one coauthor of this tutorial who is both a lawyer and a developer pointed out that in law school, she understood defined terms more quickly than other law students precisely because of her programming background. For developers, having \verb0#define0 (in the C programming language) or other types of constants and/or macros that automatically expand in the place where they are used is second nature. As such, adding a defined terms section was not terribly problematic for developers, and thus GPLv3 adds one. Most of these defined terms are somewhat straightforward and bring forward better worded definitions from GPLv2. Herein, this tutorial discusses a few of the new ones. GPLv3~\S0 includes definitions of five new terms not found in any form in GPLv2: ``modify'' ``covered work'', ``propagate'', ``convey'', and ``Appropriate Legal Notices''. \subsection{Modify and the Work Based on the Program} GPLv2 included a defined term, ``work based on the Program'', but also used the term ``modify'' and ``based on'' throughout the license. GPLv2's ``work based on the Program'' definition made use of a legal term of art, ``derivative work'', which is peculiar to USA copyright law. However, ironically, the most criticism of USA-specific legal terminology in GPLv2's ``work based on the Program'' definition historically came not primarily from readers outside the USA, but from those within it\footnote{The FSF noted in that it did not generally agree with these views, and expressed puzzlement by the energy with which they were expressed, given the existence of many other, more difficult legal issues implicated by the GPL. Nevertheless, the FSF argued that it made sense to eliminate usage of local copyright terminology to good effect.}. Admittedly, even though differently-labeled concepts corresponding to the derivative work are recognized in all copyright law systems, these counterpart concepts might differ to some degree in scope and breadth from the USA derivative work. The goal and intention of GPLv2 was always to cover all rights governed by relevant copyright law, in the USA and elsewhere. GPLv3 therefore takes the task of internationalizing the license further by removing references to derivative works and by providing a more globally useful definition. The new definition returns to the common elements of copyright law. Copyright holders of works of software have the exclusive right to form new works by modification of the original --- a right that may be expressed in various ways in different legal systems. GPLv3 operates to grant this right to successive generations of users (particularly through the copyleft conditions set forth in GPLv3~\S5, as described later in this tutorial in its \S~\ref{GPLv3s5}). Here in GPLv3~\S0, ``modify'' refers to basic copyright rights, and then this definition of ``modify'' is used to define ``modified version of'' and ``work based on,'' as synonyms. \section{The Covered Work} GPLv3 uses a common license drafting technique of building upon simpler definitions to make complex ones. The Program is a defined term found throughout GPLv2, and the word ``covered'' and the phrase ``covered by this license'' are used in tandem with the Program in GPLv2, but not as part of a definition. GPLv3 offers a single term ``covered work'', which enables some of the wording in GPLv3 to be simpler and clearer than its GPLv2 counterparts. \section{Propagate} The term ``propagate'' serves two purposes. First, ``propagate'' provides a simple and convenient means for distinguishing between the kinds of uses of a work that GPL imposes conditions on and the kinds of uses that GPL does not (for the most part) impose conditions on. Second, ``propagate'' helps globalize GPL in its wording and effect. When a work is GPL'd, the copyright law of some particular country will govern certain legal issues arising under the license. A term like ``distribute'' (or its equivalent in languages other than English) is used in several national copyright statutes. Yet, practical experience with GPLv2 revealed the awkwardness of using the term ``distribution'' in a license intended for global use: the scope of ``distribution'' in the copyright context can differ from country to country. The GPL never necessarily intended the specific meaning of ``distribution'' that exists under USA (or any other country's) copyright law. Indeed, even within a single country and language, the term distribution may be ambiguous; as a legal term of art, distribution varies significantly in meaning among those countries that recognize it. For example, comments during GPLv3's drafting process indicated that in at least one country, distribution may not include network transfers of software but may include interdepartmental transfers of physical copies within an organization. Meanwhile, the copyright laws of many countries, as well as certain international copyright treaties, recognize ``making available to the public'' or ``communication to the public'' as one of the exclusive rights of copyright holders. Therefore, the GPL defines the term ``propagate'' by reference to activities that require permission under ``applicable copyright law'', but excludes execution and private modification from the definition. GPLv3's definition also gives examples of activities that may be included within ``propagation'' but it also makes clear that, under the copyright laws of a given country, ``propagation'' may include other activities as well. Thus, propagation is defined by behavior, and not by categories drawn from some particular national copyright statute. This helps not only with internationalization, but also factually-based terminology aids in developers' and users' understanding of GPL\@. \section{Convey} Further to this point, a subset of propagate --- ``convey'' --- is defined. Conveying includes activities that constitute propagation of copies to others. As with the definition of propagate, GPLv3 thus addresses transfers of copies of software in behavioral rather than statutory terms. \section{Appropriate Legal Notices} GPLv2 used the term ``appropriate copyright notice and disclaimer of warranty'' in two places, which is a rather bulk term. Also, experience with GPLv2 and other licenses that grant software freedom showed throughout the 1990s that the scope of types of notices that need preservation upon conveyance were more broad that merely the copyright notices. The Appropriate Legal Notice definition consolidates the material that GPLv2 traditionally required preserved into one definition. \section{Other Defined Terms} Note finally that not all defined terms in GPLv3 appear in GPLv3~\S0. Specifically, those defined terms that are confined in use to a single section are defined in the section in which they are used, and GPLv3~\S1 contains those definitions focused on source code. In this tutorial, those defined terms are discussed in the section where they are defined and/or used. \section{GPLv3~\S1: Understanding CCS} Ensuring that users have the source code to the software they receive and the freedom to modify remains the paramount right embodied in the Free Software Definition (found in \S~\ref{Free Software Definition} of this tutorial). As such, GPLv3~\S1 is likely one of the most important sections of GPLv3, as it contains all the defined terms related to this important software freedom. \subsection{Source Code Definition} First, GPLv3\~S1 retains GPLv2's definition of ``source code'' and adds an explicit definition of ``object code'' as ``any non-source version of a work''. Object code is not restricted to a narrow technical meaning and is understood broadly to include any form of the work other than the preferred form for making modifications to it. Object code therefore includes any kind of transformed version of source code, such as bytecode or minified Javascript. The definition of object code also ensures that licensees cannot escape their obligations under the GPL by resorting to shrouded source or obfuscated programming. \subsection{CCS Definition} The definition of CCS\footnote{Note that the preferred term for those who work regularly with both GPLv2 and GPLv3 is ``Complete Corresponding Source'', abbreviated to ``CCS''. Admittedly, the word ``complete'' no longer appears in GPLv3 (which uses the word ``all'' instead). However, both GPLv2 and the early drafts of GPLv3 itself used the word ``complete'', and early GPLv3 drafts even called this defined term ``Complete Corresponding Source''. Meanwhile, use of the acronym ``CCS'' (sometimes, ``C\&CS'') was so widespread among GPL enforcers that its use continues even though GPLv3-focused experts tend to say just the defined term of ``Corresponding Source''.}, or, as GPLv3 officially calls it, ``Corresponding Source'' in GPLv3~\S1\P4 is possibly the most complex definition in the license. The CCS definition is broad so as to protect users' exercise of their rights under the GPL\@. The definition includes with particular examples to remove any doubt that they are to be considered CCS\@. GPLv3 seeks to make it completely clear that a licensee cannot avoid complying with the requirements of the GPL by dynamically linking a subprogram component to the original version of a program. The example also clarifies that the shared libraries and dynamically linked subprograms that are included in Corresponding Source are those that the work is ``specifically'' designed to require, which clarifies that they do not include libraries invoked by the work that can be readily substituted by other existing implementations. While copyleft advocates never doubted this was required under GPLv2's definition of CCS, making it abundantly clear with an extra example. GPL, as always, seeks to ensure users are truly in a position to install and run their modified versions of the program; the CCS definition is designed to be expansive to ensure this software freedom. However, although the definition of CCS is expansive, it is not sufficient to protect users' freedoms in many circumstances. For example, a GPL'd program, or a modified version of such a program, might be locked-down and restricted. The requirements in GPLv3~\S6 (discussed in Section~\ref{GPLv3s6} of this tutorial) handle that issue. (Early drafts of GPLv3 included those requirements in the definition of CCS; however, given that the lock-down issue only comes up in distribution of object code, it is more logical to place those requirements with the parts of GPLv3 dealing directly with object code distribution). The penultimate paragraph in GPLv3\S2 notes that GPLv3's CCS definition does not require source that can be automatically generated. Many code generators, preprocessors and take source code as input and sometimes even have output that is still source code. Source code should always be whatever the original programmer preferred to modify. GPLv3\S1's final paragraph removes any ambiguity about what should be done on source-only distributions. Specifically, the right to convey source code that does not compile, does not work, or otherwise is experimental in-progress work is fully permitted, \textit{provided that} no object code form is conveyed as well. Indeed, when combined with the permissions in GPLv3\S~5, it is clear that if one conveys \textit{only} source code, one can never be required to provide more than that. One always has the right to modify a source code work by deleting any part of it, and there can be no requirement that free software source code be a whole functioning program. \subsection{The System Library Exception} The previous section skipped over one part of the CCS definition, the so-called system library exception. The ``System Libraries'' definition (and the ``Standard Interface'' and ``Major Component'' definitions, which it includes) are designed as part to permit certain distribution arrangements that are considered reasonable by copyleft advocates. The system library exception is designed to allow copylefted software to link with these libraries when such linking would hurt software freedom more than it would hurt proprietary software. The system library exception has two parts. Part (a) rewords the GPLv2 exception for clarity replaces GPLv2's words ``unless that component itself accompanies the executable'' with ``which is not part of the Major Component''. The goal here is to not require disclosure of source code of certain libraries, such as necessary Microsoft Windows DLLs (which aren't part of Windows' kernel but accompany it) that are required for functioning of copylefted programs compiled for Windows. However, in isolation, (a) would be too permissive, as it would sometimes allowing distributors to evade important GPL requirements. Part (b) reigns in (a). Specifically, (b) specifies only a few functionalities that a the system library may provide and still qualify for the exception. The goal is to ensure system libraries are truly adjunct to a major essential operating system component, compiler, or interpreter. The more low-level the functionality provided by the library, the more likely it is to be qualified for this exception. Admittedly, the system library exception is a frequently discussed topic of obsessed GPL theorists. The amount that has been written on the system library exception (both the GPLv2 and GPLv3 versions of it), if included herein, could easily increase this section of the tutorial to a length greater than all the others. Like any exception to the copyleft requirements of GPL, would-be GPL violators frequently look to the system library exception as a potential software freedom circumvention technique. When considering whether or not a library qualifies for the system library exception, here is a pragmatic thesis to consider, based on the combined decades of experience in GPL interpretation of this tutorial's authors: the harder and more strained the reader must study and read the system library exception, the more likely it is that the library in question does not qualify for it. \section{GPLv3~\S2: Basic Permissions} GPLv3~\S2 can roughly be considered as an equivalent to GPLv2~\S0 (discussed in \S~\ref{GPLv2s0} of this tutorial). However, the usual style of improvements found in GPLv3 are found here as well. For example, the first sentence of GPLv3~\S2 furthers the goal internationalization. Under the copyright laws of some countries, it may be necessary for a copyright license to include an explicit provision setting forth the duration of the rights being granted. In other countries, including the USA, such a provision is unnecessary but permissible. GPLv3~\S2\P1 also acknowledges that licensees under the GPL enjoy rights of copyright fair use, or the equivalent under applicable law. These rights are compatible with, and not in conflict with, the freedoms that the GPL seeks to protect, and the GPL cannot and should not restrict them. However, note that (sadly to some copyleft advocates) the unlimited freedom to run is confined to the \textit{unmodified} Program. This confinement is unfortunately necessary since Programs that do not qualify as a User Product in GPLv3~\S6 (see \S~\ref{user-product} in this tutorial) might have certain unfortunate restrictions on the freedom to run\footnote{See \S~ref{freedom-to-run} of this tutorial for the details on ``the freedom to run''.} GPLv3~\S2\P2 distinguishes between activities of a licensee that are permitted without limitation and activities that trigger additional requirements. Specifically, GPLv3~\S2\P2 guarantees the basic freedoms of privately modifying and running the program. Also, GPLv3~\S2\P2 gives an explicit permission for a client to provide a copy of its modified software to a contractor exclusively for that contractor to modify it further, or run it, on behalf of the client. However, the client can \textit{only} exercise this control over its own copyrighted changes to the GPL-covered program. The parts of the program it obtained from other contributors must be provided to the contractor with the usual GPL freedoms. Thus, GPLv3 permits users to convey covered works to contractors operating exclusively on the users' behalf, under the users' direction and control, and to require the contractors to keep the users' copyrighted changes confidential, but \textit{only if} the contractor is limited to acting on the users' behalf (just as the users' employees would have to act). The strict conditions in this ``contractors provision'' are needed so that it cannot be twisted to fit other activities, such as making a program available to downstream users or customers. By making the limits on this provision very narrow, GPLv3 ensures that, in all other cases, contractors gets the full freedoms of the GPL that they deserve. GPLv3~\S2's final paragraph includes an explicit prohibition of sublicensing. This provision ensures that GPL enforcement is always by the copyright holder. Usually, sublicensing is regarded as a practical convenience or necessity for the licensee, to avoid having to negotiate a license with each licensor in a chain of distribution. The GPL solves this problem in another way --- through its automatic licensing provision found in GPLv3\~S10 (which is discussed in more detail in \S\~ref{GPLv3s10} of this tutorial). \section{GPLv3's views on DRM and Device Lock-Down} \label{GPLv3-drm} The issues of DRM, device lock-down and encryption key disclosure were the most hotly debated during the GPLv3 process. FSF's views on this were sadly frequently misunderstood and, comparing the provisions related to these issues in the earliest drafts of GPLv3 to the final version of GPLv3 shows the FSF's willingness to compromise on tactical issues to reach the larger goal of software freedom. Specifically, GPLv3 introduced provisions that respond to the growing practice of distributing GPL-covered programs in devices that employ technical means to restrict users from installing and running modified versions. This practice thwarts the expectations of developers and users alike, because the right to modify is one of the core freedoms the GPL is designed to secure. Technological measures to defeat users' rights. These measures are often described by such Orwellian phrases, such as ``digital rights management,'' which actually means limitation or outright destruction of users' legal rights, or ``trusted computing,'' which actually means selling people computers they cannot trust. However, these measures are alike in one basic respect. They all employ technical means to turn the system of copyright law (where the powers of the copyright holder are limited exceptions to general freedom) into a virtual prison, where everything not specifically permitted is utterly forbidden. This system of ``para-copyright'' was created well after GPLv2 was written --- initially through legislation in the USA and the EU, and later in other jurisdictions as well. This legislation creates serious civil or even criminal penalties to escape from these restrictions (commonly and aptly called ``jail-breaking a device''), even where the purpose in doing so is to restore the users' legal rights that the technology wrongfully prevents them from exercising. GPLv2 did not address the use of technical measures to take back the rights that the GPL granted, because such measures did not exist in 1991, and would have been irrelevant to the forms in which software was then delivered to users. GPLv3 addresses these issues, particularly because copylefted software is ever more widely embedded in devices that impose technical limitations on the user's freedom to change it. However, FSF always made a clear distinction to avoid conflating these ``lock-down'' measures with legitimate applications that give users control, as by enabling them to choose higher levels of system or data security within their networks, or by allowing them to protect the security of their communications using keys they can generate or copy to other devices for sending or receiving messages. Such technologies present no obstacles to software freedom and the goals of copyleft. The public GPLv3 drafting process sought to balance these positions of copyleft advocates with various desperate views of the larger Free-Software-using community. Ultimately, FSF compromised to the GPLv3\S3 and GPLv3\S6 provisions that, taken together, are a minimalist set of terms sufficient to protect the software freedom against the threat of invasive para-copyright. The compromises made were ultimately quite reasonable. The primary one is embodied in GPLv3\S6's ``User Product'' definition (see \S~\ref{user-product} in this tutorial for details). Additionally, some readers of early GPLv3 drafts seem to have assumed GPLv3 contained a blanket prohibition on DRM; but it does not. In fact, no part of GPLv3 forbids DRM regarding non-GPL'd works; rather, GPLv3 forbids the use of DRM specifically to lock-down restrictions on users' ability to install modified versions of the GPL'd software itself, but again, \textit{only} with regard to User Products. Large enterprise users of free software often contract with non-employee developers, often working offsite, to make modifications intended for the user's private or internal use, and often arrange with other companies to operate their data centers. Whether GPLv2 permits these activities is not clear and may depend on variations in copyright law. The practices seem basically harmless, so we have decided to make it clear they are permitted. \section{GPLv3~\S3: What Hath DMCA Wrought} \label{GPLv3s3} As discussed in \S~\ref{software-and-non-copyright} of this tutorial, \href{http://www.law.cornell.edu/uscode/text/17/1201}{17 USC~\S1201} and relate sections\footnote{These sections of the USC are often referred to as the ``Digital Millennium Copyright Act'', or ``DMCA'', as that was the name of the bill that so-modified these sections of the USC\@.} prohibits users from circumventing technological measures that implement DRM\@. Since this is part of copyright law and the GPL is primarily a copyright license, and since what the DMCA calls ``circumvention'' is simply ``modifying the software'' under the GPL, GPLv3 must disclaim such anti-circumvention provisions are not applicable to the GPLv3'd software. GPLv3\S3 shields users from being subjected to liability under anti-circumvention law for exercising their rights under the GPL, so far as the GPL can do so. First, GPLv3\S3\P1 declares that no GPL'd program is part of an effective technological protection measure, regardless of what the program does. Early drafts of GPLv3\S3\P1 referred directly to the DMCA, but the final version instead includes instead an international legal reference to anticircumvention laws enacted pursuant to the 1996 WIPO treaty and any similar laws. Lawyers outside the USA worried that a USA statutory reference could be read as indicating a choice for application of USA law to the license as a whole. While the FSF did not necessarily agree with that view, the FSF decided anyway to refer to the WIPO treaty rather than DMCA, since several national anticircumvention laws were (or will likely be) structured more similarly to the anticircumvention provisions of the DMCA in their implementation of WIPO\@. Furthermore, the addition of ``or similar laws'' provides an appropriate catch-all. Furthermore, GPLv3\S3\P2 states precisely that a conveying party waives the power to forbid circumvention of technological measures only to the extent that such circumvention is accomplished through the exercise of GPL rights in the conveyed work. GPLv3\S3\P2 makes clear that the referenced ``legal rights'' are specifically rights arising under anticircumvention law. and refers to both the conveying party's rights and to third party rights, as in some cases the conveying party will also be the party legally empowered to enforce or invoke rights arising under anticircumvention law. These disclaimers by each licensor of any intention to use GPL'd software to stringently control access to other copyrighted works should effectively prevent any private or public parties from invoking DMCA-like laws against users who escape technical restriction measures implemented by GPL'd software. \section{GPLv3~\S4: Verbatim Copying} \label{GPLv3s4} GPLv3~\S4 is a revision of GPLv2\~S1 (as discussed in \S~\ref{GPLv2s1} of this tutorial). There are almost no changes to this section from the GPLv2\~S1, other than to use the new defined terms. The only notable change of ``a fee'' to ``any price or no price'' in the first sentence of GPLv3\S4\P2. The GPLv2\S1\P1 means that the GPL permits one to charge money for the distribution of software. Despite efforts by copyleft advocates to explain this in GPLv2 itself and in other documents, there are evidently some people who still believe that GPLv2 allows charging for services but not for selling copies of software and/or that the GPL requires downloads to be gratis. Perhaps this is because GPLv2 referred to charging a ``fee''; the term ``fee'' is generally used in connection with services. GPLv2's wording also referred to ``the physical act of transferring.'' The intention was to distinguish charging for transfers from attempts to impose licensing fees on all third parties. ``Physical'' might be read, however, as suggesting ``distribution in a physical medium only''. To address these two issues, GPLv3 says ``price'' in place of ``fee,'' and removes the term ``physical.'' GPLv3~\S4 has also been revised from its corresponding section in GPLv2 in light of the GPLv3~\S7 (see \S~\ref{GPLv3s7} in this tutorial for more). Specifically, a distributor of verbatim copies of the program's source code must obey any existing additional terms that apply to parts of the program pursuant to GPLv3~\S7. In addition, the distributor is required to keep intact all license notices, including notices of such additional terms. Finally, there is no harm in explicitly pointing out what ought to be obvious: that those who convey GPL-covered software may offer commercial services for the support of that software. \section{GPLv3~\S5: Modified Source} \label{GPLv3s5} % FIXME: 5(a) is slightly different in final version Section 5 contains a number of changes relative to the corresponding section in GPLv2. Subsection 5a slightly relaxes the requirements regarding notice of changes to the program. In particular, the modified files themselves need no longer be marked. This reduces administrative burdens for developers of modified versions of GPL'd software. Under subsection 5a, as in the corresponding provision of GPLv2, the notices must state ``the date of any change,'' which we interpret to mean the date of one or more of the licensee's changes. The best practice would be to include the date of the latest change. However, in order to avoid requiring revision of programs distributed under ``GPL version 2 or later,'' we have retained the existing wording. % FIXME: It's now (b) and (c). Also, ``validity'' of proprietary % relicensing? Give me a break. I'll fix that. Subsection 5b is the central copyleft provision of the license. It now states that the GPL applies to the whole of the work. The license must be unmodified, except as permitted by section 7, which allows GPL'd code to be combined with parts covered by certain other kinds of free software licensing terms. Another change in subsection 5b is the removal of the words ``at no charge,'' which was often misinterpreted by commentators. The last sentence of subsection 5b explicitly recognizes the validity of disjunctive dual-licensing. % FIXME: 5d. Related to Appropriatey Legal notices % follows 5d now, call it the ``final paragraph'' The paragraph following subsection 5c has been revised for clarity, but the underlying meaning is unchanged. When independent non-derivative sections are distributed for use in a combination that is a covered work, the whole of the combination must be licensed under the GPL, regardless of the form in which such combination occurs, including combination by dynamic linking. The final sentence of the paragraph adapts this requirement to the new compatibility provisions of section 7. We have added these words to the aggregation clause to eliminate any question that GPLv3 alters the scope of the copyleft as understood and applied under GPLv2. In GPLv3, as in GPLv2, addition of modules or other parts to a program results in a new program based on the old program, with different functional characteristics created by the merger of two expressions: the original program and the added parts. Such added parts are ``by their nature extensions of'' the old program, and therefore the entire new program which they and the old program form must be licensed under the GPL. As subsection 5c states, packaging of a work has no bearing on the scope of copyleft. \section{GPLv3~\S6: Non-Source and Corresponding Source} \label{GPLv3s6} Section 6 of GPLv3, which clarifies and revises GPLv2 section 3, requires distributors of GPL'd object code to provide access to the corresponding source code, in one of four specified ways. As noted above, ``object code'' in GPLv3 is defined broadly to mean any non-source version of a work. % FIXME: probably mostly still right, needs some updates, though. Subsections 6a and 6b now apply specifically to distribution of object code in a physical product. Physical products include embedded systems, as well as physical software distribution media such as CDs. As in GPLv2, the distribution of object code may either be accompanied by the machine-readable source code, or it may be accompanied by a written offer to provide the machine-readable source code to any third party. GPLv3 clarifies that the medium for software interchange on which the machine-readable source code is provided must be a durable physical medium. Subsection 6b does not prevent a distributor from offering to provide source code to a third party by some other means, such as transmission over a network, so long as the option of obtaining source code on a physical medium is presented. % FIXME: probably mostly still right, needs some updates, though. Subsection 6b revises the requirements for the written offer to provide source code. As before, the offer must remain valid for at least three years. In addition, even after three years, a distributor of a product containing GPL'd object code must offer to provide source code for as long as the distributor also continues to offer spare parts or customer support for the product model. We believe that this is a reasonable and appropriate requirement; a distributor should be prepared to provide source code if he or she is prepared to provide support for other aspects of a physical product. % FIXME: 10x language is gone. Subsection 6b also increases the maximum permitted price for providing a copy of the source code. GPLv2 stated that the price could be no more than the cost of physically performing source distribution; GPLv3 allows the price to be up to ten times the distributor's cost. It may not be practical to expect some organizations to provide such copies at cost. Moreover, permitting such organizations to charge ten times the cost is not particularly harmful, since some recipient of the code can be expected to make the code freely available on a public network server. We also recognize that there is nothing wrong with profiting from providing copies of source code, provided that the price of a copy is not so unreasonably high as to make it effectively unavailable. % FIXME: probably mostly still right, needs some updates, though. Subsection 6c gives narrower permission than the corresponding subsection in GPLv2. The option of including a copy of an offer received in accordance with subsection 6b is available only for private distribution of object code; moreover, such private distribution is restricted to ``occasional non-commercial distribution.'' This subsection makes clear that a distributor cannot comply with the GPL merely by making object code available on a publicly-accessible network server accompanied by a copy of the written offer to provide source code received from an upstream distributor. % FIXME: probably mostly still right, needs some updates, though. New subsection 6d, which revises the final paragraph of GPLv2 section 3, addresses distribution of object code by offering access to copy the code from a designated place, such as by enabling electronic access to a network server. Subsection 6d clarifies that the distributor must offer equivalent access to copy the source code ``in the same way through the same place.'' This wording permits a distributor to offer a third party access to both object code and source code on a single network portal or web page, even though the access may include links to different physical servers. For example, a downstream distributor may provide a link to an upstream distributor's server and arrange with the operator of that server to keep the source code available for copying for as long as the downstream distributor enables access to the object code. This codifies what has been our interpretation of GPLv2. % FIXME: where should this go? We improved the wording of this sentence to provide a clearer expression of the intended policy. Under the 6d option, you may charge for the conveyed object code. Those who pay to obtain the object code must be given equivalent and gratis access to obtain the Corresponding Source. (If you convey the object code to them gratis, you must likewise make the Corresponding Source available to them without charge.) Those who do not obtain the object code from you, perhaps because they choose not to pay the fee you charge, are outside the scope of the provision; you need not give them any kind of access to the Corresponding Source. %FIXME: 6e, peer-to-peer Informing the peers is clearly enough; what seemed to be an additional knowledge requirement was superfluous wording. % FIXME: Not final paragraph anymore. The final paragraph of section 6 takes account of the fact that the Complete Corresponding Source Code may include added parts that carry non-GPL terms, as permitted by section 7. % FIXME: update lock-down section to work with more recent drafts Though the definition of Complete Corresponding Source Code in the second paragraph of section 1 is expansive, it is not sufficient to protect users' freedoms in many circumstances. For example, a GPL'd program, or a modified version of such a program, might need to be signed with a key or authorized with a code in order for it to run on a particular machine and function properly. Similarly, a program that produces digitally-restricted files might require a decryption code in order to read the output. The third paragraph of section 1 addresses this problem by making clear that Complete Corresponding Source Code includes any such encryption, authorization, and decryption codes. By requiring the inclusion of this information whenever the GPL requires distribution of Complete Corresponding Source Code, we thwart efforts to obstruct the goals of the GPL, and we ensure that users will remain in control over their own machines. We recognize an exception where use of the program normally implies that the user already has the codes. For example, in secure systems a computer owner might possess any keys needed to run a program, while the distributor of the program might not have the keys. % FIXME: installation information?? % FIXME: perhaps this additional information isn't needed, next 3 paras, but % there might be something good here Another major goal for GPLv3 has been to thwart technical measures such as signature checks in hardware to prevent modification of GPLed software on a device. Previous drafts attempted to accomplish this by defining "Corresponding Source" to include any encryption or authorization keys necessary to install new versions of the software. A number of members of the community questioned the impact and utility of such a definition. The third discussion draft uses a different strategy to accomplish the same task. Section 6 requires that parties distributing object code provide recipients with the source code through certain means. Now, when those distributors pass on the source, they are also required to pass on any information or data necessary to install modified software on the particular device that included it. We believe that this will more precisely accomplish our goals, and avoid potential problems with expanding the definition of source code. The new strategy should be familiar to free software developers: the GNU LGPL has long had similar requirements that enable users to link proprietary programs to modified libraries. \label{user-product} In addition, the scope of these requirements has been narrowed. This draft introduces the concept of a "User Product," which includes devices that are sold for personal, family, or household use. Distributors are only required to provide installation information when they convey object code in a User Product. After some discussion with committees, we discovered that the proposals in the second discussion draft would interfere with a number of existing business models that don't seem to be dangerous. We believe that this compromise will achieve the greatest success in preventing tivoization. In brief, we condition the right to convey object code in a defined class of ``User Products,'' under certain circumstances, on providing whatever information is required to enable a recipient to replace the object code with a functioning modified version. %FIXME: this really big section on user product stuff may be too much for the % tutorial In our earlier drafts, the requirement to provide encryption keys applied to all acts of conveying object code, as this requirement was part of the general definition of Corresponding Source. Section 6 of Draft 3 now limits the applicability of the technical restrictions provisions to object code conveyed in, with, or specifically for use in a defined class of ``User Products.'' In our discussions with companies and governments that use specialized or enterprise-level computer facilities, we found that sometimes these organizations actually want their systems not to be under their own control. Rather than agreeing to this as a concession, or bowing to pressure, they ask for this as a preference. It is not clear that we need to interfere, and the main problem lies elsewhere. While imposing technical barriers to modification is wrong regardless of circumstances, the areas where restricted devices are of the greatest practical concern today fall within the User Product definition. Most, if not all, technically-restricted devices running GPL-covered programs are consumer electronics devices, and we expect that to remain true in the near future. Moreover, the disparity in clout between the manufacturers and these users makes it difficult for the users to reject technical restrictions through their weak and unorganized market power. Even if limited to User Products, as defined in Draft 3, the provision still does the job that needs to be done. Therefore we have decided to limit the technical restrictions provisions to User Products in this draft. The core of the User Product definition is a subdefinition of ``consumer product'' taken verbatim from the Magnuson-Moss Warranty Act, a federal consumer protection law in the United States: ``any tangible personal property which is normally used for personal, family, or household purposes.''\footnote{15 U.S.C.~\S\ 2301.} The United States has had three decades of experience of liberal judicial and administrative interpretation of this definition in a manner favorable to consumer rights.\footnote{The Magnuson-Moss consumer product definition itself has been influential in the United States and Canada, having been adopted in several state and provincial consumer protection laws.} We mean for this body of interpretation to guide interpretation of the consumer product subdefinition in section 6, which will provide a degree of legal certainty advantageous to device manufacturers and downstream licensees alike. Our incorporation of such legal interpretation is in no way intended to work a general choice of United States law for GPLv3 as a whole. The paragraph in section 6 defining ``User Product'' and ``consumer product'' contains an explicit statement to this effect, bracketed for discussion. We will decide whether to retain this statement in the license text after gathering comment on it. One well-established interpretive principle under Magnuson-Moss is that ambiguities are resolved in favor of coverage. That is, in cases where it is not clear whether a product falls under the definition of consumer product, the product will be treated as a consumer product.\footnote{16 C.F.R.~\S\ 700.1(a); \textit{McFadden v.~Dryvit Systems, Inc.}, 54 U.C.C.~Rep.~Serv.2d 934 (D.~Ore.~2004).} Moreover, for a given product, ``normally used'' is understood to refer to the typical use of that type of product, rather than a particular use by a particular buyer. Products that are commonly used for personal as well as commercial purposes are consumer products, even if the person invoking rights is a commercial entity intending to use the product for commercial purposes.\footnote{16 C.F.R. \S \ 700.1(a). Numerous court decisions interpreting Magnuson-Moss are in accord; see, e.g., \textit{Stroebner Motors, Inc.~v.~Automobili Lamborghini S.p.A.}, 459 F.~Supp.2d 1028, 1033 (D.~Hawaii 2006).} Even a small amount of ``normal'' personal use is enough to cause an entire product line to be treated as a consumer product under Magnuson-Moss.\footnote{\textit{Tandy Corp.~v.~Marymac Industries, Inc.}, 213 U.S.P.Q.~702 (S.D.~Tex.~1981). In this case, the court concluded that TRS-80 microcomputers were consumer products, where such computers were designed and advertised for a variety of users, including small businesses and schools, and had only recently been promoted for use in the home.} We do not rely solely on the definition of consumer product, however, because in the area of components of dwellings we consider the settled interpretation under Magnuson-Moss underinclusive. Depending on how such components are manufactured or sold, they may or may not be considered Magnuson-Moss consumer products.\footnote{Building materials that are purchased directly by a consumer from a retailer, for improving or modifying an existing dwelling, are consumer products under Magnuson-Moss, but building materials that are integral component parts of the structure of a dwelling at the time that the consumer buys the dwelling are not consumer products. 16 C.F.R.~\S\S~700.1(c)--(f); Federal Trade Commission, Final Action Concerning Review of Interpretations of Magnuson-Moss Warranty Act, 64 Fed.~Reg.~19,700 (April 22, 1999); see also, e.g., \textit{McFadden}, 54 U.C.C.~Rep.~Serv.2d at 934.} Therefore, we define User Products as a superset of consumer products that also includes ``anything designed or sold for incorporation into a dwelling.'' Although the User Products rule of Draft 3 reflects a special concern for individual purchasers of devices, we wrote the rule to cover a category of products, rather than categorizing users. Discrimination against organizational users has no place in a free software license. Moreover, a rule that applied to individual use, rather than to use of products normally used by individuals, would have too narrow an effect. Because of its incorporation of the liberal Magnuson-Moss interpretation of ``consumer product,'' the User Products rule benefits not only individual purchasers of User Products but also all organizational purchasers of those same kinds of products, regardless of their intended use of the products. we have replaced the Magnuson-Moss reference with three sentences that encapsulate the judicial and administrative principles established over the past three decades in the United States concerning the Magnuson-Moss consumer product definition. First, we state that doubtful cases are resolved in favor of coverage under the definition. Second, we indicate that the words ``normally used'' in the consumer product definition refer to a typical or common use of a class of product, and not the status of a particular user or expected or actual uses by a particular user. Third, we make clear that the existence of substantial non-consumer uses of a product does not negate a determination that it is a consumer product, unless such non-consumer uses represent the only significant mode of use of that product. It should be clear from these added sentences that it is the general mode of use of a product that determines objectively whether or not it is a consumer product. One could not escape the effects of the User Products provisions by labeling what is demonstrably a consumer product in ways that suggest it is ``for professionals,'' for example, contrary to what some critics of Draft 3 have suggested. We have made one additional change to the User Products provisions of section 6. In Draft 3 we made clear that the requirement to provide Installation Information implies no requirement to provide warranty or support for a work that has been modified or installed on a User Product. The Final Draft adds that there is similarly no requirement to provide warranty or support for the User Product itself. % FIXME: this needs integration In Draft 3 we instead use a definition of ``Installation Information'' in section 6 that is as simple and clear as that goal. Installation Information is information that is ``required to install and execute modified versions of a covered work \dots from a modified version of its Corresponding Source,'' in the same User Product for which the covered work is conveyed. We provide guidance concerning how much information must be provided: it ``must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.'' For example, the information provided would be insufficient if it enabled a modified version to run only in a disabled fashion, solely because of the fact of modification (regardless of the actual nature of the modification). The information need not consist of cryptographic keys; Installation Information may be ``any methods, procedures, authorization keys, or other information.'' %FIXME: This probably needs work to be brought into clarity with tutorial, %next three paragarphs. Why do distributors only have to provide Installation Information for User Products? Some companies effectively outsource their entire IT department to another company. Computers and applications are installed in the company's offices, but managed remotely by some service provider. In some of these situations, the hardware is locked down; only the service provider has the key, and the customers consider that to be a desirable security feature. We think it's unfortunate that people would be willing to give up their freedom like this. But they should be able to fend for themselves, and the market provides plenty of alternatives to these services that would not lock them down. As a result, we have introduced this compromise to the draft: distributors are only required to provide Installation Information when they're distributing the software on a User Product, where the customers' buying power is likely to be less organized. This is a compromise of strategy, and not our ideals. Given the environment we live in today --- where Digital Restrictions Management is focused largely in consumer devices, and everyone, including large companies, is becoming increasingly worried about the effects of DRM thanks to recent developments like the release of Microsoft's Windows Vista --- we think that the proposed language will still provide us with enough leverage to effectively thwart DRM. We still believe you have a fundamental right to modify the software on all the hardware you own; the preamble explains, ``If such problems [as locked-down hardware] arise substantially in other domains, we stand ready to extend this provision to those domains in future versions of the GPL, as needed to protect the freedom of users.'' The definition of Installation Information states that the information provided ``must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.'' We did not consider it necessary to define ``continued functioning'' further. However, we believed it would be appropriate to provide some additional guidance concerning the scope of GPLv3-compliant action or inaction that distributors of technically-restricted User Products can take with respect to a downstream recipient who replaces the conveyed object code with a modified version. We make clear that GPLv3 implies no obligation ``to continue to provide support service, warranty, or updates'' for such a work. Most technically-restricted User Products are designed to communicate across networks. It is important for both users and network providers to know when denial of network access to devices running modified versions becomes a GPL violation. We settled on a rule that permits denial of access in two cases: ``when the modification itself materially and adversely affects the operation of the network,'' and when the modification itself ``violates the rules and protocols for communication across the network.'' The second case is deliberately drawn in general terms. We intend it to serve as a foundation for development of reasonable enforcement policies that respect recipients' right to modify while recognizing the legitimate interests of network providers. % FIXME: This needs merged in somewhere in here The mere fact that use of the work implies that the user \textit{has} the key may not be enough to ensure the user's freedom in using it. The user must also be able to read and copy the key; thus, its presence in a special register inside the computer does not satisfy the requirement. In an application in which the user's personal key is used to protect privacy or limit distribution of personal data, the user clearly has the ability to read and copy the key, which therefore is not included in the Corresponding Source. On the other hand, if a key is generated based on the object code, or is present in hardware, but the user cannot manipulate that key, then the key must be provided as part of the Corresponding Source. % FIXME: this came from Section 1 but is now mostly in Section 6 In section 1, we have tried to limit as precisely as possible the situation in which an encryption or signing key is part of the Corresponding Source Code of a GPL'd work. Where someone is provided a GPL'd work, he must receive the whole of the power to use and modify the work that was available to preceding licensors whose permissions he automatically receives. If a key would be necessary to install a fully functional version of the GPL'd work from source code, the user who receives the binary must receive the key along with the source. The requirement of full functionality, which we have illustrated with examples, is no more optional than it would be if GPL'd software were redistributed with an additional license condition, rather than a technical limitation, on the uses to which modified versions could be put.\footnote{There is a clear distinction between this situation and the situation of authenticated modules or plug-ins distributed as part of a multi-component software system, so that instances of the software can verify for the user the integrity of the collection. So long as the decision about whether to run a modified version is the user's decision, not controlled by a preceding licensor or a third party, the vendor's authentication key would also not qualify as part of the Corresponding Source under the language we have adopted for Draft 2.} % FIXME: this needs the right place. We do not object to the practice of conveying object code in a mode not practically susceptible to modification by any party, such as code burned in ROM or embedded in silicon. What we find ethically objectionable is the refusal to pass on to the downstream licensee the real right to modify, coupled with the retention of that right in the device manufacturer or some other party. Our text has never prohibited distribution in ROM, but we have decided to make the point explicitly, for clarity's sake. Accordingly, our text states that the requirement to provide Installation Information ``does not apply if neither you nor any third party retains the ability to install modified object code on the User Product.'' %FIXME: publicly documented format. This might work as a start on that: Our primary objective here was to ensure that the distributor use a generally-recognized mechanism for packaging source code. \section{Understanding License Compatibility} \label{license-compatibility} % FIXME: more about license compatibility here. A challenge that faced the Free Software community heavily through out the early 2000s was the proliferation of incompatible Free Software licenses. Of course, we cannot make the GPL compatible with all such licenses. GPLv3 contains provisions that are designed to reduce license incompatibility by making it easier for developers to combine code carrying non-GPL terms with GPL'd code. % FIXME: connecting text \subsection{Additional Permissions} % FIXME: rework and fix formatting. The GPL is a statement of permissions, some of which have conditions. Additional terms, terms that supplement those of the GPL, may come to be placed on, or removed from, GPL-covered code in certain common ways. We consider those added terms ``additional permissions'' if they grant exceptions from the conditions of the GPL, and ``additional requirements'' if they add conditions to the basic permissions of the GPL. The treatment of additional permissions and additional requirements under GPLv3 is necessarily asymmetrical, because they do not raise the same ethical and interpretive issues; in particular, additional requirements, if allowed without careful limitation, could transform a GPL'd program into a non-free one. With these principles in the background, section 7 answers the following questions: (1) How do the presence of additional terms on all or part of a GPL'd program affect users' rights? (2) When and how may a licensee add terms to code being distributed under the GPL? (3) When may a licensee remove additional terms? % FIXME: FSF third person, etc. Additional permissions present the easier case. We have licensed some of our own software under GPLv2 with permissive exceptions that allow combination with non-free code, and that allow removal of those permissions by downstream recipients; similarly, LGPLv2.1 is in essence a permissive variant of GPLv2, and it permits relicensing under the GPL. We have generalized these practices in section 7. A licensee may remove any additional permission from a covered work, whether it was placed by the original author or by an upstream distributor. A licensee may also add any kind of additional permission to any part of a work for which the licensee has, or can give, appropriate copyright permission. For example, if the licensee has written that part, the licensee is the copyright holder for that part and can therefore give additional permissions that are applicable to it. Alternatively, the part may have been written by someone else and licensed, with the additional permissions, to that licensee. Any additional permissions on that part are, in turn, removable by downstream recipients. As subsection 7a explains, the effect of an additional permission depends on whether the permission applies to the whole work or a part. % FIXME: rework this a bit We have drafted version 3 of the GNU LGPL, which we have released with Draft 2 of GPLv3, as a simple list of additional permissions supplementing the terms of GPLv3. Section 7 has thus provided the basis for recasting a formally complex license as an elegant set of added terms, without changing any of the fundamental features of the existing LGPL. We offer this draft of LGPLv3 as as a model for developers wishing to license their works under the GPL with permissive exceptions. The removability of additional permissions under section 7 does not alter any existing behavior of the LGPL; the LGPL has always allowed relicensing under the ordinary GPL. \subsection{Additional Requirements and License Compatibility} % FIXME: minor rewrites needed We broadened the title of section 7 because license compatibility, as it is conventionally understood, is only one of several facets of the placement of additional terms on GPL'd code. The license compatibility issue arises for three reasons. First, the GPL is a strong copyleft license, requiring modified versions to be distributed under the GPL. Second, the GPL states that no further restrictions may be placed on the rights of recipients. Third, all other free software licenses in common use contain certain requirements, many of which are not conditions made by the GPL. Thus, when GPL'd code is modified by combination with code covered by another formal license that specifies other requirements, and that modified code is then distributed to others, the freedom of recipients may be burdened by additional requirements in violation of the GPL. It can be seen that additional permissions in other licenses do not raise any problems of license compatibility. % FIXME: minor rewrites needed Section 7 relaxes the prohibition on further restrictions slightly by enumerating, in subsection 7b, a limited list of categories of additional requirements that may be placed on code without violating GPLv3. The list includes the items that were listed in Draft 1, though rewritten for clarity. It also includes a new catchall category for terms that might not obviously fall within one of the other categories but which are precisely equivalent to GPLv3 conditions, or which deny permission for activities clearly not permitted by GPLv3. We have carefully considered but rejected proposals to expand this list further. We have also rejected suggestions, made by some discussion committee members, that the Affero clause requirement (7d in Draft 1 and 7b4 in Draft 2) be removed, though we have revised it in response to certain comments. We are unwavering in our view that the Affero requirement is a legitimate one, and we are committed to achieving compatibility of the Affero GPL with GPLv3. % FIXME: minor rewrites needed A GPL licensee may place an additional requirement on code for which the licensee has or can give appropriate copyright permission, but only if that requirement falls within the list given in subsection 7b. Placement of any other kind of additional requirement continues to be a violation of the license. Additional requirements that are in the 7b list may not be removed, but if a user receives GPL'd code that purports to include an additional requirement not in the 7b list, the user may remove that requirement. Here we were particularly concerned to address the problem of program authors who purport to license their works in a misleading and possibly self-contradictory fashion, using the GPL together with unacceptable added restrictions that would make those works non-free software. \section{GPLv3~\S7: Explicit Compatibility} % FIXME: probably mostly still right, needs some updates, though. In GPLv3 we take a new approach to the issue of combining GPL'd code with code governed by the terms of other free software licenses. Our view, though it was not explicitly stated in GPLv2 itself, was that GPLv2 allowed such combinations only if the non-GPL licensing terms permitted distribution under the GPL and imposed no restrictions on the code that were not also imposed by the GPL. In practice, we supplemented this policy with a structure of exceptions for certain kinds of combinations. % FIXME: probably mostly still right, needs some updates, though. Section 7 of GPLv3 implements a more explicit policy on license compatibility. It formalizes the circumstances under which a licensee may release a covered work that includes an added part carrying non-GPL terms. We distinguish between terms that provide additional permissions, and terms that place additional requirements on the code, relative to the permissions and requirements established by applying the GPL to the code. % FIXME: probably mostly still right, needs some updates, though. Section 7 first explicitly allows added parts covered by terms with additional permissions to be combined with GPL'd code. This codifies our existing practice of regarding such licensing terms as compatible with the GPL. A downstream user of a combined GPL'd work who modifies such an added part may remove the additional permissions, in which case the broader permissions no longer apply to the modified version, and only the terms of the GPL apply to it. % FIXME: probably mostly still right, needs some updates, though. In its treatment of terms that impose additional requirements, section 7 extends the range of licensing terms with which the GPL is compatible. An added part carrying additional requirements may be combined with GPL'd code, but only if those requirements belong to an set enumerated in section 7. We must, of course, place some limit on the kinds of additional requirements that we will accept, to ensure that enhanced license compatibility does not defeat the broader freedoms advanced by the GPL. Unlike terms that grant additional permissions, terms that impose additional requirements cannot be removed by a downstream user of the combined GPL'd work, because no such user would have the right to do so. % FIXME: probably mostly still right, needs some updates, though. Under subsections 7a and 7b, the requirements may include preservation of copyright notices, information about the origins of the code or alterations of the code, and different warranty disclaimers. Under subsection 7c, the requirements may include limitations on the use of names of contributors and on the use of trademarks for publicity purposes. In general, we permit these requirements in added terms because many free software licenses include them and we consider them to be unobjectionable. Because we support trademark fair use, the limitations on the use of trademarks may seek to enforce only what is required by trademark law, and may not prohibit what would constitute fair use. % FIXME: 7d-f \section{GPLv3~\S7(e): Peer-to-Peer Sharing Networks} % FIXME: rewrite a bit, maybe drop reference to bitorrent? Certain decentralized forms of peer-to-peer file sharing present a challenge to the unidirectional view of distribution that is implicit in GPLv2 and Draft 1 of GPLv3. It is neither straightforward nor reasonable to identify an upstream/downstream link in BitTorrent distribution; such distribution is multidirectional, cooperative and anonymous. In systems like BitTorrent, participants act both as transmitters and recipients of blocks of a particular file, but they see themselves as users and receivers, and not as distributors in any conventional sense. At any given moment of time, most peers will not have the complete file. % FIXME: rewrite a bit. The GPL permits distribution of a work in object code form over a network, provided that the distributor offers equivalent access to copy the Corresponding Source Code ``in the same way through the same place.'' This wording might be interpreted to permit BitTorrent distribution of binaries if they are packaged together with the source code, but this impractical, for at least two reasons. First, even if the source code is packaged with the binary, it will only be available to a non-seeding peer at the end of the distribution process, but the peer will already have been providing parts of the binary to others in the network, functioning rather like a router or a cache proxy. Second, in practice BitTorrent and similar peer-to-peer forms of transmission have been less suitable means for distributing source code. In large distributions, packaging source code with the binary may result in a substantial increase in file size and transmission time. Source code packages themselves tend not to be transmitted through BitTorrent owing to reduced demand. There generally will be too few participants downloading the same source package at the same time to enable effective seeding and distribution. % FIXME: rewrite a bit. We have made two changes that recognize and facilitate distribution of covered works in object code form using BitTorrent or similar peer-to-peer methods. First, under new subsection 6e, if a licensee conveys such a work using peer-to-peer transmission, that licensee is in compliance with section 6 so long as the licensee knows, and informs other peers where, the object code and its Corresponding Source are publicly available at no charge under subsection 6d. The Corresponding Source therefore need not be provided through the peer-to-peer system that was used for providing the binary. Second, we have revised section 9 to make clear that ancillary propagation of a covered work that occurs as part of the process of peer-to-peer file transmission does not require acceptance, just as mere receipt and execution of the Program does not require acceptance. Such ancillary propagation is permitted without limitation or further obligation. % FIXME: removing additional restrictions % FIXME: probably mostly still right, needs some updates, though. Section 7 requires a downstream user of a covered work to preserve the non-GPL terms covering the added parts just as they must preserve the GPL, as long as any substantial portion of those parts is present in the user's version. % FIXME: minor rewrites needed Section 7 points out that GPLv3 itself makes no assertion that an additional requirement is enforceable by the copyright holder. However, section 7 makes clear that enforcement of such requirements is expected to be by the termination procedure given in section 8 of GPLv3. % FIXME: better context, etc. Some have questioned whether section 7 is needed, and some have suggested that it creates complexity that did not previously exist. We point out to those readers that there is already GPLv2-licensed code that carries additional terms. One of the objectives of section 7 is to rationalize existing practices of program authors and modifiers by setting clear guidelines regarding the removal and addition of such terms. With its carefully limited list of allowed additional requirements, section 7 accomplishes additional objectives, permitting the expansion of the base of code available for GPL developers, while also encouraging useful experimentation with requirements we do not include in the GPL itself. \section{GPLv3~\S8: A Lighter Termination} % FIXME: probably mostly still right, needs some updates, though. GPLv2 provided for automatic termination of the rights of a person who copied, modified, sublicensed, or distributed a work in violation of the license. Automatic termination can be too harsh for those who have committed an inadvertent violation, particularly in cases involving distribution of large collections of software having numerous copyright holders. A violator who resumes compliance with GPLv2 would need to obtain forgiveness from all copyright holders, but even to contact them all might be impossible. % FIXME: needs to be updated to describe more complex termination Section 8 of GPLv3 replaces automatic termination with a non-automatic termination process. Any copyright holder for the licensed work may opt to terminate the rights of a violator of the license, provided that the copyright holder has first given notice of the violation within 60 days of its most recent occurrence. A violator who has been given notice may make efforts to enter into compliance and may request that the copyright holder agree not exercise the right of termination; the copyright holder may choose to grant or refuse this request. % FIXME: needs to be updated to describe more complex termination If a licensee who is in violation of GPLv3 acts to correct the violation and enter into compliance, and the licensee receives no notice of the past violation within 60 days, then the licensee need not worry about termination of rights under the license. In Draft 3 the termination provision of section 8 has been revised to indicate that, if a licensee violates the GPL, a contributor may terminate any patent licenses that it granted under the first paragraph of section 11 to that licensee, in addition to any copyright permissions the contributor granted to the licensee. Therefore, a contributor may terminate the patent licenses it granted to a downstream licensee who brings patent infringement litigation in violation of section 10. We have made two substantive changes to section 8. First, we have clarified that patent rights granted under the GPL are among the rights that a copyright holder may terminate under section 8. Therefore, a contributor who grants a patent license under the first paragraph of section 11 may terminate that patent license, just as that contributor may terminate copyright rights, to a downstream recipient who has violated the license. We think that this is a reasonable result, and was already implicit in the wording of the termination provision in our earlier drafts. Moreover, this clarification should encourage patent holders to make contributions to GPL-covered programs. Second, we have modified the termination procedure by providing a limited opportunity to cure license violations, an improvement that was requested by many different members of our community. If a licensee has committed a first-time violation of the GPL with respect to a given copyright holder, but the licensee cures the violation within 30 days following receipt of notice of the violation, then any of the licensee's GPL rights that have been terminated by the copyright holder are ``automatically reinstated.'' The addition of the cure opportunity achieves a better balance than our earlier section 8 drafts between facilitating enforcement of the license and protecting inadvertent violators against unfair results. We have restructured the form of section 8 by replacing non-automatic termination with automatic termination coupled with opportunities for provisional and permanent reinstatement of rights. The revised wording does not alter the underlying policy or details of procedure established in the previous drafts, including the 60-day period of repose and 30-day cure opportunity for first-time violators. The restoration of automatic termination was motivated in part to facilitate enforcement in European countries. We also believe the revised wording will be easier to understand and apply in all jurisdictions. \section{GPLv3~\S9: Acceptance} % FIXME: needs some work here Section 9 means what it says: mere receipt or execution of code neither requires nor signifies contractual acceptance under the GPL. Speaking more broadly, we have intentionally structured our license as a unilateral grant of copyright permissions, the basic operation of which exists outside of any law of contract. Whether and when a contractual relationship is formed between licensor and licensee under local law do not necessarily matter to the working of the license. \section{GPLv3~\S10: Explicit Downstream License} % FIXME: These don't belong here, but it's closer to where it ought to be now. It is important to note that section 11, paragraph 3 refers to a work that is conveyed, and section 10, paragraph 2 refers to a kind of automatic counterpart to conveying achieved as the result of a transaction. % FIXME: needs filled out and more here. Draft1 removed the words ``at no charge'' from what is now subsection 5b, the core copyleft provision, for reasons related to our current changes to the second paragraph of section 4: it had contributed to a misconception that the GPL did not permit charging for distribution of copies. The purpose of the ``at no charge'' wording was to prevent attempts to collect royalties from third parties. The removal of these words created the danger that the imposition of licensing fees would no longer be seen as a license violation. We therefore have added a new explicit prohibition on imposition of licensing fees or royalties in section 10. This section is an appropriate place for such a clause, since it is a specific consequence of the general requirement that no further restrictions be imposed on downstream recipients of GPL-covered code. Careful readers of the GPL have suggested that its explicit prohibition against imposition of further restrictions\footnote{GPLv2, section 6; Draft 3, section 10, third paragraph.} has, or ought to have, implications for those who assert patents against other licensees. Draft 2 took some steps to clarify this point in a manner not specific to patents, by describing the imposition of ``a license fee, royalty, or other charge'' for exercising GPL rights as one example of an impermissible further restriction. In Draft 3 we have clarified further that the requirement of non-imposition of further restrictions has specific consequences for litigation accusing GPL-covered programs of infringement. Section 10 now states that ``you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program (or the contribution of any contributor).'' That is to say, a patent holder's licensed permissions to use a work under GPLv3 may be terminated under section 8 if the patent holder files a lawsuit alleging that use of the work, or of any upstream GPLv3-licensed work on which the work is based, infringes a patent. \section{GPLv3~\S11: Explicit Patent Licensing} \label{GPLv3s11} The patent licensing practices that section 7 of GPLv2 (corresponding to section 12 of GPLv3) was designed to prevent are one of several ways in which software patents threaten to make free programs non-free and to prevent users from exercising their rights under the GPL. GPLv3 takes a more comprehensive approach to combatting the danger of patents. Software patenting is a harmful and unjust policy, and should be abolished; recent experience makes this all the more evident. Since many countries grant patents that can apply to and prohibit software packages, in various guises and to varying degrees, we seek to protect the users of GPL-covered programs from those patents, while at the same time making it feasible for patent holders to contribute to and distribute GPL-covered programs as long as they do not attack the users of those programs. It is generally understood that GPLv2 implies some limits on a licensee's power to assert patent claims against the use of GPL-covered works. Therefore, we have designed GPLv3 to reduce the patent risks that distort and threaten the activities of users who make, run, modify and share free software. At the same time, we have given due consideration to practical goals such as certainty and administrability for patent holders that participate in distribution and development of GPL-covered software. Our policy requires each such patent holder to provide appropriate levels of patent assurance to users, according to the nature of the patent holder's relationship to the program. Draft 3 features several significant changes concerning patents. We have made improvements to earlier wording, clarified when patent assertion becomes a prohibited restriction on GPL rights, and replaced a distribution-triggered non-assertion covenant with a contribution-based patent license grant. We have also added provisions to block collusion by patent holders with software distributors that would extend patent licenses in a discriminatory way. Draft 3 introduces the terms ``contributor'' and ``contribution,'' which are used in the third paragraph of section 10 and the first paragraph of section 11, discussed successively in the following two subsections. Section 0 defines a contributor as ``a party who licenses under this License a work on which the Program is based.'' That work is the ``contribution'' of that contributor. In other words, each received GPLv3-covered work is associated with one or more contributors, making up the finite set of upstream GPLv3 licensors for that work. Viewed from the perspective of a recipient of the Program, contributors include all the copyright holders for the Program, other than copyright holders of material originally licensed under non-GPL terms and later incorporated into a GPL-covered work. The contributors are therefore the initial GPLv3 licensors of the Program and all subsequent upstream licensors who convey, under the terms of section 5, modified works on which the Program is based. For a contributor whose contribution is a modified work conveyed under section 5, the contribution is ``the entire work, as a whole'' which the contributor is required to license under GPLv3. The contribution therefore includes not just the material added or altered by the contributor, but also the pre-existing material the contributor copied from the upstream version and retained in the modified version. Our usage of ``contributor'' and ``contribution'' should not be confused with the various other ways in which those terms are used in certain other free software licenses.\footnote{Cf., e.g., Apache License, version 2.0, section 1; Eclipse Public License, version 1.0, section 1; Mozilla Public License, version 1.1, section 1.1.} The term ``patent license,'' as used in the third through fifth paragraphs of section 11, is not meant to be confined to agreements formally identified or classified as patent licenses. The new second paragraph of section 11 makes this clear by defining ``patent license,'' for purposes of the subsequent three paragraphs, as ``a patent license, a covenant not to bring suit for patent infringement, or any other express agreement or commitment, however denominated, not to enforce a patent.'' The definition does not include patent licenses that arise by implication or operation of law, because the third through fifth paragraphs of section 11 are specifically concerned with explicit promises that purport to be legally enforceable. Our previous drafts featured a patent license grant triggered by all acts of distribution of GPLv3-covered works.\footnote{In Draft 2 we rewrote the patent license as a covenant not to assert patent claims. We explain why we reverted to the form of a patent license grant in \S\ \ref{cov}.} Many patent-holding companies objected to this policy. They have made two objections: (1) the far-reaching impact of the patent license grant on the patent holder is disproportionate to the act of merely distributing code without modification or transformation, and (2) it is unreasonable to expect an owner of vast patent assets to exercise requisite diligence in reviewing all the GPL-covered software that it provides to others. Some expressed particular concern about the consequences of ``inadvertent'' distribution. The argument that the impact of the patent license grant would be ``disproportionate,'' that is to say unfair, is not valid. Since software patents are weapons that no one should have, and using them for aggression against free software developers is an egregious act, preventing that act cannot be unfair. However, the second argument seems valid in a practical sense. A typical GNU/Linux distribution includes thousands of programs. It would be quite difficult for a redistributor with a large patent portfolio to review all those programs against that portfolio every time it receives and passes on a new version of the distribution. Moreover, this question raises a strategic issue. If the GPLv3 patent license requirements convince patent-holding companies to remain outside the distribution path of all GPL-covered software, then these requirements, no matter how strong, will cover few patents. We concluded it would be more effective to make a partial concession which would lead these companies to feel secure in doing the distribution themselves, so that the conditions of section 10 would apply to assertion of their patents. We therefore made the stricter section 11 patent license apply only to those distributors that have modified the program. The other changes we have made in sections 10 and 11 provide strengthened defenses against patent assertion and compensate partly for this concession. Therefore, in Draft 3, the first paragraph of section 11 states that a contributor's patent license covers all the essential patent claims implemented by the whole program as that contributor distributes it. Contributors of modified works grant a patent license to claims that read on ``the entire work, as a whole.'' This is the work that the copyleft clause in section 5 requires the contributor to license under GPLv3; it includes the material the contributor has copied from the upstream version that the contributor has modified. The first paragraph of section 11 does not apply to those that redistribute the program without change.\footnote{An implied patent license from the distributor, however, may arise by operation of law. See the final paragraph of section 11. Moreover, distributors are subject to the limits on patent assertion contained in the third paragraph of section 10.} We hope that this decision will result in fairly frequent licensing of patent claims by contributors. A contributor is charged with awareness of the fact that it has modified a work and provided it to others; no act of contribution should be treated as inadvertent. Our rule also requires no more work, for a contributor, than the weaker rule proposed by the patent holders. Under their rule, the contributor must always compare the entire work against its patent portfolio to determine whether the combination of the modifications with the remainder of the work cause it to read on any of the contributor's patent claims. We have made three changes to the definition of ``essential patent claims'' in section 0. This definition now serves exclusively to identify the set of patent claims licensed by a contributor under the first paragraph of section 11. First, we have clarified when essential patent claims include sublicensable claims that have been licensed to the contributor by a third party.\footnote{This issue is typically handled in other free software licenses having patent licensing provisions by use of the unhelpful term ``licensable,'' which is either left undefined or is given an ambiguous definition.} Most commercial patent license agreements that permit sublicensing do so under restrictive terms that are inconsistent with the requirements of the GPL. For example, some patent licenses allow the patent licensee to sublicense but require collection of royalties from any sublicensees. The patent licensee could not distribute a GPL-covered program and grant the recipient a patent sublicense for the program without violating section 12 of GPLv3.\footnote{Draft 3 provides a new example in section 12 that makes this point clear.} In rare cases, however, a conveying party can freely grant patent sublicenses to downstream recipients without violating the GPL. Draft 3 now defines essential patent claims, for a given party, as a subset of the claims ``owned or controlled'' by the party. The definition states that ``control includes the right to grant sublicenses in a manner consistent with the requirements of this License.'' Therefore, in the case of a patent license that requires collection of royalties from sublicensees, essential patent claims would not include any claims sublicensable under that patent license, because sublicenses to those claims could not be granted consistent with section 12. Second, we now state that essential patent claims are those ``that would be infringed by some manner, permitted by this License, of making, using, or selling the work.'' This modified wording is intended to make clear that a patent claim is ``essential'' if some mode of usage would infringe that claim, even if there are other modes of usage that would not infringe. Third, we have clarified that essential patent claims ``do not include claims that would be infringed only as a consequence of further modification of the work.'' That is to say, the set of essential patent claims licensed under the first paragraph of section 11 is fixed by the the particular version of the work that was contributed. The claim set cannot expand as a work is further modified downstream. (If it could, then any software patent claim would be included, since any software patent claim can be infringed by some further modification of the work.)\footnote{However, ``the work'' should not be understood to be restricted to a particular mechanical affixation of, or medium for distributing, a program, where the same program might be provided in other forms or in other ways that may be captured by other patent claims held by the contributor.} The downstream shielding provision of section 11 responds particularly to the problem of exclusive deals between patent holders and distributors, which threaten to distort the free software distribution system in a manner adverse to developers and users. Draft 2 added a source code availability option to this provision, as a specific alternative to the general requirement to shield downstream users from patent claims licensed to the distributor. A distributor conveying a covered work knowingly relying on a patent license may comply with the provision by ensuring that the Corresponding Source of the work is publicly available, free of charge. We retained the shielding option in Draft 2 because we did not wish to impose a general requirement to make source code available to all, which has never been a GPL condition. The addition of the source code availability option was supported by the free software vendors most likely to be affected by the downstream shielding provision. Enterprises that primarily use and occasionally distribute free software, however, raised concerns regarding the continued inclusion of a broadly-worded requirement to ``shield,'' which appears to have been mistakenly read by those parties as creating an obligation to indemnify. To satisfy these concerns, in Draft 3 we have replaced the option to shield with two specific alternatives to the source code availability option. The distributor may comply by disclaiming the patent license it has been granted for the conveyed work, or by arranging to extend the patent license to downstream recipients.\footnote{The latter option, if chosen, must be done ``in a manner consistent with the requirements of this License''; for example, it is unavailable if extension of the patent license would result in a violation of section 12. Cf.~the discussion of sublicensable patent claims in \S\ \ref{epc}.} The GPL is intended to permit private distribution as well as public distribution, and the addition of these options ensures that this remains the case, even though we expect that distributors in this situation will usually choose the source code availability option. Without altering its underlying logic, we have modified the phrasing of the requirement to make clear that it is activated only if the Corresponding Source is not already otherwise publicly available. (Most often it will, in fact, already be available on some network server operated by a third party.) Even if it is not already available, the option to ``cause the Corresponding Source to be so available'' can then be satisfied by verifying that a third party has acted to make it available. That is to say, the affected distributor need not itself host the Corresponding Source to take advantage of the source code availability option. This subtlety may help the distributor avoid certain peculiar assumptions of liability. We have made two other changes to the downstream shielding provision. The phrase ``knowingly rely'' was left undefined in our earlier drafts; in Draft 3 we have provided a detailed definition. We have also deleted the condition precedent, added in Draft 2, that the relied-upon patent license be one that is non-sublicensable and ``not generally available to all''; this was imprecise in Draft 2 and is unnecessary in Draft 3. In nearly all cases in which the ``knowingly relying'' test is met, the patent license will indeed not be sublicensable or generally available to all on free terms. If, on the other hand, the patent license is generally available under terms consistent with the requirements of the GPL, the distributor is automatically in compliance, because the patent license has already been extended to all downstream recipients. If the patent license is sublicensable on GPL-consistent terms, the distributor may choose to grant sublicenses to downstream recipients instead of causing source code to be publicly available. In such a case, if the distributor is also a contributor, it will already have granted a patent sublicense by operation of the first paragraph of section 11,\footnote{See \S\ \ref{epc}.} and so it need not do anything further to comply with the third paragraph. % FIXME: This probably needs editing One major goal for GPLv3 is to provide developers with additional protection from being sued for patent infringement. After much feedback and cooperation from the committees, we are now proposing a patent license which closely resembles those found in other free software licenses. This will be more comfortable for everyone in the free software community to use, without creating undue burdens for distributors. We have also added new terms to stop distributors from colluding with third parties to offer selective patent protection, as Microsoft and Novell have recently done. The GPL is designed to ensure that all users receive the same rights; arrangements that circumvent this make a mockery of free software, and we must do everything in our power to stop them. Our strategy has two parts. First, any license that protects some recipients of GPLed software must be extended to all recipients of the software. Second, we prohibit anyone who made such an agreement from distributing software released under GPLv3. We are still considering whether or not this ban should apply when a deal was made before these terms were written, and we look forward to community input on this issue. The patent license grant of the first paragraph of section 11 no longer applies to those who merely distribute works without modification. (We explain why we made this change in the next subsection.) Such parties are nonetheless subject to the conditions stated in section 10. Unlike the patent license, which establishes a defense for downstream users lasting for as long as they remain in compliance with the GPL, the commitment not to sue that arises under section 10 is one that the distributor can end, so long as the distributor also ceases to distribute. This is because a party who initiates patent litigation in violation of section 10 risks termination of its licensed permissions by the copyright holders of the work. % FIXME: just brought in words here, needs rewriting. is rooted in the basic principles of the GPL. Our license has always stated that distributors may not impose further restrictions on users' exercise of GPL rights. To make the suggested distinction between contribution and distribution is to allow a distributor to demand patent royalties from a direct or indirect recipient, based on claims embodied in the distributed code. This undeniably burdens users with an additional legal restriction on their rights, in violation of the license. %FIXME: possible useful text, but maybe not. In the covenant provided in the revised section 11, the set of claims that a party undertakes not to assert against downstream users are that party's ``essential patent claims'' in the work conveyed by the party. ``Essential patent claims,'' a new term defined in section 0, are simply all claims ``that would be infringed by making, using, or selling the work.'' We have abandoned the phrase ``reasonably contemplated use.'' This change makes the obligations of distributing patent holders more predictable. % FIXME: probably needs a lot of work, these provisions changed over time. GPLv3 adds a new section on licensing of patents. GPLv2 relies on an implied patent license. The doctrine of implied license is one that is recognized under United States patent law but may not be recognized in other jurisdictions. We have therefore decided to make the patent license grant explicit in GPLv3. Under section 11, a redistributor of a GPL'd work automatically grants a nonexclusive, royalty-free and worldwide license for any patent claims held by the redistributor, if those claims would be infringed by the work or a reasonably contemplated use of the work. % FIXME: probably needs a lot of work, these provisions changed over time. The patent license is granted both to recipients of the redistributed work and to any other users who have received any version of the work. Section 11 therefore ensures that downstream users of GPL'd code and works derived from GPL'd code are protected from the threat of patent infringement allegations made by upstream distributors, regardless of which country's laws are held to apply to any particular aspect of the distribution or licensing of the GPL'd code. % FIXME: probably needs a lot of work, these provisions changed over time. A redistributor of GPL'd code may benefit from a patent license that has been granted by a third party, where the third party otherwise could bring a patent infringement lawsuit against the redistributor based on the distribution or other use of the code. In such a case, downstream users of the redistributed code generally remain vulnerable to the applicable patent claims of the third party. This threatens to defeat the purposes of the GPL, for the third party could prevent any downstream users from exercising the freedoms that the license seeks to guarantee. % FIXME: probably needs a lot of work, these provisions changed over time. The second paragraph of section 11 addresses this problem by requiring the redistributor to act to shield downstream users from these patent claims. The requirement applies only to those redistributors who distribute knowingly relying on a patent license. Many companies enter into blanket patent cross-licensing agreements. With respect to some such agreements, it would not be reasonable to expect a company to know that a particular patent license covered by the agreement, but not specifically mentioned in it, protects the company's distribution of GPL'd code. % FIXME: does this still fit with the final retaliation provision? This narrowly-targeted patent retaliation provision is the only form of patent retaliation that GPLv3 imposes by its own force. We believe that it strikes a proper balance between preserving the freedom of a user to run and modify a program, and protecting the rights of other users to run, modify, copy, and distribute code free from threats by patent holders. It is particularly intended to discourage a GPL licensee from securing a patent directed to unreleased modifications of GPL'd code and then suing the original developers or others for making their own equivalent modifications. Several other free software licenses include significantly broader patent retaliation provisions. In our view, too little is known about the consequences of these forms of patent retaliation. As we explain below, section 7 permits distribution of a GPL'd work that includes added parts covered by terms other than those of the GPL. Such terms may include certain kinds of patent retaliation provisions that are broader than those of section 2. % FIXME: should we mention Microsoft-Novell at all? Section 7 of GPLv2 (now section 12 of GPLv3) has seen some success in deterring conduct that would otherwise result in denial of full downstream enjoyment of GPL rights. Experience has shown us that more is necessary, however, to ensure adequate community safety where companies act in concert to heighten the anticompetitive use of patents that they hold or license. Previous drafts of GPLv3 included a ``downstream shielding'' provision in section 11, which we have further refined in Draft 3; it is now found in the third paragraph of section 11. In addition, Draft 3 introduces two new provisions in section 11, located in the fourth and fifth paragraphs, that address the problem of collusive extension of patent forbearance promises that discriminate against particular classes of users and against the exercise of particular freedoms. This problem has been made more acute by the recent Microsoft/Novell deal. We attack the Microsoft-Novell deal from two angles. First, in the sixth paragraph of section 11, the draft says that if you arrange to provide patent protection to some of the people who get the software from you, that protection is automatically extended to everyone who receives the software, no matter how they get it. This means that the patent protection Microsoft has extended to Novell's customers would be extended to everyone who uses any software Novell distributes under GPLv3. Second, in the seventh paragraph, the draft says that you are prohibited from distributing software under GPLv3 if you make an agreement like the Microsoft-Novell deal in the future. This will prevent other distributors from trying to make other deals like it. The main reason for this is tactical. We believe we can do more to protect the community by allowing Novell to use software under GPL version 3 than by forbidding it to do so. This is because of paragraph 6 of section 11 (corresponding to paragraph 4 in Draft 3). It will apply, under the Microsoft/Novell deal, because of the coupons that Microsoft has acquired that essentially commit it to participate in the distribution of the Novell SLES GNU/Linux system. Microsoft is scrambling to dispose of as many Novell SLES coupons as possible prior to the adoption of GPLv3. Unfortunately for Microsoft, those coupons bear no expiration date, and paragraph 6 has no cut-off date. Through its ongoing distribution of coupons, Microsoft will have procured the distribution of GPLv3-covered programs as soon as they are included in Novell SLES distributions, thereby extending patent defenses to all downstream recipients of that software by operation of paragraph 6. A secondary reason is to avoid affecting other kinds of agreements for other kinds of activities. We have tried to take care in paragraph 7 to distinguish pernicious deals of the Microsoft/Novell type from business conduct that is not particularly harmful, but we cannot be sure we have entirely succeeded. There remains some risk that other unchangeable past agreements could fall within its scope. In future deals, distributors engaging in ordinary business practices can structure the agreements so that they do not fall under paragraph 7. However, it will block Microsoft and other patent aggressors from further such attempts to subvert parts of our community. A software patent forbids the use of a technique or algorithm, and its existence is a threat to all software developers and users. A patent holder can use a patent to suppress any program which implements the patented technique, even if thousands of other techniques are implemented together with it. Both free software and proprietary software are threatened with death in this way. However, patents threaten free software with a fate worse than death: a patent holder might also try to use the patent to impose restrictions on use or distribution of a free program, such as to make users feel they must pay for permission to use it. This would effectively make it proprietary software, exactly what the GPL is intended to prevent. Novell and Microsoft have recently attempted a new way of using patents against our community, which involves a narrow and discriminatory promise by a patent holder not to sue customers of one particular distributor of a GPL-covered program. Such deals threaten our community in several ways, each of which may be regarded as de facto proprietization of the software. If users are frightened into paying that one distributor just to be safe from lawsuits, in effect they are paying for permission to use the program. They effectively deny even these customers the full and safe exercise of some of the freedoms granted by the GPL. And they make disfavored free software developers and distributors more vulnerable to attacks of patent aggression, by dividing them from another part of our community, the commercial users that might otherwise come to their defense. We have added the fourth and fifth paragraphs of section 11 to combat this threat. This subsection briefly describes the operation of the new provisions. We follow it with a more detailed separate note on the Microsoft/Novell patent deal, in which we provide an extensive rationale for these measures. As noted, one effect of the discriminatory patent promise is to divide and isolate those who make free software from the commercial users to whom the promise is extended. This deprives the noncommercial developers of the communal defensive measures against patents made possible by the support of those commercial users. The fourth paragraph of section 11 operates to restore effective defenses to the targets of patent aggression. A patent holder becomes subject to the fourth paragraph of section 11 when it enters into a transaction or arrangement that involves two acts: (1) conveying a GPLv3-covered work, and (2) offering to some, but not all, of the work's eventual users a patent license for particular activities using specific copies of the covered work. This paragraph only operates when the two triggering acts are part of a single arrangement, because the patent license is part of the arrangement for conveying, which requires copyright permission. Under those conditions, the discriminatory patent license is ``automatically extended to all recipients of the covered work and works based on it.'' This provision establishes a defense to infringement allegations brought by the patent holder against any users of the program who are not covered by the discriminatory patent license. That is to say, it gives all recipients the benefit of the patent promise that the patent holder extended only to some. The effect is to make contributing discriminatory promises of patent safety to a GPL distribution essentially like contributing code. In both cases, the operation of the GPL extends license permission to everyone that receives a copy of the program. The fourth paragraph of section 11 gives users a defense against patent aggression brought by the party who made the discriminatory patent promise that excluded them. By contrast, the fifth paragraph stops free software vendors from contracting with patent holders to make discriminatory patent promises. In effect, the fifth paragraph extends the principle of section 12 to situations involving collusion between a patent holder and a distributor. Under this provision, a distributor conveying a GPL-covered program may not make an arrangement to get a discriminatory patent promise from a third party for its customers, covering copies of the program (or products that contain the program), if the arrangement requires the distributor to make payment to the third party based on the extent of its activity in conveying the program, and if the third party is itself in the business of distributing software. Unlike the fourth paragraph, which creates a legal defense for targets of patent aggression, the consequence for violation of the fifth paragraph is termination of GPL permissions for the distributor. The business, technical, and patent cooperation agreement between Microsoft and Novell announced in November 2006 has significantly affected the development of Draft 3. The fourth and fifth paragraphs of section 11 embody our response to the sort of threat represented by the Microsoft/Novell deal, and are designed to protect users from such deals, and prevent or deter the making of such deals. The details of the agreements entered into between Microsoft and Novell, though subject to eventual public disclosure through the securities regulation system, have not been fully disclosed to this point.\footnote{Lawyers employed by the Software Freedom Law Center, which is counsel to the Free Software Foundation and other relevant free software clients, were accorded limited access to the terms of the deal under a non-disclosure agreement between SFLC and Novell. The reasons for delay in the application of securities regulations requiring publication of the relevant contracts are unrelated to the deal between Microsoft and Novell.} It is a matter of public knowledge, however, that the arrangement calls for Novell to pay a portion of the future gross revenue of one of its divisions to Microsoft, and that (as one other feature of a complex arrangement) Microsoft has promised Novell's customers not to bring patent infringement actions against certain specific copies of Novell's SUSE ``Linux''\footnote{This is a GNU/Linux distribution, and is properly called SUSE GNU/Linux Enterprise Server.} Enterprise Server product for which Novell receives revenue from the user, so long as the user does not make or distribute additional copies of SLES. The basic harm that such an agreement can do is to make the free software subject to it effectively proprietary. This result occurs to the extent that users feel compelled, by the threat of the patent, to get their copies in this way. So far, the Microsoft/Novell deal does not seem to have had this result, or at least not very much: users do not seem to be choosing Novell for this reason. But we cannot take for granted that such threats will always fail to harm the community. We take the threat seriously, and we have decided to act to block such threats, and to reduce their potential to do harm. Such deals also offer patent holders a crack through which to split the community. Offering commercial users the chance to buy limited promises of patent safety in effect invites each of them to make a separate peace with patent aggressors, and abandon the rest of our community to its fate. Microsoft has been restrained from patent aggression in the past by the vocal opposition of its own enterprise customers, who now also use free software systems to run critical applications. Public statements by Microsoft concerning supposed imminent patent infringement actions have spurred resistance from users Microsoft cannot afford to alienate. But if Microsoft can gain royalties from commercial customers by assuring them that \textit{their} copies of free software have patent licenses through a deal between Microsoft and specific GNU/Linux vendors, Microsoft would then be able to pressure each user individually, and each distributor individually, to treat the software as proprietary. If enough users succumb, it might eventually gain a position to terrify noncommercial developers into abandoning the software entirely. Preventing these harms is the goal of the new provisions of section 11. The fourth paragraph deals with the most acute danger posed by discrimination among customers, by ensuring that any party who distributes others' GPL-covered programs, and makes promises of patent safety limited to some but not all recipients of copies of those specific programs, automatically extends its promises of patent safety to cover all recipients of all copies of the covered works. This will negate part of the harm of the Microsoft/Novell deal, for GPLv3-covered software. In addition to the present deal, however, GPLv3 must act to deter similar future arrangements, and it cannot be assumed that all future arrangements by Microsoft or other potential patent aggressors will involve procuring the conveyance of the program by the party that grants the discriminatory promises of patent safety. Therefore, we need the fifth paragraph as well, which is aimed at parties that play the Novell role in a different range of possible deals. Drafting this paragraph was difficult because it is necessary to distinguish between pernicious agreements and other kinds of agreements which do not have an acutely harmful effect, such as patent contributions, insurances, customary cross-license promises to customers, promises incident to ordinary asset transfers, and standard settlement practices. We believe that we have achieved this, but it is hard to be sure, so we are considering making this paragraph apply only to agreements signed in the future. If we do that, companies would only need to structure future agreements in accord with the fifth paragraph, and would not face problems from past agreements that cannot be changed now. We are not yet convinced that this is necessary, and we plan to ask for more comment on the question. This is why the date-based cutoff is included in brackets. One drawback of this cutoff date is that it would ``let Novell off'' from part of the response to its deal with Microsoft. However, this may not be a great drawback, because the fourth paragraph will apply to that deal. We believe it is sufficient to ensure either the deal's voluntary modification by Microsoft or its reduction to comparative harmlessness. Novell expected to gain commercial advantage from its patent deal with Microsoft; the effects of the fourth paragraph in undoing the harm of that deal will necessarily be visited upon Novell. \section{GPLv3~\S12: Familiar as GPLv2 \S~7} % FIXME: probably mostly still right, needs some updates, though. The wording in the first sentence of section 12 has been revised slightly to clarify that an agreement, such as a litigation settlement agreement or a patent license agreement, is one of the ways in which conditions may be ``imposed'' on a GPL licensee that may contradict the conditions of the GPL, but which do not excuse the licensee from compliance with those conditions. This change codifies what has been our interpretation of GPLv2. % FIXME: probably mostly still right, needs some updates, though. We have removed the limited severability clause of GPLv2 section 7 as a matter of tactical judgment, believing that this is the best way to ensure that all provisions of the GPL will be upheld in court. We have also removed the final sentence of GPLv2 section 7, which we consider to be unnecessary. \section{GPLv3~\S13: The Great Affero Compromise} The main purpose of clause 7b4 was to attain GPLv3 compatibility for the additional condition of version 1 of the Affero GPL, with a view to achieving compatibility for a future version, since version 1 was incompatible with GPLv3.\footnote{Version 1 of the Affero GPL contains its own copyleft clause, worded identically to that in GPLv2, which conflicts with the copyleft clause in GPLv3. The Affero GPL permits relicensing under versions of the GPL later than version 2, but only if the later version ``includes terms and conditions substantially equivalent to those of this license'' (Affero GPL, version 1, section 9). The Affero license was written with the expectation that its additional requirement would be incorporated into the terms of GPLv3 itself, rather than being placeable on parts added to a covered work through the mechanism of section 7 of GPLv3.} However, we wrote the clause broadly enough to cover a range of other possible terms that would differ from the Affero condition in their details. Draft 3 no longer pursues the more ambitious goal of allowing compatibility for a whole category of Affero-like terms. In place of 7b4, we have added a new section 13 that simply permits GPLv3-covered code to be linked with code covered by the forthcoming version 2 of the Affero GPL. We have made this decision in the face of irreconcilable views from different parts of our community. While we had known that many commercial users of free software were opposed to the inclusion of a mandatory Affero-like requirement in the body of GPLv3 itself, we were surprised at their opposition to its availability through section 7. Free software vendors allied to these users joined in their objections, as did a number of free software developers arguing on ethical as well as practical grounds. Some of this hostility seemed to be based on a misapprehension that Affero-like terms placed on part of a covered work would somehow extend to the whole of the work.\footnote{It is possible that the presence of the GPLv2-derived copyleft clause in the existing Affero GPL contributed to this misunderstanding.} Our explanations to the contrary did little to satisfy these critics; their objections to 7b4 instead evolved into a broader indictment of the additional requirements scheme of section 7. It was clear, however, that much of the concern about 7b4 stemmed from its general formulation. Many were alarmed at the prospect of GPLv3 compatibility for numerous Affero-like licensing conditions, unpredictable in their details but potentially having significant commercial consequences. On the other hand, many developers, otherwise sympathetic to the policy goals of the Affero GPL, have objected to the form of the additional requirement in that license. These developers were generally disappointed with our decision to allow Affero-like terms through section 7, rather than adopt a condition for GPLv3. Echoing their concerns about the Affero GPL itself, they found fault with the wording of the section 7 clause in both of the earlier drafts. We drafted 7b4 at a higher level than its Draft 1 counterpart based in part on comments from these developers. They considered the Draft 1 clause too closely tied to the Affero mechanism of preserving functioning facilities for downloading source, which they found too restrictive of the right of modification. The 7b4 rewording did not satisfy them, however. They objected to its limitation to terms requiring compliance by network transmission of source, and to the technically imprecise or inaccurate use of the phrase ``same network session.'' We have concluded that any redrafting of the 7b4 clause would fail to satisfy the concerns of both sets of its critics. The first group maintains that GPLv3 should do nothing about the problem of public use. The second group would prefer for GPLv3 itself to have an Affero-like condition, but that seems to us too drastic. By permitting GPLv3-covered code to be linked with code covered by version 2 of the Affero GPL, the new section 13 honors our original commitment to achieving GPL compatibility for the Affero license. Version 2 of the Affero GPL is not yet published. We will work with Affero, Inc., and with all other interested members of our community, to complete the drafting of this license following the release of Draft 3, with a goal of having a final version available by the time of our adoption of the final version of GPLv3. We hope the new Affero license will satisfy those developers who are concerned about the issue of public use of unconveyed versions but who have concerns about the narrowness of the condition in the existing Affero license. As the second sentence in section 13 indicates, when a combined work is made by linking GPLv3-covered code with Affero-covered code, the copyleft on one part will not extend to the other part.\footnote{The plan is that the additional requirement of the new Affero license will state a reciprocal limitation.} That is to say, in such combinations, the Affero requirement will apply only to the part that was brought into the combination under the Affero license. Those who receive such a combination and do not wish to use code under the Affero requirement may remove the Affero-covered portion of the combination. Those who criticize the permission to link with code under the Affero GPL should recognize that most other free software licenses also permit such linking. \section{GPLv3~\S14: So, When's GPLv4?} \label{GPLv3s14} % FIXME Say more No substantive change has been made in section 14. The wording of the section has been revised slightly to make it clearer. % FIXME; proxy \section{GPLv3~\S15--17: Warranty Disclaimers and Liability Limitation} No substantive changes have been made in sections 15 and 16. % FIXME: more, plus 17 % FIXME: Section header needed here about choice of law. % FIXME: reword into tutorial Some have asked us to address the difficulties of internationalization by including, or permitting the inclusion of, a choice of law provision. We maintain that this is the wrong approach. Free software licenses should not contain choice of law clauses, for both legal and pragmatic reasons. Choice of law clauses are creatures of contract, but the substantive rights granted by the GPL are defined under applicable local copyright law. Contractual free software licenses can operate only to diminish these rights. Choice of law clauses also raise complex questions of interpretation when works of software are created by combination and extension. There is also the real danger that a choice of law clause will specify a jurisdiction that is hostile to free software principles. % FIXME: reword into tutorial, \ref to section 7. Our revised version of section 7 makes explicit our view that the inclusion of a choice of law clause by a licensee is the imposition of an additional requirement in violation of the GPL. Moreover, if a program author or copyright holder purports to supplement the GPL with a choice of law clause, section 7 now permits any licensee to remove that clause. % FIXME: does this need to be a section, describing how it was out then in % then out then in? :) We have removed from this draft the appended section on ``How to Apply These Terms to Your New Programs.'' For brevity, the license document can instead refer to a web page containing these instructions as a separate document. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{The Lesser GPL} As we have seen in our consideration of the GPL, its text is specifically designed to cover all possible derivative works under copyright law. Our goal in designing GPL was to make sure that any derivative work of GPL'd software was itself released under GPL when distributed. Reaching as far as copyright law will allow is the most direct way to reach that goal. However, while the strategic goal is to bring as much Free Software into the world as possible, particular tactical considerations regarding software freedom dictate different means. Extending the copyleft effect as far as copyright law allows is not always the most prudent course in reaching the goal. In particular situations, even those of us with the goal of building a world where all published software is Free Software realize that full copyleft does not best serve us. The GNU Lesser General Public License (``GNU LGPL'') was designed as a solution for such situations. \section{The First LGPL'd Program} The first example that FSF encountered where such altered tactics were needed was when work began on the GNU C Library. The GNU C Library would become (and today, now is) a drop-in replacement for existing C libraries. On a Unix-like operating system, C is the lingua franca and the C library is an essential component for all programs. It is extremely difficult to construct a program that will run with ease on a Unix-like operating system without making use of services provided by the C library --- even if the program is written in a language other than C\@. Effectively, all user application programs that run on any modern Unix-like system must make use of the C library. By the time work began on the GNU implementation of the C libraries, there were already many C libraries in existence from a variety of vendors. Every proprietary Unix vendor had one, and many third parties produced smaller versions for special purpose use. However, our goal was to create a C library that would provide equivalent functionality to these other C libraries on a Free Software operating system (which in fact happens today on modern GNU/Linux systems, which all use the GNU C Library). Unlike existing GNU application software, however, the licensing implications of releasing the GNU C Library (``glibc'') under GPL were somewhat different. Applications released under GPL would never themselves become part of proprietary software. However, if glibc were released under GPL, it would require that any application distributed for the GNU/Linux platform be released under GPL\@. Since all applications on a Unix-like system depend on the C library, it means that they must link with that library to function on the system. In other words, all applications running on a Unix-like system must be combined with the C library to form a new whole derivative work that is composed of the original application and the C library. Thus, if glibc were GPL'd, each and every application distributed for use on GNU/Linux would also need to be GPL'd, since to even function, such applications would need to be combined into larger derivative works by linking with glibc. At first glance, such an outcome seems like a windfall for Free Software advocates, since it stops all proprietary software development on GNU/Linux systems. However, the outcome is a bit more subtle. In a world where many C libraries already exist, many of which could easily be ported to GNU/Linux, a GPL'd glibc would be unlikely to succeed. Proprietary vendors would see the excellent opportunity to license their C libraries to anyone who wished to write proprietary software for GNU/Linux systems. The de-facto standard for the C library on GNU/Linux would likely be not glibc, but the most popular proprietary one. Meanwhile, the actual goal of releasing glibc under GPL --- to ensure no proprietary applications on GNU/Linux --- would be unattainable in this scenario. Furthermore, users of those proprietary applications would also be users of a proprietary C library, not the Free glibc. The Lesser GPL was initially conceived to handle this scenario. It was clear that the existence of proprietary applications for GNU/Linux was inevitable. Since there were so many C libraries already in existence, a new one under GPL would not stop that tide. However, if the new C library were released under a license that permitted proprietary applications to link with it, but made sure that the library itself remained Free, an ancillary goal could be met. Users of proprietary applications, while they would not have the freedom to copy, share, modify and redistribute the application itself, would have the freedom to do so with respect to the C library. There was no way the license of glibc could stop or even slow the creation of proprietary applications on GNU/Linux. However, loosening the restrictions on the licensing of glibc ensured that nearly all proprietary applications at least used a Free C library rather than a proprietary one. This trade-off is central to the reasoning behind the LGPL\@. Of course, many people who use the LGPL today are not thinking in these terms. In fact, they are often choosing the LGPL because they are looking for a ``compromise'' between the GPL and the X11-style liberal licensing. However, understanding FSF's reasoning behind the creation of the LGPL is helpful when studying the license. \section{What's the Same?} Much of the text of the LGPL is identical to the GPL\@. As we begin our discussion of the LGPL, we will first eliminate the sections that are identical, or that have the minor modification changing the word ``Program'' to ``Library.'' First, LGPLv2.1~\S1, the rules for verbatim copying of source, are equivalent to those in GPLv2~\S1. Second, LGPLv2.1~\S8 is equivalent GPLv2~\S4\@. In both licenses, this section handles termination in precisely the same manner. LGPLv2.1~\S9 is equivalent to GPLv2~\S5\@. Both sections assert that the license is a copyright license, and handle the acceptance of those copyright terms. LGPLv2.1~\S10 is equivalent to GPLv2~\S6. They both protect the distribution system of Free Software under these licenses, to ensure that up, down, and throughout the distribution chain, each recipient of the software receives identical rights under the license and no other restrictions are imposed. LGPLv2.1~\S11 is GPLv2~\S7. As discussed, it is used to ensure that other claims and legal realities, such as patent licenses and court judgments, do not trump the rights and permissions granted by these licenses, and requires that distribution be halted if such a trump is known to exist. LGPLv2.1~\S12 adds the same features as GPLv2~\S8. These sections are used to allow original copyright holders to forbid distribution in countries with draconian laws that would otherwise contradict these licenses. LGPLv2.1~\S13 sets up FSF as the steward of the LGPL, just as GPLv2~\S9 does for GPL. Meanwhile, LGPLv2.1~\S14 reminds licensees that copyright holders can grant exceptions to the terms of LGPL, just as GPLv2~\S10 reminds licensees of the same thing. Finally, the assertions of no warranty and limitations of liability are identical; thus LGPLv2.1~\S15 and LGPLv2.1~\S16 are the same as GPLv2~\S11 and \S 12. As we see, the entire latter half of the license is identical. The parts which set up the legal boundaries and meta-rules for the license are the same. It is our intent that the two licenses operate under the same legal mechanisms and are enforced precisely the same way. We strike a difference only in the early portions of the license. Namely, in the LGPL we go into deeper detail of granting various permissions to create derivative works, so the redistributors can make some proprietary derivatives. Since we simply do not allow the license to stretch as far as copyright law does regarding what derivative works must be relicensed under the same terms, we must go further to explain which derivative works we will allow to be proprietary. Thus, we'll see that the front matter of the LGPL is a bit more wordy and detailed with regards to the permissions granted to those who modify or redistribute the software. \section{Additions to the Preamble} Most of LGPL's Preamble is identical, but the last seven paragraphs introduce the concepts and reasoning behind creation of the license, presenting a more generalized and briefer version of the story with which we began our consideration of LGPL\@. In short, FSF designed LGPL for those edge cases where the freedom of the public can better be served by a more lax licensing system. FSF doesn't encourage use of LGPL automatically for any software that happens to be a library; rather, FSF suggests that it only be used in specific cases, such as the following: \begin{itemize} \item To encourage the widest possible use of a Free Software library, so it becomes a de-facto standard over similar, although not interface-identical, proprietary alternatives \item To encourage use of a Free Software library that already has interface-identical proprietary competitors that are more developed \item To allow a greater number of users to get freedom, by encouraging proprietary companies to pick a Free alternative for its otherwise proprietary products \end{itemize} LGPL's preamble sets forth the limits to which the license seeks to go in chasing these goals. LGPL is designed to ensure that users who happen to acquire software linked with such libraries have full freedoms with respect to that library. They should have the ability to upgrade to a newer or modified Free version or to make their own modifications, even if they cannot modify the primary software program that links to that library. Finally, the preamble introduces two terms used throughout the license to clarify between the different types of derivative works: ``works that use the library,'' and ``works based on the library.'' Unlike GPL, LGPL must draw some lines regarding derivative works. We do this here in this license because we specifically seek to liberalize the rights afforded to those who make derivative works. In GPL, we reach as far as copyright law allows. In LGPL, we want to draw a line that allows some derivative works copyright law would otherwise prohibit if the copyright holder exercised his full permitted controls over the work. \section{An Application: A Work that Uses the Library} In the effort to allow certain proprietary derivative works and prohibit others, LGPL distinguishes between two classes of derivative works: ``works based on the library,'' and ``works that use the library.'' The distinction is drawn on the bright line of binary (or runtime) derivative works and source code derivatives. We will first consider the definition of a ``work that uses the library,'' which is set forth in LGPLv2.1~\S5. We noted in our discussion of GPLv2~\S3 (discussed in Section~\ref{GPLv2s3} of this document) that binary programs when compiled and linked with GPL'd software are derivative works of that GPL'd software. This includes both linking that happens at compile-time (when the binary is created) or at runtime (when the binary -- including library and main program both -- is loaded into memory by the user). In GPL, binary derivative works are controlled by the terms of the license (in GPLv2~\S3), and distributors of such binary derivatives must release full corresponding source\@. In the case of LGPL, these are precisely the types of derivative works we wish to permit. This scenario, defined in LGPL as ``a work that uses the library,'' works as follows: \newcommand{\workl}{$\mathcal{L}$} \newcommand{\lplusi}{$\mathcal{L\!\!+\!\!I}$} \begin{itemize} \item A new copyright holder creates a separate and independent work, \worki{}, that makes interface calls (e.g., function calls) to the LGPL'd work, called \workl{}, whose copyright is held by some other party. Note that since \worki{} and \workl{} are separate and independent works, there is no copyright obligation on this new copyright holder with regard to the licensing of \worki{}, at least with regard to the source code. \item The new copyright holder, for her software to be useful, realizes that it cannot run without combining \worki{} and \workl{}. Specifically, when she creates a running binary program, that running binary must be a derivative work, called \lplusi{}, that the user can run. \item Since \lplusi{} is a derivative work of both \worki{} and \workl{}, the license of \workl{} (the LGPL) can put restrictions on the license of \lplusi{}. In fact, this is what LGPL does. \end{itemize} We will talk about the specific restrictions LGPLv2.1 places on ``works that use the library'' in detail in Section~\ref{lgpl-section-6}. For now, focus on the logic related to how the LGPLv2.1 places requirements on the license of \lplusi{}. Note, first of all, the similarity between this explanation and that in Section~\ref{separate-and-independent}, which discussed the combination of otherwise separate and independent works with GPL'd code. Effectively, what LGPLv2.1 does is say that when a new work is otherwise separate and independent, but has interface calls out to an LGPL'd library, then it is considered a ``work that uses the library.'' In addition, the only reason that LGPLv2.1 has any control over the licensing of a ``work that uses the library'' is for the same reason that GPL has some say over separate and independent works. Namely, such controls exist because the {\em binary combination\/} (\lplusi{}) that must be created to make the separate work (\worki{}) at all useful is a derivative work of the LGPLv2.1'd software (\workl{}). Thus, a two-question test that will help indicate if a particular work is a ``work that uses the library'' under LGPLv2.1 is as follows: \begin{enumerate} \item Is the source code of the new copyrighted work, \worki{}, a completely independent work that stands by itself, and includes no source code from \workl{}? \item When the source code is compiled, does it create a derivative work by combining with \workl{}, either by static (compile-time) or dynamic (runtime) linking, to create a new binary work, \lplusi{}? \end{enumerate} If the answers to both questions are ``yes,'' then \worki{} is most likely a ``work that uses the library.'' If the answer to the first question ``yes,'' but the answer to the second question is ``no,'' then most likely \worki{} is neither a ``work that uses the library'' nor a ``work based on the library.'' If the answer to the first question is ``no,'' but the answer to the second question is ``yes,'' then an investigation into whether or not \worki{} is in fact a ``work based on the library'' is warranted. \section{The Library, and Works Based On It} In short, a ``work based on the library'' could be defined as any derivative work of LGPL'd software that cannot otherwise fit the definition of a ``work that uses the library.'' A ``work based on the library'' extends the full width and depth of copyright derivative works, in the same sense that GPL does. Most typically, one creates a ``work based on the library'' by directly modifying the source of the library. Such a work could also be created by tightly integrating new software with the library. The lines are no doubt fuzzy, just as they are with GPL'd works, since copyright law gives us no litmus test for derivative works of a software program. Thus, the test to use when considering whether something is a ``work based on the library'' is as follows: \begin{enumerate} \item Is the new work, when in source form, a derivative work under copyright law of the LGPL'd work? \item Is there no way in which the new work fits the definition of a ``work that uses the library''? \end{enumerate} If the answer is ``yes'' to both these questions, then you most likely have a ``work based on the library.'' If the answer is ``no'' to the first but ``yes'' to the second, you are in a gray area between ``work based on the library'' and a ``work that uses the library.'' In our years of work with the LGPLv2.1, however, we have never seen a work of software that was not clearly one or the other; the line is quite bright. At times, though, we have seen cases where a derivative work appeared in some ways to be a work that used the library and in other ways a work based on the library. We overcame this problem by dividing the work into smaller subunits. It was soon discovered that what we actually had were three distinct components: the original LGPL'd work, a specific set of works that used that library, and a specific set of works that were based on the library. Once such distinctions are established, the licensing for each component can be considered independently and the LGPLv2.1 applied to each work as prescribed. \section{Subtleties in Defining the Application} In our discussion of the definition of ``works that use the library,'' we left out a few more complex details that relate to lower-level programming details. The fourth paragraph of LGPLv2.1~\S5 covers these complexities, and it has been a source of great confusion. Part of the confusion comes because a deep understanding of how compiler programs work is nearly mandatory to grasp the subtle nature of what LGPLv2.1~\S5, \P 4 seeks to cover. It helps some to note that this is a border case that we cover in the license only so that when such a border case is hit, the implications of using LGPL continue in the expected way. To understand this subtle point, we must recall the way that a compiler operates. The compiler first generates object code, which are the binary representations of various programming modules. Each of those modules is usually not useful by itself; it becomes useful to a user of a full program when those modules are {\em linked\/} into a full binary executable. As we have discussed, the assembly of modules can happen at compile-time or at runtime. Legally, there is no distinction between the two --- both create a derivative work by copying and combining portions of one work and mixing them with another. However, under LGPL, there is a case in the compilation process where the legal implications are different. Specifically, while we know that a ``work that uses the library'' is one whose final binary is a derivative work, but whose source is not, there are cases where the object code --- that intermediate step between source and final binary --- is a derivative work created by copying verbatim code from the LGPL'd software. For efficiency, when a compiler turns source code into object code, it sometimes places literal portions of the copyrighted library code into the object code for an otherwise separate independent work. In the normal scenario, the derivative would not be created until final assembly and linking of the executable occurred. However, when the compiler does this efficiency optimization, at the intermediate object code step, a derivative work is created. LGPLv2.1~\S5\P4 is designed to handle this specific case. The intent of the license is clearly that simply compiling software to ``make use'' of the library does not in itself cause the compiled work to be a ``work based on the library.'' However, since the compiler copies verbatim, copyrighted portions of the library into the object code for the otherwise separate and independent work, it would actually cause that object file to be a ``work based on the library.'' It is not FSF's intent that a mere compilation idiosyncrasy would change the requirements on the users of the LGPLv2.1'd software. This paragraph removes that restriction, allowing the implications of the license to be the same regardless of the specific mechanisms the compiler uses underneath to create the ``work that uses the library.'' As it turns out, we have only once had anyone worry about this specific idiosyncrasy, because that particular vendor wanted to ship object code (rather than final binaries) to their customers and was worried about this edge condition. The intent of clarifying this edge condition is primarily to quell the worries of software engineers who understand the level of verbatim code copying that a compiler often does, and to help them understand that the full implications of LGPLv2.1 are the same regardless of the details of the compilation progress. \section{LGPLv2.1~\S6 \& LGPLv2.1~\S5: Combining the Works} \label{lgpl-section-6} Now that we have established a good working definition of works that ``use'' and works that ``are based on'' the library, we will consider the rules for distributing these two different works. The rules for distributing ``works that use the library'' are covered in LGPLv2.1~\S6\@. LGPLv2.1~\S6 is much like GPLv2~\S3, as it requires the release of source when a binary version of the LGPL'd software is released. Of course, it only requires that source code for the library itself be made available. The work that ``uses'' the library need not be provided in source form. However, there are also conditions in LGPLv2.1~\S6 to make sure that a user who wishes to modify or update the library can do so. LGPLv2.1~\S6 lists five choices with regard to supplying library source and granting the freedom to modify that library source to users. We will first consider the option given by \S~6(b), which describes the most common way currently used for LGPLv2.1 compliance on a ``work that uses the library.'' LGPLv2.1~\S6(b) allows the distributor of a ``work that uses the library'' to simply use a dynamically linked, shared library mechanism to link with the library. This is by far the easiest and most straightforward option for distribution. In this case, the executable of the work that uses the library will contain only the ``stub code'' that is put in place by the shared library mechanism, and at runtime the executable will combine with the shared version of the library already resident on the user's computer. If such a mechanism is used, it must allow the user to upgrade and replace the library with interface-compatible versions and still be able to use the ``work that uses the library.'' However, all modern shared library mechanisms function as such, and thus LGPLv2.1~\S6(b) is the simplest option, since it does not even require that the distributor of the ``work 2based on the library'' ship copies of the library itself. LGPLv2.1~\S6(a) is the option to use when, for some reason, a shared library mechanism cannot be used. It requires that the source for the library be included, in the typical GPL fashion, but it also has a requirement beyond that. The user must be able to exercise her freedom to modify the library to its fullest extent, and that means recombining it with the ``work based on the library.'' If the full binary is linked without a shared library mechanism, the user must have available the object code for the ``work based on the library,'' so that the user can relink the application and build a new binary. The remaining options in LGPLv2.1~\S6 are very similar to the other choices provided by GPLv2~\S3. There are some additional options, but time does not permit us in this course to go into those additional options. In almost all cases of distribution under LGPL, either LGPLv2.1~\S6(a) or LGPLv2.1~\S6(b) are exercised. \section{Distribution of the Combined Works} Essentially, ``works based on the library'' must be distributed under the same conditions as works under full GPL\@. In fact, we note that LGPLv2.1~\S2 is nearly identical in its terms and requirements to GPLv2~\S2. There are again subtle differences and additions, which time does not permit us to cover in this course. \section{And the Rest} The remaining variations between LGPL and GPL cover the following conditions: \begin{itemize} \item Allowing a licensing ``upgrade'' from LGPL to GPL\@ (in LGPLv2.1~\S3) \item Binary distribution of the library only, covered in LGPLv2.1~\S4, which is effectively equivalent to LGPLv2.1~\S3 \item Creating aggregates of libraries that are not derivative works of each other, and distributing them as a unit (in LGPLv2.1~\S7) \end{itemize} Due to time constraints, we cannot cover these additional terms in detail, but they are mostly straightforward. The key to understanding LGPLv2.1 is understanding the difference between a ``work based on the library'' and a ``work that uses the library.'' Once that distinction is clear, the remainder of LGPLv2.1 is close enough to GPL that the concepts discussed in our more extensive GPL unit can be directly applied. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{Integrating the GPL into Business Practices} Since GPL'd software is now extremely prevalent through the industry, it is useful to have some basic knowledge about using GPL'd software in business and how to build business models around GPL'd software. \section{Using GPL'd Software In-House} As discussed in Sections~\ref{GPLv2s0} and~\ref{GPLv2s5} of this tutorial, the GPL only governs the activities of copying, modifying and distributing software programs that are not governed by the license. Thus, in FSF's view, simply installing the software on a machine and using it is not controlled or limited in any way by GPL\@. Using Free Software in general requires substantially fewer agreements and less license compliance activity than any known proprietary software. Even if a company engages heavily in copying the software throughout the enterprise, such copying is not only permitted by GPLv2~\S\S1 and 3, but it is encouraged! If the company simply deploys unmodified (or even modified) Free Software throughout the organization for its employees to use, the obligations under the license are very minimal. Using Free Software has a substantially lower cost of ownership --- both in licensing fees and in licensing checking and handling -- than the proprietary software equivalents. \section{Business Models} \label{Business Models} Using Free Software in house is certainly helpful, but a thriving market for Free Software-oriented business models also exists. There is the traditional model of selling copies of Free Software distributions. Many companies, including IBM and Red Hat, make substantial revenue from this model. IBM primarily chooses this model because they have found that for higher-end hardware, the cost of the profit made from proprietary software licensing fees is negligible. The real profit is in the hardware, but it is essential that software be stable, reliable and dependable, and the users be allowed to have unfettered access to it. Free Software, and GPL'd software in particular (because IBM can be assured that proprietary versions of the same software will not exists to compete on their hardware) is the right choice. Red Hat has actually found that a ``convenience fee'' for Free Software, when set at a reasonable price (around \$60 or so), can produce some profit. Even though Red Hat's system is fully downloadable on their Web site, people still go to local computer stores and buy copies of their box set, which is simply a printed version of the manual (available under a Free license as well) and the Free Software system it documents. \medskip However, custom support, service, and software improvement contracts are the most widely used models for GPL'd software. The GPL is central to their success, because it ensures that the code base remains common, and that large and small companies are on equal footing for access to the technology. Consider, for example, the GNU Compiler Collection (GCC). Cygnus Solutions, a company started in the early 1990s, was able to grow steadily simply by providing services for GCC --- mostly consisting of new ports of GCC to different or new, embedded targets. Eventually, Cygnus was so successful that it was purchased by Red Hat where it remains a profitable division. However, there are very small companies like CodeSourcery, as well as other medium-sized companies like MontaVista and OpenTV that compete in this space. Because the code-base is protect by GPL, it creates and demands industry trust. Companies can cooperate on the software and improve it for everyone. Meanwhile, companies who rely on GCC for their work are happy to pay for improvements, and for ports to new target platforms. Nearly all the changes fold back into the standard versions, and those forks that exist remain freely available. \medskip \label{Proprietary Relicensing} A final common business model that is perhaps the most controversial is proprietary relicensing of a GPL'd code base. This is only an option for software in which a particular entity is the sole copyright holder. As discussed earlier in this tutorial, a copyright holder is permitted under copyright law to license a software system under her copyright as many different ways as she likes to as many different parties as she wishes. Some companies, such as MySQL AB and TrollTech, use this to their financial advantage with regard to a GPL'd code base. The standard version is available from the company under the terms of the GPL\@. However, parties can purchase separate proprietary software licensing for a fee. This business model is problematic because it means that the GPL'd code base must be developed in a somewhat monolithic way, because volunteer Free Software developers may be reluctant to assign their copyrights to the company because it will not promise to always and forever license the software as Free Software. Indeed, the company will surely use such code contributions in proprietary versions licensed for fees. \section{Ongoing Compliance} GPL compliance is in fact a very simple matter -- much simpler than typical proprietary software agreements and EULAs. Usually, the most difficult hurdle is changing from a proprietary software mindset to one that seeks to foster a community of sharing and mutual support. Certainly complying with the GPL from a users' perspective gives substantially fewer headaches than proprietary license compliance. For those who go into the business of distributing {\em modified\\} versions of GPL'd software, the burden is a bit higher, but not by much. The glib answer is that by releasing the whole product as Free Software, it is always easy to comply with the GPL. However, admittedly to the dismay of FSF, many modern and complex software systems are built using both proprietary and GPL'd components that are not legally derivative works of each other. Sometimes, it is easier simply to improve existing GPL'd application than to start from scratch. In exchange for that benefit, the license requires that the modifier give back to the commons that made the work easier in the first place. It is a reasonable trade-off and a way to help build a better world while also making a profit. Note that FSF does provide services to assist companies who need assistance in complying with the GPL. You can contact FSF's GPL Compliance Labs at $<$compliance@fsf.org$>$. If you are particularly interested in matters of GPL compliance, we recommend the second course in this series, {\em GPL Compliance Case Studies and Legal Ethics in Free Software Licensing\/}, in which we discuss some real GPL violation cases that FSF has worked to resolve. Consideration of such cases can help give insight on how to handle GPL compliance in new situations. % ===================================================================== % END OF FIRST DAY SEMINAR SECTION % =====================================================================