IoT and the Special Risks and Rewards of Open Source Software and Technology Standards – Part II

Heather Meeker O'Melveny & Myers LLP
Open Source Software Capital

This is Part II in a two-part series about IoT and Open Source.

Part I of this article laid out the basic principles of opens source licensing that apply particularly to IoT. This article lays out some of the technical principles that apply to IoT and open source licensing and lists some takeaways and best practices for complying with open source licenses in IoT.

Operating Systems and Applications
Some Software Has no Binary Form
Dynamic Linking? Static Linking?
Distribution
“Anti-Tivoization”
Takeaways

Operating Systems and Applications

When learning about open source licensing, you may hear about operating systems and applications. These are all just kinds of software, but they serve different purposes. The operating system is the “traffic cop” of your computer. It runs all the time and “boots” when you turn on your computer. It is the interface between your computer and the real world—like through Wi-Fi modems, printers, or keyboards. An application or app is a program for a specific purpose that runs “on top of” the operating system.

Applications can’t access the hardware of your computer except through the operating system. Applications have limited permission to affect other applications or the basic systems of the computer, for security and reliability reasons. Therefore, applications run in what is called “user space”—a virtual sandbox that is defined by the operating system interface. When we say that an application runs on Windows, Linux or iOS, that means it is written to the specifications for interacting with that operating system. This is important to open source because the most significant piece of open source software in the world is the “Linux kernel”: an open source operating system licensed under GPL.

Some Software Has no Binary Form

Some software is written in so-called high-level languages or scripting languages, such as Javascript, Python, Ruby, HTML and CSS. Next time you are looking at a web page, try right-clicking and selecting the option to “view page source.” You will see some source code, probably in HTML, CSS or Javascript—the languages used to develop web pages. In contrast, operating systems and other basic software is in binary form because it needs to run very quickly. Web pages and applications spend most of their time waiting for you, the user, to respond, so they don’t need to be quite as fast. The implication for open source licensing is that source code is always available by definition.

Dynamic Linking? Static Linking?

Some people are very confused by talk about dynamic and static linking. It’s a concept that comes up in open source licensing, particularly for licenses like GPL and LGPL. If you are writing a program, you don’t write it all from scratch. In fact, you mostly stitch together existing libraries of software, much of which may be open source software. When you put your program together, you use a “build” program that tells your program where to find the libraries it is using. The way the libraries are integrated can be called links. But don’t confuse this with the generic term link, or a link on a web site (sometimes called a hyperlink).

Statically linked libraries load when the program launches. But that can make the program slow to load and take up a lot of computing space. So, an alternative is to dynamically link the library, which tells the computer to find, load, and execute the library only when and if needed. If you have ever used a program on your desktop and seen a “DLL error,” that means your computer was instructed by the build program to look for a dynamically linked library—a DLL—that it could not find. That might happen, for example, if the program installation was incomplete. But all you need to know about links, for the purpose of open source licensing, is that the decision to statically or dynamically link software is based on technical needs, and it affects one license called LGPL. The challenge for IoT is that it runs in small systems where there is often no separation between kernel and user space, and the ability to dynamically link may not exist.

Static linking isn’t relevant to high-level languages (Java, Python, PERL, PHP, CSS, Javascript, HTML). Most high-level languages are effectively dynamically linked.

Distribution

Open source licenses impose conditions only if you take certain actions allowed by the license, and the main triggering action is distributing the software. So, many people want to know what constitutes distribution. Distribution is one of the rights granted under US copyright law. Though the term is not precisely defined, we know a lot about what it means for GPL because of broad community practice. Distribution is transferring a copy from one legal person to another. That means that if one person within an organization gives a copy to another person within the same organization, it is not distribution because both persons are acting as agents of the same legal entity. But IoT software is almost always distributed. That’s quite different from the software business generally, where more and more software is being deployed via SaaS or from the cloud instead of via on-premises installations.

“Anti-Tivoization”

There is one more concept in open source software licensing that especially affects IoT. The “Version 3” licenses—GPL3, AGPL3 and LGPL3—contain special requirements for consumer electronics. The terms are actually set forth in GPL3, but AGPL3 and LGPL3 reference the same terms.

