Copyleft/guide Changeset - 6ac76d614f3c

Changeset - 6ac76d614f3c

Parent rev.

Child rev.

[Not reviewed]

0 1 0

Bradley Kuhn (bkuhn) - 10 years ago 2014-03-21 01:26:56
bkuhn@ebb.org

Wordsmith paragraph

1 file changed with 14 insertions and 8 deletions:

compliance-guide.tex

0 comments (0 inline, 0 general)

compliance-guide.tex

➞

Show inline comments

@@ ... / @@ -190,62 +190,68 @@ source (CCS)\footnote{For more on CCS, see @@
 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 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.  Ask your software developers to send an email to a
+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.  Make sure they use a revision control system, and have
 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 local changes made.
+of the software and, separately, any local changes.
 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
 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
+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.
 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''}

0 comments (0 inline, 0 general)