@@ -216,53 +216,54 @@ standard place describing each new Free Software component they add to the syste
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 we will explain in further detail below, the most important component
to maintaining GPL compliance is inclusion of the complete and
corresponding source code in any distributions that you make of GPL'd
software. Knowing at all times what sources generated a given binary
distribution is paramount.
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 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