CaROS/poky
3
1
Fork 0
mirror of https://git.yoctoproject.org/git/poky synced 2026-01-01 13:58:04 +00:00
Code Issues Packages Projects Releases Wiki Activity

dev-manual: licenses: mention SPDX for license compliance

Browse Source 
(From yocto-docs rev: a34626dd59617a32f6c20aa9ac11f15db2795a75)

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
CC: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Michael Opdenacker 2023-09-13 16:11:58 +02:00 committed by Richard Purdie
parent 8f6f37b37b
commit 39f02bdc8d
1 changed files with 22 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
documentation/dev-manual/licenses.rst
View File

@ -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::