The versions – three of them to date – of the GNU General Public License (GPL) were drafted with the intention of maintaining legal protection for the principle of open-source software: that it should protect the freedom of the user of software ‘to share and change all versions of a program – to make sure it remains free software for all its users’.
This concept of freedom is broken down by the Free Software Foundation, which publishes the GPL, into four individual freedoms:
- the freedom to use the software for any purpose
- the freedom to change the software to suit the user’s needs
- the freedom to share the software with friends and neighbours, and
- the freedom to share the changes the user makes
Every user of open-source software published under one of the three versions of the GPL is required to comply with that version’s terms. In fact, v1, v2 and v3 of the GPL each adopt different approaches to the enforcement of these four freedoms: it is important to understand the differences between them, to avoid the security and development risks that can trap the unwary.
It is also important to know that each version is a different license in its own right and drafted to meet particular requirements. This means that v2 is not an updated or improved version of v1, and v3 is not an updated or improved version of v2: they are different licenses, and each is equally valid and legally enforceable.
For embedded device manufacturers, v3 of the GPL gives rise to special difficulties with compliance, as we shall see.
Open-source software transformed the embedded device industry
It is no exaggeration to say that the embedded device industry would not exist in its present form without open-source software. Of course, the most familiar example of open-source software is the Linux® operating system, the backbone of the majority of connected embedded devices today. But the entire Linux-based embedded software ecosystem consists of thousands of subordinate open-source software products, each licensed separately. The flourishing of open-source software available to all has produced an extraordinary amount of innovation precisely because of the open nature of the programs.
The GNU GPL’s role in protecting the four freedoms has been a crucial pillar supporting the open-source structure. It should be said, however, that the GPL does not have an exclusive hold on the open-source software market: there are various other respected open-source licenses in widespread use today.
Nevertheless, the GPL is the most common and the best known. Embedded device manufacturers will be particularly familiar with GPL v2, which is the license under which the Linux kernel has been made available for many years. Every embedded device must make its use of the Linux kernel compliant with v2. In practice, this has turned out to be easily done, and in our experience, users of the FoundriesFactory® platform achieve GPL v2 compliance as a matter of course.
Increasing caution about the use of GPL v3 in embedded devices
Compliance with GPL v3 is a different matter, however. To understand why, it helps to know the background to the introduction of GPL v3. The Linux OS and the open-source software movement arose out of a desire to provide users of computers, and particularly of personal computers, with the freedom to modify and re-install the software running on the devices they owned. As stated above, the GPL protects this freedom.
A PC is a device that inherently supports the development and installation of software programs, so the freedom to modify open-source software is built into the hardware design.
A problem arose with the introduction of application-specific computers – devices such as TV set-top boxes that were based on a PC’s architecture, and had the same basic hardware capabilities as a PC, but that had a specific and limited set of functions, such as streaming rights-protected video content.
Like a PC, such application-specific computers were often based on the Linux OS, but the hardware and user interface provided little or no scope for the user to inspect, modify or re-install the open-source software that ran on them. And there is no provision in v1 or v2 of the GPL for requiring the manufacturer of a device based on open-source software to provide the device owner with an open door into the device to enable modification and re-installation of GPL-licensed source code.
So GPL v3 was written, in part, to enforce a right for the user to gain access to the hardware in order to be able to inspect and modify the source code.
While the original intention behind GPL v3 was to address issues observed with managed embedded devices, particularly in response to the TiVo scenario, it has inadvertently presented challenges for product makers (due the requirement to allow access to the hardware to enable local software modifications). This contrasts with the historical use of open-source software under v1 or v2 of the GPL in embedded devices, where manufacturers were not obliged to grant users the right to modify the embedded software.
Security risks inherent in complying with GPL v3
While most of the body of open-source code on which embedded devices rely is today released under GPL v2 or licenses other than the GPL, certain open-source software programs are only available under GPL v3. If any embedded device manufacturer is tempted to use such software, it would do well to consider the security risks to their embedded devices inherent in complying with the license’s terms. Most embedded devices can be upgraded through the installation of over-the-air (OTA) updates: the development, distribution and installation of such updates is under the control of the device manufacturer. This allows it to apply cast-iron security features that protect the embedded device from attack or intrusion by hackers.
Compliance with GPL v3 forces the manufacturer to provide a means for the user to gain access and be permitted to modify all v3-licensed source code stored on the device. There is a considerable risk that this opens a back door to malicious actors to exploit the opening to v3 software, creating a vulnerability that makes it easier for a cyber-attacker to develop the capability to hack into a fleet of networked devices.
The security risks also have to be considered alongside the development risks: the sheer complexity of the task of granting user access to GPL v3 programs while quarantining all other software could create a huge development overhead, compromise device security, and substantially delay a product’s entry to the market.
Oopen-source software license-aware with Foundries.io
What to do given the difficulties and risks associated with GPL v3? The advice of Foundries.io, based on our experience working with a wide range of embedded device manufacturers that use the FoundriesFactory platform, is to avoid the use of GPL v3 programs unless there is an exceptionally strong reason for doing so. And if the decision is to use a GPL v3 program, to do so in full awareness of the risks and difficulties associated with compliance.
In fact, nearly all embedded device manufacturers in nearly all circumstances can do all that they need to do with the vast body of open-source software available under GPL v1 and v2 and the other licenses applied to open-source programs.
Users of the FoundriesFactory DevSecOps product have a particular advantage here, which is that the platform provides a tool for tracking the licensing of every single program embedded in every single iteration of a product, throughout its lifetime from development through installation to decommissioning. This license information is collected in a continuously updated software bill-of-materials (SBOM) collated individually for every production unit of every product variant. The FoundriesFactory platform includes a utility for alerting developers when they use GPL v3 source code: the tool ensures that development teams can avoid mistakenly or inadvertently embedding GPL v3 code in a device.
For more information and help with open-source license compliance, or to evaluate the FoundriesFactory platform’s SBOM and license management functions, contact Foundries.io today.