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 the license is accepted, 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" page from the Yocto Project website's 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 the respective encumbered BSPs. If available, these substitutions are your simplest and most preferred options. Use of these substitutions of course assumes the resulting functionality meets system requirements.
If however, a non-encumbered version is unavailable or it provides unsuitable functionality or quality, you can use an encumbered version.
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 Reference
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 visiting the
"Downloads" page of 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.
Note that 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.