The definition of “open source” in the most recent version (article 2(48)) of the Cyber Resilience Act (CRA) goes beyond the Open Source Definition (OSD) managed by OSI. It says:

“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.”

The addition of “openly shared” was a considered and intentional addition by the co-legislators – they even checked with community members that it did not cause unintended effects before adding it. While open source communities all “openly share” the source code of their projects, the same is not true of some companies, especially those with “open core” business models.

For historical reasons, it is not a requirement either of the OSD or of the FSF's Free Software Definition (FSD) and the most popular open source licenses do not require it. Notably, the GPL does not insist that source code be made public – only that those receiving the binaries must be able to request the corresponding source code and enjoy it however they wish (including making it public).

For most open source projects and their uses, the CRA's extra requirement will make no difference. But it complicates matters for companies that either restrict source availability to paying customers (such as Red Hat) or make little distinction between available and non-available source (such as ForgeRock) or withhold source to certain premium elements.

A similar construct^{1} is used in the AI Act (recital 102) and I anticipate this trend will continue through other future legislation. Personally I welcome this additional impetus to openness.

Notes, Tags and Mentions

• #CRA, #OpenSource, #Policy, #Europe, #FreeSoftware, #SoftwareFreedom
• {1} The mention in the AI Act has a different character to that in the CRA. In the AI Act it is more narrative, restricted to a recital and is a subset of attributes of the license. In this form it actually refers to virtually no OSI-approved licenses. In the CRA the wording part of the formal definition in an Article, so much more impactful, and adds an additional requirement over the basic requirements of licensing.

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.

The CRA rightly addresses the need for commercial suppliers to protect their customers from exploits and cyber attacks. But by incorrectly assuming that Dirk Riehle's terminology calling single-company projects “commercial open source” means it's possible to use the “commerciality” of an application to distinguish single-company activity from community projects, and by using the concepts of proprietary software to then define boundaries, legislators have exposed the open development of software itself to the regulations rather than just the for-profit use of open source artifacts in the marketplace.

There will be no escape from this for European projects like the Eclipse Foundation, but projects outside Europe — especially smaller projects — may just decide to erect geo-blocks and not deliver their work to European IP addresses. CRA-motivated geo-blocks start with not being able to know what to do without seeking legal advice, and even then being told “maybe” and still left to decide yourself.

One response when I raised this was to say that the European Union is a massive and valuable market and projects would not risk being excluded from it by geo-blocking. But this argument ignores the fact that just because Alice deploys some code profitably in Europe, it doesn't mean Bob in Nebraska will share in the profit even though he wrote it, whether he's in business or not where he lives. Open source licenses do not create a relationship over which financial reward is guaranteed.

Geo-blocks have happened before. Many small global publications block access from the EU rather than resolve legal uncertainties with GDPR, but the risk of CRA-related geoblocks is much more consequential because reading those sites is optional whereas much open source software maintained internationally is woven into the fabric of Europe's infrastructure.

In addition, those avoiding evaluating their GDPR responsibilities (or evading them after evaluating them) are likely to fear compliance will impact the benefit they gain from surveillance advertising, while for open source developers the perceived risk is of being the target of a punitive bureaucracy for failing to complete paperwork that adds nothing to their work.

If the confusion persists, open source projects will need to thoughtfully consider how to proceed. Disentangling dependencies that choose to pragmatically block Europe will be traumatic; should they be forked or substituted? Things could get very messy. Let's hope the co-legislators see sense, finally talk to the open source community and address the issues.

Notes, Tags and Mentions

• #CRA #OpenSource #Europe #Policy
• @EclipseFdn@mastodon.social @dirkriehle@hachyderm.io

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.

The European Commission draft of the CRA purported to exclude open source from the scope of the new law throughout community development until it was made available on the market commercially — its author said as much at FOSDEM 2023. This is a good thing as it would be harmful to open source development if merely developing software in the open became subject to regulation — I have written previously about the mistaken use of a proprietary-software frame. However, as drafted the Act has substantial apparent inaccuracies and oversights that would probably lead to regulation of developers pre-market.

Consequently many practitioners have asked those considering the Act to correct these defects. It is proving very challenging, because originally the CRA only applied to physical products with digital elements (like IoT devices, routers and so on), but following the impact assessment (which made a serious error of comprehension with an academic source) the scope was enlarged to include products without physical elements. I regard this as a huge mistake and the origin of the ambiguities which are causing the problems. Unfortunately it appears to be too late to fix, so now we are trying to get an adequate ringfence around the pre-market development cycles of open source by fourth-sector developers.

Some voices have then sought to misrepresent this as an attempt to exclude open source entirely from the regulation even when placed on the market commercially. This meme was already circulating when the draft text was first released (before any advocates I know had even commented). Naming no names, these voices are the kind of “friends of open source” whose agenda is actually to disadvantage it as much as possible. Some parties have then abstracted this misdirection into a general criticism. If you do see anyone asking for open source per se to be excluded rather than just for the development community to be excluded from the scope, please let me know so OSI can intervene.

Notes, Tags and Mentions

• #OpenSource #CRA #Policy #Europe #4thSector
• @osi@opensource.org @dirkriehle@hachyderm.io
• The photo is my own, taken in London at the former Kirkcaldy Testing and Experimenting Works on Stamford Street.

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.