@@ -201,97 +201,97 @@ 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}
As explained in further detail below, the most important component of GPL
compliance is the one most often ignored: proper inclusion of CCS in all
distributions of GPL'd
software. To comply with GPL's CCS requirements, the distributor
\textit{must} always know precisely what sources generated a given binary
distribution.
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:
follow to decrease the likelihood of this occurrence:
\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}