% compliance-guide.tex -*- LaTeX -*-
\part{A Practical Guide to GPL Compliance}
\label{gpl-compliance-guide}
{\parindent 0in
This part is: \\
\begin{tabbing}
Copyright \= \copyright{} 2014 \= \hspace{.2in} Bradley M. Kuhn. \\
Copyright \= \copyright{} 2014 \= \hspace{.2in} Free Software Foundation, Inc. \\
Copyright \> \copyright{} 2008 \> \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{3in}
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
\verb=https://creativecommons.org/licenses/by-sa/4.0/legalcode=.
\url{https://creativecommons.org/licenses/by-sa/4.0/legalcode}.
\end{center}
}
\bigskip
\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}
Early GPL enforcement 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 \verb0gpl-violations.org0, a website and mailing
approach and launched \url{gpl-violations.org}, 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. 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.
\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 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 invoking 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. Those interested in this issue should study
\tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related
Licenses}'s Section on derivative works}{\S~\ref{derivative-works} of
this tutorial}.}
However, 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. This tutorial therefore focuses primarily on that 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.
@@ -332,278 +332,278 @@ 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.
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.
\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:
is licensed under the GPLv3\@. A copy of that license is included in 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.
\url{http://www.example.com/sources/productnum/}.
\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:
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.
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\@.