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

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

[Stefan Christ]

Add the file which contains the Freescale EULA to variable
LIC_FILES_CHKSUM, so the EULA is deployed in the folder

    ${LICENSE_DIRECTORY}/${PN}/

for all recipes which use the bbclass fsl-eula-unpack.

Add a vardepsexclude to variable LIC_FILES_CHKSUM to share the sstate
cache across multiple build directories.  See commit

   commit e8c6cf822889c02b76db03f2e9c6915a1bda1c06
   Author: Christopher Larson <kergoth@gmail.com>
   Date:   Wed Oct 23 22:30:41 2013 +0000

       fsl-eula-unpack: add FSL_EULA_FILE to vardepsexclude

Signed-off-by: Stefan Christ <s.christ@phytec.de>
---
 classes/fsl-eula-unpack.bbclass | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/classes/fsl-eula-unpack.bbclass b/classes/fsl-eula-unpack.bbclass
index 0da17c3..55872e5 100644
--- a/classes/fsl-eula-unpack.bbclass
+++ b/classes/fsl-eula-unpack.bbclass
@@ -6,6 +6,9 @@
 #
 #  SRC_URI = "${FSL_MIRROR}/firmware-imx-${PV};fsl-eula=true"
 
+LIC_FILES_CHKSUM += "file://${FSL_EULA_FILE};md5=6df184a9b1950b68e17fdcd7513bdb97"
+LIC_FILES_CHKSUM[vardepsexclude] += "FSL_EULA_FILE"
+
 python fsl_bin_do_unpack() {
     src_uri = (d.getVar('SRC_URI', True) or "").split()
     if len(src_uri) == 0:
-- 
1.9.1

Re: [PATCH] fsl-eula-unpack: deploy Freescale EULA

[Lauren Post]

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.

Lauren

-----Original Message-----
From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-bounces@yoctoproject.org] On Behalf Of Stefan Christ
Sent: Thursday, May 28, 2015 3:55 AM
To: meta-freescale@yoctoproject.org
Subject: [meta-freescale] [PATCH] fsl-eula-unpack: deploy Freescale EULA

Add the file which contains the Freescale EULA to variable LIC_FILES_CHKSUM, so the EULA is deployed in the folder

    ${LICENSE_DIRECTORY}/${PN}/

for all recipes which use the bbclass fsl-eula-unpack.

Add a vardepsexclude to variable LIC_FILES_CHKSUM to share the sstate cache across multiple build directories.  See commit

   commit e8c6cf822889c02b76db03f2e9c6915a1bda1c06
   Author: Christopher Larson <kergoth@gmail.com>
   Date:   Wed Oct 23 22:30:41 2013 +0000

       fsl-eula-unpack: add FSL_EULA_FILE to vardepsexclude

Signed-off-by: Stefan Christ <s.christ@phytec.de>
---
 classes/fsl-eula-unpack.bbclass | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/classes/fsl-eula-unpack.bbclass b/classes/fsl-eula-unpack.bbclass index 0da17c3..55872e5 100644
--- a/classes/fsl-eula-unpack.bbclass
+++ b/classes/fsl-eula-unpack.bbclass
@@ -6,6 +6,9 @@
 #
 #  SRC_URI = "${FSL_MIRROR}/firmware-imx-${PV};fsl-eula=true"
 
