[meta-freescale] [fsl-community-bsp-base][PATCH v2] setup-environment: Update pre-EULA language to support older licenses.

[Stefan Christ]

Hi,

> Any proposed multi-EULA system must provide, at least:
 
I think that's the main point of the discussion and the confusion. The current
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_FILES_CHKSUM variables:

    LIC_FILES_CHKSUM = "file://COPYING;md5=acdb807ac7275fe32f9f64992e111241"

That is, I think, the correct behaviour

Other recipes don't do this like 'imx-gpu-viv'. The recipe only contains

    LIC_FILES_CHKSUM = "file://gpu-core/usr/include/gc_vdk.h;beginline=5;endline=11;md5=12c028cbbbedb4b8770267131500592c"

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 that
single EULA whether or not the software tarball contains the exact same copy 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_FLAGS mechanism [1] in Yocto can be
used for that. It also supports some sort wild-care enabling to accept a range
of licences, but that is transparent to the user.

Mit freundlichen Grüßen / Kind regards,
	Stefan Christ

[1] http://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html#enabling-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 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: otavio.salvador at gmail.com [mailto:otavio.salvador at gmail.com] On Behalf Of Otavio Salvador
> Sent: Monday, June 08, 2015 8:28 AM
> To: Post Lauren-RAA013
> Cc: Daiane Angolini; meta-freescale at yoctoproject.org
> 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 <Lauren.Post at freescale.com> 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
> meta-freescale at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale