% compliance-guide.tex -*- LaTeX -*- \part{A Practical Guide to GPL Compliance} \label{gpl-compliance-guide} {\parindent 0in This part is: \\ \begin{tabbing} Copyright \= \copyright{} 2008, 2014 \= \hspace{.2in} Bradley M. Kuhn. \\ Copyright \= \copyright{} 2014 \> \hspace{.2in} Free Software Foundation, Inc. \\ Copyright \> \copyright{} 2008, 2014 \> \hspace{.2in} Software Freedom Law Center. \\ \end{tabbing} \vspace{.1in} \begin{center} Authors of this part are: \\ Bradley M. Kuhn \\ Aaron Williamson \\ Karen M. Sandler \\ Copy editors of this part include: \\ Martin Michlmayr \vspace{.2in} The copyright holders of 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 \url{https://creativecommons.org/licenses/by-sa/4.0/legalcode}. \vfill This part includes material from many sources, including the following CC-By-SA-licensed published works: \\ \begin{itemize} \item \textit{The Practical Guide GPL Compliance}, by Bradley M. Kuhn and Aaron Williamson first published on 2008-08-20. \\ \item \textit{Software Freedom Law Center Guide to GPL Compliance, 2nd Edition}, written by Eben Moglen and Mishi Choudhary on 2014-10-31. \\ \end{itemize} However, this work is primarily composed of the many contributions it receives as a public, collaborative project. Please \href{https://gitorious.org/copyleft-org/tutorial/history/master:compliance-guide.tex}{review its Git logs} for full documentation of all contributions. \end{center} } \pagebreak \chapter*{Executive Summary} This is a guide to effective compliance with the GNU General Public License (GPL) and related licenses. Copyleft advocates usually seek to assist the community with GPL compliance cooperatively. This guide focuses on complying from the start, so that readers can learn to avoid enforcement actions entirely, or, at least, minimize the negative impact when enforcement actions occur. This guide introduces and explains basic legal concepts related to the GPL and its enforcement by copyright holders. It also outlines business practices and methods that lead to better GPL compliance. Finally, it recommends proper post-violation responses to the concerns of copyright holders. \chapter{Background} Copyright law grants exclusive rights to authors. Authors who chose copyleft seek to protect the freedom of users and developers to copy, share, modify and redistribute the software. However, copyleft is ultimately implemented through copyright, and the GPL is primarily and by default a copyright license. (See \S~\ref{explaining-copyright} for more about the interaction between copyright and copyleft.) Copyright law grants an unnatural exclusive control to copyright holders regarding copyright-controlled permissions related to the work. Therefore, copyright holders (or their agents) are the ultimately the sole authorities to enforce copyleft and protect the rights of users. Actions for copyright infringement are the ultimate legal mechanism for enforcement. Therefore, copyright holders, or collaborative groups of copyright holders, have historically been the actors in GPL enforcement. The earliest of these efforts began soon after the GPL was written by Richard M.~Stallman (RMS) in 1989, and consisted of informal community efforts, often in public Usenet discussions.\footnote{One example is the public outcry over NeXT's attempt to make the Objective-C front-end to GCC proprietary. RMS, in fact, handled this enforcement action personally and the Objective-C front-end is still part of upstream GCC today.} Over the next decade, the Free Software Foundation (FSF), which holds copyrights in many GNU programs, was the only visible entity actively enforcing its GPL'd copyrights on behalf of the software freedom community. FSF's enforcement was generally a private process; the FSF contacted violators confidentially and helped them to comply with the license. Most violations were pursued this way until the early 2000's. By that time, Linux-based systems such as GNU/Linux and BusyBox/Linux had become very common, particularly in embedded devices such as wireless routers. During this period, public ridicule of violators in the press and on Internet fora supplemented ongoing private enforcement and increased pressure on businesses to comply. In 2003, the FSF formalized its efforts into the GPL Compliance Lab, increased the volume of enforcement, and built community coalitions to encourage copyright holders to together settle amicably with violators. Beginning in 2004, Harald Welte took a more organized public enforcement approach and launched \href{http://gpl-violations.org/}{gpl-violations.org}, a website and mailing list for collecting reports of GPL violations. On the basis of these reports, Welte successfully pursued many enforcement actions in Europe, including formal legal action. Harald earns the permanent fame as the first copyright holder to bring legal action in a court regarding GPL compliance. In 2007, two copyright holders in BusyBox, in conjunction with the Software Freedom Conservancy (``Conservancy''), filed the first copyright infringement lawsuit based on a violation of the GPL\@ in the USA. While lawsuits are of course quite public, the vast majority of Conservancy's enforcement actions are resolved privately via cooperative communications with violators. As both FSF and Conservancy have worked to bring individual companies into compliance, both organizations have encountered numerous violations resulting from preventable problems such as inadequate attention to licensing of upstream software, misconceptions about the GPL's terms, and poor communication between software developers and their management. This document highlights these problems and describe best practices to encourage corporate Free Software users to reevaluate their approach to GPL'd software and avoid future violations. Both FSF and Conservancy continue GPL enforcement and compliance efforts for software under the GPL, the GNU Lesser Public License (LGPL) and other copyleft licenses. In doing so, both organizations have found that most violations stem from a few common, avoidable mistakes. All copyleft advocates hope to educate the community of commercial distributors, redistributors, and resellers on how to avoid violations in the first place, and to respond adequately and appropriately when a violation occurs. \section{Who Has Compliance Obligations?} All distributors of modified or unmodified versions of copylefted works unmodified versions of the works have compliance obligations. Common methods of modifying the works include innumerable common acts, such as: \begin{itemize} \item embedding those works as executable copies into a device, \item transferring a digital copy of executable copies to someone else, \item posting a patch to the copylefted software to a public mailing list. \end{itemize} Such distributors have obligations to (at least) the users to whom they (or intermediary parties) distribute those copies. In some cases, distributors have obligations to third parties not directly receiving their distribution of the works (depending on the distributors chosen licensing options, as described later in \S~\ref{binary-distribution-permission}). In addition, distributors have compliance obligations to upstream parties, such as preservation of reasonable legal notices embedded in the code, and appropriate labeling of modified versions. Online service providers and distributors alike have other compliance obligations. In general, they must refrain from imposing any additional restrictions on downstream parties. Most typically, such compliance problems arise from ``umbrella licenses:'' EULAs, or sublicenses that restrict downstream users' rights under copyleft. (See \S~\ref{GPLv2s6} and \S~\ref{GPLv3s10}). Patent holders having claims reading on GPL'd works they distribute must refrain from enforcing those claims against parties to whom they distribute. Furthermore, patent holders holding copyrights on GPLv3'd works must further grant an explicit patent license for any patent claims reading on the version they distributed, and therefore cannot enforce those specific patent claims against anyone making, using or selling a work based on their distributed version. All parties must refrain from acting as a provider of services or distributor of licensed works if they have accepted, or had imposed on them by judicial action, any legal conditions that would prevent them from meeting any obligation under GPL\@. (See \S~\ref{GPLv2s7}, \S~\ref{GPLv3s11} and \S~\ref{GPLv3s12}. \section{What Are The Risks of Non-Compliance?} Copyleft experts have for decades observed a significant mismatch between the assumptions most businesses make about copyleft compliance and the realities. Possibly due to excessive marketing of proprietary tools and services from the for-profit compliance industry, businesses perennially focus on the wrong concerns. This tutorial seeks to educate those businesses about what actually goes wrong, what causes disputes, and how to resolve those disputes. Many businesses currently invest undue resources to avoid unlikely risks that have low historical incidence of occurrence and low cost of remediation, while leaving unmanaged the risks that have historically resulted in all the litigation and other adverse outcomes. For example, some ``compliance industry''\footnote{``Compliance industry'' refers to third-party for-profit companies that market proprietary software tools and/or consulting services that purport to aid businesses with their Free Software license compliance obligations, such as those found in GPL and other copyleft licenses. This tutorial leaves the term in quotes throughout, primarily to communicate the skepticism most of this tutorial's authors feel regarding the mere existence of this industry. Not only do copyleft advocates object on principle to proprietary software tools in general, and to their ironic use specifically to comply with copyleft, but also to the ``compliance industry'' vendors' marketing messaging, which some copyleft advocates claim as a cause in the risk misassessments discussed herein. Bradley M.~Kuhn, specifically, regularly uses the term ``compliance industrial complex'' \href{http://en.wikipedia.org/wiki/Military-industrial_complex}{to analogize the types of problems in this industry to those warned against in the phrase of origin}.} vendors insist that great effort must be expended to carefully list, in the menus or manuals of embedded electronics products, copyright notices for every last copyright holder that contributed to the Free Software included in the product. While nearly all Free Software licenses, including copylefts like GPL, require preservation and display of copyright notices, failure to meet this specific requirement is trivially remedied. Therefore, businesses should spend just reasonable efforts to properly display copyright notices, and note that failure to do so is simply remedied: add the missing copyright notice! \section{Understanding Who's Enforcing} \label{compliance-understanding-whos-enforcing} The mismatch between actual compliance risk and compliance risk management typically results from a misunderstanding of licensor intentions. For-profit businesses often err by assuming other actors have kindred motivations. The primary enforcers of the GPL, however, have goals that for-profit businesses will find strange and perhaps downright alien. Specifically, community-oriented GPL enforcement organizations (called ``COGEOs'' throughout the remainder of this tutorial) are typically non-profit charities (such as the FSF and Software Freedom Conservancy) who declare, as part of their charitable mission, advancement of software freedom for all users. In the USA, these COGEOs are all classified as charitable under the IRS's 501(c)(3) designation, which is reserved for organizations that have a mission to enhance the public good. As such, these COGEOs enforce GPL primarily to pursue the policy goals and motivations discussed throughout this tutorial: to spread software freedom further. As such, COGEOs are unified in their primary goal to bring the violator back into compliance as quickly as possible, and redress the damage caused by the violation. COGEOs are steadfast in their position in a violation negotiation: comply with the license and respect freedom. Certainly, other entities do not share the full ethos of software freedom as institutionalized by COGEOs, and those entities pursue GPL violations differently. Oracle, a company that produces the GPL'd MySQL database, upon discovering GPL violations typically negotiates a proprietary software license separately for a fee. While this practice is not one a COGEO would undertaking nor endorsing, a copyleft license technically permits this behavior. To put a finer point on this practice already discussed in~\S~\ref{Proprietary Relicensing}, copyleft advocates usually find copyleft enforcement efforts focused on extract alternative proprietary licenses distasteful at best, and a corrupt manipulation of copyleft at worst. Much to the advocates' chagrin, such for-profit enforcement efforts seem to increase rather than decrease. Thus, unsurprisingly, for-profit adopters of GPL'd software often incorrectly assume that all copyright holders seek royalties. Businesses therefore focus on the risk of so-called ``accidental'' (typically as the result of unsupervised activity by individual programmers) infringe copyright by incorporating ``snippets'' of copylefted code into their own proprietary computer program. ``Compliance industry'' flagship products, therefore, focus on ``code scanning'' services that purport to detect accidental inclusions. Such effort focuses on proprietary software development and view Free Software as a foreign interloper. Such approach not only ignores current reality that many companies build their products directly on major copylefted projects (e.g., Android vendor's use of the kernel named Linux), but also creates a culture of fear among developers, leading them into a downward spiral of further hiding their necessary reliance on copylefted software in the company's products. Fortunately, COGEOs regard GPL compliance failures as an opportunity to improve compliance. Every compliance failure downstream represents a loss of rights by their users. The COGEOs are the guardian of its users' and developers' rights. Their activity seeks to restore those rights, and to protect the project's contributors' intentions in the making of their software. \chapter{Best Practices to Avoid Common Violations} \label{best-practices} Unlike highly permissive licenses (such as the ISC license), which typically only require preservation of copyright notices, licensees face many important requirements from the GPL. These requirements are carefully designed to uphold certain values and standards of the software freedom community. While the GPL's requirements may initially appear counter-intuitive to those more familiar with proprietary software licenses, by comparison, its terms are in fact clear and quite favorable to licensees. Indeed, the GPL's terms actually simplify compliance when violations occur. GPL violations occur (or, are compounded) most often when companies lack sound practices for the incorporation of GPL'd components into their internal development environment. This section introduces some best practices for software tool selection, integration and distribution, inspired by and congruent with software freedom methodologies. Companies should establish such practices before building a product based on GPL'd software.\footnote{This document addresses compliance with GPLv2, GPLv3, LGPLv2, and LGPLv3. Advice on avoiding the most common errors differs little for compliance with these four licenses. \S~\ref{lgpl} discusses the key differences between GPL and LGPL compliance.} \section{Evaluate License Applicability} \label{derivative-works} Political discussion about the GPL often centers around determining the ``work'' that must be licensed under GPL, or in other words, ``what is the derivative and/or combined work that was created''. Nearly ever esoteric question asked by lawyers seek to consider that question \footnote{\tutorialpartsplit{In fact, a companion work, \textit{Detailed Analysis of the GNU GPL and Related Licenses} contains an entire section discussing derivative works}{This tutorial in fact also addresses the issue at length in~\S~\ref{derivative-works}}.} (perhaps because that question explores exciting legal issues while the majority of the GPL deals with much more mundane ones). Of course, GPL was designed primarily to embody the licensing feature of copyleft. However, most companies who add complex features to and make combinations with GPL'd software are already well aware of their more complex obligations under the license that require complex legal analysis. And, there are few companies overall that engage in such activities. Thus, in practical reality, this issue is not relevant to the vast majority of companies distributing GPL'd software. Thus, experienced GPL enforcers find that few redistributors' compliance challenges relate directly to combined work issues in copyleft. Instead, the distributions of GPL'd systems most often encountered typically consist of a full operating system including components under the GPL (e.g., Linux, BusyBox) and components under the LGPL (e.g., the GNU C Library). Sometimes, these programs have been patched or slightly improved by direct modification of their sources, and thus the result is unequivocally a modified version. Alongside these programs, companies often distribute fully independent, proprietary programs, developed from scratch, which are designed to run on the Free Software operating system but do not combine with, link to, modify, derive from, or otherwise create a combined work with the GPL'd components.\footnote{However, these programs do often combine with LGPL'd libraries. This is discussed in detail in \S~\ref{lgpl}.} In the latter case, where the work is unquestionably a separate work of creative expression, no copyleft provisions are invoked. The core compliance issue faced, thus, in such a situation, is not an discussion of what is or is not a combined, derivative, and/or modified version of the work, but rather, issues related to distribution and conveyance of binary works based on GPL'd source, but without Complete, Corresponding Source. As such, issues of software delivery are the primary frustration for GPL enforcers. In particular, the following short list accounts for at least 95\% of the GPL violations ever encountered: \begin{itemize} \item The violator fails to provide required information about the presence of copylefted programs and their applicable license terms in the product they have purchased. \item The violator fails to reliably deliver \hyperref[CCS Definition]{complete, corresponding source} (CCS) for copylefted programs the violator knew were included (i.e., the CCS is either delivered but incomplete, or is not delivered at all). \item Requestors are ignored when they communicate with violator's published addresses requesting fulfillment of businesses' obligations. \end{itemize} This tutorial therefore focuses primarily on these issue. Admittedly, a tiny minority of compliance situations relate to question of derivative, combined, or modified versions of the work. Those situations are so rare, and the details from situation to situation differ greatly. Thus, such situations require a highly fact-dependent analysis and cannot be addressed in a general-purpose document such as this one. \medskip Most companies accused of violations lack a basic understanding of how to comply even in the straightforward scenario. This document provides those companies with the fundamental and generally applicable prerequisite knowledge. For answers to rarer and more complicated legal questions, such as whether your software is a derivative or combined work of some copylefted software, consult with an attorney.\footnote{If you would like more information on the application of derivative works doctrine to software, a detailed legal discussion is presented in our colleague Dan Ravicher's article, \textit{Software Derivative Work: A Circuit Dependent Determination} and in \tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related Licenses}'s Section on derivative works}{\S~\ref{derivative-works} of this tutorial}.} This discussion thus assumes that you have already identified the ``work'' covered by the license, and that any components not under the GPL (e.g., applications written entirely by your developers that merely happen to run on a Linux-based operating system) distributed in conjunction with those works are separate works within the meaning of copyright law and the GPL\@. In such a case, the GPL requires you to provide complete corresponding source (CCS)\footnote{For more on CCS, see \tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related Licenses}'s Section on GPLv2~\S2 and GPLv3~\S1.}{\S~\ref{GPLv2s2} and \S~\ref{GPLv3s1} of this tutorial}.} for the GPL'd components and your modifications thereto, but not for independent proprietary applications. The procedures described in this document address this typical scenario. \section{Monitor Software Acquisition} Software engineers deserve the freedom to innovate and import useful software components to improve products. However, along with that freedom should come rules and reporting procedures to make sure that you are aware of what software that you include with your product. The most typical response to an initial enforcement action is: ``We didn't know there was GPL'd stuff in there''. This answer indicates failure in the software acquisition and procurement process. Integration of third-party proprietary software typically requires a formal arrangement and management/legal oversight before the developers incorporate the software. By contrast, developers often obtain and integrate Free Software without intervention nor oversight. That ease of acquisition, however, does not mean the oversight is any less necessary. Just as your legal and/or management team negotiates terms for inclusion of any proprietary software, they should gently facilitate all decisions to bring Free Software into your product. Simple, engineering-oriented rules help provide a stable foundation for Free Software integration. For example, simply ask your software developers to send an email to a standard place describing each new Free Software component they add to the system, and have them include a brief description of how they will incorporate it into the product. Further, make sure developers use a revision control system (such as Git or Mercurial), and store the upstream versions of all software in a ``vendor branch'' or similar mechanism, whereby they can easily track and find the main version of the software and, separately, any local changes. Such procedures are best instituted at your project's launch. Once chaotic and poorly-sourced development processes begin, cataloging the presence of GPL'd components becomes challenging. Such a situation often requires use of a tool to ``catch up'' your knowledge about what software your product includes. Most commonly, companies choose some software licensing scanning tool to inspect the codebase. However, there are few tools that are themselves Free Software. Thus, GPL enforcers usually recommend the GPL'd \href{http://fossology.org/}{FOSSology system}, which analyzes a source code base and produces a list of Free Software licenses that may apply to the code. FOSSology can help you build a catalog of the sources you have already used to build your product. You can then expand that into a more structured inventory and process. \section{Track Your Changes and Releases} As explained in further detail below, the most important component of GPL compliance is the one most often ignored: proper inclusion of CCS in all distributions of GPL'd software. To comply with GPL's CCS requirements, the distributor \textit{must} always know precisely what sources generated a given binary distribution. In an unfortunately large number of our enforcement cases, the violating company's engineering team had difficulty reconstructing the CCS for binaries distributed by the company. Here are three simple rules to follow to decrease the likelihood of this occurrence: \begin{itemize} \item Ensure that your developers are using revision control systems properly. \item Have developers mark or ``tag'' the full source tree corresponding to builds distributed to customers. \item Check that your developers store all parts of the software development in the revision control system, including {\sc readme}s, build scripts, engineers' notes, and documentation. \end{itemize} Your developers will benefit anyway from these rules. Developers will be happier in their jobs if their tools already track the precise version of source that corresponds to any deployed binary. \section{Avoid the ``Build Guru''} Too many software projects rely on only one or a very few team members who know how to build and assemble the final released product. Such knowledge centralization not only creates engineering redundancy issues, but also thwarts GPL compliance. Specifically, CCS does not just require source code, but scripts and other material that explain how to control compilation and installation of the executable and object code. Thus, avoid relying on a ``build guru'', a single developer who is the only one who knows how to produce your final product. Make sure the build process is well defined. Train every developer on the build process for the final binary distribution, including (in the case of embedded software) generating a final firmware image suitable for distribution to the customer. Require developers to use revision control for build processes. Make a rule that adding new components to the system without adequate build instructions (or better yet, scripts) is unacceptable engineering practice. \chapter{Details of Compliant Distribution} Distribution of GPL'd works has requirements; copyleft will not function without placing requirements on redistribution. However, some requirements are more likely to cause compliance difficult than others. This chapter\footnote{Note that this chapter refers heavily to specific provisions and language in \hyperref[GPLv2s3-full-text]{GPLv2\S3} and \hyperref[GPLv3s6-full-text]{GPLv3\S6}. It may be helpful to review \S~\ref{GPLv2s3} and \S~\ref{GPLv3s6} first, and then have a copy of each license open while reading this section.} explains some the specific requirements placed upon distributors of GPL'd software that redistributors are most likely to overlook, yielding compliance problems. First, \hyperref[GPLv2s1]{GPLv2\S1} and \hyperref[GPLv2s4]{GPLv2\S4} require that the full license text must accompany every distribution (either in source or binary form) of each licensed work. Strangely, this requirement is responsible for a surprisingly significant fraction of compliance errors; too often, physical products lack required information about the presence of GPL'd programs and the applicable license terms. Automated build processes can and should carry a copy of the license from the the source distribution into the final binary firmware package for embedded products. Such automation usually achieves compliance regarding license inclusion requirements\footnote{At least one COGEO recommends the \href{https://www.yoctoproject.org/}{Yocto Project}, since its engineers have designed such features into it build process.} \section{Binary Distribution Permission} \label{binary-distribution-permission} % be careful below, you cannot refill the \if section, so don't refill % this paragraph without care. The various versions of the GPL are copyright licenses that grant permission to make certain uses of software that are otherwise restricted by copyright law. This permission is conditioned upon compliance with the GPL's requirements. This section walks through the requirements (of both GPLv2 and GPLv3) that apply when you distribute GPL'd programs in binary (i.e., executable or object code) form, which is typical for embedded applications. Because a binary application derives from a program's original sources, you need permission from the copyright holder to distribute it. \S~3 of GPLv2 and \S~6 of GPLv3 contain the permissions and conditions related to binary distributions of GPL'd programs.\footnote{These sections cannot be fully understood in isolation; read the entire license thoroughly before focusing on any particular provision. However, once you have read and understood the entire license, look to these sections to guide compliance for binary distributions.} Failure to provide or offer CCS is the single largest failure mode leading to compliance disputes. GPL's binary distribution sections offer a choice of compliance methods, each of which we consider in turn. Each option refers to the ``Corresponding Source'' code for the binary distribution, which includes the source code from which the binary was produced. This abbreviated and simplified definition is sufficient for the binary distribution discussion in this section, but you may wish to refer back to this section after reading the thorough discussion of ``Corresponding Source'' that appears in \S~\ref{corresponding-source}. \subsection{Option (a): Source Alongside Binary} GPLv2~\S~3(a) and v3~\S~6(a) embody the easiest option for providing source code: including Corresponding Source with every binary distribution. While other options appear initially less onerous, this option invariably minimizes potential compliance problems, because when you distribute Corresponding Source with the binary, \emph{your GPL obligations are satisfied at the time of distribution}. This is not true of other options, and for this reason, we urge you to seriously consider this option. If you do not, you may extend the duration of your obligations far beyond your last binary distribution. Compliance under this option is straightforward. If you ship a product that includes binary copies of GPL'd software (e.g., in firmware, or on a hard drive, CD, or other permanent storage medium), you can store the Corresponding Source alongside the binaries. Alternatively, you can include the source on a CD or other removable storage medium in the box containing the product. GPLv2 refers to the various storage mechanisms as ``medi[a] customarily used for software interchange''. While the Internet has attained primacy as a means of software distribution where super-fast Internet connections are available, GPLv2 was written at a time when downloading software was not practical (and was often impossible). For much of the world, this condition has not changed since GPLv2's publication, and the Internet still cannot be considered ``a medium customary for software interchange''. GPLv3 clarifies this matter, requiring that source be ``fixed on a durable physical medium customarily used for software interchange''. This language affirms that option (a) requires binary redistributors to provide source on a physical medium. Please note that while selection of option (a) requires distribution on a physical medium, voluntary distribution via the Internet is very useful. This is discussed in detail in \S~\ref{offer-with-internet}. \subsection{Option (b): The Offer} \label{offer-for-source} Many distributors prefer to ship only an offer for source with the binary distribution, rather than the complete source package. This option has value when the cost of source distribution is a true per-unit cost. For example, this option might be a good choice for embedded products with permanent storage too small to fit the source, and which are not otherwise shipped with a CD but \emph{are} shipped with a manual or other printed material. However, this option increases the duration of your obligations dramatically. An offer for source must be good for three full years from your last binary distribution (under GPLv2), or your last binary or spare part distribution (under GPLv3). Your source code request and provisioning system must be designed to last much longer than your product life cycle. Thus, it also increases your compliance costs in the long run. In addition, if you are required to comply with the terms of GPLv2, you {\bf cannot} use a network service to provide the source code. For GPLv2, the source code offer is fulfilled only with physical media. This usually means that you must continue to produce an up-to-date ``source code CD'' for years after the product's end-of-life. \label{offer-with-internet} Under GPLv2, it is acceptable and advisable for your offer for source code to include an Internet link for downloadable source \emph{in addition} to offering source on a physical medium. This practice enables those with fast network connections to get the source more quickly, and typically decreases the number of physical media fulfillment requests. (GPLv3~\S~6(b) permits provision of source with a public network-accessible distribution only and no physical media. We discuss this in detail at the end of this section.) The following is a suggested compliant offer for source under GPLv2 (and is also acceptable for GPLv3) that you would include in your printed materials accompanying each binary distribution: \begin{quote} The software included in this product contains copyrighted software that is licensed under the GPL\@. A copy of that license is included in this document on page $X$\@. You may obtain the complete Corresponding Source code from us for a period of three years after our last shipment of this product, which will be no earlier than 2011-08-01, by sending a money order or check for \$5 to: \\ GPL Compliance Division \\ Our Company \\ Any Town, US 99999 \\ \\ Please write ``source for product $Y$'' in the memo line of your payment. You may also find a copy of the source at \url{http://www.example.com/sources/Y/}. This offer is valid to anyone in receipt of this information. \end{quote} There are a few important details about this offer. First, it requires a copying fee. GPLv2 permits ``a charge no more than your cost of physically performing source distribution''. This fee must be reasonable. If your cost of copying and mailing a CD is more than around \$10, you should perhaps find a cheaper CD stock and shipment method. It is simply not in your interest to try to overcharge the community. Abuse of this provision in order to make a for-profit enterprise of source code provision will likely trigger enforcement action. Second, note that the last line makes the offer valid to anyone who requests the source. This is because v2~\S~3(b) requires that offers be ``to give any third party'' a copy of the Corresponding Source. GPLv3 has a similar requirement, stating that an offer must be valid for ``anyone who possesses the object code''. These requirements indicated in v2~\S~3(c) and v3~\S~6(c) are so that noncommercial redistributors may pass these offers along with their distributions. Therefore, the offers must be valid not only to your customers, but also to anyone who received a copy of the binaries from them. Many distributors overlook this requirement and assume that they are only required to fulfill a request from their direct customers. The option to provide an offer for source rather than direct source distribution is a special benefit to companies equipped to handle a fulfillment process. GPLv2~\S~3(c) and GPLv3~\S~6(c) avoid burdening noncommercial, occasional redistributors with fulfillment request obligations by allowing them to pass along the offer for source as they received it. Note that commercial redistributors cannot avail themselves of the option (c) exception, and so while your offer for source must be good to anyone who receives the offer (under v2) or the object code (under v3), it \emph{cannot} extinguish the obligations of anyone who commercially redistributes your product. The license terms apply to anyone who distributes GPL'd software, regardless of whether they are the original distributor. Take the example of Vendor $V$, who develops a software platform from GPL'd sources for use in embedded devices. Manufacturer $M$ contracts with $V$ to install the software as firmware in $M$'s device. $V$ provides the software to $M$, along with a compliant offer for source. In this situation, $M$ cannot simply pass $V$'s offer for source along to its customers. $M$ also distributes the GPL'd software commercially, so $M$ too must comply with the GPL and provide source (or $M$'s \emph{own} offer for source) to $M$'s customers. This situation illustrates that the offer for source is often a poor choice for products that your customers will likely redistribute. If you include the source itself with the products, then your distribution to your customers is compliant, and their (unmodified) distribution to their customers is likewise compliant, because both include source. If you include only an offer for source, your distribution is compliant but your customer's distribution does not ``inherit'' that compliance, because they have not made their own offer to accompany their distribution. The terms related to the offer for source are quite different if you distribute under GPLv3. Under v3, you may make source available only over a network server, as long as it is available to the general public and remains active for three years from the last distribution of your product or related spare part. Accordingly, you may satisfy your fulfillment obligations via Internet-only distribution. This makes the ``offer for source'' option less troublesome for v3-only distributions, easing compliance for commercial redistributors. However, before you switch to a purely Internet-based fulfillment process, you must first confirm that you can actually distribute \emph{all} of the software under GPLv3. Some programs are indeed licensed under ``GPLv2, \emph{or any later version}'' (often abbreviated ``GPLv2-or-later''). Such licensing gives you the option to redistribute under GPLv3. However, a few popular programs are only licensed under GPLv2 and not ``or any later version'' (``GPLv2-only''). You cannot provide only Internet-based source request fulfillment for the latter programs. If you determine that all GPL'd works in your whole product allow upgrade to GPLv3 (or were already GPLv3'd to start), your offer for source may be as simple as this: \begin{quote} The software included in this product contains copyrighted software that is licensed under the GPLv3\@. A copy of that license is included in this document on page $X$\@. You may obtain the complete Corresponding Source code from us for a period of three years after our last shipment of this product and/or spare parts therefor, which will be no earlier than 2011-08-01, on our website at \url{http://www.example.com/sources/productnum/}. \end{quote} \medskip Under both GPLv2 and GPLv3, source offers must be accompanied by a copy of the license itself, either electronically or in print, with every distribution. Finally, it is unacceptable to use option (b) merely because you do not have Corresponding Source ready. We find that some companies choose this option because writing an offer is easy, but producing a source distribution as an afterthought to a hasty development process is difficult. The offer for source does not exist as a stop-gap solution for companies rushing to market with an out-of-compliance product. If you ship an offer for source with your product but cannot actually deliver \emph{immediately} on that offer when your customers request it, you should expect an enforcement action. \subsection{Option (c): Noncommercial Offers} As discussed in the last section, GPLv2~\S~3(c) and GPLv3~\S~6(c) apply only to noncommercial use. These options are not available to businesses distributing GPL'd software. Consequently, companies that redistribute software packaged for them by an upstream vendor cannot merely pass along the offer they received from the vendor; they must provide their own offer or corresponding source to their distributees. We talk in detail about upstream software providers in \S~\ref{upstream}. \subsection{Option 6(d) in GPLv3: Internet Distribution} Under GPLv2, your formal provisioning options for Corresponding Source ended with \S~3(c). But even under GPLv2, pure Internet source distribution was a common practice and generally considered to be compliant. GPLv2 mentions Internet-only distribution almost as aside in the language, in text at the end of the section after the three provisioning options are listed. To quote that part of GPLv2~\S~3: \begin{quote} If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. \end{quote} When that was written in 1991, Internet distribution of software was the exception, not the rule. Some FTP sites existed, but generally software was sent on magnetic tape or CDs. GPLv2 therefore mostly assumed that binary distribution happened on some physical media. By contrast, GPLv3~\S~6(d) explicitly gives an option for this practice that the community has historically considered GPLv2-compliant. Thus, you may fulfill your source-provision obligations by providing the source code in the same way and from the same location. When exercising this option, you are not obligated to ensure that users download the source when they download the binary, and you may use separate servers as needed to fulfill the requests as long as you make the source as accessible as the binary. However, you must ensure that users can easily find the source code at the time they download the binary. GPLv3~\S~6(d) thus clarifies a point that has caused confusion about source provision in v2. Indeed, many such important clarifications are included in v3 which together provide a compelling reason for authors and redistributors alike to adopt GPLv3. \subsection{Option 6(e) in GPLv3: Software Torrents} Peer-to-peer file sharing arose well after GPLv2 was written, and does not easily fit any of the v2 source provision options. GPLv3~\S~6(e) addresses this issue, explicitly allowing for distribution of source and binary together on a peer-to-peer file sharing network. If you distribute solely via peer-to-peer networks, you can exercise this option. However, peer-to-peer source distribution \emph{cannot} fulfill your source provision obligations for non-peer-to-peer binary distributions. Finally, you should ensure that binaries and source are equally seeded upon initial peer-to-peer distribution. \section{Preparing Corresponding Source} \label{corresponding-source} Most enforcement cases involve companies that have unfortunately not implemented procedures like our \S~\ref{best-practices} recommendations and have no source distribution arranged at all. These companies must work backwards from a binary distribution to come into compliance. Our recommendations in \S~\ref{best-practices} are designed to make it easy to construct a complete and Corresponding Source release from the outset. If you have followed those principles in your development, you can meet the following requirements with ease. If you have not, you may have substantial reconstruction work to do. \subsection{Assemble the Sources} For every binary that you produce, you should collect and maintain a copy of the sources from which it was built. A large system, such as an embedded firmware, will probably contain many GPL'd and LGPL'd components for which you will have to provide source. The binary distribution may also contain proprietary components which are separate and independent works that are covered by neither the GPL nor LGPL\@. The best way to separate out your sources is to have a subdirectory for each component in your system. You can then easily mark some of them as required for your Corresponding Source releases. Collecting subdirectories of GPL'd and LGPL'd components is the first step toward preparing your release. \subsection{Building the Sources} Few distributors, particularly of embedded systems, take care to read the actual definition of Corresponding Source in the GPL\@. Consider carefully the definition, from GPLv3: \begin{quote} The ``Corresponding Source'' for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. \end{quote} and the definition from GPLv2: \begin{quote} The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. \end{quote} Note that you must include ``scripts used to control compilation and installation of the executable'' and/or anything ``needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities''. These phrases are written to cover different types of build environments and systems. Therefore, the details of what you need to provide with regard to scripts and installation instructions vary depending on the software details. You must provide all information necessary such that someone generally skilled with computer systems could produce a binary similar to the one provided. Take as an example an embedded wireless device. Usually, a company distributes a firmware, which includes a binary copy of Linux\footnote{``Linux'' refers only to the kernel, not the larger system as a whole.} and a filesystem. That filesystem contains various binary programs, including some GPL'd binaries, alongside some proprietary binaries that are separate works (i.e., not derived from, nor based on freely-licensed sources). Consider what, in this case, constitutes adequate ``scripts to control compilation and installation'' or items ``needed to generate, install and run'' the GPL'd programs. Most importantly, you must provide some sort of roadmap that allows technically sophisticated users to build your software. This can be complicated in an embedded environment. If your developers use scripts to control the entire compilation and installation procedure, then you can simply provide those scripts to users along with the sources they act upon. Sometimes, however, scripts were never written (e.g., the information on how to build the binaries is locked up in the mind of your ``build guru''). In that case, we recommend that you write out build instructions in a natural language as a detailed, step-by-step {\sc readme}. No matter what you offer, you need to give those who receive source a clear path from your sources to binaries similar to the ones you ship. If you ship a firmware (kernel plus filesystem), and the filesystem contains binaries of GPL'd programs, then you should provide whatever is necessary to enable a reasonably skilled user to build any given GPL'd source program (and modified versions thereof), and replace the given binary in your filesystem. If the kernel is Linux, then the users must have the instructions to do the same with the kernel. The best way to achieve this is to make available to your users whatever scripts or process your engineers would use to do the same. These are the general details for how installation instructions work. Details about what differs when the work is licensed under LGPL is discussed in \S~\ref{lgpl}, and specific details that are unique to GPLv3's installation instructions are in \S~\ref{user-products}. \subsection{What About the Compiler?} The GPL contains no provision that requires distribution of the compiler used to build the software. While companies are encouraged to make it as easy as possible for their users to build the sources, inclusion of the compiler itself is not normally considered mandatory. The Corresponding Source definition -- both in GPLv2 and GPLv3 -- has not been typically read to include the compiler itself, but rather things like makefiles, build scripts, and packaging scripts. Nonetheless, in the interest of goodwill and the spirit of the GPL, most companies do provide the compiler itself when they are able, particularly when the compiler is based on GCC\@ or another copylefted compiler. If you have a GCC-based system, it is your prerogative to redistribute that GCC version (binaries plus sources) to your customers. We in the software freedom community encourage you to do this, since it often makes it easier for users to exercise their software freedom. However, if you chose to take this recommendation, ensure that your GCC distribution is itself compliant. If you have used a proprietary, third-party compiler to build the software, then you probably cannot ship it to your customers. We consider the name of the compiler, its exact version number, and where it can be acquired as information that \emph{must} be provided as part of the Corresponding Source. This information is essential to anyone who wishes to produce a binary. It is not the intent of the GPL to require you to distribute third-party software tools to your customer (provided the tools themselves are not based on the GPL'd software shipped), but we do believe it requires that you give the user all the essential non-proprietary facts that you had at your disposal to build the software. Therefore, if you choose not to distribute the compiler, you should include a {\sc readme} about where you got it, what version it was, and who to contact to acquire it, regardless of whether your compiler is Free Software, proprietary, or internally developed. \section{Best Practices and Corresponding Source} \S~\ref{best-practices} and \S~\ref{corresponding-source} above are closely related. If you follow the best practices outlined above, you will find that preparing your Corresponding Source release is an easier task, perhaps even a trivial one. Indeed, the enforcement process itself has historically been useful to software development teams. Development on a deadline can lead organizations to cut corners in a way that negatively impacts its development processes. We have frequently been told by violators that they experience difficulty when determining the exact source for a binary in production (in some cases because their ``build guru'' quit during the release cycle). When management rushes a development team to ship a release, they are less likely to keep release sources tagged and build systems well documented. We suggest that, if contacted about a violation, product builders use GPL enforcement as an opportunity to improve their development practices. No developer would argue that their system is better for having a mysterious build system and no source tracking. Address these issues by installing a revision system, telling your developers to use it, and requiring your build guru to document his or her work! \section{Non-Technical Compliance Issues} Certainly, the overwhelming majority of compliance issues are, in fact, either procedural or technical. Thus, the primary material in this chapter so far has covered those issues. However, a few compliance issues do require more direct consideration of a legal situation. This portion guide does not consider those in detail, as a careful reading of the earlier chapters of Part~\ref{gpl-lgpl-part} shows various places where legal considerations are necessary for considering compliance activity. For example, specific compliance issues related to \hyperref[GPLv2s7]{GPLv2\S7}, \hyperref[GPLv3s7]{GPLv3\S7}, and \hyperref[GPLv3s7]{GPLv3\S11} demand a more traditional approach to legal license compliance. Of course, such analysis and consideration can be complicated, and some are considered in the enforcement case studies that follow in the next part. However, compliance issues related to such sections are not rare, and, as is typical, no specific training is available for dealing with extremely rare occurrences. \section{Self-Assessment of Compliance} Most companies that adopt copylefted software believe they have complied. Humans usually have difficult admitting their own mistakes, particularly systematic ones. Therefore, perhaps the most important necessary step to stay in compliance is a company's regular evaluation of their own compliance. First, exercise a request CCS for all copylefted works from all your upstream providers of software and of components embedding software. Then, perform your own CCS check on this material first, and verify that it meets the requirements. This tutorial presents later a case study of a COGEO's CCS check in \S~\ref{pristine-example}, which you can emulate when examining their own CCS\@. Second, measure all copyleft compliance from the position of the users\footnote{Realizing of course that user very well may not be your own customer.} downstream from you exercising their rights under GPL\@. Have those users received notice of the copylefted software included in your product? Is CCS available to the users easily (preferably by automated means)? Ask yourself these questions frequently. If you cannot answer these questions with certainty in the positive, dig deeper and modify your process. Avoid ``compliance industry'' marketing distractions and concentrate on the copylefted software you already know is in your product. Historically, the risk from a copylefted code snippet that some programmer dropped in your proprietary product careless of the consequences is a problem far more infrequent and less difficult to resolve. Efficient management of the risks of higher concern lies in making sure you can provide, for example, precisely CCS for a copy of Coreboot, the kernel named Linux, BusyBox, or GNU tar that you included in a product your company shipped two years ago than in the risk of 10 lines of GPL'd Java code an engineer accidentally pasted into the source of your ERP system. Thus, reject the ``compliance industry'' suggestions that code scanners find and help solve fundamental compliance problems. Consider how COGEO's tend to use code scanners. FOSSology is indeed an important part of a violation investigation, but such is the last step and catches only some (usually minor) licensing notice problems. Thus, code scanners can help solve minor compliance problems once you have resolved the major ones. Code scanners do not manage risk. \chapter{When The Letter Comes} Unfortunately, many GPL violators ignore their obligations until they are contacted by a copyright holder or the lawyer of a copyright holder. You should certainly contact your own lawyer if you have received a letter alleging that you have infringed copyrights that were licensed to you under the GPL\@. This section outlines a typical enforcement case and provides some guidelines for response. These discussions are generalizations and do not all apply to every alleged violation. However, COGEO's in particular universally follow the processes described herein. \section{Communication Is Key} GPL violations are typically only escalated when a company ignores the copyright holder's initial communication or fails to work toward timely compliance. Accused violators should respond very promptly to the initial request. As the process continues, violators should follow up weekly with the copyright holders to make sure everyone agrees on targets and deadlines for resolving the situation. Ensure that any staff who might receive communications regarding alleged GPL violations understands how to channel the communication appropriately within your organization. Often, initial contact is addressed for general correspondence (e.g., by mail to corporate headquarters or by e-mail to general informational or support-related addresses). Train the staff that processes such communications to escalate them to someone with authority to take action. An uninformed response to such an inquiry (e.g., from a first-level technical support person) can cause negotiations to fail prematurely. Answer promptly by multiple means (paper letter, telephone call, and email), even if your response merely notifies the sender that you are investigating the situation and will respond by a certain date. Do not let the conversation lapse until the situation is fully resolved. Proactively follow up with synchronous communication means to be sure communications sent by non-reliable means (such as email) were received. Remember that the software freedom community generally values open communication and cooperation, and these values extend to GPL enforcement. You will generally find that software freedom developers and their lawyers are willing to have a reasonable dialogue and will work with you to resolve a violation once you open the channels of communication in a friendly way. Furthermore, if the complaint comes from a COGEO, assume they are well-prepared. COGEO's fully investigate compliance issues before raising the issue. The claims and concerns will be substantiated, and immediate denials will likely lead the COGEO to suspect malice rather than honest mistake. However, the biggest and most perennial mistake that all COGEOs see during enforcement is this: failure to include the violators' software development teams in the enforcement discussions and negotiations. As described above, CCS verification and approval is the most time-consuming and difficult part of resolving most compliance matters. Without direct contact between software developers on both sides, the resolution of the technical issues involved in demonstrating that the binary distributed was built from the source provided is likely to be tortuous, expensive, and tense. Your lawyers will certainly be understandably reluctant to expose your employees to direct inquiry from potentially adverse parties. However, facilitated exchanges of information among software engineers communicating on technical subjects shortens the time to resolution, substantially reduces the cost of reaching resolution, and prevents unnecessary escalation due to mutual misunderstanding. Furthermore, such frank technical discussion will often be the only way to avoid compliance litigation once a violation has occurred. Fortunately, these frank discussions will improve your company's relationships. Free Software development communities improve software to benefit everyone, which includes you and your company. When you use copylefted community software in your products, you are part of that community. Therefore, resolving a compliance matter is an occasion to strengthen your relationship to the community, by increasing communication between your developers and the project whose work you use for business benefit. \section{Termination} Many redistributors overlook the GPL's termination provision (GPLv2~\S~4 and GPLv3~\S~8). Under v2, violators forfeit their rights to redistribute and modify the GPL'd software until those rights are explicitly reinstated by the copyright holder. In contrast, v3 allows violators to rapidly resolve some violations without consequence. If you have redistributed an application under GPLv2\footnote{This applies to all programs licensed to you under only GPLv2 (``GPLv2-only''). However, most so-called GPLv2 programs are actually distributed with permission to redistribute under GPLv2 \emph{or any later version of the GPL} (``GPLv2-or-later''). In the latter cases, the redistributor can choose to redistribute under GPLv2, GPLv3, GPLv2-or-later or even GPLv3-or-later. Where the redistributor has chosen v2 explicitly, the v2 termination provision will always apply. If the redistributor has chosen v3, the v3 termination provision will always apply. If the redistributor has chosen GPLv2-or-later, then the redistributor may want to narrow to GPLv3-only upon violation, to take advantage of the termination provisions in v3.}, but have violated the terms of GPLv2, you must request a reinstatement of rights from the copyright holders before making further distributions, or else cease distribution and modification of the software forever. Different copyright holders condition reinstatement upon different requirements, and these requirements can be (and often are) wholly independent of the GPL\@. The terms of your reinstatement will depend upon what you negotiate with the copyright holder of the GPL'd program. Since your rights under GPLv2 terminate automatically upon your initial violation, \emph{all your subsequent distributions} are violations and infringements of copyright. Therefore, even if you resolve a violation on your own, you must still seek a reinstatement of rights from the copyright holders whose licenses you violated, lest you remain liable for infringement for even compliant distributions made subsequent to the initial violation. GPLv3 is more lenient. If you have distributed only v3-licensed programs, you may be eligible under v3~\S~8 for automatic reinstatement of rights. You are eligible for automatic reinstatement when: \begin{itemize} \item you correct the violation and are not contacted by a copyright holder about the violation within sixty days after the correction, or \item you receive, from a copyright holder, your first-ever contact regarding a GPL violation, and you correct that violation within thirty days of receipt of copyright holder's notice. \end{itemize} In addition to these permanent reinstatements provided under v3, violators who voluntarily correct their violation also receive provisional permission to continue distributing until they receive contact from the copyright holder. If sixty days pass without contact, that reinstatement becomes permanent. Nonetheless, you should be prepared to cease distribution during those initial sixty days should you receive a termination notice from the copyright holder. Given that much discussion of v3 has focused on its so-called more complicated requirements, it should be noted that v3 is, in this regard, more favorable to violators than v2. However, note that most Linux-based systems typically include some software licensed under GPLv2-only, and thus the copyright holders have withheld permission to redistribute under terms of GPLv3. In larger aggregate distributions which include GPLv2-only works (such as the kernel named Linux), redistributors must operate as if termination is immediate and permanent, since the technological remove of GPLv2-only works from the larger distribution requires much more engineering work than the negotiation required to seek restoration of rights for distribution under GPLv2-only after permanent termination. \chapter{Standard Requests} \label{enforcement-standard-requests} As we noted above, different copyright holders have different requirements for reinstating a violator's distribution rights. Upon violation, you no longer have a license under the GPL\@. Copyright holders can therefore set their own requirements outside the license before reinstatement of rights. We have collected below a list of reinstatement demands that copyright holders often require. \begin{itemize} \item {\bf Compliance on all Free Software copyrights}. Copyright holders of Free Software often want a company to demonstrate compliance for all GPL'd software in a distribution, not just their own. A copyright holder may refuse to reinstate your right to distribute one program unless and until you comply with the licenses of all Free Software in your distribution. \item {\bf Notification to past recipients}. Users to whom you previously distributed non-compliant software should receive a communication (email, letter, bill insert, etc.) indicating the violation, describing their rights under the GPL, and informing them how to obtain a gratis source distribution. If a customer list does not exist (such as in reseller situations), an alternative form of notice may be required (such as a magazine advertisement). \item {\bf Appointment of a GPL Compliance Officer.} The software freedom community values personal accountability when things go wrong. Copyright holders often require that you name someone within the violating company officially responsible for Free Software license compliance, and that this individual serve as the key public contact for the community when compliance concerns arise. \item {\bf Periodic Compliance Reports.} Many copyright holders wish to monitor future compliance for some period of time after the violation. For some period, your company may be required to send regular reports on how many distributions of binary and source have occurred. \end{itemize} These are just a few possible requirements for reinstatement. In the context of a GPL violation, and particularly under v2's termination provision, the copyright holder may have a range of requests in exchange for reinstatement of rights. These software developers are talented professionals from whose work your company has benefited. Indeed, you are unlikely to find a better value or more generous license terms for similar software elsewhere. Treat the copyright holders with the same respect you treat your corporate partners and collaborators. \chapter{Special Topics in Compliance} There are several other issues that are less common, but also relevant in a GPL compliance situation. To those who face them, they tend to be of particular interest. \section{LGPL Compliance} \label{lgpl} GPL compliance and LGPL compliance mostly involve the same issues. As we discussed in \S~\ref{derivative-works}, questions of modified versions of software are highly fact-dependent and cannot be easily addressed in any overview document. The LGPL adds some additional complexity to the analysis. Namely, the various LGPL versions permit proprietary licensing of certain types of modified versions. These issues are discussed in greater detail in Chapter~\ref{LGPLv2} and~\ref{LGPLv3}. However, as a rule of thumb, once you have determined (in accordance with LGPLv3) what part of the work is the ``Application'' and what portions of the source are ``Minimal Corresponding Source'', then you can usually proceed to follow the GPL compliance rules that discussed above, replacing our discussion of ``Corresponding Source'' with ``Minimal Corresponding Source''. LGPL also requires that you provide a mechanism to combine the Application with a modified version of the library, and outlines some options for this. Also, the license of the whole work must permit ``reverse engineering for debugging such modifications'' to the library. Therefore, you should take care that the EULA used for the Application does not contradict this permission. Thus, under the terms of LGPL, you must refrain from license terms on works based on the licensed work that prohibit replacement of the licensed components of the larger non-LGPL'd work, or prohibit decompilation or reverse engineering in order to enhance or fix bugs in the LGPL'd components. LGPLv3 is not surprisingly easier to understand and examine from a compliance lens, since the FSF was influenced in LGPLv3's drafting by questions and comments on LGPLv2.1 over a period of years. Admittedly, LGPLv2.1 is still in wide use, and thus compliance with LGPLv2.1 remains a frequent topic you may encounter. The best advice there is careful study of Chapter~\ref{LGPLv2}. However, to repeat a key point here made within that chapter: Note though that, since the LGPLv2.1 can be easily upgraded to GPLv2-or-later, in the worst case you simply need to comply as if the software was licensed under GPLv2. The only reason you must consider the question of whether you have a ``work that uses the library'' or a ``work based on the library'' is when you wish to take advantage of the ``weak copyleft'' effect of the Lesser GPL\@. If GPLv2-or-later is an acceptable license (i.e., if you plan to copyleft the entire work anyway), you may find this an easier option. \section{Upstream Providers} \label{upstream} With ever-increasing frequency, software development (particularly for embedded devices) is outsourced to third parties. If you rely on an upstream provider for your software, note that you \emph{cannot ignore your GPL compliance requirements} simply because someone else packaged the software that you distribute. If you redistribute GPL'd software (which you do, whenever you ship a device with your upstream's software in it), you are bound by the terms of the GPL\@. No distribution (including redistribution) is permissible absent adherence to the license terms. Therefore, you should introduce a due diligence process into your software acquisition plans. This is much like the software-oriented recommendations we make in \S~\ref{best-practices}. Implementing practices to ensure that you are aware of what software is in your devices can only improve your general business processes. You should ask a clear list of questions of all your upstream providers and make sure the answers are complete and accurate. The following are examples of questions you should ask: \begin{itemize} \item What are all the licenses that cover the software in this device? \item From which upstream vendors, be they companies or individuals, did \emph{you} receive your software before distributing it to us? \item What are your GPL compliance procedures? \item If there is GPL'd software in your distribution, we will be redistributors of this GPL'd software. What mechanisms do you have in place to aid us with compliance? \item If we follow your recommended compliance procedures, will you formally indemnify us in case we are nonetheless found to be in violation of the GPL? \end{itemize} This last point is particularly important. Many GPL enforcement actions are escalated because of petty finger-pointing between the distributor and its upstream. In our experience, agreements regarding GPL compliance issues and procedures are rarely negotiated up front. However, when they are, violations are resolved much more smoothly (at least from the point of view of the redistributor). Consider the cost of potential violations in your acquisition process. Using Free Software allows software vendors to reduce costs significantly, but be wary of vendors who have done so without regard for the licenses. If your vendor's costs seem ``too good to be true,'' you may ultimately bear the burden of the vendor's inattention to GPL compliance. Ask the right questions, demand an account of your vendors' compliance procedures, and seek indemnity from them. In particular, any time your vendor incorporates copylefted software, you \textit{must} exercise your own rights as a user to request CCS for all the copylefted programs that your suppliers provided to you. Furthermore, you must ensure that CCS is correct and adequate yourself. Good vendors should help you do this, and make it easy. If those vendors cannot, pick a different vendor before proceeding with the product. \section{Mergers and Acquisitions} Often, larger companies often encounter copyleft licensing during a Mergers and Acquisitions (M\&A) process. Ultimately, a merger or acquisition causes all of the other company's problems to become yours. Therefore, for most concerns, the acquirer ``simply'' must apply the compliance analysis and methodologies discussed earlier across the acquired company's entire product line. Of course, this is not so simple, as such effort may be substantial, but a well-defined process for compliance investigation means the required work, while voluminous, is likely rote. A few sections of GPL require careful attention and legal analysis to determine the risk of acquisitions. Those handling M\&A issues should pay particular attention to the requirements of GPLv2~\S7 and GPLv3~\S10--12 --- focusing on how they relate to the acquired assets may be of particular importance. For example, GPLv3\S10 clarifies that in business acquisitions, whether by sale of assets or transfers of control, the acquiring party is downstream from the party acquired. This results in new automatic downstream licenses from upstream copyright holders, licenses to all modifications made by the acquired business, and rights to source code provisioning for the now-downstream purchaser. However, despite this aid given by explicit language in GPLv3, acquirers must still confirm compliance by the acquired (even if GPLv3\S10 does assert the the acquirers rights under GPL, that does not help if the acquired is out of compliance altogether). Furthermore, for fear of later reprisal by the acquirer if a GPL violation is later discovered in the acquired's product line, the acquired may need to seek a waiver and release of from additional damages beyond a requirement to comply fully (and a promise of rights restoration) if a GPL violation by the acquired is later uncovered during completion of the acquisition or thereafter. Finally, other advice available regarding handling of GPL compliance in an M\&A situation tends to ignore the most important issue: most essential copylefted software is not wholly copyrighted by the entities involved in the M\&A transaction. Therefore, copyleft obligations likely reach out to the customers of all entities involved, as well as to the original copyright holders of the copylefted work. As such, notwithstanding the two paragraphs in GPLv3\S10, the entities involved in M\&A should read the copyleft licenses through the lens of third parties whose software freedom rights under those licenses are of equal importance to then entities inside the transaction. \section{User Products and Installation Information} \label{user-products} GPLv3 requires you to provide ``Installation Information'' when v3 software is distributed in a ``User Product.'' During the drafting of v3, the debate over this requirement was contentious. However, the provision as it appears in the final license is reasonable and easy to understand. If you put GPLv3'd software into a User Product (as defined by the license) and \emph{you} have the ability to install modified versions onto that device, you must provide information that makes it possible for the user to install functioning, modified versions of the software. Note that if no one, including you, can install a modified version, this provision does not apply. For example, if the software is burned onto an non-field-upgradable ROM chip, and the only way that chip can be upgraded is by producing a new one via a hardware factory process, then it is acceptable that the users cannot electronically upgrade the software themselves. Furthermore, you are permitted to refuse support service, warranties, and software updates to a user who has installed a modified version. You may even forbid network access to devices that behave out of specification due to such modifications. Indeed, this permission fits clearly with usual industry practice. While it is impossible to provide a device that is completely unmodifiable\footnote{Consider that the iPhone, a device designed primarily to restrict users' freedom to modify it, was unlocked and modified within 48 hours of its release.}, users are generally on notice that they risk voiding their warranties and losing their update and support services when they make modifications.\footnote{A popular t-shirt in the software freedom community reads: ``I void warranties.''. Our community is well-known for modifying products with full knowledge of the consequences. GPLv3's ``Installation Instructions'' section merely confirms that reality, and makes sure GPL rights can be fully exercised, even if users exercise those rights at their own peril.} GPLv3 is in many ways better for distributors who seek some degree of device lock-down. Technical processes are always found for subverting any lock-down; pursuing it is a losing battle regardless. With GPLv3, unlike with GPLv2, the license gives you clear provisions that you can rely on when you are forced to cut off support, service or warranty for a customer who has chosen to modify. % FIXME-soon: write a full section on Javascript compliance. Here's a % potentially useful one-sentence introduction for such a % section. % Non-compliance with GPLv3 in the % distribution of Javascript on the Web is becoming more frequent %FIXME-soon: END \section{Beware The Consultant in Enforcers' Clothing} There are admittedly portions of the GPL enforcement community that function somewhat like the \href{http://en.wikipedia.org/wiki/Hacker_%28computer_security%29#Classifications}{computer security and network penetration testing hacker community}. By analogy, most COGEO's consider themselves \href{http://en.wikipedia.org/wiki/White_hat_%28computer_security%29}{white hats}, while some might appropriately call \hyperref[Proprietary Relicensing]{proprietary relicensing} by the name ``\href{http://en.wikipedia.org/wiki/Hacker_%28computer_security%29#Black_hat}{black hats}''. And, to finalize the analogy, there are indeed few \href{http://en.wikipedia.org/wiki/Grey_hat}{grey hat} GPL enforcers. Grey hat GPL enforcers usually have done some community-oriented GPL enforcement themselves, typically working as a volunteer for a COGEO, but make their living as a ``hired gun'' consultant to find GPL violations and offer to ``fix them'' for companies. Other such operators hold copyrights in some key piece of copylefted software and enforce as a mechanism to find out who is most likely to fund improvements on the software. A few companies report that they have formed beneficial consulting or employment relationships with developers they first encountered through enforcement. In some such cases, companies have worked with such consultants to alter the mode of use of the project's code in the company's products. More often in these cases, the communication channels opened in the course of the inquiry served other consulting purposes later. Feelings and opinions about this behavior are mixed within the larger copyleft community. Some see it as a reasonable business model and others renounce it as corrupt behavior. Regardless, a GPL violator should always immediately determine the motivations of the enforcer via documented, verifiable facts. For example, COGEOs such as the FSF and Conservancy have made substantial public commitments to enforce in a way that is uniform, transparent, and publicly documented. Furthermore, since these specific organizations are public charities in the USA, they are accountable to the IRS (and the public at large) in their annual Form 990 filings. Everyone may examine their revenue models and scrutinize their work. However, entities and individuals who do GPL enforcement centered primarily around a profit motive are likely the most dangerous enforcement entities for one simple reason: an agreement to comply fully with the GPL for past and future products --- always the paramount goal to COGEOs --- may not suffice as adequate resolution for a proprietary relicensing company or grey hat GPL enforcer. Therefore, violators must consider carefully who has made the enforcement inquiry and ask when and where the enforcer made public commitments and reports regarding their enforcement work and perhaps even ask the enforcer to directly mimic CEOGEO's detailed public disclosures and follow the \hyperref[enforcement-standard-requests]{standard requests for resolution} found in this document. \chapter{Conclusion} GPL compliance need not be an onerous process. Historically, struggles have been the result of poor development methodologies and communications, rather than any unexpected application of the GPL's source code disclosure requirements. Compliance is straightforward when the entirety of your enterprise is well-informed and well-coordinated. The receptionists should know how to route a GPL source request or accusation of infringement. The lawyers should know the basic provisions of Free Software licenses and your source disclosure requirements, and should explain those details to the software developers. The software developers should use a version control system that allows them to associate versions of source with distributed binaries, have a well-documented build process that anyone skilled in the art can understand, and inform the lawyers when they bring in new software. Managers should build systems and procedures that keep everyone on target. With these practices in place, any organization can comply with the GPL without serious effort, and receive the substantial benefits of good citizenship in the software freedom community, and lots of great code ready-made for their products. \vfill % LocalWords: redistributors NeXT's Slashdot Welte gpl ISC embedders BusyBox % LocalWords: someone's downloadable subdirectory subdirectories filesystem % LocalWords: roadmap README upstream's Ravicher's FOSSology readme CDs iPhone % LocalWords: makefiles violator's Michlmayr Stallman RMS GPL'd Harald LGPL %% LocalWords: GPL's resellers copylefted sublicenses GPLv unmanaged MySQL %% LocalWords: misassessments licensor COGEOs COGEO LGPLv CCS Requestors %% LocalWords: codebase Yocto distributees COGEO's Coreboot ERP reseller %% LocalWords: redistributor reinstatements decompilation acquired's grey %% LocalWords: upgradable unmodifiable Relicensing relicensing