Discussion :

[Sandra Coret]

Les appareils intelligents connectés à Internet devront se conformer à des règles strictes de l'Union européenne en matière de cybersécurité, sous peine de se voir infliger une amende ou d'être bannis

Les appareils intelligents connectés à Internet, tels que les réfrigérateurs et les téléviseurs, devront se conformer à des règles strictes de l'Union européenne en matière de cybersécurité, sous peine de se voir infliger une amende ou d'être bannis de l'Union, selon un document de la Commission européenne

Les préoccupations relatives aux attaques de cybersécurité se sont accrues ces dernières années à la suite d'incidents très médiatisés où des pirates informatiques ont endommagé des entreprises et exigé d'énormes rançons.

L'exécutif européen annoncera sa proposition, connue sous le nom de "loi sur la cyber-résilience", le 13 septembre. Il est probable qu'elle devienne une loi après que les pays de l'UE auront apporté leur contribution.

Selon le document, les règles pourraient réduire le coût des cyberincidents pour les entreprises de 290 milliards d'euros (289,8 milliards de dollars) par an, contre des coûts de mise en conformité d'environ 29 milliards d'euros.

Les fabricants devront évaluer les risques de cybersécurité de leurs produits et prendre les mesures appropriées pour résoudre les problèmes, précise le document.

Les entreprises devront notifier les incidents à l'ENISA, l'agence de cybersécurité de l'UE, dans les 24 heures dès qu'elles auront connaissance des problèmes, et prendre des mesures pour les résoudre.

Les importateurs et les distributeurs seront tenus de vérifier que les produits sont conformes aux règles de l'UE.

Si les entreprises ne s'y conforment pas, les autorités nationales de surveillance pourront "interdire ou restreindre la mise à disposition de ce produit sur le marché national, le retirer de ce marché ou le rappeler", précise le document.

Les entreprises qui enfreignent les règles peuvent se voir infliger des amendes allant jusqu'à 15 millions d'euros ou jusqu'à 2,5 % de leur chiffre d'affaires mondial total, le montant le plus élevé étant retenu, les amendes étant moins élevées pour les infractions moins graves.

Source : Document de la Commission européenne

Et vous ?

Qu'en pensez-vous ?

Voir aussi :

L'UE évolue vers un règlement relatif aux cryptomonnaies et attire l'attention avec l'abandon de la terminologie de bannissement de l'algorithme de preuve de travail : adoption tacite du bitcoin ?

La loi européenne sur l'intelligence artificielle peut avoir un effet dissuasif sur les efforts en matière de logiciels libres, avertissent les experts de la Brookings Institution

La Commission européenne critiquée et poursuivie pour avoir enfreint ses propres lois sur la protection des données, l'organisme de réglementation aurait transféré aux États-Unis des données

[pierre-y]

Amazon qui arose généreusement le parlement européen mais qui veut quand même cartographié nos baraque, ça va se situer ou?

[totozor]

Je pensais que cette loi servait surtout à "protéger" les particuliers mais :

Les préoccupations relatives aux attaques de cybersécurité se sont accrues ces dernières années à la suite d'incidents très médiatisés où des pirates informatiques ont endommagé des entreprises et exigé d'énormes rançons.

Les entreprises se font vraiment piratées via leur électroménager connecté?
Je sais par exemple que nous avons plusieurs réseaux dans mon entreprise, je serais très surpris que les télé promotionnelles ou les outils de saisie sans accès sécurisé soient reliée au réseau de prodution.

[mith06]

L'analyse systématique des messages privés à la recherche de matériel d'abus sexuel d'enfants (CSAM) est-elle compatible avec leurs règles sur la cybersécurité?

https://www.developpez.com/actu/3334...n-des-enfants/

[Stéphane le calme]

La proposition européenne de loi sur la cyber-résilience, une menace pour l'open source ? Oui,
pour plusieurs acteurs qui indiquent que son application pourrait avoir un impact désastreux sur l'open source

La proposition de loi sur la cyber-résilience (CRA pour Cyber Resilience Act) de l'UE, qui vise à « renforcer les règles de cybersécurité pour garantir des produits matériels et logiciels plus sûrs », pourrait avoir des conséquences désastreuses pour les logiciels open source, selon des dirigeants de la communauté open source.

L'Europe part d'un constat :

Les produits matériels et logiciels font de plus en plus l'objet de cyberattaques réussies, entraînant un coût annuel mondial estimé de la cybercriminalité à 5 500 milliards d'euros en 2021.

Ces produits souffrent de deux problèmes majeurs qui augmentent les coûts pour les utilisateurs et la société :

1. un faible niveau de cybersécurité, reflété par des vulnérabilités généralisées et la fourniture insuffisante et incohérente de mises à jour de sécurité pour y remédier, et
2. une compréhension et un accès insuffisants aux informations par les utilisateurs, les empêchant de choisir des produits dotés de propriétés de cybersécurité adéquates ou de les utiliser de manière sécurisée.

Alors que la législation existante sur le marché intérieur s'applique à certains produits contenant des éléments numériques, la plupart des produits matériels et logiciels ne sont actuellement couverts par aucune législation de l'UE traitant de leur cybersécurité. En particulier, le cadre juridique actuel de l'UE ne traite pas de la cybersécurité des logiciels non embarqués, même si les attaques de cybersécurité ciblent de plus en plus les vulnérabilités de ces produits, entraînant des coûts sociétaux et économiques importants.

Deux objectifs principaux ont été identifiés visant à assurer le bon fonctionnement du marché intérieur :

