Yes I know. Not sure why QC is stuck on Thud. Even newer releases from
QC for the target that we are working on is stuck at Thud.

Mans

Den fre 8 apr. 2022 kl 18:59 skrev Alexander Kanavin <alex.kanavin@...>:

Thud has been EOL for a long time. You can see when the support been
added here (end of 2019 it seems):
https://git.yoctoproject.org/poky/log/meta/lib/oeqa/selftest/cases/incompatible_lic.py?h=master-next

Alex

On Fri, 8 Apr 2022 at 18:56, Måns <mans.zigher@...> wrote:

I am currently on Thud so I am missing the support from what I can
tell to set INCOMPATIBLE_LICENSE per image. I have tried to find the
commit that adds that support but am having some problems finding it.
Do you maybe know what I should look for to find the commit that adds
this support?

Thanks

Den fre 8 apr. 2022 kl 10:16 skrev Alexander Kanavin <alex.kanavin@...>:

Hello Mans,

please refer to the tests we have for the feature:
https://git.yoctoproject.org/poky/tree/meta/lib/oeqa/selftest/cases/incompatible_lic.py?h=master-next#n95
(line 95 and below)

The key bit is:
INCOMPATIBLE_LICENSE:pn-core-image-minimal = "GPL-3.0* LGPL-3.0*"
e.g. apply the restriction only to core-image-minimal.

Alex

On Fri, 8 Apr 2022 at 08:06, Måns <mans.zigher@...> wrote:

Hi Alex,

Could you maybe clarify what you mean with "setting
INCOMPATIBLE_LICENSE per image"? Do you mean that you have one
specific image that is used when you build an image for release to the
customer and then one image for development?

Thanks

Den ons 6 apr. 2022 kl 11:04 skrev Alexander Kanavin <alex.kanavin@...>:

I'd suggest you start by setting INCOMPATIBLE_LICENSE per image, e.g.
enable gpl3 ban only in the images that ship to the customers and not
across the entire build. Then carefully look at what pulls in bash
into those images and why, and reconfigure those pieces to not do that
(e.g. by reconfiguring the PACKAGECONFIGs), or rewrite the scripts in
posix shell.

Alex

On Wed, 6 Apr 2022 at 10:59, Mans Zigher <mans.zigher@...> wrote:

Hi,

I cannot use GPLv3 packages in our image build. I am no legal expert
but from what I can understand most companies will not be able to
comply with this license without allowing the customer to compile and
deploy a new version of any GPLv3 package to the target. I know it is
possible to comply with this but we are using secure boot and have not
the time and probably no interest in setting up a solution for
allowing customers to be able to deploy GPLv3 packages on the target.
We are trying to make use of INCOMPATIBLE_LICENSE but that results in
several issues. We have made sure that we don't include GPLv3 in the
image build using a manual process but would like to use
INCOMPATIBLE_LICENSE to alert any developer about the issue. It seems
like INCOMPATIBLE_LICENSE is a bit harsh since it will catch any
packages even if it is only part of the SDK and also for native
packages that are not part of the image build.

I cannot be the only one with this problem so how are other companies
solving this issue? Are they just not using the INCOMPATIBLE_LICENSE?
Are you setting up a parallel process for checking for any
incompatible licenses issues?

A more specific issue is that there are so many packages with bash
dependencies which are pulling in bash which is GPLv3 so how have you
solved that? Currently we have done some pretty uggly hacks which I am
not that happy with but we needed to keep it out of the image.

Thanks