+LIC_FILES_CHKSUM += "file://${FSL_EULA_FILE};md5=6df184a9b1950b68e17fdcd7513bdb97"
+LIC_FILES_CHKSUM[vardepsexclude] += "FSL_EULA_FILE"
+
 python fsl_bin_do_unpack() {
     src_uri = (d.getVar('SRC_URI', True) or "").split()
     if len(src_uri) == 0:
--
1.9.1

--
_______________________________________________
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale

Re: [PATCH] fsl-eula-unpack: deploy Freescale EULA

[Otavio Salvador]

On Wed, Jun 3, 2015 at 11:13 AM, Lauren Post <Lauren.Post@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

Re: [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@yoctoproject.org [mailto:meta-freescale-bounces@yoctoproject.org] On Behalf Of Otavio Salvador
Sent: Wednesday, June 03, 2015 9:31 AM
To: Post Lauren-RAA013
Cc: meta-freescale@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@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@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale

Re: [PATCH] fsl-eula-unpack: deploy Freescale EULA

[Otavio Salvador]

On Wed, Jun 3, 2015 at 11:56 AM, Ann Thornton
<Ann.Thornton@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

The technical is easy to address and all justifications you and Lauren
gave us are technical. I am concerned the legal ones and this needs to
have a official statement from Freescale explicitly saying it and
taking the responsibility for it.

As I said, please point _in the EULA text_ where all this statements
are written and I am fine with this, otherwise this is a legal flaw..

-- 
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

Re: [PATCH] fsl-eula-unpack: deploy Freescale EULA

[Eric Nelson]

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@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

Re: [PATCH] fsl-eula-unpack: deploy Freescale EULA

[Lauren Post]

The current license does that but it is not embedded into the older packages.  Current license evolved from the previous license.  We feel comfortable that users building legacy devices will be covered same as before.

The current patch assumes the license will checksum match the license in the packages.  We don't want to update legacy packages each time the license is updated.  We don't have bandwidth and is not required.  The license in legacy packages matches the license on freescale.com the content was originally distributed with.

Our licensing usage has evolved to a common license.  It will be changed often to add new 3rd parties to the Appendix.  That does not affect previous 3rd parties.   

Every package has the EULA in it so the original EULA stands.
If there is confusion we can create an SCR for the mx53 which is the one that uses proprietary amd gpu (it uses new license for multimedia and old license for vpu and gpu).

We also might have future files that do not require updates.  We provide an SCR that lists the version of license associated with each package.  We don't want to rebind every package each time license gets updated.

We understand everyone's concern but this solution is not the right one.  

If you want a disclaimer add in the setup-environment one that says the license in the package is the license that takes precedence.

Lauren


-----Original Message-----
From: Eric Nelson [mailto:eric.nelson@boundarydevices.com] 
Sent: Wednesday, June 03, 2015 11:46 AM
To: Otavio Salvador; Thornton Ann-RA43240; Post Lauren-RAA013
Cc: meta-freescale@yoctoproject.org; Stefan Christ
Subject: Re: [meta-freescale] [PATCH] fsl-eula-unpack: deploy Freescale EULA

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@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

Re: [PATCH] fsl-eula-unpack: deploy Freescale EULA

[Daiane Angolini]

On Wed, Jun 3, 2015 at 2:19 PM, Lauren Post <Lauren.Post@freescale.com> wrote:
> The current license does that but it is not embedded into the older packages.  Current license evolved from the previous license.  We feel comfortable that users building legacy devices will be covered same as before.
>
> The current patch assumes the license will checksum match the license in the packages.  We don't want to update legacy packages each time the license is updated.  We don't have bandwidth and is not required.  The license in legacy packages matches the license on freescale.com the content was originally distributed with.
>
> Our licensing usage has evolved to a common license.  It will be changed often to add new 3rd parties to the Appendix.  That does not affect previous 3rd parties.
>
> Every package has the EULA in it so the original EULA stands.
> If there is confusion we can create an SCR for the mx53 which is the one that uses proprietary amd gpu (it uses new license for multimedia and old license for vpu and gpu).
>
> We also might have future files that do not require updates.  We provide an SCR that lists the version of license associated with each package.  We don't want to rebind every package each time license gets updated.
>
> We understand everyone's concern but this solution is not the right one.
>
> If you want a disclaimer add in the setup-environment one that says the license in the package is the license that takes precedence.
>

Lauren,

I haven't understood anything in this discussion. I used to think
about the old EULA as a disclaimer of the complete BSP, but each
package would be released under its own licensing. (the EULA would be
the offline replacement of the click-through agreement we had in
Freescale webpage).

The community has accepted recently one EULA change without
questioning it. Now you are presenting a "legal moving target"
scenario which I sincerely was not able to understand. I mean, I can
understand why you and your team don't want to update every single
released package everytime a new release is published, but what is the
change on legal implications? What is being moving?

We are not lawyers or trusted advisors, we barely understand some
initial copyleft statements, can you, please, elaborate what is EULA
for, what is the change in the packages, what is SCR for and what is
the next changes and how it impacts community and next products? What
is the new file/process similar to the click-trough agreement?

I really want to understand, but it's very difficult from past emails,
can we step back and start from the beginning?

At the end, nobody wants to go to the jail.

Best Regards,
Daiane

> Lauren
>
>
> -----Original Message-----
> From: Eric Nelson [mailto:eric.nelson@boundarydevices.com]
> Sent: Wednesday, June 03, 2015 11:46 AM
> To: Otavio Salvador; Thornton Ann-RA43240; Post Lauren-RAA013
> Cc: meta-freescale@yoctoproject.org; Stefan Christ
> Subject: Re: [meta-freescale] [PATCH] fsl-eula-unpack: deploy Freescale EULA
>
> 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@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
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale

Re: [PATCH] fsl-eula-unpack: deploy Freescale EULA

[Ann Thornton]

[-- Attachment #1: Type: text/plain, Size: 6846 bytes --]


We wanted to talk to our lawyer before responding.  But I will try to 
explain a little bit about how the license works.

The EULA is the license.  We do not create the license.  That comes from 
the legal department.  They recently re-did the license scenario so that 
instead of having lots of licenses for all Freescale products, there are 
just a handful.  They are using appendices for different 3rd party 
agreements and adding them to the main license.  So what we have is the 
main license context that doesn't change with a bunch of appendices for 
specific things added to it.  A lot of these appendices are not 
pertinent to our BSP but that is the way it works so we don't have to 
have a lot of different licenses.  The current license we use is on v6 
and we expect a v7 soon.  So even though the EULA is not changing as far 
as we are concerned, the checksum is going to be changing all the time.

We have been including a copy of the latest EULA in all the Freescale 
proprietary packages as we release them, but we don't re-release old 
packages every time we release new ones so the checksum on the EULAs 
will be different in different packages.  So I don't understand how 
having just one checksum stored in one place for the EULA is ever going 
to work.  Or am I not understanding what the patch in question is doing?

Ann Thornton



On 6/3/2015 1:22 PM, Daiane Angolini wrote:
> On Wed, Jun 3, 2015 at 2:19 PM, Lauren Post <Lauren.Post@freescale.com> wrote:
>> The current license does that but it is not embedded into the older packages.  Current license evolved from the previous license.  We feel comfortable that users building legacy devices will be covered same as before.
>>
>> The current patch assumes the license will checksum match the license in the packages.  We don't want to update legacy packages each time the license is updated.  We don't have bandwidth and is not required.  The license in legacy packages matches the license on freescale.com the content was originally distributed with.
>>
>> Our licensing usage has evolved to a common license.  It will be changed often to add new 3rd parties to the Appendix.  That does not affect previous 3rd parties.
>>
>> Every package has the EULA in it so the original EULA stands.
>> If there is confusion we can create an SCR for the mx53 which is the one that uses proprietary amd gpu (it uses new license for multimedia and old license for vpu and gpu).
>>
>> We also might have future files that do not require updates.  We provide an SCR that lists the version of license associated with each package.  We don't want to rebind every package each time license gets updated.
>>
>> We understand everyone's concern but this solution is not the right one.
>>
>> If you want a disclaimer add in the setup-environment one that says the license in the package is the license that takes precedence.
>>
> Lauren,
>
> I haven't understood anything in this discussion. I used to think
> about the old EULA as a disclaimer of the complete BSP, but each
> package would be released under its own licensing. (the EULA would be
> the offline replacement of the click-through agreement we had in
> Freescale webpage).
>
> The community has accepted recently one EULA change without
> questioning it. Now you are presenting a "legal moving target"
> scenario which I sincerely was not able to understand. I mean, I can
> understand why you and your team don't want to update every single
> released package everytime a new release is published, but what is the
> change on legal implications? What is being moving?
>
> We are not lawyers or trusted advisors, we barely understand some
> initial copyleft statements, can you, please, elaborate what is EULA
> for, what is the change in the packages, what is SCR for and what is
> the next changes and how it impacts community and next products? What
> is the new file/process similar to the click-trough agreement?
>
> I really want to understand, but it's very difficult from past emails,
> can we step back and start from the beginning?
>
> At the end, nobody wants to go to the jail.
>
> Best Regards,
> Daiane
>
>> Lauren
>>
>>
>> -----Original Message-----
>> From: Eric Nelson [mailto:eric.nelson@boundarydevices.com]
>> Sent: Wednesday, June 03, 2015 11:46 AM
>> To: Otavio Salvador; Thornton Ann-RA43240; Post Lauren-RAA013
>> Cc: meta-freescale@yoctoproject.org; Stefan Christ
>> Subject: Re: [meta-freescale] [PATCH] fsl-eula-unpack: deploy Freescale EULA
>>
>> 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@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
>> --
>> _______________________________________________
>> meta-freescale mailing list
>> meta-freescale@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-freescale


-- 
Ann Thornton

/Microcontrollers Software and Applications
Freescale Semiconductors
email: Ann.Thornton@freescale.com/

[-- Attachment #2: Type: text/html, Size: 8342 bytes --]

Re: [PATCH] fsl-eula-unpack: deploy Freescale EULA

[Lauren Post]

[-- Attachment #1: Type: text/plain, Size: 6703 bytes --]

Sorry for the delay in answering.  We checked with our lawyer so it took some time to answer this.

-          The current patch for aligning EULA checksum with license in package can’t be used.  We must have ability to have older licenses in packages not checksum with latest EULA.

-          Our lawyer approved the following language to replace the language in setup-environment before showing the EULA

-          The language means that the license in the package prevails if there are any conflicts.

-          Note she did not like the wording of the existing text before showing the EULA.

Here is what should be displayed before showing the EULA.  I’ll send a patch with this change and revert the other patch which is unacceptable for legacy packages

All software is subject to agreement to, and compliance with, Freescale's End User License Agreement.   To have the right to use these binaries in your images, you must read and accept the following terms.  If there are conflicting terms embedded in the software, the terms embedded in the Software will control.


Thanks,
Lauren




On 6/3/2015 1:22 PM, Daiane Angolini wrote:

On Wed, Jun 3, 2015 at 2:19 PM, Lauren Post <Lauren.Post@freescale.com><mailto:Lauren.Post@freescale.com> wrote:

The current license does that but it is not embedded into the older packages.  Current license evolved from the previous license.  We feel comfortable that users building legacy devices will be covered same as before.



The current patch assumes the license will checksum match the license in the packages.  We don't want to update legacy packages each time the license is updated.  We don't have bandwidth and is not required.  The license in legacy packages matches the license on freescale.com the content was originally distributed with.



Our licensing usage has evolved to a common license.  It will be changed often to add new 3rd parties to the Appendix.  That does not affect previous 3rd parties.



Every package has the EULA in it so the original EULA stands.

If there is confusion we can create an SCR for the mx53 which is the one that uses proprietary amd gpu (it uses new license for multimedia and old license for vpu and gpu).



We also might have future files that do not require updates.  We provide an SCR that lists the version of license associated with each package.  We don't want to rebind every package each time license gets updated.



We understand everyone's concern but this solution is not the right one.



If you want a disclaimer add in the setup-environment one that says the license in the package is the license that takes precedence.





Lauren,



I haven't understood anything in this discussion. I used to think

about the old EULA as a disclaimer of the complete BSP, but each

package would be released under its own licensing. (the EULA would be

the offline replacement of the click-through agreement we had in

Freescale webpage).



The community has accepted recently one EULA change without

questioning it. Now you are presenting a "legal moving target"

scenario which I sincerely was not able to understand. I mean, I can

understand why you and your team don't want to update every single

released package everytime a new release is published, but what is the

change on legal implications? What is being moving?



We are not lawyers or trusted advisors, we barely understand some

initial copyleft statements, can you, please, elaborate what is EULA

for, what is the change in the packages, what is SCR for and what is

the next changes and how it impacts community and next products? What

is the new file/process similar to the click-trough agreement?



I really want to understand, but it's very difficult from past emails,

can we step back and start from the beginning?



At the end, nobody wants to go to the jail.



Best Regards,

Daiane



Lauren





-----Original Message-----

From: Eric Nelson [mailto:eric.nelson@boundarydevices.com]

Sent: Wednesday, June 03, 2015 11:46 AM

To: Otavio Salvador; Thornton Ann-RA43240; Post Lauren-RAA013

Cc: meta-freescale@yoctoproject.org<mailto:meta-freescale@yoctoproject.org>; Stefan Christ

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



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@freescale.com><mailto:Ann.Thornton@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

--

_______________________________________________

meta-freescale mailing list

meta-freescale@yoctoproject.org<mailto:meta-freescale@yoctoproject.org>

https://lists.yoctoproject.org/listinfo/meta-freescale

--
Ann Thornton

Microcontrollers Software and Applications
Freescale Semiconductors
email: Ann.Thornton@freescale.com<mailto:Ann.Thornton@freescale.com>

[-- Attachment #2: Type: text/html, Size: 16528 bytes --]

Re: [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@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

Re: [PATCH] fsl-eula-unpack: deploy Freescale EULA

[Ann Thornton]

[-- Attachment #1: Type: text/plain, Size: 4704 bytes --]


Thanks, Stefan, for the clarifications.

It would be nice if the EULA didn't change over time.  It would be nice 
to have it in the folder with the rest of the licenses.

So what does the checksum do the += when the values differ?  With the = 
does it keep the checksum locally?  If append is used it copies it and 
then assumes all EULAs have the same checksum? Could we append a version 
to the EULA name when it is copied over and the checksum that goes with 
it?  That would solve the problem in one way, I think.

Ann Thornton

On 6/5/2015 2:25 AM, Stefan Christ wrote:
> 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@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


-- 
Ann Thornton

/Microcontrollers Software and Applications
Freescale Semiconductors
email: Ann.Thornton@freescale.com/

[-- Attachment #2: Type: text/html, Size: 6023 bytes --]

Re: [PATCH] fsl-eula-unpack: deploy Freescale EULA

[Otavio Salvador]

Dear Lauren,

On Thu, Jun 4, 2015 at 2:27 PM, Lauren Post <Lauren.Post@freescale.com> wrote:
...
> All software is subject to agreement to, and compliance with, Freescale's
> End User License Agreement.   To have the right to use these binaries in
> your images, you must read and accept the following terms.  If there are
> conflicting terms embedded in the software, the terms embedded in the
> Software will control.
...

I completely disagree with the change proposed by your lawyer. The
statement seems completely wrong to me.

When we use the "all" word this states that Freescale EULA overrides
the license terms of:

Linux kernel - GPL-2.0
Qt5 - LGPL-3.0 / commercial
…

and Freescale has no right to do so. The proposed text put Freescale
at risk of license agreement glitch as when it is said "If there are
conflicting terms embedded in the software, the terms embedded in the
Software will control." it opens the door for someone to make a GPL
application and contaminate EULA covered binaries (i.e Vivante's
ones), just by linking at them and stating their license "controls"
the license terms.  It is clear that the lawyer is underestimating the
complexity involved here.

The text in use, nowadays, in the setup-environment:

"Some BSPs depend on libraries and packages which are covered by Freescale's
End User License Agreement (EULA). To have the right to use these binaries in
your images, you need to read and accept the following..."

Makes clear that it is user/customer duty to inspect the EULA and
check if it is possible to agree with it, it makes clear libraries and
packages might be under this license and its his/her duty to verify
those.

Regards,

-- 
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

Re: [PATCH] fsl-eula-unpack: deploy Freescale EULA

[Ann Thornton]

[-- Attachment #1: Type: text/plain, Size: 2144 bytes --]


I think you are misunderstanding what this says.  It is saying that the 
licenses in the software override this.  So the GPL licensed code is 
still GPL, etc.

Ann

On 6/8/2015 8:01 AM, Otavio Salvador wrote:
> Dear Lauren,
>
> On Thu, Jun 4, 2015 at 2:27 PM, Lauren Post <Lauren.Post@freescale.com> wrote:
> ...
>> All software is subject to agreement to, and compliance with, Freescale's
>> End User License Agreement.   To have the right to use these binaries in
>> your images, you must read and accept the following terms.  If there are
>> conflicting terms embedded in the software, the terms embedded in the
>> Software will control.
> ...
>
> I completely disagree with the change proposed by your lawyer. The
> statement seems completely wrong to me.
>
> When we use the "all" word this states that Freescale EULA overrides
> the license terms of:
>
> Linux kernel - GPL-2.0
> Qt5 - LGPL-3.0 / commercial
> …
>
> and Freescale has no right to do so. The proposed text put Freescale
> at risk of license agreement glitch as when it is said "If there are
> conflicting terms embedded in the software, the terms embedded in the
> Software will control." it opens the door for someone to make a GPL
> application and contaminate EULA covered binaries (i.e Vivante's
> ones), just by linking at them and stating their license "controls"
> the license terms.  It is clear that the lawyer is underestimating the
> complexity involved here.
>
> The text in use, nowadays, in the setup-environment:
>
> "Some BSPs depend on libraries and packages which are covered by Freescale's
> End User License Agreement (EULA). To have the right to use these binaries in
> your images, you need to read and accept the following..."
>
> Makes clear that it is user/customer duty to inspect the EULA and
> check if it is possible to agree with it, it makes clear libraries and
> packages might be under this license and its his/her duty to verify
> those.
>
> Regards,
>


-- 
Ann Thornton

/Microcontrollers Software and Applications
Freescale Semiconductors
email: Ann.Thornton@freescale.com/

[-- Attachment #2: Type: text/html, Size: 2894 bytes --]

Re: [PATCH] fsl-eula-unpack: deploy Freescale EULA

[Otavio Salvador]

On Mon, Jun 8, 2015 at 11:09 AM, Ann Thornton
<Ann.Thornton@freescale.com> wrote:
> I think you are misunderstanding what this says.  It is saying that the
> licenses in the software override this.  So the GPL licensed code is still
> GPL, etc.

Licensing is way complex and subtle than this. GPL code may not even
use Freescale libraries as it is "viral" and would be impossible to
"open" the Vivante's code, for example. The statement gives the wrong
conception that it would be possible plus the setup-environment should
be as neutral as possible as the real EULA(s) need to be reviewed and
considered by customer legal team.

-- 
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