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

[Ann Thornton]

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 Thornton

-----Original Message-----
From: meta-freescale-bounces at yoctoproject.org [mailto:meta-freescale-bounces at yoctoproject.org] On Behalf Of Otavio Salvador
Sent: Wednesday, June 03, 2015 9:31 AM
To: Post Lauren-RAA013
Cc: meta-freescale at yoctoproject.org
Subject: Re: [meta-freescale] [PATCH] fsl-eula-unpack: deploy Freescale EULA

On Wed, Jun 3, 2015 at 11:13 AM, Lauren Post <Lauren.Post at freescale.com> wrote:
>
> This patch is going to cause a HUGE problem on all our proprietary packages.
>
> MX53's bound license is an precursor to current license.  With this change MX53 is now broken.   The old license did not require an SCR so an SCR is not available for mx53.
>
> We are going to get many new versions of our EULA as more 3rd parties are added to the appendix.  This is going to be a big problem.  It means we have to update new versions for packages that might have no changes but EULA change.
>
> I think the current implementation of keeping the license bound to the recipe is the correct.  If this is part of the eula unpack class it will be a big problem to maintain in future.   People will see new versions of components that are not changing but only because of a EULA
>
> If we keep the license checksum in the recipe the problem is solved.
>
> I am a licensing trusted advisor and I know our licenses well and the new license evolved from the earlier licenses so the older packages are covered under current license but do not need to packaged with each license update.

Where in the EULA file it says it is compatible with the next versions? I am not a licensing trusted advisor, nor a lawyer, but it is hard to believe a previous version says it is compatible with upcoming, non-released, versions.

Is there a document from Freescale Legal authorities stating this? How a company can have this statement to avoid any possible legal implications due the license change happened in the package or EULA?

Stefan change makes it easier to spot those changes and demand the right actions from Freescale to solve them. What you are stating I couldn't find in the EULA file. Please point me the place where this is stated.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
--
_______________________________________________
meta-freescale mailing list
meta-freescale at yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale