From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bastet.se.axis.com (bastet.se.axis.com [195.60.68.11]) by mail.openembedded.org (Postfix) with ESMTP id E363078C0D for ; Thu, 26 Jul 2018 13:16:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by bastet.se.axis.com (Postfix) with ESMTP id 09EE41858F; Thu, 26 Jul 2018 15:16:05 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at bastet.se.axis.com Received: from bastet.se.axis.com ([IPv6:::ffff:127.0.0.1]) by localhost (bastet.se.axis.com [::ffff:127.0.0.1]) (amavisd-new, port 10024) with LMTP id LfdY3iWYe5vr; Thu, 26 Jul 2018 15:16:02 +0200 (CEST) Received: from boulder03.se.axis.com (boulder03.se.axis.com [10.0.8.17]) by bastet.se.axis.com (Postfix) with ESMTPS id C449A1858A; Thu, 26 Jul 2018 15:16:02 +0200 (CEST) Received: from boulder03.se.axis.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 823F91E088; Thu, 26 Jul 2018 15:16:02 +0200 (CEST) Received: from boulder03.se.axis.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 75CDA1E083; Thu, 26 Jul 2018 15:16:02 +0200 (CEST) Received: from seth.se.axis.com (unknown [10.0.2.172]) by boulder03.se.axis.com (Postfix) with ESMTP; Thu, 26 Jul 2018 15:16:02 +0200 (CEST) Received: from XBOX02.axis.com (xbox02.axis.com [10.0.5.16]) by seth.se.axis.com (Postfix) with ESMTP id 68AC41CBC; Thu, 26 Jul 2018 15:16:02 +0200 (CEST) Received: from XBOX02.axis.com (10.0.5.16) by XBOX02.axis.com (10.0.5.16) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 26 Jul 2018 15:16:02 +0200 Received: from XBOX02.axis.com ([fe80::50c3:4d2f:4507:7776]) by XBOX02.axis.com ([fe80::50c3:4d2f:4507:7776%21]) with mapi id 15.00.1365.000; Thu, 26 Jul 2018 15:16:02 +0200 From: Peter Kjellerstedt To: Jonathan Haigh , "openembedded-core@lists.openembedded.org" Thread-Topic: [oe-core] INCOMPATIBLE_LICENSE mechanism Thread-Index: AQHUH2P1ipMkerX65UWFRjBAEJC/rqSWocT7gArf4mA= Date: Thu, 26 Jul 2018 13:16:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.0.5.60] MIME-Version: 1.0 X-TM-AS-GCONF: 00 Cc: Jeremy Johnson Subject: Re: INCOMPATIBLE_LICENSE mechanism X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 13:16:05 -0000 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_d7450c2b26f644358476ea6ec27717b6XBOX02axiscom_" --_000_d7450c2b26f644358476ea6ec27717b6XBOX02axiscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is related to a similar problem we are seeing with the use of "or" for= licenses. We use the archiver.bbclass to export all open source code we us= e. However, for recipes that specify multiple licenses using "or", we would= like to specify the one under which we are using the code. E.g., if the LI= CENSE is "GPL-2.0 | Proprietary", we would like to treat the code as "Propr= ietary", but when it comes to the archiver.bbclass, even if we have told it= to ignore packages with Proprietary licenses, it will include the package = due to the alternative GPL-2.0 license. The idea we have is to allow to specify a USED_LICENSE (e.g., in a bbappend= or a separate configuration file), which should take the actually used lic= ense. This should be verified to be one of the allowed licenses specified i= n LICENSE (in case LICENSE changes and no longer allows the chosen license)= , and after that, LICENSE should be treated as if this was the value it had= been given. This does, however, not take into account the use of the same= package in multiple images with different licensing requirements (we only = build one image so that is not a problem for us). //Peter From: openembedded-core-bounces@lists.openembedded.org On Behalf Of Jonathan Haigh Sent: den 19 juli 2018 17:08 To: openembedded-core@lists.openembedded.org Cc: Jeremy Johnson Subject: [OE-core] [oe-core] INCOMPATIBLE_LICENSE mechanism Hi, I have some questions, comments and suggestions about the INCOMPATIBLE_LICE= NSE mechanism: 1. If I specify licenseX in INCOMPATIBLE_LICENSE then I get an error when b= uilding a recipe with a package (packageA) that just RRECOMMENDS a package = (packageB) with licenceX, even if I add packageB to BAD_RECOMMENDATIONS_pn-= packageA. Am I correct in thinking that this behaviour is unintentional? 2. When checking whether a license expression is compatible with INCOMPATIB= LE_LICENSE, the code takes into account "or" operands in the license expres= sion, such that if licenseX is in INCOMPATIBLE_LICENSE but licenseY isn't, = and a package's license expression is "licenseX | licenseY" then the licens= e will be deemed okay even though licenseX is incompatible. I don't think t= his consideration of "or" operands is valid. Consider the case where: * packageA has license expression "LGPLv3 | GPLv2; * packageB has license expression "MIT"; * packageB dynamically links with packageA; * INCOMPATIBLE_LICENSE =3D "LGPL-3.0". PackageB mustn't be using packageA under the terms of the GPLv2 because the= resulting combination would have to be GPLv2, not MIT, to comply with the = terms of the GPLv2. PackageB must therefore be using packageA under the ter= ms of the LGPLv3, but LGPL-3.0 is in INCOMPATIBLE_LICENSE, so the combinati= on should be rejected. Actually keeping track of how licenses of packages and their dependents int= eract might be too much work, too messy, or require too much legal knowledg= e, so I suggest this special treatment of "or" operands in license expressi= ons is removed. Another approach might be to allow packages explicitly decl= are the licenses under which they are using their rdependencies. That would= n't work nicely with the implicit RDEPENDS addition mechanism though. 3. If I understand correctly, INCOMPATIBLE_LICENSE doesn't let me have diff= erent license policies for packages that go into different images. It would= be useful to be able to specify INCOMPATIBLE_LICENSE in an image recipe to= prevent just that image containing packages/recipes with incompatible lice= nses. This would be useful e.g. to have a GPLv3-free production image but a= llow GPLv3 packages in a debug image. 4. From the code in license.bbclass, it looks like when writing the rootfs = and image manifest files, the intended behaviour is to modify the license e= xpressions of packages/recipes by removing incompatible "or" branches (whic= h seems a little odd, especially given #2). However, this is not the actual= behaviour of the code when run with Python3. From write_license_files() in= license.bbclass: bad_licenses =3D (d.getVar("INCOMPATIBLE_LICENSE") or "").split() bad_licenses =3D map(lambda l: canonical_license(d, l), bad_licenses) bad_licenses =3D expand_wildcard_licenses(d, bad_licenses) expand_wildcard_licenses() expects a list, but in Python3 map() returns som= e sort of iterator, which causes expand_wildcard_licenses() to return an em= pty list. This can be fixed by wrapping the call to map() in a call to list= (). I'll send a patch for this. I have a bbclass that adds license checking at the rootfs/image stage and d= oesn't take into account the "or" operands in license expressions, but I th= ink it would be better to change/extend the functionality of the INCOMPATIB= LE_LICENSE mechanism. Do the oe-core maintainers here agree with the follow= ing approach? * Don't fail a build if a package just RRECOMMENDs another package with= an incompatible license, only fail if the package is actually built. * Don't take "or" operands into account when checking for incompatible = licenses. * Add functionality to allow INCOMPATIBLE_LICENSE to just apply to pack= ages/recipes that go into a particular image. * Don't modify package/recipe license expressions in the manifest files= . If so, I'd like to contribute patches to do this. I'm not at all familiar w= ith how the RRECOMMENDS mechanism works though, so some guidance on that pa= rt would be useful. Thanks for all the work being done on OE, it is much appreciated. Jonathan IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_d7450c2b26f644358476ea6ec27717b6XBOX02axiscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is related to a similar problem we are seeing with= the use of “or” for licenses. We use the archiver.bbclass to e= xport all open source code we use. However, for recipes that specify multiple licenses using “or”, we would like to sp= ecify the one under which we are using the code. E.g., if the LICENSE is &#= 8220;GPL-2.0 | Proprietary”, we would like to treat the code as ̶= 0;Proprietary”, but when it comes to the archiver.bbclass, even if we have told it to ignore packages with Proprietary licenses, it will i= nclude the package due to the alternative GPL-2.0 license.

 

