Open source licenses versus open source practices

As discussed in part one of this series, legal risk can be analyzed by answering three questions:

1. Who can be a plaintiff?
2. What arguments can the plaintiff make?
3. How likely is the plaintiff to win?

The Vizio case (Software Freedom Conservancy, Inc. v. Vizio, Inc. et al) increases risk along all three dimensions. It increases the number of possible plaintiffs, it expands the range of arguments that can be made, and - if the SFC is successful - provides persuasive authority that plaintiffs similar to SFC should be granted the same relief.

Nevertheless, the Vizio case, just like "traditional" open source enforcement cases, is about complying with the open source license. If you comply with the license, none of these possible plaintiffs have a case. What is changing, however, is that there is increasing risk associated with poor open source practices , separate from and in addition to simple compliance. One of the most significant of these sources of risk is the Executive Order on Improving our Nation's Cybersecurity, or the EO for short.

The Executive Order and open source

On May 12, 2021, the Biden administration issued an executive order on cybersecurity in response to nationwide security incidents involving SolarWinds as well as a well-publicized ransomeware attack against Colonial Pipeline. The EO highlighted the need to modernize the cybersecurity of the Federal government as well as establish protocols for sharing information relating to cybersecurity threats and breaches.

The EO is twenty-three very dense pages long, so you may not have read it. But buried about halfway down are the following provisions (emphasis added in bold):

Sec. 4. Enhancing Software Supply Chain Security. [...]

(e) ...[T]he Secretary of Commerce ... shall issue guidance identifying practices that enhance the security of the software supply chain.... includ[ing] standards, procedures, or criteria regarding: [...]

(vi) maintaining accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes, and performing audits and enforcement of these controls on a recurring basis;

(vii) providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website; [and..]

(x) ensuring and attesting, to the extent practicable, to the integrity and provenance of open source software used within any portion of a product.

What does this all mean? It means that within a year, anyone selling to the government, directly or indirectly, is going to have a number of new mandatory contract terms that will apply to all software procurement. These new contract terms will require automated, ongoing processes that identify the origin and use of open source software, and report on that usage to customers as part of a Software Bill of Materials (SBOM).

Focusing on open source practices and governance

What makes these provisions new is their complete independence from the world of copyright and license compliance. All of these requirements are about software procurement and development processes. Your organization may comply perfectly with its open source licenses, but it can still fail to fully comply with these guidelines. For example, the EO guidelines require ongoing scanning processes and reporting in an SBOM format. It requires that an organization have policies about the use of third party software, and that those policies be enforced.

As a practical matter, however, these guidelines nearly mandate open source compliance. If a company is fully complying with its open source licenses, then of course they are going to have policies around the use of open source software. Of course they are going to regularly scan their source code for open source, and report its use to their customers. About the only thing that is unique to the EO, above regular open source best practices, is the use of an SBOM as a reporting format -- and use of an SBOM is rapidly becoming a best practice as well. The EO is silent on license compliance, including compliance with copyleft licenses like the GPL. But the basic reporting required by the EO is already necessary for open source license compliance, even for very permissive licenses like the MIT and BSD licenses.

Another source of contract risk

Returning to the theme of this series, however, the EO creates a new type of contract risk for anyone even peripherally involved with the United States Federal government, and possibly for other companies as well. The consulting company PWC summarized the effect of the EO this way (emphasis in bold):

1. Federal executive agencies are expected to modernize their technology environment and security practices.
2. Federal contractors, including commercial-off-the-shelf (COTS) software providers, will likely see new cybersecurity standards built into contract terms. They will be required to share more information on cyber incidents.
3. The private sector will likely see a focus on software supply chain security, as well as on transparency through proposed consumer security labeling on software and internet of things (IoT) devices. As a result, software and IoT device companies should expect new security requirements and assessment standards.

This is the first time that open source processes have been at the center of widespread mandatory contract terms. This raises the stakes: Not only can customers sue as possible third party beneficiaries, but failure to prove that your company is following good open source supply chain security practices will be a breach of contract.

(This is part two of the series about increasing legal risks associated with poor open source practices, discussing the implications of the presidential Executive Order on Improving our Nation's Cybersecurity. Part one is about the SFC v. Vizio case. Part three discusses the dangers of FTC actions and shareholder suits resulting from poor open source practices.)