[OE-core][PATCH 0/2] spdx30: Add summary field and concluded license support

[OE-core][PATCH 0/2] spdx30: Add summary field and concluded license support

[Stefano Tondo]

This patch series improves SPDX 3.0 SBOM documentation quality by adding
summary field population and concluded license support.

The summary field enhancement makes SBOMs more human-readable by providing
brief descriptions for each package using an intelligent fallback chain.
This is particularly useful for security review and compliance documentation
where understanding component purposes at a glance is valuable.

The concluded license support allows tracking the results of manual or
automated license analysis in SBOMs through the SPDX_CONCLUDED_LICENSE
variable. This addresses use cases where license analysis identifies
differences from the declared LICENSE field, with clear guidelines on when
to use the variable versus correcting the upstream LICENSE field.

Both changes improve SBOM completeness and usefulness without impacting
existing builds or requiring changes to existing recipes.

Stefano Tondo (2):
  spdx30_tasks: Add summary field with fallback chain
  spdx30_tasks: Add concluded license support with
    SPDX_CONCLUDED_LICENSE

 meta/classes/spdx-common.bbclass | 11 +++++++++++
 meta/lib/oe/spdx30_tasks.py      | 35 +++++++++++++++++++++++++++++++++++
 2 files changed, 46 insertions(+)

--
2.43.0

[OE-core 1/2] spdx30_tasks: Add summary field with fallback chain

[Stefano Tondo]

From: Stefano Tondo <stefano.tondo.ext@siemens.com>

Add automatic population of summary field with intelligent fallback
chain to improve SBOM human-readability and documentation completeness.

The summary field provides a brief description of each package in the
SBOM, making it easier for humans to understand the purpose of components
without reading full descriptions. The implementation uses a fallback
chain to ensure every package has a meaningful summary:

  SUMMARY:${package} → SUMMARY → DESCRIPTION → generated description

This improvement addresses SBOM documentation quality requirements and
makes SBOMs more useful for security review and compliance documentation.

Signed-off-by: Stefano Tondo <stefano.tondo.ext@siemens.com>
---
 meta/lib/oe/spdx30_tasks.py | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oe/spdx30_tasks.py b/meta/lib/oe/spdx30_tasks.py
index f731a709e3..286a08ed9b 100644
--- a/meta/lib/oe/spdx30_tasks.py
+++ b/meta/lib/oe/spdx30_tasks.py
@@ -636,7 +636,22 @@ def create_spdx(d):
             set_var_field(
                 "HOMEPAGE", spdx_package, "software_homePage", package=package
             )
-            set_var_field("SUMMARY", spdx_package, "summary", package=package)
+            
+            # Add summary with fallback to DESCRIPTION
+            summary = None
+            if package:
+                summary = d.getVar("SUMMARY:%s" % package)
+            if not summary:
+                summary = d.getVar("SUMMARY")
+            if not summary:
+                # Fallback to DESCRIPTION if SUMMARY not available
+                summary = d.getVar("DESCRIPTION")
+            if not summary:
+                # Last resort: generate from package name
+                summary = f"Package {package or d.getVar('PN')}"
+            if summary:
+                spdx_package.summary = summary
+            
             set_var_field("DESCRIPTION", spdx_package, "description", package=package)
 
             if d.getVar("SPDX_PACKAGE_URL:%s" % package) or d.getVar("SPDX_PACKAGE_URL"):
-- 
2.52.0

Re: [OE-core] [OE-core 1/2] spdx30_tasks: Add summary field with fallback chain

[Joshua Watt]

On Thu, Dec 18, 2025 at 5:01 AM Stefano Tondo via
lists.openembedded.org <stondo=gmail.com@lists.openembedded.org>
wrote:
>
> From: Stefano Tondo <stefano.tondo.ext@siemens.com>
>
> Add automatic population of summary field with intelligent fallback
> chain to improve SBOM human-readability and documentation completeness.
>
> The summary field provides a brief description of each package in the
> SBOM, making it easier for humans to understand the purpose of components
> without reading full descriptions. The implementation uses a fallback
> chain to ensure every package has a meaningful summary:
>
>   SUMMARY:${package} → SUMMARY → DESCRIPTION → generated description
>
> This improvement addresses SBOM documentation quality requirements and
> makes SBOMs more useful for security review and compliance documentation.
>
> Signed-off-by: Stefano Tondo <stefano.tondo.ext@siemens.com>

LGTM thanks.

