Le Cyber Resilience Act ou CRA est un sujet qui a déjà été évoqué sur ces pages.
Il s’agit d’un projet de directive qui a pour objectif louable d’améliorer la cybersécurité des produits numériques en Europe. Cependant, c’est un texte “buggé” qui va faire l’objet d’un vote crucial cette semaine, le 19 juillet, au sein du comité ITRE du Parlement européen, et qui pourrait être adopté dans la foulée, sans vote en session plénière, par le Parlement lui-même. Si rien de change d’ici son adoption finale, il aura des conséquences particulièrement lourdes pour les petites et moyennes entreprises (PME) évoluant dans le domaine du logiciel libre, et plus généralement sur la filière du logiciel libre, une composante essentielle de l’économie numérique européenne.
Quels sont les principaux problèmes que pose le texte du comité ITRE pour la filière européenne du logiciel libre ?
Nous en discutons de manière plus détaillée dans cette dépêche, qui reprend, en très grande partie, un communiqué du CNLL.
Sommaire
- Quels sont les principaux problèmes que pose le texte du comité ITRE pour la filière européenne du logiciel libre ?
- Comment réagir à ce stade ?
- Annexe: Chronologie des événements
Quels sont les principaux problèmes que pose le texte du comité ITRE pour la filière européenne du logiciel libre ?
Le CRA va imposer des exigences administratives et techniques très coûteuses pour les organisations qui diffusent des produits ou des services logiciels ou contenant des logiciels. Elles devront notamment développer, documenter et mettre en œuvre des politiques et des procédures pour chaque projet, préparer une documentation technique pour chaque version de produit et suivre un processus complexe de marquage CE. L’étude d’impact de la Commission estime à 30% l’augmentation des coûts de développement pour les PME, ce qui est largement supérieur aux marges habituellement constatées dans le secteur. En cas de non-respect de ces obligations, les PME sont passibles d’une amende de 15 millions d’euros.
Les logiciels libres sont, par définition, des logiciels diffusés sous une licence de logiciel libre (ou open source, ce qui revient essentiellement au même). Toutes les licences de logiciel libre en usage actuellement comprennent une clause de non-responsabilité: il est en effet logique qu’un individu, une entreprise, petite ou grande, une fondation, un institut de recherche, etc. ne tiennent pas à être tenu à une responsabilité (lorsqu’il n’y a pas une volonté délibérée de nuire) quand il ou elle offre, gratuitement, le fruit de son travail en tant que bien commun au reste de l’humanité. En parallèle, les éditeurs de logiciels libres n’ont pas attendu le CRA pour proposer à leurs clients des contrats où ils s’engagent à assurer la maintenance de leurs logiciels libres, contre une rémunération, qui couvre les frais de maintenance mais aussi les frais de R&D nécessaire à la création et à l’évolution de ces logiciels.
Dans le texte d’origine de la Commission, le CRA comprend une exemption pour les « activités non-commerciales », dont les représentants de l’écosystème open source ont souligné, dès la publication du projet de texte initial, l’ambiguïté et les risques que celle-ci représente.
Selon le projet de texte actuel du comité ITRE, dont des éléments ont été publiés par GitHub la semaine dernière, tout projet de logiciel libre qui compte parmi ses contributeurs des employés d’une entreprise est considéré comme une activité commerciale. Cette définition élargie englobe presque tous les projets de logiciels libres significatifs, avec des conséquences potentiellement dévastatrices. Non seulement cela inciterait les projets, dont on sait que certains ont des difficultés à assurer leur durabilité financière, à refuser les contributions de sociétés utilisatrices de leurs logiciels, mais cela pourrait également conduire les entreprises à interdire à leurs employés de participer à des projets de logiciel libre. Cela inciterait également les entreprises de la filière du logiciel libre à cesser de publier leurs composants en open source, à rendre moins transparentes leurs pratiques de développement, et à renoncer à contribuer à des projets de logiciels libres lorsque ceux-ci ne rentrent pas dans les exceptions, très restrictives, prévues par le texte.
Par ailleurs, le texte du comité ITRE dispose que tout projet de logiciel libre acceptant des donations récurrentes de la part d’entités commerciales est considéré comme une activité commerciale. Cela représente un risque majeur pour la pérennité des projets de logiciel libre qui servent de briques de base aux produits que les PME du logiciel libre mettent sur le marché. En effet, la durabilité financière de ces projets open source est un défi maintes fois évoqué et largement reconnu. Les donations régulières provenant d’entités commerciales sont souvent une source de financement essentielle qui permet aux projets de continuer leur travail. Cependant, si le CRA est adopté en l’état, ces projets seront incités à refuser les donations, et donc voir leurs ressources limitées strictement au bénévolat, ce qui va à l’encontre de la volonté affichée par ailleurs d’améliorer leur durabilité financière. L’impact négatif se propagera en aval de tous ces projets, avec comme conséquence systémique un affaiblissement de la sécurité globale des produits mis sur le marché en Europe, en plus de la disruption de la chaîne d’approvisionnement logicielle des éditeurs de logiciels européens.
Enfin, notons que la filière du logiciel libre, au-delà des PME qui la composent principalement, est un secteur économique majeur pour l’Europe. Elle contribue à l’économie de l’UE à hauteur de 65 à 95 milliards d’euros par an, selon l’étude de la Commission de 2021, et est au cœur de la recherche et développement dans de nombreux domaines technologiques avancés, y compris du programme de R&D Horizon Europe. L’impact du CRA sur cette filière risque donc d’avoir des conséquences bien au-delà des entreprises directement concernées.
Le CNLL appelle donc les législateurs européens à prendre en compte ces enjeux, et à réviser le CRA de manière à protéger la filière du logiciel libre, et notamment les PME qui en sont le socle, sans pour autant compromettre l’objectif de renforcement de la cybersécurité.
À l’avenir, ce type de réglementation devra être élaboré en concertation étroite avec les acteurs de l’écosystème open source, y compris les entreprises européennes qui développement des logiciels libres et celles qui intègrent des composants open source dans leurs produits, les plus à même de comprendre et d’expliquer les spécificités et les enjeux de leur secteur. L'APELL (Association Professionnelle Européenne du Logiciel Libre), qui fédère les associations nationales d’entreprises du libre en Europe, doit être un interlocuteur privilégié des institutions européennes sur ces questions, tout comme le CNLL auprès du gouvernement français. Nous appelons également à la création au sein de la Commission d’un OSPO (Open Source Programme Office) externe, focalisé sur le développement de la filière du logiciel libre en Europe, qui devra travailler en étroite collaboration avec OSOR, l’OSPO interne de la Commission, et apporter son expertise lors des initiatives législatives à venir qui concerneront le logiciel libre.
Enfin, nous devons collectivement favoriser une meilleure compréhension, au sein de nos institutions, des enjeux du numérique ouvert et des dynamiques technologiques et économiques complexes qui caractérisent l’écosystème du logiciel libre. Cela passe par une formation renforcée des décideurs politiques sur ces questions, mais aussi par une meilleure prise en compte de l’expertise technologique interne et externe dans les processus décisionnels.
Comment réagir à ce stade ?
Compte-tenu de l’urgence de la situation, il faut contacter les eurodéputé(es) membres du comité ITRE en leur expliquant l’importance de préserver la dynamique de l’écosystème du logiciel libre pour l’indépendance technologique et économique européenne dans le domaine du numérique.
Annexe: Chronologie des événements
- Sept. 2022: La Commission publie sa proposition de directive. L’écosystème du logiciel libre n’a pas été consulté en amont.
- Oct.-Nov. 2022: Plusieurs organisations constatent et rapportent les ambiguïtés du texte initial, dont l’Internet Society et NLNet Labs
- Déc. 2022: La Commission organise à Bruxelles une série d’ateliers: "Open Source workshops for computing and sustainability", auxquels sont invités de nombreux experts et représentant de la filière du logiciel libre européenne. Le CRA ne fait pas partie des sujets à l’ordre du jour. Les fonctionnaires responsables du CRA au sein de la Commission ne sont pas impliqués dans ces ateliers.
- Jan.-Fév. 2023: L’APELL obtient un RDV avec la Commission pour discuter du développement de la filière et de la menace que représente potentiellement le CRA. Ce RDV est repoussé deux fois, la deuxième sine die.
- Avril 2023: Une lettre ouverte, co-signée par de nombreuses organisations représentatives de l’écosystème du logiciel libre européen, est adressée aux eurodéputés, aux membres du Conseil et aux représentants de la Commission.
- Avril 2023: L’APELL demande un RDV auprès de Thierry Breton. Sans réponse.
- Mai 2023: L’APELL demande un RDV auprès des fonctionnaires responsables du CRA au sein de la Commission (unité H2). Sans réponse.
- Mai 2023: La Commission organise un webinaire pour « expliquer le CRA aux PME ». Le sujet du logiciel libre, soulevé par les participants, est jugé inapproprié par les représentants de la Commission, qui promettent néanmoins qu’il n’y a pas lieu de s’inquiéter.
- Juin 2023: Le comité IMCO votes des amendements qui permettent de clarifier le texte originel dans un sens qui préserve l’écosystème du logiciel libre. Hélas, ces amendements ne sont pas recevables, car ils ne relèvent pas de la compétence du comité IMCO.
- Juillet 2023: Le comité ITRE s’apprête à voter ses amendements. Le texte fuite et provoque la sidération de l’écosystème du logiciel libre.
- Fin juillet 2023: Le Conseil arrêtera probablement sa position.
- Sept. 2023: Début du trilogue entre la Commission, le Parlement et le Conseil.
- Début 2024: Le texte sera probablement adopté définitivement.
Aller plus loin
- Le communiqué sur le site du CNLL (66 clics)
- La dépêche précédente sur le CRA (43 clics)
- Blog post de GitHub (55 clics)
- Blog post de Mozilla (61 clics)
# Le problème est-il dans l'énoncé ?
Posté par Pinaraf . Évalué à 6.
Hé ben, il faudrait peut-être commencer par là ? Les prix sont-ils maintenus artificiellement bas par l'exploitation d'une armée de développeurs de composants libres récupérés par des pillards dans le but de les commercialiser ?
Note, j'entends bien que la licence permette ce pillage, et que pour les développeurs à la base, ce soit un objectif entendu. Mais il est plus que temps de cesser de se voiler la face, le monde de l'informatique est merdique avec une fuite complète de leurs responsabilités par les éditeurs. Dans tous les autres corps d'ingénierie, l'entreprise est responsable (de ses ponts, trains, voitures, avions…). Alors pourquoi est-ce-que dans l'informatique on jette un pudique voile d'irresponsabilité avec une licence ?
Pour revenir sur le projet de loi :
Mais heureusement, sinon la solution est évidente : créer un projet bidon à côté, y coller tout le code, et avoir une entité en face qui le commercialise. Et qui s'appeleriot Android, comme disait la pub.
Donc oui, tel qu'il est défini actuellement, ce projet est problématique, mais il est quasi impossible de différencier un vrai projet libre (par exemple PostgreSQL) d'une coquille pour entreprise peu scrupuleuse (Android/AOSP). Je n'ai pas la réponse à cette question, je ne sait pas comment une jurisprudence pourrait s'établir là dessus…
[^] # Re: Le problème est-il dans l'énoncé ?
Posté par Stefane Fermigier (site web personnel) . Évalué à 4.
Un vrai projet de logiciel libres est un projet qui vise à produire un logiciel qui est vraiment libre, autrement dit qui est sous licence libre, autrement dit une licence qui respecte les libertés définies par la FSF ou l'OSI.
Après il y a des projets de logiciels libres qui sont plus ou moins collaboratifs. Certains auteurs de logiciels libres préfèrent décider seuls des patches qu'ils acceptent, voir refusent par avance les patches, faute de temps pour les traîter.
Donc tu veux que les auteurs de logiciels libres, en plus de se faire "piller" (selon tes termes, personnellement je pense qu'il faut chercher à développer des mécanismes qui permettent une meilleure répartition des revenus au sein de la chaîne d'approvisionnement logicielle), soient soumis à une responsabilité sur les logiciels qu'ils développent ?
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Le problème est-il dans l'énoncé ?
Posté par Astaoth . Évalué à 5.
Je n'ai pas lu l'ensemble du communiqué du CNLL, mais cette phrase me laisse perplexe : tu veux dire qu'actuellement ce n'est pas le cas ?
Donc mettons, je fais une app qui devient populaire mais qui traite des données de l'utilisateur, et que je diffuse sous licence libre. Si dedans j'inclue une bibliothèque vérolée volontairement ou non qui va voler les données des utilisateurs, en l'état actuel, je ne peux pas en être tenu pour responsable ?
Emacs le fait depuis 30 ans.
[^] # Re: Le problème est-il dans l'énoncé ?
Posté par Pinaraf . Évalué à 3.
Le cas des données personnelles est différent à cause du RGPD, si je ne m'abuse, même si là je pense que tu tombes dans un «trou» réglementaire, ce serait à un juge de déclarer si tu es coupable ou non (bon courage à lui).
Ce projet de loi va plus loin en incluant les conséquences possibles en cyber-sécurité.
Imaginons qu'une entreprise vende un logiciel de stockage de mots de passe, et que, oops, ça se fait trouer et les mots de passe partent dans la nature. Aujourd'hui, l'entreprise peut se cacher derrière la licence (sauf à démontrer une faute grave, à nouveau, bon courage), alors qu'avec ce projet de loi il y aura une obligation de moyens minimale pour la sécurité. Est-ce-que ça supprimerait tous les problèmes de sécurité ? Bien sûr que non. Mais quand on se prend une faille de type log4j ou heartbleed, la moindre des choses c'est que les entreprises les utilisant mettent à jour promptement.
[^] # Re: Le problème est-il dans l'énoncé ?
Posté par Stefane Fermigier (site web personnel) . Évalué à 8.
Modifions légèrement ton exemple: tu as écrit une application qui devient populaire, que tu diffuses sous licence libre, puis tu passes à autre chose, et 10 ans après quelqu'un trouve une faille de sécurité. Tu n'as plus le temps de t'en occuper, tu laisses filer, et là tu te retrouve passible d'une amende de 15 millions d'euros.
A contrario, si tu fabriques sciemment un malware, sous licence libre ou pas, il est tout à fait normal que tu sois tenu pour responsable, même si la licence t'exonère de toute responsabilité. C'est dejà le cas, AFAICT, pour le droit européen.
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Le problème est-il dans l'énoncé ?
Posté par Astaoth . Évalué à 2. Dernière modification le 20 juillet 2023 à 09:29.
Je vois, merci pour l'explication. Il semble assez dur de trouver un juste milieu entre ce cas, et celui pris par Pinaraf.
Mais si j'ai bien compris le communiqué du CNLL, dans le cas donné ici, c'est une app développé sans entreprise derrière, donc la clause de responsabilité ne s'applique pas.
Emacs le fait depuis 30 ans.
[^] # Re: Le problème est-il dans l'énoncé ?
Posté par Alex G. . Évalué à 4.
Pour moi ce serait pourtant simple: soumettre aux obligations celui qui vend le logiciel, pas celui qui l'a produit (après à celui qui vend un logiciel tiers de s'assurer que les obligations seront tenu).
[^] # Re: Le problème est-il dans l'énoncé ?
Posté par Pinaraf . Évalué à -1.
Donc tu veux que Google soit irresponsable pour le tas de hack qu'est Android ?
Et tu peux tartiner de périphrases comme tu veux, une entreprise qui fait son beurre sur le dos des autres, c'est du pillage, que les autres aient été d'accord ou non. Dernier exemple que j'ai vu passer : https://twitter.com/maximilianhils/status/1680193548212228097
[^] # Re: Le problème est-il dans l'énoncé ?
Posté par Yuul B. Alwright . Évalué à 2.
Ce que dit Astaoth n'as rien d'une périphrase. Et ton exemple ne démontre pas de pillage.
[^] # Re: Le problème est-il dans l'énoncé ?
Posté par Stefane Fermigier (site web personnel) . Évalué à 4.
Je n'ai pas écrit ca.
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Le problème est-il dans l'énoncé ?
Posté par Stefane Fermigier (site web personnel) . Évalué à 6.
Oui, je l'ai vu passer, comme d'autres similaires, et ca n'a strictement rien à voir.
La on a une entreprise qui réclame du support ou des évolutions à son auteur, et s'offusque lorsque celui-ci propose de discuter d'un contrat.
A partir du moment où il y a un contrat, il est normal qu'il y ait des responsabilités fortes. Avant, c'est beaucoup plus discutable.
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Le problème est-il dans l'énoncé ?
Posté par tkr . Évalué à 2.
précisez svp, exemples à l'appui, pour ceux qui connaissent mal/pas android
[^] # Re: Le problème est-il dans l'énoncé ?
Posté par Yuul B. Alwright . Évalué à 8.
Quand une entreprise vent un appareil ou un service qui utilise un logiciel libre, ses salariés fournissent un travail et c'est ce travail qui est payé. Ce n'est pas un pillage.
Le logiciel libre fait d'un logiciel un bien commun et plus un capitale qu'on exploite avec un modèle économique basé sur la rente. Le modèle économique basé sur la rente existe déjà, c'est le logiciel privateur, et il ne profite pas aux "petits créateurs" ou "petites créatrices" de logiciels.
Tu compare des objets physiques avec des idées ? Si je suis ta logique, on devrait limiter le droit d'écrire du code aux seuls personnes assez riches pour se payer des études d'ingénieur ? On doit interdire la réappropriation des outils pour des raisons de sécurité ?
Qu'il soit exigé, pour certains domaines où la sécurité est importante, que les logiciels utilisés aient une certaines garantie que des personnes peuvent fournir contre rémunération est un bon choix.
Par exemple: Qu'il soit demandé que les logiciels utilisés pour un tour de contrôle aient un certains niveau de sécurité et donc demandé à un prestataire d'assurer ce niveau de sécurité c'est une bonne chose.
Mais imposer, pour chaque logiciel, des obligations qui limiteraient la possibilité de création à quelques industriels avec énormément de capital, c'est juste faire de la programmation un privilège qui ne pourra que servir les intérêt d'une haute bourgeoisie.
Donc, pour éviter les abus d'industriels, établissons des règles qui privilégient les plus gros industriels ?
[^] # Re: Le problème est-il dans l'énoncé ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 5.
Lapsus révélateur d'un parti pris :-) ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Le problème est-il dans l'énoncé ?
Posté par Yuul B. Alwright . Évalué à -1.
Ah, rejeter tout un message pour un faute d'orthographe ?
On en est là ?
[^] # Re: Le problème est-il dans l'énoncé ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 10.
Loin de moi l’idée d’ostraciser votre prose ; votre débat m’intéresse au plus haut point. J’espérais que le smiley fasse ressentir une nuance de sympathie dans ma remarque.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Le problème est-il dans l'énoncé ?
Posté par Pinaraf . Évalué à 0.
Je suggère de lire le projet de directive avant de sortir ce genre de phrase.
Si tu développes un logiciel pour, par exemple, compter le nombre de clics sur un bouton, tu n'es pas ciblé par la directive. Pareil pour un logiciel pour gérer une collection de cartes à collectionner, un jeu…
L'objet de la directive reste d'être proportionné aux risques, toute la difficulté de ce genre de travail législatif étant d'exprimer cela correctement.
L'étude d'impact identifiait d'ailleurs des domaines spécifiques, à savoir «Smart Manufacturing, Finance, Energy, Transport and Smart Home».
C'est vrai qu'aujourd'hui il n'y a rien qui privilégie les plus gros industriels tiens… combien d'OS mobiles sont réellement utilisés et utilisables sans compromis majeurs ? combien de moteurs de navigateur web ? Puis la tendance avec l'IA ne va pas du tout dans cette direction…
[^] # Re: Le problème est-il dans l'énoncé ?
Posté par Yuul B. Alwright . Évalué à 0.
Donc ta solution pour combattre des privilèges c'est d'en établir de nouveau qui… profiterons aux même personnes.
[^] # Re: Le problème est-il dans l'énoncé ?
Posté par Yuul B. Alwright . Évalué à 2.
Si tu as besoin d'un certain niveau de sécurité, tu fais appelle à des personnes ou une structure qui te la fournis contre rémunération. Mais développer un logiciel et assurer un certains niveau de sécurité peuvent être effectué par deux entités différentes. Entités qui peuvent collaborer.
Et même si tu définit des domaines spécifiques, ça ratisse large car ça peut inclure tout noyau, toutes bibliothèques ou autre brique logiciel pouvant être utilisé dans ce domaine. Donc une bonne partie des logiciels libres existants.
[^] # Re: Le problème est-il dans l'énoncé ?
Posté par Pinaraf . Évalué à 3.
Et c'est exactement pour ça qu'on se retrouve dans la merde niveau sécurité informatique. Si tu penses pouvoir assurer la sécurité a posteriori, c'est pas ta tonne de sparadrap, même payée très cher, qui réglera le problème.
Donc se pose la question de la responsabilité. Un gus tout seul dans son garage peut-il être responsable, non. Google, Github, oui. Quelqu'un qui en a fait son travail à temps plein, là par contre, ça devient carrément discutable.
Mais en aucun cas la distinction ne doit se faire sur libre/pas libre, militer en ce sens aboutira soit à une loi inutile puisque ne couvrant pas le problème qu'on a aujourd'hui, soit en l'absence de prise en compte du besoin d'exemption pour des cas très précis.
# L'enjeu du problème: la définition du logiciel libre "commercial"
Posté par Stefane Fermigier (site web personnel) . Évalué à 10.
Pour que les choses soient claire:
Pour moi, et pour la plupart des gens qui suivent ce dossier, il ne s'agit pas de demander une exemption pour tous les logiciels libres. Cela serait contre-productif en terme d'image.
Nous pouvons nous satisfaire d'un exemption pour les logiciels libre non-commerciaux, ce qui est dans le texte d'origine de la Commission.
Après toute la question est de définir un logiciel libre commercial / non-commercial.
Pour moi, un logiciel libre ne devient commercial qu'en présence d'un contrat entre l'éditeur du logiciel, l'opérateur du service ou le fabriquant du produit, et l'utilisateur, avec un échange de valeur.
Cette valeur est a priori monétaire, mais on comprend bien que la Commission veulent éviter que les GAFAM, qui pratiquent abondamment la philosophie du "si tu ne paies pas, c'est que c'est toi le produit", ne soient exemptés. Autrement dit que si l'opérateur (car il s'agit le plus souvent de services en ligne) exploite les données des utilisateurs, à des fins de ciblage publicitaire par exemple, ou pour entraîner des modèles d'IA, il y a un échange de valeur.
La pratique de nombreuses sociétés du logiciel libre, qui mettent à disposition gratuitement leurs produits sans aucune garantie, et qui vendent aux utilisateurs qui souhaitent cette garantie des contrats de maintenance / support, me semble à préserver.
Ce qui me semble aberrant, c'est d'exiger d'un éditeur de logiciel libre, qui met à disposition son logiciel gratuitement, de prendre en plus un risque financier (les 15 millions d'euros de sanction, pour le PME) pour des utilisateurs qui ne paient pas, comme il serait aberrant d'exiger de lui qu'il assure le support de tous ses utilisateurs non-payant avec des garanties de service.
De même, il est aberrant d'exiger d'un industriel qui met en open source un logiciel qui n'est pas son coeur de métier, qui n'en tire aucun gain financier de manière directe, d'engager en plus sa responsabilité. De très nombreux responsables de projets de logiciels libres au sein de grands groupes ont déclaré que si la responsabilité de leur entreprise était engagée, il serait obligé d'y mettre fin.
"There's no such thing as can't. You always have a choice." - Ken Gor
# Parallèle avec la science
Posté par bertrand . Évalué à 8.
Un scientifique pond une théorie.
Des gens l'utilisent.
Et un jour, on tombe sur un os, la théorie est "fausse" dans le cas considéré. La gravité de Newton dans le cas d'effet relativiste par exemple.
Le scientifique devrait donc être responsable des dégats !
Il va falloir d'urgence fermer les labos de recherche et autres universités. Ou comment se préparer à l'avenir !
[^] # Re: Parallèle avec la science
Posté par Pinaraf . Évalué à 3.
Cette comparaison est complètement stupide, une théorie est plus abstraite qu'un logiciel, n'en déplaise à certains.
Une entreprise réalise un pont.
Des gens l'utilisent.
Et un jour, on tombe sur un os, un défilé militaire passe et leur rythme de marche fait s'effondrer le pont à cause d'une erreur de conception.
L'entreprise qui a conçu le pont est responsable des dégâts.
[^] # Re: Parallèle avec la science
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Sauf que l'entreprise est seule responsable, pas tous les auteurs d'ouvrage sur les ponts de l'Histoire.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Parallèle avec la science
Posté par Pinaraf . Évalué à 3.
Si tu construis un pont dans ton coin pour ton usage, tu n'es responsable que pour toi.
Si tu construis un pont pour une route contre monnaie sonnante et trébuchante, tu es responsable.
Si quelqu'un construit une route sur ton pont déjà existant, il est responsable.
Et c'est bien l'esprit de la loi et de tous les documents que j'ai pu lire à son sujet. Le cœur du problème c'est la définition de monnaie sonnante et trébuchante.
Mais quand je vois pleurer Github, c'est-à-dire des auteurs de contrefaçon (puisque c'est le terme pour le vol de propriété intellectuelle, et c'est ce qu'est Github copilot), ça m'émeut pas une seconde. Ces gens ne sont en aucun cas présents pour aider le libre, et donc si une loi va contre leurs intérêts, c'est leur problème, et il est certain qu'ils feront ce qu'ils ont fait ici, à savoir diffuser leur interprétation d'un extrait de brouillon. J'attends d'avoir un véritable texte avant de juger.
[^] # Re: Parallèle avec la science
Posté par Joël Thieffry (site web personnel) . Évalué à 3.
Sauf que si un cambrioleur s'introduit chez toi, en ressort et se fait mal en trébuchant sur ton pont, il pourra porter plainte contre toi. C'est idiot, mais c'est quand même toi le responsable.
Enfin je diverge du propos général, veuillez reprendre le débat.
[^] # Re: Parallèle avec la science
Posté par seraf1 . Évalué à 2.
Sauf qu'il n'a jamais été spécifié que le pont devait pouvoir résisté à une compagnie marchant au pas.
Dans ce genre d'idées, un fabriquant de four micro-onde ne doit pas pouvoir être tenu pour responsable si une personne utilise celui-ci pour faire sécher son chat, sinon on se retrouve avec des notices d'utilisation ressemblant à une bible !
[^] # Re: Parallèle avec la science
Posté par Faya . Évalué à 2.
Je pense même que la personne tenue responsable sera le gradé à la tête de la compagnie car "le règlement militaire interdit déjà de marcher au pas sur un pont". (Bon Wikipedia ne donne pas de source pour cette affirmation mais je doute qu'on ait accès aux règlements de l'armée)
[^] # L'Union la plus bête du monde
Posté par devnewton 🍺 (site web personnel) . Évalué à 10. Dernière modification le 17 juillet 2023 à 20:51.
Le parallèle serait plutôt à faire avec l'ingénierie.
Imaginons qu'un certain Archimède invente un système pour soulever des objets lourds (comme la compilation des lois idiotes de l'UE).
Notre inventeur devra pondre un dossier de sécurité et le faire auditer à chaque ajout de poulie et être en mesure de déclarer chaque fois qu'une corde lâche. Et ce pour chaque palan construit en Europe, même si lui même n'en a jamais fait qu'un prototype dans son jardin.
Avec un tel système réglementaire, on peut être sûr qu'il préférera rester dans son bain et crier Eurecon plutôt que Eureka.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Alors lisons cette proposition de réglement
Posté par vpo . Évalué à 8.
La proposition est là.
https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:52022PC0454
Et on peut lire :
C'est la seule mention de "logiciels libres".
Je n'ai pas vu de mention disant que si un contributeur est salarié d'une boîte privée, alors cela transformerait le logiciel libre en logiciel libre à activité commerciale.
Par contre, bien évidemment, si la boîte privée distribue ledit logiciel libre dans un de ses produits, elle sera tenue responsable pour ses produits à elle en cas de faille dans le logiciel libre, puisqu'elle en fait une activité commerciale. Et elle ne pourra pas se retourner au civil contre les créateurs du projet qui eux n'ont pas d'activité commerciale.
Par contre en effet, les petites PME qui développent leur propre soft en logiciel libre et qui proposent des services payants autours vont être soumise à ce règlement. Et là quand on voit comment certains softs sont développés ça va leur faire tout drôle.
Exemple vécu : SugarCRM et ses forks comme vTiger. J'avais installé ça pour des potes qui montaient leur boîte. Mode d'installation préconisé à l'époque pour que le CRM marche bien : faire un chmod 777 sur tout le contenu du répertoire d'installation. Bien sûr…
Alors pour votre maison, faites sauter les serrures et dégondez toutes les portes, c'est plus pratique pour rentrer et sortir…
[^] # Re: Alors lisons cette proposition de réglement
Posté par Pinaraf . Évalué à 5.
À noter au passage le beau cheval de troie : si on utilise des données personnelles pour autre chose que sécurité/compatibilité/interopérabilité, hop, ça rentre dans le lot de commercial.
Et ça, ça fait plaisir, casser un peu la légende du gratuit quand c'est payé par le vol de données personnelles…
[^] # Re: Alors lisons cette proposition de réglement
Posté par Dring . Évalué à 2.
Si je comprends bien le journal, depuis la proposition, il y a eu des amendements qui portent justement sur cette partie, et ce sont ces changements qui poseraient soucis. Mais on peut trouver où la version courante ?
Plus étrange encore, il me semblait que le texte était passé au journal officiel le 7 juin, donc déjà applicable ?
Je suis perdu…
https://www.ssi.gouv.fr/actualite/adoption-definitive-du-cybersecurity-act-un-succes-pour-lautonomie-strategique-europeenne/
[^] # Re: Alors lisons cette proposition de réglement
Posté par Jean-Baptiste Faure . Évalué à 3.
Il me semble que tu confonds le Cyber Security Act et le Cyber Resilience Act.
[^] # Re: Alors lisons cette proposition de réglement
Posté par Proxy2023 . Évalué à 2.
La version approuvée par le commité ITRE le 19 juillet, avec mandat de négociations:
ITRE 19 July approved text with mandate
les votes : roll call votes
La version du 13 juillet, approuvée par le conseil (COREPER-I) le 19 avec mandat de négociations (trilogue):
EU Council compromise text approved for negotations
le compte-rendu du COREPER-I du 19 n'était pas encore publié mais une communication officielle a été faite:
member-states-agree-common-position
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.