L’impact de la NPLD sur l’écosystème Open Source

Entrée en vigueur le 8 décembre 2024, la directive 2024/2853 relative à la responsabilité du fait des produits défectueux (dite “New Product Liability Directive” et abrégée NPLD) porte une refonte substantielle du régime de la responsabilité des produits défectueux mis en place par la directive du 25 juillet 1985¹. Ce nouveau texte permet de prendre en compte plus largement les biens et les usages numériques (y compris les récentes évolutions en matière d’intelligence artificielle (IA)) ainsi que les évolutions règlementaires en matière numérique (telles que le récent Cyber Resilience Act (CRA)).
La nouvelle directive apporte ainsi des modifications au régime de responsabilité des producteurs au sein de l’Union européenne, tout en gardant le principe d’une responsabilité sans faute car « [la] responsabilité sans faute des opérateurs économiques reste le seul moyen de résoudre de façon adéquate le problème d’une juste répartition des risques inhérents à la production technique moderne. » (considérant 2)

Compte tenu des modifications apportées, la précédente directive est abrogée, mais les États ont jusqu’au 9 décembre 2026 pour transposer ce nouveau texte, qui sera applicable aux produits qui seront mis sur le marché ou mis en service à partir de cette date. Afin de ne pas créer d’insécurité pour les opérateurs économiques, il n’y aura pas d’effet rétroactif et le cadre antérieur continuera à s’appliquer pour tous les produits mis sur le marché ou mis en service avant cette transposition. Alors qu’en principe la transposition d’une directive laisse une marge d’adaptation aux États membres, ceux-ci devront appliquer ce nouveau régime de manière uniforme sans pouvoir prévoir de règles plus ou moins protectrices dans le but, rappelé par le législateur européen, de ne pas créer de rupture de concurrence entre les règlementations des pays de l’UE.

Cette directive prolonge et complète les autres règlementations européennes récemment promulguées (le « paquet numérique »), dont plus spécifiquement le CRA et l’AI Act, en favorisant l’indemnisation de préjudices conséquents à un usage d’IA ou encore de produits non (ou mal) sécurisés. Ce corpus de textes forme un dispositif couvrant l’ensemble des étapes de la vie d’un produit : en amont de la mise sur le marché, lors de la mise sur le marché (et éventuellement lors de la mise en service – pour l’AI Act et la NPLD) et en aval de cette mise sur le marché.

À l’instar des autres régulations récentes, il semble opportun d’étudier la NPLD à la lumière des modifications qu’elle entraine pour les différents opérateurs économiques (c’est-à-dire les sociétés opérant sur le marché européen) et les utilisateurs finaux, mais également les pratiques de l’Open Source. L’objectif est de permettre d’anticiper les effets, de s’y préparer et éventuellement de soulever quelques interrogations.

I – Présentation et apports de la directive

A – Champ d’application

L’article 1^er de la directive (Objet et objectifs) donne le ton en précisant que le texte « établit des règles communes relatives à la responsabilité des opérateurs économiques pour les dommages causés à des personnes physiques par des produits défectueux et à la réparation de ces dommages. »

Ainsi, même si la notion de consommateur² est plusieurs fois visée dans la directive, le bénéfice de la protection est ici étendu à « toute personne physique » dès lors qu’il s’agit de « produits mis sur le marché ou mis en service après le 9 décembre 2026 » et cela pour dix ans à partir de la mise sur le marché ou de la mise en service d’un produit. Ce délai est renouvelé pour dix nouvelles années en cas de modifications substantielles du produit (ce qui couvre potentiellement certaines mises à jour du produit).

Cet élargissement du champ d’application de la directive permet de renforcer la sécurité des consommateurs européens vis-à-vis des produits défectueux, physiques comme numériques, en prévoyant une responsabilité sans faute dès lors que la personne physique peut justifier : a) d’un dommage, b) de la défectuosité d’un produit ; c) et d’un lien entre ce dommage est la défectuosité du produit. Le mécanisme est donc inchangé si ce n’est que ces trois éléments ont évolué afin de prendre en compte les dernières évolutions liées aux numériques :

