In September of last year, the European Union (EU) announced the Cyber Resilience Act (CRA), which included new requirements for hardware and software products produced in the EU. Since the announcement, there have been growing concerns that the CRA is too ambiguous and represents unreasonable requirements for open source software.
There is general praise for the CRA's efforts to establish better standards for software and provide specific criteria for open source software. However, as it is currently written, the future of open source software in the EU remains uncertain and risks being irrevocably damaged.
Shortly after the announcement of the CRA, NLnet Labs, a non-profit foundation that develops free, liberally licensed, open-source software for DNS and BGP routing, raised concerns with their blog post, "Open-source software vs. the proposed Cyber Resilience Act." In the post, Maarten Aersten provided a detailed overview of the CRA's specific language that holds the greatest potential to negatively impact open source software in the EU.
In the post, Aersten articulates the primary issues, "At a high level the 'essential cybersecurity requirements' are not unreasonable, but the compliance overhead can range from tough to impossible for small or cash-strapped developers. The CRA could bring support to open-source developers maintaining the critical foundations of our digital society. But instead of introducing incentives for integrators or financial support via the CRA, the current proposal will overload small developers with compliance work."
Unpacking what he describes, it becomes clear Aersten's believed the CRA’s unilateral focus on compliance related to commercial software interaction, regardless of the type of software, is overreaching. He points out that while all software should have a process for vetting security, enforcing compliance standards that small open source teams or individuals can't reasonably meet could discourage contributors. As a result, they may be less likely to get involved or even stop working on critical open source software projects.
Aersten notes that the CRA does provide an exception, "In order not to hamper innovation or research, free and open-source software developed or supplied outside the course of a commercial activity should not be covered by this Regulation." However, the language of software developed "outside the course of a commercial activity" creates ambiguity, given there is no definition of that commercial activity.
This isn't the only time this particular language in the CRA has been cited. In December, Brian Fox pointed out the upsides of the European Union's (EU) Cyber Resilience Act (CRA). He also raised concerns regarding what could be interpreted as unintentionally targeting open source software distributors like Maven Central, PyPI, and npm.
Speaking on the impact to hosts of open source software, Brian called out, "... the liability associated with the current regulation would make this a prudent course of action in markets that adopt it as drafted. And the consequence of this would be Central, npm, PyPI, and countless other repositories being suddenly inaccessible to the European Union, which would be disastrous for both the EU and the ecosystem as a whole."
In this instance, Brian offers a unique perspective speaking from Sonatype's position as a commercial vendor and the steward of Maven Central, the largest public repository for open source Java components. Standing on both sides of commercial activity outlined by the CRA, he observed the same ambiguity Aersten is concerned about. Without clarification, these aspects of the CRA represent a real risk to the distribution and availability of open source software in Europe.
This sentiment can be seen in a February blog post from the Eclipse Foundation. They reach a similar interpretation of the CRA, citing, "... the CRA legislation (along with the companion revisions to the Product Liability Directive) in its current form will have enormous negative effects on both the open source community and the European economy."
More specifically, they call out similar points by Aersten, noting, "... any compliance burden be placed on the downstream commercial adopters and consumers, rather than the producers of open source."
The Python Software Foundation (PSF) followed the Eclipse analysis and commentary about a month later. Citing alignment with the aforementioned foundation, the PSF highlighted risks to the future of open source in the EU, especially as it pertains to the distribution and availability of open source software, "Any policy that does not provide clear carve outs for repositories offered for the public good will do irreparable harm to the individual’s accessibility to the power of modern software development."
These concerns should not be taken lightly. In its current form, the CRA could allow legitimate commercial entities to avoid responsibility for creating secure software. It's essential to consider how the CRA has diverged from more modern interpretations of liability and responsibility associated with producing "goods." While a discussion of goods in the context of software can slide into a semantic debate, there is growing support for treating organizations that produce software as manufacturers. This also means holding them accountable in similar ways.
Applying the paradigm of responsibility from other manufacturing industries, it would be unusual to accept that a manufacturer could produce something like an automobile without ensuring its safety and security. Even in cases where a supplier provides a defective part, the final assembler of the product, as shown by the evolution of case law, bears the ultimate responsibility.
The open source community has raised similar concerns about responsibility as well. As part of their earlier response, the PSF asked policymakers to consider, "Rather than following the code all the way upstream, we would prefer to see policy makers follow the money… Consumer liability and responsibility cannot be assigned until a product is assembled and something is for sale."
In some ways, this is a David and Goliath scenario. Looking at this from the perspective of the average open source contributor or maintainer, often just a small team or a single developer, it may be easier to stop contributing to open source than to try and change the CRA. Luckily, some of the most significant open source projects are heeding the call to bring attention to ensure the CRA is not taking open source software down an irreversible path in the EU. And that engagement isn't slowing down by any measure.
On April 17, the Eclipse Foundation and 12 other open source organizations submitted an open letter to the European Commission. The letter provides a stark warning, "If the CRA is, in fact, implemented as written, it will have a chilling effect on open source software development as a global endeavour, with the net effect of undermining the EU's own expressed goals for innovation, digital sovereignty, and future prosperity." In addition, they requested that going forward a partnership to engage the open source community "to ensure that future legislation and policy decisions are informed."
What started as isolated posts on a few blogs across as many months has gained momentum. Following the letter from the Eclipse Foundation, the Internet Systems Consortium (ISC) and NLnet Labs also sent a joint letter to the European Parliament committee working on the CRA.
Officially titled as a "plea for fairness for non-profit developers of open source software," they cite specific guidance from the recently released US Cyber Security Strategy, "Responsibility must be placed on the stakeholders most capable of taking action to prevent bad outcomes, not [..] on the open-source developer of a component that is integrated into a commercial product."
And this is important, as governments globally are using the US National Cybersecurity Strategy as a framework for their own policy and regulation.
It's unclear to what level, if any, the European Parliament and Representatives to the Council of the European Union will modify the language of the CRA. Unfortunately, inaction may prove detrimental in the long run. Based on the open source software community response, the CRA has stepped across a line much more clearly defined by legislation in other parts of the world. And these have provided examples of what it should be like, heralded as thoughtful approaches that acknowledge the role and value of open source software. Why the CRA has veered from that isn't clear.
Though pure speculation, it's possible the EU policymakers are underestimating the ability of leaders within the open source community to call members to action; it's not unusual for hubris to drive the winds of politics. If this is the case, it would be a tremendous folly for the EU. Not only could the legislation significantly affect access to the innovation offered by open source software, but it would also fail to recognize the various platforms the open source community uses to share its message.
If the last couple of weeks is any sign, a more outspoken side of the open source community is just getting started. Putting a bit of punctuation on the written requests, the call to action has now moved to in-person events.
At last week’s KubeCon + CloudNativeCon, the head of the Linux Foundation Europe, Gabriel Columbro, utilized his opportunity as a keynote speaker and expressed deep concern as part of his keynote, urging the community to "fix flaws in the EU's planned Cyber Resiliency Act." The event, with 10,000 attendees, is widely praised for showcasing the growth and impact of open source. This makes it another promising platform for motivating and directly communicating with the open source community on critical topics like the CRA. One can only assume there is now even greater awareness and increased power to drive change.