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-boun...@lists.openembedded.org
<openembedded-core-boun...@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.john...@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.
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