La notion de produit est élargie puisqu’elle inclut non seulement les biens matériels, mais aussi les logiciels³ ainsi que ceux intégrés dans un autre produit interconnecté (article 4.1).

Cet article constitue une extension de la définition du produit, consacrant la jurisprudence antérieure européenne et française⁴ concernant des logiciels et clarifiant le rôle des éditeurs de produits numériques (cela quel que soit son mode de fourniture ou d’utilisation, et donc indépendamment du fait qu’il soit installé sur un appareil, accessible via un réseau de communication ou des technologies en nuage, ou fourni dans le cadre d’un modèle de logiciel en tant que service). Plus encore, la directive étend aussi ses effets aux mises à jour des logiciels, par ou pour les fabricants. Elle rappelle aussi l’application aux systèmes d’IA (cf AI Act).

À noter que la notion de produit s’étend à la fois aux composants directement intégrés dans le produit, mais aussi aux services connexes interconnectés dès lors qu’ils sont aussi sous le contrôle du fabricant. Le considérant 17 l’exprime pleinement : « il est de plus en plus fréquent que des services numériques soient intégrés à un produit ou interconnectés avec celui-ci de telle sorte que l’absence du service empêcherait le produit d’exécuter une de ses fonctions. Bien que la présente directive n’ait pas vocation à s’appliquer aux services en tant que tels, il est nécessaire d’étendre la responsabilité sans faute auxdits services numériques intégrés ou interconnectés, étant donné que ceux-ci déterminent la sécurité du produit au même titre que les composants physiques ou numériques. Il convient que ces services connexes soient considérés comme des composants du produit auquel ils sont intégrés ou avec lequel ils sont interconnectés, lorsqu’ils sont sous le contrôle du fabricant de ce produit. »

Les dommages potentiellement indemnisables sont relativement larges, allant de dommages corporels (de la mort aux lésions corporelles « y compris l’atteinte médicalement reconnue à la santé psychologique »⁵) aux dommages causés à des biens (à l’exception des biens défectueux ou de tout autre produit sous le contrôle du fabricant, et des biens « exclusivement [utilisés] à des fins professionnelles »⁶) et à la corruption ou destruction de données (à l’exception des données utilisées à des fins professionnelles)⁷.

La directive prévoit une assiette d’indemnisation relativement large, puisqu’elle précise aussi que pourront aussi être indemnisées les « les pertes immatérielles résultant de ces dommages ».

La définition de la défectuosité précise qu’« un produit est considéré comme défectueux lorsqu’il n’offre pas la sécurité à laquelle une personne peut légitimement s’attendre ».

Une liste non exhaustive présente les facteurs à prendre en compte lors de l’évaluation de la défectuosité d’un produit (article 7), dont des exigences de sécurité et de cybersécurité (cf. CRA) ou encore lié à l’entrainement de l’IA (cf. AI Act). À noter que la directive prévoit toute une série de dispositifs permettant soit d’alléger la preuve de la défectuosité⁸, soit d’alléger la responsabilité du fabricant au titre d’une « exonération pour risque de développement »⁹.

Le lien de causalité pouvant parfois être complexe à prouver, la directive organise un assouplissement de la charge de la preuve incombant à la victime. La défectuosité du produit est ainsi par exemple présumée par la seule démonstration par la personne lésée que le produit était défectueux, qu’elle a subi un dommage, et que le lien de causalité entre le dommage et la défectuosité du produit découle d’un lien probable entre les deux (article 10). Ce sera alors à l’opérateur économique de prouver cette absence de causalité, ce qui est toujours particulièrement complexe à argumenter.

En plus de cette extension du champ d’application de la réglementation des produits défectueux, la NPLD vient aligner la dénomination et la définition des opérateurs économiques concernés sur celles des autres textes du « paquet numérique ».

B – Les acteurs concernés

