Le Cyber Resilience Act : une menace pour le logiciel libre ?

Le 17 avril 2023, treize groupes d’intérêt du secteur du logiciel libre et de l’open source ont signé une lettre ouverte adressée à la Commission européenne¹ pour l’alerter sur leurs craintes à l’égard de la proposition de règlement concernant des exigences horizontales en matière de cybersécurité pour les produits comportant des éléments numériques et modifiant le règlement (UE) 2019/1020².

Présenté en septembre 2022, le projet de règlement connu sous le nom anglais de Cyber Resilience Act (CRA) prévoit des obligations en matière de sécurité à tous les « produits comportant des éléments numériques dont l’utilisation prévue ou raisonnablement prévisible comprend une connexion directe ou indirecte, logique ou physique, à un dispositif ou à un réseau » (art. 2 (1) du règlement proposé). En clair : il vise à s’assurer que tous les logiciels et matériels connectés mis sur le marché dans l’Union européenne (UE) apportent des garanties minimales en matière de sécurité informatique.

De nombreux cas existent déjà, pour lesquels des obligations de sécurité informatique s’imposent. C’est le cas en vertu de l’article 32 du règlement général de protection des données (RGPD), applicable au traitement des données à caractère personnel. C’est aussi le cas pour les opérateurs de services essentiels, couverts par la directive Network Information Security (NIS)³. Mais de nombreux logiciels, dont ceux embarqués dans des objets connectés, ne sont toujours soumis à aucune réglementation spécifique en matière de cybersécurité.

Le souhait d’une amélioration de la sécurité des produits numériques en Europe est partagé par les signataires de la lettre ouverte. Alors pourquoi craignent-ils les effets de cette proposition de règlement ?

Pour le comprendre, il est utile de rappeler les caractéristiques du logiciel libre ou open source, de son modèle de développement et de ses modèles d’affaires. Nous verrons ainsi que le projet de Cyber Resilience Act l’appréhende difficilement, justifiant des amendements qui visent à créer une exemption au bénéfice du logiciel libre ou open source plus large que celle actuellement prévue.

Les logiciels libres : des biens communs souvent développés par une communauté informelle

Le mouvement du logiciel libre est né d’abord aux États-Unis dans les années 1980. Il conçoit les logiciels comme des biens communs⁴. Il s’est structuré autour de la Free Software Foundation, fondée en 1985 par l’informaticien Richard Stallman. Celui-ci définit le logiciel libre comme répondant à quatre caractéristiques socio-techniques, qu’il appelle les « quatre libertés », usuellement numérotées de 0 à 3⁵ :

1. la liberté d’utiliser le logiciel pour tout usage ;
2. la liberté d’étudier le logiciel pour en comprendre le fonctionnement et le modifier pour lui faire faire ce que veut son utilisateur ;
3. la liberté de redistribuer le logiciel et d’en faire des copies, dans un objectif altruiste de partage ;
4. la liberté d’améliorer le programme et de partager ses améliorations avec le public.

Cette définition est d’ailleurs rappelée au considérant 10 du projet de Cyber Resilience Act, qui définit les logiciels libres comme « logiciels, y compris leurs codes sources et versions modifiées, qui sont librement partagés et accessibles, utilisables, modifiables et redistribuables ».

Les logiciels dits « open source » ont généralement les mêmes caractéristiques, mais ce terme est considéré comme plus neutre idéologiquement. Il a été inventé pour rendre la méthode de développement des logiciels libres⁶ − qui repose sur l’interaction entre un noyau dur de développeurs et des contributions d’une communauté d’utilisateurs⁷ −, acceptable aux yeux des dirigeants d’entreprises. Parler de « logiciel open source » revient donc à parler de « logiciel libre », sans revendiquer le projet politique porté par la Free Software Foundation.

Pour résister à l’extension du droit de la propriété intellectuelle aux programmes d’ordinateurs accélérée par l’adoption du Computer Software Copyright Act de 1980 aux États-Unis, Richard Stallman a inventé le copyleft. Il s’agit d’une clause insérée dans un contrat de licence, obligeant quiconque modifiant ou redistribuant un logiciel libre à le faire selon les mêmes conditions. Elle sert à empêcher la privatisation d’un logiciel que ses auteurs considèrent comme un bien commun. Ainsi, avant d’être une innovation technique, le logiciel libre est surtout une innovation juridique. Les logiciels open source, c’est-à-dire ceux qui ne revendiquent pas la dimension politique et militante du logiciel libre, préfèrent en général d’autres licences que la GNU General Public Licence de la Free Software Foundation, comme la licence BSD, qui ne contiennent pas de copyleft⁸. En France comme dans le reste de l’Union européenne⁹, la violation d’un contrat de licence d’un logiciel libre constitue une contrefaçon¹⁰. Toute la difficulté réside dans l’identification des auteurs et titulaires de droits d’auteurs, qui, avec le Cyber Resilience Act, se doublera d’une difficulté à identifier un unique fabricant.

