@@ -57,385 +57,385 @@ 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
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 has 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 mistakes that can be,
for the most part, easily avoided. 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 appear initially
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{While, 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 the copyleft provisions; this is
particularly true for most embedders. 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,
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 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.
Admittedly, a tiny
minority of situations which lie outside these two categories, and thus
do involve close questions about derivative and combined works. Those
situations admittedly do require a highly
fact-dependent analysis and cannot be addressed in a general-purpose
document, anyway.
\medskip
Most companies accused of violations lack a basic understanding
of how to comply even in the former 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
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
Licenses}'s Section on GPLv2~\S2 and GPLv3~\S1.}{\S~\ref{GPLv2s2} and \S~\ref{GPLv3s1} of
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 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, 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 occurance:
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}
This section explains 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.
\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.}
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.
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 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