La directive vise notamment les fabricants, les mandataires, les importateurs, les distributeurs, les prestataires de services d’exécution de commandes ainsi que les fournisseurs de plateforme en lignes qui peuvent chacun voir leur responsabilité solidairement ou subsidiairement engagée en fonction de leur rôle dans la chaîne de distribution du produit concerné (article 8). Lorsqu’une faute de la personne lésée est caractérisée conjointement avec la défectuosité du produit, une réduction de la responsabilité est alors possible (article 13)

Le principe posé par la directive est que les opérateurs économiques sont cumulativement (tous) responsables des dommages causés par un produit défectueux. Notamment, l’article 8.1 prévoit le cumul des responsabilités du fabricant du produit final et du fabricant du composant intégré. Ce régime renforce la nécessité pour les fabricants (éditeurs de logiciels, intégrateurs, etc.) qui doivent mettre en place des procédures de vérification de leurs composants logiciels, encore plus particulièrement lorsque ces dépendances sont Open Source.

Opérateur	Définition	Régime de responsabilité	Exonération de responsabilité	CRA	AI Act
Fabricant	« Toute personne physique ou morale qui : • a) met au point, fabrique ou produit un produit ; • b) fait concevoir ou fabriquer un produit ou qui, en apposant sur ce produit son nom, sa marque ou d’autres caractéristiques distinctives, se présente comme son fabricant ; • c) met au point, fabrique ou produit un produit pour son propre usage » (article 4.10) Remarque : le considérant 13 rappelle que « […] les développeurs ou producteurs de logiciels, y compris les fournisseurs de systèmes d’IA au sens du règlement (UE) 2024/1689 du Parlement européen et du Conseil (5), devraient être considérés comme des fabricants. »	Le fabricant peut être tenu responsable en cas de produit défectueux (article 8.1 (a.b.c.)). Le fabricant peut être tenu solidairement responsable avec d’autres opérateurs (article 12).	Le fabricant peu être exonéré de responsabilité : • Lorsqu’ « il n’a pas mis le produit sur le marché ni ne l’a mis en service » (article 11.1.a) ; • S’ « il est probable que la défectuosité ayant causé le dommage n’existait pas au moment de la mise sur le marché, de la mise en service ou, dans le cas d’un distributeur, de la mise à disposition sur le marché du produit, ou que cette défectuosité est apparue après ce moment ; » (article 11.1.c) ; • « s’il s’agit d’un fabricant d’un composant défectueux visé à l’article 8, paragraphe 1, premier alinéa, point b), que la défectuosité du produit dans lequel le composant a été intégré est due à la conception de ce produit ou aux instructions données par le fabricant de ce produit au fabricant de ce composant ; » (article 11.1.f) ; • « Dans le cas d’une personne qui modifie un produit visé à l’article 8, paragraphe 2, que la défectuosité ayant causé le dommage est liée à une partie du produit non affectée par la modification. » (article 11.1.g) Cela sauf si le défaut provient d’un service connexe ou de l’absence de mise à jour nécessaire à la sécurité ni en cas de modification substantielle du logiciel intégré, et que cet élément soit sous le contrôle du fabricant (article 11.2).	Définition équivalente (article 3.13)	Définition équivalente à celle de fournisseur (article 3.3)
Mandataire	« Toute personne physique ou morale établie dans l’Union ayant reçu un mandat écrit d’un fabricant pour agir en son nom aux fins de l’accomplissement de tâches déterminées » (article 4.11)	Le mandataire peut être tenu responsable « dans le cas d’un fabricant d’un produit ou d’un composant établi en dehors de l’Union, et sans préjudice de la responsabilité de ce fabricant » (art 8.1.c.ii) Le mandataire peut être tenu solidairement responsable avec d’autres opérateurs (article 12).	Pas d’exonération pour le mandataire per se.	Définition équivalente (article 3.15)	Définition équivalente (article 3.5)
Importateur	« Toute personne physique ou morale qui met sur le marché de l’Union un produit provenant d’un pays tiers » (article 4.12)	L’importateur peut être tenu responsable « dans le cas d’un fabricant d’un produit ou d’un composant établi en dehors de l’Union, et sans préjudice de la responsabilité de ce fabricant » (art 8.1.c.i) L’importateur peut être tenu solidairement responsable avec d’autres opérateurs (article 12).	L’importateur peut être exonéré de sa responsabilité : • Lorsqu’« il n’a pas mis le produit sur le marché ni ne l’a mis en service » (article 11.1.a) ; • « S’il est probable que la défectuosité ayant causé le dommage n’existait pas au moment de la mise sur le marché, de la mise en service ou, dans le cas d’un distributeur, de la mise à disposition sur le marché du produit, ou que cette défectuosité est apparue après ce moment ; » (article 11.1.c)	Définition équivalente (article 3.16)	Définition équivalente (article 3.6)
Prestataire de services d’exécution des commandes	« Toute personne physique ou morale qui offre, dans le cadre d’une activité commerciale, au moins deux des services suivants : entreposage, conditionnement, étiquetage et expédition d’un produit, sans être propriétaire du produit concerné, à l’exclusion des services postaux au sens de l’article 2, point 1), de la directive 97/67/CE du Parlement européen et du Conseil (19), des services de livraison de colis au sens de l’article 2, point 2), du règlement (UE) 2018/644 du Parlement européen et du Conseil (20), et de tout autre service postal ou service de transport de marchandises » (article 4.13)	Le prestataire de services d’exécution des commandes peut être tenu responsable « dans le cas d’un fabricant d’un produit ou d’un composant établi en dehors de l’Union, et sans préjudice de la responsabilité de ce fabricant : iii) en l’absence d’importateur établi dans l’Union ou de mandataire, le prestataire de services d’exécution des commandes » peut être tenu responsable (article 8.1.c.i). Le prestataire de services d’exécution des commandes peut être tenu solidairement responsable avec d’autres opérateurs (article 12).
Distributeur	« Toute personne physique ou morale faisant partie de la chaine d’approvisionnement qui met un produit à disposition sur le marché, autre que le fabricant ou l’importateur de ce produit » (article 4.14)	« Les États membres veillent à ce que, lorsqu’un opérateur économique parmi ceux visés au § 1 et établis dans l’Union ne peut être identifié, chaque distributeur du produit défectueux soit responsable quand : a) et b) » (art 8.3) Le distributeur peut être tenu solidairement responsable avec d’autres opérateurs (article 12).	Le distributeur peut être exonéré de sa responsabilité lorsqu’ « il n’a pas mis le produit à disposition sur le marché » (article 11.1.b)	Définition équivalente (article 3.17)	Définition équivalente (article 3.7)
Fournisseur de plateforme en ligne	Non clairement définit (article 8.4 : « permet aux consommateurs de conclure des contrats à distance avec des professionnels et qui n’est pas un opérateur économique ») mais les plateformes en lignes sont définies à l’article 4	Le fournisseur de plateforme en ligne peut être tenu responsable s’il permet une conclusion de contrats directe entre un consommateur et un opérateur économique (article 8.4). Le fournisseur de plateforme en ligne peut être tenu responsable solidairement avec d’autres opérateurs (article 12).

