<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#943634;
font-weight:normal;
font-style:normal;
text-decoration:none none;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1061832347;
mso-list-template-ids:-50672074;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1
{mso-list-id:1636445573;
mso-list-template-ids:-239069944;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="SV" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="color:#943634;mso-fareast-language:EN-US">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 use. 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 LICENSE is “GPL-2.0 | Proprietary”, we would like to treat the code as “Proprietary”, 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.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#943634;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#943634;mso-fareast-language:EN-US">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 license. This should
be verified to be one of the allowed licenses specified in 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).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#943634;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#943634;mso-fareast-language:EN-US">//Peter<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#943634;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> openembedded-core-bounces@lists.openembedded.org <openembedded-core-bounces@lists.openembedded.org>
<b>On Behalf Of </b>Jonathan Haigh<br>
<b>Sent:</b> den 19 juli 2018 17:08<br>
<b>To:</b> openembedded-core@lists.openembedded.org<br>
<b>Cc:</b> Jeremy Johnson <Jeremy.Johnson@arm.com><br>
<b>Subject:</b> [OE-core] [oe-core] INCOMPATIBLE_LICENSE mechanism<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div id="divtagdefaultwrapper">
<div>
<div id="divRplyFwdMsg">
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"> Hi, <o:p></o:p></span></p>
</div>
</div>
<div>
<div id="x_divtagdefaultwrapper">
<p><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
<p><span style="font-size:12.0pt;color:black">I have some questions, comments and suggestions about the INCOMPATIBLE_LICENSE mechanism:<o:p></o:p></span></p>
<p><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
<p><span style="font-size:12.0pt;color:black">1. If I specify licenseX in INCOMPATIBLE_LICENSE then I get an error when building 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?<o:p></o:p></span></p>
<p><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
<p><span style="font-size:12.0pt;color:black">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 if licenseX is in INCOMPATIBLE_LICENSE but licenseY
isn't, and a package's license expression is "licenseX | licenseY" then the license will be deemed okay even though licenseX is incompatible. I don't think this consideration of "or" operands is valid. Consider the case where:<o:p></o:p></span></p>
<ul type="disc">
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
<span style="font-size:12.0pt">packageA has license expression "LGPLv3 | GPLv2;<o:p></o:p></span></li><li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
<span style="font-size:12.0pt">packageB has license expression "MIT";<o:p></o:p></span></li><li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
<span style="font-size:12.0pt">packageB dynamically links with packageA;<o:p></o:p></span></li><li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
<span style="font-size:12.0pt">INCOMPATIBLE_LICENSE = "LGPL-3.0".<o:p></o:p></span></li></ul>
<p><span style="font-size:12.0pt;color:black">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 terms of the LGPLv3, but LGPL-3.0 is in INCOMPATIBLE_LICENSE, so the combination should be rejected.<o:p></o:p></span></p>
<p><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
<p><span style="font-size:12.0pt;color:black">Actually keeping track of how licenses of packages and their dependents interact might be too much work, too messy, or require too much legal knowledge, so I suggest this special treatment of "or" operands in license
expressions is removed. Another approach might be to allow packages explicitly declare the licenses under which they are using their rdependencies. That wouldn't work nicely with the implicit RDEPENDS addition mechanism though.<o:p></o:p></span></p>
<p><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
<p><span style="font-size:12.0pt;color:black">3. If I understand correctly, 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 specify INCOMPATIBLE_LICENSE in an image
recipe to prevent just that image containing packages/recipes with incompatible licenses. This would be useful e.g. to have a GPLv3-free production image but allow GPLv3 packages in a debug image.<o:p></o:p></span></p>
<p><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
<p><span style="font-size:12.0pt;color:black">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 expressions of packages/recipes 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_license_files() in license.bbclass:<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"> bad_licenses = (d.getVar("INCOMPATIBLE_LICENSE") or "").split()<br>
bad_licenses = map(lambda l: canonical_license(d, l), bad_licenses)<br>
bad_licenses = expand_wildcard_licenses(d, bad_licenses)<o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">expand_wildcard_licenses() expects a list, but in Python3 map() returns some sort of iterator, which causes expand_wildcard_licenses() to return an empty list. This can be fixed by wrapping the
call to map() in a call to list(). I'll send a patch for this.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">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 maintainers here agree with the following approach?<o:p></o:p></span></p>
</div>
<div>
<ul type="disc">
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo2">
<span style="font-size:12.0pt">Don't fail a build if a package just RRECOMMENDs another package with an incompatible license, only fail if the package is actually built.<o:p></o:p></span></li><li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo2">
<span style="font-size:12.0pt">Don't take "or" operands into account when checking for incompatible licenses.<o:p></o:p></span></li><li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo2">
<span style="font-size:12.0pt">Add functionality to allow INCOMPATIBLE_LICENSE to just apply to packages/recipes that go into a particular image.<o:p></o:p></span></li><li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo2">
<span style="font-size:12.0pt">Don't modify package/recipe license expressions in the manifest files.
<o:p></o:p></span></li></ul>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">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 would be useful.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">Thanks for all the work being done on OE, it is much appreciated.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">Jonathan<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal">IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please 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.
<o:p></o:p></p>
</div>
</div>
</body>
</html>