What’s happening in the world of consortia, standards,
and open source software
The Standards Blog tracks and explains the way standards and open source software impact business, society, and the future. This site is hosted by Gesmer Updegrove LLP, a technology law firm based in Boston, Massachusetts, USA. GU is an internationally recognized leader in creating and representing the organizations that create and promote standards and open source software. The opinions expressed in The Standards Blog are those of the authors alone, and not necessarily those of GU. Please see the Terms of Use and Privacy Policy for this site, which appear here. You can find a summary of our services here. To learn how GU can help you, contact: Andrew Updegrove
Not 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 …
In 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.
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 …
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.
For 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 …
This post was written by 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 https://masslawblog.com/ Antitrust 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.
Ninety-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.
The 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?
Free and open source software (FOSS) development has for many years enjoyed an increasingly positive public image. Particularly in the last several years, it’s become recognized as the foundation upon which most of the modern computing world rests. FOSS proponents include many governments, too, including many in Europe and the European Commission itself.
That’s all good and quite appropriate, but it’s worth keeping in mind that FOSS involves the conscious agreement of head to head competitors to work towards a common result – something that would otherwise normally be a red flag to antitrust regulators in the US, competition authorities in Europe, and to many of their peers throughout the world. To date, those regulators do not seem to have expressed any concerns over FOSS development generally. But that can change.
Not long ago, the Linux community celebrated the twenty-fifth anniversary of Linus Torvalds’ famous Internet post, and thus its birth. While Linux was not the first open source project (Richard Stallman announced his GNU Project eight years before), it soon became the poster child of a new way of collaborative development that changed not only how technology is created, but many other aspects of the world as well. Today, most critical software platforms and architectures are open source, and virtually all proprietary software is riddled with free and open source software (FOSS) as well. So, what could go wrong? Well, a lot, actually, unless we pause to think about where the potholes may emerge in the future, and how we can successfully navigate our way around them. That’s what I plan to do in a series of articles to which this is the introduction.