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

Thu Jun 4 10:27:58 PDT 2015

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 at freescale.com><mailto:Lauren.Post at 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 at boundarydevices.com]

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

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

Cc: meta-freescale at yoctoproject.org<mailto:meta-freescale at 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 at freescale.com><mailto: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

--

_______________________________________________

meta-freescale mailing list

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

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

--
Ann Thornton

Microcontrollers Software and Applications
Freescale Semiconductors
email: Ann.Thornton at freescale.com<mailto:Ann.Thornton at freescale.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20150604/e62b21dd/attachment-0001.html>