Maintaining Open Source License Compliance
Introduction
One of the concerns for a development organization using open source software is how to maintain compliance with various open-source licenses during the lifecycle of the product. While this section does not provide legal advice or comprehensively cover all scenarios, it does present methods that you can use to assist you in meeting the compliance requirements during a software release.
Even though this entry explains the know-how of keeping compliance for an Embedded Linux system, its guidelines could be applied for any Open Source software you are including in your project. To check about WinCE licensing and components included in the WinCE license from Toradex, check this post.
Embedded Linux Systems Built With Yocto Project
Toradex's images build system is based on OpenEmbedded/Yocto Project's, and overall offers infinite possibilities of creating your Embedded Linux image. 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, the requirements of the major FLOSS (Free-Libre / Open Source Software) licenses can begin to be covered by assuming that three main areas of concern exist:
1. Source code must be provided.
2. License text for the software must be provided.
3. 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).
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. 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.
This guide has been taken and adapted from the Yocto Project development manual. Make sure to check it from Yocto Project page if you have further doubts.
A minimal experience in building images with Yocto Project is advised as we will be referring to some of the folders and files used on it. You can read more about this from our complete guide of building images from Yocto Project.
Disclaimer: This guide is offered as a simple starting point in getting your license agreements set up. Make sure to seek proper legal advice if you need it.
Providing Source Code
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 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 the build and not just the source used in the released image. It will include a toolchain source, and other artifacts, which you would not generally release. However, the more serious issue for most companies is the accidental release of proprietary software. 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 a source. 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 source as a tarball. You can do this by adding the following to the local.conf file found in the Build Directory:
INHERIT += "archiver"
ARCHIVER_MODE[src] = "original"
During the creation of your image, the source from all recipes that deploy packages to the image is placed within subdirectories of DEPLOY_DIR/sources based on the LICENSE for each recipe. Releasing the entire directory enables you to comply with requirements concerning providing the unmodified source. 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 the source. Let us assume you are only concerned with GPL code as identified by running the following script:
# Script to archive a subset of packages matching specific license(s)
# Source and license files are copied into sub folders of package folder
# Must be run from build folder
#!/bin/bash
src_release_dir="source-release"
mkdir -p $src_release_dir
for a in deploy/sources/*; do
for d in $a/*; do
# Get package name from path
p=`basename $d`
p=${p%-*}
p=${p%-*}
# Only archive GPL packages (update *GPL* regex for your license check)
numfiles=`ls deploy/licenses/$p/*GPL* 2> /dev/null | wc -l`
if [ $numfiles -gt 1 ]; then
echo Archiving $p
mkdir -p $src_release_dir/$p/source
cp $d/* $src_release_dir/$p/source 2> /dev/null
mkdir -p $src_release_dir/$p/license
cp deploy/licenses/$p/* $src_release_dir/$p/license 2> /dev/null
fi
done
done
At this point, you could create a tarball from the gpl_source_release directory and provide that to the end user. This method would be a step toward achieving compliance with section 3a of GPLv2 and with section 6 of GPLv3.
Providing License Text
One requirement that is often overlooked is the 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"
LICENSE_CREATE_PACKAGE = "1"
Adding these statements to the configuration file ensures that the licenses collected during package generation are included on your image.
Setting all three variables to "1" results in the image having two copies of the same license file. One copy resides in /usr/share/common-licenses and the other resides in /usr/share/license
As the source archiver class has already archived the original unmodified source that contains 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.
Providing Compilation Scripts and Source Code Modifications
At this point, we have addressed all we need prior to generating the image. The next two requirements are addressed during the final packaging of the release.
By releasing the version of the OpenEmbedded build system and the layers used during the build, you will be providing both compilation scripts and the source code modifications in one step.
Toradex uses its own BSP layer in addition to what can be found as the reference package used by the Yocto Project (known as Poky). Since those layers are used to patch, compile, package, or modify (in any way) any open source software included in your released images, is very likely you will be required to release those layers under section 3 of GPLv2 or 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. Here is an example applied to Toradex OpenEmbedded repo:
$ mkdir oe-core
$ cd oe-core
$ repo init -u git://git.toradex.com/toradex-manifest.git -b kirkstone-6.x.y -m tdxref/default.xml
$ repo sync
# clean up the .git repos
$ find . -name ".git" -type d -exec rm -rf {} \;
$ cd .. && tar cvf sources.tar.gz
This applies to the base BSP layer from Toradex, but make sure to include any additional changes you made to your build system.