CRA — Webmink In Draft

Standards and the Presumption of Conformity

Tue, 26 Nov 2024 15:23:52 +0000

This post has graduated to the OSI Blog.

Access to the law includes access to the harmonised standards it predicates. But is it right that those standards can include royalty-due patents (SEPs)?

If you have been following the progress of the Cyber Resilience Act (CRA), you may have been intrigued to hear that the next step following publication of the Act as law in the Official Journal is the issue of a European Standards Request (ESR) to the three official European Standards Bodies (ESBs). What is that about? Well, a law like the CRA is extremely long and complex and conforming to it will involve a detailed analysis and a lot of legal advice.

Rather than forcing everyone individually to do that, the ESBs are instead sent a list of subjects that need proving and are asked to recommend a set of standards that, if observed, will demonstrate conformity with the law. This greatly simplifies things for everyone and leads to what the lawmakers call a “presumption of conformity”. You could go comply with the law based on your own research, but realistically that's impossible for almost everyone so you will instead choose to observe the harmonised standards supplied by the ESBs.

This change of purpose for standards is very significant. They have evolved from merely being a vehicle to promote interoperability in a uniform market – an optional tool for private companies that improves their product for their consumers – to being a a vehicle to prove legal compliance – a mandatory responsibility for all citizens and thus a public responsibility. This new role creates new challenges as the standards system was not originally designed with legal conformance in mind. Indeed, we are frequently reminded that standardisation is a matter for the private sector.

So for example, the three ESBs (ETSI, CENELEC and CEN) all have “IPR rules” that permit the private parties who work within them to embed in the standards steps that are patented by those private companies. This arrangement is permitted by the European law that created the mechanism, Regulation 1025/2012 (in Annex II §4c). All three ESB's expressly tolerate this behaviour as long as the patents are then licensed to implementors of the standards on “Fair, Reasonable and Non Discriminatory” (FRAND) terms. None of those words is particularly well defined, and the consequence is that to implement the standards that emerge from the ESBs you may well need to retain counsel to understand your patent obligations and enable you to enter into a relationship with Europe's largest commercial entities to negotiate a license to those patents.

Setting aside the obvious problems this creates for open source software (where the need for such relationships broadly inhibits implementation), it is also a highly questionable challenge to our democracy. At the foundation of our fundamental rights is the absolute requirement that first, every citizen may know the law that governs them and secondly every citizen is freely able to comply if they choose. The Public.Resource.Org case shows us this principle also extends to standards that are expressly or effectively necessary for compliance with a given law.

But when these standards are allowed to have patents intentionally embodied within them by private actors for their own profit, citizens find themselves unable to practically conform to the law without specialist support and a necessary private relationship with the patent holders. While some may have considered this to be a tolerable compromise when the goal of standards was merely interoperability, it is clearly an abridgment of fundamental rights to condition compliance with the law on identifying and negotiating a private licensing arrangement for patents, especially those embedded intentionally in standards.

Just as Regulation 1025/2012 will need updating to reflect the court ruling on availability of standards, so too should it be updated to require that harmonised standards will only be accepted from the ESBs if they are supplied on FRAND terms where all restrictions on use are waived by the contributors.

Links, Tags & Mentions

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.

CRA Standards Request Draft Published

Sun, 28 Apr 2024 10:58:44 +0100

This article now forms part of an OSI position.

The European Commission recently published a public draft of the standards request associated with the Cyber Resilience Act (CRA). Anyone who wants to comment on it has until May 16, after which comments will be considered and a final request to the European Standards Organisations (ESOs) will be issued. This process is all governed by regulation 2012/1025, of which more in a future post.

This development is important for every entity that will have duties under the CRA (“manufacturers” and “software stewards”). Conformance with the harmonised standards that emerge from this process will allow manufacturers to CE-mark their software on the presumption it complies with the requirements of the CRA, without taking further steps.

For those who depend on incorporating or creating open source software, there is an encouraging new development found here. For the first time in a European standards request, there is an express requirement to respect the needs of open source developers and users. Recital 10 tells each standards organisation that

“where relevant, particular account should be given to the needs of the free and open source software community”

and that is made concrete in Article 2 which specifies:

The work programme shall also include the actions to be undertaken to ensure effective participation of relevant stakeholders, such as small and medium enterprises and civil society organisations, including specifically the open source community where relevant

and that requirement is made concrete in article 3 which requires proof that effective participation has been facilitated. The community is going to have to step up to help the ESOs satisfy these requirements – or have corporates masquerading as community do it instead.

Notes, Tags and Mentions

