Chapter 13. Achieving GPL Compliance

In this chapter, we learn how to fulfill open source license compliance and how we can use Poky to provide the needed artifacts such as source code, licensing text, and the list of derivative work. This is critical for most products being introduced in 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 the copyright law in order to maximize rights and express freedom. It impacts our day-to-day work in such a way that companies must know how to deal with open source and free software licenses as they have a high 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 virtually include all 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, and how do we fulfill copyleft compliance requirements?

Note

This chapter describes how the Yocto Project can help you in the task, but be aware that...

Managing software licensing with Poky

One important Poky feature is the capability of license for license management. 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 kind of licenses present in it.

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.

Tip

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 with the copyright, license, and author name; this information is regarding the recipe itself. Then, there is a set...

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 needed artifacts that should be shared as part of the copyleft compliance accomplishment 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 use the core-image-full-cmdline image for the qemuarm machine. To start with our example, examine the files under build/tmp/deploy/licenses/core-image-full-cmdline-qemuarm-<datastamp>, which are as follows:

• package.manifest: This lists all the packages into the image.

• license.manifest: This lists the names, versions, recipe names, and licenses for all packages. This file may be used for copyleft compliance...

Summary

In this chapter, we learned how Poky can help with copyleft license compliance accomplishment and also understood why it should not be used as a legal background. Poky enables us to generate source code, reproduction scripts, and license text for used packages, to be used in 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 understand how we can use the Yocto Project tools with an external BSP, the Freescale ARM BSP. We will use it to generate an image for use with the Wandboard machine.