EU Cyber Resilience Act and the emergence of proto-legislation

EU laws start with recitals. These are considerations.

The EU Joint practical guide notes:

The purpose of the recitals is to set out concise reasons for the chief provisions of the enacting terms, without reproducing or paraphrasing them. They shall not contain normative provisions or political exhortations.

After the recitals follow the articles, the operative provisions.

Den Heijer et al show “that the use of recitals has changed substantially over time. Preambles are growing and many recitals contain normative exhortations. In addition, a substantial proportion of recitals in currently adopted acts merely paraphrases the enacting terms. Such drafting practices are in violation of the EU’s guidelines on legislative drafting. They may jeopardize the legislative principles of accessibility and legal certainty.”

The Council of the EU finds it easier to reach a compromise on recitals than on articles. Den Heijer et al argue that recitals that are used to alter the normative content of EU [law] generate confusion, poly-interpretability and give a false impression of European consensus.

In 2007, when we wrote a report on the European Parliament version of the IPRED2 proposal, we didn’t even mention recitals. The debates were about articles. I’m somewhat shocked by the deterioration.

European Court of Justice:

On this point, it must be stated that the preamble to a Community act has no binding legal force and cannot be relied on as a ground for derogating from the actual provisions of the act in question. ³

In the case of the CRA, regarding open source, the “meat” is in the recitals – in violation of the Joint practical guide.

The European Commission proposal didn’t exclude open source development, and recitals cannot be relied on as a ground for derogating from the actual provisions, so, it may seem, only adding recitals is not enough to safeguard open source. Turns out, the co-legislators were creative enough to do that – using a shortcut, and at a price.

The safeguards for open source ended up in the recitals 10 through 10e, a 5 pages column, beginning at page 16. See the Attachment, recitals. They are apparently linked to Article 3 Definitions (23), page 130. Maarten Aertsen reported:

it was explained to me that the definition of “making available on the market” is the key, in particular “commercial activity”, which is what connects with recitals 10 through 10e.

Here is Article 3 Definitions (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;

Having a 5 pages column of recitals linking to a short definition is unusual. This approach comes with some issues.

First, if in particular “commercial activity” is key, why doesn’t article 3 have a definition of “commercial” or “commercial activity”? Commercial activity is not defined in article 3, the CRA only gives considerations in the recitals regarding it. As a result, the definition of ’making available on the market’ in Article 3 Definitions (23), if read in the light of recital 10, has a different meaning than if read in the light of recital 10(a), or 10(b), etc. This is rather fuzzy. By not defining commercial (activity), the act remains in a state prior to really creating a law. We could call this proto-legislation.

Recitals consider what a law should do, and the articles implement the considerations with a rule or definition. It is more difficult to formulate a rule or definition than to give some considerations. It forces to understand, imagine, conceptualise. Make a rule, exceptions to the rule, and may be exceptions to the exceptions. With good rules, you know “where you are”. As the proof is in the pudding, the proof is in the rule or definition. With clear rules you can see whether the rules in the act are consistent with each other and with rules in other laws. Even then, it is good to have the considerations as a back up. Courts can read articles in the light of the recitals.

We can expect the EU Court to properly navigate the fuzziness; it is hard to overlook a 5 pages column of recitals regarding open source, and open source software is important enough to get it right. May this understanding never dissipate. But it is ugly, and in less obvious cases it could lead to legal uncertainty. Vrijschrift has an open source, access to knowledge, and digital rights agenda. We do not want legal uncertainty, especially not regarding fundamental rights.

Second, if the EU makes another law on software, it would be handy to incorporate a definition like: “commercial activity means commercial activity as defined in Article 3, point (x), of the Cyber Resilience Act”. But without a definition that is not possible. Or, if you would like to see a 5 pages column of recitals as the definition, linking to them imports the fuzziness. This way you do not create a system of law, but a patchwork of considerations. This would make EU law harder to understand.

Third, in the debates on the IPRED2 proposal, “commercial (scale)” was widely discussed. But none of the proposed definitions was longer than a few lines. This alone seems an indication that something is off. Recitals 10 through 10e seem just as much about making a distinction between upstream development and downstream commercial use. It is an open question whether definitions of “commercial”, “upstream development”, and / or “downstream use”, and a simple article only bringing downstream commercial use under the scope of the CRA wouldn’t have provided a more clear solution, that is also reusable in other acts. The recitals could have been used for background.

By more or less refusing to discuss articles, the Council of the EU avoids clarity. The Cyber Resilience Act may be a clear example, as the original commission proposal was broken and the repairs are in the recitals. It may not harm open source in this case, in general it does harm accessibility and legal certainty, and leads (in part) to a patchwork of considerations instead of a legal system.

I would suggest the Council of the EU reinvent itself as a co-legislator.

(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. 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, or 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. Accepting donations without the intention of making a profit should not be considered to be a commercial activity.

(10a) Products provided as part of the delivery of a service for which a fee is charged solely to recover the actual costs directly related to the operation of that service, such as may be the case with certain products provided by public administration entities, should not be considered on those grounds alone a commercial activity for the purposes of this Regulation. Furthermore, products with digital elements which are developed or modified by a public administration entity exclusively for its own use should not be considered as made available on the market as defined by this Regulation.

(10b) Software and data that are openly shared and where users can freely access, use, modify and redistribute them or modified versions thereof, can contribute to research and innovation in the market. To foster the development and deployment of free and open-source software, in particular by microenterprises and small, medium-sized enterprises, including start-ups, and not-for-profit organisations, academic research and individuals, the application of this Regulation to free and open-source software products 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.

(10c) Free and open-source software is understood as software the source code of which is openly shared and the license 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. In relation to the economic operators covered by this regulation, only 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 be covered by this Regulation. 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. More specifically, for the purpose of this Regulation and in relation to the economic operators referred therein, to ensure that there is a clear distinction between the development and the supply phases, the provision of free and open-source software products with digital elements that are not monetised by their manufacturers is not considered a commercial activity. Furthermore, the 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 only be considered as making available on the market if the component is monetised by its original manufacturer. For instance, the mere fact that an open-source software product with digital elements 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. 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. Finally, for the purpose of this Regulation, the development of products with digital elements 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. 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.

(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. 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. For the purpose of the light-touch and tailor-made regulatory regime, an intention for integration into monetised products includes cases where manufacturers that integrate a component into their own products with digital elements either contribute to the development of that component in a regular manner or provide regular financial assistance to ensure the continuity of the software product. The provision of sustained support to the development of a product with digital elements includes but is not limited to the hosting and managing of software development collaboration platforms, the hosting of source code or software, the governing or managing of free and open-source software products with digital elements as well as the steering of the development of such products. Given that the light-touch and tailor-made regulatory regime does not subject open-source software stewards to the same obligations as manufacturers under this Regulation, they should not be able to affix the CE marking to the products with digital elements whose development they support.

(10e) The sole act of hosting products with digital elements 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. Providers of such services should only be considered distributors if they make such software available on the market and hence supply it for distribution or use on the Union market in the course of a commercial activity.