VS: [licensing] Integrating meta-doubleopen into OE

Mikko Murto

In particular:

* the source archiver is problematic in various ways
Agreed. IMHO, one of the bigger problems with the source archiver is that it
has so many modes of operation. Presumably, someone wanted each one,
but it does make it ugly and hard to test. Technically, I believe that the meta-
doubleopen adds "yet another" archiver mode (since it does appear to do
source archiving), but in practice and with a little work it looks like this
overlaps the "patched" mode of archiver.bbclass; I think more evaluation is
necessary to see if the overlap can be eliminated in one way or another.
Yep, there's an archiver step included, for which the layer may not be the best place. The reasoning for it is that we wanted an archive of the files described in the SPDX for the project's workflow to run them through the license scanner. One functionality that I'm not particularly happy about is that we also include the packaged files in the archive. When we only archived the source files and linked the packaged files to their source with dwarfsrcfiles, we noticed that files that are generated during the build process but are not binary are kind of lost here, so we had to upload them too for scanning.

I'm also worried that if we generate the complex SPDX files that
meta-doubleopen does, we'll have people running away. We may need to
default to something simpler with the option of adding in a lot of the
information as unless you're handing things off to fossology or other
tools, it probably is overkill for most users and if default may actually put
people off?

I need to look more into it, but I'm partial to sticking with SPDX if at all
possible. If it can express everything we need I'd rather not invent some
other format that is basically the same thing.
I think the keyword here is *complex* SPDX files. For many use cases a SBOM may be a list of packages in image. The current default saves a lot of information in addition to this, specifically information about all the source files and packaged files and their relationships to the packages, which is something we need for the current project. A valid SPDX document could omit this file level information and just include the package information, which may be a saner default for a lot of people, at least in the beginning. This is something that in my mind would be a good candidate for configuration; store only the package data by default but include file level data if so specified in local.conf for example.