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