From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id BC6CBE009AE; Thu, 4 Jun 2015 09:34:49 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -0.0 SPF_HELO_PASS SPF: HELO matches SPF record * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 HTML_MESSAGE BODY: HTML included in message * -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no * trust * [207.46.100.101 listed in list.dnswl.org] X-Greylist: delayed 92315 seconds by postgrey-1.32 at yocto-www; Thu, 04 Jun 2015 09:34:44 PDT Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0101.outbound.protection.outlook.com [207.46.100.101]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 724FAE00985 for ; Thu, 4 Jun 2015 09:34:44 -0700 (PDT) Received: from BY2PR03CA009.namprd03.prod.outlook.com (10.255.93.26) by DM2PR0301MB0703.namprd03.prod.outlook.com (10.160.97.11) with Microsoft SMTP Server (TLS) id 15.1.172.22; Thu, 4 Jun 2015 16:34:42 +0000 Received: from BY2FFO11FD021.protection.gbl (10.255.93.4) by BY2PR03CA009.outlook.office365.com (10.255.93.26) with Microsoft SMTP Server (TLS) id 15.1.184.17 via Frontend Transport; Thu, 4 Jun 2015 16:34:41 +0000 Authentication-Results: spf=fail (sender IP is 192.88.158.2) smtp.mailfrom=freescale.com; gmail.com; dkim=none (message not signed) header.d=none; Received-SPF: Fail (protection.outlook.com: domain of freescale.com does not designate 192.88.158.2 as permitted sender) receiver=protection.outlook.com; client-ip=192.88.158.2; helo=az84smr01.freescale.net; Received: from az84smr01.freescale.net (192.88.158.2) by BY2FFO11FD021.mail.protection.outlook.com (10.1.15.210) with Microsoft SMTP Server (TLS) id 15.1.184.11 via Frontend Transport; Thu, 4 Jun 2015 16:34:41 +0000 Received: from [127.0.0.1] (RA43240-03.am.freescale.net [10.81.17.26]) by az84smr01.freescale.net (8.14.3/8.14.0) with ESMTP id t54GYZKf001724; Thu, 4 Jun 2015 09:34:40 -0700 Message-ID: <55707E1C.2060202@freescale.com> Date: Thu, 4 Jun 2015 11:34:36 -0500 From: Ann Thornton User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Daiane Angolini , Lauren Post References: <1432803324-14497-1-git-send-email-s.christ@phytec.de> <556F2F48.80908@boundarydevices.com> In-Reply-To: X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD021; 1:BgbrN4FU3KtUo5SBOGVMJ0PMCGtW9LXsFl+sq7KeaTk52Na8eOSY8ird7ySfSF0dOm0Qc2jwsUQv6HWgl+tvrbVE/osDTYZOOINq8Y5BzizDOLUxxxwTsgpfrMRhaOnp2cPHGJ129tWHgw00sFLfTb3bpXiXbzsWIQGsILHq8r0ubjEz6dRvzTNJhlHKPMzFA394DoDFTKUNPQgH5YLVSKpKvtOT07ScSfZM+ZXlF4NhNCkWinYaujCP/yUrKoI5kjNZWoeJHkVp+f5cgsjF6V/l6MuNn0yhjLm5tqVg1X8= X-Forefront-Antispam-Report: CIP:192.88.158.2; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(339900001)(189002)(51704005)(199003)(377454003)(51164003)(252514010)(24454002)(479174004)(13464003)(6806004)(59896002)(64706001)(230783001)(33656002)(86362001)(92566002)(50986999)(36756003)(120886001)(4001350100001)(19617315012)(93886004)(19580405001)(4001540100001)(106466001)(105606002)(87266999)(77156002)(54356999)(76176999)(65816999)(62966003)(104016003)(46102003)(5001960100002)(81156007)(19580395003)(77096005)(64126003)(97736004)(2950100001)(84326002)(189998001)(80316001)(15975445007)(65956001)(85426001)(99136001)(69596002)(87936001)(83506001)(65806001)(5001770100001)(5001830100001)(68736005)(512874002)(5001860100001)(4001450100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0703; H:az84smr01.freescale.net; FPR:; SPF:Fail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0301MB0703; 2:/waVxC+OTti+BssJgj2HfHGbuyv1LMMyUroClnNUdI8f9hSvuTKc7x2gHwJjH4Fb; 2:uqPskZidErtKSUFyiL7JZUmVxV96nqiOPcf3SgC38bZlKT2YLZ/yYGeWbPi2Feji86aS2+kPvlT1/KN778I8hmESvrnAsDl8nmblxNHYhAjLN2WGb/EqKiUefJQp5Em1CB8GNZBHWit4wsJ3YPpJgn3sXFg7Fe8MDCgIvxvL/EB9RCAb+4jYrEYQmGenfKDrAooExbzB27XWZAZmu2jICgtHDt3IYcdiDFC1QzyL4rc=; 6:Psm6dLc/68ohzhLIVQ9dUI5V53KFVWD1HfxDnRxtR/W0mzO9lmB4PGlJH/DdjUSrgBDZ9edaCsYtBisranWMt5CE3On0DZipg5CeREhM8JwUiJLLeSDhFfILJOBK7EH6rBgomSYbvqnUV3WgkYDn68zhlTX507/7XrOFREU9KcwyoTwcQmEcTktCRQrQ7YX8qGAZAyFBvH/XiJnR+9B8GHsGCCPN5jh3R1MvHGjlmHPFrOQvbt/80I0z+3tAtmq1HD7qErzaxKnvBiA+7Pp/Kfy5u6wtU76UY6sSudNYE8WcnOkcB4nuJgSOmNiFITAc8Y4CsJbT4cF230sXitlbrQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0703; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:DM2PR0301MB0703; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0703; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0301MB0703; 3:yIlntAHkqs3TOU0iUz9jSCdiNVKyyx4ZpFmWi930ICoR2FHNzHz6c7FwnOFwJNB9rV5GNVPprO1uc24O7xBuPrh7HWJmgcqBdwhzk7A3BlpCAKl2bhqVyWSJr+ch+RHhX196WhzTam57ApaEfnFCx9agfq7W+rhEDrF2N52QfPmxYKfZv+6LAj8qmJh18KrYkht3YveaugL/GkvJ1UNOBO2Bj7TDcK5x2NOhV2+Q6KDM8ZD6Z8Jj53q89OqvVuvfdkQeoNNESzkDx5smBt2ZcJ9Szz1QcozE1PYU44GlWL00sQcusTikX5lgdLksaIE1 X-Forefront-PRVS: 0597911EE1 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTJQUjAzMDFNQjA3MDM7OTo4bTRscWxDSDRPWThBL2FQblgvVHpubU5L?= =?utf-8?B?UkpERmFWdnJhbnZlbDJuQ3U4MkxpcjlMamRLRzlNTm1IWUoxNUpjVkUxc3h3?= =?utf-8?B?dytMN1FkRWNNVHRIN0YyVTBTMzR4MFNndEdTWkNYaFYyVjNOUnkwQzd4UElp?= =?utf-8?B?dHQvMmlyM2F0OENQMGFmc1B1c2JvVUFwckZaTnNHNHdRRGpTOERGODBhNHZu?= =?utf-8?B?QmpmSExkMlQ1N3M2VzZRb3hNVXlmeXZBa1daQUk5VEhNZTdERTNzVEtuVDFP?= =?utf-8?B?RjlmZkM4N3ZkbzlYL3ZoMU5JRDk0YVN3NCt6ZXErc2RBNmRmby9rSnV5MG1T?= =?utf-8?B?S3M0OVRlbC9ZbzhZTzM2eTYybStwZjE3c0pmdGJnVjRPbnU2aVZ6U1BOUWll?= =?utf-8?B?T2VXL05NQ1JMNjQ0UFNnSVNpd1dvemd6Q0UwQm5qMHJsZWpkZEdjYVhMSFVP?= =?utf-8?B?TnF3Nm9WamMxSDViVEd5RTZOdURScUlkR0JrM0FhTVVNWEJoakFZdEU0R05h?= =?utf-8?B?d3ordkNzTERtWGxGK1g3dTZqdStoVzJwWW9xUmUxMzdVVVNIR3pGOTQ4V1FP?= =?utf-8?B?NVAwZ2Z1UElrd2Y4azhNSGYyNkpqRjQxNGx3ekFmc2hES1gyWG9VUzNPUE1F?= =?utf-8?B?WGlUVmZLNHl0Y1p6bVZ1dmtLU3JuL0xhekpqTXFrS2NvcmUzQVRiclhvVG81?= =?utf-8?B?MlplSitiZyt6UEZOek04YlQralo1dEFVNmorNDRvVmcrREJWd2JNRnY0Yndw?= =?utf-8?B?SGI4VWdSanY3MlRzUFBPOWRuM3hveTVoYmZlY1VGK3liZHBtNUpoODVNUk0r?= =?utf-8?B?R3JzQVJpdXhWaDFuVzhlcCtyZEVQNTRYTzZaS1lOSDYwQnZYaGhVTVROZ1BC?= =?utf-8?B?WkxIOUFnbXVxalJOQjg4QUZETUZKWldTMTBOQnVhanF2MVBKb04zenlEYlRE?= =?utf-8?B?QWNuSnZrelZza1Z2RGNmcjZRTW0relZKdjg0TXNFdzBLb1MvVzFaY2NSR0Ir?= =?utf-8?B?eDB5aTBJc3VJS3dGNUxlZmtTWXNwMWhjbTl6RUg4ckM5dHplVkRGcWdJNWpy?= =?utf-8?B?MzNZTnNsVHdoTGU3L1MyZWZtV0ZPNWkvRWVZNENiV0lOb1VyOVVYQ0wycm1Q?= =?utf-8?B?a3duckRUZmR3ZDRacWhBcFRDdXF0a1J2ME1Vd0pWNlozRXNleHlhQVMwMG10?= =?utf-8?B?QVQ0aVRIYzUxeElBaHViSjBQZ1ZUQUUrUE50YkIrTDdhR244ZmU1dzUydUll?= =?utf-8?B?cXo1RUI3K3lVbTZ3UXR3MGlRNUkzQ25SLzI0YjJHTmo3R29BS3FTTUhzbUMw?= =?utf-8?B?bDVKa21aeGIwRzhHcEtPR3pkK0FoSC9UOVljNWJDK2ZnZ0RXT3UveEZRbm1D?= =?utf-8?B?amlrZDNFRDJxR1NIUkhpMlBONEhxR1BTK2NFM1ZqM3BmalhSeWp5dy9wVDJU?= =?utf-8?B?d0lwSVZONEhPRHhsc1NzZ0hlM3Q4OVhhc1Brb2QrQWE1WWk0YjRqOE5ZQ21W?= =?utf-8?B?SlRMa051MnhNSm1UVXVLdXNuYkFOdE9TcG55S0hLNHZjY1hwZW1OQ2w2TTlP?= =?utf-8?B?Tm5UZklXamZTa0V4eDFmbkorNEdhTmtLOHdkMC9QbHZ0SEVKaWtyS2RKVWla?= =?utf-8?B?SjJQUGVhYVc1WmdnUzhTS09iVTBIWHp5UVJSaExvMmFhZSs2NE1MZE9Cc3Bt?= =?utf-8?B?OXQ3Tk90eEJkZTEwVjNjZUduUENlZERsc2p0WFB2aGJaRThYVDRBT3VUNXFl?= =?utf-8?B?anc5SDFCaFovbkFkbWxTaVl1L09FbmlZN25QT28rZUlhUmsvMmlIRXcxbDd4?= =?utf-8?B?ZXFOdEFpWU1CTXNld05iSFVBMXpTc1NJeWgxWTFLTnczakNzMURqL1FxRW9F?= =?utf-8?B?aFZUSVQxZ3VmRTZ5YmEzdXA1VEVPaHIwc2tLZWZEQit4VHRKV1FCYzQzYTJR?= =?utf-8?B?TmFjbEZwZWlZaUhLckdlYUNsaFp0Y015bk9kR0Zpc1pDbU5JRU1IUWxFdklJ?= =?utf-8?B?dzV1b21VZGYwYlZ5TXFoSzRhYWdUKzM3TXdhQlRGQ2hoR3JUTS92THZsTkJ0?= =?utf-8?Q?H+k9G7d1t8WzuqyTYFQlhldGzw?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0301MB0703; 3:m4xljx7lAK3sKwZXWF49TfB/oAyoOjJApMSEyvKioP8E8cwSzI2Fxx4Ja8fq2r63207FmmyQ4CjvJDwhjxqUkuhiJZMqOtIVUXBcmq446mC9ADoNORR7LuRmGiMHaEPrwSnSJP7d1q0xeqPp+tTXSg==; 10:nALq7hNEYdIeqhjtA2+4wGv7Bfp/Z+Fu/+Mhyfbnu/0XtZKc6gAF4AWCv76i4dMBqwj8G/dgKuGkwpw0ibo6i6NriVHmHOGy+ZkO5Wl/QMY=; 6:MNW81YD+BY08RUSQwrzICiRz1Eo1UQ6oDXd8dWKu1PHEZTPiqfK08lVIkB8ZDbb/ X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jun 2015 16:34:41.6272 (UTC) X-MS-Exchange-CrossTenant-Id: 710a03f5-10f6-4d38-9ff4-a80b81da590d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=710a03f5-10f6-4d38-9ff4-a80b81da590d; Ip=[192.88.158.2]; Helo=[az84smr01.freescale.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0703 Cc: "meta-freescale@yoctoproject.org" , Otavio Salvador Subject: Re: [PATCH] fsl-eula-unpack: deploy Freescale EULA X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 16:34:49 -0000 Content-Type: multipart/alternative; boundary="------------010606080401000606070305" --------------010606080401000606070305 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit 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 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 >>> 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/ --------------010606080401000606070305 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

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