INCOMPATIBLE_LICENSE mechanism

INCOMPATIBLE_LICENSE mechanism

[Jonathan Haigh]

[-- Attachment #1: Type: text/plain, Size: 4438 bytes --]

 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.

[-- Attachment #2: Type: text/html, Size: 6491 bytes --]

Re: INCOMPATIBLE_LICENSE mechanism

[Peter Kjellerstedt]

[-- Attachment #1: Type: text/plain, Size: 5924 bytes --]

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@lists.openembedded.org <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 <Jeremy.Johnson@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.

[-- Attachment #2: Type: text/html, Size: 17204 bytes --]

Re: INCOMPATIBLE_LICENSE mechanism

[Richard Purdie]

On Thu, 2018-07-26 at 13:16 +0000, Peter Kjellerstedt wrote:
> 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).

Just thinking out loud you could have something like a 

gplv3-license-incompatible.inc:

LICENSE_pn-<some-recipe> = "MIT"
LICENSE_pn-<some--other-recipe> = "GPLv2"
INCOMPATIBLE_LICENSE = "GPLv3"

i.e. just force the license of a set of recipes to values known to work
 with GPLv3 exclusion?

Cheers,

Richard

Re: INCOMPATIBLE_LICENSE mechanism

[Peter Kjellerstedt]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org <openembedded-
> core-bounces@lists.openembedded.org> On Behalf Of Richard Purdie
> Sent: den 26 juli 2018 18:14
> To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>; Jonathan Haigh
> <Jonathan.Haigh@arm.com>; openembedded-core@lists.openembedded.org
> Cc: Jeremy Johnson <Jeremy.Johnson@arm.com>
> Subject: Re: [OE-core] [oe-core] INCOMPATIBLE_LICENSE mechanism
> 
> On Thu, 2018-07-26 at 13:16 +0000, Peter Kjellerstedt wrote:
> > 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).
> 
> Just thinking out loud you could have something like a
> 
> gplv3-license-incompatible.inc:
> 
> LICENSE_pn-<some-recipe> = "MIT"
> LICENSE_pn-<some--other-recipe> = "GPLv2"
> INCOMPATIBLE_LICENSE = "GPLv3"
> 
> i.e. just force the license of a set of recipes to values known to work
>  with GPLv3 exclusion?
> 
> Cheers,
> 
> Richard

Yes, I know. However, the idea with USED_LICENSE was the validation, that it 
contains one of the allowed licenses listed in LICENSE. I.e., if LICENSE is 
changed and the USED_LICENSE no longer validates, then there would be a build 
error. Without this, if we set LICENSE as per above, and the actual licensing 
changes, there is a great risk that we do not notice this and continues to 
use the code as per the old license.

//Peter

Re: INCOMPATIBLE_LICENSE mechanism

[Paul Eggleton]

On Thursday, 26 July 2018 5:14:05 PM BST Richard Purdie wrote:
> On Thu, 2018-07-26 at 13:16 +0000, Peter Kjellerstedt wrote:
> > 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).
> 
> Just thinking out loud you could have something like a 
> 
> gplv3-license-incompatible.inc:
> 
> LICENSE_pn-<some-recipe> = "MIT"
> LICENSE_pn-<some--other-recipe> = "GPLv2"
> INCOMPATIBLE_LICENSE = "GPLv3"

That was my first thought, but the issue is that you won't get any warning in 
future if the LICENSE value within the recipe changes to no longer provide the 
option you've selected. 

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: INCOMPATIBLE_LICENSE mechanism

[Richard Purdie]

On Thu, 2018-07-19 at 15:08 +0000, Jonathan Haigh wrote:
> 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?

RRECOMMENDS are a runtime setting and something that the package
manager cares about. From bitbake's perspective, a RRECOMMEND and an
RDEPEND are the same thing.

This is done mainly for build determinism, we can't just sometimes
decide to build a recommendation but sometimes not (for example if its
build failed).

So the behaviour is intentional at one level but obviously the
implications for INCOMPATIBLE_LICENSE are problematic.

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

The code there is simplistic and tries to spot "obvious" problems. As
you point out, its not entirely accurate. I'd very much like to see it
improved.

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

If you remove it, I'm not sure the situation improves much. I think
originally the idea was to be able to dial in a license policy such
that it would flag whichever combinations were problematic and
configured as incompatible.

Perhaps a better idea would be a new check in insane.bbclass which
checks the things a package is depending upon and considers and warns
about known problematic licensing. The list of licenses it was using
could then be influences by INCOMPATIBLE_LICENSE and you would get the
result you're looking for, admittedly at build time rather than parse
time but its better than nothing.

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

INCOMPATIBLE_LICENSE is a "hammer" approach which removes many recipes
from the view of the system entirely. That was the way some legal
departments wanted it to work.

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

Please!

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

This is potentially more problematic than you realise.

> Don't take "or" operands into account when checking for incompatible
> licenses.

I don't agree with this, I think we need to improve the code to handle
this better though.

> Add functionality to allow INCOMPATIBLE_LICENSE to just apply to
> packages/recipes that go into a particular image.

That is using it for something quite different from its original deisgn
intent.

> Don't modify package/recipe license expressions in the manifest
> files.

This is done because that file may be used as a basis to provide
something to a legal department and if you're not meant to be shipping
GPLv3, listing it in the manifest would cause more confusion. I can see
this from both sides...

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

See above, I've tried to explain the challenge there!

I would much rather see the existing mechanisms improved than adding
extra classes or new ones but there are reasons for some of why it
works the way it does.

Cheers,

Richard

Re: INCOMPATIBLE_LICENSE mechanism

[Jonathan Haigh]

>> 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?
>
> RRECOMMENDS are a runtime setting and something that the package
> manager cares about. From bitbake's perspective, a RRECOMMEND and an
> RDEPEND are the same thing.
>
> This is done mainly for build determinism, we can't just sometimes
> decide to build a recommendation but sometimes not (for example if its
> build failed).
>
> So the behaviour is intentional at one level but obviously the
> implications for INCOMPATIBLE_LICENSE are problematic.
>
>> 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.
>
> The code there is simplistic and tries to spot "obvious" problems. As
> you point out, its not entirely accurate. I'd very much like to see it
> improved.
>
>> 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.
>
> If you remove it, I'm not sure the situation improves much. I think
> originally the idea was to be able to dial in a license policy such
> that it would flag whichever combinations were problematic and
> configured as incompatible.
>
> Perhaps a better idea would be a new check in insane.bbclass which
> checks the things a package is depending upon and considers and warns
> about known problematic licensing. The list of licenses it was using
> could then be influences by INCOMPATIBLE_LICENSE and you would get the
> result you're looking for, admittedly at build time rather than parse
> time but its better than nothing.
>
>>  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.
>
> INCOMPATIBLE_LICENSE is a "hammer" approach which removes many recipes
> from the view of the system entirely. That was the way some legal
> departments wanted it to work.
>
>> 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.
>
> Please!
>
>> 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.
>
> This is potentially more problematic than you realise.
>
>> Don't take "or" operands into account when checking for incompatible
>> licenses.
>
> I don't agree with this, I think we need to improve the code to handle
> this better though.
>
>> Add functionality to allow INCOMPATIBLE_LICENSE to just apply to
>> packages/recipes that go into a particular image.
>
> That is using it for something quite different from its original deisgn
> intent.
>
>> Don't modify package/recipe license expressions in the manifest
>> files.
>
> This is done because that file may be used as a basis to provide
> something to a legal department and if you're not meant to be shipping
> GPLv3, listing it in the manifest would cause more confusion. I can see
> this from both sides...
>
>> 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.
>
> See above, I've tried to explain the challenge there!
>
> I would much rather see the existing mechanisms improved than adding
> extra classes or new ones but there are reasons for some of why it
> works the way it does.
>
> Cheers,
>
> Richard

Thanks for the information Richard.

I need to think about this some more, but I suspect INCOMPATIBLE_LICENSE is
just not the right tool for what I want to achieve - it works at the recipe
level but I'm more interested in licensing at the package level and what
actually ends up in final image(s).

I still don't think choosing "or" branches of license expressions to satisfy
INCOMPATIBLE_LICENSE is a good idea though, at least at the recipe level. In
order to be able to confidently choose between alternative licenses for a
recipe or package, you'd have to be sure that the chosen license was compatible
with the licenses of everything else that might have something to say about it
(practically speaking, anything that might link with something in the
recipe/package). Doing that when the recipe is first being built sounds very
tricky to me. Doing checks like that later when a rootfs or disk image is being
created seems much more feasible.

I've posted a patch on the oe-core list for the map() return value issue I
mentioned.

Regards,

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.