The Standards Blog

The Lafayette Campaign

How hard could it be to hack a Presidential Election?

Funny you should ask: The Lafayette Campaign

The Lafayette Campaign

U.S. Moves Towards Resolving Permitting US Companies to Collaborate with Huawei on 5G Standards

Dept.%20of%20Commerce%20Seal%20140.pngRegular readers will know that the addition of Huawei and scores of its subsidiaries to the U.S. Bureau of Industry and Security Entity List last May has had a serious impact on standards setting organizations (SSOs). Specifically, the related rules bar companies from disclosing certain types of U.S. origin technology to companies on the Entity List, and technology is exactly what is disclosed in the course of standards development. Due to a lack of guidance from the Department of Commerce, SSOs have been left wondering whether they can allow Huawei and its subsidiaries (collectively, “Huawei”) to participate in their technical activities. When they decide that the answer is yes, U.S. companies must then decide whether they read the regulatory tea leaves the same way. Many have not.

Over the past two weeks the situation has taken a more hopeful turn. The impetus for this change has a lot to do with the law of unexpected consequences – in this case, the results of the Department of Commerce refusing to provide the type of certainly that the private sector needs when political winds shift.

A Brief History of Open Source Software, Part 3: The FOSS Environment Today

Open Source/Open Standards

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.

A Brief History of Open Source Software, Part 2: OSS Licenses and Legalities

Open Source/Open Standards

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.

A Brief History of Open Source Software

Open Source/Open Standards

半ー太郎 [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.

RISC-V Foundation Says Goodbye to the United States

Open Source/Open Standards

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.

Guest Post: FTC and DOJ Face Off Over Antitrust And FRAND Licensing In FTC v. Qualcomm

Intellectual Property Rights

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.

Some Concerns Open Source Should Worry About, Part 3: Distributed Ownership

Open Source/Open Standards

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?

Some Concerns Open Source Should Worry About, Part 2: Antitrust

Open Source/Open Standards

US Dept. of Justice LogoFree 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.

Some Concerns Open Source Should Worry About - Part 1

Courtesy of Linda F. Palmer/Wikimedia Commons -  GNU Free Documentation LicenseNot 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.

OSI Board Pledges Allegiance to Open Source Definition, Now and Forever

Open Source/Open Standards

Illustration of the Cnut and the Waves episode by Alphonse-Marie-Adolphe de Neuville, courtesy of the Wikimedia CommonsEverything changes over time, from the constitutions of nations to political theories. Should the Open Source Software Definition be any different?

Earlier this week the Board of Directors of the Open Source Initiative issued an Affirmation of the Open Source Definition, inviting others to endorse the same position. The stated purpose of the release was to underline the importance of maintaining the open source software (OSS) definition in response to what the directors see as efforts to “undermine the integrity of open source.” Certainly, that definition has stood the test of time, and OSI has ably served as the faithful custodian of the definition of what can and cannot be referred to as OSS.

That said, while well-intentioned, the statement goes too far. It also suggests that the directors would do well to reflect on what their true role as custodians of the OSS definition should be.

Subscribe to The Lafayette Campaign