Open Source and Free Software Licenses for Embedded Systems

Introduction

The Operating System (OS) plays a central role in a computational system: it provides an abstraction of the hardware for running applications and manages all machine resources. A few decades back, Operating Systems were evolving along with the PC industry, while embedded systems were still composed of very specialized applications, usually running on microcontrollers with much less computational power than general-purpose systems. However, the rapid growth of microelectronics technologies pushed embedded systems to a new level: embedded platforms emerged on the market using powerful SoCs (System-on-a-Chip) that can run general-purpose OSes with a performance comparable (or in some cases, even better) with PCs. Additionally, the embedded hardware became less expensive and the FOSS and Open Source Hardware community brought to life many open embedded platforms through successful projects, such as the Raspberry PI. Currently, a huge number of embedded platforms running FOSS artifacts (such as the Linux kernel) are inexpensive and available to the general public. This evolution was a key factor to the development of new technologies, such as the development of IoT devices and has changed the embedded industry as well. Manufacturers started to use FOSS in their products (routers, smartphones, TVs, among many others) and several licensing issues arose throughout the years. In 2008, Free Software Foundation (FSF) initiated a lawsuit against Cisco claiming that GNU's GPL (General Public License) and LGPL (Lesser General Public License) were violated in many Linksys (acquired by Cisco) products (Lee, 2008). GNU's tools binutils, coreutils, glibc, among others, were distributed only in binary form along with several Linksys firmwares without meeting all requirements fixed by these licenses. In 2009 the parties announced a joint agreement that included a non-disclosed monetary contribution from Cisco to FSF (Smith, 2009). In 2006 the German programmer Harald Welte prosecuted D-Link (iFross, 2006) claiming that software of his authorship that were part of Linux kernel was distributed along with the firmware of a storage device (Wireless G Network Media Storage DSM G600) without meeting all GPL requirements. The violations were found after a reverse engineering process made by the author, which bought a device. The court ordered the reimbursement of all costs expended by the author with the legal process, purchasing of the device, and reverse engineering work, besides enforcing D-Link to meet all license requirements. The same programmer was also the plaintiff in other cases brought to court in different countries. In 2013, Welte prosecuted the company FANTEC for using his software kernel components (netfilter/iptables) in one of their firmwares (FANTEC 3DFHDL Media Player device) without the release of complete corresponding source code (Welte, 2013), in this case the source code was released but it did not fully match the version present in the firmware. The court decided a penalty fee to FANTEC plus expenses for the lawyers. Additionally, it was requested that the company disclosed the exact information about the media player firmware. These examples show how not following all FOSS license requirements can bring not only image but also financial damages to the companies. Although the source code is open and widely available, there are important differences on license terms across different FOSS licenses. One key term is how derivative works can be licensed by the licensees (the person or entity who is receiving the license from a licensor). For some licenses, it's mandatory to release any derivative work under the same terms of the original license. Although the term “derivative work” can be broadly interpreted, such clauses can impact specially embedded systems, because while in a PC environment the distinction between user applications and the OS might be very clear, and applications usually don't require specific device drivers to work (or when required, they are already provided by the general purpose OS), the components of an embedded system are tied to the hardware and distributed as a whole along with device's firmware. In many cases it also requires device drivers that must be developed and integrated to the running OS. For some processor and microcontroller architectures that don't support different execution modes, application's code is built along with the OS kernel and flashed to the device's memory. These aspects are critical for embedded commercial applications, the license of all third party system components must be considered at the design phase in order to facilitate any licensing decision to be made. There are different approaches that can be followed to make a proprietary embedded application running on an Operating System with a FOSS license and still meet all requirements with no license violation. For instance, running a proprietary application on top of an unmodified FOSS Operating System is in accordance with FOSS license terms. However, eventual changes made to the OS kernel must be released under the same license terms depending on the type of the FOSS license. Thus, stakeholders must know all the terms, the differences and the obligations of licensors and licensees when dealing with FOSS artifacts. The goal of this chapter is to provide the foundation knowledge and cover the main aspects of FOSS licensing focusing on Operating Systems for commercial embedded systems. For the simplicity of understanding, throughout the text the term commercial shall be used interchangeably with the term proprietary in order to define systems, applications and/or any products that contain artifacts commercially developed and/or not licensed under a FOSS license. Note that even if a commercial application releases software artifacts under a FOSS license, the same concerns must be taken into account in order to meet all license requirements.