mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-05-30 00:20:08 +00:00
Code Issues Projects Releases Wiki Activity

documentation/bsp-guide/bsp.xml: Patch applied for Licensing

Browse Source 
"The LICENSE_FLAGS mechanism can now be used to meet the special
license requirements needed by some BSPs.  Update the documentation to
reflect the current BSP licensing mechanisms.

Also add a new blurb about the time-limited kernel."

                                  - Tom Zanussi

I applied this patch verbatim and will check and clean up text
as needed.

(From yocto-docs rev: d05a7ddbc0d6017e5a8be2b3e0117f53e30a204b)

Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Tom Zanussi
2012-03-22 07:20:52 -06:00
committed by Richard Purdie
parent 9332e39d86
commit 9d2974a31b
1 changed files with 93 additions and 103 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documentation/bsp-guide/bsp.xml
+93 -103
View File
@@ -656,135 +656,125 @@
</section> </section>
</section> </section>
<section id='bsp-click-through-licensing'> <section id='bsp-licensing'>
<title>BSP 'Click-Through' Licensing Procedure</title> <title>BSP Licensing Considerations</title>
<note> This section describes how
click-through licensing is expected to work.
Currently, this functionality is not yet implemented.
</note>
<para> <para>
In some cases, a BSP contains separately licensed IP In some cases, a BSP contains separately licensed IP
(Intellectual Property) for a component that imposes (Intellectual Property) for a component or components
upon the user a requirement to accept the terms of a that impose upon the user a requirement to accept the
'click-through' license. terms of a commercial or other type of license that
Once the license is accepted the requires some kind of explicit EULA (End User License
Yocto Project build system can then build and include the Agreement). Once the license is accepted the Yocto
corresponding component in the final BSP image. Project build system can then build and include the
Some affected components might be essential to the normal corresponding component in the final BSP image, or if
functioning of the system and have no 'free' replacement the BSP is available in the form of an already built
(i.e. the resulting system would be non-functional image, the user will be able to download the image after
without them). agreeing to the license or EULA.
On the other hand, other components might be simply </para>
'good-to-have' or purely elective, or if essential <para>
nonetheless have a 'free' (possibly less-capable) Some affected components might be essential to the
version that could be used as a in the BSP recipe. normal functioning of the system and have no 'free'
replacement (i.e. the resulting system would be
non-functional without them). On the other hand, other
components might be simply 'good-to-have' or purely
elective, or if essential nonetheless have a 'free'
(possibly less-capable) version that could be used as a
in the BSP recipe.
</para> </para>
<para> <para>
For cases where you can substitute something and still maintain functionality, For cases where you can substitute something and still
the Yocto Project website's maintain functionality, the Yocto Project website's
<ulink url='&YOCTO_HOME_URL;/download/all?keys=&amp;download_type=1&amp;download_version='>BSP Download Page</ulink> <ulink url='&YOCTO_HOME_URL;/download/all?keys=&amp;download_type=1&amp;download_version='>BSP
makes available 'de-featured' BSPs that are completely free of any IP encumbrances. Download Page</ulink> makes available 'de-featured' BSPs
For these cases you can use the substitution directly and without any further licensing that are completely free of any IP encumbrances. For
requirements. these cases you can use the substitution directly and
If present, these fully 'de-featured' BSPs are named appropriately different without any further licensing requirements. If present,
as compared to the names of the respective encumbered BSPs. these fully 'de-featured' BSPs are named appropriately
If available, these substitutions are the simplest and most preferred options. different as compared to the names of the respective
This, of course, assumes the resulting functionality meets requirements. encumbered BSPs. If available, these substitutions are
the simplest and most preferred options. This, of
course, assumes the resulting functionality meets
requirements.
</para> </para>
<para> <para>
If however, a non-encumbered version is unavailable or the 'free' version If however, a non-encumbered version is unavailable or
would provide unsuitable functionality or quality, you can use the 'free' version would provide unsuitable
an encumbered version. functionality or quality, you can use an encumbered
version.
</para> </para>
<para> <para> A couple different methods exist within the Yocto
Several methods exist within the Yocto Project build system to satisfy the licensing Project build system to satisfy the licensing
requirements for an encumbered BSP. requirements for an encumbered BSP. The following list
The following list describes them in preferential order: describes them in order of preference:
</para> </para>
<orderedlist> <orderedlist>
<listitem> <listitem>
<para>
Yocto recipes that have commercial or other types of
specially-licensed packages define a variable named
LICENSE_FLAGS. For each of those recipes, a user
can specify a matching license string in a
local.conf variable named LICENSE_FLAGS_WHITELIST.
This signifies that the user agrees to the license,
and the corresponding recipe can then be built and
included in the image. See Section 3.3.2. in The
Yocto Project Reference Manual for details on these
variables and how to make use of them.
</para>
<para> <para>
Get a license key (or keys) for the encumbered BSP by visiting If you build as you normally would, without
a website and providing the name of the BSP and your email address specifying any recipes in the
through a web form. LICENSE_FLAGS_WHITELIST, the build will stop and
</para> provide you with the list of recipes that you've
tried to include in the image which need entries in
the LICENSE_FLAGS_WHITELIST. Once the appropriate
license flags have been entered 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.
</para>
<para> <para>
After agreeing to any applicable license terms, the Once the appropriate license flags are whitelisted
BSP key(s) will be immediately sent to the address in the LICENSE_FLAGS_WHITELIST variable, the
you gave and you can use them by specifying BSPKEY_&lt;keydomain&gt; encumbered image can be built with no change at all
environment variables when building the image: to the normal build process.
</para>
<literallayout class='monospaced'>
$ BSPKEY_&lt;keydomain&gt;=&lt;key&gt; bitbake core-image-sato
</literallayout>
<para>
These steps allow the encumbered image to be built
with no change at all to the normal build process.
</para>
<para>
Equivalently and probably more conveniently, a line
for each key can instead be put into the user's
<filename>local.conf</filename> file found in the Yocto Project file's
build directory.
</para>
<para>
The &lt;keydomain&gt; component of the
BSPKEY_&lt;keydomain&gt; is required because there
might be multiple licenses in effect for a given BSP.
In such cases, a given &lt;keydomain&gt; corresponds to
a particular license. In order for an encumbered
BSP that encompasses multiple key domains to be built
successfully, a &lt;keydomain&gt; entry for each
applicable license must be present in <filename>local.conf</filename> or
supplied on the command-line.
</para> </para>
</listitem> </listitem>
<listitem> <listitem>
<para> <para>
Do nothing - build as you normally would. Get a pre-built version of the BSP. You can do this
When a license is needed the build will stop and prompt you with instructions. by visiting the Yocto Project website's
Follow the license prompts that originate from the <ulink url='&YOCTO_HOME_URL;/download'>Download</ulink>
encumbered BSP. page and clicking on "BSP Downloads". BSP tarballs
These prompts usually take the form of instructions that contain proprietary components can be
needed to manually fetch the encumbered package(s) downloaded after agreeing to the licensing
and md5 sums into the required directory requirements of each of the individually encumbered
(e.g. the <filename>yocto/build/downloads</filename>). packages as part of the download process. Obtaining
Once the manual package fetch has been the BSP this way allows you to access an encumbered
completed, restart the build to continue where image immediately after agreeing to the
it left off. click-through license agreements presented by the
During the build the prompt will not appear again since you have satisfied the website. Note that if you want to build the image
requirement. yourself using the recipes contained within the BSP
</para> tarball, you will still need to create an
</listitem> appropriate LICENSE_FLAGS_WHITELIST to match the
<listitem> encumbered recipes in the BSP.
<para>
Get a full-featured BSP recipe rather than a key.
You can do this by visiting the Yocto Project website's
<ulink url='&YOCTO_HOME_URL;/download'>Download</ulink> page and
clicking on "BSP Downloads".
BSP tarballs that have proprietary information can be downloaded after agreeing
to licensing requirements as part of the download process.
Obtaining the code this way allows you to build an encumbered image with
no changes at all as compared to the normal build.
</para> </para>
</listitem> </listitem>
</orderedlist> </orderedlist>
<para> <para>
Note that the third method is also the only option available Note also that the pre-compiled images are bundled with
when downloading pre-compiled images generated from non-free BSPs. a time-limited kernel which will run for only a
Those images are likewise available at from the Yocto Project website. predetermined amount of time (10 days) before it forces
the system to reboot. This is meant as a discouragement
to directly redistributing the image as-is, and means
that you'll have to eventually rebuild the image if you
want to remove that restriction.
</para> </para>
</section> </section>