diff --git a/compliance-guide.tex b/compliance-guide.tex new file mode 100644 index 0000000000000000000000000000000000000000..828d5e3118e13ae8ed6cce064689c4f0cbaffd1c --- /dev/null +++ b/compliance-guide.tex @@ -0,0 +1,1016 @@ +\documentclass[letterpaper]{fixme} + +\title{A Practical Guide to GPL Compliance} +\titleformatted{A Practical Guide to GPL Compliance} +\date{August 26, 2008} + +\keywords{SFLC, software, freedom, law, center, free, open, source, gpl, compliance, violation} + +\subject{SFLC's guide to better compliance with the GPL and related FOSS Licenses} + +% The below is a horrible hack. What happens is that the HTML generator +% (tex4ht) freaks out when \\ is used in the author field. tex4ht seems +% to have some concept of ``author lists'' but I cannot figure out how to +% use this. I added this code here (and keep carrying it over from doc to +% doc) to get around that problem, but really it should be handled in the +% LaTeX class. -- bkuhn + +\ifx \generateHTML \isGeneratingHTML +\author{ + \Hnewline} +\else +\author{Bradley M. Kuhn \\ Aaron Williamson \\ Karen M. Sandler } +\fi + +\begin{document} + +\maketitle + +Copyright \copyright{} 2008, Software Freedom Law Center. Licensed +\href{http://creativecommons.org/licenses/by-sa/4.0/legalcode}{CC-BY-SA + 4.0 unported}. + +\section{Executive Summary} + +This is a guide to effective compliance with the GNU General Public +License (GPL) and related licenses. In accordance with the Software +Freedom Law Center's (SFLC's) philosophy of assisting the community with +GPL compliance cooperatively, this guide focuses on avoiding compliance +actions and minimizing the negative impact when enforcement actions occur. +It 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. + +\section{Background} + +Early GPL enforcement efforts began soon after the GPL was written by +Richard Stallman 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.} 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 community of +Free/Libre and Open Source Software (FOSS) developers. 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 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 \verb0gpl-violations.org0, a website and mailing +list for collecting reports of GPL violations. On the basis of these +reports, Welte successfully pursued many enforcements in Europe, including +formal legal action. + +In 2007, the SFLC filed the first U.S.~copyright infringement lawsuit +based on a violation of the GPL\@. While the lawsuits filed by SFLC on +behalf of its clients have been quite public, SFLC resolves the vast +majority of enforcement actions privately via +cooperative communications with violators. As we have worked to bring +individual companies into compliance, we 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. In this document, we highlight these problems and describe +best practices to encourage corporate users of FOSS to reevaluate their +approach to GPL'd software and avoid future violations. + +SFLC continues to conduct GPL enforcement and compliance efforts for many +of its clients who release their software under the GPL, the GNU Lesser +Public License (LGPL) and other copyleft licenses. In doing so, we have +found that most violations stem from a few common mistakes that can be, +for the most part, easily avoided. We 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{Best Practices to Avoid Common Violations} +\label{best-practices} + +Unlike highly permissive FOSS licenses (such as the ISC license), which +typically only require preservation of copyright notices, the GPL places a +number of important requirements upon licensees. These requirements are +carefully designed to uphold certain values and standards of the software +freedom community. While the GPL's requirements may appear initially +counter-intuitive to those more familiar with proprietary software +licenses, by comparison its terms are in fact clear and favorable to +licensees. The terms of the GPL actually simplify compliance when +violations occur. + +GPL violations are often caused or compounded by a failure to adopt sound +practices for the incorporation of GPL'd components into a company's +internal development environment. In this section, we introduce some best +practices for software tool selection, integration and distribution, +inspired by and congruent with FOSS methodologies. We suggest companies +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.} + +\subsection{Evaluate License Applicability} +\label{derivative-works} +Political discussion about the GPL often centers around the ``copyleft'' +requirements of the license. Indeed, the license was designed primarily +to embody this licensing feature. Most companies adding non-trivial +features (beyond mere porting and bug-fixing) to GPL'd software, and +thereby implicating these requirements, are already well aware of their +more complex obligations under the license.\footnote{There has been much legal + discussion regarding copyleft and derivative works. In practical + reality, this issue is not relevant to the vast majority of companies + distributing GPL'd software.} + +However, in our experience with GPL enforcement, few redistributors' +compliance challenges relate directly to the copyleft provisions; this is +doubly true for most embedders. Instead, the distributions of GPL'd +systems that we encounter 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, +resulting unequivocally in a derivative work. Alongside these programs, +companies often distribute fully independent, proprietary programs, +developed from scratch, which are designed to run on the FOSS operating +system but do not combine with, link to, modify, or otherwise derive from +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 derivative work has been created. The tiny +minority of situations which lie outside these two categories, and thus +involve close questions about derivative works, require a highly +fact-dependent analysis and cannot be addressed in a general-purpose +document. + +Most companies accused of violations, however, lack a basic understanding +of how to comply even in the straightforward scenario. This document +provides that fundamental and generally applicable prerequisite knowledge. +For answers to rarer and more complicated legal questions, such as whether +your software is a derivative 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}.} + +For this discussion, we will assume 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. In +such a case, the GPL requires you to provide complete and corresponding +source 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. + +\subsection{Monitor Software Acquisition} + +Software engineers should have the freedom to innovate and import useful +software components to improve your product. However, along with that +freedom should come rules and reporting procedures to make sure that you +are aware of what software is being tested or included with your product. + +The companies we contact about GPL violations often respond with: ``We +didn't know there was GPL'd stuff in there''. This answer indicates a +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, your developers often obtain and +integrate FOSS without intervention. The 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 be involved in all decisions to bring FOSS into your +product. + +Simple, engineering-oriented rules help provide a stable foundation for +FOSS integration. Ask your software developers to send an email to a +standard place describing each new FOSS component they add to the system, +and have them include a brief description of how they will incorporate it +into the product. Make sure they use a revision control system, and have +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 local changes made. + +Such procedures are best instituted at your project's launch. Once a +chaotic and poorly-sourced development process has begun, the challenges +of determining and cataloging the presence of GPL'd components is +difficult. If you are in that situation, we recommend the +\href{http://fossology.org/}{Fossology system}, which analyzes a +source-code base and produces a list of FOSS 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. + +\subsection{Track Your Changes and Releases} + +As we will explain in further detail below, the most important component +to maintaining GPL compliance is inclusion of the complete and +corresponding source code in any distributions that you make of GPL'd +software. Knowing at all times what sources generated a given binary +distribution is paramount. + +In an unfortunately large number of our enforcement cases, the violating +company's engineering team had difficulty reconstructing the precise +sources for a given binary distributed by the company. Ensure that your +developers are using revision control systems properly. Have them mark or +tag the full source tree corresponding to builds distributed to customers. +Finally, 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. Your developers will also +benefit from a system that tracks the precise version of source that +corresponds to any deployed binary. + +\subsection{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 it also +endangers GPL compliance, which requires you to provide build scripts. + +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. + +\section{Details of Compliant Distribution} + +In this section, we explain the specific requirements placed upon +distributors of GPL'd software. Note that this section refers heavily to +specific provisions and language in +\href{http://www.gnu.org/licenses/old-licenses/gpl-2.0.html#section3}{GPLv2} +and \href{http://www.fsf.org/licensing/licenses/gpl.html#section6}{GPLv3}. +It may be helpful to have a copy of each license open while reading this +section. + +\subsection{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.\footnote{For a full discussion of this concept, please see +\ifpdf +\href{http://www.softwarefreedom.org/resources/2008/foss-primer.html\#x1-40002}{the + chapter entitled ``Common Copyright Questions''} in SFLC's publication, +\href{http://www.softwarefreedom.org/resources/2008/foss-primer.pdf}{\textit{A + Legal Issues Primer for Open Source and Free Software Projects}}. +\else +\ifx \generateHTML \isGeneratingHTML +\href{http://www.softwarefreedom.org/resources/2008/foss-primer.html\#x1-40002}{the + chapter entitled ``Common Copyright Questions''} in SFLC's publication +\href{http://www.softwarefreedom.org/resources/2008/foss-primer.html}{\textit{A + Legal Issues Primer for Open Source and Free Software Projects}}. +\else +the chapter entitled ``Common Copyright Questions'' in SFLC's publication, +\textit{A Legal Issues Primer for Open Source and Free Software + Projects}. +\fi +\fi +} +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.} + +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}. + +\subsubsection{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}. + +\subsubsection{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. + +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 +\verb0http://www.example.com/sources/Y/0. + +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 non-commercial 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 +\verb0http://www.example.com/sources/productnum/0. +\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 chose 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 receive it, you should expect an enforcement +action. + +\subsubsection{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 who 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}. + +\subsubsection{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. + +\subsubsection{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. + +\subsection{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. + +\subsubsection{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. + +\subsubsection{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 +FOSS 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}. + +\subsubsection{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 FOSS 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 FOSS +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 FOSS, proprietary, or +internally developed. + +\subsection{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{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. + +\subsection{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. We urge accused violators to respond very promptly to the +initial request. As the process continues, 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 unknowledgable 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 FOSS community generally values open communication and +cooperation, and these values extend to GPL enforcement. You will +generally find that FOSS 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. + +\subsection{Termination} + +Many redistributors overlook 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. + +\section{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 FOSS copyrights}. Copyright holders of FOSS + 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 FOSS 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 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 FOSS community + values personal accountability when things go wrong. Copyright holders + often require that you name someone within the violating company + officially responsible for FOSS 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. + +\section{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. + +\subsection{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-dependant 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 well beyond the +scope of this document, but 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 we +discussed, 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. + +\subsection{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 from 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 enforcements 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 FOSS 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. + +\subsection{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 FOSS 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. + +\section{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 FOSS 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 FOSS community, and lots of great code +ready-made for their products. + +\vfill + +\end{document} + +% 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