From: Ann Thornton <Ann.Thornton@freescale.com>
To: Stefan Christ <s.christ@phytec.de>,
Eric Nelson <eric.nelson@boundarydevices.com>
Cc: "meta-freescale@yoctoproject.org"
<meta-freescale@yoctoproject.org>,
Otavio Salvador <otavio@ossystems.com.br>
Subject: Re: [PATCH] fsl-eula-unpack: deploy Freescale EULA
Date: Fri, 5 Jun 2015 16:06:40 -0500 [thread overview]
Message-ID: <55720F60.40602@freescale.com> (raw)
In-Reply-To: <20150605072556.GA2553@lws-christ>
[-- 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 --]
prev parent reply other threads:[~2015-06-05 21:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-28 8:55 [PATCH] fsl-eula-unpack: deploy Freescale EULA Stefan Christ
2015-06-03 14:13 ` Lauren Post
2015-06-03 14:30 ` Otavio Salvador
2015-06-03 14:56 ` Ann Thornton
2015-06-03 16:15 ` Otavio Salvador
2015-06-03 16:46 ` Eric Nelson
2015-06-03 17:19 ` Lauren Post
2015-06-03 18:22 ` Daiane Angolini
2015-06-04 16:34 ` Ann Thornton
2015-06-04 17:27 ` Lauren Post
2015-06-08 13:01 ` Otavio Salvador
2015-06-08 14:09 ` Ann Thornton
2015-06-08 15:06 ` Otavio Salvador
2015-06-05 7:25 ` Stefan Christ
2015-06-05 21:06 ` Ann Thornton [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55720F60.40602@freescale.com \
--to=ann.thornton@freescale.com \
--cc=eric.nelson@boundarydevices.com \
--cc=meta-freescale@yoctoproject.org \
--cc=otavio@ossystems.com.br \
--cc=s.christ@phytec.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.