When adding a package A to an image (RDEPENDS += "A"), with the former depending on a static linked library package B (DEPENDS += "B"), package B will not appear in the generated license manifest nor in the source tarball generated by the archiving class. This occurs as the licensing and archiving classes assume that only packages included via RDEPEND end up in the image. However, this is not the case, as statically linking implies, that source code from package B is copied into package A at compile time and thus ends up being part of the rootfs. As a result, potential obligations regarding license compliance for package B will not be met. As the archiving and licensing classes are fundamental cornerstones of the "Maintaining Open Source License Compliance During Your Product's Lifecycle" chapter within the manuals (https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#maintaining-open-source-license-compliance-during-your-products-lifecycle), it is fair to say, that many users will depend on these for their license compliance reports and thus this should be addressed quickly, either by fixing this issue or by making the users aware of these shortcomings, so that they can make the informed decision, whether they want to rely on these mechanisms for their single source of truth.
We don't enable static libraries by default, in part because of this problem. We will document the limitation but we don't have a good idea about how to make the system report on static library dependencies.
(In reply to comment #1) > We don't enable static libraries by default, in part because of this problem. > We will document the limitation but we don't have a good idea about how to > make the system report on static library dependencies. I see. One idea I had (however not sure feasible) would be to check the content of packages included by DEPENDS for well-known extensions (e.g. *.a) and based on the findings treat them as part of the resulting image. This of course could lead to false positives, but I think it would be better to rather include too many, than too few packages. Introducing some sort of "LICENSE_IGNORE" variable could be used to remove false positives from the manifest and the sources folder.
Jasper if you want to try, that'd be great. Let me know if you need any help with the process. It really would be good to fix this deficiency.
The documentation aspect of this bug is now addressed by this commit: http://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/commit/?id=444ca8900e8057562d2a71a77e6e6798aca3ce85 Removing myself as assignee for this bug. You may close this bug if you consider that the warning in documentation is enough, or re-assign it to somebody else.
We need some ideas about how to catch this type of manifest error.
We think that the SPDX class will deal with this and document the relationship. We're working on enabling that by default on master and plan to add test cases to prove that it works!
That sounds promising Randy! Does or is it planned that the new create-spdx class (looking at it for the first time, sorry) also deals with the creation of the source code archives? Otherwise the licenses would be listed correctly in the SPDX license files, but the respective code would be missing from the source code dump
The create-spdx class has the option to create source archives
Jasper, Can you take a look at the SPDX generation and see if this resolves your concerns? If so, please close this.
Jasper, Do you have what you need based on Joshua's comments?
Hi all, sorry for the late reply, the notifications got lost in my mail inbox ;) I should be able to test this within the next couple of days.
Jasper, We're assuming that the SPDX generation resolves your concerns, Re-open if that's not the case. YP bug review.
bulk change to add Saul's non-WR address.
Bulk change: Remove Saul's old WR address.