diff options
Diffstat (limited to 'documentation/dev-manual/licenses.rst')
-rw-r--r-- | documentation/dev-manual/licenses.rst | 520 |
1 files changed, 520 insertions, 0 deletions
diff --git a/documentation/dev-manual/licenses.rst b/documentation/dev-manual/licenses.rst new file mode 100644 index 0000000000..0db193f7e4 --- /dev/null +++ b/documentation/dev-manual/licenses.rst | |||
@@ -0,0 +1,520 @@ | |||
1 | .. SPDX-License-Identifier: CC-BY-SA-2.0-UK | ||
2 | |||
3 | Working With Licenses | ||
4 | ********************* | ||
5 | |||
6 | As mentioned in the ":ref:`overview-manual/development-environment:licensing`" | ||
7 | section in the Yocto Project Overview and Concepts Manual, open source | ||
8 | projects are open to the public and they consequently have different | ||
9 | licensing structures in place. This section describes the mechanism by | ||
10 | which the :term:`OpenEmbedded Build System` | ||
11 | tracks changes to | ||
12 | licensing text and covers how to maintain open source license compliance | ||
13 | during your project's lifecycle. The section also describes how to | ||
14 | enable commercially licensed recipes, which by default are disabled. | ||
15 | |||
16 | Tracking License Changes | ||
17 | ======================== | ||
18 | |||
19 | The license of an upstream project might change in the future. In order | ||
20 | to prevent these changes going unnoticed, the | ||
21 | :term:`LIC_FILES_CHKSUM` | ||
22 | variable tracks changes to the license text. The checksums are validated | ||
23 | at the end of the configure step, and if the checksums do not match, the | ||
24 | build will fail. | ||
25 | |||
26 | Specifying the ``LIC_FILES_CHKSUM`` Variable | ||
27 | -------------------------------------------- | ||
28 | |||
29 | The :term:`LIC_FILES_CHKSUM` variable contains checksums of the license text | ||
30 | in the source code for the recipe. Following is an example of how to | ||
31 | specify :term:`LIC_FILES_CHKSUM`:: | ||
32 | |||
33 | LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \ | ||
34 | file://licfile1.txt;beginline=5;endline=29;md5=yyyy \ | ||
35 | file://licfile2.txt;endline=50;md5=zzzz \ | ||
36 | ..." | ||
37 | |||
38 | .. note:: | ||
39 | |||
40 | - When using "beginline" and "endline", realize that line numbering | ||
41 | begins with one and not zero. Also, the included lines are | ||
42 | inclusive (i.e. lines five through and including 29 in the | ||
43 | previous example for ``licfile1.txt``). | ||
44 | |||
45 | - When a license check fails, the selected license text is included | ||
46 | as part of the QA message. Using this output, you can determine | ||
47 | the exact start and finish for the needed license text. | ||
48 | |||
49 | The build system uses the :term:`S` | ||
50 | variable as the default directory when searching files listed in | ||
51 | :term:`LIC_FILES_CHKSUM`. The previous example employs the default | ||
52 | directory. | ||
53 | |||
54 | Consider this next example:: | ||
55 | |||
56 | LIC_FILES_CHKSUM = "file://src/ls.c;beginline=5;endline=16;\ | ||
57 | md5=bb14ed3c4cda583abc85401304b5cd4e" | ||
58 | LIC_FILES_CHKSUM = "file://${WORKDIR}/license.html;md5=5c94767cedb5d6987c902ac850ded2c6" | ||
59 | |||
60 | The first line locates a file in ``${S}/src/ls.c`` and isolates lines | ||
61 | five through 16 as license text. The second line refers to a file in | ||
62 | :term:`WORKDIR`. | ||
63 | |||
64 | Note that :term:`LIC_FILES_CHKSUM` variable is mandatory for all recipes, | ||
65 | unless the :term:`LICENSE` variable is set to "CLOSED". | ||
66 | |||
67 | Explanation of Syntax | ||
68 | --------------------- | ||
69 | |||
70 | As mentioned in the previous section, the :term:`LIC_FILES_CHKSUM` variable | ||
71 | lists all the important files that contain the license text for the | ||
72 | source code. It is possible to specify a checksum for an entire file, or | ||
73 | a specific section of a file (specified by beginning and ending line | ||
74 | numbers with the "beginline" and "endline" parameters, respectively). | ||
75 | The latter is useful for source files with a license notice header, | ||
76 | README documents, and so forth. If you do not use the "beginline" | ||
77 | parameter, then it is assumed that the text begins on the first line of | ||
78 | the file. Similarly, if you do not use the "endline" parameter, it is | ||
79 | assumed that the license text ends with the last line of the file. | ||
80 | |||
81 | The "md5" parameter stores the md5 checksum of the license text. If the | ||
82 | license text changes in any way as compared to this parameter then a | ||
83 | mismatch occurs. This mismatch triggers a build failure and notifies the | ||
84 | developer. Notification allows the developer to review and address the | ||
85 | license text changes. Also note that if a mismatch occurs during the | ||
86 | build, the correct md5 checksum is placed in the build log and can be | ||
87 | easily copied to the recipe. | ||
88 | |||
89 | There is no limit to how many files you can specify using the | ||
90 | :term:`LIC_FILES_CHKSUM` variable. Generally, however, every project | ||
91 | requires a few specifications for license tracking. Many projects have a | ||
92 | "COPYING" file that stores the license information for all the source | ||
93 | code files. This practice allows you to just track the "COPYING" file as | ||
94 | long as it is kept up to date. | ||
95 | |||
96 | .. note:: | ||
97 | |||
98 | - If you specify an empty or invalid "md5" parameter, | ||
99 | :term:`BitBake` returns an md5 | ||
100 | mis-match error and displays the correct "md5" parameter value | ||
101 | during the build. The correct parameter is also captured in the | ||
102 | build log. | ||
103 | |||
104 | - If the whole file contains only license text, you do not need to | ||
105 | use the "beginline" and "endline" parameters. | ||
106 | |||
107 | Enabling Commercially Licensed Recipes | ||
108 | ====================================== | ||
109 | |||
110 | By default, the OpenEmbedded build system disables components that have | ||
111 | commercial or other special licensing requirements. Such requirements | ||
112 | are defined on a recipe-by-recipe basis through the | ||
113 | :term:`LICENSE_FLAGS` variable | ||
114 | definition in the affected recipe. For instance, the | ||
115 | ``poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly`` recipe | ||
116 | contains the following statement:: | ||
117 | |||
118 | LICENSE_FLAGS = "commercial" | ||
119 | |||
120 | Here is a | ||
121 | slightly more complicated example that contains both an explicit recipe | ||
122 | name and version (after variable expansion):: | ||
123 | |||
124 | LICENSE_FLAGS = "license_${PN}_${PV}" | ||
125 | |||
126 | In order for a component restricted by a | ||
127 | :term:`LICENSE_FLAGS` definition to be enabled and included in an image, it | ||
128 | needs to have a matching entry in the global | ||
129 | :term:`LICENSE_FLAGS_ACCEPTED` | ||
130 | variable, which is a variable typically defined in your ``local.conf`` | ||
131 | file. For example, to enable the | ||
132 | ``poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly`` package, you | ||
133 | could add either the string "commercial_gst-plugins-ugly" or the more | ||
134 | general string "commercial" to :term:`LICENSE_FLAGS_ACCEPTED`. See the | ||
135 | ":ref:`dev-manual/licenses:license flag matching`" section for a full | ||
136 | explanation of how :term:`LICENSE_FLAGS` matching works. Here is the | ||
137 | example:: | ||
138 | |||
139 | LICENSE_FLAGS_ACCEPTED = "commercial_gst-plugins-ugly" | ||
140 | |||
141 | Likewise, to additionally enable the package built from the recipe | ||
142 | containing ``LICENSE_FLAGS = "license_${PN}_${PV}"``, and assuming that | ||
143 | the actual recipe name was ``emgd_1.10.bb``, the following string would | ||
144 | enable that package as well as the original ``gst-plugins-ugly`` | ||
145 | package:: | ||
146 | |||
147 | LICENSE_FLAGS_ACCEPTED = "commercial_gst-plugins-ugly license_emgd_1.10" | ||
148 | |||
149 | As a convenience, you do not need to specify the | ||
150 | complete license string for every package. You can use | ||
151 | an abbreviated form, which consists of just the first portion or | ||
152 | portions of the license string before the initial underscore character | ||
153 | or characters. A partial string will match any license that contains the | ||
154 | given string as the first portion of its license. For example, the | ||
155 | following value will also match both of the packages | ||
156 | previously mentioned as well as any other packages that have licenses | ||
157 | starting with "commercial" or "license". | ||
158 | :: | ||
159 | |||
160 | LICENSE_FLAGS_ACCEPTED = "commercial license" | ||
161 | |||
162 | License Flag Matching | ||
163 | --------------------- | ||
164 | |||
165 | License flag matching allows you to control what recipes the | ||
166 | OpenEmbedded build system includes in the build. Fundamentally, the | ||
167 | build system attempts to match :term:`LICENSE_FLAGS` strings found in | ||
168 | recipes against strings found in :term:`LICENSE_FLAGS_ACCEPTED`. | ||
169 | A match causes the build system to include a recipe in the | ||
170 | build, while failure to find a match causes the build system to exclude | ||
171 | a recipe. | ||
172 | |||
173 | In general, license flag matching is simple. However, understanding some | ||
174 | concepts will help you correctly and effectively use matching. | ||
175 | |||
176 | Before a flag defined by a particular recipe is tested against the | ||
177 | entries of :term:`LICENSE_FLAGS_ACCEPTED`, the expanded | ||
178 | string ``_${PN}`` is appended to the flag. This expansion makes each | ||
179 | :term:`LICENSE_FLAGS` value recipe-specific. After expansion, the | ||
180 | string is then matched against the entries. Thus, specifying | ||
181 | ``LICENSE_FLAGS = "commercial"`` in recipe "foo", for example, results | ||
182 | in the string ``"commercial_foo"``. And, to create a match, that string | ||
183 | must appear among the entries of :term:`LICENSE_FLAGS_ACCEPTED`. | ||
184 | |||
185 | Judicious use of the :term:`LICENSE_FLAGS` strings and the contents of the | ||
186 | :term:`LICENSE_FLAGS_ACCEPTED` variable allows you a lot of flexibility for | ||
187 | including or excluding recipes based on licensing. For example, you can | ||
188 | broaden the matching capabilities by using license flags string subsets | ||
189 | in :term:`LICENSE_FLAGS_ACCEPTED`. | ||
190 | |||
191 | .. note:: | ||
192 | |||
193 | When using a string subset, be sure to use the part of the expanded | ||
194 | string that precedes the appended underscore character (e.g. | ||
195 | ``usethispart_1.3``, ``usethispart_1.4``, and so forth). | ||
196 | |||
197 | For example, simply specifying the string "commercial" in the | ||
198 | :term:`LICENSE_FLAGS_ACCEPTED` variable matches any expanded | ||
199 | :term:`LICENSE_FLAGS` definition that starts with the string | ||
200 | "commercial" such as "commercial_foo" and "commercial_bar", which | ||
201 | are the strings the build system automatically generates for | ||
202 | hypothetical recipes named "foo" and "bar" assuming those recipes simply | ||
203 | specify the following:: | ||
204 | |||
205 | LICENSE_FLAGS = "commercial" | ||
206 | |||
207 | Thus, you can choose to exhaustively enumerate each license flag in the | ||
208 | list and allow only specific recipes into the image, or you can use a | ||
209 | string subset that causes a broader range of matches to allow a range of | ||
210 | recipes into the image. | ||
211 | |||
212 | This scheme works even if the :term:`LICENSE_FLAGS` string already has | ||
213 | ``_${PN}`` appended. For example, the build system turns the license | ||
214 | flag "commercial_1.2_foo" into "commercial_1.2_foo_foo" and would match | ||
215 | both the general "commercial" and the specific "commercial_1.2_foo" | ||
216 | strings found in the :term:`LICENSE_FLAGS_ACCEPTED` variable, as expected. | ||
217 | |||
218 | Here are some other scenarios: | ||
219 | |||
220 | - You can specify a versioned string in the recipe such as | ||
221 | "commercial_foo_1.2" in a "foo" recipe. The build system expands this | ||
222 | string to "commercial_foo_1.2_foo". Combine this license flag with a | ||
223 | :term:`LICENSE_FLAGS_ACCEPTED` variable that has the string | ||
224 | "commercial" and you match the flag along with any other flag that | ||
225 | starts with the string "commercial". | ||
226 | |||
227 | - Under the same circumstances, you can add "commercial_foo" in the | ||
228 | :term:`LICENSE_FLAGS_ACCEPTED` variable and the build system not only | ||
229 | matches "commercial_foo_1.2" but also matches any license flag with | ||
230 | the string "commercial_foo", regardless of the version. | ||
231 | |||
232 | - You can be very specific and use both the package and version parts | ||
233 | in the :term:`LICENSE_FLAGS_ACCEPTED` list (e.g. | ||
234 | "commercial_foo_1.2") to specifically match a versioned recipe. | ||
235 | |||
236 | Other Variables Related to Commercial Licenses | ||
237 | ---------------------------------------------- | ||
238 | |||
239 | There are other helpful variables related to commercial license handling, | ||
240 | defined in the | ||
241 | ``poky/meta/conf/distro/include/default-distrovars.inc`` file:: | ||
242 | |||
243 | COMMERCIAL_AUDIO_PLUGINS ?= "" | ||
244 | COMMERCIAL_VIDEO_PLUGINS ?= "" | ||
245 | |||
246 | If you | ||
247 | want to enable these components, you can do so by making sure you have | ||
248 | statements similar to the following in your ``local.conf`` configuration | ||
249 | file:: | ||
250 | |||
251 | COMMERCIAL_AUDIO_PLUGINS = "gst-plugins-ugly-mad \ | ||
252 | gst-plugins-ugly-mpegaudioparse" | ||
253 | COMMERCIAL_VIDEO_PLUGINS = "gst-plugins-ugly-mpeg2dec \ | ||
254 | gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse" | ||
255 | LICENSE_FLAGS_ACCEPTED = "commercial_gst-plugins-ugly commercial_gst-plugins-bad commercial_qmmp" | ||
256 | |||
257 | |||
258 | Of course, you could also create a matching list for those | ||
259 | components using the more general "commercial" in the | ||
260 | :term:`LICENSE_FLAGS_ACCEPTED` variable, but that would also enable all | ||
261 | the other packages with :term:`LICENSE_FLAGS` | ||
262 | containing "commercial", which you may or may not want:: | ||
263 | |||
264 | LICENSE_FLAGS_ACCEPTED = "commercial" | ||
265 | |||
266 | Specifying audio and video plugins as part of the | ||
267 | ``COMMERCIAL_AUDIO_PLUGINS`` and ``COMMERCIAL_VIDEO_PLUGINS`` statements | ||
268 | (along with the enabling :term:`LICENSE_FLAGS_ACCEPTED`) includes the | ||
269 | plugins or components into built images, thus adding support for media | ||
270 | formats or components. | ||
271 | |||
272 | Maintaining Open Source License Compliance During Your Product's Lifecycle | ||
273 | ========================================================================== | ||
274 | |||
275 | One of the concerns for a development organization using open source | ||
276 | software is how to maintain compliance with various open source | ||
277 | licensing during the lifecycle of the product. While this section does | ||
278 | not provide legal advice or comprehensively cover all scenarios, it does | ||
279 | present methods that you can use to assist you in meeting the compliance | ||
280 | requirements during a software release. | ||
281 | |||
282 | With hundreds of different open source licenses that the Yocto Project | ||
283 | tracks, it is difficult to know the requirements of each and every | ||
284 | license. However, the requirements of the major FLOSS licenses can begin | ||
285 | to be covered by assuming that there are three main areas of concern: | ||
286 | |||
287 | - Source code must be provided. | ||
288 | |||
289 | - License text for the software must be provided. | ||
290 | |||
291 | - Compilation scripts and modifications to the source code must be | ||
292 | provided. | ||
293 | |||
294 | There are other requirements beyond the scope of these three and the | ||
295 | methods described in this section (e.g. the mechanism through which | ||
296 | source code is distributed). | ||
297 | |||
298 | As different organizations have different methods of complying with open | ||
299 | source licensing, this section is not meant to imply that there is only | ||
300 | one single way to meet your compliance obligations, but rather to | ||
301 | describe one method of achieving compliance. The remainder of this | ||
302 | section describes methods supported to meet the previously mentioned | ||
303 | three requirements. Once you take steps to meet these requirements, and | ||
304 | prior to releasing images, sources, and the build system, you should | ||
305 | audit all artifacts to ensure completeness. | ||
306 | |||
307 | .. note:: | ||
308 | |||
309 | The Yocto Project generates a license manifest during image creation | ||
310 | that is located in ``${DEPLOY_DIR}/licenses/``\ `image_name`\ ``-``\ `datestamp` | ||
311 | to assist with any audits. | ||
312 | |||
313 | Providing the Source Code | ||
314 | ------------------------- | ||
315 | |||
316 | Compliance activities should begin before you generate the final image. | ||
317 | The first thing you should look at is the requirement that tops the list | ||
318 | for most compliance groups --- providing the source. The Yocto Project has | ||
319 | a few ways of meeting this requirement. | ||
320 | |||
321 | One of the easiest ways to meet this requirement is to provide the | ||
322 | entire :term:`DL_DIR` used by the | ||
323 | build. This method, however, has a few issues. The most obvious is the | ||
324 | size of the directory since it includes all sources used in the build | ||
325 | and not just the source used in the released image. It will include | ||
326 | toolchain source, and other artifacts, which you would not generally | ||
327 | release. However, the more serious issue for most companies is | ||
328 | accidental release of proprietary software. The Yocto Project provides | ||
329 | an :ref:`archiver <ref-classes-archiver>` class to | ||
330 | help avoid some of these concerns. | ||
331 | |||
332 | Before you employ :term:`DL_DIR` or the :ref:`archiver <ref-classes-archiver>` class, you need to | ||
333 | decide how you choose to provide source. The source :ref:`archiver <ref-classes-archiver>` class | ||
334 | can generate tarballs and SRPMs and can create them with various levels | ||
335 | of compliance in mind. | ||
336 | |||
337 | One way of doing this (but certainly not the only way) is to release | ||
338 | just the source as a tarball. You can do this by adding the following to | ||
339 | the ``local.conf`` file found in the :term:`Build Directory`:: | ||
340 | |||
341 | INHERIT += "archiver" | ||
342 | ARCHIVER_MODE[src] = "original" | ||
343 | |||
344 | During the creation of your | ||
345 | image, the source from all recipes that deploy packages to the image is | ||
346 | placed within subdirectories of ``DEPLOY_DIR/sources`` based on the | ||
347 | :term:`LICENSE` for each recipe. | ||
348 | Releasing the entire directory enables you to comply with requirements | ||
349 | concerning providing the unmodified source. It is important to note that | ||
350 | the size of the directory can get large. | ||
351 | |||
352 | A way to help mitigate the size issue is to only release tarballs for | ||
353 | licenses that require the release of source. Let us assume you are only | ||
354 | concerned with GPL code as identified by running the following script: | ||
355 | |||
356 | .. code-block:: shell | ||
357 | |||
358 | # Script to archive a subset of packages matching specific license(s) | ||
359 | # Source and license files are copied into sub folders of package folder | ||
360 | # Must be run from build folder | ||
361 | #!/bin/bash | ||
362 | src_release_dir="source-release" | ||
363 | mkdir -p $src_release_dir | ||
364 | for a in tmp/deploy/sources/*; do | ||
365 | for d in $a/*; do | ||
366 | # Get package name from path | ||
367 | p=`basename $d` | ||
368 | p=${p%-*} | ||
369 | p=${p%-*} | ||
370 | # Only archive GPL packages (update *GPL* regex for your license check) | ||
371 | numfiles=`ls tmp/deploy/licenses/$p/*GPL* 2> /dev/null | wc -l` | ||
372 | if [ $numfiles -ge 1 ]; then | ||
373 | echo Archiving $p | ||
374 | mkdir -p $src_release_dir/$p/source | ||
375 | cp $d/* $src_release_dir/$p/source 2> /dev/null | ||
376 | mkdir -p $src_release_dir/$p/license | ||
377 | cp tmp/deploy/licenses/$p/* $src_release_dir/$p/license 2> /dev/null | ||
378 | fi | ||
379 | done | ||
380 | done | ||
381 | |||
382 | At this point, you | ||
383 | could create a tarball from the ``gpl_source_release`` directory and | ||
384 | provide that to the end user. This method would be a step toward | ||
385 | achieving compliance with section 3a of GPLv2 and with section 6 of | ||
386 | GPLv3. | ||
387 | |||
388 | Providing License Text | ||
389 | ---------------------- | ||
390 | |||
391 | One requirement that is often overlooked is inclusion of license text. | ||
392 | This requirement also needs to be dealt with prior to generating the | ||
393 | final image. Some licenses require the license text to accompany the | ||
394 | binary. You can achieve this by adding the following to your | ||
395 | ``local.conf`` file:: | ||
396 | |||
397 | COPY_LIC_MANIFEST = "1" | ||
398 | COPY_LIC_DIRS = "1" | ||
399 | LICENSE_CREATE_PACKAGE = "1" | ||
400 | |||
401 | Adding these statements to the | ||
402 | configuration file ensures that the licenses collected during package | ||
403 | generation are included on your image. | ||
404 | |||
405 | .. note:: | ||
406 | |||
407 | Setting all three variables to "1" results in the image having two | ||
408 | copies of the same license file. One copy resides in | ||
409 | ``/usr/share/common-licenses`` and the other resides in | ||
410 | ``/usr/share/license``. | ||
411 | |||
412 | The reason for this behavior is because | ||
413 | :term:`COPY_LIC_DIRS` and | ||
414 | :term:`COPY_LIC_MANIFEST` | ||
415 | add a copy of the license when the image is built but do not offer a | ||
416 | path for adding licenses for newly installed packages to an image. | ||
417 | :term:`LICENSE_CREATE_PACKAGE` | ||
418 | adds a separate package and an upgrade path for adding licenses to an | ||
419 | image. | ||
420 | |||
421 | As the source :ref:`archiver <ref-classes-archiver>` class has already archived the original | ||
422 | unmodified source that contains the license files, you would have | ||
423 | already met the requirements for inclusion of the license information | ||
424 | with source as defined by the GPL and other open source licenses. | ||
425 | |||
426 | Providing Compilation Scripts and Source Code Modifications | ||
427 | ----------------------------------------------------------- | ||
428 | |||
429 | At this point, we have addressed all we need to prior to generating the | ||
430 | image. The next two requirements are addressed during the final | ||
431 | packaging of the release. | ||
432 | |||
433 | By releasing the version of the OpenEmbedded build system and the layers | ||
434 | used during the build, you will be providing both compilation scripts | ||
435 | and the source code modifications in one step. | ||
436 | |||
437 | If the deployment team has a :ref:`overview-manual/concepts:bsp layer` | ||
438 | and a distro layer, and those | ||
439 | those layers are used to patch, compile, package, or modify (in any way) | ||
440 | any open source software included in your released images, you might be | ||
441 | required to release those layers under section 3 of GPLv2 or section 1 | ||
442 | of GPLv3. One way of doing that is with a clean checkout of the version | ||
443 | of the Yocto Project and layers used during your build. Here is an | ||
444 | example: | ||
445 | |||
446 | .. code-block:: shell | ||
447 | |||
448 | # We built using the dunfell branch of the poky repo | ||
449 | $ git clone -b dunfell git://git.yoctoproject.org/poky | ||
450 | $ cd poky | ||
451 | # We built using the release_branch for our layers | ||
452 | $ git clone -b release_branch git://git.mycompany.com/meta-my-bsp-layer | ||
453 | $ git clone -b release_branch git://git.mycompany.com/meta-my-software-layer | ||
454 | # clean up the .git repos | ||
455 | $ find . -name ".git" -type d -exec rm -rf {} \; | ||
456 | |||
457 | One thing a development organization might want to consider for end-user | ||
458 | convenience is to modify | ||
459 | ``meta-poky/conf/templates/default/bblayers.conf.sample`` to ensure that when | ||
460 | the end user utilizes the released build system to build an image, the | ||
461 | development organization's layers are included in the ``bblayers.conf`` file | ||
462 | automatically:: | ||
463 | |||
464 | # POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf | ||
465 | # changes incompatibly | ||
466 | POKY_BBLAYERS_CONF_VERSION = "2" | ||
467 | |||
468 | BBPATH = "${TOPDIR}" | ||
469 | BBFILES ?= "" | ||
470 | |||
471 | BBLAYERS ?= " \ | ||
472 | ##OEROOT##/meta \ | ||
473 | ##OEROOT##/meta-poky \ | ||
474 | ##OEROOT##/meta-yocto-bsp \ | ||
475 | ##OEROOT##/meta-mylayer \ | ||
476 | " | ||
477 | |||
478 | Creating and | ||
479 | providing an archive of the :term:`Metadata` | ||
480 | layers (recipes, configuration files, and so forth) enables you to meet | ||
481 | your requirements to include the scripts to control compilation as well | ||
482 | as any modifications to the original source. | ||
483 | |||
484 | Compliance Limitations with Executables Built from Static Libraries | ||
485 | ------------------------------------------------------------------- | ||
486 | |||
487 | When package A is added to an image via the :term:`RDEPENDS` or :term:`RRECOMMENDS` | ||
488 | mechanisms as well as explicitly included in the image recipe with | ||
489 | :term:`IMAGE_INSTALL`, and depends on a static linked library recipe B | ||
490 | (``DEPENDS += "B"``), package B will neither appear in the generated license | ||
491 | manifest nor in the generated source tarballs. This occurs as the | ||
492 | :ref:`license <ref-classes-license>` and :ref:`archiver <ref-classes-archiver>` | ||
493 | classes assume that only packages included via :term:`RDEPENDS` or :term:`RRECOMMENDS` | ||
494 | end up in the image. | ||
495 | |||
496 | As a result, potential obligations regarding license compliance for package B | ||
497 | may not be met. | ||
498 | |||
499 | The Yocto Project doesn't enable static libraries by default, in part because | ||
500 | of this issue. Before a solution to this limitation is found, you need to | ||
501 | keep in mind that if your root filesystem is built from static libraries, | ||
502 | you will need to manually ensure that your deliveries are compliant | ||
503 | with the licenses of these libraries. | ||
504 | |||
505 | Copying Non Standard Licenses | ||
506 | ============================= | ||
507 | |||
508 | Some packages, such as the linux-firmware package, have many licenses | ||
509 | that are not in any way common. You can avoid adding a lot of these | ||
510 | types of common license files, which are only applicable to a specific | ||
511 | package, by using the | ||
512 | :term:`NO_GENERIC_LICENSE` | ||
513 | variable. Using this variable also avoids QA errors when you use a | ||
514 | non-common, non-CLOSED license in a recipe. | ||
515 | |||
516 | Here is an example that uses the ``LICENSE.Abilis.txt`` file as | ||
517 | the license from the fetched source:: | ||
518 | |||
519 | NO_GENERIC_LICENSE[Firmware-Abilis] = "LICENSE.Abilis.txt" | ||
520 | |||