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

  \tutorialpartsplit{\texit{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

\tutorialpartsplit{\texit{Detailed Analysis of the GNU GPL and Related

      Licenses}'s Section on GPLv2~\S2 and GPLv3~\S1.}{\S~\ref{GPLv2s2} and \S~\ref{GPLv3s1} of

    this tutorial}.

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}

In an unfortunately large number of our enforcement cases, the violating

company's engineering team had difficulty reconstructing the precise

sources for a given binary distributed by the company.  Ensure that your

developers are using revision control systems properly.  Have them mark or

tag the full source tree corresponding to builds distributed to customers.

Finally, 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.  Your developers will also

benefit from a system that tracks 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 it also

endangers GPL compliance, which requires you to provide build scripts.

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}

In this section, we explain 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.\footnote{For a full discussion of this concept, please see

\ifpdf

\href{http://www.softwarefreedom.org/resources/2008/foss-primer.html\#x1-40002}{the

  chapter entitled ``Common Copyright Questions''} in SFLC's publication,

\href{http://www.softwarefreedom.org/resources/2008/foss-primer.pdf}{\textit{A

    Legal Issues Primer for Open Source and Free Software Projects}}.

\else

\ifx \generateHTML \isGeneratingHTML

\href{http://www.softwarefreedom.org/resources/2008/foss-primer.html\#x1-40002}{the

  chapter entitled ``Common Copyright Questions''} in SFLC's publication

\href{http://www.softwarefreedom.org/resources/2008/foss-primer.html}{\textit{A

    Legal Issues Primer for Open Source and Free Software Projects}}.

\else

the chapter entitled ``Common Copyright Questions'' in SFLC's publication,

\textit{A Legal Issues Primer for Open Source and Free Software

  Projects}.

\fi

\fi

}

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