II – Impact de la Directive vis-à-vis de l’Open Source

A – Le principe d’une responsabilité réservée uniquement à l’Open Source Commercial

Pour rappel, la quasi-totalité des licences Open Source prévoient des clauses limitant ou excluant toute responsabilité et toute garantie de la part des auteurs du logiciel.

Les exceptions notables sont des licences qui prévoient des limitations spécifiquement adaptées à la règlementation nationale (telles l’EUPL, les licences CeCILL ou l’OSL) ou encore des licences particulièrement lapidaires (telle la licence WTFPL) pour lesquelles l’usage recommandé est généralement l’ajout d’un texte complémentaire excluant toute garantie et responsabilité.

Néanmoins, cette sécurisation contractuelle n’est pas efficace dans le cadre de la directive qui établit un régime dit d’ordre public (plus précisément d’ordre public de protection¹⁰, au sens qu’il ne peut être revendiqué que par les personnes pour qui ce régime a été prévu) qui ne peut valablement être remis en cause contractuellement ou même par une loi nationale (article 15). Ainsi, et la directive le rappelle, la responsabilité des opérateurs économiques (et en premier lieu les éditeurs/fabricants) pourra toujours être engagée par une personne physique sur la base de ce texte.

Néanmoins, les projets Open Source communautaires restent a priori non concernés par la directive en ce qu’ils ne sont pas en pratique « mis sur le marché » (ni même « mis en service », puisque cette notion repose sur une mise sur le marché). Afin d’éviter toute interprétation préjudiciable aux pratiques de l’Open Source, la NPLD prévoit ainsi une exclusion par principe de son champ d’application des « logiciels libres et ouverts dès lors qu’ils sont fournis en dehors d’une activité commerciale » (article 2.2).

