Re: [OE-core][PATCH v6 03/15] spdx3: Add recipe SPDX data

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2026-03-12 at 08:11 -0600, Joshua Watt wrote:
> On Thu, Mar 12, 2026 at 5:43 AM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > 
> > On Tue, 2026-03-10 at 12:38 -0600, Joshua Watt via lists.openembedded.org wrote:
> > > Adds a new package to the SPDX output that represents the recipe data
> > > for a given recipe. Importantly, this data contains only things that can
> > > be determined statically from only the recipe, so it doesn't require
> > > fetching or building anything. This means that build time dependencies
> > > and CVE information for recipes can be analyzed without needing to
> > > actually do any builds.
> > > 
> > > Sadly, license data cannot be included because NO_GENERIC_LICENSE means
> > > that actual license text might only be available after do_fetch
> > 
> > We talked about these patches on the review call. I'm a bit worried
> > about the direction we're going from a few angles.
> > 
> > The general theme is the complexity and increasingly seemingly tangled
> > web we seem to be weaving and whether we're going to end up in a good
> > place.
> > 
> > Taking NO_GENERIC_LICENSE specifically, it may be we should mandate
> > that such licenses are copied into the metadata, then we solve the
> > license data problem that way? That would simplify some of the problems
> > we're facing and reduce some set of the corner cases.
> > 
> > This patch adds a new task into the task graph and I'm getting a bit
> > worried about the number of them the SPDX class is adding. I appreciate
> > there is a later patch removing one, which is nice though :)
> 
> With the removal of the vestigial task in this patch series, the task
> graph for SPDX is:
> 
> do_create_recipe_spdx - > "static" information we can determine about
> the recipe just from the metadata (no fetching, compiling, etc.)
> 
> do_create_spdx -> Information about what we built and how we built it.
> We obviously have to build to figure this part out (the definition of
> this didn't change in this patch series; it should really be called
> do_create_build_spdx, but it inherited the name from the SPDX 2 code,
> so I don't want to change it)
> 
> do_create_runtime_spdx -> Information about runtime packages. This has
> to be a separate task because while the build graph is a DAG, the
> runtime graph is not. The definition of this didn't change in this
> patch series.

I'm not entirely sure why we couldn't collect both sets of information
in one go in the same task, maybe inspecting BB_TASKDEPS instead of the
tasks actual dependencies but that is getting distracted into other
issues I guess.

> Various SBoM assembly tasks: These are the tasks that take the
> individual SPDX files generated by the tasks above and link them into
> a complete document that ends up in DEPLOY_DIR. They are all
> identified by having "sbom" in the name (do_create_image_sbom_spdx)
> 
> 
> > So, for this patch, could we just drop NO_GENERIC_LICENSE and how much
> > code complexity improvement does that buy us?
> 
> I'm not clear what you mean by this. I'm not including any additional
> License information, because we don't have it. I didn't change any
> license handling in the SPDX code, and I didn't add any more, so if
> you're talking about simplifying the SPDX code by dropping
> NO_GENERIC_LICENSE, it gains you nothing here specifically.
> 
> It might be nice to improve NO_GENERIC_LICENSE in general, but I don't
> think we can do that for 6.0. If we do that later, we might be able to
> add license information to the "recipe" level SPDX data.
> 
> The comment in the commit messages was probably more of a gripe than
> useful information (It feels like we _should_ be able to get license
> data statically, but we can't). I'll just remove it.

Ok, fair enough. I was more thinking that we could fix things so we
could get that information. I think I was getting confused and thinking
you were getting partial information.

We should perhaps separate out the NO_GENERIC_LICENSE issue into a
separate bug/issue to work on.

Cheers,

Richard