Release 03
TL:DR
Take note of this proposed legislation and then — as far as is possible, given its draft status:
- confirm that your software development and distribution activities fall outside its scope
and/or:
- keep your project both legitimately open‑source and within the somewhat unclear non‑commercial exemption as currently articulated.
Or alternatively, depart from that exception space with understanding and intent — and be aware that your statutory obligations and liabilities will increase markedly as a result.
My assessment is that the Cyber Resilience Act (CRA) will not apply to any of the established energy system modeling framework projects, given those projects remain genuinely open‑source and refrain from any form of commercial activity — for instance, spin‑off ventures that provide subscription‑based technical support to third‑party users.
Conversely, closed‑source modeling projects that sell commercial software products will, very likely, fall under the CRA.
Commercial activity, in the context of the CRA, is defined broadly and need not involve monetary payments.
Introduction
At the time of writing, October 2023, the European Union is considering Europe‑wide legislation to improve the quality of software, particularly in relation to known and potential vulnerabilities. That legislation is the proposed Cyber Resilience Act (CRA).
Under current drafting, some forms of software distribution will not be included and some forms of open‑source software development will be explicitly exempt from the statutory requirements of the CRA.
Thus, open energy system modeling projects should be aware of how their development and distribution practices fit within the CRA and where the open‑source not‑for‑profit boundary might lie. Crossing those lines and falling under the provisions of the CRA will incur substantial overheads and additional liabilities. Fulfilling these mandatory compliance requirements may even render some projects nonviable (NLnet Labs et al 2023).
This posting is based on discussions within an open source legal community that I participate in. That community operates under the Chatham House Rule so that much of the material presented here remains necessarily unattributed.
The current version of the CRA is provisional and this posting should be read with that fact in mind. That said, software lawyers think that the final legislation will likely have tighter definitions and that the line delineating the not‑for‑profit exemption will be better articulated.
There are also substantial technical discussions regarding the intersection between section § 7 of the GNU GPL‑2.0 public license and the draft CRA requirements. I am not going to traverse that question because only one significant energy system framework (GenX) uses that particular license.
Similar legislative measures are being planned for the United Kingdom and are briefly touched on by Turunen (2023).
Those unfamiliar with the type of software under discussion here can review the Wikipedia article on open energy system models. Most software development occurs within academia — clearly a niche area in terms of open software development.
Regarding third‑party copyright and this posting, the CC‑BY‑4.0 site license for this forum does not apply to the quoted material provided below.
The author has no legal training. If you require legal advice, seek suitably skilled professional input.
Orientation
The proposed legislation addresses self‑evident problems with code quality, particularly regarding so‑called critical and highly‑critical software. Energy system frameworks, of course, class as non‑critical software.
As indicated, the CRA provides an exemption for open‑source software that is additionally non‑commercial in nature. The CRA also makes a distinction between components and products. These definitions and their application need to be navigated with some care.
The fact that your project resides entirely outside the European Union is unlikely to be material — unless your software never enters Europe. Geoblocking (see below) and other strategies are being considered in some circles, but I am going to assume the CRA may apply to your project and that you wish to observe European law.
Also to note at the outset that the draft CRA has attracted sustained criticism from major players from within the free software world (Aertsen 2022, Kolkman 2022, Milinkovich 2023). On the other hand, some open‑source commentators have been more measured, particularly around whether your typical open‑source project indeed supplies a final “product” and thus be covered by this work‑in‑progress legislation.
This posting does not cover what is needed to comply with the CRA — except to note that you may need to commission an external notifying body to audit your software development processes and then report those findings to the Commission on a regular basis.
In this analysis, there are two overarching questions to resolve. Does your open‑source software project:
- produce a software artifact that would fall under the CRA?
- class as not‑for‑profit and thereby be exempt from the CRA?
Issues of scope
The first overarching question involves examining different types of software artifact, whether they fall under the CRA, and if so, which parties along the supply chains (more generally webs) would be held responsible for CRA compliance. The CRA is aimed at “products with digital elements” and thus covers hardware with embedded systems as well as stand‑alone software.
The obligations under the CRA therefore target final products and the entities that manufacture and distribute them.
Some have argued that most open‑source projects offer only source code and that even building binaries is left to the recipient. The host operating system, in turn, furnishes the many dependencies not supplied. Continuing, the codebase delivered would more naturally class as a “component”. They say that the CRA also seems to contemplate this interpretation because the only mention of “open source” in the draft is for the reporting obligations of manufacturers such that “open source components” are included.
Some of the more salient definitions given in the CRA are repeated (article 3, emphasis added):
“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
“component” means software or hardware intended for integration into an electronic information system
“electronic information system” means any system, including electrical or electronic equipment, capable of processing, storing or transmitting digital data
“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
“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
The phrase “placed on the market” is defined more broadly than common usage would suggest and loops back to the notion of commercial activity as the informing concept (European Commission 2022a:19).
It remains unclear to me whether offering your energy system framework — say a python codebase and associated workflow tooling via a public code repository — constitutes distributing a component or a product. One can read the definitions above both ways. In which case, discretion would suggest that you opt for the product classification and thus fall under the CRA in this respect.
Issues regarding not‑for‑profit
Regarding the second overarching question concerning not‑for‑profit status, Car and De Luca (2023:5) note:
Last but not least, in order not to hamper innovation or research, free not‑for‑profit open source software is not covered by the proposal.
And then continue (page 8) (see also Kolkman 2022):
Internet Society — a non-governmental organisation (NGO) promoting internet development — pleads for clear exclusion of not-for-profit open source licence software from the scope of the CRA, because of the unclear definition of commercial activity in the proposal.
So I think two further questions naturally arise:
- how will the boundary for commercial activity be defined when the CRA is finalized?
- does your particular software project fall under these not‑for‑profit exemptions?
From the discussions I have seen (in addition to the quote above), the not‑for‑profit boundary currently provided needs to be written in clearer language. Indeed, the current draft discusses only “commercial activity” and the not‑for‑profit attribute often discussed follows by implication alone. Conversely, the CRA states that software supplied “free of charge” can still be developed via activities which the Commission would class as commercial.
Here is recital 10 replicated in full (a recital is part of the legal preamble intended to provide context and necessarily carries less legal weight than provisions written into the main body) (again emphasis added):
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.
Be aware that a revised version of recital 10 is in circulation for negotiation purposes (General Secretariat of the Council 2023). Quoting that forked passage in part (page 13, emphasis added):
Taking account of the above-mentioned elements determining the commercial nature of an activity, this Regulation should only apply to free and open-source software that is supplied in the course of a commercial activity.
That modification limits the scope of the CRA to software distribution in the course of commercial activity. While underscoring that that passage is not part of the current official draft.
My impression, at the time of writing, is that most open energy modeling framework projects would be exempt from the CRA on basis of recital 10 — in either framing.
Various downstream activities spun‑off by an energy modeling project could result in the entire project being covered by the CRA. So care and insight are needed when developing ancillary activities. For‑profit consultancy work would clearly remain outside the CRA, provided the client was not offered software. Conversely, an open‑source project that elects to provide paid support to third‑party users would probably invalidate any non‑commercial exemption.
To underscore that the European Commission intends the CRA to fully apply to all open‑source software in the first instance — and that exceptions like the one being discussed are designed to address special cases where the public interest might not otherwise be well served.
Sanctions
The CRA provides for fines of up to 2.5% of annual turnover or €15 million, whichever is higher. Such fines can apply to the manufacturers, importers, distributors, or other “economic operators” of any “product with digital elements” made available in the European single market (article 53).
In the context of open energy system modeling projects, the question of which entity or entities could be held responsible for compliance failures raises an avalanche of issues and questions. That matter is not considered in this posting.
Geoblocking
Be aware that some open‑source projects run from software hosting services located in the United States are seriously discussing the prospect of geoblocking the European Union (Turunen 2023, community discussions). Such an act would be driven primarily by a perceived need to manage their export liabilities in relation to the CRA — and not to prevent developers in Europe from gaining access to their code. Nonetheless, geoblocking may substantially disrupt your workflow, particularly if your workflow is automated.
Closure
The current draft of the Cyber Resilience Act remains provisional and has yet to enter into EU law.
While this posting split the discussion into two overarching questions — scope and commerciality — the reality is that the relevant provisions cross back and forth between these two framings within the proposed text.
Projects that are considering embarking on downstream commercial services should think carefully about the CRA. Remaining within the bounds of exempt activity provides clear advantages — and crossing that dividing line will result in regulatory compliance and additional liabilities. Moreover, having your project reside entirely outside the European Union, as some have suggested, may well not be sufficient to circumvent the requirements of the CRA.
Ditto, independent parties considering providing paid services on top of extant projects should evaluate their CRA obligations carefully too. Indeed, the software quality assurance and reporting requirements may well fall to them and not to the underlying project.
This posting is not intended to suggest that poor software engineering is acceptable in the absence of regulatory oversight. The author believes that most energy modeling framework projects would benefit from a greater emphasis on code quality and more formalized software quality assurance processes.
Finally, feel free to comment below. And particularly if you have new information or insights.
Draft legislation
European Parliament (14 September 2022). Proposal for a regulation of the European Parliament and of The Council on horizontal cybersecurity requirements for products with digital elements and amending Regulation (EU) 2019/1020 — COM(2022) 454 final — 2022/0272 (COD). Strasbourg, France: European Parliament.
European Parliament (15 September 2022). ANNEXES to the proposal for a regulation of the European Parliament and of The Council on horizontal cybersecurity requirements for products with digital elements and amending Regulation (EU) 2019/1020 — COM(2022) 454. Strasbourg, France: European Parliament.
General Secretariat of the Council (13 July 2023). Subject: Proposal for a Regulation of the European Parliament and of the Council on horizontal cybersecurity requirements for products with digital elements and amending Regulation (EU) 2019/102 — Mandate for negotiations with the European Parliament — Interinstitutional File: 2022/0272(COD. Brussels, Belgium: Council of the European Union. Contains a modified version of recital 10.
References
Aertsen, Maarten (14 November 2022). Open-source software vs. the proposed Cyber Resilience Act. The NLnet Labs Blog.
Car, Polona and Stefano De Luca (May 2023). EU cyber-resilience act — Briefing EU Legislation in Progress — PE 739.259. Strasbourg, France: European Parliamentary Research Service (EPRS), European Parliament.
European Commission (29 June 2022a). “The ‘Blue Guide’ on the implementation of EU product rules 2022 — 2022/C 247/01 — Commission Notice”. Official Journal of the European Union. 65: 1–152. ISSN 1725-2423.
European Commission (15 September 2022b). Cyber Resilience Act: shaping Europe’s digital future. European Commission. Brussels, Belgium. Last update 20 June 2023.
Kolkman, Olaf (24 October 2022). The EU’s proposed Cyber Resilience Act will damage the open source ecosystem. Internet Society. Reston, Virginia, USA.
Milinkovich, Mike (23 February 2023). Cyber Resilience Act: good intentions and unintended consequences. Life at Eclipse.
NLnet Labs et al (23 January 2023). The Cyber Resilience Act: unintended harms to security and stability of open source internet infrastructure software. NLnet Labs and others. European Commission feedback reference F3376542. URL points to landing page.
Turunen, Ilkka (12 January 2023). Europe’s cyber security strategy must be clear about open source. ComputerWeekly.com. United Kingdom.
▢