Reviewed-by: Joshua Watt <JPEWhacker@gmail.com>

> ---
>  meta/lib/oe/spdx30_tasks.py | 17 ++++++++++++++++-
>  1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/meta/lib/oe/spdx30_tasks.py b/meta/lib/oe/spdx30_tasks.py
> index f731a709e3..286a08ed9b 100644
> --- a/meta/lib/oe/spdx30_tasks.py
> +++ b/meta/lib/oe/spdx30_tasks.py
> @@ -636,7 +636,22 @@ def create_spdx(d):
>              set_var_field(
>                  "HOMEPAGE", spdx_package, "software_homePage", package=package
>              )
> -            set_var_field("SUMMARY", spdx_package, "summary", package=package)
> +
> +            # Add summary with fallback to DESCRIPTION
> +            summary = None
> +            if package:
> +                summary = d.getVar("SUMMARY:%s" % package)
> +            if not summary:
> +                summary = d.getVar("SUMMARY")
> +            if not summary:
> +                # Fallback to DESCRIPTION if SUMMARY not available
> +                summary = d.getVar("DESCRIPTION")
> +            if not summary:
> +                # Last resort: generate from package name
> +                summary = f"Package {package or d.getVar('PN')}"
> +            if summary:
> +                spdx_package.summary = summary
> +
>              set_var_field("DESCRIPTION", spdx_package, "description", package=package)
>
>              if d.getVar("SPDX_PACKAGE_URL:%s" % package) or d.getVar("SPDX_PACKAGE_URL"):
> --
> 2.52.0
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#228118): https://lists.openembedded.org/g/openembedded-core/message/228118
> Mute This Topic: https://lists.openembedded.org/mt/116840956/3616693
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [JPEWhacker@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

[OE-core 2/2] spdx30_tasks: Add concluded license support with SPDX_CONCLUDED_LICENSE

[Stefano Tondo]

From: Stefano Tondo <stefano.tondo.ext@siemens.com>

Add hasConcludedLicense relationship to SBOM packages with support for
manual license conclusion override via SPDX_CONCLUDED_LICENSE variable.

The concluded license represents the license determination after manual
or external license analysis. This should be set manually in recipes or
layers when:

1. Manual license review identifies differences from the declared LICENSE
2. External license scanning tools detect additional license information
3. Legal review concludes a different license applies

By default, concluded license equals declared license (indicating no
separate license analysis was performed). When differences are found,
users should:

1. Preferably: Correct the LICENSE field in the recipe and contribute
   the fix upstream to OpenEmbedded
2. Alternatively: Set SPDX_CONCLUDED_LICENSE locally in your layer when
   upstream contribution is not immediately possible or when the license
   conclusion is environment-specific

This variable allows tracking license analysis results in the SBOM while
maintaining the recipe LICENSE field for build system compatibility.

The variable is initialized in spdx-common.bbclass with comprehensive
documentation explaining its purpose, usage guidelines, and examples.

Example usage in recipe or layer:
  SPDX_CONCLUDED_LICENSE = "MIT & Apache-2.0"

Signed-off-by: Stefano Tondo <stefano.tondo.ext@siemens.com>
---
 meta/classes/spdx-common.bbclass | 13 +++++++++++++
 meta/lib/oe/spdx30_tasks.py      | 21 +++++++++++++++++++++
 2 files changed, 34 insertions(+)

diff --git a/meta/classes/spdx-common.bbclass b/meta/classes/spdx-common.bbclass
index ca0416d1c7..3ca4c70cc0 100644
--- a/meta/classes/spdx-common.bbclass
+++ b/meta/classes/spdx-common.bbclass
@@ -36,6 +36,19 @@ SPDX_LICENSES ??= "${COREBASE}/meta/files/spdx-licenses.json"
 
 SPDX_CUSTOM_ANNOTATION_VARS ??= ""
 
+SPDX_CONCLUDED_LICENSE ??= ""
+SPDX_CONCLUDED_LICENSE[doc] = "The license concluded by manual or external \
+    license analysis. This should only be set when license analysis (manual review \
+    or external scanning tools) identifies differences from the declared LICENSE. \
+    When unset or empty, the concluded license defaults to the declared license, \
+    indicating no separate analysis was performed. When differences are found, the \
+    preferred approach is to correct the LICENSE field in the recipe and contribute \
+    the fix upstream to OpenEmbedded. Use this variable locally only when upstream \
+    contribution is not immediately possible or when the license conclusion is \
+    environment-specific. This allows tracking license analysis results in SBOM \
+    while maintaining recipe LICENSE field for build compatibility. \
+    Example: SPDX_CONCLUDED_LICENSE = 'MIT & Apache-2.0'"
+
 SPDX_MULTILIB_SSTATE_ARCHS ??= "${SSTATE_ARCHS}"
 
 python () {
diff --git a/meta/lib/oe/spdx30_tasks.py b/meta/lib/oe/spdx30_tasks.py
index 286a08ed9b..84d70f6f72 100644
--- a/meta/lib/oe/spdx30_tasks.py
+++ b/meta/lib/oe/spdx30_tasks.py
@@ -712,6 +712,27 @@ def create_spdx(d):
                 oe.spdx30.RelationshipType.hasDeclaredLicense,
                 [oe.sbom30.get_element_link_id(package_spdx_license)],
             )
+            
+            # Add concluded license relationship
+            # Use SPDX_CONCLUDED_LICENSE if set, otherwise default to declared license
+            concluded_license_str = d.getVar("SPDX_CONCLUDED_LICENSE")
+            if concluded_license_str:
+                # Use explicitly set concluded license
+                if concluded_license_str != package_license and concluded_license_str != d.getVar("LICENSE"):
+                    concluded_spdx_license = add_license_expression(
+                        d, build_objset, concluded_license_str, license_data
+                    )
+                else:
+                    concluded_spdx_license = package_spdx_license
+            else:
+                # Default: concluded = declared (no analysis performed)
+                concluded_spdx_license = package_spdx_license
+            
+            pkg_objset.new_relationship(
+                [spdx_package],
+                oe.spdx30.RelationshipType.hasConcludedLicense,
+                [oe.sbom30.get_element_link_id(concluded_spdx_license)],
+            )
 
             # NOTE: CVE Elements live in the recipe collection
             all_cves = set()
-- 
2.52.0

Re: [OE-core] [OE-core 2/2] spdx30_tasks: Add concluded license support with SPDX_CONCLUDED_LICENSE

[Joshua Watt]

On Thu, Dec 18, 2025 at 5:02 AM Stefano Tondo via
lists.openembedded.org <stondo=gmail.com@lists.openembedded.org>
wrote:
>
> From: Stefano Tondo <stefano.tondo.ext@siemens.com>
>
> Add hasConcludedLicense relationship to SBOM packages with support for
> manual license conclusion override via SPDX_CONCLUDED_LICENSE variable.
>
> The concluded license represents the license determination after manual
> or external license analysis. This should be set manually in recipes or
> layers when:
>
> 1. Manual license review identifies differences from the declared LICENSE
> 2. External license scanning tools detect additional license information
> 3. Legal review concludes a different license applies
>
> By default, concluded license equals declared license (indicating no
> separate license analysis was performed). When differences are found,
> users should:
>
> 1. Preferably: Correct the LICENSE field in the recipe and contribute
>    the fix upstream to OpenEmbedded
> 2. Alternatively: Set SPDX_CONCLUDED_LICENSE locally in your layer when
>    upstream contribution is not immediately possible or when the license
>    conclusion is environment-specific
>
> This variable allows tracking license analysis results in the SBOM while
> maintaining the recipe LICENSE field for build system compatibility.
>
> The variable is initialized in spdx-common.bbclass with comprehensive
> documentation explaining its purpose, usage guidelines, and examples.
>
> Example usage in recipe or layer:
>   SPDX_CONCLUDED_LICENSE = "MIT & Apache-2.0"
>
> Signed-off-by: Stefano Tondo <stefano.tondo.ext@siemens.com>
> ---
>  meta/classes/spdx-common.bbclass | 13 +++++++++++++
>  meta/lib/oe/spdx30_tasks.py      | 21 +++++++++++++++++++++
>  2 files changed, 34 insertions(+)
>
> diff --git a/meta/classes/spdx-common.bbclass b/meta/classes/spdx-common.bbclass
> index ca0416d1c7..3ca4c70cc0 100644
> --- a/meta/classes/spdx-common.bbclass
> +++ b/meta/classes/spdx-common.bbclass
> @@ -36,6 +36,19 @@ SPDX_LICENSES ??= "${COREBASE}/meta/files/spdx-licenses.json"
>
>  SPDX_CUSTOM_ANNOTATION_VARS ??= ""
>
> +SPDX_CONCLUDED_LICENSE ??= ""
> +SPDX_CONCLUDED_LICENSE[doc] = "The license concluded by manual or external \
> +    license analysis. This should only be set when license analysis (manual review \
> +    or external scanning tools) identifies differences from the declared LICENSE. \
> +    When unset or empty, the concluded license defaults to the declared license, \
> +    indicating no separate analysis was performed. When differences are found, the \
> +    preferred approach is to correct the LICENSE field in the recipe and contribute \
> +    the fix upstream to OpenEmbedded. Use this variable locally only when upstream \
> +    contribution is not immediately possible or when the license conclusion is \
> +    environment-specific. This allows tracking license analysis results in SBOM \
> +    while maintaining recipe LICENSE field for build compatibility. \
> +    Example: SPDX_CONCLUDED_LICENSE = 'MIT & Apache-2.0'"
> +

It's unfortunate that the concluded license can't use an actual SPDX
license string; using an OE license string means converting.

Presumably, the reason for doing this is so that you can do:

SPDX_CONCLUDED_LICENSE = "${LICENSE}"

Is that a valid use case? If not, we should use an actual SPDX license
string instead.

>  SPDX_MULTILIB_SSTATE_ARCHS ??= "${SSTATE_ARCHS}"
>
>  python () {
> diff --git a/meta/lib/oe/spdx30_tasks.py b/meta/lib/oe/spdx30_tasks.py
> index 286a08ed9b..84d70f6f72 100644
> --- a/meta/lib/oe/spdx30_tasks.py
> +++ b/meta/lib/oe/spdx30_tasks.py
> @@ -712,6 +712,27 @@ def create_spdx(d):
>                  oe.spdx30.RelationshipType.hasDeclaredLicense,
>                  [oe.sbom30.get_element_link_id(package_spdx_license)],
>              )
> +
> +            # Add concluded license relationship
> +            # Use SPDX_CONCLUDED_LICENSE if set, otherwise default to declared license
> +            concluded_license_str = d.getVar("SPDX_CONCLUDED_LICENSE")
> +            if concluded_license_str:
> +                # Use explicitly set concluded license
> +                if concluded_license_str != package_license and concluded_license_str != d.getVar("LICENSE"):
> +                    concluded_spdx_license = add_license_expression(
> +                        d, build_objset, concluded_license_str, license_data
> +                    )

You can't make the concluded license default to the declared license.
The concluded license is the license that you (then end user)
determines is applicable, and we can't have the core code making that
assumption for users. If no concluded license is explicitly set by the
user, then it should not be in the SPDX.

> +                else:
> +                    concluded_spdx_license = package_spdx_license
> +            else:
> +                # Default: concluded = declared (no analysis performed)
> +                concluded_spdx_license = package_spdx_license
> +
> +            pkg_objset.new_relationship(
> +                [spdx_package],
> +                oe.spdx30.RelationshipType.hasConcludedLicense,
> +                [oe.sbom30.get_element_link_id(concluded_spdx_license)],
> +            )
>
>              # NOTE: CVE Elements live in the recipe collection
>              all_cves = set()
> --
> 2.52.0
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#228119): https://lists.openembedded.org/g/openembedded-core/message/228119
> Mute This Topic: https://lists.openembedded.org/mt/116840957/3616693
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [JPEWhacker@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [OE-core] [OE-core 2/2] spdx30_tasks: Add concluded license support with SPDX_CONCLUDED_LICENSE

[Joshua Watt]

On Thu, Dec 18, 2025 at 5:02 AM Stefano Tondo via
lists.openembedded.org <stondo=gmail.com@lists.openembedded.org>
wrote:
>
> From: Stefano Tondo <stefano.tondo.ext@siemens.com>
>
> Add hasConcludedLicense relationship to SBOM packages with support for
> manual license conclusion override via SPDX_CONCLUDED_LICENSE variable.
>
> The concluded license represents the license determination after manual
> or external license analysis. This should be set manually in recipes or
> layers when:
>
> 1. Manual license review identifies differences from the declared LICENSE
> 2. External license scanning tools detect additional license information
> 3. Legal review concludes a different license applies
>
> By default, concluded license equals declared license (indicating no
> separate license analysis was performed).

This is incorrect. If the concluded license was not specified, then no
analysis was performed. Setting the concluded license to the declared
license means that you (the end user) agree that the declared license
is the applicable one, which is not the same thing. As stated, we
cannot set the concluded license to a default value in any core code,
since we can't make that assumption for our users.

When differences are found,
> users should:
>
> 1. Preferably: Correct the LICENSE field in the recipe and contribute
>    the fix upstream to OpenEmbedded
> 2. Alternatively: Set SPDX_CONCLUDED_LICENSE locally in your layer when
>    upstream contribution is not immediately possible or when the license
>    conclusion is environment-specific
>
> This variable allows tracking license analysis results in the SBOM while
> maintaining the recipe LICENSE field for build system compatibility.
>
> The variable is initialized in spdx-common.bbclass with comprehensive
> documentation explaining its purpose, usage guidelines, and examples.
>
> Example usage in recipe or layer:
>   SPDX_CONCLUDED_LICENSE = "MIT & Apache-2.0"
>
> Signed-off-by: Stefano Tondo <stefano.tondo.ext@siemens.com>
> ---
>  meta/classes/spdx-common.bbclass | 13 +++++++++++++
>  meta/lib/oe/spdx30_tasks.py      | 21 +++++++++++++++++++++
>  2 files changed, 34 insertions(+)
>
> diff --git a/meta/classes/spdx-common.bbclass b/meta/classes/spdx-common.bbclass
> index ca0416d1c7..3ca4c70cc0 100644
> --- a/meta/classes/spdx-common.bbclass
> +++ b/meta/classes/spdx-common.bbclass
> @@ -36,6 +36,19 @@ SPDX_LICENSES ??= "${COREBASE}/meta/files/spdx-licenses.json"
>
>  SPDX_CUSTOM_ANNOTATION_VARS ??= ""
>
> +SPDX_CONCLUDED_LICENSE ??= ""
> +SPDX_CONCLUDED_LICENSE[doc] = "The license concluded by manual or external \
> +    license analysis. This should only be set when license analysis (manual review \
> +    or external scanning tools) identifies differences from the declared LICENSE. \
> +    When unset or empty, the concluded license defaults to the declared license, \
> +    indicating no separate analysis was performed. When differences are found, the \
> +    preferred approach is to correct the LICENSE field in the recipe and contribute \
> +    the fix upstream to OpenEmbedded. Use this variable locally only when upstream \
> +    contribution is not immediately possible or when the license conclusion is \
> +    environment-specific. This allows tracking license analysis results in SBOM \
> +    while maintaining recipe LICENSE field for build compatibility. \
> +    Example: SPDX_CONCLUDED_LICENSE = 'MIT & Apache-2.0'"
> +
>  SPDX_MULTILIB_SSTATE_ARCHS ??= "${SSTATE_ARCHS}"
>
>  python () {
> diff --git a/meta/lib/oe/spdx30_tasks.py b/meta/lib/oe/spdx30_tasks.py
> index 286a08ed9b..84d70f6f72 100644
> --- a/meta/lib/oe/spdx30_tasks.py
> +++ b/meta/lib/oe/spdx30_tasks.py
> @@ -712,6 +712,27 @@ def create_spdx(d):
>                  oe.spdx30.RelationshipType.hasDeclaredLicense,
>                  [oe.sbom30.get_element_link_id(package_spdx_license)],
>              )
> +
> +            # Add concluded license relationship
> +            # Use SPDX_CONCLUDED_LICENSE if set, otherwise default to declared license
> +            concluded_license_str = d.getVar("SPDX_CONCLUDED_LICENSE")
> +            if concluded_license_str:
> +                # Use explicitly set concluded license
> +                if concluded_license_str != package_license and concluded_license_str != d.getVar("LICENSE"):
> +                    concluded_spdx_license = add_license_expression(
> +                        d, build_objset, concluded_license_str, license_data
> +                    )
> +                else:
> +                    concluded_spdx_license = package_spdx_license
> +            else:
> +                # Default: concluded = declared (no analysis performed)
> +                concluded_spdx_license = package_spdx_license
> +
> +            pkg_objset.new_relationship(
> +                [spdx_package],
> +                oe.spdx30.RelationshipType.hasConcludedLicense,
> +                [oe.sbom30.get_element_link_id(concluded_spdx_license)],
> +            )
>
>              # NOTE: CVE Elements live in the recipe collection
>              all_cves = set()
> --
> 2.52.0
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#228119): https://lists.openembedded.org/g/openembedded-core/message/228119
> Mute This Topic: https://lists.openembedded.org/mt/116840957/3616693
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [JPEWhacker@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>