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