Tracking CRA implementation for Free and Open Source Software and its Stewards
Ever since the Cyber Resilience Act surfaced in fall 2022, we have kept an eye out for unintended effects on free and open source software. Active engagement from many independent voices in the community helped to address these in the outcome of the negotiations, since adopted by the European Parliament. With publication of the final text expected somewhere this fall (full application 36 months later), our focus is shifting towards the CRA's implementation, including by collaborating in a working group at the Eclipse Foundation.
by Maarten Aertsen
CRA implementation means different things to different groups. To the European Commission, it means providing definitions for the list of important/critical products, setting up ENISA's single reporting platform and issuing guidance to facilitate implementation of CRA requirements. To national governments, it means appointing a regulator, so it can stand up a CRA team to get ready to notify auditors and (later) start market surveillance and enforcement. Finally, to free and open source developers, it means figuring out if and how you are in scope, perhaps tangentially as an open source software steward. That's where we are at NLnet Labs.
We also provide technical expertise to policy-making bodies, including regulators and governments so they have the understanding they need when making public policy decisions related to the Internet infrastructure.
Most prominent to manufacturers, and applicable to most of the above, are the technical standards that will spell out the CRA's requirements in detail. Standards can also be relevant to stewards that have a lot of development participation by manufacturers. When manufacturers use steward-supported software as a component in their products, they will need to meet due diligence requirements as part of their responsibility to CE mark the resulting product. This incentivizes development to align with CRA requirements in such communities, even if the steward itself does not have a direct obligation to meet them.
FOSS compatible CRA standards?
The European Commission is requesting the European Standardisation Organisations (ESOs) to write the CRA standards (draft request). What is a new and promising development, is the Commission's explicit request to the ESOs to ensure effective participation of the open-source community and present evidence of how they have facilitated representation and participation of the open-source community. This will not be easy. It is not a natural fit with the way ESOs are structured along either national lines, in a pay-to-play model, or both.
Eclipse Foundation's "Open Regulatory Compliance" working group
The Eclipse Foundation is trailblazing a mechanism to interface with the ESOs and is attempting to charter an "Open Regulatory Compliance" working group "to collaborate on the establishment of common specifications for secure software development based on existing open-source best practices" (quote). While the charter extends beyond just the CRA, the initial focus is on specifications intended to feed into the CRA standards under development at the ESOs. This benefits manufacturers that integrate open-source software and stewards that see high manufacturer participation.
Figuring out the steward role together
Looking back on the CRA's policy process earlier this year, I wrote:
We cannot expect the FOSS community to organise as an industry organises (in trade organisations). If it turns out that FOSS appears nicely organised to a policy maker, then they are probably not talking to the whole community but just to the industry part of it.
But it is more than just manufacturers working on standards in Eclipse's new working group. On the contrary, there is also a group of actors interested in collaborating to better understand the open-source software steward role. It is this topic, distinct from the CRA standards work, that NLnet Labs will collaborate on.
To do so, we decided to become a so-called "Foundation member" of Eclipse's "Open Regulatory Compliance" working group (and an “Associate Member” of Eclipse itself to do so). We will focus our available energy on the new steward concept and in the spirit of open standards and open-source software, collaborate on the CRA's policy requirements for stewards in Article 24 (assuming they fit what we do in the final text of the CRA).
Eclipse is starting this effort by inviting manufacturers, foundations and individuals to collaborate. We feel it’s well worth a try.