diff options
-rw-r--r-- | documentation/dev-manual/licenses.rst | 30 |
1 files changed, 22 insertions, 8 deletions
diff --git a/documentation/dev-manual/licenses.rst b/documentation/dev-manual/licenses.rst index 9629dc5329..200c3fc389 100644 --- a/documentation/dev-manual/licenses.rst +++ b/documentation/dev-manual/licenses.rst | |||
@@ -298,14 +298,28 @@ There are other requirements beyond the scope of these three and the | |||
298 | methods described in this section (e.g. the mechanism through which | 298 | methods described in this section (e.g. the mechanism through which |
299 | source code is distributed). | 299 | source code is distributed). |
300 | 300 | ||
301 | As different organizations have different methods of complying with open | 301 | As different organizations have different ways of releasing software, |
302 | source licensing, this section is not meant to imply that there is only | 302 | there can be multiple ways of meeting license obligations. At |
303 | one single way to meet your compliance obligations, but rather to | 303 | least, we describe here two methods for achieving compliance: |
304 | describe one method of achieving compliance. The remainder of this | 304 | |
305 | section describes methods supported to meet the previously mentioned | 305 | - The first method is to use OpenEmbedded's ability to provide |
306 | three requirements. Once you take steps to meet these requirements, and | 306 | the source code, provide a list of licenses, as well as |
307 | prior to releasing images, sources, and the build system, you should | 307 | compilation scripts and source code modifications. |
308 | audit all artifacts to ensure completeness. | 308 | |
309 | The remainder of this section describes supported methods to meet | ||
310 | the previously mentioned three requirements. | ||
311 | |||
312 | - The second method is to generate a *Software Bill of Materials* | ||
313 | (:term:`SBoM`), as described in the ":doc:`/dev-manual/sbom`" section. | ||
314 | Not only do you generate :term:`SPDX` output which can be used meet | ||
315 | license compliance requirements (except for sharing the build system | ||
316 | and layers sources for the time being), but this output also includes | ||
317 | component version and patch information which can be used | ||
318 | for vulnerability assessment. | ||
319 | |||
320 | Whatever method you choose, prior to releasing images, sources, | ||
321 | and the build system, you should audit all artifacts to ensure | ||
322 | completeness. | ||
309 | 323 | ||
310 | .. note:: | 324 | .. note:: |
311 | 325 | ||