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:

\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

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.

\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 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}.

\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:

\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.

\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\@.

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.

\subsection{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,