“Does this regulation affect to me or my projects?”
That’s the first question developers should be asking when they hear about new laws, such as the new EU-wide product regulation for tech, the Cyber Resilience Act (CRA).
In this post I propose some basic questions you can ask yourself to figure out if the CRA is something you need to be concerned about. At a for-profit company the answer will be pretty quick: the CRA applies to almost every product that can connect to a network and is sold on the European common market.
It’s not quite as easy for open source developers though. The CRA offers special exceptions and limits that give a lot more freedom from regulation to free and open source software (FOSS). However, these exceptions mean that answering this question for open source developers is more complicated. The rest of this article will help you with finding that answer.
ABOUT THE CRA
The CRA is a product regulation and it covers almost every piece of software and digital goods imaginable: games, “internet of things” enabled home appliances, browsers, word processors, firewalls, and operating systems. The few exceptions to it are mostly products that are already highly regulated such as defense and transportation.
As of October 10th 2024, the CRA was finalized and formally adopted, and its first requirements come into effect in 21 months, the end of July 2026. The full set of requirements comes into effect on 31 October 2027, three years after the law was adopted.
This may seem like plenty of time to prepare, but given the long timeline of product development and the type of technical documentation mandated by the CRA, the time to start acting is far closer. If you are going to be impacted by it, you can and should begin to prepare for it.
Open source developers may have heard that, like many EU regulations, a goal of the CRA is to encourage and even exempt the development of free and open source software from regulation as much as possible. This is a goal of the CRA … but it will also end up regulating many FOSS projects.
To have a better idea of if your open source project is covered, a FOSS developer needs to ask themselves three things about their project to see if the CRA applies:
1. Is my project a product?
2. Is my project open source?
3. Is my project commercial?
Unfortunately, the answers to these questions aren’t completely straightforward. But, by looking at the Act, as I’ll do below, it becomes a lot easier to decide if you need to talk to a lawyer about how to comply with the CRA.
For an in depth look at when the CRA applies to FOSS projects, keep reading. If you’d rather watch a video, I gave a pair of lightning talks at last month’s RIPE 89 conference; a general overview and quick summary of the CRA and open source issues. If you want to dig into the Act on your own, this is a PDF of the CRA as adopted. It includes all annexes, which cover many of the more technical aspects of CRA compliance. However, technical standards for CRA compliance are still being written.
CAVEATS AND CAUTIONS
The CRA is a brand new regulation and it doesn’t come into effect for over a year. This means that there are a lot of things left to learn about it and how it will be enforced. Looking at text is a good way to learn what might happen, but both regulators and the courts will have chances to reinterpret the meaning of the CRA. There are some vague parts of the law that will be clarified only after the actual standards are completed and when the CRA comes into effect.
Enforcement of the CRA is a particularly open area, as it depends heavily on both self-regulation and existing product regulation frameworks for certification. The primary regulatory organization for enforcing the CRA will be the existing EU Market Surveillance Authorities (consumer safety regulators) who are often underfunded. Even ENISA, the EU-wide information security agency that will manage much of the CRA’s breach reporting requirements, has around one hundred employees. However, the CRA will regulate tens of thousands of “networked products with digital elements”. How these regulators and the available resources will meet this enormous task is unsure, as is what industries or even which manufacturers will be the primary focus of enforcement. Keep all this in mind when considering the article below and thinking about the CRA more broadly.
Now to answer those questions.
I. IS MY PROJECT A PRODUCT?
The Cyber Resilience Act begins and ends as a product regulation. Anyone’s first question should be “Is my project a product … or at least a product under the CRA?”
The CRA regulates every “product with digital elements” sold on the EU common market. This means products that have a networking component, including remote services that allow products to function (such as integrated online storage for a product) and commercialized in the EU. There are also a few exceptions for industries that already have high degrees of government oversight such as defense and most transportation, but the Cyber Resilience Act is a broad regulation that will cover thousands of products.
What it won’t cover is things that aren’t products, meaning that they either aren’t being sold or used to make money in other commercial ways, they are services, or they are something else entirely – even if people pay for them. Software as a service, cloud providers, internet service providers and similar projects are not a product, and are not covered by the CRA unless linked directly to a product. There are plenty of other, similar European regulations that they need to follow though. It’s also worth noting that while most products are sold, the CRA covers products that are commercial and make money from users in other ways, such as collecting private data and using it for anything other than improving the product itself. This commercial requirement is especially important to Free and Open Source Software, and is covered below in that context.
The CRA also takes special effort to note that on their own individual contributions to open source projects, even commercial ones, do not trigger any responsibility under the Act:
This Regulation does not apply to natural or legal persons who contribute with source code to products with digital elements qualifying as free and open-source software that are not under their responsibility. CRA §18.
II. IS MY PROJECT FREE AND OPEN SOURCE SOFTWARE?
To be precise, is it what the CRA defines as “free and open-source software”.
This is important because non-commercial FOSS products are generally exempt from CRA regulation, and even when they are regulated the standards are less strict. What the CRA means by “commercial” is the most complex of our three questions, and the next section covers it. However, before establishing that a project is non-commercial, we have to ask if it’s FOSS according to the CRA’s definition.
The CRA largely covers its application to FOSS in Sections 15 – 22, but defines it in Section 18 as follows:
Free and open-source software is understood as software the source code of which is openly shared and the licensing of which provides for all rights to make it freely accessible, usable, modifiable and redistributable. Free and open-source software is developed, maintained and distributed openly, including via online platforms.” CRA §18.
The first essential element here is that FOSS source code must be available publicly, and more specifically publicly available online. The second is that it must be available under an open license. Licensing, as always, is more complex. What exactly does the CRA intend when it says FOSS must be released under a license that provides “all rights” to make it freely accessible, usable, modifiable, and redistributable?
A strict reading of this wording implies that only software released into the public domain is FOSS, as even permissive open licenses such as the BSD or Apache license place minimal requirements on use – such as requiring acknowledgement of the original developers. Worse, Copyleft licenses such as the GPL place limits on the ability of users to make the code they cover into a proprietary product. The most common open source licenses withhold various rights from users.
The CRA offers a potential exception though – it requires that a FOSS license provides “all rights [to make the software] freely accessible, usable, modifiable and redistributable”. Restrictions limiting the right to make the software proprietary or forcing one to credit the original authors need not be considered limitations on how accessible, usable, modifiable and redistributable the product is. You can still modify something under a GPL license, you just also need to use the GPL when you distribute it. This is a distinction the regulators are very likely to make, because a decision that eliminates the majority of open source licenses from the CRA’s definition of FOSS would be absurd, confusing, and counterproductive to the regulation’s goals and the law usually finds a way to avoid looking absurd, especially at scale.
III. IS MY PROJECT COMMERCIAL?
Finally, the last and most complex of the CRA’s riddles. When is a FOSS project still considered a product under the CRA? Again, the answer looks simple at first:
[O]nly free and open-source software made available on the market, and therefore supplied for distribution or use in the course of a commercial activity, should fall within the scope of this Regulation. CRA §18.
A FOSS product that is “supplied for distribution or use in the course of commercial activity” is regulated by the CRA. What exactly does this mean though? The CRA has a number of examples of what is and isn’t commercial activity and buries a few guidelines in other sections.
Supply in the course of a commercial activity might be characterised not only by charging a price for a product with digital elements, but also by charging a price for technical support services where this does not serve only the recuperation of actual costs, by 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. CRA §15.
In this section there are five recitals that act as legally significant examples of what constitutes commercial activity under the CRA:
- “[C]harging a price for a product with digital elements”
Simple. Selling products is a commercial activity and products that are sold are covered by the CRA. - “[C]harging a price for technical support services where this does not serve only the recuperation of actual costs”
This is a little more complex, because it allows FOSS products to charge for technical support, but only up to the amount necessary to recoup “actual” costs. The costs undoubtedly include wages for developers who provide the technical support, and other related costs, but to what degree? - “[A]n intention to monetise”
Intentions are hard things to prove, but if you are trying to make money from your FOSS project it’s commercial, independent of your success. Additionally, CRA regulators can use the circumstances of the product’s publication as a way of determining this commercial intent. What the developer says and how they distribute their product matters. - “[T]he processing of personal data for reasons other than exclusively for improving the security, compatibility or interoperability”
This means collecting and selling user data or using for purposes like targetting advertising – it’s a commercial activity. - “[A]ccepting donations exceeding the costs associated with the design, development and provision”
Another tricky provision similar to the one above on maintenance contracts. Donations are fine, but they can’t exceed the costs associated with design and development.
Of the types of commercialization listed here two present a special concern for FOSS developers: technical support contract and donations. In both situations, the CRA excludes these ways of raising funds from commercial activity if they are “don’t exceed the costs associated with design and development” or the “recuperation of actual costs”. Questions arise.
Who determines what actual costs are and if any stated costs are reasonable? What is “design and development”? Does maintenance count or can maintenance only be paid for by support contracts, not donations? Like many regulations, ambiguity has arisen, and we don’t get definitions for all the key terms … but we do get more paragraphs of the regulation that seem to refer to these issues and flesh out these exceptions.
On the question of donations we have this bit of guidance. Section 15 ends with:
Accepting donations without the intention of making a profit should not be considered to be a commercial activity.
Relief! Donations are excluded unless they are gathered with the intention of making a profit … but how does one determine that beyond intent beyond contextual clues of the designer intended to profit?
The CRA also includes some hopeful language for support contracts:
[T]he mere fact that an open-source software product with digital elements receives financial support from manufacturers or that manufacturers contribute to the development of such a product should not in itself determine that the activity is of commercial nature. CRA §18.
So even paid support for third-party commercial activity may not alone determine if a FOSS project is commercial. In these situations the commercial actor using the FOSS project as part of their own commercial project is responsible for certifying that their commercial product, including any FOSS parts, is sufficiently secure and meets CRA standards. Obviously this will result in commercial manufacturers putting pressure on open source developers to meet CRA standards when they wish to incorporate them, but the statute allows the developer to ask for payment for this without risking the open source status of their project. This protection is explicitly included in the CRA, also in Section 18.
[T]he supply of products with digital elements qualifying as free and open-source software components intended for integration by other manufacturers into their own products with digital elements should be considered making available on the market only if the component is monetised by its original manufacturer
While beneficial, none of these terms entirely clarifies the question of when donations and support contracts, or even contracts to add specific features for a corporate client, are commercial. They are helpful though, as they indicate the direction that the CRA intends to move in for FOSS – to exclude FOSS projects from the CRA unless they are intentionally and clearly commercial. Other passages in the CRA also support this reading, and perhaps provide even greater protections to FOSS products and their typical funding sources:
The mere circumstances under which the product with digital elements 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. More specifically, for the purposes of this Regulation and in relation to the economic operators that fall within its scope, to ensure that there is a clear distinction between the development and supply phases, the provision of products with digital elements qualifying as free and open-source software that are not monetised by their manufacturers should not be considered to be a commercial activity. CRA §18.
and
Regulation to products with digital elements qualifying as free and open-source software supplied for distribution or use in the course of a commercial activity should take into account the nature of the different development models of software distributed and developed under free and open-source software licences. CRA §17.
Even more ways of looking at FOSS to determine if it reaches the level of commercial activity that the CRA must regulate. The first term makes a “clear distinction between the development and supply phases” providing that only the ways that a product is distributed, or how it is supported at distribution determine if it is commercial activity. This is another clarification that the actual monetization of the FOSS project is the primary factor to determine if the CRA regulates it.
The second term supports this understanding, and perhaps complicates it, by acknowledging that open source projects in particular can have long and convoluted development processes that look nothing like proprietary software development. The final paragraph of Section 18 highlights this issue with the following term:
[T]he mere presence of regular releases should not in itself lead to the conclusion that a product with digital elements is supplied in the course of a commercial activity.
With these terms the CRA almost offers an alternate way of determining when FOSS is commercial, and thus when it’s a regulated product – is it taking in money, beyond any costs to cover support or add new features and update, after it has been fully developed?
This may itself complicate the situation for developers as product development timelines are long, and often even long with FOSS projects, but the documentation requirements of the CRA are best met during the development process. If one is unsure about the ultimate success, or funding sources of an open source project, it can be hard to predict if the project will eventually need to be monetized or lend itself to commercial distribution. The CRA has an exemption that helps here as well, at least for developers that are willing to forgo profit.
[T]he development of products with digital elements qualifying as free and open-source software by not-for-profit organisations should not be considered to be a commercial activity provided that the organisation is set up in such a way that ensures that all earnings after costs are used to achieve not-for-profit objectives. CRA §18.
If the project is in the hands of a not-for-profit organization its development and distribution should not be considered commercial and within the CRA’s oversight, as long as any funds brought in to develop and support the project are spent either on the project or for other non-profit purposes. A well run non-profit already has to use money it brings in for “not-for-profit objectives” so this term can be read as a blanket exception from the CRA for non-profit organizations.
WRAPPING THINGS UP
Determining if one’s project must comply with the CRA should be possible by answering the following three questions:
- Is my project a “product” ?
- Is my project “open source” ?
- Is my open source project “commercial” ?
Even, or especially, with these questions answered there’s a lot more to learn about the CRA. It’s 265 pages of regulation including annexes, and this post only looks at the small question of when the Act applies to open source and free software. The actual regulatory requirements and implementation of the CRA is a much larger topic. It’s a topic that plenty of other organizations and individuals are keeping track of along with other emerging EU tech regulations. I’ve found the articles from Bert Hubert and NLNet Labs useful for updates on the CRA and questions about its implications for Open Source projects. Many of the larger Open Source foundations and organizations are also involved both in tracking the CRA’s implementation and even shaping how the CRA will approach FOSS both with lobbying and through the Open Source Software Steward role created by the CRA.
DISCLAIMER
This post is provided as information only and is not legal advice. I can’t give you legal advice like this, least of all because I don’t know your specific situation. Reading it doesn’t create any sort of attorney-client relationship between us, and I am not suggesting that you base any decisions on what you’ve read here. If you have legal questions you should seek an attorney who can and will represent you in an official capacity.
Finally, below are links to my presentations at the RIPE 89 conference in October 2024, that quickly cover the CRA and its approach to open source.
THE CYBER RESILIENCE ACT AND OPEN SOURCE SOFTWARE
CYBER RESILENCE ACT – WHEN IS FREE AND OPEN SOFTWARE COMMERCIAL?
Leave a Reply