1. créer les conditions pour le développement de produits sécurisés avec des éléments numériques en veillant à ce que les produits matériels et logiciels soient mis sur le marché avec moins de vulnérabilités et en veillant à ce que les fabricants prennent la sécurité au sérieux tout au long du cycle de vie d'un produit ; et
2. créer des conditions permettant aux utilisateurs de prendre en compte la cybersécurité lors de la sélection et de l'utilisation de produits comportant des éléments numériques.

La loi proposée peut être décrite comme le marquage CE pour les produits logiciels et a quatre objectifs spécifiques. Notamment :

1. veiller à ce que les fabricants améliorent la sécurité des produits contenant des éléments numériques dès la phase de conception et de développement et tout au long du cycle de vie ;
2. assurer un cadre de cybersécurité cohérent, facilitant la conformité pour les producteurs de matériel et de logiciels ;
3. améliorer la transparence des propriétés de sécurité des produits avec des éléments numériques, et
4. permettre aux entreprises et aux consommateurs d'utiliser des produits contenant des éléments numériques en toute sécurité.

Le projet de loi comprend une évaluation d'impact qui indique que « pour les développeurs de logiciels et les fabricants de matériel, cela augmentera les coûts directs de conformité pour les nouvelles exigences de cybersécurité, l'évaluation de la conformité, la documentation et les obligations de déclaration ». Ce surcoût fait partie d'un coût total de mise en conformité, y compris la charge pesant sur les entreprises et les pouvoirs publics, estimée à 29 milliards d'euros, et les prix plus élevés qui en résultent pour les consommateurs. Cependant, les législateurs prévoient une réduction des coûts des incidents de sécurité estimés entre 180 et 290 milliards d'euros par an.

La question est cependant : comment les développeurs de logiciels libres peuvent-ils supporter le coût de la conformité, alors que le manque de financement est déjà un problème critique pour de nombreux projets ?

La perspective de la Fondation Eclipse

Mike Milinkovich, directeur de la Fondation Eclipse, s'est dit « profondément préoccupé par le fait que le CRA pourrait modifier fondamentalement le contrat social qui sous-tend l'ensemble de l'écosystème open source : des logiciels open source fournis gratuitement, à toutes fins, qui peuvent être modifiés et distribués ultérieurement gratuitement, mais sans garantie ni responsabilité envers les auteurs, contributeurs ou distributeurs open source. On peut raisonnablement s'attendre à ce que la modification légale de cet arrangement par le biais de la législation ait des conséquences imprévues sur l'économie de l'innovation en Europe ».

Il définit ce qu'il attend de la Fondation Eclipse, y compris l'élaboration, la documentation et la mise en œuvre de politiques et de procédures pour « chaque projet de la Fondation Eclipse ».

Milinkovich note également que le CRA vise à restreindre les « logiciels inachevés » afin qu'ils ne soient « pas disponibles sur le marché à des fins autres que les tests ». L'utilisation de versions intermédiaires et de logiciels en cours de développement intense est courante dans la communauté open source, et les licences ne sont actuellement pas limitées aux tests.

Fondamentalement, le cœur de la législation proposée est d'étendre le régime de marquage CE à tous les produits comportant des éléments numériques vendus en Europe. Notre hypothèse basée sur le texte actuel est que ce processus sera appliqué aux logiciels open source mis à disposition sous des licences open source et fournis gratuitement, apparemment sous des licences qui déclinent toute responsabilité ou garantie. Nous sommes profondément préoccupés par le fait que le CRA pourrait modifier fondamentalement le contrat social qui sous-tend l'ensemble de l'écosystème open source : des logiciels open source fournis gratuitement, à toutes fins, qui peuvent être modifiés et redistribués gratuitement, mais sans garantie ni responsabilité envers les auteurs. , contributeurs ou distributeurs open source. On peut raisonnablement s'attendre à ce que la modification juridique de cet arrangement par voie législative ait des conséquences imprévues sur l'économie de l'innovation en Europe.

Sans une exemption plus claire pour l'open source, afin de se conformer à la législation, la Fondation Eclipse devra :

• Élaborer, documenter et mettre en œuvre des politiques et des procédures pour chaque projet de la Fondation Eclipse afin de s'assurer qu'elles sont conformes aux exigences du CRA notamment :
  
  • Toutes les exigences de développement et de sécurité après la publication énoncées à l'annexe I, y compris la fourniture de mécanismes de notification et de mise à jour.
  • Toutes les exigences relatives à la documentation de l'utilisateur énoncées à l'annexe II.
  • Toute la documentation technique du produit indiquée à l'annexe V, y compris "... des informations complètes sur la conception et le développement du produit ... y compris, le cas échéant, des dessins et des schémas et/ou une description de l'architecture du système expliquant comment les composants logiciels s'appuient sur ou s'alimentent mutuellement et s'intègrent dans le traitement global.
• Pour chaque version de projet EF, préparer la documentation spécifique au projet requise par l'annexe V, y compris "... une évaluation des risques de cybersécurité contre lesquels le produit avec des éléments numériques est conçu, développé, produit, livré et maintenu...".
• Déterminer pour chaque projet s'il répond à la définition de « produit avec éléments numériques », « produit critique avec éléments numériques » ou « produit hautement critique avec éléments numériques ».
  
  • Pour chaque projet qui est un "produit avec des éléments numériques", établir, compléter et documenter un processus d'auto-évaluation du marquage CE.
  • Pour chaque « produit critique avec éléments numériques » ou « produit hautement critique avec éléments numériques », s'engager avec un organisme d'audit CE externe et compléter les processus supplémentaires requis pour obtenir l'approbation du marquage CE. Notez que nous ne savons pas exactement quels seraient les coûts en temps, en ressources et en argent pour mettre en œuvre ces processus d'audit externe. Notre hypothèse est qu'ils seraient substantiels.
  • Il est également important de noter que dans la plupart des autres domaines réglementés par les marquages CE, ils sont effectués là où des normes, des spécifications et/ou des processus de certification bien connus sont en place. Ceux-ci ne sont pas en place pour la plupart des projets open source Eclipse Foundation. Cela pourrait augmenter considérablement les coûts et les risques associés à la conformité.