#Policy #CRA #OpenSource #FreeSoftware #SoftwareFreedom

Openly Shared

Thu, 25 Apr 2024 09:17:43 +0100

This article has moved to the OSI Blog.

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.

The Return Of "Freeware"

Thu, 04 May 2023 10:59:57 +0100

Like me you may be surprised to see the suggestion from the IMCO Committee to change “free and open source software” in the CRA to “freeware and open source software” in an amendment from Karen Melchior MEP¹. It's not a word I have heard much this decade, so I checked with her team and discovered this was an informed and intentional choice, not a misunderstanding (by them, at least).

They told me that they believed the term “free and open source software” was misunderstood² by the Commission to be two categories — proprietary software supplied without charge and software developed in the open under an OSI-approved license. They inquired and found that the team authoring the draft at the Commission very much intended to create an exception for proprietary software delivered at no charge, so have proposed this amended language to clarify the matter along with an amendment (129) defining “freeware” for absolute clarity.

I should add I have yet to meet anyone from the Commission who can substantiate this.

Notes, Tags and Mentions

The IMCO Amendments include this word in Amendment 66 and 120 and it is defined in Amendment 129.
My earlier article “Getting Back To A Social Frame” appears relevant here.

#CRA #EUCRA #FOSS #FLOSS #IMCO #OpenSource #Freeware

Comply or Withdraw?

Thu, 27 Apr 2023 19:03:47 +0100

Update: This has now graduated to the OSI Blog. What might happen if the uncertainty about who has responsibilities under the Cyber Resilience Act (CRA) is allowed to persist? The global open source community are averse to legal risks and generally lack access to counsel so will very possibly simply withdraw their offers of source code rather than resolve the uncertainty.

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

Not Trying To Opt Out

Wed, 26 Apr 2023 15:50:49 +0100

No, open source advocates are not engaged in “special pleading” to try to get open source given an unreasonable artificial market advantage in Europe, as some are alleging. From the very beginning I have heard people claiming that open source advocates are trying to get open source software per se excluded from the scope of regulation by the Cyber Resilience Act (CRA). Even now it seems people are still hearing this.

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.

Consulting The Fourth Sector

Mon, 10 Apr 2023 17:10:03 +0100

Update: This post has graduated to the OSI blog and is also available en Français. It's good news that the European Commission is now considering the value and needs of open source in its policy deliberations. What's less good is that it does so through the wrong lens. The Commission needs to extend its consultations, Expert Groups and other work to include and consider the fourth sector.

Post-industrial society comprises three sectors in the worldview undergirding the European Union:

The Commercial Sector includes industrial, extractive, service, logistic and administrative companies. They are represented pro se, by industry and trade associations, by consulting and lobbying companies and more.
The Labour Sector includes workers of all kinds – industrial, skilled, research, educational, managerial, entrepreneurial and more. They are represented by trade unions, professional bodies, trade associations and more.
The Consumer Sector comprises everyone spending their personal wealth at all scales. They are represented by consumer associations, civil society organisations, religious organisations and more.

But the Internet has driven change over the last 50 years from which has arisen the World Wide Web and thence the Open Source movement, which in turn have catalysed many open culture movements in their rainbow mantles. The wave of open has produced many phenomena, good, bad and pending judgement – including the gig economy, open knowledge communities like Wikipedia and the Internet Archive, technology giants like Facebook and Google, open software stacks and supply chains and much, much more.

The roles people play in this open wave do not fit comfortably into the three post-industrial sectors. An individual would be expected predominantly to fall within the consumer sector, with a section of their life represented in the labour sector. But an open source developer can play roles characteristic of a commercial sector player, innovating and creating soft goods (commercial sector) which are assembled (commercial sector) or used (consumer sector) by others. A video streamer may be creating new copyrighted works of great value (commercial sector) that are widely viewed (consumer sector). An author or musician can now create their own compelling brand without becoming an employee of a publisher.

This is the new fourth sector. It comprises individuals, often connected and facilitated by ad-hoc or charitable communities, playing the roles of the commercial, labour and consumer sectors in varying mixes all at the same time. The fourth sector is poorly represented by the entities and roles associated with all three of the other sectors. That's inevitable; each fourth sector role will fuse together an aspect represented and an aspect confronted by any of the entities and roles dedicated to the three traditional sectors. So a consumer association won't advocate well for open source developers because an aspect of their existence is classified as commercial. A streamer won't be well represented by a trade union because they embody both consumer and commercial aspects. And so on.

