From 4a847c8abddad4f1b04e597a2154c187b17a4773 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Thu, 11 Oct 2012 11:34:55 -0700 Subject: documentation: dev-manual - Added license compliance section. (From yocto-docs rev: a94b34506152f3494f1acce7b03318d3b5a0a283) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- .../dev-manual/dev-manual-common-tasks.xml | 212 ++++++++++++++++++++- 1 file changed, 210 insertions(+), 2 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 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. + +
+