Re: Integrating meta-doubleopen into OE


Given the recent interest in SBOM support for OE-core, I'm going to start
looking at integrating meta-doubleopen as an SBOM solution for OE.
I've taken a look around in the project, and I think it covers most of the
requirements that I think OE needs for SBOM support:

1) It provides almost all of the information about recipes and packages that is
considered "minimum viable" for SBOM support (based on the presentations
from Kate Stewart that I watched). The only field I've noticed is lacking is the
"Supplier Name" (SPDX "PackageSupplier"). I'm by no means an SBOM expert, so
I'm not quite clear what that field should be or how to populate it, but I think we
can worry about that later.

2) It's self contained; there is not dependency on external components or

3) It produces SPDX JSON output, which is a standardized format and should be
fairly easily translated to just about any other format

It's possibly that meta-doubleopen does more that what would be
considered a minimum viable SBOM solution for OE, but it seems quite
useful and I suspect any extra functionality are things we would want
anyway. I'd be curious for the Mikko (the author) to chime in and let us
know what works well and what doesn't with the layer.

Ideally, I think this could be brought into OE-core in some form; does
anyone have any thoughts on this idea? I think that the code as-is needs
a little bit of cleanup to make that happen, but moving it to core would
make that a little easier (it seems there is some duplication between
what meta-doubleopen is doing and other various components in OE).
Frequently a wide range of open source software is incorporated (or more than this) to code-base.
It results in set of license types of same or even higher number of elements in set projects need to adhere to.
Every license type seems to raise own requirements regarding deliveries to customer.
There is also a huge set of commonly known copyleft license types.
Projects seem to need tool-chain capable to deliver set a range of artifact types
as complete set of copyleft licenses in use is asking for.
Set of artifacts seems to be what project need to deliver to customers, this sounds for me to be more than SBOM.
Is this a proper view? If yes, which of these 2 components (sbom, or rather set of artifacts for customer delivery for oss compliance)
does OE aim to fulfill?

Join to automatically receive all group messages.