documentation: dev-manual - edits to the license compliance section.

Implemented Beth Flanagan's review comments.

(From yocto-docs rev: d480c8525861db4383ce1b656168c01d01c26b2e)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

1 files changed, 33 insertions, 16 deletions

diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml
index 5ba1ff0173..fc7a535f85 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -2636,8 +2636,8 @@
             With hundreds of different open source licenses that the Yocto 
             Project tracks, it is difficult to know the requirements of each 
             and every license.
-            However, we can cover the requirements of all of the known licenses, by
-            assuming that there there are three main areas of concern:
+            However, we can begin to cover the requirements of the major FLOSS licenses, by
+            assuming that there are three main areas of concern:
             <itemizedlist>
                 <listitem><para>Source code must be provided.</para></listitem>
                 <listitem><para>License text for the software must be 
@@ -2649,6 +2649,10 @@
             There are other requirements beyond the scope of these
             three and the methods described in this section 
             (e.g. the mechanism through which source code is distributed).
+            As different organizations have different methods of complying with 
+            open source licensing, this section is not meant to imply that 
+            there is only one single way to meet your compliance obligations, 
+            but rather to describe one method of achieving compliance.
         </para>
 
         <para>
@@ -2667,7 +2671,7 @@
             <title>Providing the Source Code</title>
 
             <para>
-                Compliance needs to begin when you generate the 
+                Compliance activities should begin before you generate the 
                 final image. 
                 The first thing you should look at is the requirement that
                 tops the list for most compliance groups - providing
@@ -2683,20 +2687,24 @@
                 used by the build. 
                 This method, however, has a few issues.
                 The most obvious is the size of the directory since it includes
-                all sources used in teh build and not just the ones to be released. 
+                all sources used in the build and not just the source used in 
+                the released image. 
+                It will include toolchain source, and other artifacts which 
+                you would not generally release. 
                 But, the more serious issue for most companies is accidental 
                 release of proprietary software. 
-                The Yocto Project provides an archiver class to help.
+                The Yocto Project provides an archiver class to help avoid
+                some of these concerns.
             </para>
 
             <para>
                 Before you employ <filename>DL_DIR</filename> or the 
                 archiver class, you need to decide how you choose to
                 provide source. 
-                The source archiver class can generate tarballs 
-                and SRPMs and can create them with various levels of compliance. 
-                One way of doing this is to release just the original source 
-                as a tarball.
+                The source archiver class can generate tarballs and SRPMs 
+                and can create them with various levels of compliance in mind. 
+                One way of doing this (but certainly not the only way) is to 
+                release just the original source as a tarball.
                 You can do this by adding the following to the 
                 <filename>local.conf</filename> file found in the 
                 <link linkend='build-directory'>Build Directory</link>:
@@ -2712,7 +2720,8 @@
                 <filename>DEPLOY_DIR/sources</filename> based on the 
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-LICENSE'><filename>LICENSE</filename></ulink>
                 for each recipe. 
-                Releasing an entire directory ensures compliance.
+                Releasing the entire directory ensures compliance with 
+                requirements concerning providing the unmodified source.
                 It is important to note that the size of the directory can
                 get large. 
             </para>
@@ -2731,7 +2740,8 @@
                 At this point, you could create a tarball from the 
                 <filename>gpl_source_release</filename> directory and
                 provide that to the end user.
-                This method achieves full source compliance for GPL.
+                This method would be a step toward achieving compliance 
+                with section 3a of GPLv2 and with section 6 of GPLv3.
             </para>
         </section>
 
@@ -2754,6 +2764,11 @@
                 Adding these statements to the configuration file ensures
                 that the licenses collected during package generation
                 are included on your image.
+                As the source archiver has already archived the original 
+                unmodified source which would contain the license files, 
+                you would have already met the requirements for inclusion 
+                of the license information with source as defined by the GPL 
+                and other open source licenses.
             </para>
         </section>
 
@@ -2780,7 +2795,8 @@
                 and a distro layer, and those those layers are used to patch, 
                 compile, package, or modify (in any way) any open source 
                 software included in your released images, you
-                must release those layers. 
+                must release those layers as required by section 3 of GPLv2 
+                and section 1 of GPLv3. 
                 One way of doing that is with a clean
                 checkout of the version of the Yocto Project and layers used 
                 during your build.
@@ -2818,10 +2834,11 @@
        ##COREBASE##/meta-my-software-layer \
        "
                 </literallayout>
-                Creating a tarball from the top-level 
-                <link linkend='source-directory'>Source Directory</link>
-                (e.g. <filename>poky</filename>) at this point ensures
-                that you include the scripts and the modifications.
+                Creating and providing an archive of the 
+                <link linkend='source-directory'>Source Directory</link> 
+                (e.g. <filename>poky</filename>) ensures that you have met your 
+                requirements to include the scripts to control compilation 
+                as well as any modifications to the original source.
             </para>
         </section>
     </section>