diff options
| -rw-r--r-- | documentation/bsp-guide/bsp.xml | 192 |
1 files changed, 91 insertions, 101 deletions
diff --git a/documentation/bsp-guide/bsp.xml b/documentation/bsp-guide/bsp.xml index a8d571c038..40d994a2b2 100644 --- a/documentation/bsp-guide/bsp.xml +++ b/documentation/bsp-guide/bsp.xml | |||
| @@ -656,135 +656,125 @@ | |||
| 656 | </section> | 656 | </section> |
| 657 | </section> | 657 | </section> |
| 658 | 658 | ||
| 659 | <section id='bsp-click-through-licensing'> | 659 | <section id='bsp-licensing'> |
| 660 | <title>BSP 'Click-Through' Licensing Procedure</title> | 660 | <title>BSP Licensing Considerations</title> |
| 661 | |||
| 662 | <note> This section describes how | ||
| 663 | click-through licensing is expected to work. | ||
| 664 | Currently, this functionality is not yet implemented. | ||
| 665 | </note> | ||
| 666 | |||
| 667 | <para> | 661 | <para> |
| 668 | In some cases, a BSP contains separately licensed IP | 662 | In some cases, a BSP contains separately licensed IP |
| 669 | (Intellectual Property) for a component that imposes | 663 | (Intellectual Property) for a component or components |
| 670 | upon the user a requirement to accept the terms of a | 664 | that impose upon the user a requirement to accept the |
| 671 | 'click-through' license. | 665 | terms of a commercial or other type of license that |
| 672 | Once the license is accepted the | 666 | requires some kind of explicit EULA (End User License |
| 673 | Yocto Project build system can then build and include the | 667 | Agreement). Once the license is accepted the Yocto |
| 674 | corresponding component in the final BSP image. | 668 | Project build system can then build and include the |
| 675 | Some affected components might be essential to the normal | 669 | corresponding component in the final BSP image, or if |
| 676 | functioning of the system and have no 'free' replacement | 670 | the BSP is available in the form of an already built |
| 677 | (i.e. the resulting system would be non-functional | 671 | image, the user will be able to download the image after |
| 678 | without them). | 672 | agreeing to the license or EULA. |
| 679 | On the other hand, other components might be simply | 673 | </para> |
| 680 | 'good-to-have' or purely elective, or if essential | 674 | <para> |
| 681 | nonetheless have a 'free' (possibly less-capable) | 675 | Some affected components might be essential to the |
| 682 | version that could be used as a in the BSP recipe. | 676 | normal functioning of the system and have no 'free' |
| 677 | replacement (i.e. the resulting system would be | ||
| 678 | non-functional without them). On the other hand, other | ||
| 679 | components might be simply 'good-to-have' or purely | ||
| 680 | elective, or if essential nonetheless have a 'free' | ||
| 681 | (possibly less-capable) version that could be used as a | ||
| 682 | in the BSP recipe. | ||
| 683 | </para> | 683 | </para> |
| 684 | 684 | ||
| 685 | <para> | 685 | <para> |
| 686 | For cases where you can substitute something and still maintain functionality, | 686 | For cases where you can substitute something and still |
| 687 | the Yocto Project website's | 687 | maintain functionality, the Yocto Project website's |
| 688 | <ulink url='&YOCTO_HOME_URL;/download/all?keys=&download_type=1&download_version='>BSP Download Page</ulink> | 688 | <ulink url='&YOCTO_HOME_URL;/download/all?keys=&download_type=1&download_version='>BSP |
| 689 | makes available 'de-featured' BSPs that are completely free of any IP encumbrances. | 689 | Download Page</ulink> makes available 'de-featured' BSPs |
| 690 | For these cases you can use the substitution directly and without any further licensing | 690 | that are completely free of any IP encumbrances. For |
| 691 | requirements. | 691 | these cases you can use the substitution directly and |
| 692 | If present, these fully 'de-featured' BSPs are named appropriately different | 692 | without any further licensing requirements. If present, |
| 693 | as compared to the names of the respective encumbered BSPs. | 693 | these fully 'de-featured' BSPs are named appropriately |
| 694 | If available, these substitutions are the simplest and most preferred options. | 694 | different as compared to the names of the respective |
| 695 | This, of course, assumes the resulting functionality meets requirements. | 695 | encumbered BSPs. If available, these substitutions are |
| 696 | the simplest and most preferred options. This, of | ||
| 697 | course, assumes the resulting functionality meets | ||
| 698 | requirements. | ||
| 696 | </para> | 699 | </para> |
| 697 | 700 | ||
| 698 | <para> | 701 | <para> |
| 699 | If however, a non-encumbered version is unavailable or the 'free' version | 702 | If however, a non-encumbered version is unavailable or |
| 700 | would provide unsuitable functionality or quality, you can use | 703 | the 'free' version would provide unsuitable |
| 701 | an encumbered version. | 704 | functionality or quality, you can use an encumbered |
| 705 | version. | ||
| 702 | </para> | 706 | </para> |
| 703 | 707 | ||
| 704 | <para> | 708 | <para> A couple different methods exist within the Yocto |
| 705 | Several methods exist within the Yocto Project build system to satisfy the licensing | 709 | Project build system to satisfy the licensing |
| 706 | requirements for an encumbered BSP. | 710 | requirements for an encumbered BSP. The following list |
| 707 | The following list describes them in preferential order: | 711 | describes them in order of preference: |
| 708 | </para> | 712 | </para> |
| 709 | 713 | ||
| 710 | <orderedlist> | 714 | <orderedlist> |
| 711 | <listitem> | 715 | <listitem> |
| 712 | |||
| 713 | <para> | 716 | <para> |
| 714 | Get a license key (or keys) for the encumbered BSP by visiting | 717 | Yocto recipes that have commercial or other types of |
| 715 | a website and providing the name of the BSP and your email address | 718 | specially-licensed packages define a variable named |
| 716 | through a web form. | 719 | LICENSE_FLAGS. For each of those recipes, a user |
| 720 | can specify a matching license string in a | ||
| 721 | local.conf variable named LICENSE_FLAGS_WHITELIST. | ||
| 722 | This signifies that the user agrees to the license, | ||
| 723 | and the corresponding recipe can then be built and | ||
| 724 | included in the image. See Section 3.3.2. in The | ||
| 725 | Yocto Project Reference Manual for details on these | ||
| 726 | variables and how to make use of them. | ||
| 717 | </para> | 727 | </para> |
| 718 | |||
| 719 | <para> | ||
| 720 | After agreeing to any applicable license terms, the | ||
| 721 | BSP key(s) will be immediately sent to the address | ||
| 722 | you gave and you can use them by specifying BSPKEY_<keydomain> | ||
| 723 | environment variables when building the image: | ||
| 724 | </para> | ||
| 725 | |||
| 726 | <literallayout class='monospaced'> | ||
| 727 | $ BSPKEY_<keydomain>=<key> bitbake core-image-sato | ||
| 728 | </literallayout> | ||
| 729 | 728 | ||
| 730 | <para> | 729 | <para> |
| 731 | These steps allow the encumbered image to be built | 730 | If you build as you normally would, without |
| 732 | with no change at all to the normal build process. | 731 | specifying any recipes in the |
| 732 | LICENSE_FLAGS_WHITELIST, the build will stop and | ||
| 733 | provide you with the list of recipes that you've | ||
| 734 | tried to include in the image which need entries in | ||
| 735 | the LICENSE_FLAGS_WHITELIST. Once the appropriate | ||
| 736 | license flags have been entered into the whitelist, | ||
| 737 | restart the build to continue where it left off. | ||
| 738 | During the build the prompt will not appear again | ||
| 739 | since you have satisfied the requirement. | ||
| 733 | </para> | 740 | </para> |
| 734 | 741 | ||
| 735 | <para> | ||
| 736 | Equivalently and probably more conveniently, a line | ||
| 737 | for each key can instead be put into the user's | ||
| 738 | <filename>local.conf</filename> file found in the Yocto Project file's | ||
| 739 | build directory. | ||
| 740 | </para> | ||
| 741 | |||
| 742 | <para> | 742 | <para> |
| 743 | The <keydomain> component of the | 743 | Once the appropriate license flags are whitelisted |
| 744 | BSPKEY_<keydomain> is required because there | 744 | in the LICENSE_FLAGS_WHITELIST variable, the |
| 745 | might be multiple licenses in effect for a given BSP. | 745 | encumbered image can be built with no change at all |
| 746 | In such cases, a given <keydomain> corresponds to | 746 | to the normal build process. |
| 747 | a particular license. In order for an encumbered | ||
| 748 | BSP that encompasses multiple key domains to be built | ||
| 749 | successfully, a <keydomain> entry for each | ||
| 750 | applicable license must be present in <filename>local.conf</filename> or | ||
| 751 | supplied on the command-line. | ||
| 752 | </para> | 747 | </para> |
| 753 | </listitem> | 748 | </listitem> |
| 754 | <listitem> | 749 | <listitem> |
| 755 | <para> | 750 | <para> |
| 756 | Do nothing - build as you normally would. | 751 | Get a pre-built version of the BSP. You can do this |
| 757 | When a license is needed the build will stop and prompt you with instructions. | 752 | by visiting the Yocto Project website's |
| 758 | Follow the license prompts that originate from the | 753 | <ulink url='&YOCTO_HOME_URL;/download'>Download</ulink> |
| 759 | encumbered BSP. | 754 | page and clicking on "BSP Downloads". BSP tarballs |
| 760 | These prompts usually take the form of instructions | 755 | that contain proprietary components can be |
| 761 | needed to manually fetch the encumbered package(s) | 756 | downloaded after agreeing to the licensing |
| 762 | and md5 sums into the required directory | 757 | requirements of each of the individually encumbered |
| 763 | (e.g. the <filename>yocto/build/downloads</filename>). | 758 | packages as part of the download process. Obtaining |
| 764 | Once the manual package fetch has been | 759 | the BSP this way allows you to access an encumbered |
| 765 | completed, restart the build to continue where | 760 | image immediately after agreeing to the |
| 766 | it left off. | 761 | click-through license agreements presented by the |
| 767 | During the build the prompt will not appear again since you have satisfied the | 762 | website. Note that if you want to build the image |
| 768 | requirement. | 763 | yourself using the recipes contained within the BSP |
| 769 | </para> | 764 | tarball, you will still need to create an |
| 770 | </listitem> | 765 | appropriate LICENSE_FLAGS_WHITELIST to match the |
| 771 | <listitem> | 766 | encumbered recipes in the BSP. |
| 772 | <para> | ||
| 773 | Get a full-featured BSP recipe rather than a key. | ||
| 774 | You can do this by visiting the Yocto Project website's | ||
| 775 | <ulink url='&YOCTO_HOME_URL;/download'>Download</ulink> page and | ||
| 776 | clicking on "BSP Downloads". | ||
| 777 | BSP tarballs that have proprietary information can be downloaded after agreeing | ||
| 778 | to licensing requirements as part of the download process. | ||
| 779 | Obtaining the code this way allows you to build an encumbered image with | ||
| 780 | no changes at all as compared to the normal build. | ||
| 781 | </para> | 767 | </para> |
| 782 | </listitem> | 768 | </listitem> |
| 783 | </orderedlist> | 769 | </orderedlist> |
| 784 | <para> | 770 | <para> |
| 785 | Note that the third method is also the only option available | 771 | Note also that the pre-compiled images are bundled with |
| 786 | when downloading pre-compiled images generated from non-free BSPs. | 772 | a time-limited kernel which will run for only a |
| 787 | Those images are likewise available at from the Yocto Project website. | 773 | predetermined amount of time (10 days) before it forces |
| 774 | the system to reboot. This is meant as a discouragement | ||
| 775 | to directly redistributing the image as-is, and means | ||
| 776 | that you'll have to eventually rebuild the image if you | ||
| 777 | want to remove that restriction. | ||
| 788 | </para> | 778 | </para> |
| 789 | </section> | 779 | </section> |
| 790 | 780 | ||
