As governments are moving to regulate the software market, the old tools of product liability regulation from the non-digital world are in need of an update, in order to realise the full set of opportunities, and grapple with the challenges presented by this new, less physical ecosystem. At OFE, we are particularly focused on the impacts on Open Source Software (OSS) and open innovation. Our work with the EU Cyber Resilience Act (CRA) during recent months has both underscored the need to increase Open Source capacity and competence among governments, but also a need for more active participation from Open Source stakeholders as trusted partners of governments and societies. We all share the goal of a more secure and resilient development and use of software.
In a nutshell, this blog post argues for the same thing OFE has argued for since its inception: better dialogue between regulators, policymakers and open technology experts. In the current context, I will firstly share some reflections on why the Commission’s first proposal for a way to exempt OSS development from the CRA missed the mark, secondly why we see the focus on capacity-building in government in the Securing Open Source Software Act in the U.S. Senate as more constructive, thirdly on the need for public-private investments into the maintenance of Open Source Software, and lastly on the responsibility of Open Source stakeholders to work with governments as partners to solve the challenges of software markets and of the digital age more generally.
Open Source is important, it grew fast, but is still under-appreciated by policymakers
Open Source Software has won, and with that revolutionised the way software is built, used, and maintained globally. This innovation model has enabled the creation of high-quality software at a speed previously inconceivable, while also empowering users to modify and share code without friction and restrictions. It is estimated that 70-90% of software in existence is Open Source. It runs the digital infrastructure that we and our society rely on. It is also often in Open Source projects that innovation at the bleeding edge takes place.
In what is arguably the first horizontal regulation for the software market, the EU Cyber Resilience Act was introduced to improve the security and resilience of “products with digital elements”. It is laudable that the European Commission did include language to protect Open Source from undue burden, and the European Commission has shown a lot of leadership in other areas when it comes to OSS.
However, in this case, the CRA language unfortunately missed the mark. As drafted, the Act would have a disproportionate negative impact on the development of Open Source software.
It is also striking that the original proposal dedicates a mere recital to open source, despite the role of OSS in the world today. Now, the number of lines of text on a topic is not necessarily linked to the importance given to the topic by its authors. Unfortunately, this short recital doesn’t yet achieve its objective of exempting Open Source development (note: not Open Source products) from the CRA obligations.
This post is not going to get into the details of this, but to look at why the incomplete exemption came to be in the first place. If you’re interested in the CRA specifically, you can read about it here and here.
Focus on capacity-building in government in the Securing Open Source Software Act in the U.S. Senate
In contrast to Europe’s CRA, the Securing Open Source Software Act introduced in the US Senate aims to “authorize the Cybersecurity and Infrastructure Security Agency (CISA) to improve the security of open-source software, or computer code that is publicly available for anyone to use or modify.”
One of the key aspects of the US Act is the focus on capacity-building within the government. Of course, this is a very different kind of law than the CRA, as it merely outlines the duties of the Cybersecurity and Infrastructure Security Agency (CISA).
CISA is tasked to “perform outreach and engagement to bolster the security of open source software”. That, in our view, seems to be a logical first step to avoid unintended consequences in later lawmaking. In contrast, for the CRA, the open source ecosystem has a feeling of not having been consulted. As I read it, CISA will build an Open Source Programme Office (OSPO). OFE has argued for a few years now that this is a key tool to increase competence and capability of governments at all levels.
In an EU context, we have several institutions that could play this role, or could be tasked with it. The European Commission was one of the first public administrations in the world to build an Open Source Programme Office (OSPO). The EC OSPO is well-connected with many parts of the OSS ecosystem. Their input (and perhaps from other technical experts across DG DIGIT) in the drafting process of laws affecting open source, such as the CRA, the AI Act and the New Product Liability Directive, would arguably help keeping the effects to the intended ones, and avoiding the unintended.
Need for public and private investments into the maintenance of Open Source Software
All of this is not to say that Open Source doesn’t need to improve. For example, one of the challenges of Open Source Software development is the sustainability of the software over time. Unlike proprietary software, which is typically maintained by a single vendor, Open Source Software is maintained by a community of developers who contribute to the software on a voluntary basis. While this model has many benefits, it also means that approaches to sustainability over time must look different.
Setting a regulatory framework to increase the security of software products should be preceded by, or at least combined with, active, ambitious steps to increase public and private investments in the maintenance of Open Source Software. Governments can, and already do, play a role in supporting the development and maintenance of critical Open Source Software by providing funding and other resources. European governments have in fact taken some of the most promising first steps through the work of, for example, the Sovereign Tech Fund in Germany and the European Commission’s Next Generation Internet initiative. The new entities/policy vehicles, named the European digital infrastructure consortiums (EDICs), have a lot of potential in this area, but getting it right, both in terms of goals and governance, will be key to success.
These government efforts should, in addition to direct investments, investigate how they could create more incentives for the private sector to increase their contribution to the sustainability of Open Source Software they rely on.
This is an area where Europe can lead, and the next Commission should really consider ambitious policy in this area.
Responsibility of Open Source stakeholders to engage with policymakers
There is also a need for Open Source stakeholders to step up their game. Policymakers may not be familiar with the Open Source development model or may not fully grasp the opportunities and implications of the Open Source model for increased security. It is the responsibility of Open Source stakeholders to participate as trusted partners of governments and society.
Open Source is big and important now, and providing early and constructive feedback on proposed regulations and standards to ensure that Open Source Software is properly considered in policy discussions is the obvious next step.
In recent years, we have seen the founding of APELL, the European Open Source Business Association, representing thousands of SMEs. And in the past months, we’ve seen several organisations, large and small, spending countless hours finding a way forward for the CRA, while making sure that the ultimate goals of the Act are met.
We all care deeply about increased cyber security and resilience. Together, we will get there.