Q&A with Andrew Updegrove, Gesmer Updegrove LLP, Partner
The following is for general information purposes only, and is not intended as legal advice.
The IEEE Standards Association (IEEE SA) is exhibiting at OSCON 2017 in Austin, Texas, 10-11 May 2017. Stop by Booth 207 to learn about the role that open source plays in IEEE standards development.
What is open source software, and what open source licenses is IEEE intending to use?
Open source software (OSS) is software made available in object and source code forms on licensing terms that meet the “Open Source Definition” maintained by the Open Source Initiative (OSI).[1] It’s a 10-part definition that addresses requirements such as free redistribution, technology neutrality, unrestricted scope of free use, etc. OSI has approved over sixty licenses, and they range from very simple to very detailed.
While there are scores of licenses on the OSI’s list—many with only minor variations from other licenses on the list—only a small number of those licenses are frequently used. IEEE is currently focused on three of the most commonly used licenses.
One is the 3-Clause BSD License, which falls into the “very simple” category. It permits code redistribution, with or without modification, subject only to the following three terms:
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
- 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.
- Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
The disclaimer that follows looks pretty much like any other license disclaimer you’ve ever read.
So, the concept behind the BSD 3-Clause is, here’s some code—use it. Other than requiring you to give credit where credit is due and saying, don’t come back and sue us, that’s pretty much all the BSD 3-Clause requires. It’s an extremely permissive, unrestrictive license. The code can be changed, redistributed, bundled … basically, whatever the developer wants to do with it. The BSD 3-Clause License was one of the earliest OSS licenses created, and millions of different software programs have been distributed under its terms.
The second license the IEEE will be using is the Apache License, Version 2.0. Apache in some ways is similar in that it seeks to provide very similar freedom of use without including significant restrictions on top of what you saw in the BSD license. However, it tries to be a lot more specific on the legalities, with the goal of resolving many of the ambiguities of simpler licenses. This is understandable, because those simpler licenses were developed at a time when virtually no software was patentable. In 1998, however, a federal court ruled that many types of software could be patented. So, that raised the question of whether the BSD 3-Clause Licenses did, or did not, imply the grant of a patent license to the extent the code included anything patented or patentable. In order to answer that question, the members of the Apache Foundation decided to write a license that included an explicit patent license. While they were at it, they expanded on some other topics as well. These aspects are appreciated by those developing software within the IEEE environment, so this license has been included as well.
The Apache Foundation decided to provide another document as well, this time to cover the increasingly common situation where the code in question had many authors rather than just one (you’ll remember that a little program called Linux had gotten off the ground by then as well). So they wrote a Contributors License Agreement (CLA) with “inbound” terms that mirrored those contained in the “outbound” Apache License so that the conveyance of rights was as seamless and consistent as possible. IEEE created a very similar CLA for use by those contributing code to projects that decide to use the BSD 3-Clause License. The reason was the same—to provide the maximum amount of certainty for the IEEE, as the host of the development, and for the upstream and downstream licensees as well.
The third license that IEEE will be using came from CERN (European Organization for Nuclear Research) in Switzerland, and it’s explicitly for hardware designs. The CERN license necessarily is rather different, even though it was created to achieve very similar results. That’s because, unlike OSS code, which is a finished product, most open source hardware collaborations create designs, not finished projects. So instead of licensing a finished product, like OSS, you have to go ahead and build it yourself. There are some exceptions to that rule. Just as standards groups sometimes develop reference implementations of a standard, some open hardware projects build hardware reference platforms as well. In the more common case, though, what’s being collaboratively developed is the design, and that’s what the CERN license is drafted to address. Because of the differences between code and designs, and because CERN decided that it wanted to achieve some additional goals besides just saying “here it is, use it,” there are a number of extra requirements, some substantive and some basically administrative in nature. Here are some examples:
- The software running on the hardware can either be subject to the CERN license, or expressly not subject to it.
- Copies of related documentation can be redistributed—but only verbatim, unless the licensee makes the modified documentation available on a public server for at least three years so that the original licensor can see how the documentation has been changed.
Covering all the differences would make this too long an answer, but there will be an IEEE FAQ when the new licenses and CLAs (yes, there will be a CLA matched to the CERN license as well) are rolled out that will explain the CERN license in greater detail.
What does this all have to do with IEEE and its stakeholders?
Let’s say you are a standards consumer. You’re going to be finding that more and more often you’ll be invited to use OSS in conjunction with a standard, with that OSS coming from the same source (in this case, IEEE). That OSS could be instantiated in a related test tool, or as reference implementation of a standard, so you don’t have to build an implementation of the standard yourself, or as an alternative—and sometimes required—element of the standard itself. With the new IEEE open source licensing program, IEEE working groups will be able to do all these things in order to better achieve the goals they want to achieve. In other words, they’ll have the flexibility to take whatever path they think will work best, and will interoperate most efficiently with the fast-evolving, increasingly hybrid open standards/open source world we live in.
One of the things I like to point out is that business people don’t join standards organizations in order to develop standards. They join standards organizations because they have a problem they want to solve; they’re actually pretty agnostic about how they might go about solving it. Engineers are the same way. If they’re using OSS all the time, and they decide using OSS is the best tool for the job, IEEE wants to make that possible. So, if interoperability is the goal and you can achieve it faster and better with OSS, that’s what you’re going to be able to do.
If you’re not already comfortable with OSS but want to be able to participate and be effective and relevant in this new hybrid environment, you’ll need to understand OSS as a new way of achieving technical and business goals. Not surprisingly, there are some significant differences between how open standards and open source are handled, so you’ll want to get your arms around the basics of what OSS licensing is all about, too.
How will IEEE manage the process of including open source in its technical work from the IPR perspective?
As I mentioned earlier, there are lots of different ways and situations where IEEE working groups may want to develop code. The challenge is determining how to manage these instances on an IPR (intellectual property rights) basis. IPR relating to open standards and IPR relating to open source vary significantly. In broad strokes, standards make sense only if you cannot change them, while the freedom to change is fundamental to the value proposition of open source. And some aspects of traditional RAND (reasonable and non-discriminatory) obligations run counter to software freedoms. As a result, it’s important to adopt licenses and procedures that are compatible with IEEE’s existing IPR policy, which IEEE must carefully consider: building the bridges needed to allow open source software and standards to play nicely in the same sandbox.
Andrew Updegrove is a founding partner of Gesmer Updegrove LLP, a Boston-based technology law firm. He has helped create and represent more than 150 open standards and open source development organizations, and by both multinational companies as well as government agencies to advise them in achieving their standards and open source-related policies and goals.