@@ -153,193 +153,193 @@ 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
\tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related
Licenses}'s Section on derivative works}{\S~\ref{derivative-works} of
this tutorial}.}
This discussion thus assumes that you have already identified the
``work'' covered by the license, and that any components not under the GPL
(e.g., applications written entirely by your developers that merely happen
to run on a Linux-based operating system) distributed in conjunction with
those works are separate works within the meaning of copyright law and the GPL\@. In
such a case, the GPL requires you to provide complete corresponding
source (CCS)\footnote{For more on CCS, see
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