I believe the European Commission’s Cyber Resilience Act proposal needs an important amendment to avoid damage to the open source software ecosystem. The regulation should be modified to make it clear that software produced under an open source license and distributed on not-for-profit basis is out of scope for the regulation, in line with previously stated objectives of the European Commission.
The Cyber Resilience Act
On 15 September 2022 the European Commission released a proposal for a regulation on horizontal cybersecurity requirements for products with digital elements, in short, the Cyber Resilience Act.
The act establishes a set of expectations for any product, hardware, or software, with digital elements. These expectations include the ability to perform updates, follow diligent software development practices, and the assessment of cybersecurity risks, to name a few. Any manufacturer following best practices in cybersecurity and software and hardware lifecycle development should be able to meet these requirements. The compliance with these expectations depends on the type of product but ranges from self-assessed to certified by a third party, or implied through the implementation of EU standards.
There are serious concerns with the Cyber Resilience Act proposal in terms of effectiveness, before I get to concerns on the open source ecosystem. With experience from other domains of software assurance, certification will not eradicate bugs even when a manufacturer is fully compliant. Even if a product bears the CE marking, it can contain bugs that can have devastating global impact. Rather than to further speculate about the general effectiveness of the regulation, I have other concerns that implicate the global and open nature of the Internet: the need for certification, and the threat of fines, may stifle open source development and hence the development of the Internet, which depends deeply on open source software and systems.
Open Source and the Internet
The history and evolution of the Internet and open source software are deeply intertwined. The TCP/IP stack became widely available because of its implementation under the Berkeley Software Distribution license, a “generous” form of copyright license that allows downstream users to modify and further distribute the software. Many standards developed in open standards organizations such as the IETF and W3C rely on the availability of open source software[1]. Many critical elements of the Internet operate using free and open source software. Open source software and the development model that is uses—where contributions can be made from volunteers to a common software code base—has spawned and enabled multiple communities: from operating system hackers to security researchers and from those who develop routing software to those who write firmware for ESP32 microcontrollers (a hobby of the author’s). Without that technical community there wouldn’t be an Internet today and the world would miss out on any number of exciting and innovative services that we enjoy today.
A possible unintended outcome of this regulation could be that developers of open source software outside the internal market will geographically restrict access to open source code, simply because they do not want to be liable for not complying to EU regulation; they are often hobbyists and not experts in compliance regulations. It is not unthinkable that if this regulation comes into effect it results in open source licenses that prevent distribution in Europe, just to prevent the legal risks of falling afoul of regulatory enforcement. For developers inside the market, the compliance costs may be simply too high, a disincentive to share their ideas and innovations. Whether the liability disclaimers that currently exist in open source licenses sufficiently protect developers of open source software conflicts with the regulation is a matter for legal specialists (although it seems doubtful because commercial software distributors could easily use the same kinds of limitations-on-liability clauses to avoid the Cyber Resilience Act’s requirements).
Issues with the Regulatory Text
I read the proposed regulation with a few scenarios in my mind:
- the publication of DNS nameserver or BGP route origin validation software by a not-for-profit;
- the distribution of microcontroller firmware by a hobbyist on GitHub;
- the ability to download and use open source security vulnerability analysis tools; and
- the distribution of the FreeBSD operating system.
These are scenarios that I contributed to or relied on throughout my professional career. Use cases that helped me and others to run start-ups, innovate, learn, and contribute to society through the development technology. All these scenarios arguably critical products in the context of Annex 3, in some cases even class II. Meaning that those products are subject to an external assessment.
Not-for-profits and the Publication of Open Source
Below I analyze the regulation in the context of open source software. Quotes come from the 15 September 2022 version of the draft regulation.
First, recital 10 makes a promise about the regulation.
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.
This is good news. However, only outside the course of a commercial activity. So, if one engages in any sort of commercial activity there will be an impact. Recital 10 continues:
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 authorize other services, or by the use of personal data for reasons other than exclusively for improving the security, compatibility or interoperability of the software.
At least two not-for-profit organizations that distribute open source DNS software also offer support[2]. Many open source software products are provided by organizations that provide consultancy using the product. This is particularly the case for open source security tools that are ‘sponsored’ by security consultancy firms[3]. Is sponsorship to a foundation seen as a commercial activity? How about an individual developer receiving a small fee for adding a feature to an open source product – is that considered commercial activity? It is unclear.
Recital 10 allows for a broad interpretation, and this creates legal uncertainty for these organizations which may result in the withdrawal from these open source products from the market. But a recital doesn’t carry the same weight as the articles of a regulation and would hope that the articles would provide clarity. Unfortunately, they do not, as demonstrated below.
Article 1 lays down essential requirements for the products and ‘obligations for economic operators’ while Article 2 scopes the regulation to products and does not talk about natural or legal persons involved in commercial activity. I’ve collected the relevant definitions from article 3 here:
(17) ‘economic operator’ means the manufacturer, the authorised representative, the importer, the distributor, or any other natural or legal person who is subject to obligations laid down by this Regulation;
(18) ‘manufacturer’ means any natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under his or her name or trademark, whether for payment or free of charge;
(21) ‘distributor’ means any natural or legal person in the supply chain, other than the manufacturer or the importer, that makes a product with digital elements available on the Union market without affecting its properties;
(22) ‘placing on the market’ means the first making available of a product with digital elements on the Union market;
(23) ‘making available on the market’ means any supply of a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge;
Commercial activity is not further defined, whilst the definition of ‘economic operator’ is defined by “those subject to this regulation” – ironically software developers would call such circular definitions a bug with potential security implications. A quick scan of other EU regulatory texts does not provide a clear example of commercial activity.
Recommendation 1: The articles of the regulation should be amended to declare software produced under open source licenses clearly out of scope. That would resolve the ambiguity stemming from the recitals.
Distribution Platforms
Distribution platforms such as GitLab, GitHub, Bitbucket, and Sourceforge all make open source software available to the global and thus the EU internal market. They are the distributor in the context of the regulation. They are bound to article 14 of the regulation. Article 14.2 reads:
2. Before making a product with digital elements available on the market, distributors shall verify that:
1. (a) the product with digital elements bears the CE marking;
2. (b) the manufacturer and the importer have complied with the obligations set out respectively in Articles 10(10), 10(11) and 13(4).
This means that, if an individual publishes open source code on such platform, the platform has to validate whether the manufacturer complied with the regulation. They will have to assess whether the manufacturer engages in commercial activity and whether the product they place in the repository (marked as release) is subject to Annex 3 of the regulation. (As somebody who developed and made available some firmware for microcontrollers I am wondering if I manufactured a Annex II Class I.20 component?). This is troubling as these software distribution platforms do not have expertise in assessing compliance, and we wouldn’t want such a powerful free service to be so encumbered.
What if the code is distributed through a commercial cloud platform like Box or DropBox? Will that platform be seen as the distributor? Would they need to constantly examine what people are uploading and then make an assessment for things they detect as being “software”?
Recommendation 2: The role of intermediaries in distributing software should be clarified. In particular, platforms that distribute open source software should be excluded from the regulation. Concretely: amend Article 2 to declare software produced under open source license and distributed on not-for-profit basis out of scope for the certification requirements in the regulation.
I agree with the commission that products and services which are sold and use open source software should be subject to the regulation. They either implement processes to test and validate the used libraries, or support open source developers to gain certification themselves. That way the regulation may give rise to voluntary certification of the most used, and highest quality open source software. A good thing.
Incapability: Limited Availability of Software for Testing Purposes
Open source software is by definition openly shared and freely accessible, usable, modifiable and redistributable. This is not limited to released software versions or their binary equivalents, but also to alpha, beta or other unreleased versions. This is completely incompatible with the carve-out for ‘unfinished software’, as described in Article 4(3):
Article 4
3. Member States shall not prevent the making available of unfinished software which does not comply with this Regulation provided that the software is only made available for a limited period required for testing purposes and that a visible sign clearly indicates that it does not comply with this Regulation and will not be available on the market for purposes other than testing.
Recommendation 3: To bring the articles of the regulation in-line with the stated intention in the recitals this article could easily be modified with a small amendment: “provided that the software is open source or is only made available for a limited period required for testing purposes […]”.
Relation to Other EU Documents and Statements
I am surprised that the draft regulation leaves open source subject to these uncertainties because the European Commission is a strong supporter of open source, and has various initiatives to increase its security.
For instance, the open source Strategy 2020-2023 acknowledges the importance of open source software for the EU’s economy. It rightfully observes that “[B]eing free to inspect and improve, open source offers more options for increasing security. It allows for independent audits and code inspections, so the time and effort spent can be balanced according to need. This improves security, not just for us, but for everyone.”. Besides it states that “[T]he Commission is an enthusiastic user of and contributor to open source. This is reflected in its digital strategy, which encourages the IT community to tap into the growing potential of open source, join forces with major commercial players and communities, and mobilize co-creation capacity to support directorates-general in pioneering new solutions.”
In addition, the commission takes stimulating action to increase open source security in the form of bug bounties. They offer rewards of up to EUR 5000 for finding security vulnerabilities in LibreOffice, LEOS, Mastodon, Odoo, CryptPad, and other open source solutions used by public services across the European Union. All of this we can get behind as carrots that stimulate a culture of review and security.
Conclusion
The Cyber Resilience Act will most certainly change the security landscape but will also impact the openness of the Internet by virtue of its impact on open source software development. Without a clearer carve-out of open source software in the articles of the regulation there will be unintended disruptions that will negatively impact the development and use of open source software in the internal market and will damage the ability to digitally connect, educate, and develop society through the Internet.
I finally recommend that members in the global technical community that care about open source software development closely track the developments around this regulation, as its impact will be global, just like the General Data Protection Regulation, the GDPR.
Acknowledgements
I would like to thank Andrei Robachevsky, David Frautchy, Joseph Lorenzo Hall and Maarten Aertsen for feedback and discussion.
[1] RFC 5218 “What Makes for a Successful Protocol?” identifies open code availability as an initial success factor for protocol deployment.
[2] These are ISC for BIND, and NLnetLabs, through their subsidiary OpenNetLabs for NSD and Unbound.
[3] For instance, the metasploid framework is hosted by Rapid7