Hi

"It is over. There are no excuses left if you are still using meta-gplv2."
-- https://twitter.com/yoctoproject/status/1552209990148145153
"There are other ways of removing GPLv3 components from modern OE/YP builds and we'd like to focus people's attention onto those."
-- https://git.yoctoproject.org/meta-gplv2/commit/?id=43bf0e8d5985945d19d01f94bfbbda420c4435f3

Where can we find more details re the best ways of removing GPLv3 components please?

Or, starting with a clean slate and adding back only what we actually need (for i.MX 8X and Qt Commercial).

Have tried searching, but going round in circles, as all the results so far still point back to meta-gplv2.
Including the "How do I":
"If you use INCOMPATIBLE_LICENSE to exclude GPLv3 or set PREFERRED_VERSION to substitute a GPLv2 version of a GPLv3 recipe, then you must add the meta-gplv2 layer to your configuration."
-- https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_build_an_image_without_GPLv3_Licensed_packages_.3F

The context is that some of our customers require Secure Boot and Chain of Trust (in an embedded environment).
If we keep GPLv3 components, then we need to provide "any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work".

Thank you
-- Peter

"It is over. There are no excuses left if you are still using meta-gplv2."
-- https://twitter.com/yoctoproject/status/1552209990148145153
"There are other ways of removing GPLv3 components from modern OE/YP builds and we'd like to focus people's attention onto those."
-- https://git.yoctoproject.org/meta-gplv2/commit/?id=43bf0e8d5985945d19d01f94bfbbda420c4435f3

Where can we find more details re the best ways of removing GPLv3 components please?

Or, starting with a clean slate and adding back only what we actually need (for i.MX 8X and Qt Commercial).

Have tried searching, but going round in circles, as all the results so far still point back to meta-gplv2.
Including the "How do I":
"If you use INCOMPATIBLE_LICENSE to exclude GPLv3 or set PREFERRED_VERSION to substitute a GPLv2 version of a GPLv3 recipe, then you must add the meta-gplv2 layer to your configuration."
-- https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_build_an_image_without_GPLv3_Licensed_packages_.3F

The context is that some of our customers require Secure Boot and Chain of Trust (in an embedded environment).
If we keep GPLv3 components, then we need to provide "any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work".

On Thu, 6 Oct 2022 at 15:27, Peter via lists.yoctoproject.org
<poberauer=yahoo.co.uk@...> wrote:

"It is over. There are no excuses left if you are still using meta-gplv2."
-- https://twitter.com/yoctoproject/status/1552209990148145153
"There are other ways of removing GPLv3 components from modern OE/YP builds and we'd like to focus people's attention onto those."
-- https://git.yoctoproject.org/meta-gplv2/commit/?id=43bf0e8d5985945d19d01f94bfbbda420c4435f3

Where can we find more details re the best ways of removing GPLv3 components please?

Or, starting with a clean slate and adding back only what we actually need (for i.MX 8X and Qt Commercial).

Have tried searching, but going round in circles, as all the results so far still point back to meta-gplv2.
Including the "How do I":
"If you use INCOMPATIBLE_LICENSE to exclude GPLv3 or set PREFERRED_VERSION to substitute a GPLv2 version of a GPLv3 recipe, then you must add the meta-gplv2 layer to your configuration."
-- https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_build_an_image_without_GPLv3_Licensed_packages_.3F

The context is that some of our customers require Secure Boot and Chain of Trust (in an embedded environment).
If we keep GPLv3 components, then we need to provide "any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work".

The suggested way nowadays is to set INCOMPATIBLE_LICENSE only for the
image that is actually going to ship in a product, then work your way
throgh specific gpl3 dependencies that get pulled in, and eliminate
them one by one - precisely how is impossible to tell beforehands, but
typical problems are bash scripts (which you need to package
separately and not include into the product, or rewrite in posix shell
and use #!/bin/sh), or optional dependencies on things like readline,
which can be switched off via PACKAGECONFIG tweaks.

Thank you for the replies, Alex and Michael.
Have joined the docs list.
Couple of related threads for reference:
https://lists.yoctoproject.org/g/yocto/topic/question_how_to_handle/90285507
https://lists.yoctoproject.org/g/yocto/topic/incompatible_license_how_to/75210517

Thank you
-- Peter

Thank you for the replies, Alex and Michael.
Have joined the docs list.
Couple of related threads for reference:
https://lists.yoctoproject.org/g/yocto/topic/question_how_to_handle/90285507
https://lists.yoctoproject.org/g/yocto/topic/incompatible_license_how_to/75210517

Thank you
-- Peter

Hi Alex and Michael

Thank you very much, that worked for core-image-minimal and core-image-weston, with kirkstone-4.0.4

For core-image-weston, copying the "Settings for weston" from incompatible_lic.py#n149 works.
And core-image-minimal works automatically with just INCOMPATIBLE_LICENSE:pn-core-image-minimal = "GPL-3.0* LGPL-3.0* AGPL-3.0*"

Whereas, the global ban produced errors e.g.:
INCOMPATIBLE_LICENSE = "GPL-3.0* LGPL-3.0* AGPL-3.0*"
...
ERROR: Nothing RPROVIDES 'bash' (but /workdir/poky/poky/meta/recipes-devtools/opkg-utils/opkg-utils_0.5.0.bb, /workdir/poky/poky/meta/recipes-devtools/python/python3_3.10.4.bb RDEPENDS on or otherwise requires it)
Missing or unbuildable dependency chain was: ['core-image-minimal', 'packagegroup-core-boot', 'update-alternatives-opkg', 'bash']

However, the documentation recommends the global ban and does not mention the per-image variant?
https://docs.yoctoproject.org/ref-manual/images.html
https://docs.yoctoproject.org/ref-manual/variables.html#term-INCOMPATIBLE_LICENSE

Out of curiosity, why does the per image variant work, but not the global ban?
And how should one know to use the pn- prefix? i.e.
this: INCOMPATIBLE_LICENSE:pn-core-image-minimal
not this: INCOMPATIBLE_LICENSE:core-image-minimal?

Thank you
-- Peter

However, the documentation recommends the global ban and does not mention the per-image variant?
https://docs.yoctoproject.org/ref-manual/images.html
https://docs.yoctoproject.org/ref-manual/variables.html#term-INCOMPATIBLE_LICENSE

Out of curiosity, why does the per image variant work, but not the global ban?

And how should one know to use the pn- prefix? i.e.
this: INCOMPATIBLE_LICENSE:pn-core-image-minimal
not this: INCOMPATIBLE_LICENSE:core-image-minimal?

On Mon, 24 Oct 2022 at 13:58, Peter via lists.yoctoproject.org
<poberauer=yahoo.co.uk@...> wrote:

However, the documentation recommends the global ban and does not mention the per-image variant?
https://docs.yoctoproject.org/ref-manual/images.html
https://docs.yoctoproject.org/ref-manual/variables.html#term-INCOMPATIBLE_LICENSE

Yes, someone should go over the documentation and change every mention
of this to recommend per-image variant, as a global one is basically
impossible to use without pulling in meta-gpl2. Patches welcome :)

Out of curiosity, why does the per image variant work, but not the global ban?

Global ban works at the task dependency creation stage, and if bash
needs to be built, it will throw an error, even if the actual bash
binary will not end up in the image, and is only used as a runtime
dependency for a package that won't be installed.
Per-image ban performs a 'late' check when the image is actually put together.

You should now know everything to fix the docs ;-)