[meta-freescale] [PATCH] fsl-eula-unpack: deploy Freescale EULA

[Stefan Christ]

Hi Eric and Ann,

> I think (Stefan, please confirm) that the reason for this patch
> has to do with the way that the EULAs are "accepted" by the user.
>
> The current process involves an acknowledgement of a single
> "Freescale EULA" in the setup-environment script.

Yes, that's correct. I assumed that, since the fsl-community-bsp contains only
a single EULA file which the user accepts by adding 'ACCEPT_FSL_EULA = ""' to
his local.conf, there is only one EULA covering all packages.

And the user is only presented a single EULA file. So appending ACCEPT_FSL_EULA
means that he accepts this one EULA only.


The reason for my patch was that Yocto provides a way [1] to bundle all
licenses, which are used in the recipes, into the deployment folder

    deploy/licenses/<recipe-name>/

Since the EULA was missing in this directory, I wrote the patch and adding
LIC_FILES_CHKSUM globally was the right choice based on my assumption.


> >> It looks like Stefan is saying that the using
> >> LIC_FILES_CHKSUM_append will override the problem.  But we will
> >> need to put that in all the recipes so the end result will nullify
> >> this patch, I think.

No, you missunderstood my patch message. Using "LIC_FILES_CHKSUM_append" fixes
a bug only.

If "LIC_FILES_CHKSUM +=" is used, the EULA is not always put into the license
directory, because "LIC_FILES_CHKSUM =" in a recipe will overwrite all previous
"+=" assigments.

If "LIC_FILES_CHKSUM_append" is used, the EULA is always deployed into the
license directory for every recipe which inherits the fsl-eula-unpack bbclass.


It had nothing to do with the legal aspects or the multi EULA issue.

Mit freundlichen Grüßen / Kind regards,
	Stefan Christ

[1] http://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html#usingpoky-configuring-LIC_FILES_CHKSUM


On Wed, Jun 03, 2015 at 09:46:00AM -0700, Eric Nelson wrote:
> Hi Ann and Lauren,
> 
> On 06/03/2015 09:15 AM, Otavio Salvador wrote:
> > On Wed, Jun 3, 2015 at 11:56 AM, Ann Thornton 
> > <Ann.Thornton at freescale.com> wrote:
> >> 
> >> Here is the problem:  The EULA is updated frequently with changes
> >> that really don't matter to existing packages.  New 3rd party
> >> requirements are added that apply to new packages, typos are
> >> occasionally fixed, and so on.
> >> 
> >> If this patch is limiting us to only one EULA in all packages, that
> >> means all of the older packages have to be updated with new EULAs
> >> and a new version number every few months.  That is just not going
> >> to happen.  Not to mention other groups that have older packages as
> >> well.  The core of the EULA has not changed and will not change
> >> (the legal department has promised us that) so we expect that
> >> future EULAs will be in line with the current ones.
> >> 
> >> It looks like Stefan is saying that the using
> >> LIC_FILES_CHKSUM_append will override the problem.  But we will
> >> need to put that in all the recipes so the end result will nullify
> >> this patch, I think.
> > 
> > Ann, we need to separate two issues here:
> > 
> > - technical - legal
> > 
> 
> I think (Stefan, please confirm) that the reason for this patch
> has to do with the way that the EULAs are "accepted" by the user.
> 
> The current process involves an acknowledgement of a single
> "Freescale EULA" in the setup-environment script.
> 
> If there are a dozen Freescale licenses in various packages,
> do each of them need to be acked by the user before using them?
> 
> If so, can the Freescale legal folks put together an over-arching
> license that covers all components? It seems that the EULA is
> usually re-used and way broader than most of the patches (including
> Microsoft, SanDisk, CSR and Global Locate, which likely don't have
> rights in most of the covered components).
> 
> Please advise,
> 
> 
> Eric