From 39f02bdc8dc1817220268aed0357d16450ee9bc8 Mon Sep 17 00:00:00 2001 From: Michael Opdenacker Date: Wed, 13 Sep 2023 16:11:58 +0200 Subject: dev-manual: licenses: mention SPDX for license compliance (From yocto-docs rev: a34626dd59617a32f6c20aa9ac11f15db2795a75) Signed-off-by: Michael Opdenacker CC: Joshua Watt Signed-off-by: Richard Purdie --- documentation/dev-manual/licenses.rst | 30 ++++++++++++++++++++++-------- 1 file changed, 22 insertions(+), 8 deletions(-) (limited to 'documentation/dev-manual') diff --git a/documentation/dev-manual/licenses.rst b/documentation/dev-manual/licenses.rst index f28baf57d1..3b9190d47f 100644 --- a/documentation/dev-manual/licenses.rst +++ b/documentation/dev-manual/licenses.rst @@ -305,14 +305,28 @@ There are other requirements beyond the scope of these three and the methods described in this section (e.g. the mechanism through which source code is distributed). -As different organizations have different methods of complying with open -source licensing, this section is not meant to imply that there is only -one single way to meet your compliance obligations, but rather to -describe one method of achieving compliance. The remainder of this -section describes methods supported to meet the previously mentioned -three requirements. Once you take steps to meet these requirements, and -prior to releasing images, sources, and the build system, you should -audit all artifacts to ensure completeness. +As different organizations have different ways of releasing software, +there can be multiple ways of meeting license obligations. At +least, we describe here two methods for achieving compliance: + +- The first method is to use OpenEmbedded's ability to provide + the source code, provide a list of licenses, as well as + compilation scripts and source code modifications. + + The remainder of this section describes supported methods to meet + the previously mentioned three requirements. + +- The second method is to generate a *Software Bill of Materials* + (:term:`SBoM`), as described in the ":doc:`/dev-manual/sbom`" section. + Not only do you generate :term:`SPDX` output which can be used meet + license compliance requirements (except for sharing the build system + and layers sources for the time being), but this output also includes + component version and patch information which can be used + for vulnerability assessment. + +Whatever method you choose, prior to releasing images, sources, +and the build system, you should audit all artifacts to ensure +completeness. .. note:: -- cgit v1.2.3-54-g00ecf