As a result, existing consultation mechanisms used by legislators are guaranteed to fail. When they try to deal with open source by expressing the understanding they have gained of proprietary software, they will keep causing collateral damage — as we have seen in the Cyber Resilience Act (CRA) and many times previously. The need will increase as regulation tries to control, account for or promote the activities of the fourth sector without consulting it.

One significant reason this has been happening for such a long time already is the lack of a term to use to raise the issue. That's why I am proposing to call this sector of European society the “fourth sector”. It extends well beyond open source, covering any new, citizen-centric economic activity which is hard to have represented with only the existing commercial, labour and consumer lenses. Let's tell the Commission and other governments that it's time to care about the fourth sector, which is the driving force for all the changes they want to embrace — or control.

Notes, Tags & Mentions

This essay and the thinking behind it about a “meshed society” has been around for quite some time — indeed, I named my consulting company after it in 2013 because it under-girded all my thinking at Sun and before that at IBM! I finally got round to a web search to see if the term “fourth sector” was in use and ... yes it is, in the USA! Defined in a very similar way to the way I have done, although with the focus on only entrepreneurial activity, using the term as a synonym of “for-benefit company” and omitting the dimension of individual and local activity without incorporation. See Building Better and Fourth Sector Group for example. Their concept amazingly omits open source. Time to remedy that.
Photo is my own, of the edition of Auguste Rodin's “The Burghers of Calais” (“Les Bourgeois de Calais”) exhibited at the Musée Rodin in Paris.
#CRA #OpenSource #4thSector #Policy #Democracy #Representation #Terminology

Open Source Is Conceptually Disjoint From Proprietary Software

Tue, 04 Apr 2023 16:46:04 +0100

Update: This post has graduated to the OSI Blog. In reviewing the language and concepts being used in the various draft bills and directives circulating in Brussels at present, it is clear that the experts crafting the language are using their understanding of proprietary software to build the protections they clearly intend for open source. This may be the cause of the problems we continue to see as the instruments iterate, especially in the absence of direct consultation.

Proprietary software and the company that places it on the market can usefully be seen as the same target for those creating legislation. The software is constructed in secret, under the control of a single party, and the controlling party is responsible for both funding the work and monetising the result. However, the same cannot be said for open source software, which is created openly by a globally-distributed and unaffiliated community whose relationship with the larger work is “volunteer”. Using terminology associated with the worldview of proprietary software in legislation that affects open source is at best ambiguous and at worst extends consumer regulation to the domain of research and development.

Open source software is an artifact arising from the interactions of a community of contributors with no contractual binding between them beyond the open source license itself, which disclaims all warranties and has no conduit for funds. If there is an open source charity or trade association hosting the community, there will also be only a limited binding to to it and probably none that is a funding conduit. Many communities are unincorporated and don't even have this level of interconnection.

Because of this, those who place the artifact with digital elements on the market must be assumed to have no financial, organisational or indeed morally relevant relationship with any other party involved in the artifact's origination or use. There may be links, but it's best to start from the assumption there will be none because making them is an outside activity with no accommodation in open source licensing.

In many cases (sadly) those placing the artifact on the market have no connection at all with the community, not even at the level where it is appropriate to consider members of the community as suppliers. As one community member wrote:

I am not your supplier. So all your Software Supply Chain ideas? You are not buying from a supplier, you are a raccoon digging through dumpsters for free code.

The software and the community thus need to be considered separately when choosing language that applies regulation affecting open source. Some highlights to note:

The software is made freely available under an OSI-approved license that ensures its consumer may do anything it wishes without needing any relationship with rights holders.
The members of the community collaborate for many different reasons, and even when those reasons have commercial intent the commercial intents in play are likely to be unrelated both formally and informally.
Many community members have a moral/ethical basis for their participation which can sometimes take priority over pragmatic convenience.
Treating the software and the company placing it on the market as interchangeable is unsafe.
As a consequence, it is unsafe to assume that because two parties are monetising a piece of open source software, that there is a flow of funds or even a relationship between them. Regulation should only apply to the party triggering the clause in the legislation, unlike with proprietary software where it is reasonable to assume a link.

Notes, Tags & Mentions

See also “The comprehension error behind the CRA issue“
The photograph is my own, of the Head of Saint Gereon in front of the Basilica of St. Gereon in Bonn, artist Iskender Yediler.
#CRA #PLD #Policy #OpenSource #Software

CRA Compliance - Engaging Standards Bodies

Fri, 24 Mar 2023 09:38:41 +0000

Update: This has now graduated to the OSI Blog. One of the proposals in the Cyber Resilience Act (CRA) is that European standards bodies should develop suitable standards that help simplify conformance. Bert Hubert explains how this might work in his extensive CRA explainer.