L’éditeur d’un logiciel propriétaire est généralement clairement identifié. Celui-ci signe des contrats avec ses employés, ses sous-traitants, et ses clients, qui peuvent, en cas de dysfonctionnement, engager sa responsabilité contractuelle. Les choses se compliquent avec le logiciel libre. À titre d’exemple, les contributeurs à la version 5.10 de Linux, noyau du système d’exploitation GNU/Linux, auraient été près de deux mille¹¹. La majeure partie n’est pas employée par la Linux Foundation. La plupart des projets libres ou open source, comme Yarn − un gestionnaire de modules initialement créé par Facebook et utilisé dans de nombreux logiciels Javascript − ou OpenSSL − une bibliothèque de chiffrement très largement utilisée pour sécuriser les sites web −, sont maintenus par des communautés informelles de contributeurs parfois bénévoles, parfois payés par un employeur qui voit un intérêt au suivi d’une brique technique élémentaire dont il dépend.

Or, les logiciels libres ne sont pas immunisés contre les failles de sécurité. En 2014, la faille Heartbleed, détectée dans la librairie OpenSSL, avait affecté de très nombreux sites web, y compris ceux de Facebook, Google et Twitter¹². Les auteurs de logiciels libres ou open source n’ont toutefois, à ce jour, aucune obligation ou responsabilité à l’égard de leurs utilisateurs, sauf si une faute intentionnelle est démontrée.

Une volonté de responsabiliser les fabricants de logiciels qui peinent à s’adapter au logiciel libre

Le RGPD, le Digital Services Act et le Digital Markets Act sont des textes emblématiques de la politique de l’Union européenne dans le secteur du numérique ces dernières années. Aucun de ces textes n’impose toutefois d’obligations aux éditeurs de logiciels en tant que tels. Les récentes propositions de règlement sur l’intelligence artificielle (IA)¹³, le projet de directive sur la responsabilité en matière d’IA¹⁴, la proposition de directive relative à la responsabilité du fait des produits défectueux¹⁵ et le projet de Cyber Resilience Act suivent une logique différente.

Ainsi, la proposition de Cyber Resilience Act, par son article 10, entend imposer aux fabricants de produits (hardware comme software) comportant des éléments numériques une si longue liste d’obligations que nous relevons ici seulement les plus importantes d’entre elles. Un fabricant devra ainsi s’assurer que son produit est livré sans vulnérabilité connue, il devra conduire une évaluation des risques, introduire des paramètres par défaut sécurisés et des mécanismes pour réduire les conséquences d’une faille de sécurité, conduire une évaluation de la conformité selon une procédure établie à l’article 24 de la proposition, fournir les informations relatives à la sécurité et garantir que les vulnérabilités découvertes feront l’objet de mises à jour de sécurité. Certaines obligations paraissent même un peu superflues car redondantes avec des règles préexistantes. Ainsi, l’annexe I, dans son alinéa 1 (1) (3) (e), prévoit que le fabricant respecte le principe de minimisation des données « à caractère personnel ou autres [sic] »¹⁶ prévu à l’article 5 du RGPD.

La conformité au Cyber Resilience Act risque d’être structurellement difficile pour les projets de logiciels libres ou open source, étant donné le mode de fonctionnement que nous avons précédemment exposé. Une interprétation stricte du texte, s’il était adopté dans une version proche de la proposition initiale de la Commission, risquerait d’aboutir à l’interdiction d’un grand nombre de briques logicielles libres pourtant essentielles au bon fonctionnement de l’écosystème numérique, comme OpenSSL. Ceci amène certains à plaider pour une exemption très large au bénéfice du logiciel libre.

Il n’en existe guère dans les articles de la proposition initiale. Seul le considérant 10 précise qu’« afin de ne pas entraver l’innovation ou la recherche, les logiciels libres et ouverts développés ou fournis en dehors du cadre d’une activité commerciale ne devraient pas être couverts par le présent règlement ». Cette formule paraît très restrictive, puisqu’elle peut être interprétée comme énonçant deux conditions cumulatives : une finalité d’innovation ou de recherche, et l’absence d’activité commerciale.

Ignorons la première condition, que l’on peut aussi comprendre comme une simple déclaration d’intention dépourvue de portée juridique, telle qu’il arrive d’en trouver dans des considérants. Dans cette hypothèse, il est vrai que cette exemption concernera un grand nombre de personnes et, notamment, l’ensemble des contributeurs bénévoles à des projets de logiciels libres, ou toutes les associations à but non lucratif qui offrent un soutien matériel à certains de ces projets. Mais que se passe-t-il si, par exemple, un contributeur bénévole facture des prestations de conseils tirées de sa compétence sur le logiciel libre auquel il a contribué ? Il devrait alors s’assurer de la conformité du logiciel auquel il contribue au Cyber Resilience Act, alors même qu’il n’a en aucune manière de contrôle effectif sur le projet dans son ensemble, ni les moyens – voire les compétences – de s’assurer de la conformité du produit.

