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 :

É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 ?