I've discussed with our lawyer and she is willing to change language to avoid this confusion both you and Daiane have about Open source.
The lawyer used to create the original language is not here and the license has evolved since the initial language was created. We must use the new language provided by our current lawyer. The changes in this patch proposed do not affect any bug fixes I'm sending a v3 of this patch with the updated language. Regarding the fsl-eula-unpack class patch, the license checksum in the recipe should take precedence. Does it work this way in the latest patch? Lauren -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Otavio Salvador Sent: Monday, June 08, 2015 8:28 AM To: Post Lauren-RAA013 Cc: Daiane Angolini; [email protected] Subject: Re: [meta-freescale] [fsl-community-bsp-base][PATCH v2] setup-environment: Update pre-EULA language to support older licenses. Dear Lauren, On Fri, Jun 5, 2015 at 2:56 PM, Lauren Post <[email protected]> wrote: > 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 not > work. 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 binaries we have in use now. When Daiane, Yi and I, back in 2011 and 2012, had all discussions with Freescale legal's team to find a more user-friendly 'click-through' way the current mechanism has been proposed, reviewed and approved. I understand Freescale is planning changes in this regard but those changes need to be properly proposed and reviewed, and most important, those change must not impact the bugfixes needed today. I understand the legal terms can change, but the patches you are proposing does not really align with what you are saying the change is. 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 all 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 accept something we cannot have a full view. Any proposed multi-EULA system must provide, at least: a proper "click-through" mechanism for each EULA (as I still didn't see where 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 its creation in 2010 so there is no good reason to not reuse all this background experience from the community with a homemade solution. 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 technical details and it took a considerable time to make them to proper understand all the implications and details. I fear you'll need to pass all the pain we passed back then, once again. 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 -- _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