Pourtant, l’activité commerciale est définie de façon très large par la proposition. Le considérant 10 poursuit en effet en indiquant que « l’activité commerciale peut être caractérisée non seulement par le prix facturé pour un produit, mais également par le prix des services d’assistance technique, par la fourniture d’une plateforme logicielle par l’intermédiaire de laquelle le fabricant monétise d’autres services, ou par l’utilisation de données à caractère personnel pour des raisons autres qu’aux seules fins d’améliorer la sécurité, la compatibilité ou l’interopérabilité du logiciel ».

Or, ce n’est pas parce que les logiciels libres ou open source sont librement disponibles qu’ils ne font l’objet d’aucune activité commerciale. En 2018, la société Red Hat Linux, avant son rachat par IBM, avait déclaré un chiffre d’affaires de près de 3 milliards de dollars¹⁷. La Commission estime sans doute qu’une telle entreprise devrait être en mesure de supporter les coûts de la conformité, ce qui nous semble raisonnable. Mais tel n’est pas le cas de la majorité des entreprises qui proposent des services commerciaux autour de logiciels libres. Une petite entreprise qui aide à déployer correc­tement une librairie comme OpenSSL, ou un designer web en freelance qui déploie une installation d’un système de gestion de contenus (Content Management System en anglais, ou CMS) libre comme WordPress ou Drupal devra-t-il supporter les coûts de la conformité du produit pour lequel il propose des services commerciaux ?

On le voit bien, le Cyber Resilience Act soulève de nombreuses interrogations. Il a été pensé pour imposer aux fabricants de logiciels propriétaires, dont le code, fermé, n’est pas susceptible d’audit, des règles horizontales de cybersécurité. Mais, ce faisant, interprété strictement, il risque de nuire à l’écosystème du logiciel libre ou open source, alors que, de l’aveu même de la Commission européenne, le « code source ouvert offre davantage de possibilités pour renforcer la sécurité, puisque le code peut être librement inspecté et amélioré »¹⁸.

Plusieurs amendements visant à élargir l’exemption accordée au logiciel libre ou open source, et à l’introduire dans les articles du règlement ont été déposés en commission IMCO (Commission du marché intérieur et de la protection des consommateurs) et en commission ITRE (Commission de l’industrie, de la recherche et de l’énergie) du Parlement européen. Pour l’heure, il est trop tôt pour faire des pronostics sur les chances d’aboutir de tels amendements.

Sources :

1. Lettre datée du 17 avril 2023, intitulée « Open Letter to the European Commission on the Cyber Resilience Act », disponible sur le site de la fondation Eclipse,
   newsroom.eclipse.org.
2. Voir la procédure 2022/0272 (COD).
3. Directive (UE) 2016/1148 du Parlement européen et du Conseil du 6 juillet 2016 concernant des mesures destinées à assurer un niveau élevé commun de sécurité des réseaux et des systèmes d’information dans l’Union européenne.
4. Ce mouvement est étudié en France par Sébastien Broca, auteur de l’ouvrage Utopie du logiciel libre : du bricolage informatique à la réinvention sociale, Éditions du Passager clandestin, 2013.
5. Voir Sébastien Broca, Ibid.
6. Mathias Klang, « Free software and open source : The freedom debate and its consequences », First Monday, vol. 10, n° 5, mars 2005, firstmonday.org.
7. Eric Raymond, The Cathedral and the Bazaar, Sebastopol CA, O’Reilly, 1999.
8. Mathias Klang, Ibid.
9. CJUE, 5^e ch., 18 décembre 2019, IT Development SAS contre Free Mobile SAS, Aff. C-666/18.
10. Cass. 1re ch. civ., 5 octobre 2022, Entr’Ouvert contre Orange, pourvoi n° 21-15.386.
11. Jonathan Corbet, « Statistics from the 5.10 kernel development cycle », LWM.net, lwn.net, 14 December 2020.
12. Michaël Szadkowski, « Faille Heartbleed : les sites pour lesquels il est conseillé de changer son mot de passe », lemonde.fr. 11 avril 2014.
13. Proposition de règlement du Parlement européen et du Conseil établissant des règles harmonisées concernant l’intelligence artificielle et modifiant certains actes législatifs de l’Union, COM (2021) 206 FINAL.
14. Proposition de directive du Parlement européen et du Conseil relative à l’adaptation des règles en matière de responsabilité civile extracontractuelle au domaine de l’intelligence artificielle, COM/2022/496 FINAL.
15. Proposition de directive du Parlement européen et du Conseil relative à la responsabilité du fait des produits défectueux, COM (2022) 495 FINAL.
16. Il est difficile d’interpréter les termes « ou autres » introduits à l’alinéa 1 (1) (3) (e) de l’annexe I de la proposition de la Commission, dans la mesure où le principe de minimisation des données ne s’applique qu’aux données à caractère personnel.
17. « Red Hat Reports Fourth Quarter and Fiscal Year 2018 Results », redhat.com, March 26, 2018.
18. Commission européenne, « Stratégie européenne en matière de logiciels libres 2020 – 2023 – l’esprit d’ouverture », C (2020) 7149 FINAL, p. 2, commission.europa.eu.