|
IMO, and I think most people I have seen have echoed this, it mostly depends on primary function.
1) This means for example that Drupal would generally count as a CMS, the drupal module supporting OAuth through some other provider might require some obligations, whereas most obligations would be on the party developing/running the OAuth server or service
that this connects to. Unless you mean Drupal itself being the OAuth server/provider, in which case I would suggest to not do that.
2) Yes, there can be products that are purely digital, why shouldn’t there be?
3) A manufacturer/integrator whatever would be responsible for their work, though depending on their business they might qualify for rules as an SME, which have slightly different rules sometimes. Still, I would suggest not using Drupal for access management.
(Except for itself)
You might argue whether „making available on the market“ also covers bespoke works, but based on the definition of Art.3 (22) I think that is also covered.
4) Afaik, individuals are not covered by the regulation, in most cases. (Recital 17 is the best reason I could find right now)
5) Yes, the drupal association would be a candidate for open source software stewardship, which depends on what exactly it does. I a module is not sold, I believe most modules should not fall under the regulation, as f.e. source code hosting services are
generally exempted. (Recital 20)
Please note: this is a very general view, and individual circumstances might differ, and change the outcome.
--
Dr. Florian Idelberger
Karlsruher Institut für Technologie (KIT)
Zentrum für Angewandte Rechtswissenschaft (ZAR)
Institut für Informations- und Wirtschaftsrecht
Vincenz-Prießnitz-Str. 3, D-76131 Karlsruhe
E-Mail: florian.idelberger@xxxxxxx
KIT - Universität des Landes Baden-Württemberg und
nationales Forschungszentrum in der Helmholtz-Gemeinschaft
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.
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 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
|
