Chapter 13. Achieving GPL Compliance

In this chapter, we will see how we can ensure open source license compliance and how we can 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 that are introduced into the market nowadays, as open source code needs to live side by side with proprietary code.

Understanding copyleft

Copyleft is a legal way to use copyright law in order to maximize rights and express freedom. It greatly impacts our day-to-day work to such a large extent that companies must know how to deal with open source and free software licenses, as they have a big impact on their products.

When building a Linux distribution, there are at least two projects being used: the Linux kernel and a compiler. The most commonly used compiler nowadays is the GNU Compiler Collection (GCC).

The Linux kernel is released under the GPLv2 license, and the GCC is released under the GPLv2, GPLv2.1, and GPLv3 licenses, depending on the project used.

However, a Linux-based system can include virtuallyall projects available throughout the world, in addition to all applications made by the company for its product. How do we know the number of projects and licenses that are included, and how do we fulfill copyleft compliance requirements?

Note

This chapter describes how the Yocto Project can help you...

Managing software licensing with Poky

One important Poky feature is the ability to manage licenses. Most of the time, we, as developers, do not care about licenses because we keep our focus on our own bugs. However, when creating a product, it is very important to care and know about licenses and the kinds of licenses present in the product.

Poky keeps track of licenses, works with commercial and noncommercial licenses, and has a strategy to work with proprietary applications, at least during the development cycle.

Note

One important thing to know, at first, is that a recipe is released under a certain license, and it represents a project released under a different license. The recipe and the project are two different entities and they have different licensing, so the two different 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...

Using Poky to achieve copyleft compliance

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.

License auditing

To help us to achieve copyleft compliance, Poky generates a license manifest during the image build, located at build/tmp/deploy/licenses/<image_name-machine_name-datestamp>/.

To demonstrate this process, we will use the core-image-full-cmdline image for the qemuarm machine. To start with our example, look at the files under build/tmp/deploy/licenses/core-image-full-cmdline-qemuarm-<datastamp>, which are as follows:

• image_license.manifest: This lists the recipe names, versions, licenses, and the files of packages that are available in build/tmp/deploy/image/<machine> but not installed inside rootfs. The most common examples...

Summary

In this chapter, we learned how Poky can help with copyleft license compliance and also learned why it should not be used as a legal background. Poky enables us to generate source code, reproduction scripts, and license text for packages usedin our distribution. In addition, we learned that the license manifest generated within the image may be used to audit the image.

In the next chapter, we will learn how we can use Yocto Project's tools with real hardware. We will use the Yocto Project to generate an image for use with the Beagle Bone Black, Raspberry Pi, and Wandboard machines.