The ultimate list of reactions to the Cyber Resilience Act

The European Commission’s proposed Cyber Resilience Act (CRA) as drafted may harm Open Source, and perhaps all other non-industrial software.

There were 131 responses to the proposed text that the Commission has sent to the Parliament, including one from the Open Source Initiative. Of those, 18 responses – representing a significant proportion of Europe’s software industry – shared OSI’s concerns to some degree. Here are some sample points from the responses:

Open Source Foundations

Open Source Initiative (OSI)

• “We recognise 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.”
• “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 availability of globally-maintained open source software in Europe.”

Open Forum Europe (OFE — with OSI, Eclipse, APELL, CNLL, OSBA) 

• “Replacing the current general freedom to publish software with a new system that imposes a set of CRA requirements constitutes a significant disruption to open innovation in Europe. The current formulation of the CRA interferes with almost every software development model other than the case of a single company developing the entire code-base behind closed doors and making periodical releases. This model was common until the late 1990s, but much less so now.”
• “If a security vulnerability is discovered in software used in Europe, the liability and technical requirements of the CRA, in its current form, would place a hurdle in front of anyone in Europe working on a fix.”

The Document Foundation (LibreOffice)

• “On the other hand, the CRA ignores the security risks associated with files created by the software covered by the act itself, which can have even more devastating consequences (according to security expert Kaspersky Labs, in 2018, 70% of all malware worldwide was carried by documents created by the most widely used office suite).”
• “For the purposes of the Cyber Resilience Act, there is a real risk that software based on LibreOffice technology will be considered to be made in the course of a commercial activity, and thus subject to the legislation”

Vrijschrift.org

• “when defining a notion of commercial activity regarding open source software, the CRA provides examples of the creation and/or use of open source software that are typically understood as non-commercial but would fall under this definition of commercial activity”
• “This creates legal uncertainty for developers and is bound to result in a chilling effect on the very ecosystems that have often acted more responsibly, by and large, in dealing with security defects in their software than proprietary actors.”

NLNet Labs (with CZ.NIC, ISC, NetDEF)

• “While we applaud the efforts of the European Commission to enhance the cyber security of products with digital components, we fear that the CRA could create a series of unintended adverse consequences to the security and stability of Open Source Internet Infrastructure Software – and by extension to the Internet.”
• “We feel that the regulation as applied would impose disproportionate regulatory compliance burdens on developers and curators of “critical products” that will strain their existing capacity while failing to enhance the security or stability of this type of software”

Trade Associations

Developers Alliance

• “It is important to preserve the incentives for software developers to contribute to open-source projects and to continue to utilize such resources and tools in their work, without the pressure of legal liability.”

RIPE NCC

• “RIPE community members pointed out that the current open-source ecosystem is a complex one in which there is often no clear distinction between commercial and non-commercial products, as product development is an ongoing process that builds upon itself with designs, technologies, standards and code being shared in myriad ways for myriad purposes. This rich interplay and open access are the very features of the open-source ecosystem that allow for innovation — and which strengthen resilience and security.”
• “It is our understanding that the CRA intends to cover any software and hardware product, and its remote data processing solutions, that is connected to the Internet (either logically or physically) and which is placed on the market as an independent product to be distributed for end use. In other words, it is our understanding that software that is connected to the Internet but is not placed on the market as a product with the aim to be distributed to end users — such as, for example, a customer portal — would not fall under the scope of the CRA. However, the proposal is not explicit about this point, and further clarity is therefore needed.”

ITI – Information Technology Industry Council

• “However, it is worth noting that there are many open-source projects that create products that could fall into most categories of critical software products, and open-source software is often incorporated into other products that are sold on the market. This could create uncertainty for open-source developers regarding their obligations related to conformity assessment. Legislators should seek to preserve incentives to develop and maintain open-source software by preventing any possibility that it could be classified as “commercial activity.””

DIGITALEUROPE

• “However, the recital’s broad interpretation of ‘commercial activity’ does not accurately reflect operational best practices, governance and licensing in an OSS context.”

Japan Business Council in Europe (JBCE)

• “There could be a significant imbalance between open-source ventures compared to commercial software counterparts, with open-source ventures developing very widely implemented software components, but often receiving a fraction of the commercial benefit that commercial software ventures would (when also including the same component). Considering that open-source also drives innovation and rapid advancement in almost all areas of critical products, it is necessary to include additional ringfencing around the specific CRA requirements for open-source products, including those used in “commercial activities” to avoid constraining or burdening essential open source activities and ultimately stifling open-source innovation and contribution within the European Union.”

Bitkom

• “Recital 10 excludes open source software that is not used in the course of a commercial activity but does not define the term or give details on how to assess the intended use and/or the determination of the intended use and/or a default category if no determination was done in advance.”

Eco

• “The definitions, while generally sound, are a matter of concern for the developers of open-source software, who see a lack of distinction between open-source software distributed on a not-for-profit basis and commercial software. eco recommends exploring the further implications and harmful effects for the development of open-source software for deployment in the market on a not-for-profit basis.”
• “The definition of “unfinished software” in Article 4(3) is not in line with the current status of product and software development. It specifically contradicts the premises and conditions for the deployment and use of open-source software. eco recommends further exploring the topic so as to avoid unintended detrimental effects on the European software industry.”

Corporations

OpenXchange

• “the Act would discriminate against certain types of software and of software makers for which the main motivations are not economic, but that still generate some form of financial return to support the development of their code, and thus cannot be considered “non-commercial”. For example, this includes software developed by universities and public research centres, including some basic applications that make the entire Internet work; software developed by individual developers, mostly in their spare time; software that is meant to increase privacy and freedom of expression, such as encrypted communication apps, decentralized social media and anonymous browsers; and much more. To this regard, the weak exception for non-commercial open-source software is entirely insufficient to solve the issue.”

GitHub

• “However, the scope of “commercial activity” is unclear and risks bringing into scope activities that are not placing a product on the market per se.”
• “[paid] services and general financial support do not change the fact that these open source projects and developers are not placing software onto the market as a paid product.”
• “Annex I requires delivery “without any known exploitable vulnerabilities” but this risks an unobtainable objective, as manufacturers regularly learn of new vulnerabilities and make risk-based assessments on the need to prioritize fixes for timely delivery of product updates. … Similarly, the vulnerability handling requirements outlined in Annex I raise concerns. In particular, the requirement to “remediate vulnerabilities without delay” may undermine established practices of coordinated vulnerability disclosure and risk-based assessments from manufacturers on when to push and how to coordinate security updates”

Huawei

• “As currently drafted – perhaps unintentionally – the text targets  open-source not for profit foundations rather than targeting the organizations that leverage open source for commercial activity.”

Microsoft

• “There is ambiguity resulting from the intersection of OSS with “commercial activity,” both in the context of infrastructure and services provided to open source projects and with regard to activities that open source projects may pursue while building OSS.”
• “the infrastructure and services provided to open source projects should be out of scope, regardless of commercial status.”
• “Commercial services enabling the effective use of OSS, such as technical support and consulting services, should also be out of scope and not bring OSS offerings into scope.”

Sonatype

• “Specifically, various organizations, like Sonatype, maintain and make available FOSS free of charge as a benefit to the FOSS community (including through maintaining publicly accessible projects or repositories), while also charging for optional, ancillary services. The commercial activity qualifier as currently drafted could be read to eliminate the FOSS exemption for these organizations, which would leave them with an unenviable choice: either incur substantial costs and undertake significant effort to comply with the substance of the Regulation in maintaining free FOSS repositories, or shut down the public repositories (either altogether or just to entities originating from the EU).”