• Pour chaque version de projet, documenter que le processus de marquage CE pertinent consiste (comme décrit ci-dessus) en une déclaration de conformité UE rédigée et signée par un responsable de la fondation, puis le marquage CE est apposé et la documentation technique ainsi que la déclaration UE de conformité est mise à disposition pendant au moins 10 ans après la libération. Notez que nous estimons que chaque année, les projets de la Fondation Eclipse rendent disponibles plusieurs centaines de versions.

L'Open Source Initiative

L'Open Source Initiative (OSI) a soumis des commentaires à la Commission européenne demandant « des travaux supplémentaires sur l'exception Open Source aux exigences du corps de la loi ». L'OSI souhaite que la responsabilité de la conformité soit retirée à « tout acteur qui n'est pas un bénéficiaire commercial direct du déploiement ».

Simon Phipps, défenseur de l'open source et directeur de la norme OSI, a déclaré que la législation « pourrait nuire à l'open source » et que le texte actuel de la législation « causerait d'importants problèmes pour les logiciels open source », en partie à cause d'ambiguïtés dans le libellé, et en partie parce qu'il ne le fait pas, à savoir reconnaître « la manière dont les communautés open source fonctionnent réellement ».

Nous reconnaissons que la Commission européenne a formulé une exception au considérant 10 pour tenter de garantir que ces dispositions n'affectent pas accidentellement les logiciels Open Source. Cependant, en s'appuyant sur plus de deux décennies d'expérience, nous, à l'Open Source Initiative, pouvons clairement voir que le texte actuel causera des problèmes considérables pour les logiciels Open Source. Les problèmes proviennent d'ambiguïtés dans la formulation et d'un cadrage qui ne correspond pas au fonctionnement réel des communautés Open Source et à la motivation de leurs participants.

Premièrement, pour que ceux qui distribuent des logiciels en tant que fonction communautaire puissent compter en toute confiance sur l'exclusion, celle-ci doit absolument être insérée en tant qu'article et le « devrait » doit être remplacé par « doit ».

Deuxièmement, étant donné que l'objectif est - ou devrait être - d'éviter de nuire aux logiciels Open Source, que la Commission européenne s'efforce de soutenir, cet objectif doit être énoncé au début du paragraphe comme justification, en remplacement de la formulation d'introduction sur la prévention des dommages. à la « recherche et à l'innovation » pour éviter de trop restreindre l'exception.

Troisièmement, la référence à « non commercial » comme qualificatif devrait être remplacée. Le terme « commercial » a toujours conduit à une incertitude juridique pour les logiciels et est un terme qui ne devrait pas être appliqué dans le contexte de l'open source car les utilisations commerciales spécifiques des projets open source par certains utilisateurs sont fréquemment déconnectées des motivations et de la rémunération potentielle de la communauté plus large de mainteneurs. Le logiciel lui-même est donc indépendant de son application commerciale ultérieure. Le problème n'est pas l'absence d'une taxonomie de « commercial », c'est le fait même de rendre « commercial » la qualification plutôt que, par exemple, « déploiement pour le commerce ». Ainsi, l'ajout d'une taxonomie de la commercialité n'est pas une solution. L'OSI serait heureux de collaborer sur de meilleures approches pour qualifier une exception.

D'autres réactions

Olaf Kolkman, conseiller exécutif de l'Internet Society, a également exprimé ses inquiétudes en disant que « le règlement devrait être modifié pour indiquer clairement que les logiciels produits sous une licence open source et distribués à but non lucratif sont hors de portée du règlement ».

C'est une question complexe car l'utilisation de logiciels open source dans les « éléments numériques » des produits est monnaie courante.

Brian Fox, ancien président du projet Apache Maven et maintenant CTO et co-fondateur de la société devops Sonatype, a déclaré que la législation pourrait rendre « Central, npm, PyPi et d'innombrables autres dépôts soudainement inaccessibles à l'Union européenne, ce qui serait désastreux, tant pour l'UE que pour l'écosystème dans son ensemble. Dans le même temps, il a déclaré que le projet de loi est « par ailleurs [un] texte législatif très admirable qui vise à renforcer la posture de cybersécurité dans les produits numériques d'une manière plus avancée que nombre de ses homologues ».

La question est maintenant de savoir si l'UE peut préserver la bonne intention de la législation sans les conséquences désastreuses redoutées par la communauté open source.

Sources : Cyber Resilience Act, Eclipse Foundation (1, 2), Internet Society, SonaType, The Document Foundation

Et vous ?

Que pensez-vous de la proposition européenne sur la cyber-résilience notamment au niveau de ses objectifs annoncés ?
Comprenez-vous les craintes des acteurs de l'open source ?

[HaryRoseAndMac]

L'europe est entrain de sombrer dans un totalitarisme fou !

Il est plus que temps de mettre à un terme à la gouvernance de ces "dirigeants" qui n'en sont pas et de les faire destituer au plus vite.

[totozor]

