The comprehension error behind the CRA issue
Perhaps all the problems we are having with the Cyber Resilience Act (CRA) arise from a misunderstanding of specialist language used by an academic evolving into an imperfect use of the term “commercial” in the exclusion of open source from the CRA?
A colleague drew my attention back to the impact assessment performed by the European Commission last year in the process of drafting the CRA text that was recently sent to the European Parliament. Skimming through, my attention settled on Annex 3 and in particular “Box 4: The open source software (OSS) market – outlook” (on page 30-31 of Part 2 – snapshot). This page includes the statement:
According to the literature, it is in principle possible to segment the open source software (OSS) market into commercial open source and non-commercial open source. In opposition to its counterpart, commercial open source is defined as “open source software projects that are owned by a single firm that derives a direct and significant revenue stream from the software”
which cites a paper by academic Dirk Riehl from 2009 as “the literature”. But the opening assertion is profoundly incorrect. Dirk has never advocated for segmenting the open source software market into “commercial open source and non-commercial open source”, or proposed treating those terms as descriptive rather than as defined terms.
The quotation is fair – Dirk does (controversially to many people) use the term “commercial open source” as a defined term to indicate an open source project where only one company is predominantly involved in maintenance of the source code. But the antonym he has coined for this is not “non-commercial” – rather it is “community open source”. The coinage is controversial because it leads people to incorrectly believe that community-maintained open source projects are in some way “non-commercial”, as the Commission has done here.
It appears the impact assessment drove final choices in drafting the CRA. For example, there were a range of available policy options (see section 5.2 of the Impact Assessment (part 1, page 28)) and it seems the Impact Assessment led to the decision to select option 4 (regulate all digital products) rather than option 3 (predominantly regulate only embedded software). Was this choice validated by the belief that open source software could be segmented into “commercial” and “non-commercial”? There is no mention of open source in section 6 (page 39) so presumably there was no expectation of impact on open source arising from this decision.
Cite The Source
It seems to me that many of the issues observed with the open source exception to the CRA arise from the use of the term “commercial” with a definition assumed from the Blue Guide and NLF when in fact the risk assessment that led to the legislative option chosen used Riehl's rather specific coinage as its definition.
Based on these observations, I wonder if one approach to take here to resolve the community's concerns is to import the misunderstood definition into the CRA so that it adequately defines “commercial” in the way it was scoped in the impact assessment (except using a more recent formulation of Riehl's definition).
At first consideration, this seems to remove all the issues that have been concerning the community without detracting from the intent of the legislation. It excludes all in-progress open source software from the scope of the CRA while continuing to give responsibilities to those embedding software and those producing proprietary-equivalent software products. It may be that expressly describing all the relevant attributes of what's in and out would be better, but it's surely worth considering using the original idea that perhaps created the issue?
Follow @webmink@the.webm.ink to be informed of new posts. 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.