\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

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