diff options
Diffstat (limited to 'poky/documentation/dev-manual/licenses.rst')
| -rw-r--r-- | poky/documentation/dev-manual/licenses.rst | 30 |
1 files changed, 22 insertions, 8 deletions
diff --git a/poky/documentation/dev-manual/licenses.rst b/poky/documentation/dev-manual/licenses.rst index 9629dc5329..200c3fc389 100644 --- a/poky/documentation/dev-manual/licenses.rst +++ b/poky/documentation/dev-manual/licenses.rst @@ -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 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:: |