[Sarcasme]C'est du génie:
1. On impose une règlementation que seuls les grands peuvent se payer (on assure le maintien de ceux qu'on condamne en façade)
2. En imposant cette règlementation, on impose une certification - que nous allons assurer (On fait entrer des sous dans les caisses pour un service que personne ne demande)
3. Ce surcout sera escaladé au consommateur (nous) mais c'est pas grave on fait ça pour leur bien, ils vont être content

Voici ce que nous appelons le capitalisme moderne : faire payer des gens un service qu'ils n'ont jamais demandé pour sa propre survie et sous couvert de leur bien

T'es pas d'accord, on s'en fout, on te demande pas ton avis[/Sarcasme]

[Mickael_Istria]

Pour mettre le feu au debat, je suis plutot favorable a cette idee dans le fond. Et pourtant je fais 100% de mon dev en open-source autour d'Eclipse et d'autres projets de la Fondation (donc dans les contraintes dont parle Mike Milinkovich).
En fait, l'informatique atteint un age tres mature, et -comme prevu- a conquis le monde. Et donc, on commence a voir que des mauvais logiciels sont des sources de problemes pour la societe (eg des ransomwares qui bloquent les hopitaux a cause de failles logicielles). Au meme titre que les tuyaux de gaz, les bitumes des routes, les prises electriques, le legiciel arrive a etre critique au point de pouvoir etre un danger pour l'utilisateur et la societe s'il est trop mal fait. Ca parait donc interessant qu'une entitie politique censee representer le peuple decide de s'interesser au sujet en demandant des contraintes ou certification de securite aux fournisseurs de logiciels. L'objectif final semble etre une plus grande securite logicielle pour les citoyens et la societe. Si on peut le faire, pourquoi pas?
Apres, pour l'open source, il reste la question de qui est le fournisseur: est-ce que le fournisseur est l'auteur du code ou le consommateur qui l'embarque dans son application finale (potentiellement commerciale)? Mon experience avec l'OSS c'est qu'en realite, l'auteur de code OSS ne prend pas la responsabilite en cas de problemes et qu'il s'agit d'un partage de code au niveau R&D et non produit, cela n'empeche pas l'OSS d'etre de qualite produit, mais cela n'est pas une garantie qui est offerte sans contrepartie aux consommateurs, et le fait que le code soit ouvert est cense permettre aux consommateurs d'etablir la confiance dont ils ont besoin et eventuellement de faire certifier ce dont ils ont besoin pour leur business (apres tout, c'est le consommateur qui y gagne plus que le fournisseur, c'est normal que ce soit lui qui prenne en charge les frais de mise sur le marche). Je pense qui Mike et autres essayent de faire du lobbying pour rendre cette interpretation explicite dans la proposition de loi.
La ou la fondation et/ou la communaute Eclipse a un positionnement bancal, qui predate a cette proposition mais qui pese tres lourd ici, c'est qu'elle a tendance a se croire pour un editeur: c'est une fondation OSS mais elle ne se content pas de faire de la collaboration projet comme le fait eg le projet Linux: la fondation Eclipse heberge des quasi-produits comme l'Eclipse IDE, Glassfish, Temurin... et a ce titre, en se comportant comme un fournisseur de logiciels finaux, elle l'est peut-etre un peu. Avec quelques autres collegues influents chez Eclipse, on se demande et on demande a la communaute Eclipse en general, si le modele de fournir des binaires aux utilisateurs n'est pas en soit un probleme. Rester au niveau "le projet met a dispo les sources, aux consommateurs de builder" comme le font Gnome ou le kernel Linux presente au final des avantages sur la responsabilisation des consommateurs vis-a-vis de l'open-source: en devant builder eux-memes, il devient clair qu'ils ont interet a contribuer, et qu'ils deviennent responsable de la qualite du resultat. Ca remet les choses au clair tant au niveau organisationnel qu'au niveau juridique.

Par contre, j'imagine que la proposition de loi en l'etat a de claires lacunes qui devront etre corrigees. Il est beaucoup plus dur d'ecrire une bonne loi que d'ecrire du code. Il est normal que des critiques soient fait pour proteger les bases du domaines, que la societe civile et la sphere politique n'ont pas forcement a leur connaissance immediate. Mais j'apprecie l'intention de cette proposition de loi.

[Mickael_Istria]

Et j'en rajoute une couche: de part le code source ouvert et accessible, l'open-source a en fait une avance certaine sur le code close-source. Il peut etre audite et certifie sans devoir creer de documentation technique intermediaire, il est naturellement plus securise de part son exposition a plus de lecteurs. Donc ce CRA pourrait meme etre un avantage competitif de l'OSS par rapport au code ferme.

[totozor]

J'aime ton point de vue mais je me pose des questions en tant que néophyte

Apres, pour l'open source, il reste la question de qui est le fournisseur: est-ce que le fournisseur est l'auteur du code ou le consommateur qui l'embarque dans son application finale (potentiellement commerciale)?[...]l'auteur de code OSS ne prend pas la responsabilite [...], cela n'empeche pas l'OSS d'etre de qualite produit, mais cela n'est pas une garantie[...] aux consommateurs, [...] permettre aux consommateurs d'etablir la confiance [...] de faire certifier

Désolé d'avoir haché le texte mais ça permet de mettre en avant ce qui me semble l'articulation de la reflexion.
Si je suis le consommateur de l'open source, je deviens le fournisseur d'un service couvert par la proposition.
Donc je vais être audité sur mon produit et je vais devoir justifier de la qualité de mon socle l'open source.
Et là il y a quelques choix :
- je t'imposes un audit pour me couvrir du risque que ton code représente
- je prends la responsabilité de l'analyse et de la garantie de la certification de ton code (ça coute et je ne vais probablement jamais accepter d'assumer ça)
- je te demande le certificat au moment où j'utilise ton code
- je n'utilise plus ton code et je vais payer un autre pour le service et le certificat

