Bug 10733 - Licences copied into the image don't include firmware/kernel licences if not in the rootfs
Summary: Licences copied into the image don't include firmware/kernel licences if not ...
Status: NEW
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: deployment (show other bugs)
Version: unspecified
Hardware: x86 Multiple
: Medium normal
Target Milestone: 6.2
Assignee: Joshua Watt
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2016-11-28 15:05 UTC by Mariano Lopez
Modified: 2026-09-17 15:04 UTC (History)
8 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mariano Lopez 2016-11-28 15:05:38 UTC
Failed to copy licenses from deployed packages (not installed), to the rootfs. This happens with individual packages and with the manifest. The license (LICENSE_DIRECTORY) and the manifest (LICENSE_DIRECTORY/IMAGE_NAME) are in the correct directory but are not copied to the rootfs.

It seems it is because the task for the deployed packages is in IMAGE_POSTPROCESS_COMMAND. Check bug 9446 for more information why this task is in IMAGE_POSTPROCESS_COMMAND.
Comment 1 Mariano Lopez 2016-12-02 18:25:10 UTC
The license class has the feature to copy the license manifests and files to the resulting image. It will fail to copy the image_license manifest, because the creation of this manifest runs after the creation of rootfs.

You can reproduce this using:

COPY_LIC_DIRS = "1"
COPY_LIC_MANIFEST = "1"

and building any image, the image_manifest won't be in /usr/share/common-licenses, nor the kernel license.
Comment 2 Markus Lehtonen 2017-01-02 13:00:01 UTC
If I understand correctly, license.bbclass is doing what it is supposed to do: It only copies the licenses of packages that are installed in the device. Many packages in the deploydir do not necessarily have anything to do with the image and they should not copied (they're waste of disk-space there, too). Thus, I would suggest to close this as NOTABUG.

I might be wrong, though. I cc'd Ross, probably he has a definitive understanding what license.bbclass should do.
Comment 3 Mariano Lopez 2017-01-03 14:57:40 UTC
(In reply to comment #2)
> If I understand correctly, license.bbclass is doing what it is supposed to
> do: It only copies the licenses of packages that are installed in the
> device. Many packages in the deploydir do not necessarily have anything to
> do with the image and they should not copied (they're waste of disk-space
> there, too). Thus, I would suggest to close this as NOTABUG.
> 
> I might be wrong, though. I cc'd Ross, probably he has a definitive
> understanding what license.bbclass should do.

This feature was added because of bug 6772, Paul and I have had several discussions regarding what licenses must be included and how we need to get the packages that are not installed but somehow end in the image. This led us to include licenses from packages that were deployed (kernel, bootloader, and firmware are the most common). I agree with you these packages don't end up in the rootfs, but if you build an image (most of the time you build an image and not only the rootfs) they will end in the image. Also at least the kernel's libraries are used to build packages that are in rootfs.
Comment 4 Markus Lehtonen 2017-01-04 08:05:32 UTC
You're actually right. It makes sense to include all the licenses that were deployed as part of the bitbake task being run. I was befuddled by reading the license.bbclass code a bit incorrectly.

This is a rather nasty dependency problem. Basically we want use artefacts (i.e. copy the licenses into rootfs) that are produced by tasks that are not dependencies of do_rootfs. We cannot fix this by just moving write_deploy_manifest() back to ROOTFS_POSTPROCESS_COMMAND (described in bug 9446). The only solution I can currently think of is to make do_rootfs depend on all the relevant tasks (EXTRA_IMAGEDEPENDS and do_boot* tasks) and _then_ move write_deploy_manifest() back to ROOTFS_POSTPROCESS_COMMAND.
Comment 5 Richard Purdie 2017-01-05 14:19:49 UTC
What you're describing basically isn't going to work or is possible as its circular logic. do_rootfs can only depend on the things which go into the rootfs, not the wider list of things which happen to be deployed. Doing otherwise would break cases where a rootfs is included within a rootfs (e.g. an initramfs) since the smaller rootfs would then have to depend on the larger one and it becomes an impossible to execute task graph.

The only sane thing to do is to deploy a separate manifest to the rootfs which lists the licences of everything in deploy. This can't be included in the rootfs itself.
Comment 6 Markus Lehtonen 2017-01-05 15:27:36 UTC
Assigning to Paul for comments. What do you think would be the best thing to do? Do we really need the deploy manifest inside the rootfs. As per Richard's comment it is very hard if not impossible to achieve.
Comment 7 Paul Eggleton 2017-03-17 03:57:47 UTC
I definitely see this as a legitimate use case. Many embedded devices already include "show license text" functionality that has to show the license for everything included in the system, which would for example have to cover the kernel and bootloader, neither of which might actually be present in the image itself.

There are also technical challenges to implementing this as Richard pointed out. At the moment there's no pressing demand so he proposed that we drop the priority to Medium and move this to Future.
Comment 8 Ross Burton 2017-03-17 11:56:20 UTC
Would the use-case of including pieces not in the image itself (such as bootloaders) be solvable by simply IMAGE_INSTALL += u-boot-lic?

If the implementation is "all deployed packages", what if the image is built before u-boot?  The image doesn't contain u-boot so this is possible.
Comment 9 Jonathan Liu 2020-09-06 22:12:25 UTC
(In reply to comment #8)
> Would the use-case of including pieces not in the image itself (such as
> bootloaders) be solvable by simply IMAGE_INSTALL += u-boot-lic?

How about something like IMAGE_INSTALL_LICENSE += "u-boot"?

It would have the same effect as IMAGE_INSTALL with regard to license generation but would not actually install the package contents.
Comment 10 Richard Purdie 2024-09-12 14:59:27 UTC
Even with SPDX, "deployed" binaries are still an open question with regard to license manifests.
Comment 11 Joshua Watt 2026-09-17 15:02:30 UTC
This will be fixed by the improvements to SPDX that improves the output for "deployed" recipes like the kernel et. al.