Inversement, la responsabilité des opérateurs économiques sera recherchée « lorsque le logiciel est fourni en échange d’un prix, ou en échange de données à caractère personnel utilisées non exclusivement pour améliorer la sécurité, la compatibilité ou l’interopérabilité du logiciel, et lorsqu’il est donc fourni dans le cadre d’une activité commerciale » (considérant 14). De plus, la NPLD s’appliquera au fabricant d’un produit mis sur le marché et intégrant un logiciel libre et ouvert (considérant 15), que le produit final soit Open Source ou non.

Ainsi, « la responsabilité du fabricant visée au premier alinéa, point a), couvre également tout dommage causé par un composant défectueux lorsqu’il a été intégré dans un produit ou interconnecté avec celui-ci sous le contrôle de ce fabricant » (article 8). En pratique, cette règlementation rappelle aux organisations qui intègrent des centaines, voire des milliers de composants Open Source à leurs produits numériques, qu’elles seront responsables de toute défectuosité des produits et, notamment, de celle imputable à l’usage de ces composants Open Source.

L’exclusion des logiciels libres et ouverts du champ d’application de la directive s’explique au-delà de la volonté de la commission « d’encourager la recherche et l’innovation dans le cadre des logiciels libres et ouverts » (considérant 14) et de préserver et encourager l’écosystème collaboratif et non lucratif du logiciel libre, par le fait que ces logiciels ne répondent pas au critère de « mise sur le marché » ou de « mise en service » (qui renvoie à la notion d’activité commerciale). Une analyse approfondie du sujet avait été réalisée dans le Guide de conformité au Cyber Resilience Act à destination des acteurs de la filière Open Source¹¹. La directive mentionne que la responsabilité est engagée si le logiciel est fourni en échange de données personnelles « non exclusivement pour améliorer la sécurité, la compatibilité ou l’interopérabilité », ce qui étend plus clairement aux modèles économiques « gratuits » reposent sur la collecte de données à d’autres fins (télémétrie pour l’UX, marketing, etc.)

B – Identification et responsabilisation des opérateurs économiques

Le principe est donc que les opérateurs économiques traditionnels (éditeurs (fabricants), distributeurs (entreprise de services du numérique – ESN), etc.) sont pleinement responsables des logiciels Open Source qu’ils intègrent dans leurs produits. À l’inverse, les principales fondations Open Source (Apache, Eclipse, Linux Foundation) ou autres organisations à but non lucratif seront a priori exclues du champ de la directive (considérant 15) malgré leur rôle central en termes de structuration de l’écosystème et de fourniture d’une infrastructure qui, bien que non commerciale, est nécessaire à opérateurs économiques.

Certaines situations spécifiques aux équilibres de l’Open Source risquent néanmoins d’être plus complexes à appréhender. Ainsi, compte tenu de la multiplicité des opérateurs économiques potentiellement en cause, les juges devront certainement opérer au cas par cas avec quelques situations heureusement clarifiées par la directive :

