It may be useful to also look at the PLD and the various other bits of regulation.
Because one aspects the politicians cared about a fair bit was the loss of `feature' that was present when a product was bought later on. Such as, say, Netfix or Spotify integration on a television, or phone integration in a car.
And then that TV or Car loosing the half usefulness the consumer bought it for as an API was retired.
So I think it is fair to assume that these definitions wil get broader and wider; and that API demarcation lines get weaker from a product as sold perspective.
Dw
On 4 Jul 2024, at 12:10, Steve Millidge (Payara) via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:
Thanks Steffen – I will go back to our lawyers for a revised assessment 😊 From: Steffen Zimmermann <steffen.zimmermann@xxxxxxxx> Sent: Thursday, July 4, 2024 11:04 AM To: Open Regulatory Compliance Working Group <open-regulatory-compliance@xxxxxxxxxxx> Cc: Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> Subject: AW: [open-regulatory-compliance] Does being categorized as Important or Critical product impact FOSS dependencies (Was: European Commission informal CRA consultations on the definition of Critical and Important products) Hi, once again 😉 remote data processing is an option! Software products without remote data processing are clearly in scope. If a software product leverages remote data processing to perfom essential functions, this processing is also in scope. The question therefore is, if there is remote data processing, which part of the remote data processing is in scope and which not and to what extend does this include the infrastructure of the service/solution? Remote data processing in scope, when “the absence of which would prevent […] a product with digital elements from performing one of itsfunctions.” Example is given in the recital (11): That approach ensures that such products are adequately secured in their entirety by their manufacturers, irrespective of whether data is processed or stored locally on the user’s device or remotely by the manufacturer. At the same time, processing or storage at a distance falls within the scope of this Regulation only in so far as it is necessary for a product with digital elements to perform its functions. Such processing or storage at a distance includes the situation where a mobile application requires access to an application programming interface or to a database provided by means of a service developed by the manufacturer. In such a case, the service falls within the scope of this Regulation as a remote data processing solution. Mit den besten Grüßen, Steffen Zimmermann Industrial Security @ VDMA Von: open-regulatory-compliance <open-regulatory-compliance-bounces@xxxxxxxxxxx> Im Auftrag von Steve Millidge (Payara) via open-regulatory-compliance Gesendet: Donnerstag, 4. Juli 2024 11:47 An: Open Regulatory Compliance Working Group <open-regulatory-compliance@xxxxxxxxxxx> Cc: Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> Betreff: Re: [open-regulatory-compliance] Does being categorized as Important or Critical product impact FOSS dependencies (Was: European Commission informal CRA consultations on the definition of Critical and Important products) I also agree this is a reasonable question to ask as there is contradictory advice coming from some lawyers. “The purpose of this Regulation is to ensure a high level of cybersecurity of products with digital elements and their integrated remote data processing solutions.” – emphasis in original text For example advice we received is that a product can be software but it must also have “its remote data processing solutions” and the remote data processing is only in scope if “it is necessary for a product with digital elements to perform its functions”. So my simple understanding is that drupal or a drupal module is under the scope of the CRA if it passes the statements below; 1) It is installed by an end user i.e. a product placed on the market (not pure SAAS) 2) It must talk to some remote data processing to function – “for which is designed and developed by the manufacturer, or under the responsibility of the manufacturer” 3) That remote data processing is necessary to perform its functions. If it is sold as pure SAAS then NIS(2) would apply depending on the size of the org selling it as SAAS. So in my mind a pure OAuth integration module would fail (2) as although it is designed to integrate with an OAuth provider the module writer is not providing the remote data processing. However a module that say talked to some service ran by the module manufacturer – say a drupal module/code library shipped by a service provider like Auth0 that had to use their SAAS service would be covered. Note I am not an expert on this just reiterating the gist of legal advice we received. From: open-regulatory-compliance <open-regulatory-compliance-bounces@xxxxxxxxxxx> On Behalf Of Felix Reda via open-regulatory-compliance Sent: Thursday, July 4, 2024 10:05 AM To: Open Regulatory Compliance Working Group <open-regulatory-compliance@xxxxxxxxxxx> Cc: Felix Reda <felixreda@xxxxxxxxxx> Subject: Re: [open-regulatory-compliance] Does being categorized as Important or Critical product impact FOSS dependencies (Was: European Commission informal CRA consultations on the definition of Critical and Important products) Am 03.07.2024 um 23:20 schrieb Idelberger, Florian (IIWR) via open-regulatory-compliance < open-regulatory-compliance@xxxxxxxxxxx>: 2) Yes, there can be products that are purely digital, why shouldn’t there be?
While this answer is correct, it is not an unreasonable question to ask. Traditionally, a lot of EU legislation, including the 1983 Product Liability Directive (PLD) up until recently, defined products as "all movables, ... even though incorporated into another movable or into an immovable“ - this definition was often interpreted as requiring products to be tangible. Only the recent revision of the PLD changed the definition of products to explicitly include software. EU consumer law still distinguishes between „goods“, which have to be tangible, and „digital content“ (data which are produced and supplied in digital form), which are intangible.
For the purposes of the CRA, however, the definition in Art. 3 (1) provides the answer:
'product with digital elements' means a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately; (emphasis mine)
By explicitly including software placed on the market separately from any hardware, the CRA clarifies that for the purposes of this law, a product can be purely digital (same as for the revised PLD). For other laws, the situation may be different.
Best,
Felix Am 03.07.2024 um 22:29 schrieb Joe Murray via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx>:
Thanks for the discussion Dirk-Willem, Steffen, Marta, Florian and Christian.
I am bringing forward this actual use case to try to sharpen our discussion and understanding because it seems like an edge case but not uncommon.
Drupal is a loose open source ecosystem with probably a few billion in annual turnover used by about 1 percent of internet websites .
I'm trying to tease out the difference between the primary function of an open source project (e.g. Drupal as a CMS, which is not covered by https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Annex_3.html), the primary function of an extension to the product (e.g. a Drupal module supporting OAuth for identity access management, which is covered by Annex 3 but is normally not the primary function of a Drupal install), and the primary function of the product in a particular sale (of Drupal with OAuth module as an identity access management system). I suspect that the firm selling the open source solution would have legal liabilities to ensure that it is securely developed, but I am unclear after that.
As I look more closely, I see the CRA only covers products. Are there products that are purely digital? Digital services are sometimes covered by NIS 2 if they are purchased by important or essential entities (https://ec.europa.eu/commission/presscorner/detail/en/QANDA_22_5375), and it entails equivalent obligations.
So I'm still trying to figure out which entities would meet which legal definitions in the sale of an individual Drupal CMS with a primary purpose of serving as an identity management system for access control to a political party or government department based on generic modules. I'm assuming that a consulting company making the sale and making the site from open source components would be the manufacturer: they are taking money, so they are putting the software on the market.
I'm unclear on whether individuals contributing to the relevant software modules will be protected or liable in some way.
In the Drupal ecosystem, there is a Drupal Association that as I understand it may be a candidate for Open Source Steward. I do not understand whether the maintainers of the 50,000+ contributed modules who tend to be a collection of a small number of individuals sometimes getting sponsorships will qualify as collections of Stewards, e.g. https://www.drupal.org/project/simple_oauth or https://www.drupal.org/project/auth0 . I doubt it. They rarely get money for sites that include their module, so I'm not sure if they are manufacturers in our example of a sale by the consulting company.
I hope this is helpful.
Joe Murray, PhD (he/him) President, JMA Consulting 416.466.1281
We respectfully acknowledge the autonomy of Indigenous peoples, and that JMA Consulting is located on the traditional territory of many nations including the Mississaugas of the Credit, the Anishnabeg, the Chippewa, the Haudenosaunee and the Wendat peoples which is now home to many diverse First Nations, Inuit and Métis peoples. We also acknowledge that Toronto is covered by Treaty 13 with the Mississaugas of the Credit.
On Mon, Jul 1, 2024 at 10:20 AM Dirk-Willem van Gulik via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote: On 1 Jul 2024, at 15:47, Steffen Zimmermann <steffen.zimmermann@xxxxxxxx> wrote: sorry for my very special view on machinery, which is b2b. That grinding machines I have in mind look like these. These are more or less “systems of systems”, having linux, windows, sensors, actuators, ethernet, opc ua, mqtt, REST-API, you name it.
... Build by developers maybe as a tailor-made product but based on a lot of (OSS) components from hundreds of suppliers.
Sure - and in some cases - when they buy, on the EU market, some component. Such as a ready made firewall - then that product was placed on the market by its supplier with all the trimmings. But that is fairly immaterial to these (end) developer from a ‘does my grinder need Annex II/III’ treatment CRA perspective. Dw _______________________________________________ open-regulatory-compliance mailing list open-regulatory-compliance@xxxxxxxxxxxTo unsubscribe from this list, visit https://accounts.eclipse.org_______________________________________________ open-regulatory-compliance mailing list open-regulatory-compliance@xxxxxxxxxxxTo unsubscribe from this list, visit https://accounts.eclipse.org
_______________________________________________open-regulatory-compliance mailing listopen-regulatory-compliance@xxxxxxxxxxxTo unsubscribe from this list, visit https://accounts.eclipse.org
|