From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 6CBB5E009C2; Wed, 10 Jun 2015 07:13:07 -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 autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] Received: from root.phytec.de (mail.phycard.de [217.6.246.34]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id BEE14E0095D for ; Wed, 10 Jun 2015 07:13:02 -0700 (PDT) Received: from idefix.phytec.de (idefix.phytec.de [172.16.0.10]) by root.phytec.de (Postfix) with ESMTP id 530B6A00345 for ; Wed, 10 Jun 2015 16:14:29 +0200 (CEST) Received: from lws-christ ([172.16.11.76]) by idefix.phytec.de (IBM Domino Release 9.0.1FP2 HF590) with ESMTP id 2015061016130091-84299 ; Wed, 10 Jun 2015 16:13:00 +0200 Date: Wed, 10 Jun 2015 16:13:00 +0200 From: Stefan Christ To: meta-freescale@yoctoproject.org Message-ID: <20150610141300.GC6447@lws-christ> References: <1433519858-30909-1-git-send-email-lauren.post@freescale.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-MIMETrack: Itemize by SMTP Server on Idefix/Phytec(Release 9.0.1FP2 HF590|December 11, 2014) at 10.06.2015 16:13:00, Serialize by Router on Idefix/Phytec(Release 9.0.1FP2 HF590|December 11, 2014) at 10.06.2015 16:13:01 Subject: Re: [fsl-community-bsp-base][PATCH v2] setup-environment: Update pre-EULA language to support older licenses. 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: Wed, 10 Jun 2015 14:13:07 -0000 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, > Any proposed multi-EULA system must provide, at least: =20 I think that's the main point of the discussion and the confusion. The curr= ent implementation in the fsl-community-bsp is a single-EULA system. The user accepts only a single EULA in setup-environment. But in fact every recipe which uses the "fsl-eula-unpack" bbclass downloads= a software tarball which may contain another version of the EULA. Some recipes like 'firmware-imx' (checked on fido) put the Licence/EULA from the software tarball in the LIC=5FFILES=5FCHKSUM variables: LIC=5FFILES=5FCHKSUM =3D "file://COPYING;md5=3Dacdb807ac7275fe32f9f6499= 2e111241" That is, I think, the correct behaviour Other recipes don't do this like 'imx-gpu-viv'. The recipe only contains LIC=5FFILES=5FCHKSUM =3D "file://gpu-core/usr/include/gc=5Fvdk.h;beginl= ine=3D5;endline=3D11;md5=3D12c028cbbbedb4b8770267131500592c" although there is a file 'COPYING' in the software tarball which contains a version of Freescale EULA. If it's a single-EULA system, the global EULA in "sources/meta-fsl-arm/EULA= ", which is presented to the user, should be deployed along the package (as my patch did). This also means that the all software is actually covered by th= at single EULA whether or not the software tarball contains the exact same cop= y of the EULA in the file COPYING. And my patch doesn't break any builds because= the md5sum is only checked against the global EULA file, not the actual EULA in= the downloaded software tarball. If it's a multi-EULA system, the user should be able to accept every EULA separately. The already mentioned LICENSE=5FFLAGS mechanism [1] in Yocto ca= n be used for that. It also supports some sort wild-care enabling to accept a ra= nge of licences, but that is transparent to the user. Mit freundlichen Gr=C3=BC=C3=9Fen / Kind regards, Stefan Christ [1] http://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html#enabl= ing-commercially-licensed-recipes On Mon, Jun 08, 2015 at 03:09:34PM +0000, Lauren Post wrote: > I've discussed with our lawyer and she is willing to change language to a= void this confusion both you and Daiane have about Open source. >=20 > The lawyer used to create the original language is not here and the licen= se has evolved since the initial language was created. >=20 > We must use the new language provided by our current lawyer. The changes= in this patch proposed do not affect any bug fixes >=20 > I'm sending a v3 of this patch with the updated language. >=20 > Regarding the fsl-eula-unpack class patch, the license checksum in the re= cipe should take precedence. Does it work this way in the latest patch? >=20 > Lauren >=20 > -----Original Message----- > From: otavio.salvador@gmail.com [mailto:otavio.salvador@gmail.com] On Beh= alf Of Otavio Salvador > Sent: Monday, June 08, 2015 8:28 AM > To: Post Lauren-RAA013 > Cc: Daiane Angolini; meta-freescale@yoctoproject.org > Subject: Re: [meta-freescale] [fsl-community-bsp-base][PATCH v2] setup-en= vironment: Update pre-EULA language to support older licenses. >=20 > Dear Lauren, >=20 > On Fri, Jun 5, 2015 at 2:56 PM, Lauren Post w= rote: > > Regardless, patch must be reverted or it causes build breaks on legacy = patches. > > > > We can think of another solution for Yocto 1.9 but current patch will n= ot work. >=20 > The Stefan patch shouldn't be reverted. He kindly provided the two other= patches to fix the build failure and I succeed in building the legacy bina= ries we have in use now. >=20 > When Daiane, Yi and I, back in 2011 and 2012, had all discussions with Fr= eescale legal's team to find a more user-friendly 'click-through' > way the current mechanism has been proposed, reviewed and approved. I un= derstand Freescale is planning changes in this regard but those changes nee= d to be properly proposed and reviewed, and most important, those change mu= st not impact the bugfixes needed today. >=20 > I understand the legal terms can change, but the patches you are proposin= g does not really align with what you are saying the change is. >=20 > If the Freescale legal's team is going to require multi-EULA support for = future releases, a new EULA mechanism must be proposed and reviewed, and al= l the needed information must be shared with community in order to get this= on the same level to the current technical solution. We cannot blindly ac= cept something we cannot have a full view. >=20 > Any proposed multi-EULA system must provide, at least: >=20 > a proper "click-through" mechanism for each EULA (as I still didn't see w= here is said in the EULA that it covers future and previous versions of it)= or clearly state this mechanism is not needed anymore. > do not reinvent the wheel for license management as the Yocto Project has= the mechanisms to handle this accordingly and it has been evolving since i= ts creation in 2010 so there is no good reason to not reuse all this backgr= ound experience from the community with a homemade solution. >=20 > When we had this discussion with the Freescale legal's team, back in 2011= , it was clear that they have some difficulties to understand all those tec= hnical details and it took a considerable time to make them to proper under= stand all the implications and details. I fear you'll need to pass all the = pain we passed back then, once again. >=20 > Regards, >=20 > --=20 > 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 > --=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > meta-freescale mailing list > meta-freescale@yoctoproject.org > https://lists.yoctoproject.org/listinfo/meta-freescale