• Le développeur initial d’un logiciel Open Source développé ou fourni dans le cadre d’une activité commerciale est considéré comme son fabricant et donc responsable d’un éventuel dommage causé par celui-ci (lecture a contrario du considérant 15) ;
• Celui qui modifie et distribue à son tour le logiciel sera aussi responsable, sauf à ce qu’il puisse prouver que ses modifications n’ont pas été de nature à générer la défectuosité ;
• Si un tel logiciel Open Source est intégré au sein d’un produit autre, également destiné à usage commercial et à une mise sur le marché, alors le développeur initial et le fabricant du produit final sont tous deux responsables du dommage causé par le produit final du fait d’une défectuosité du logiciel (article 8.1.b) — sauf si le logiciel Open Source a été modifié d’une manière telle à générer une telle défectuosité ;
• Inversement, si le logiciel Open Source ayant fait l’objet d’une intégration n’a pas été développé ou fourni dans le cadre d’une activité commerciale, seul le fabricant du produit final ayant causé un dommage sera responsable de ce dernier ;
• etc.

III – Pour finir

A – Quelques questions en suspens

Concernant la définition de logiciels libres et ouverts

À noter que la directive ne semble pas définir précisément ce que sont les « logiciels libres et ouverts » et qu’il serait ainsi tout à fait utile que le législateur français clarifie ce point dans le cadre de la transposition du texte (comme l’a fait plus clairement le législateur européen dans le règlement CRA). Tout au plus, retrouve-t-on des éléments complémentaires dans les considérants :

• (14) Les logiciels libres et ouverts, dont le code source est ouvertement partagé et qui permettent aux utilisateurs d’avoir librement accès au logiciel ou à ses versions modifiées et de les utiliser, modifier et redistribuer librement, peuvent contribuer à la recherche et à l’innovation sur le marché. Ce type de logiciel est soumis à des licences qui donnent à tous la liberté d’exécuter, de copier, de distribuer, d’étudier, de modifier et d’améliorer le logiciel. Afin de ne pas entraver l’innovation ou la recherche, il convient que la présente directive ne s’applique pas aux logiciels libres et ouverts développés ou fournis en dehors du cadre d’une activité commerciale, étant donné que les produits ainsi développés ou fournis ne sont, par définition, pas mis sur le marché. Le développement de ces logiciels ou la contribution à ces logiciels ne devraient pas s’entendre comme leur mise à disposition sur le marché. La fourniture de tels logiciels dans des référentiels ouverts ne devrait pas être considérée comme une mise à disposition sur le marché, à moins que cela ne se produise dans le cadre d’une activité commerciale. En revanche, il convient que la présente directive s’applique lorsque le logiciel est fourni en échange d’un prix, ou en échange de données à caractère personnel utilisées non exclusivement pour améliorer la sécurité, la compatibilité ou l’interopérabilité du logiciel, et lorsqu’il est donc fourni dans le cadre d’une activité commerciale.
• (15) Lorsque des logiciels libres et ouverts fournis en dehors du cadre d’une activité commerciale sont ensuite intégrés par un fabricant en tant que composants dans un produit dans le cadre d’une activité commerciale et sont ainsi mis sur le marché, il convient que ce fabricant puisse être tenu pour responsable des dommages causés par la défectuosité du logiciel concerné, mais pas le fabricant du logiciel puisque celui-ci ne remplirait pas la condition relative à la mise sur le marché d’un produit ou d’un composant.

Quant à la forme du logiciel

Il est intéressant de noter que le considérant 13 rappelle que « les informations ne doivent pas être considérées comme un produit, et les règles en matière de responsabilité du fait des produits ne devraient donc pas s’appliquer au contenu des fichiers numériques, tels que les fichiers médias, les livres électroniques ou le simple code source des logiciels. » La directive n’apporte pas d’autres précisions quant aux autres formes du logiciel (code source, code compilé, etc.) qui, a priori, sont donc sans incidence quant aux responsabilités prévues par la directive.

