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

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.

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.

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.