There's a crucial issue here for open source. EU policy experts say not to worry about CRA compliance because the EU standards bodies will streamline it. But the ESOs are corporate-controlled, patent-loving & expensive to engage. Shouldn't the EU address this if they want open source accommodated?

In Europe, standards requests from the European Commission are handled by bodies which have been designated a European Standardisation Organisation (ESO) under EU law. There are only three of these; CEN, CENELEC and ETSI. None of these standards development organisations are accessible to open source projects per se.

CEN and CENELEC are largely controlled by national standards bodies which in turn are dominated by national industries, while ETSI is a member organisation with high membership fees and largely secret proceedings (although laudably with free specifications) that is directly controlled by its members, predominantly from the telecoms industries but also including the European states. In addition, ETSI celebrates its role as a pioneer and proponent of FRAND licensing, which is fundamentally incompatible with open source communities. As with all de jure standards, participation in each of these standards bodies is expensive, both financially and in time, and engaging in their governance is beyond the scope of small players.

Given this context, when the European Commission requests standards that will be applied for conformity assessment it's not clear how they will take into account the development workflow that applies to open source software. Like the European Commission itself (as I commented recently), Europe's standards bodies have no functional relationships with open source charities and do not consult them.

It is very important to find ways to give a voice to the true community and not just its corporate members. As things currently stand open source will only be considered through the lens of its corporate uses. Since open source is a social movement with software artifacts for which the applications are diverse, paying heed only to the attributes of the software and the needs of the companies consuming it is an inadequate approach. You can't even proxy through small business, let alone multinationals and their lobbyists – many of them are unaware of how communities work and without community understanding, fundamental errors can be made.

As a result, I believe whatever legislation arises from the CRA (and related instruments) needs to specify that standards bodies making related standards must include effective measures to consult and include the open source community. If this doesn't happen, as NLnet Labs explained, “The only alternative left available are the conformity assessment procedures that involve paying for third party process auditors.” And open source developers definitely can't afford that.

Tags & Mentions

#CRA #Standards #OpenSource #FOSS #Policy #4thSector @bert_hubert@fosstodon.org @maarten@techpolicy.social

The Commission MUST Consult The Open Source Community

Thu, 16 Mar 2023 09:46:34 +0000

Update: Graduated to the OSI Blog

I wrote recently about the possible origin of a serious defect in terminology in the Impact Assessment of the Cyber Resilience Act (CRA). But this is not the only problem with the Impact Assessment. A crucial one appears in Annex 2 (on page 4 of the Part 2 pdf), where it becomes clear from sections 2-4 that no open source communities or community fiduciaries were consulted as stakeholders.

In the comments by the European Commission's policy officers given during a FOSDEM Main Stage panel it became clear they had been working on the language of the updates to the Public Liability Directive (PLD) and CRA for a significant time. When asked why they had not consulted the community until now (at 1:27:45 on the video), they replied it was the community's responsibility to find out about their work and show up to published consultations.

It is not enough to expect the open source ecosystem to spontaneously show up – it is not structured in a way that makes that likely. In any case the consultation process has no category for individuals who make economically significant works outside the role of “Company” or “Workforce”. In other words, there were no consultations aimed at the community. At best we will show up late in the process asking why no-one called, as we are now.

It is not unreasonable to ask to be treated in a way respectful of these realities; the process does so for SMEs. Section 4 of Annex 2 observes “However, it has been very difficult to get substantial input from SMEs.” As a result there was extensive, targeted outreach to SMEs resulting in significant inputs. No equivalent effort was made to reach out to open source charities like OSI, or to significant fiduciaries like Apache, Eclipse or Python.

There are some inputs all the same. It's great that companies in the open source ecosystem do show up in consultations, and I know of a number who have lobbyists in Brussels. But they cannot be relied on to explain or even consider the perspectives of the significant number of community participants either outside their interest area or even opposed to it.

It is very important to find ways to give a voice to the true community and not just its corporate members. Open source is a social movement with software artifacts and market consequences. Paying heed only to the latter (or even the latter two) is an inadequate approach. You can't proxy through SMEs, let alone multinationals and their lobbyists.

This is a serious and persistent issue with the Commission's work; they need to become aware that when proposals affect the open source ecosystem (of which the open source software market they value is a part but not the whole), it is essential for them to treat the members of that ecosystem as key stakeholders and make at least as much of an effort to reach out to them as they do to SMEs — possibly more.

#CRA #PLD #Policy #OpenSource #Community #4thSector