O'Melveny & Myers LLP
Open Source Software Capital
This is Part I in a two-part series about IoT and Open Source.
Open source software is everywhere today, including in nearly every IoT device. Open source software licenses require companies to comply with various license conditions, and those requirements can be particularly challenging for IoT products. It’s also probably fair to say that there is a lot of noncompliance with open source license conditions in the IoT landscape. Indeed, the Software Freedom Conservancy, currently the main community enforcer of licenses like GPL in the United States, has recently received a grant for compliance activity focused on embedded software and IoT. This article explains why IoT can be a “perfect storm” for open source compliance and includes some suggestions for best practices to reduce the risk of noncompliance.
The first part of this article is a refresher on the principles of open source licensing compliance and some of the technical principles that are particularly important for open source and IoT. The last part explains how these principles apply to IoT.
You might have heard that there are lots of open source licenses—too many to understand. That’s not exactly right. The Open Source Initiative (OSI) is the organization that reviews licenses to certify that they are open source licenses, which means they meet the Open Source Definition. OSI has approved over 100 licenses, but most of them are rarely used. The six licenses listed below are the top licenses used, and almost all open source software—well over 99%—is under one of these licenses. So, to understand open source licenses, we really need to understand only these six. The ones in CAPITALS are called permissive licenses, and the others are copyleft licenses.
Almost all open source licenses require you to deliver a license notice if you distribute the software. License notices are not complicated to prepare and present, but they can be a lot of work and operationally challenging to implement.
License notices are different from copyright notices. A copyright notice says, for example, Copyright 2021 Heather Meeker. A license notice is a document that sets out the terms on which the software is offered. Sometimes, both the copyright notice and the license notice are part of the same document, and sometimes they are separate. But each of them is almost always in a “plaintext” file, with the extension txt. Plaintext files have no formatting, like fonts, italics, and paragraph spacing. It is a format that can be delivered across any platform and in a small file.
Licenses that include the copyright notice are sometimes called template licenses. For example, the BSD license looks like this:
Copyright <YEAR> <COPYRIGHT HOLDER>
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The angle brackets indicate that the licensor (the author) should fill in the blanks in the copyright notice at the top.
Other licenses, like the Apache License 2.0, don’t use this approach. For these licenses, any copyright notice must be delivered separately. Sometimes, copyright notices are in the header (comments at the top) of the source code file. Sometimes, they are in a separate file. Sometimes, they are missing. The Apache License 2.0, which is one of the most popular open source licenses, also specifies that any text file called “NOTICE.TXT” included in the source code should be considered a notice file and must be delivered upon distribution of the software, along with the license notice. For example:
If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License.
Most open source licenses use the Apache 2.0 approach of separating copyright notices, but none of the other major open source licenses has a specific NOTICE.TXT requirement. You might notice a copyright notice in some licenses, like GPL version 2:
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
That notice actually refers to the copyright for the text of the license, not the software it covers.
License notices are easy to deliver if you distribute software in source code form. Notices are “baked in” to source code because they consist of text files that are included in the top-level folder of the source code package.
This photo shows an example of an open source notice file on a Samsung mobile phone, circa 2017. This kind of notice file is necessary if you distribute binaries only. Your product may include hundreds of open source packages under many licenses, and your notices must be in or with your product. So, for a product that contains binaries only, you need a game plan for delivering your notices.
Permissive licenses, like the BSD license to Apache 2.0, are very easy to understand. They allow you to do anything you like with the software, under only one condition: if you distribute the software, you must include the license and copyright notice. This copy of the license serves to inform recipients that the software they are getting contains some software under the license, but it doesn’t limit how you can license a product that contains this software. It’s a very lightweight requirement.
Some open source licenses impose additional conditions—other than notice conditions—on the exercise of the distribution right. These licenses are usually called copyleft licenses. Copyleft licenses are sometimes called “viral,” but that is a misnomer that causes a lot of misunderstanding, so it is best to avoid using that word. Many people find copyleft confusing, but it can be boiled down to two conditions.
Copyleft comes in a few flavors. GPL is sometimes called a strong copyleft license because it applies to all of the code in a program. LGPL is a license that only applies to libraries of code, which are parts of programs, and is sometimes called weak or library copyleft. There are a few other weak copyleft licenses, which were written in a more traditional way than LGPL, and are intended to be straightforward to comply with. These licenses also apply to libraries.
For more on IoT and open source, see Part II of this article, which will discuss some of the technical principles that are important to IoT and open source and provide take-aways and best practices for open source compliance in IoT.
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:
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: email@example.com
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.