The final compromise text of the EU Cyber Resilience Act is now officially available, and various open source voices are currently opining on it. This is a complex act and other parts of the open source world (like the Eclipse Foundation and NLNet Labs) have been hard at work to advocate with the EU and member states to get a CRA that is good for open source. I’ve also been highly critical.

UPDATE: NLNet Labs has also weighed in on the final text, and what they learned over at the open source FOSDEM conference, where the European Commission also showed up to present on the CRA and what it means for open source. A very useful read.

Regulation is never fun, especially when it applies to you. And governments do not have a good track record where it comes to regulating computers. Given this, many in the open source community are worried about the upcoming EU Cyber Resilience Act.

I wrote about the various problems of the act here and here. I also discussed the open source ecosystem and the CRA. Finally, I described the binding nature of the words in the CRA on the position of open source.

Photo by Christian Lue on Unsplash

For clarity, I’m not paid by the EU (at least not for this work), but I do feel the need to defend the actual contents of the CRA against some of the unfounded and misguided pieces people are writing now.

The challenge

The state of computing security is dire, and governments around the world have rightly decided things can’t go on like this.

But the question is always, what do you regulate, and how? If we compare things to food safety, governments do not regulate how you cook at home. They do regulate your ingredients however.

Once you start providing food for larger groups of people, even free of charge, even for charity, you have to adhere to professional standards. This is no fun, but for your health it doesn’t matter if your food poisoning came from a charity event or from a commercial restaurant.

The CRA comes with lots of rules on how software should be developed, tested, audited and supported. If all these rules applied to open source, the consequences would be terrible. I’m not planning to hire a compliance department to get my new open source image sharing software out there!

Generic regulatory anger versus does this apply to me

We tend to be worried about two things: regulation in general, and how it would apply to us. A generic feeling that governments should stay out of software, versus the chances they’ll come for OUR software. These are two separate concerns.

In this post I’m going to focus entirely on the second part. Some organizations are so unhappy with the mere existence of regulation that they can no longer think clearly about if or how it would apply to them.

So let’s see what the actual text says.

Note: I’ve elided some repetitive phrases from the CRA quotations for legibility, do check the original text to be sure.

The scope

The CRA regulates commercial activity: “(10) This Regulation applies to economic operators only in relation to products with digital elements made available on the market, hence supplied for distribution or use on the Union market in the course of a commercial activity.”

This is an encouraging start for open source. If anyone wants the CRA to regulate open source authors or companies, they first have to establish that what you are doing is a “commercial activity”. Now, earlier incarnations of the CRA did not provide great guidance on what a commercial activity is. There were justified worries that if someone tried hard enough, they could try to claim that open source was also a “commercial activity”. I described that situation earlier.

In the final CRA compromise, a lot of clarification has been added. Let’s start with the big ones:

(10c) .. the provision of free and open-source software products that are not monetised by their manufacturers is not considered a commercial activity.
(10c) This Regulation does not apply to natural or legal persons who contribute source code to free and open-source products that are not under their responsibility.

So if you are not “monetizing” your open source product, you can stop reading here, the CRA does not apply to you. And if you submit any PRs or code or patches to other people’s open source, you are also completely in the clear, no matter what they are up to.

As an example, Google maintains an image library called libwebp. It was recently involved in a worldwide rushed security update because of serious security problems. The CRA however does not apply to libwebp per se since Google is not in any way monetizing it. But do read on for why Google will be on the hook anyhow: it turns out commercial USERS of open source WILL be regulated.

But, what if someone supports you with money, hardware or code:

(10c) the mere fact that an open-source software product receives financial support by manufacturers or that manufacturers contribute to the development of such a product should not in itself determine that the activity is of commercial nature.
(10) Accepting donations without the intention of making a profit should not be considered to be a commercial activity.

But what if you make regular software releases that people rely on:

(10c) In addition, the mere presence of regular releases in itself does not lead to the conclusion that a product is supplied in the course of a commercial activity

But what if you are an open source non-profit that receives money (for development)?

(10c).. for the purpose of this Regulation, the development of products qualifying as free and open-source software by not-for-profit organisations should not be considered a commercial activity as long as the organisation is set up in a way that ensures that all earnings after cost are used to achieve not-for-profit objectives.

But what if you are an open source non-profit foundation and someone pays you for actual technical support for your open source product?

(10) The supply in the course of 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 when this does not serve only the recuperation of actual costs.

But what if you forked a product from a very commercial VC-backed company, so the product has a commercial history:

(10c) The mere circumstances under which the product has been developed, or how the development has been financed should therefore not be taken into account when determining the commercial or non-commercial nature of that activity.

But what if there are very commercial users of your open source that are making money with your thing?

(10c) Furthermore, the supply of products qualifying as free and open-source software components intended for integration by other manufacturers into their own products should only be considered as making available on the market if the component is monetised by its original manufacturer.

