Bug 14407

Summary:	Static linked libraries do not appear in license manifest nor in sources tarball
Product:	[Build System, Metadata & Runtime] OE-Core	Reporter:	Jasper Ben Orschulko <Jasper.Orschulko>
Component:	oe-core other	Assignee:	Jasper Ben Orschulko <Jasper.Orschulko>
Status:	RESOLVED WORKSFORME	QA Contact:
Severity:	normal
Priority:	Medium+	CC:	randy.macleod, ross.burton, sgw
Version:	unspecified
Target Milestone:	5.99
Hardware:	All
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	Don't know

Description Jasper Ben Orschulko 2021-05-25 16:28:19 UTC

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.

Comment 1 Randy MacLeod 2021-05-27 15:00:18 UTC

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.

Comment 2 Jasper Ben Orschulko 2021-05-27 16:51:16 UTC

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

Comment 3 Randy MacLeod 2021-05-28 02:07:36 UTC

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.

Comment 4 Michael Opdenacker 2021-10-18 15:45:49 UTC

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.

Comment 5 Randy MacLeod 2021-10-21 15:10:31 UTC

We need some ideas about how to catch this type of manifest error.

Comment 6 Randy MacLeod 2023-03-09 16:06:43 UTC

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!

Comment 7 Jasper Ben Orschulko 2023-06-15 09:18:32 UTC

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

Comment 8 Joshua Watt 2023-06-15 12:57:01 UTC

The create-spdx class has the option to create source archives

Comment 9 Joshua Watt 2024-10-31 14:31:41 UTC

Jasper,

Can you take a look at the SPDX generation and see if this resolves your concerns?

If so, please close this.

Comment 10 Randy MacLeod 2024-11-07 15:58:05 UTC

Jasper, Do you have what you need based on Joshua's comments?

Comment 11 Jasper Ben Orschulko 2024-11-19 17:19:29 UTC

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.

Comment 12 Randy MacLeod 2025-01-16 16:10:55 UTC

Jasper,
We're assuming that the SPDX generation resolves your concerns,
Re-open if that's not the case.

YP bug review.

Comment 13 Randy MacLeod 2025-02-14 16:46:26 UTC

bulk change to add Saul's non-WR address.

Comment 14 Randy MacLeod 2025-02-14 16:48:16 UTC

Bulk change: Remove Saul's old WR address.