D'un point de vue capitaliste je ne gagne rien à payer pour la certification d'un produit récupérer.
Si je veux rendre ça "rentable" je t'achètes pour gagner le bénéfice de mon investissement.
Donc à la fin, on pousse (passivement) l'Open Source à disparaitre par impuissance face au système certificatif.

il devient clair qu'ils ont interet a contribuer, et qu'ils deviennent responsable de la qualite du resultat. Ca remet les choses au clair tant au niveau organisationnel qu'au niveau juridique.

Dans l'industrie, un risque on le tue (s'il est technique on s'assure de le faire disparaitre), on le transfert (technique de la patate chaude) ou on l'assure (je paye une assurance qui payera à ma place le jour où il s'avère).
Si le fonctionnement est identique, je n'ai pas intérêt à prendre en charge le risque lié au travail d'un autre (sauf s'il est tellement petit que ça ne me coute - virtuellement - rien)

Il peut etre audite et certifie sans devoir creer de documentation technique intermediaire, il est naturellement plus securise de part son exposition a plus de lecteurs. Donc ce CRA pourrait meme etre un avantage competitif de l'OSS par rapport au code ferme.

Dans l'industrie un auditeur ne certifiera (il prend une responsabilité juridique quand il le fait) jamais un objet s'il n'est pas décrit par une doc technique.
Les auditeurs que j'ai croisé n'aiment pas ce qui est naturel, ils aiment ce qui est écrit.
Il y a pas longtemps on s'est fait épinglé parce qu'un opérateur ne respectait pas la procédure mais avait une attitude plus sécurisante qu'elle. (Ce n'est pas l'opérateur qui se fait épingler mais le responsable de la procédure)

[denisys]

Il devient de plus en plus urgent, de ce débarrassé de la dictature de l'Union européenne !!!!

[irrmichael]

Donc si je développe des jeux, je vais devoir faire certifier mon code? payer des centaines d'euros pour ça? J'espère que Unity va assumer le CE

[leyouki]

Une bonne âme pourrait pointer le rapport cité de synopsys sur la part de logiciel libre dans l'économie numérique actuelle ? Je ne le trouve pas. 🙏

[leyouki]

Une bonne âme pourrait pointer le rapport cité de synopsys sur la part de logiciel libre dans l'économie numérique actuelle ? Je ne le trouve pas. 🙏

Le rapport est présenté ici: https://www.synopsys.com/software-in...-analysis.html
et téléchargeable là: https://www.synopsys.com/content/dam...ossra-2023.pdf

[juju26]

Bonjour,
Cela concerne quel type de logiciels / application ?
Parce que le risque de sécurité n'est certainement pas le même entre un jeux, un logiciel lamba en local (qui ne fait pas office de serveur), un pare-feu... ou encore une application en ligne...
Je n'ai pas trouvé de détails sur ce point.
Encore des lois usine à gaz qui impacteront uniquement les dev européens...

[Stéphane le calme]

Loi européenne sur la cyber-résilience : qu'est-ce que cela signifie pour l'écosystème open source ?
Un développeur analyse le nouveau texte du projet de loi

Le 20 décembre, le Comité des Représentants Permanents a confirmé l'accord sur le texte de compromis du projet de loi Cyber Resilience Act (CRA). Quelle est la portée de ces modifications sur les fournisseurs de logiciel open source ? Qu'en est-il des utilisateurs open source ? Analyse des implications pour le logiciel libre et open source (FOSS) du point de vue d'un développeur.

L'Europe part d'un constat :

Les produits matériels et logiciels font de plus en plus l'objet de cyberattaques réussies, entraînant un coût annuel mondial estimé de la cybercriminalité à 5 500 milliards d'euros en 2021.

Ces produits souffrent de deux problèmes majeurs qui augmentent les coûts pour les utilisateurs et la société :

1. un faible niveau de cybersécurité, reflété par des vulnérabilités généralisées et la fourniture insuffisante et incohérente de mises à jour de sécurité pour y remédier, et
2. une compréhension et un accès insuffisants aux informations par les utilisateurs, les empêchant de choisir des produits dotés de propriétés de cybersécurité adéquates ou de les utiliser de manière sécurisée.

Alors que la législation existante sur le marché intérieur s'applique à certains produits contenant des éléments numériques, la plupart des produits matériels et logiciels ne sont actuellement couverts par aucune législation de l'UE traitant de leur cybersécurité. En particulier, le cadre juridique actuel de l'UE ne traite pas de la cybersécurité des logiciels non embarqués, même si les attaques de cybersécurité ciblent de plus en plus les vulnérabilités de ces produits, entraînant des coûts sociétaux et économiques importants.

Deux objectifs principaux ont été identifiés visant à assurer le bon fonctionnement du marché intérieur :

1. créer les conditions pour le développement de produits sécurisés avec des éléments numériques en veillant à ce que les produits matériels et logiciels soient mis sur le marché avec moins de vulnérabilités et en veillant à ce que les fabricants prennent la sécurité au sérieux tout au long du cycle de vie d'un produit ; et
2. créer des conditions permettant aux utilisateurs de prendre en compte la cybersécurité lors de la sélection et de l'utilisation de produits comportant des éléments numériques.

Élaboré sur la base de la stratégie de cybersécurité de l’UE de 2020, le CRA (Cyber Resilience Act) introduit des règles communes en matière de cybersécurité pour les fabricants et les développeurs de produits comportant des éléments numériques, couvrant à la fois le matériel et les logiciels. L’objectif de ce texte est de protéger les consommateurs et les entreprises des risques en matière de cybersécurité dans leur utilisation des matériels filaires et connectés, ainsi que des logiciels.

Le 15 septembre 2022, la Commission a présenté un premier projet qui a été soumis à l’examen du Parlement européen et du Conseil. Le 1^er décembre 2023, Bruxelles que le Parlement européen et le Conseil étaient parvenus la veille à un accord sur la loi. Puis, le 20 décembre, le Comité des Représentants Permanents a confirmé l'accord sur le texte de compromis du projet de loi CRA.

La portée de ces modifications sur les fournisseurs de logiciel open source

Dans sa section 10, le texte traite principalement de l'open source. Voici une analyse du développeur Bert Hubert

L'activité commerciale, comment est-elle définie ?

Le CRA réglemente l'activité commerciale : « (10) Le présent règlement s'applique aux opérateurs économiques uniquement en ce qui concerne les produits comportant des éléments numériques mis à disposition sur le marché, donc fournis pour être distribués ou utilisés sur le marché de l'Union dans le cadre d'une activité commerciale ».

C’est un début encourageant pour l’open source. Si quelqu’un souhaite que le CRA réglemente les auteurs ou les entreprises open source, il doit d’abord établir que ce que vous faites est une « activité commerciale ». Or, les versions antérieures du CRA ne fournissaient pas de grandes indications sur ce qu’est une activité commerciale. Il y avait des inquiétudes justifiées quant au fait que si quelqu’un faisait suffisamment d’efforts, il pourrait prétendre que l’open source était aussi une « activité commerciale ».

Le CRA est très clair sur le fait que ce n’est pas uniquement une question d’argent. Par exemple, si vous essayez de faire « payer avec leurs données » aux utilisateurs comme condition d’utilisation de votre produit, c’est commercial. Ou, si vous associez votre produit open source à des services payants*:

• (10) une intention de monétiser, par exemple en fournissant une plate-forme logicielle à travers laquelle le fabricant monétise d'autres services, en exigeant comme condition d'utilisation le traitement des données à caractère personnel pour des raisons autres que exclusivement l'amélioration de la sécurité, de la compatibilité ou de l'interopérabilité du logiciel, ou en acceptant des dons dépassant les coûts associés à la conception, au développement et à la fourniture d'un produit comportant des éléments numériques.

N'est pas considéré comme une activité commerciale...

Dans le compromis final sur le CRA, de nombreuses précisions ont été ajoutées. Par exemple :

• (10c) .. la fourniture de produits logiciels gratuits et à source ouverte qui ne sont pas monétisés par leurs fabricants n'est pas considérée comme une activité commerciale.
• (10c) Le présent règlement ne s'applique pas aux personnes physiques ou morales qui contribuent au code source de produits gratuits et open source qui ne relèvent pas de leur responsabilité.

Donc si vous ne « monétisez » pas votre produit open source, vous pouvez arrêter de lire ici, le CRA ne s'applique pas à vous. Et si vous soumettez des PR, du code ou des correctifs à l’open source d’autres personnes, vous êtes également complètement tranquilles, peu importe ce qu’ils font.

Que se passe-t-il si quelqu'un vous soutient avec de l'argent, du matériel ou du code :

• (10c) le simple fait qu'un produit logiciel open source reçoive un soutien financier de la part des fabricants ou que les fabricants contribuent au développement d'un tel produit ne devrait pas en soi déterminer que l'activité est de nature commerciale.
• (10) L'acceptation de dons sans intention de réaliser un profit ne devrait pas être considérée comme une activité commerciale.

Que se passe-t-il si vous publiez régulièrement des versions logicielles sur lesquelles les gens comptent :

• (10c) En outre, la simple présence de rejets réguliers ne permet pas en soi de conclure qu'un produit est fourni dans le cadre d'une activité commerciale.

Que se passe-t-il si vous êtes une organisation open source à but non lucratif qui reçoit de l'argent (pour le développement) ?

• (10c). Aux fins du présent règlement, le développement de produits qualifiés de logiciels libres et open source par des organisations à but non lucratif ne devrait pas être considéré comme une activité commerciale pour autant que l'organisation soit créée de manière à veiller à ce que tous les bénéfices après coûts soient utilisés pour atteindre des objectifs à but non lucratif.

Que se passe-t-il si vous êtes une fondation open source à but non lucratif et que quelqu'un vous paie pour un support technique réel pour votre produit open source ?

• (10) La fourniture dans le cadre d'une activité commerciale peut être caractérisée non seulement par la facturation d'un prix pour un produit, mais également par la facturation de services d'assistance technique lorsque cela ne sert pas uniquement à récupérer les coûts réels.

Et si vous aviez acheté un produit provenant d'une entreprise très commerciale financée par du capital-risque, de sorte que le produit ait un historique commercial :

• (10c)Les simples circonstances dans lesquelles le produit a été développé, ni la manière dont le développement a été financé, ne devraient donc pas être prises en compte pour déterminer la nature commerciale ou non commerciale de cette activité.

Que se passe-t-il s’il y a des utilisateurs très commerciaux de votre open source qui gagnent de l’argent avec votre truc ?

• (10c) En outre, la fourniture de produits qualifiés de composants logiciels libres et à code source ouvert destinés à être intégrés par d'autres fabricants dans leurs propres produits ne devrait être considérée comme une mise à disposition sur le marché que si le composant est monétisé par son fabricant d'origine.

Que se passe-t-il si vous êtes une distribution Linux (comme Debian) hébergeant des tonnes d’open source d’autres personnes :

• (10e) Le seul fait d'héberger des produits sur des référentiels ouverts, y compris via des gestionnaires de packages ou sur des plateformes de collaboration, ne constitue pas en soi la mise à disposition sur le marché d'un produit comportant des éléments numériques.

Compte tenu de tout cela, presque tous les projets open source actuels devraient être épargnés. Il y a cependant des difficultés pour ceux qui réalisent des projets de « fauxpen source », ou pour ceux qui font des ventes commerciales régulières de choses fournies avec la source.

Qu’en est-il des utilisateurs open source ?

Le CRA reconnaît que les logiciels, ouverts ou fermés, sont constitués de composants et de bibliothèques, et elle a de beaux mots sur qui en est responsable : les personnes qui mettent les logiciels à disposition sur le marché dans le cadre d'une activité commerciale.

Mais la responsabilité s'arrête là : si quelqu'un utilise le logiciel open source dont vous êtes l'auteur, vous n'êtes en aucun cas responsable de son utilisation commerciale. Les personnes qui intègrent vos contenus doivent faire preuve de leur propre diligence raisonnable :

• (18 bis) Lors de l'intégration de composants provenant de tiers dans des produits pendant la phase de conception et de développement, afin de garantir que les produits sont conçus, développés et fabriqués conformément aux exigences essentielles prévues à l'annexe I du présent règlement, les fabricants devraient exercer une diligence raisonnable à l’égard de ces composants, y compris les composants logiciels libres et open source qui n’ont pas été mis à disposition sur le marché.

Cette posture contraste avec un précédent texte que dénonçait la Python Software Foundation. En effet, de nombreux éditeurs de logiciels modernes s'appuient sur des logiciels open source provenant de dépôts publics sans en avertir l'auteur, et certainement sans entrer dans une quelconque relation commerciale ou contractuelle avec lui. L'ancienne version indiquait que les auteurs de composants open source pourraient être légalement et financièrement responsables de la manière dont leurs composants sont appliqués dans le produit commercial d'un tiers.

Selon la Python Software Foundation, ce texte-là ne faisait aucune différence entre les auteurs indépendants qui n'ont jamais été payés pour la fourniture de logiciels et les grandes enseigne de la technologie qui vendent des produits en échange de paiements de la part des utilisateurs finaux. « Nous pensons que la responsabilité accrue devrait être soigneusement attribuée à l'entité qui a conclu un accord avec le consommateur. Nous nous joignons à nos collègues européens de la Fondation Eclipse et de NLnet Labs pour exprimer nos inquiétudes sur la manière dont ces politiques pourraient affecter les projets open source mondiaux. »

Quoiqu'il en soit, il est intéressant de noter que dans le cadre de cette diligence raisonnable, les intégrateurs (et les gouvernements !) pourraient initier ou sponsoriser des « attestations » du niveau de sécurité des composants open source. Ce serait un grand coup de pouce pour la sécurité open source :

• (10f) Les programmes d'attestation de sécurité devraient être conçus de telle manière que non seulement les personnes morales ou physiques développant ou contribuant au développement d'un produit qualifié de logiciel libre et à code source ouvert puissent initier ou financer une attestation, mais également des tiers, comme les fabricants qui intègrent de tels produits dans leurs propres produits, les utilisateurs ou encore les administrations publiques européennes et nationales.

Quelques éléments spécifiques sur la déclaration Debian

La déclaration Debian semble être basée sur une version antérieure du CRA.

Il est indiqué par exemple : «*Savoir si un logiciel est commercial ou non n'est pas réalisable, ni dans Debian ni dans la plupart des projets de logiciels libres*». En vertu de le CRA, il n'est pas nécessaire de comprendre cela pour Debian.

« Devoir obtenir des conseils juridiques avant de faire un cadeau à la société découragera de nombreux développeurs » - la version finale de le CRA est claire : si vous faites un cadeau, la CRA ne s'applique en aucun cas à vous. Il existe désormais une déclaration très claire à ce sujet.

« Imposer des exigences telles que celles proposées dans la loi rend juridiquement périlleux la redistribution de notre travail par d'autres » - le CRA a maintenant des notes spécifiques indiquant qu'une telle redistribution n'est pas couverte.

Aussi, Bert Hubert a déclaré « J'espère que le projet Debian le plus génial pourra examiner attentivement ce que dit la version actuelle du CRA, et peut-être proposer une nouvelle déclaration ».

Conclusion

Tout au long du processus CRA, divers instituts de l’UE et gouvernements des États membres ont été très réceptifs aux opinions de la communauté open source. De plus, le CRA crée virtuellement un nouveau processus par lequel l'industrie peut se réunir pour parrainer des documents de sécurité, des attestations, des audits ou même des travaux de sécurité sur des produits open source. La Commission européenne est habilitée à créer des modèles et des réglementations pour de telles procédures, et la contribution de la communauté open source serait sûrement utile pour en faire un succès.

Pour Bert Hubert, « si nous jouons bien les choses, l’open source pourrait enfin obtenir le soutien de l’industrie, car le CRA signifie que les personnes qui intègrent notre travail en sont désormais officiellement responsables ».

Source : EU Cyber Resilience Act, Bert Hubert

Et vous ?

Que pensez-vous de l'analyse de Bert Hubert ?
Vous semble-t-il y avoir des améliorations dans le projet de loi CRA par rapport à l'industrie de l'open source ? Dans quelle mesure ?
De façon plus générale, quelles en sont les implications pour les développeurs et les professionnels de l'informatique ?

[bdr443]

J'ai l'impression qu eles législateurs sont totalement déconnectés de la réalité et ont fait voter des lois sur des sujets qu'ils le maîtrisent pas.

[totozor]

J'ai l'impression qu eles législateurs sont totalement déconnectés de la réalité et ont fait voter des lois sur des sujets qu'ils le maîtrisent pas.

N'est ce pas une sorte de vérité générale depuis quelques années?
Combien de ministres/députés travaillent dans un domaine dans lequel ils ont travaillé/fait leurs preuves/se sont dûment renseignés?
Et même quand c'est le cas ils travaillent en général sur des acquis devenus obsolètes, alors quand on parle d'un domaine qui évolue rapidement...
Mais ces gens sont supérieurement intelligents donc pourquoi auraient ils besoin de s'informer auprès de sachants?

[Jade Emy]

La loi européenne sur la cyber-résilience comprend des avancées pour l'Open Source, selon la Python Software Foundation.

Auparavant, la Python Software Foundation était inquiète sur la loi européenne sur la cyber-résilience (CRA). Depuis l'évolution du texte, la PSF déclare que la loi européenne sur la cyber-résilience est adoptée avec des gains pour l'Open Source.

En avril dernier, la Python Software Foundation a écrit à la communauté pour lui faire part de ses inquiétudes quant à l'avenir de l'écosystème open source en général, et de CPython et PyPI en particulier, si la loi européenne sur la cyber-résilience (CRA) devait être adoptée sous la forme qui avait été communiquée. À l'époque, la PSF craignait qu'en fournissant des logiciels que tout le monde peut utiliser, analyser ou modifier, la PSF et/ou la communauté Python ne deviennent légalement responsables des problèmes de sécurité dans les produits construits avec les composants de code fournis gratuitement. La PSF a demandé plus de clarté, en particulier :

"Une formulation qui exempte spécifiquement les dépôts de logiciels publics qui sont offerts comme un bien public dans le but de faciliter la collaboration rendrait les choses beaucoup plus claires. Nous aimerions également que notre communauté, en particulier les amateurs, les particuliers et les autres entités disposant de peu de ressources qui hébergent des paquets sur des dépôts publics gratuits tels que PyPI, soit exemptée".

La bonne nouvelle, c'est que le texte de la CRA a beaucoup évolué entre le moment où la communauté open source - y compris la PSF - a commencé à exprimer ses préoccupations et le texte final de la loi, qui a été entériné le 1er décembre. Ce texte introduit l'idée d'un "gestionnaire open-source".

L'expression "gestionnaire de logiciels open-source" désigne toute personne morale, autre qu'un fabricant, dont le but ou l'objectif est de fournir systématiquement et durablement un soutien au développement de produits spécifiques comportant des éléments numériques qualifiés de logiciels libres, destinés à des activités commerciales, et d'assurer la viabilité de ces produits ;" (p. 76)

En outre, le texte final démontre une meilleure compréhension du fonctionnement des logiciels libres et de la valeur qu'ils apportent à l'écosystème global du développement de logiciels.

"Plus spécifiquement, aux fins du présent règlement et en ce qui concerne les opérateurs économiques qui y sont visés, afin de garantir une distinction claire entre les phases de développement et de fourniture, la fourniture de produits logiciels gratuits et open-source comportant des éléments numériques qui ne sont pas monétisés par leurs fabricants n'est pas considérée comme une activité commerciale." (p. 10)

Est-que la PSF a fini avec la législation européenne ? Ah, bien qu'il serait agréable pour la communauté Python de pouvoir rayer quelques points de sa liste de choses à faire, ce n'est pas tout à fait comme ça que ça fonctionne. Tout d'abord, le concept de "gestionnaire open-source" est une idée toute nouvelle dans la législation européenne. La PSF suivra donc la conversation au fur et à mesure que ce nouveau concept sera mis en œuvre ou interagira avec d'autres éléments de la législation européenne afin de s'assurer que la compréhension continue de refléter l'intention et les réalités du développement de l'open-source. Deuxièmement, d'autres textes législatifs sont en cours d'élaboration et pourraient également avoir un impact sur l'écosystème Python. La PSF surveillera donc la directive sur la responsabilité du fait des produits et suivrons les discussions sur les brevets essentiels pour s'assurer que les effets sur Python et le développement open-source sont intentionnels (et, bienveillants, ou tout au moins bénins).

La PSF remerci Open Forum Europe (OFE) - en particulier à Ciarán O'Riordan - d'avoir rassemblé la communauté du logiciel libre pour partager ses idées sur la manière dont le texte proposé affecterait le logiciel libre, en réfléchissant à la manière dont les objectifs de l'acte proposé pourraient être atteints sans créer involontairement un effet paralysant pour l'open-source et en communiquant ces idées aux législateurs. Le travail de l'OFE pour coordonner les efforts a certainement facilité l'écoute des préoccupations de la FSP et il a été plus facile pour les législateurs d'évaluer et de prendre en compte les impacts sur l'écosystème open source lorsqu'ils ont pu parler d'une seule voix.

L'intégralité du règlement est publiée ici, si vous souhaitez approfondir le texte.

Source : Python Software Foundation

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

Loi européenne sur la cyber-résilience : qu'est-ce que cela signifie pour l'écosystème open source ? Un développeur analyse le nouveau texte du projet de loi

Debian affirme que la loi européenne sur la cyber-résilience pourrait provoquer la disparition de plusieurs petits projets de logiciels libres dont dépendent de nombreuses distributions Linux

La proposition européenne de loi sur la cyber-résilience, une menace pour l'open source ? Oui, selon des acteurs qui indiquent que son application pourrait avoir un impact désastreux