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 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 | |||
305 | methods described in this section (e.g. the mechanism through which | 305 | methods described in this section (e.g. the mechanism through which |
306 | source code is distributed). | 306 | source code is distributed). |
307 | 307 | ||
308 | As different organizations have different methods of complying with open | 308 | As different organizations have different ways of releasing software, |
309 | source licensing, this section is not meant to imply that there is only | 309 | there can be multiple ways of meeting license obligations. At |
310 | one single way to meet your compliance obligations, but rather to | 310 | least, we describe here two methods for achieving compliance: |
311 | describe one method of achieving compliance. The remainder of this | 311 | |
312 | section describes methods supported to meet the previously mentioned | 312 | - The first method is to use OpenEmbedded's ability to provide |
313 | three requirements. Once you take steps to meet these requirements, and | 313 | the source code, provide a list of licenses, as well as |
314 | prior to releasing images, sources, and the build system, you should | 314 | compilation scripts and source code modifications. |
315 | audit all artifacts to ensure completeness. | 315 | |
316 | The remainder of this section describes supported methods to meet | ||
317 | the previously mentioned three requirements. | ||
318 | |||
319 | - The second method is to generate a *Software Bill of Materials* | ||
320 | (:term:`SBoM`), as described in the ":doc:`/dev-manual/sbom`" section. | ||
321 | Not only do you generate :term:`SPDX` output which can be used meet | ||
322 | license compliance requirements (except for sharing the build system | ||
323 | and layers sources for the time being), but this output also includes | ||
324 | component version and patch information which can be used | ||
325 | for vulnerability assessment. | ||
326 | |||
327 | Whatever method you choose, prior to releasing images, sources, | ||
328 | and the build system, you should audit all artifacts to ensure | ||
329 | completeness. | ||
316 | 330 | ||
317 | .. note:: | 331 | .. note:: |
318 | 332 | ||