diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml
index 0215fcf21a..98e5e59393 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -173,7 +173,7 @@
deficiency in the include file in the layer to which it originally belongs.
If this is the case, you need to address that deficiency instead of overlaying
the include file.
- For example, consider how Qt 4 database support plugins are configured.
+ For example, consider how Qt 4 database support plug-ins are configured.
The source directory does not have
MySQL or PostgreSQL, however OpenEmbedded's
layer meta-oe does.
@@ -1848,7 +1848,7 @@
$ bitbake -c cleanall linux-yocto
Never remove any files by hand from the tmp/deploy
- directory insided the build directory.
+ directory inside the build directory.
Always use the BitBake cleanall task to clear
out previous builds.Next, build the kernel image using this command:
@@ -2595,6 +2595,214 @@
+
+
+ Maintaining Open Source License Compliance During Your Product's Lifecycle
+
+
+ One of the concerns for a development organization using open source
+ software is how to maintain compliance with various open source
+ licensing during the lifecycle of the product.
+ While this section is not meant to be legal advice or to
+ comprehensively cover all scenarios, it is meant to
+ present methods that you can use to
+ meet the compliance requirements during a software
+ release.
+
+
+
+ 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:
+
+ Source code must be provided.
+ License text for the software must be
+ provided.
+ Compilation scripts and modifications to the
+ source code must be provided.
+
+
+ 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).
+
+
+
+ The remainder of this section describes methods supported to meet the
+ previously mentioned three requirements.
+ Once you take steps to meet these requirements,
+ and prior to releasing images, sources, and the build system,
+ you should audit all artifacts to ensure completeness.
+ The Yocto Project generates a license manifest during
+ image creation that is located
+ in ${DEPLOY_DIR}/licenses/<image_name-datestamp>
+ to assist with any audits.
+
+
+
+ Providing the Source Code
+
+
+ Compliance needs to begin when you generate the
+ final image.
+ The first thing you should look at is the requirement that
+ tops the list for most compliance groups - providing
+ the source.
+ The Yocto Project has a few ways of meeting this
+ requirement.
+
+
+
+ One of the easiest ways to meet this requirement is
+ to provide the entire
+ DL_DIR
+ 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.
+ But, the more serious issue for most companies is accidental
+ release of proprietary software.
+ The Yocto Project provides an archiver class to help.
+
+
+
+ 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.
+ You can do this by adding the following to the
+ local.conf file found in the
+ Build Directory:
+
+ ARCHIVER_MODE ?= "original"
+ ARCHIVER_CLASS = "${@'archive-${ARCHIVER_MODE}-source' if
+ ARCHIVER_MODE != 'none' else ''}"
+ INHERIT += "${ARCHIVER_CLASS}"
+ SOURCE_ARCHIVE_PACKAGE_TYPE = "tar"
+
+ During the creation of your image, all needed source
+ is placed within subdirectories of
+ DEPLOY_DIR/sources based on the
+ LICENSE
+ for each recipe.
+ Releasing an entire directory ensures compliance.
+ It is important to note that the size of the directory can
+ get large.
+
+
+
+ A way to help mitigate the size issue is to only release
+ tarballs for licenses that require the release of
+ source.
+ Let's assume you are only concerned with GPL code as
+ identified with the following:
+
+ $ cd poky/build/tmp/deploy/sources
+ $ mkdir ~/gpl_source_release
+ $ for x in `ls|grep GPL`; do cp -R $x/* ~/gpl_source_release; done
+
+ 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.
+
+
+
+
+ Providing License Text
+
+
+ One requirement that is often overlooked is inclusion
+ of license text.
+ This requirement also needs to be dealt with prior to
+ generating the final image.
+ Some licenses require the license text to accompany
+ the binary.
+ You can achieve this by adding the following to your
+ local.conf file:
+
+ COPY_LIC_MANIFEST = "1"
+ COPY_LIC_DIRS = "1"
+
+ Adding these statements to the configuration file ensures
+ that the licenses collected during package generation
+ are included on your image.
+
+
+
+
+ Providing Compilation Scripts and Source Code Modifications
+
+
+ At this point, we have addressed all we need to address
+ prior to generating the image.
+ The next two requirements are addressed during the final
+ packaging of the release.
+
+
+
+ Providing compilation scripts and source code modifications
+ can be addressed with one step.
+ All you need to do is ensure that you release the version of
+ the OpenEmbedded build system and the layers used during the build.
+
+
+
+ If the deployment team has a
+ BSP layer
+ 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.
+ One way of doing that is with a clean
+ checkout of the version of the Yocto Project and layers used
+ during your build.
+ Here is an example:
+
+ # We built using the &DISTRO_NAME; branch of the poky repo
+ $ git clone -b &DISTRO_NAME; git://git.yoctoproject.org/poky
+ $ cd poky
+ # We built using the release_branch for our layers
+ $ git clone -b release_branch git://git.mycompany.com/meta-my-bsp-layer
+ $ git clone -b release_branch git://git.mycompany.com/meta-my-software-layer
+ # clean up the .git repos
+ $ find . -name ".git" -type d -exec rm -rf {} \;
+
+ One thing a development organization might want to consider
+ for end-user convenience is to modify
+ meta-yocto/conf/bblayers.conf.sample to
+ ensure that when the end user utilizes the released build
+ system to build an image, the development organization's
+ layers are included in the bblayers.conf
+ file automatically:
+
+ # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
+ # changes incompatibly
+ LCONF_VERSION = "6"
+
+ BBPATH = "${TOPDIR}"
+ BBFILES ?= ""
+
+ BBLAYERS ?= " \
+ ##COREBASE##/meta \
+ ##COREBASE##/meta-yocto \
+ ##COREBASE##/meta-yocto-bsp \
+ ##COREBASE##/meta-my-bsp-layer \
+ ##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.
+
+
+