GPL3 Section 6: Conveying Non-Source Forms.

A distributor must provide not only source code but Installation Information

“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.”

These requirements prevent distributors of User Products—which roughly means a consumer electronics product—from locking down the device to prevent modification of the software. But most device manufacturers do not want to provide this information, because they are worried that do-it-yourself changes will cause maintenance and support problems, regulatory problems, or even personal injury.

Takeaways

That was a lot of background, but now we can see why IoT is a special case for open source compliance.

•
IoT software is almost always distributed, which means that anyone selling IoT products will have to comply with notice and source code offer conditions. For more information on issues arising from notice requirements, take a look here. IoT devices often lack a user interface, and that makes delivering notices difficult or expensive. It usually requires including a CD or paper notice—both of which can be expensive to process through a supply chain—or resorting to web-based notices, which don’t satisfy the license notice conditions for licenses like GPL.
•
IoT software is usually “low level” and therefore always executes in binary form. That has two implications. First, you cannot take advantage of the “shortcut” of relying on notices that are baked into a source code delivery; and second, for copyleft licenses, you will always need to make a separate source code offer—usually in your customer agreement. Here is a typical omnibus open source provision in a customer agreement:
Open Source Licenses
Notwithstanding the foregoing [reference license grant], Customer acknowledges that certain components of the Product (“Open Source Components”) may be covered by so-called “open source” software licenses, which means any software licenses approved as open source licenses by the Open Source Initiative or any substantially similar licenses. To the extent required by the licenses covering third party Open Source Components, the terms of such licenses will apply to such Open Source Components in lieu of the terms of this Agreement. To the extent the terms of the licenses applicable to third party Open Source Components prohibit any of the restrictions in this Agreement with respect to such Open Source Component, such restrictions will not apply to such Open Source Component. To the extent the terms of the licenses applicable to third party Open Source Components require Licensor to make an offer to provide source code or related information in connection with the Open Source Components, such offer is hereby made. Any request for source code or related information should be directed only to: __________________.
•
Small devices like IoT, particularly devices with real time operating systems, often have a monolithic architecture, meaning that it is difficult to separate programs or libraries in ways that allow you to comply with licenses like GPL, and particularly LGPL. Accordingly, software in IoT devices should usually be limited to software covered by a permissive license. For a list of permissive licenses, take a look at the Blue Oak Council List.
•
Many IoT devices are consumer devices, and therefore subject to the GPL and LGPL 3 requirements to deliver Installation Information for User Products. Accordingly, many companies making IoT devices do not allow any version 3 licensed software in their products.

It’s certainly possible to comply with open source licenses for software in IoT, but it takes a little extra work. The above tips should help you understand the issues and risks and develop a compliance process.

To learn more about open source licensing, visit Heather’s Open Source Software Licensing channel on YouTube, or COSS Media, which provides actionable insights for Commercial Open Source Software (COSS) founders and builders. You may also contact the author at:

•
Email: hmeeker@heathermeeker.com
•
Blog: heathermeeker.com
•
Twitter: @HeatherMeeker4

Heather J. Meeker specializes in open source software licensing and strategy and is a Founding Portfolio Partner at OSS Capital.

Heather is a frequent speaker at PLI Programs, including Internet of Things 2021: Everything is Connected, and Co-Chair of Open Source Software 2021 – from Compliance to Cooperation. She is the author of Open Source for Business, available for purchase on Amazon.com. A free download of the book is also available at www.heathermeeker.com/links (follow the instructions to join the book update list, and the welcome email will provide instructions for downloading the latest version of the book).

Disclaimer: The viewpoints expressed by the authors are their own and do not necessarily reflect the opinions, viewpoints and official policies of Practising Law Institute.

To submit an article for consideration, please contact the editor at: editor.plichronicle@pli.edu

This article is published on PLI PLUS, the online research database of PLI. The entirety of the PLI Press print collection is available on PLI PLUS—including PLI's authoritative treatises, answer books, course handbooks and transcripts from our original and highly acclaimed CLE programs.

Sign up for a free trial of PLI PLUS at pli.edu/pliplustrial.