Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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.

 

--

Steve Millidge

 

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:20AM 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@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org


_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org

 


Back to the top