The idea we have is to allow to specify a USED_LICENSE = (e.g., in a bbappend or a separate configuration file), which should take t= he actually used license. This should be verified to be one of the allowed licenses specified in LICENSE (in cas= e LICENSE changes and no longer allows the chosen license), and after that,= LICENSE should be treated as if this was the value it had been given. This= does, however,  not take into account the use of the same package in multiple images with different licensing re= quirements (we only build one image so that is not a problem for us).<= /o:p>

 

//Peter

 

From: openembedded-core-bounces@lists.openembedded.org <openembedd= ed-core-bounces@lists.openembedded.org> On Behalf Of Jonathan Haigh
Sent: den 19 juli 2018 17:08
To: openembedded-core@lists.openembedded.org
Cc: Jeremy Johnson <Jeremy.Johnson@arm.com>
Subject: [OE-core] [oe-core] INCOMPATIBLE_LICENSE mechanism

 

 H= i,

 

I have some questions, comm= ents and suggestions about the INCOMPATIBLE_LICENSE mechanism:

 

1. If I specify licenseX in= INCOMPATIBLE_LICENSE then I get an error when building a recipe with a pac= kage (packageA) that just RRECOMMENDS a package (packageB) with licenceX, e= ven if I add packageB to BAD_RECOMMENDATIONS_pn-packageA. Am I correct in thinking that this behaviour is unintentional?<= /span>

 