But what if you are a Linux distribution (like Debian) hosting tons of other people’s open source:

(10e) The sole act of hosting products on open repositories, including through package managers or on collaboration platforms, does not in itself constitute making available on the market of a product with digital elements.

Given all this, almost all actual open source projects should be in the clear. There is however pain for those doing ‘fauxpen source’ projects, or those that are doing regular commercial sales of things that come with source.

What about open source users?

The CRA recognizes that software, open or closed, consists of components and libraries, and it has some fine words on who is responsible for those: the people making available software on the market as part of a commercial activity.

But the buck does indeed stop there - if someone uses the open source you author, you are in no way on the hook for their commercial use of it. People that integrate your stuff should perform their own due diligence:

(18a) When integrating components sourced from third parties in products during the design and development phase, in order to ensure that the products are designed, developed and produced in accordance with the essential requirements provided for in Annex I to this Regulation, manufacturers should exercise due diligence with regard to those components, including free and open-source software components that have not been made available on the market.

Interestingly, as part of this due diligence, integrators (and governments!) could initiate or sponsor ‘attestations’ of the security level of open source components. This would be a great boost for open source security:

(10f) The security attestation programmes should be conceived in such a way that not only legal or natural persons developing or contributing to the development of a product qualifying as free and open-source software can initiate or finance an attestation but also third-parties, such as manufacturers that integrate such products into their own products, users, or European and national public administrations.

Open source projects that get email with questions from commercial users about their “CRA status” should take the opportunity to remind integrators of their responsibilities.

Also interesting is that under article 10(4a), integrators are obliged to share any vulnerabilities they have found in a component with the (open source) manufacturer, including any patches they might have developed:

10(4a) Manufacturers shall, upon identifying a vulnerability in a component, including in an open source-component, which is integrated in the product with digital elements, report the vulnerability to the person or entity manufacturing or maintaining the component. (…) Where manufacturers have developed a software or hardware modification to address the vulnerability in that component, they shall share the relevant code or documentation with the person or entity manufacturing or maintaining the component

I mentioned Google’s libwebp earlier, and how Google is not on the hook directly for that library since they don’t monetize it. However, Google Chrome relies on libwebp, which means Google should perform due diligence on it, because Chrome is most certainly monetized.

In this way, it is fair to say that the EU CRA does not apply directly to most open source. But it does apply to all commercial open source users. And in this boomerang way, most open source software will receive CRA scrutiny, where the costs will be born by the users, and not the developers. This seems to me a good thing.

Things that are commercial

The CRA is very clear that it is not all about money. For example, if you try to make users “pay with their data” as a condition of using your product, that is commercial. Or, if you tie your open source product to paid services:

(10) an intention to monetise, for instance by providing a software platform through which the manufacturer monetises other services, by requiring as a condition for use the processing of personal data for reasons other than exclusively for improving the security, compatibility or interoperability of the software, or by accepting donations exceeding the costs associated with the design, development and provision of a product with digital elements.

If you run open source for profit that is not intended to achieve not-for-profit objectives (see recital 10c), that really is commercial.

In general, the CRA is very lenient about actual open source, even when sponsored or when authored by very commercial organizations, even when accepting money to cover support costs. And even if your non-profit makes money from the open source, but spends it on non-profit objectives, that is fine.

But if you try to offer your open source as part of some kind of ultimately commercial deal, the CRA will definitely extend to you.

UPDATE: A number of readers have asked what the CRA means for individuals that maintain their own open source project and make serious money from donations or support contracts. I’d love to be able to say, but I’m just not qualified. The CRA notes you can accept donations if you don’t make a profit, and that you can sell support to recoup costs. But what does that mean for an individual? If you want some margin of safety, things are easier if the software is owned by a non-profit, and the non-profit pays you a salary. But even then I’m not entirely sure. See below on how being open source does not itself give you a blanket opt-out from this and other regulation. I’ll try to find out meanwhile how being a full time open source individual entrepreneur might work.

The open-source software steward

There is a specific part of the CRA that applies to “Open-source software stewards”, which appear to be professional entities:

(18a) ‘open-source software steward’ means any legal person, other than a manufacturer, which has the purpose or objective to systematically provide support on a sustained basis for the development of specific products with digital elements qualifying as free and open-source software that are intended for commercial activities, and ensures the viability of those products;

There is also a recital:

(10d) Taking into account the cybersecurity importance of many free and open-source software products with digital elements that are published but, within the meaning of this Regulation, not made available on the market, legal persons which provide support on a sustained basis for the development of such products with digital elements qualifying as free and open-source software, which are intended for commercial activities, and play a main role in ensuring the viability of those products (‘open-source software stewards’) should be subject to a light-touch and tailor-made regulatory regime.