On peut, par une lecture extensive du considérant 15¹² assumer une responsabilité de l’opérateur compilant le code, ou mettant à disposition le logiciel fonctionnel, mais sans pouvoir garantir une telle interprétation. Or, comme le souligne le projet Debian, le manque de certitude et de sécurité juridique sera nécessaire préjudiciable au partage de code libre et ouvert¹³.

Quant à l’évolution du code et au « contrôle du logiciel »

Conformément au fonctionnement des projets Open Source, le code des composants intégrés au sein d’un produit donné continuera d’évoluer et certaines de ces évolutions pourront être automatiquement être intégrée dans le produit du fabricant sans nécessairement qu’il ait pleinement pris conscience et validé les modifications apportées (sur le composant ou son interaction avec le reste du produit) lorsqu’il dépend de milliers, voire de dizaine de milliers de composants Open Source tiers.

Cet usage, à de multiples reprises constaté, interroge potentiellement la qualification d’un élément « sous le contrôle » du fabricant en même temps qu’il rappelle la nécessité d’avoir une connaissance complète (au sein d’une nomenclature logicielle, dite software bill of material (SBOM)) des composants et services tiers, remet en avant la question de l’outillage et des pratiques internes ainsi que la définition de « bonnes pratiques » susceptibles d’être alléguées par le fabricant. Il rappelle aussi la nécessité de prendre en compte la composante humaine des projets Open Source (notamment lorsque l’organisation du projet peut avoir une déficience de gouvernance qui permet l’acceptation de certaines contributions introduisant – volontairement ou non – des déficiences), ce que ne fait pas en l’état la directive.

B – Perspectives et réflexions

À l’instar du CRA, l’exclusion du champ d’application de la NPLD des logiciels libres et ouverts qui ne sont ni développés ni fournis dans le cadre d’une activité commerciale permet de sécuriser l’écosystème de contributeurs et mainteneurs actuels, tout en faisant reporter cette charge sur les opérateurs économiques (qu’ils soient ou non fortement impliqués dans l’écosystème des projets Open Source).

Cette répartition de la responsabilité entre les différents opérateurs économiques vise à préserver l’écosystème Open Source, en évitant de décourager les développeurs de logiciels Open Source à but non commercial de contribuer à des projets ouverts par crainte de responsabilisation. Ainsi, la directive devrait conduire les fabricants de produits finaux intégrant de tels logiciels à mettre en place des procédures de vérification de l’ensemble des composants logiciels (au travers SBOM, rendus centraux dans la mise en œuvre du CRA). Cela peut être vu comme une opportunité pour l’écosystème de l’Open Source afin d’avoir, demain, plus d’utilisateurs conscients et de contributeurs responsables. Même si la directive ne change pas, en pratique, le régime de responsabilité tel qu’il était appliqué devant les tribunaux en matière de composants logiciels intégrés, elle met en lumière des responsabilités pas toujours assumées par les acteurs économiques pour qui l’usage de l’Open Source est avant tout un gain économique (de temps, de développements) et la nécessité de revoir les contrats avec les fournisseurs, d’auditer les dépendances et de mettre en place des politiques de validation des mises à jour.

Il y aura ainsi certainement un temps de réalignement nécessaire entre les projets et les opérateurs impliqués. Ce réalignement ira de pair avec beaucoup de questions se posant dès à présent, à l’instar de celle posée le projet Debian : « knowing whether software is commercial or not isn’t feasible, neither in Debian nor in most free software projects – we don’t track people’s employment status or history, nor do we check who finances upstream projects (the original projects that we integrate in our operating system). ». L’écosystème Open Source pourra cette fois s’appuyer sur le travail conséquent réalisé lors de la publication du CRA afin d’adresser certaines problématiques se retrouvant dans la mise en application des deux textes¹⁴.

Ainsi, si l’analyse de l’impact de la NPLD sur l’écosystème Open Source peut s’appuyer sur le travail mené dans le cadre de la mise en œuvre du CRA, elle implique également une étude spécifique et approfondie afin de s’assurer de sa bonne prise en compte des spécificités de l’Open Source.