mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-06-03 01:40:07 +00:00
Code Issues Projects Releases Wiki Activity

dev-manual: licenses: mention SPDX for license compliance

Browse Source 
(From yocto-docs rev: 7082ce69f50094052df6e6134eb74c2721ecf147)

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
CC: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This commit is contained in:
Michael Opdenacker
2023-09-13 16:11:58 +02:00
committed by Steve Sakoman
parent c50eae0a3e
commit 175ff0b5fa
1 changed files with 22 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documentation/dev-manual/licenses.rst
+22 -8
View File
@@ -298,14 +298,28 @@ There are other requirements beyond the scope of these three and the
methods described in this section (e.g. the mechanism through which methods described in this section (e.g. the mechanism through which
source code is distributed). source code is distributed).
As different organizations have different methods of complying with open As different organizations have different ways of releasing software,
source licensing, this section is not meant to imply that there is only there can be multiple ways of meeting license obligations. At
one single way to meet your compliance obligations, but rather to least, we describe here two methods for achieving compliance:
describe one method of achieving compliance. The remainder of this
section describes methods supported to meet the previously mentioned - The first method is to use OpenEmbedded's ability to provide
three requirements. Once you take steps to meet these requirements, and the source code, provide a list of licenses, as well as
prior to releasing images, sources, and the build system, you should compilation scripts and source code modifications.
audit all artifacts to ensure completeness.
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:: .. note::