On Thu, May 20, 2021 at 9:18 AM Jasper Orschulko
<Jasper.Orschulko@...> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

OK, maybe I did not make the issue clear enough:

I have a package A which statically links package B at compile time
(using DEPENDS).
As a result the package A is "tainted" with source code from package B.
However, as package B is only in the DEPENDS, not in the RDEPENDS, it
is not included in the license.manifest. As a result, the output image
violates the license terms of package B.

Now my idea comes into play:
Add package B to the RDEPENDS (even though the ${PN} package is empty
after the packages-split), which should result in package B's inclusion
in the license.manifest. Or am I approaching this completely wrong?

I see, this is a workaround that will work in this case but may not
work in case where the PN is not empty
but static linking it happening. So I think in cases of static linking
the parent recipe has to reflect that chage

- --
With best regards

Jasper Orschulko
DevOps Engineer

Tel. +49 30 58 58 14 265
Fax +49 30 58 58 14 999
Jasper.Orschulko@...

• • • • • • • • • • • • • • • • • • • • • • • • • •

iris-GmbH
infrared & intelligent sensors
Ostendstraße 1-14 | 12459 Berlin

https://iris-sensing.com/




On Thu, 2021-05-20 at 09:04 -0700, Khem Raj wrote:

On Thu, May 20, 2021 at 9:00 AM Jasper Orschulko
<Jasper.Orschulko@...> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Khem,

thanks for your reply. As far as I understand, the "proper" way is
to
use dynamic linked libraries whenever possible? I have done some
more
thinking on the matter, and at least in our case the packages in
question are empty (the base package that is, everything else is in
${PN}-src ${PN}-devstatic etc), so I believe the easiest way to
include
these into the license manifest is to also add them to RDEPENDS and
set
ALLOW_EMPTY_${PN} = "1". This should not change the output image,
but
include the packages in the build, thus adding them to the license
manifest. What do you think?

I am not sure why you will include empty packages in your manifest

- --
With best regards

Jasper Orschulko
DevOps Engineer

Tel. +49 30 58 58 14 265
Fax +49 30 58 58 14 999
Jasper.Orschulko@...

• • • • • • • • • • • • • • • • • • • • • • • • • •

iris-GmbH
infrared & intelligent sensors
Ostendstraße 1-14 | 12459 Berlin

https://iris-sensing.com/




On Mon, 2021-05-17 at 15:56 -0700, Khem Raj wrote:

On 5/17/21 10:44 AM, Jasper Orschulko wrote:

Hi,

my question more or less reiterates the following:
https://www.yoctoproject.org/pipermail/yocto/2018-July/041854.html

I am trying to find a way to list statically linked libraries
in
the
license manifest, but so far I am at a loss. To my
understanding
Yocto
does not understand packages included using DEPENDS and not
RDEPENDS as
part of the resulting image, however technically source code
from
the
dependee can (and will) end up on the image as part of the
dependent
package. This is a serious issue from a legal point of view, as
the
developer ultimately might end up with an incomplete list of
licenses,
when relying on the Yocto license manifest.

Please, do correct me if I'm wrong :)

partly yes. there is a provision to disable static linking using
DISABLE_STATIC, so atleast some of packages can be cleared of.
depends
are effective during build time and its the linking which decides
on
that but you can perhaps easily write a probe and extract this
information from linker cmdline perhaps by dumping linker map and
post
processing it.

>
>
>
>
>

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmCmh3EACgkQYgqew07V
MNWiXAf9GPbvZjlzAW+ref/+RKP/9GbtSBpajVUkn+x4DYdO0DmSq6JwOGeLblW8
qu2wjw9cLwgDAL4YRLESrgA3XAbflFgf0IZBuEMbT6WONW7fgHeQ7+jPrEQ7dkgx
POrePcququDSDi2idjjrdTuqHxLl0Il09g8vJz9oktZhIKwCesqWQE8VjSLcjBaj
u+7nHLY77fV/a1o/Ka7PkH2AjbWsmn/iHC1hLN91yNVG6EyzAneHQYKDo7Y5kRVn
YWNSgmmab7uiigrN2KqFOblazkBaA5/rIKD1PpeOjqOTtF7+UfWkL5DZZArdh/KG
+E3VauRz6agqxbb0VUWZZjE6if07Qg==
=UCmd
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmCmi5gACgkQYgqew07V
MNURUQf+J7XVwVWvY8fFiOqXyiUFQXzeKpru3v9QNx6RRfXSxUXvs1taKPHEdKOG
vhBvnEIagC6Hzg0+QRBamk8c7KdgQXlS7FGNzMAbybE0Is/ocY1dpiQABSKTP8Za
4/EFNBZ64fzPMfFq3gX3mzko4vf7Ub6R3hmXkZTZnJVUTU9fMCNnxt94mXDvwSB4
bK54TRs2Zpg9s77XxL/nxvaEpkdYC2GBMxIgjahVLVhbxgmn03Sozt2zawbawGRK
NpvagP06+6o0gSgwKBJ3bU2H3i9nQGLOETTGvMjnsbqOANusNZ6QR2WTtJrFirZN
j10vjBt7b+0/GOqU0ONGnVDQYSx74A==
=foGh
-----END PGP SIGNATURE-----