summaryrefslogtreecommitdiffstats
path: root/documentation
diff options
context:
space:
mode:
authorScott Rifenbark <scott.m.rifenbark@intel.com>2012-10-11 11:34:55 -0700
committerRichard Purdie <richard.purdie@linuxfoundation.org>2012-10-15 14:45:14 +0100
commitc75c152ec4aa6aef389aa6e01e999ab5702ca963 (patch)
treed846388afadf611911d359790c35748275dd8fa5 /documentation
parent3ec994ee3ea939b4fba7d2013ea6cf400aeae6ba (diff)
downloadpoky-c75c152ec4aa6aef389aa6e01e999ab5702ca963.tar.gz
documentation: dev-manual - Added license compliance section.
(From yocto-docs rev: a94b34506152f3494f1acce7b03318d3b5a0a283) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation')
-rw-r--r--documentation/dev-manual/dev-manual-common-tasks.xml212
1 files changed, 210 insertions, 2 deletions
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 @@
173 deficiency in the include file in the layer to which it originally belongs. 173 deficiency in the include file in the layer to which it originally belongs.
174 If this is the case, you need to address that deficiency instead of overlaying 174 If this is the case, you need to address that deficiency instead of overlaying
175 the include file. 175 the include file.
176 For example, consider how Qt 4 database support plugins are configured. 176 For example, consider how Qt 4 database support plug-ins are configured.
177 The source directory does not have 177 The source directory does not have
178 MySQL or PostgreSQL, however OpenEmbedded's 178 MySQL or PostgreSQL, however OpenEmbedded's
179 layer <filename>meta-oe</filename> does. 179 layer <filename>meta-oe</filename> does.
@@ -1848,7 +1848,7 @@
1848 $ bitbake -c cleanall linux-yocto 1848 $ bitbake -c cleanall linux-yocto
1849 </literallayout></para> 1849 </literallayout></para>
1850 <para><note>Never remove any files by hand from the <filename>tmp/deploy</filename> 1850 <para><note>Never remove any files by hand from the <filename>tmp/deploy</filename>
1851 directory insided the build directory. 1851 directory inside the build directory.
1852 Always use the BitBake <filename>cleanall</filename> task to clear 1852 Always use the BitBake <filename>cleanall</filename> task to clear
1853 out previous builds.</note></para></listitem> 1853 out previous builds.</note></para></listitem>
1854 <listitem><para>Next, build the kernel image using this command: 1854 <listitem><para>Next, build the kernel image using this command:
@@ -2595,6 +2595,214 @@
2595 </section> 2595 </section>
2596 </section> 2596 </section>
2597 </section> 2597 </section>
2598
2599 <section id='maintaining-open-source-license-compliance-during-your-products-lifecycle'>
2600 <title>Maintaining Open Source License Compliance During Your Product's Lifecycle</title>
2601
2602 <para>
2603 One of the concerns for a development organization using open source
2604 software is how to maintain compliance with various open source
2605 licensing during the lifecycle of the product.
2606 While this section is not meant to be legal advice or to
2607 comprehensively cover all scenarios, it is meant to
2608 present methods that you can use to
2609 meet the compliance requirements during a software
2610 release.
2611 </para>
2612
2613 <para>
2614 With hundreds of different open source licenses that the Yocto
2615 Project tracks, it is difficult to know the requirements of each
2616 and every license.
2617 However, we can cover the requirements of all of the known licenses, by
2618 assuming that there there are three main areas of concern:
2619 <itemizedlist>
2620 <listitem><para>Source code must be provided.</para></listitem>
2621 <listitem><para>License text for the software must be
2622 provided.</para></listitem>
2623 <listitem><para>Compilation scripts and modifications to the
2624 source code must be provided.
2625 </para></listitem>
2626 </itemizedlist>
2627 There are other requirements beyond the scope of these
2628 three and the methods described in this section
2629 (e.g. the mechanism through which source code is distributed).
2630 </para>
2631
2632 <para>
2633 The remainder of this section describes methods supported to meet the
2634 previously mentioned three requirements.
2635 Once you take steps to meet these requirements,
2636 and prior to releasing images, sources, and the build system,
2637 you should audit all artifacts to ensure completeness.
2638 The Yocto Project generates a license manifest during
2639 image creation that is located
2640 in <filename>${DEPLOY_DIR}/licenses/&lt;image_name-datestamp&gt;</filename>
2641 to assist with any audits.
2642 </para>
2643
2644 <section id='providing-the-source-code'>
2645 <title>Providing the Source Code</title>
2646
2647 <para>
2648 Compliance needs to begin when you generate the
2649 final image.
2650 The first thing you should look at is the requirement that
2651 tops the list for most compliance groups - providing
2652 the source.
2653 The Yocto Project has a few ways of meeting this
2654 requirement.
2655 </para>
2656
2657 <para>
2658 One of the easiest ways to meet this requirement is
2659 to provide the entire
2660 <ulink url='&YOCTO_DOCS_REF_URL;#var-DL_DIR'><filename>DL_DIR</filename></ulink>
2661 used by the build.
2662 This method, however, has a few issues.
2663 The most obvious is the size of the directory since it includes
2664 all sources used in teh build and not just the ones to be released.
2665 But, the more serious issue for most companies is accidental
2666 release of proprietary software.
2667 The Yocto Project provides an archiver class to help.
2668 </para>
2669
2670 <para>
2671 Before you employ <filename>DL_DIR</filename> or the
2672 archiver class, you need to decide how you choose to
2673 provide source.
2674 The source archiver class can generate tarballs
2675 and SRPMs and can create them with various levels of compliance.
2676 One way of doing this is to release just the original source
2677 as a tarball.
2678 You can do this by adding the following to the
2679 <filename>local.conf</filename> file found in the
2680 <link linkend='build-directory'>Build Directory</link>:
2681 <literallayout class='monospaced'>
2682 ARCHIVER_MODE ?= "original"
2683 ARCHIVER_CLASS = "${@'archive-${ARCHIVER_MODE}-source' if
2684 ARCHIVER_MODE != 'none' else ''}"
2685 INHERIT += "${ARCHIVER_CLASS}"
2686 SOURCE_ARCHIVE_PACKAGE_TYPE = "tar"
2687 </literallayout>
2688 During the creation of your image, all needed source
2689 is placed within subdirectories of
2690 <filename>DEPLOY_DIR/sources</filename> based on the
2691 <ulink url='&YOCTO_DOCS_REF_URL;#var-LICENSE'><filename>LICENSE</filename></ulink>
2692 for each recipe.
2693 Releasing an entire directory ensures compliance.
2694 It is important to note that the size of the directory can
2695 get large.
2696 </para>
2697
2698 <para>
2699 A way to help mitigate the size issue is to only release
2700 tarballs for licenses that require the release of
2701 source.
2702 Let's assume you are only concerned with GPL code as
2703 identified with the following:
2704 <literallayout class='monospaced'>
2705 $ cd poky/build/tmp/deploy/sources
2706 $ mkdir ~/gpl_source_release
2707 $ for x in `ls|grep GPL`; do cp -R $x/* ~/gpl_source_release; done
2708 </literallayout>
2709 At this point, you could create a tarball from the
2710 <filename>gpl_source_release</filename> directory and
2711 provide that to the end user.
2712 This method achieves full source compliance for GPL.
2713 </para>
2714 </section>
2715
2716 <section id='providing-license-text'>
2717 <title>Providing License Text</title>
2718
2719 <para>
2720 One requirement that is often overlooked is inclusion
2721 of license text.
2722 This requirement also needs to be dealt with prior to
2723 generating the final image.
2724 Some licenses require the license text to accompany
2725 the binary.
2726 You can achieve this by adding the following to your
2727 <filename>local.conf</filename> file:
2728 <literallayout class='monospaced'>
2729 COPY_LIC_MANIFEST = "1"
2730 COPY_LIC_DIRS = "1"
2731 </literallayout>
2732 Adding these statements to the configuration file ensures
2733 that the licenses collected during package generation
2734 are included on your image.
2735 </para>
2736 </section>
2737
2738 <section id='providing-compilation-scripts-and-source-code-modifications'>
2739 <title>Providing Compilation Scripts and Source Code Modifications</title>
2740
2741 <para>
2742 At this point, we have addressed all we need to address
2743 prior to generating the image.
2744 The next two requirements are addressed during the final
2745 packaging of the release.
2746 </para>
2747
2748 <para>
2749 Providing compilation scripts and source code modifications
2750 can be addressed with one step.
2751 All you need to do is ensure that you release the version of
2752 the OpenEmbedded build system and the layers used during the build.
2753 </para>
2754
2755 <para>
2756 If the deployment team has a
2757 <ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP layer</ulink>
2758 and a distro layer, and those those layers are used to patch,
2759 compile, package, or modify (in any way) any open source
2760 software included in your released images, you
2761 must release those layers.
2762 One way of doing that is with a clean
2763 checkout of the version of the Yocto Project and layers used
2764 during your build.
2765 Here is an example:
2766 <literallayout class='monospaced'>
2767 # We built using the &DISTRO_NAME; branch of the poky repo
2768 $ git clone -b &DISTRO_NAME; git://git.yoctoproject.org/poky
2769 $ cd poky
2770 # We built using the release_branch for our layers
2771 $ git clone -b release_branch git://git.mycompany.com/meta-my-bsp-layer
2772 $ git clone -b release_branch git://git.mycompany.com/meta-my-software-layer
2773 # clean up the .git repos
2774 $ find . -name ".git" -type d -exec rm -rf {} \;
2775 </literallayout>
2776 One thing a development organization might want to consider
2777 for end-user convenience is to modify
2778 <filename>meta-yocto/conf/bblayers.conf.sample</filename> to
2779 ensure that when the end user utilizes the released build
2780 system to build an image, the development organization's
2781 layers are included in the <filename>bblayers.conf</filename>
2782 file automatically:
2783 <literallayout class='monospaced'>
2784 # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
2785 # changes incompatibly
2786 LCONF_VERSION = "6"
2787
2788 BBPATH = "${TOPDIR}"
2789 BBFILES ?= ""
2790
2791 BBLAYERS ?= " \
2792 ##COREBASE##/meta \
2793 ##COREBASE##/meta-yocto \
2794 ##COREBASE##/meta-yocto-bsp \
2795 ##COREBASE##/meta-my-bsp-layer \
2796 ##COREBASE##/meta-my-software-layer \
2797 "
2798 </literallayout>
2799 Creating a tarball from the top-level
2800 <link linkend='source-directory'>Source Directory</link>
2801 (e.g. <filename>poky</filename>) at this point ensures
2802 that you include the scripts and the modifications.
2803 </para>
2804 </section>
2805 </section>
2598</chapter> 2806</chapter>
2599 2807
2600<!-- 2808<!--