diff options
| author | Michael Opdenacker <michael.opdenacker@bootlin.com> | 2023-09-13 16:11:58 +0200 |
|---|---|---|
| committer | Steve Sakoman <steve@sakoman.com> | 2023-09-29 04:33:44 -1000 |
| commit | 175ff0b5faa0458ace9954c0d38c8572b28e7b2e (patch) | |
| tree | 1e629aadb96632abd0b20a12dc51e9a77aaafb31 /documentation | |
| parent | c50eae0a3e5326925c8b84d17a73d70a63f1ed4d (diff) | |
| download | poky-175ff0b5faa0458ace9954c0d38c8572b28e7b2e.tar.gz | |
dev-manual: licenses: mention SPDX for license compliance
(From yocto-docs rev: 7082ce69f50094052df6e6134eb74c2721ecf147)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
CC: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Diffstat (limited to 'documentation')
| -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 | ||