And it goes on:

This includes certain foundations as well as entities that develop and publish free and open-source software in a business context, such as not-for-profit entities developing free and open-source software in a business context. This regulatory regime should take account of their specific nature and compatibility with the type of obligations imposed. It should only cover free and open-source software products with digital elements that are ultimately intended for commercial activities, such as for integration into commercial services or into monetised products with digital elements.

Now, it is not clear to me who exactly would be considered an open-source software steward. The Python Foundation? The Linux Foundation? The SQLite Consortium? Eclipse? It would be great to know.

These stewards have certain obligations:

Open-source software stewards shall put in place and document in a verifiable manner a cybersecurity policy to foster the development of a secure product with digital elements as well as an effective handling of vulnerabilities by the developers of that product.

This should not be a problem.

It shall also foster the voluntary reporting of vulnerabilities as laid down in Article 11a by the developers of that product.

There has been a lot of noise on this reporting and how it might suck, but it is voluntary.

Next up:

Open-source software stewards shall cooperate with the market surveillance authorities, at their request, with a view to mitigating the cybersecurity risks posed by a product with digital elements qualifying as free and open-source software.

In other words, the government could show up and make you cooperate in mitigating a cybersecurity risk in your software. I realize this might rub people the wrong way. Might they not come with bogus reports of cybersecurity risks? They very much might. It is for this reason we should engage constructively with the EU (see the end of this document).

Furthermore, the open-source software steward:

(11.1) shall notify any actively exploited vulnerability contained in the product with digital elements that it becomes aware of simultaneously to the CSIRT designated as coordinator, in accordance with paragraph 7 of this Article, and to ENISA. The manufacturer shall notify that actively exploited vulnerability via the single reporting platform established in Article 11b.

This then goes on to clarify that the notification needs to include the “general nature of the exploit and of the respective vulnerability as well as any corrective or mitigating measures taken, and corrective or mitigating measures that users can take. The notification shall also indicate, where applicable, how sensitive the manufacturer deems the notified information to be”.

Note that this does not mean handing over the details of your zero days to the government.

Stewards also need to notify the CSIRT and ENISA about any severe incidents in their organization/network/infrastructure that could impact the security of their software (11.3).

Finally, stewards should inform impacted users about actively exploited vulnerabilities, or severe incidents that have an impact on the security of their products (11.8).

Rounding off, in recital 65 (Art. 53(10a)(b)), the CRA says that if open-source software stewards do not comply with these rules, there will be no monetary fines.

This light-touch regime might not be light enough for some people, but it appears this is aimed at professional organisations with staff and industry sponsorship, so I suspect they’ll be able to deal with this.

You don’t get a blanket opt-out because the source is out there

I realize the above will not satisfy everyone in the open source world. Some feel that being open source should come with a blanket opt-out from any form of regulation. We even put it in our licenses:

Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

But do note the last part of the last sentence - “to the extent permitted by law”. Computing is now important enough that regulation has come for us all, at least to some extent.

Some specific bits on the Debian statement

The Debian statement appears to be based on an earlier version of the CRA.

It for example says “Knowing whether software is commercial or not isn’t feasible, neither in Debian nor in most free software projects”. Under the CRA there is no need to figure that out for Debian.

“Having to get legal advice before giving a gift to society will discourage many developers” - the final version of the CRA is clear that if you are giving a gift, the CRA does not apply to you anyhow. There is now a very clear statement on that (see above).

“Imposing requirements such as those proposed in the act makes it legally perilous for others to redistribute our work” - the CRA now has specific notes that such redistribution is not in scope.

I hope that the most awesome Debian project could take a good look at what the current version of the CRA says, and perhaps come up with a new statement.

What’s next

The EU Cyber Resilience Act still has a long way to go before it enters into force. The open source community can play a large role here by lending its expertise to make sure things work out as intended.

Specifically, the EU has tasked CEN/CENELEC to draft secure software development standards, and I could think of nothing better than the open source community to contribute to that process. Here is our invitation:

(6b) When preparing measures for the implementation of this Regulation, the Commission shall consult and take into account the views of relevant stakeholders, such as relevant Member States’ authorities, private sector, including micro, small and medium-sized enterprises, open-source software community, consumer associations, academia, and relevant Union agencies or bodies or expert groups established at Union level.

Throughout the CRA process, various EU institutes and member state governments have been very receptive of the views of the open source community, and I see no reason why this should not continue.

Furthermore, the CRA virtually creates a new process whereby industry can come together to sponsor security documentation, attestations, audits or even security work on open source products. The European Commission is empowered to create templates and regulations for such procedures, and input from the open source community would surely be helpful to turn that into a success.

If we play this right, open source could finally gain support from industry, because the CRA means people that integrate our work are now formally on the hook for it.