In some cases, a BSP contains separately licensed Intellectual Property (IP) for a component or components. For these cases, you are required to accept the terms of a commercial or other type of license that requires some kind of explicit End User License Agreement (EULA). Once you accept the license, the OpenEmbedded build system can then build and include the corresponding component in the final BSP image. If the BSP is available as a pre-built image, you can download the image after agreeing to the license or EULA.
You could find that some separately licensed components that are essential for normal operation of the system might not have an unencumbered (or free) substitute. Without these essential components, the system would be non-functional. Then again, you might find that other licensed components that are simply 'good-to-have' or purely elective do have an unencumbered, free replacement component that you can use rather than agreeing to the separately licensed component. Even for components essential to the system, you might find an unencumbered component that is not identical but will work as a less-capable version of the licensed version in the BSP recipe.
For cases where you can substitute a free component and still maintain the system's functionality, the "DOWNLOADS" selection from the "SOFTWARE" tab on the Yocto Project website makes available de-featured BSPs that are completely free of any IP encumbrances. For these cases, you can use the substitution directly and without any further licensing requirements. If present, these fully de-featured BSPs are named appropriately different as compared to the names of their respective encumbered BSPs. If available, these substitutions are your simplest and most preferred options. Obviously, use of these substitutions assumes the resulting functionality meets system requirements.
A couple different methods exist within the OpenEmbedded build system to satisfy the licensing requirements for an encumbered BSP. The following list describes them in order of preference:
Use the
LICENSE_FLAGS
Variable to Define the Recipes that Have Commercial
or Other Types of Specially-Licensed Packages:
For each of those recipes, you can specify a
matching license string in a
local.conf
variable named
LICENSE_FLAGS_WHITELIST
.
Specifying the matching license string signifies
that you agree to the license.
Thus, the build system can build the corresponding
recipe and include the component in the image.
See the
"Enabling Commercially Licensed Recipes"
section in the Yocto Project Development Tasks
Manual for details on how to use these variables.
If you build as you normally would, without
specifying any recipes in the
LICENSE_FLAGS_WHITELIST
, the
build stops and provides you with the list of recipes
that you have tried to include in the image that
need entries in the
LICENSE_FLAGS_WHITELIST
.
Once you enter the appropriate license flags into
the whitelist, restart the build to continue where
it left off.
During the build, the prompt will not appear again
since you have satisfied the requirement.
Once the appropriate license flags are on the
white list in the
LICENSE_FLAGS_WHITELIST
variable,
you can build the encumbered image with no change
at all to the normal build process.
Get a Pre-Built Version of the BSP:
You can get this type of BSP by selecting the
"DOWNLOADS" item from the "SOFTWARE" tab on the
Yocto Project website.
You can download BSP tarballs that contain
proprietary components after agreeing to the
licensing requirements of each of the individually
encumbered packages as part of the download process.
Obtaining the BSP this way allows you to access an
encumbered image immediately after agreeing to the
click-through license agreements presented by the
website.
If you want to build the image yourself using
the recipes contained within the BSP tarball,
you will still need to create an appropriate
LICENSE_FLAGS_WHITELIST
to match the encumbered recipes in the BSP.