From e6bb30d96c785b0a1bdb3016d70d58265e49414f Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Fri, 12 Oct 2012 10:47:34 -0700 Subject: 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 Signed-off-by: Richard Purdie --- .../dev-manual/dev-manual-common-tasks.xml | 49 +++++++++++++++------- 1 file changed, 33 insertions(+), 16 deletions(-) (limited to 'documentation') 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: Source code must be provided. 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. @@ -2667,7 +2671,7 @@ Providing the Source Code - 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. Before you employ DL_DIR 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 local.conf file found in the Build Directory: @@ -2712,7 +2720,8 @@ DEPLOY_DIR/sources based on the LICENSE 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. @@ -2731,7 +2740,8 @@ At this point, you could create a tarball from the gpl_source_release 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. @@ -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. @@ -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 \ " - Creating a tarball from the top-level - Source Directory - (e.g. poky) at this point ensures - that you include the scripts and the modifications. + Creating and providing an archive of the + Source Directory + (e.g. poky) ensures that you have met your + requirements to include the scripts to control compilation + as well as any modifications to the original source. -- cgit v1.2.3-54-g00ecf