What Is the Cyber Resilience Act and Why It’s Important for Open Source
The Cyber Resilience Act (CRA) is a proposal for a European law that aims to drive the safety and integrity of software of all kinds, and it may harm Open Source.
Join the DZone community and get the full member experience.Join For Free
The Cyber Resilience Act (CRA) is an interesting and important proposal for a European law that aims to drive the safety and integrity of software of all kinds by extending the “CE” self-attestation mark to software. And it may harm Open Source. The proposal includes a requirement for self-certification by suppliers of software to attest conformity with the requirements of the CRA, including security, privacy, and the absence of Critical Vulnerability Events (CVEs).
The Open Source Initiative has submitted the following information to the European Commission’s request for input on its proposed Cyber Resilience Act text.
We recognize that the European Commission has framed an exception in recital 10 attempting to ensure these provisions do not accidentally impact Open Source software. However, drawing on more than two decades of experience, we at the Open Source Initiative can clearly see that the current text will cause extensive problems for Open Source software. The problems arise from ambiguities in the wording and framing, which do not match the way Open Source communities actually function and their participants are motivated.
First, for those distributing software as a community function to confidently rely on the exclusion, this absolutely must be inserted as an article, and the “should” must be changed to “shall.”
Second, since the goal is—or should be—to avoid harming Open Source software, which the European Commission is working hard to support, this goal should be stated at the start of the paragraph as the rationale, replacing the introductory wording about avoiding harm to “research and innovation” to avoid over-narrowing the exception.
Thirdly, the reference to “non-commercial” as a qualifier should be substituted. The term “commercial” has always led to legal uncertainty for software and is a term that should not be applied in the context of open source as specific commercial uses of open source projects by some users are frequently disconnected from the motivations and potential compensation of the wider community of maintainers.
The software itself is thus independent of its later commercial application. The problem is not the lack of a taxonomy of “commercial”; it is the very act of making “commercial” the qualification rather than, for example, “deployment for trade.” Thus adding a taxonomy of commerciality is not a solution. OSI would be pleased to collaborate on better approaches to qualifying an exception.
To illustrate the concern our community feels, we wish to highlight an analysis by OSI affiliate Eclipse Foundation, based in Brussels. While they note that, with staff and financial resources, they are “in a better position than most” to deal with such requirements, they conclude that “we fear that the obligations set forth by the legislation will cripple the Eclipse Foundation and its community.”
The Open Source Initiative assumes the Act is not intended to negatively impact the communities that make Open Source software or burden the non-profit foundations that support them.
Therefore OSI recommends further work on the Open Source exception to the requirements within the body of the Act to exclude all activities prior to commercial deployment of the software and to clearly ensure that responsibility for CE marks does not rest with any actor who is not a direct commercial beneficiary of deployment. Leaving the text as it is could chill or even prevent the availability of globally-maintained open source software in Europe. We also support the more detailed analysis we have co-signed with Open Forum Europe.
Published at DZone with permission of Stefano Maffulli. See the original article here.
Opinions expressed by DZone contributors are their own.
Effortlessly Streamlining Test-Driven Development and CI Testing for Kafka Developers
Never Use Credentials in a CI/CD Pipeline Again
Seven Steps To Deploy Kedro Pipelines on Amazon EMR
Introduction To Git