“Internet of Things” (IoT) devices—from Amazon Echos and Fitbits to the sensors that power smart cities—all contain embedded software. Most are built on the open source Linux operating system and contain dozens (or hundreds) of open source applications and software libraries. These open source components do everything from supporting the most basic functions of the device, to providing the framework for the graphic interface you see when you log on to the device. (The rest of this article will refer to open source components collectively and individually as “OSS.”)
IoT device makers don’t cobble all of this OSS together themselves. Typically, they source their embedded computing hardware (or key portions of it) from OEM hardware producers or system integrators, and these hardware suppliers provide a basic operating system for them. The device maker will then typically add their own custom software to provide user-facing functionality.
The many OSS components in an IoT device are all subject to copyright, and sometimes to patents as well.  They are made available subject to open source licenses that govern the reproduction, modification, and distribution of the software. The device maker must therefore comply with the licenses for all OSS embedded in its product, even if that OSS originates from a supplier, because it distributes all that third-party software every time it ships a product.
The presence of third-party OSS in an IoT device means that device makers must:
- (A) understand the terms of OSS licenses and assess whether they can comply with those terms;
- (B) provide end users the compliance materials required by the OSS licenses applicable to their products, including (1) copyright notices and license information for each OSS component and (2) source code for certain OSS components where required by the OSS license;
- (C) invest in the open source management tools, processes, and policies necessary to meet all these challenges comprehensively and efficiently; and
- (D) take steps to ensure that their suppliers provide them with the information necessary to enable them to fulfill their OSS-related obligations.
A. Open Source License Compliance
Open source licenses come in many shapes and sizes, but can be broadly grouped into three categories:
● Permissive licenses contain very few conditions. The MIT license, for example, requires only that a copy of the license and the developer’s copyright notice be included with all copies of the software distributed by the licensee. Permissive licenses (like most open source licenses) alsot ypically include warranty disclaimers and limitations of liability. The Apache License is unique among the most popular permissive licenses in its treatment of patents. It contains an express patent grant, and provides for defensive termination of that grant if a licensee alleges that the covered software infringes its patents.
● Reciprocal licenses  include an important quid pro quo. In addition to the requirements commonly found in permissive licenses, they require licensees to provide the source code for the OSS, including any derivative works, every time they distribute the OSS to a third party. By far the most common reciprocal license is the GNU General Public License (GPL) version 2. Reciprocally licensed OSS requires the most care: if an IoT device maker incorporates a GPL-licensed component into a proprietary program embedded in its product, it may be obligated to provide the source code for the entire combined work to its customers.
● Semi-reciprocal licenses (or “weak copyleft” licenses), such as the Mozilla Public License and Eclipse Public License, take the middle path. Licensees must provide source code for the OSS itself, including any modifications they’ve made to it, to anyone they distribute the OSS to. But, they are not generally required to provide the source code for proprietary works that interact with or incorporate the OSS .
1. Common Compliance Requirements
Any device of reasonable complexity will contain software under each of the three types of license outlined above. Therefore, every device maker can expect that its compliance obligations when distributing its product to consumers will include:
- Providing a copy of the license for every OSS component embedded in its product.
- Providing the copyright notices and other IP attribution statements required by various licenses.
Some licenses, like the MIT and BSD license, incorporate copyright statements into the license itself. This makes compliance simultaneously simpler (license and attribution requirements are met by providing a single document) and more complex (it’s not sufficient to provide a single copy of the MIT license to cover all MIT-licensed components in your product, because each contains a copyright statement that must be included).
- Providing (or offering to provide) a copy of the source code for reciprocally or semi-reciprocally licensed components, and for any derivative works of the reciprocally licensed components.
- Including notices of its modifications to OSS components, where required. Many OSS licenses of all types require that, when a licensee distributes the source code for an OSS component, it must include notices in any modified source code files. So where a device maker is required to distribute the source code for a component (e.g. because it’s reciprocally licensed) or chooses to do so, it must include these notices.
A minority of OSS licenses require licensees to include specific notices in the advertising for their products, if the advertising mentions the OSS product or the features it provides. Sometimes referred to as“obnoxious advertising clauses,” such provisions are probably overlooked more often than they’re honored, but are nonetheless worth keeping an eye out for.
2. Reciprocal Licensing Issues
While all open source licenses place basic conditions upon licensees when they distribute OSS, reciprocal licenses deserve particular attention, because they can impact the licensing of proprietary software components as well. Compliance with reciprocal (and even semi-reciprocal) licenses is a complex topic, and application is always case-specific, so we’ll only cover the basics here. For deeper treatment of more specific issues, see the resources in the footnotes. 
a. GPLv2, Copyleft, and Derivative Works
Version 2 of the GPL (GPLv2) is by far the most common reciprocal OSS license and the most commonly encountered in IoT software stacks. GPLv2 (like other variants of the GPL) has an ideological bent that’s stated plainly in the license: its purpose is to ensure that the users of software have the freedom to study, modify, and redistribute the software that they use. It’s a long license, partly because it endeavors to close many loopholes by which licensees might attempt to deprive end users of these freedoms. And its language is idiosyncratic: a lawyer can have years of experience reading and applying the license and still get stumped on occasion.
GPLv2 is also the license for Linux, the core of the operating system run by nearly every IoT device, and for a number of other core OSS operating system components that are more or less essential when building an embedded device. It also applies to some components that are commonly used in IoT devices, depending on their function. For example, FFmpeg, a library for video playback and manipulation, is subject to either LGPLv2 or GPLv2, depending on how it’s configured.
The key provision to pay attention to in GPLv2 and other reciprocal licenses is the copyleft provision. In short, this term says:
- if you distribute the GPLv2-licensed OSS to someone, you must also provide them with the complete corresponding source code;
- if you distribute a modified version of the OSS to someone, you must provide the complete corresponding source code for the OSS together with the modifications; and
- if you distribute software that is a derivative work of the OSS to someone, you must provide the complete corresponding source code for the entire derivative work.
What is a derivative work of a software application or library? That’s a topic of vigorous debate andoccasional rancor within the open source community, but here are a couple points of general agreement:
- When you modify the source code of an OSS component directly, you have created a derivative work and must include your modifications when providing source code to end users.
- If your software interfaces with an OSS program using its standard external interface (e.g. by running the OSS program and sending commands to it via the operating system), and you have not modified the OSS program, your software is not a derivative work of the OSS program.
The points of contention are far more numerous and sticky:
- If your program depends upon an unmodified OSS software library, is the program a derivative work of that library?
- Does the technical means by which your program interfaces with the OSS software library affect the answer? Specifically, if your program is written in the C programming language, does it matter whether the program is “statically” or “dynamically” linked to the library?
Static linking involves compiling both components together into a single executable program file. Dynamic linking involves compiling them separately, but incorporating a small amount of
interface code from the library into your program. Dynamic linking makes it possible for multiple
programs on a system to use the library without duplicating its object code in each program. The
functionality of the resulting program is the same regardless of which method of linking is used.
The Free Software Foundation—the nonprofit that authored and stewards the GPLlicenses—takes the view that linking of either kind yields a derivative work.  This view is embedded in its semi-reciprocal license the LGPL,  which requires licensees to provide sourcecode for programs that use the licensed library, unless the library is linked dynamically and the program incorporates no more than a minimal amount of interface code from the library itself. 
- If you modify an OSS software library to include an external interface and interact with it via the operating system, specifically to avoid linking it to your program, is your program a derivative work of the modified library?
This question was the subject of recent litigation by the Software Freedom Conservancy against VMware, which for many years used interface code from the Linux kernel in its ESXi Hypervisor software, to enable ESXi’s proprietary operating system kernel to interface with GPL-licensed device drivers. The case was dismissed on grounds unrelated to the core claims, and was abandoned by Software Freedom Conservancy when VMware subsequently removed the Linux code from its product.
- If you produce a loadable Linux kernel module containing a custom driver for hardware specific to your device, is that module a derivative work of Linux?
While several of these questions have been the subject of litigation, none have been definitively settled by the courts.
b. GPLv3 and Installation Information
Version 3 of the GPL (GPLv3) works much like GPLv2, but includes a number of new provisions. The most important of these for IoT device makers is the “Installation Information” provision in Section 6. According to this term, if you include a GPLv3-licensed component in a device sold to consumers (a “User Product”), and it is possible to update the software in that device, you must include “Installation Information” as part of the complete corresponding source code for the GPLv3 component:
“Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made. 
To paraphrase, the device maker must provide whatever information is necessary to enable an end user who has modified the GPLv3 component to install and run that modified copy onto the device. If installation of software onto the device requires the use of a special process or a cryptographic key, these must be provided to the end user. And the device can’t be designed to cease functioning simply because the GPLv3 component has been modified (although the manufacturer can void warranties for modified devices and prohibit them from accessing its networks).
This provision caused a stir among consumer electronics manufacturers when it was introduced and was one reason among many that the maintainers of Linux have cited for not adopting GPLv3 and instead continuing to use GPLv2. Device makers still commonly avoid incorporating GPLv3 components in their products. While GPLv3 is less widely used than GPLv2, there are a number of OSS projects using GPLv3 that are potentially useful in embedded devices, including Samba (an application that enables Linux devices to interact with Windows systems), and most software produced by the GNU Project.
 Some third-party components or OSS subcomponents commonly used by IoT devices are dedicated by their authors to the public domain rather than released under an OSS license and are free for general use.
 Reciprocal licenses are also referred to as “copyleft” licenses (by supporters) or “viral” licenses (by detractors).
 An important caveat to this general characterization is the GNU Lesser General Public License (LGPL), which is among the more popular semi-reciprocal licenses. The LGPL’s source-provision requirement is discussed in detail below.
