[OE-core] [oe-core] INCOMPATIBLE_LICENSE mechanism

Thu Jul 26 13:16:02 UTC 2018

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.

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).

//Peter

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

 Hi,

I have some questions, comments 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 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 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:

  *   packageA has license expression "LGPLv3 | GPLv2;
  *   packageB has license expression "MIT";
  *   packageB dynamically links with packageA;
  *   INCOMPATIBLE_LICENSE = "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 terms of the LGPLv3, but LGPL-3.0 is in INCOMPATIBLE_LICENSE, so the combination should be rejected.

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.

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.

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:

    bad_licenses = (d.getVar("INCOMPATIBLE_LICENSE") or "").split()
    bad_licenses = map(lambda l: canonical_license(d, l), bad_licenses)
    bad_licenses = expand_wildcard_licenses(d, bad_licenses)

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.

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?

  *   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 packages/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 with how the RRECOMMENDS mechanism works though, so some guidance on that part 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 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180726/148ce909/attachment-0002.html>