@@ -177,58 +177,58 @@ with an attorney.\footnote{If you would like more information on the
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 companies we contact about GPL violations often respond with: ``We
didn't know there was GPL'd stuff in there''. This answer indicates a
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, your developers often obtain and
integrate Free Software without intervention. The ease of acquisition, however,
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 be involved in all decisions to bring Free Software into your
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. 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