- HEATHER MEEKER, OPEN SOURCE FOR BUSINESS (2d ed. 2017)
- VAN LINDBERG, INTELLECTUAL PROPERTY AND OPEN SOURCE: A PRACTICAL GUIDE TO PROTECTING CODE (2008)
- ARMIJN HEMEL AND SHANE COUGHLAN, PRACTICAL GPL COMPLIANCE (2017), available at https://www.linuxfoundation.org/tools/practical-gpl-compliance/
- Copyleft.org, Copyleft and the GNU General Public License: A Comprehensive Tutorial and Guide, available at https://copyleft.org/guide/
 See Free Software Foundation, Frequently Asked Questions about the GNU Licenses, https://www.gnu.org/licenses/gpl-faq.en.html#GPLStaticVsDynamic (refer to entry “Does the GPL have different requirements for statically vs dynamically linked modules with a covered work?”).
 See Free Software Foundation, GNU Lesser General Public License version 2.1, https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html (hereinafter, “LGPLv2.1”). LGPL stands for “Lesser General Public License.” It used to stand for “Library General Public License,” as it was designed to enable open source libraries to be used by proprietary programs. The FSF’s founder Richard Stallman changed the name when he decided that it was better for developers to use the GPL for libraries as well, so that developers wishing to use the libraries would have an incentive to release their code under the GPL as well. See Free Software Foundation, Why you shouldn't use the Lesser GPL for your next library, https://www.gnu.org/licenses/why-not-lgpl.en.html.
 See LGPLv2.1 § 5