The EU Cyber Resilience Act (CRA) and Free and Open-Source Software
Originally published on ifross.org on 08.02.2023
by Florian Idelberger
In the fall of last year, the EU Commission proposed a new regulation to improve cybersecurity in the EU. Specifically, it focuses on minimum requirements for “products with digital elements”. The current proposal would likely cause irreparable harm to free and open-source software, potentially isolating the EU software market from global open-source projects.
In its explanatory materials, one of the main reasons for the regulation is an estimated global cost of cybercrime of 5.5 trillion €. It traces this to a low level of security and insufficient information for consumers and businesses buying the products. It aims to create incentives and rules for manufacturers to take security more seriously throughout a product’s lifecycle and give buyers more information when choosing products. Recently, the OSI (Open Source Initiative) published their objections to some parts of the proposed regulation and their potential impact on free and open-source software, prompting us to chime in.
The CRA proposes additional reporting and compliance requirements for products with digital elements. Primarily these are fulfilled by extending the CE mark for software and self-certifying that the product is free of published security exploits such as those published in CVEs (Critical Vulnerability Events). The reasoning and proposal are laudable, but two issues stand out. First, given the reluctant enforcement of GDPR and other recent or upcoming legislation that could also bind significant enforcement capabilities such as the DSA (Digital Services Act), it would remain to be seen how effectively the CRA would be enforced. That is even when disregarding potential problems with self-certification and fitting a highly complex security evaluation into each product in a way that users can effectively evaluate.
The main risk for free and open-source software is a different one: the typical open-source project would be unable to fulfil the reporting and certification requirements under the CRA. Hence it could certainly be a death knell for many, if not most, projects on the EU market. Hopefully, most projects won’t fall under this regulation in its final version. While pure SaaS services fall under the NIS2 directive, if it is tied to a product that needs that service, OSS could currently fall under the proposed regulation (CRA): For open-source software, the proposed regulation attempts to define an exception in recital 10:
(10) 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. This is in particular the case for
software, including its source code and modified versions, that is openly shared
and freely accessible, usable, modifiable and redistributable. In the context of
software, a commercial activity might be characterized not only by charging a
price for a product, but also by charging a price for technical support
services, by providing a software platform through which the manufacturer
monetises other services, or by the use of personal data for reasons other than
exclusively for improving the security, compatibility or interoperability of the
software. (p. 16)
And while the attempt to address the issue for OSS is laudable, the current draft is problematic. Centrally, free and open-source software is defined as the opposite of commercial activity, which is not an accurate representation of reality. Further, the recital explicitly mentions that support services or other adjacent services would bring a product under the umbrella of the CRA. It is not certain which OSS projects this would apply to because some would likely fall under the SaaS exception. Also, how this provision would be enforced is up in the air. But it is still a big risk for many projects. It could create an incentive to provide no support for free and open-source software or move away from free and open-source software. How courts will define the term “commercial” is another issue. The experience with the creative commons non-commercial licensing clause suggests, for example, that potentially even advertisements on a developer’s blog could be enough to fall outside the non-commercial exception. Additionally, no one would know how the courts interpret a given case. Thus it would be best to at least make things as clear and certain as possible. Increasing certainty could even mean including a proper definition and exception for free and open-source software inside the legal text, not only in an explanatory recital. The current Article 2 defines the scope of the regulation, with no mention of an exception for free and open-source software, casting doubt on whether and how it would be applied:
Article 2
Scope
1. This Regulation applies to products with digital elements whose intended or
reasonably foreseeable use includes a direct or indirect logical or physical data
connection to a device or network.
The articles defining the scope and definitions of the proposed regulation thus currently do not significantly help to clarify the matter concerning open-source software. One could argue an open-source project that is not sold as a physical or digital product is not a “product” from an average person’s point of view. However, that is not possible based on the proposed regulation as it uses the term “products with digital elements”. This term is not a term of general usage, but the regulation then clarifies this term to mean products which are not software as a service but comprising either software and hardware or only hardware or only software as can be derived from Article 3. Seemingly, the definition does not clarify anything, as, on the face of it, it attempts to provide a catch-all.
Article 3
Definitions
For the purposes of this regulation, the following definitions apply:
(1) 'product with digital elements' means any software or hardware product and its
remote data processing solutions, including software or hardware components to be
placed on the market separately;
As a result, the proposed regulation would likely apply to many free and open-source projects until and unless an appropriate exemption is implemented. The Open Source Initiative recently published their objections on their blog [OSI response] after the public consultation by the EU Commission had ended. In a related article, the OSI also published a “best of” list of objections raised to the regulation as submitted by several industry and interest groups and companies directly. These groups echo similar notions to the above analysis, stating that the proposed regulation as it exists currently could cause irreparable harm to free and open source software, omits some areas of security concerns such as file formats, and just generally has many unknowns. At the end of the day, all free and open-source developers need to earn a living. If this is not through a commercial company that employs them, it can often be through selling support services, donations or any kind of adjacent service or product to the open-source project. It would be a real loss to the software industry and society if, suddenly, most free and open-source software would fall under the obligations of a product under the CRA.
The legislative process is still ongoing. Hopefully, we’ll still see a helpful amendment to the regulation’s text. Update: After related talks at FOSDEM in Brussels, additional information can also be found in this thread on the fediverse.