2. When checking whether a = license expression is compatible with INCOMPATIBLE_LICENSE, the code takes = into account "or" operands in the license expression, such that i= f licenseX is in INCOMPATIBLE_LICENSE but licenseY isn't, and a package's license expression is "licenseX | licenseY&quo= t; then the license will be deemed okay even though licenseX is incompatibl= e. I don't think this consideration of "or" operands is valid. Co= nsider the case where:

  • packageA has license expression "LGPL= v3 | GPLv2;
  • packageB has license expression "MIT&= quot;;
  • packageB dynamically links with packageA;<= o:p>
  • INCOMPATIBLE_LICENSE =3D "LGPL-3.0&qu= ot;.

PackageB mustn't be using p= ackageA under the terms of the GPLv2 because the resulting combination woul= d have to be GPLv2, not MIT, to comply with the terms of the GPLv2. Package= B must therefore be using packageA under the terms of the LGPLv3, but LGPL-3.0 is in INCOMPATIBLE_LICENSE, so= the combination should be rejected.

 

Actually keeping track of h= ow licenses of packages and their dependents interact might be too much wor= k, too messy, or require too much legal knowledge, so I suggest this specia= l treatment of "or" operands in license expressions is removed. Another approach might be to allow packages explic= itly declare the licenses under which they are using their rdependencies. T= hat wouldn't work nicely with the implicit RDEPENDS addition mechanism thou= gh.

 

3. If I understand correctl= y, INCOMPATIBLE_LICENSE doesn't let me have different license policies for = packages that go into different images. It would be useful to be able to sp= ecify INCOMPATIBLE_LICENSE in an image recipe to prevent just that image containing packages/recipes with incompa= tible licenses. This would be useful e.g. to have a GPLv3-free production i= mage but allow GPLv3 packages in a debug image.

 

4. From the code in license= .bbclass, it looks like when writing the rootfs and image manifest files, t= he intended behaviour is to modify the license expressions of packages/reci= pes by removing incompatible "or" branches (which seems a little odd, especially given #2). However, this is= not the actual behaviour of the code when run with Python3. From write_lic= ense_files() in license.bbclass:

&n= bsp;

 &= nbsp;  bad_licenses =3D (d.getVar("INCOMPATIBLE_LICENSE") or= "").split()
    bad_licenses =3D map(lambda l: canonical_license(d, l), = bad_licenses)
    bad_licenses =3D expand_wildcard_licenses(d, bad_license= s)

&n= bsp;

expand_= wildcard_licenses() expects a list, but in Python3 map() returns some sort = of iterator, which causes expand_wildcard_licenses() to return an empty lis= t. This can be fixed by wrapping the call to map() in a call to list(). I'll send a patch for this.<= /span>

&n= bsp;

&n= bsp;

I have = a bbclass that adds license checking at the rootfs/image stage and doesn't = take into account the "or" operands in license expressions, but I= think it would be better to change/extend the functionality of the INCOMPATIBLE_LICENSE mechanism. Do the oe-core mainta= iners here agree with the following approach?

  • Don't fail a build if a package just RRECO= MMENDs another package with an incompatible license, only fail if the packa= ge is actually built.
  • Don't take "or" operands into ac= count when checking for incompatible licenses.
  • Add functionality to allow INCOMPATIBLE_LI= CENSE to just apply to packages/recipes that go into a particular image.
  • Don't modify package/recipe license expres= sions in the manifest files.

If so, = I'd like to contribute patches to do this. I'm not at all familiar with how= the RRECOMMENDS mechanism works though, so some guidance on that part woul= d be useful.

&n= bsp;

Thanks = for all the work being done on OE, it is much appreciated.

&n= bsp;

Jonatha= n

IMPORTANT NOTICE: The contents of this email and any= attachments are confidential and may also be privileged. If you are not th= e intended recipient, please notify the sender immediately and do not discl= ose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Th= ank you.

--_000_d7450c2b26f644358476ea6ec27717b6XBOX02axiscom_--