Article intéressant de la PSF sur une proposition de loi EU liée à la Cyber Resilience Act et qui n’est pas sans risque pour le monde de l’open source y compris l’écosystème autour de Python.
Mon anglais étant ce qu’il est, il va me falloir plusieurs lectures pour en comprendre toutes les subtilités. Mais pour celles et ceux qui le souhaitent, en fin d’article, un appel est lancé pour interpeler nos députés Européens sur le sujet avant le 26 avril (C’est court).
En effet, il s’agit d’une directive en cours d’élaboration. Le texte actuel est celui issu de la Commission européenne, il peut encore être amendé par les deux autres institutions de l’Union, le Parlement et le Conseil.
Les principaux problèmes, en résumé:
La plupart des licences de logiciel libre contiennent une clause de non-responsabilité, souvent proéminente, pour protéger les développeurs, les contributeurs et les distributeurs de toute responsabilité potentielle liée à l’utilisation du logiciel. Le CRA introduit des responsabilités très lourdes qui viennent radicalement changer le “contrat social” qui est la base de la production de logiciels libres par l’écosystème de ses développeurs, et pourrait avoir des conséquences imprévues et dommageables sur l’innovation en Europe.
En particulier, la législation proposée prévoit d’étendre le régime de la marque CE à tous les produits contenant des éléments numériques vendus en Europe, qui contiennent presque tous des logiciels libres, ce qui impose la mise en place de processus bureaucratiques extrêmement lourds.
L’exemption proposée, sous sa forme actuelle, pour les logiciels libres et open source “non commerciaux” pose de nombreux problèmes graves qui doivent être résolus pour atteindre son objectif. Elle repose sur un faux principe, qui est que la majorité du logiciel libre serait produite par des entités sans objectif lucratif, direct ou indirect.
L’exemption relative à “la mise à disposition de logiciels non finalisés” est pour sa part trop restrictive pour ne pas impacter profondément les réseaux d’innovation ouverte qui produisent in fine le logiciel libre utilisé dans les produits mis à disposition des utilisateurs.
Comme c’est encore en discussion auprès du Conseil et du Parlement, ceux qui ont réellement du poids dans le sujet seraient plutôt Thierry Breton, le Commissaire, et les gouvernements. Logiquement la CNLL a ses entrées au gouvernement (enfin j’espère !?)
GitHub a publié hier un blog post alarmiste sur le CRA:
Particulièrement mauvais pour les entreprises du logiciel libre ou contribuant au logiciel libre, le point suivant:
"The current text (Recitals 10 and 10a) would regulate open source projects unless they have “a fully decentralised development model.” Any project where a corporate employee has commit rights would need to comply with CRA obligations. This turns the win-wins of open source on its head. Projects may ban maintainers or even contributors from companies, and companies may ban their employees from contributing to open source at all.”
Ces points sont confirmés par Eclipse Foundation qui organise un webinaire aujourd’hui pour expliquer la situation plus en détail:
Ce que je comprend à ce stade: le Conseil va adopter son texte très prochainement, d’une part, et le Parlement adoptera son texte sans vote en plénière (!), auquel cas les amendements qui ont été adoptés en commissions (ITRE et IMCO) seront adoptés. Sauf que les amendements IMCO sont bons, mais les amendements ITRE sont terribles. Et comme les considérants 10 et 10 bis sont de la responsabilité de l’ITRE, ce sont leurs amendements (et non ceux de l’IMCO) qui seront appliqués.
Il y a donc un double enjeu urgent:
Peser sur le PE (-> contacter les eurodéputés) d’ici mecredi, a minima pour que les amendements ITRE ne soient pas adoptés sans vote.
Essayer de peser sur la position française au sein du Conseil.
En notant enfin que faire référence au post de GitHub peut être contre-productif, car de nombreux représentants ou fonctionnaires des institutions européennes voient l’open source comme une porte dérobées pour que les GAFAM échappent aux responsabilités qu’ils veulent leurs imposer.
Il est probable qu’Eclipse annonce lors de son webinaire un plan d’action.
Il y a en tout cas urgence à agir et fédérer les initiatives, car le vote au Parlement doit avoir lieu le 19 juillet et le Conseil pourrait être ammené (par la Présidence espagnole) à arrêter sa décision d’ici fin juillet.
Le CRA 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 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.
Pour celles et ceux qui veulent agir: il faut contacter les eurodéputés du comité ITRE pour leur expliquer le problème (éventuellement juste un mail avec une ou deux phrase perso + un lien sur le communiqué).
Another negotiation point is dealing with open-source software integrated into commercial products. Here, an agreement was reached at the technical level and endorsed at the political level.
As Euractiv previously reported, the idea was to cover only software developed in the context of commercial activities and to have more limited rules for open-source software stewards regarding documentation and vulnerability handling.
In the final iteration of the text, seen by Euractiv, non-profit organisations that sell open source software on the market but reinvest all the revenues in non-for-profit activities were also excluded from the scope.
A partir du moment où on est dans un cadre commercial, open source ou pas, on est soumis au CRA et donc obligés de se faire certifier “CE”.
Ce qui est regrettable, c’est que les législateurs européens n’aient pas adopté ce principe posé par l’administration américaine: "“La responsabilité doit être placée sur les parties prenantes les plus capables d’agir pour prévenir les incidents, et non sur les utilisateurs finaux qui supportent souvent les conséquences d’un logiciel non sécurisé ni sur le développeur open-source d’un composant qui est intégré dans un produit commercial”. (source: https://www.whitehouse.gov/wp-content/uploads/2023/03/National-Cybersecurity-Strategy-2023.pdf).
