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.

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

does not mean the oversight is any less necessary.  Just as your legal

and/or management team negotiates terms for inclusion of any proprietary

product.

Simple, engineering-oriented rules help provide a stable foundation for

free software integration.  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.  Make sure they use a revision control system, 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 local changes made.

Such procedures are best instituted at your project's launch.  Once a

chaotic and poorly-sourced development process has begun, the challenges

of determining and cataloging the presence of GPL'd components is

difficult.  If you are in that situation, we recommend the

\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 we will explain in further detail below, the most important component