O'Melveny & Myers LLP
Open Source Software Capital
This is Part II in a two-part series about IoT and Open Source.
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 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.
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.
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.
That was a lot of background, but now we can see why IoT is a special case for open source compliance.
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: __________________.
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
Heather J. Meeker specializes in open source software licensing and strategy and is a Founding Portfolio Partner at
Heather is a frequent speaker at PLI Programs, including
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:
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