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

Joshua Watt
2026-03-12T14:12:11Z

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.

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.

>
> Cheers,
>
> Richard