The Standards Blog


Tuesday, February 25th, 2020 @ 07:59 AM
Contributed by: Joanna Lee
Views: 289

Scanning Tools 140When you incorporate open source (OS) code into larger programs, it is risky to assume that the official license for the project is the only license you need to comply with. This is true even if the only OS code your company consumes comes from software projects with permissive rather than copyleft licenses.  (For an explanation of the difference between copyleft and permissive OS licenses, and why copyleft-licensed code cannot be used in proprietary applications, please see this earlier post about OS license types ).  Any OS component could be subject to a myriad of OS licenses that you might be unable to identify without performing a source code audit and scan.  This is why regular use of source code scanning tools (a.k.a. software composition analysis software) is essential to any open source compliance program.

Wednesday, February 19th, 2020 @ 12:53 PM
Contributed by: Russ Schlossbach
Views: 229

DoJ Logo 140If you participate in standards development organizations, open source foundations, trade associations, or the like (Organizations), you already know that you’re required to comply with antitrust laws.  The risks of noncompliance are not theoretical – violations can result in severe criminal and civil penalties, both for your organization and the individuals involved.  The U.S. Department of Justice (DOJ) has in fact opened investigations into several standards organizations in recent years.  

Wednesday, February 12th, 2020 @ 10:16 AM
Contributed by: Joanna Lee
Views: 588

OSS :License Word CloudNot all free and open source (OS) software licenses have been created to achieve the same goals, and failure to understand the differences can have dire consequences.  Some OS licenses are business-friendly in that they allow the code to be combined with proprietary code without imposing OS licensing requirements on the resulting combination.  Others do not allow such combinations in any circumstances (at least if the developer wishes the products to remain proprietary), and some licenses fall somewhere in between these two extremes.  Here is the minimum you need to know about OS license types before incorporating OS code into software you develop.

Friday, January 10th, 2020 @ 11:12 AM
Contributed by: Andy Updegrove
Views: 606

Courtesy Wikimedia Commons/ and The GIMP if someone asksIn its simplest form, FOSS development requires almost no traditional economic, physical or management support. All that is needed is a place to host code in a manner that allows multiple developers to collaborate on its further development. As FOSS has become more commercially valuable and widely incorporated into vendor and customer strategic plans, however, additional layers of services and structures have evolved to allow FOSS development to become more efficient and robust and the user experience even more productive. These include training, a growing certification testing network, a variety of tools to assist in legal compliance matters, and a network of hosting entities providing a wide range of supporting services and frameworks.

The development of these tools has been an important factor in allowing the commercial marketplace to rapidly evolve from a closed, proprietary world to one heavily based on OSS.

Thursday, January 2nd, 2020 @ 02:22 PM
Contributed by: Andy Updegrove
Views: 544

Courtesy of Wikimedia Commons/Jonnymccullagh [CC BY-SA 3.0 (]It would not be an exaggeration to say that the magic of open source software (OSS) is based as much on legal innovation as it is on collaboration. Indeed, the essential innovation that launched free and open source software was not Richard Stallmans GNU Project, but his announcement of a revolutionary new licensing philosophy, and the actual license agreements needed to put that philosophy into effect. Only later did global collaboration among developers explode, riding the wave of Stallman's licenses, Linus Torvald's pioneering work in creating the distributed development process, and rapidly increasing telecommunications bandwidth.

In this installment, we'll explore how Stallman's philosophy spread and forked, and where it has taken us to today.

Friday, December 27th, 2019 @ 03:10 PM
Contributed by: Andy Updegrove
Views: 1,976

半ー太郎 [CC BY-SA 4.0 (]Everybody uses open source software (OSS) today. Millions of people contribute to the code itself. Indeed, a substantial percentage of the users and creators of OSS today are young enough to have never known a world that didn't rely on OSS. In other words, it's very easy to take this remarkable product of open collaboration for granted.

But that would be a mistake, especially given how unlikely it was that such a unique phenomenon could ever have taken hold. If you've never had reason to wonder how all this came about, this three part series is for you. In it, I'll review how remote developers began to collaborate to create OSS, how the legal tools to make its distribution possible evolved, and how the world came to embrace it.

Wednesday, December 11th, 2019 @ 03:04 PM
Contributed by: Andy Updegrove
Views: 1,262

RISC-V Foundation LogoFor over thirty years U.S. companies have enjoyed a home court advantage in developing information and communications technology (ICT) standards. Specifically, the overwhelming majority of the more than five hundred consortia founded over the last thirty-five years to develop ICT standards have been formed under U.S. laws and headquartered in the U.S. That’s hardly a surprise because the vast majority of the companies that founded these same consortia were also American companies. Now the times may be a-changing.

Tuesday, August 27th, 2019 @ 12:19 PM
Contributed by: Lee Gesmer
Views: 387

This post was written by my partner, Lee Gesmer. It describes a case involving the scope of the most fundamental commitment that makes standards development and adoption possible. You can read more posts by Lee at


snapdragon-200x200.jpegAntitrust  law in the United States is regulated by both the Antitrust Division of the Department of Justice (DOJ) and the Federal Trade Commission (FTC). Usually, these two agencies are able to reach a common understanding on antitrust policy and enforcement. Infrequently, they find themselves in disagreement.

Currently, the proper antitrust treatment of standard-essential patents and patent-holder commitments to make these patents available on “fair, reasonable and non-discriminatory terms” is such an occasion. The disagreement has come to a head in FTC v. Qualcomm, now on appeal before the Ninth Circuit.

Wednesday, August 21st, 2019 @ 11:22 AM
Contributed by: Andy Updegrove
Views: 577

Bureau_of_Industry_and_Security_seal_0.jpgNinety-odd days ago, the US Bureau of Industry and Security (BIS) added Huawei and 68 of its affiliates to its “Entity List.” BIS added another 46 Huawei affiliates last week (collectively, “Huawei”), thereby making it illegal for US individuals and entities to disclose certain technology and software to Huawei and such blacklisted affiliates without a license. At the same time, it tempered the blow by issuing a Temporary General License that, among other things, allowed US entities to continue to participate with Huawei to develop 5G standards.

For all other standards, Huawei’s continued participating would be legal only to the extent a given standard setting organization (SSO) either applied for, and received, a license from the BIS, or could credibly analogize its processes to an exception recognized under existing Export Administration Regulations (EAR). The closest exceptions are disclosures at public conferences and in connection with coauthoring journal articles. Ever since, standards setting organizations (SSOs) counting Huawei as a member have been scrambling, trying to figure what they can and cannot allow Huawei to do.

On Monday of this week, three things happened that provided some answers. But almost all the answers were bad.

Monday, August 5th, 2019 @ 02:15 PM
Contributed by: Andy Updegrove
Views: 227

Network%20Diagram%20140.jpgThe vast majority of free and open source (FOSS) projects today operate on a license in/license out basis. In other words, each contributor to a code base continues to own her code while committing to provide a license to anyone that wants to download that code. Of course, no developer ever actually signs a downstream license. Instead, all contributors to a given project agree on the OSI (Open Source Initiative) approved license they want to use, and those terms stand as an open promise to all downstream users.

But is that really the best way to operate? What about the minority of projects that require contributors to assign ownership of their code to the project? They clearly think assignment is a better way to go. Are they right?