In this chapter, we will see how we can ensure open source license compliance and use Poky to provide the artifacts needed, such as the source code, licensing text, and the list of derivative work. This is critical for most products introduced into the market nowadays, as open source code needs to live alongside proprietary code.
Copyleft is a legal way to use copyright law to maximize rights and express freedom. However, it impacts our products. We must meet all obligations of open source and free software licenses.
When building a Linux distribution, at least two projects are used: the Linux kernel and a compiler. The GNU Compiler Collection (GCC) is still the most commonly used compiler. The Linux kernel uses the General Public License (GPL) v2 license, and the GCC uses the GPLv2, GPLv2.1, and GPLv3 licenses, depending on the project used.
However, a Linux-based system can include virtually all projects available worldwide, in addition to all applications made by the company for its product. So how do we know the number of projects and licenses included, and how do we fulfill copyleft compliance requirements?
Note
This chapter describes how the Yocto Project can help you in this task but be aware that you must know exactly what you need to provide and the possible license...
One important Poky feature is the ability to manage licenses. Most of the time, we only care about our bugs. However, managing licenses and the kinds of licenses used is crucial when creating a product.
Poky keeps track of licenses in every recipe. In addition, it has a strategy to work with proprietary applications during the development cycle.
Note
An important thing to know is that a recipe is released under a specific license and represents a project released under a different license. Therefore, the recipe and the project are two separate entities with specific licenses, so the two licenses must be considered part of the product.
In most recipes, information is a comment containing the copyright, license, and author name; this information pertains to the recipe itself. Then, there is a set of variables to describe the package license, and they are as follows:
LICENSE: This describes the license under which the package was...At this point, we know how to use Poky and understand its main goal. It is time to understand the legal aspects of producing a Linux-based system that uses packages under different licenses.
We can configure Poky to generate the artifacts that should be shared as part of the copyleft compliance process.
To help us achieve copyleft compliance, Poky generates a license manifest during the image build, located at build/tmp/deploy/licenses/<image_name-machine_name>-<datastamp>/.
To demonstrate this process, we will use the core-image-full-cmdline image for the qemux86-64 machine. To start with our example, look at the files under build/tmp/deploy/licenses/core-image-full-cmdline-qemux86-64-<datastamp>, which are as follows:
image_license.manifest: This lists the recipe names, versions, licenses, and the packages files available in build/tmp/deploy/image/<machine> but not...In this chapter, we learned how Poky can help with copyleft license compliance and why it should not be used as a legal resource. Poky enables us to generate source code, reproduction scripts, and license text for packages used in our distribution. In addition, we learned that the license manifest generated within the image might be used to audit the image.
In the next chapter, we will learn how to use the Yocto Project’s tools with real hardware. Then, we will use the Yocto Project to generate images for a few real boards.
© 2023 Packt Publishing Limited All Rights Reserved
