Fixing The CRA For Open Source
You're not going to fix Europe's proposed Cyber Resilience Act (CRA) by defining “commercial”. The problem is not a lack of clarity in the term; it is the act of triggering applicability of the regulations on an attribute of the work rather than on the act of deploying it in commerce.
The CRA has drawn plenty of attention from open source groups, notably with a case study from the Eclipse Foundation expressing their belief that the CRA would place an existential burden on their activities. I joined with others drafting a detailed position on behalf of multiple organisations and also wrote a statement for the Open Source Initiative that focused just on one aspect – the use of commerciality in recital 10 to trigger an exception to applicability of the CRA for open source software. In his (brave) presentation at FOSDEM, the European Commission's policy office Benjamin Boegel explained that his intention had been to ensure that the CRA was not applicable to most open source; the view of the room was that the exception failed to achieve that. All this also applies to the Product Liability Directive, which uses the same wording.
It remains my view that this problem can't be fixed just by defining “commercial”. I said in OSI's position
The problem is not the lack of a taxonomy of “commercial”, it is the very act of making “commercial” the qualification rather than, for example, “deployment for trade”.
The trigger to the exception relies on an attribute of the software itself, “commercial”. In part the problem is that's a contested attribute. In some contexts, it is best to consider all open source software as “commercial”, as David Wheeler explained in 2006. On the other hand, open source is not a business model and does not need monetising to be effective, as I wrote in 2010. Using any attribute of open source as the trigger for an exception is likely to prove problematic though.
Proprietary software is made in secret. This means there's a clear point at which it ceases to be a private matter and becomes subject to public interest, a point which can trigger regulation. All the components from which it is constructed are either created or sourced privately. The product itself is designed and assembled privately. There's no disclosure required at any point in the process, only at the point of delivery. While this is generally less desirable than the open source process, where every part is subject to public scrutiny at every stage allowing design defects and implementation errors to be discovered early and by a wide community, the CRA favours the former by restricting the need for audit and certification only to the final customer delivery.
Open source software is made in public. Every action is a matter of public interest to some extent. The CRA discriminates against open source by requiring every single step of the process to be validated as subject to the exception. As both Eclipse and NLNet Labs have explained, there are many reasons why the exception may fail to be applicable. So open source will be necessarily chilled by legislation which defaults to requiring compliance by open source developers until they can be sure an exception applies to them.
To avoid this unintentional chilling effect, it is essential that the various legislation proposals using this trigger mechanism be revised to use the act of the monetiser rather than an attribute of the software as the condition for granting an exception. One possibility would be to use the act of offering for commerce rather than the commercial character of the software as a trigger:
| Original Text | Proposed Revision |
|---|---|
| 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. 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. | 10. In order not to hamper innovation, development or research, free and open source software that is openly shared and freely accessible, usable, modifiable and redistributable shall not be covered by this Regulation until it is offered in commerce. |
The exact words used may need some work, but the concept – of moving the condition for the exception from a characteristic of the software to the act of monetising it – is surely right, and also applicable elsewhere in the text.
To discuss this post please reply from Mastodon etc. (search for the URL) & include @webmink@meshed.cloud as WriteFreely still doesn't display replies. More.