Le Cyber Resilience Act, règlement (UE) 2024/2847, ne s'applique aux logiciels libres et open source que lorsqu'ils sont « mis à disposition sur le marché », c'est-à-dire fournis « dans le cadre d'une activité commerciale ». Les trois cas, un projet non monétisé, un produit construit sur des composants open source et le gestionnaire de logiciels libres, viennent du règlement lui-même. Ce que le règlement ne fait pas, c'est dire quand un projet qui accepte de l'argent, offre du support, propose un palier payant ou est financé par une entreprise franchit la ligne. Les considérants 15 et 18 donnent la direction ; les orientations de la Commission du 27 juillet 2026, C(2026) 5252, section 3, paragraphes 42 à 89, donnent les tests, et 22 exemples traités numérotés de 13 à 34.

Cet article est cette section. Il est écrit pour les trois personnes qui posent la question : le mainteneur avec un lien de don, l'entreprise avec une édition communautaire et une édition entreprise, et la fondation.

D'abord, ce qui compte comme open source

L'article 3(48) définit le logiciel libre et open source comme « un logiciel dont le code source est ouvertement partagé et qui est mis à disposition sous une licence libre et open source prévoyant tous les droits permettant de le rendre librement accessible, utilisable, modifiable et redistribuable ». Le paragraphe 44 y lit deux conditions cumulatives : une licence accordant l'ensemble des droits, et un code source ouvertement partagé. Le paragraphe 46 en tire la conséquence pour les modèles « source disponible » et réservés aux clients : un logiciel « dont le code source n'est partagé (ou autorisé à être partagé) qu'avec des clients payants ou un groupe limité d'utilisateurs ne doit pas être considéré comme un FOSS ». Les orientations ne nomment aucune licence. Elles nomment les deux conditions.

Qui est responsable : les mainteneurs, pas les contributeurs

Avant de demander si un projet est commercial, le paragraphe 48 demande si c'est vous qui le fournissez. Paragraphe 49 : un logiciel open source est « sous la responsabilité » des personnes « qui le publient et exercent le contrôle principal sur son développement, ses versions et ses décisions de distribution (souvent appelées "mainteneurs") ». Les contributeurs, qui « contribuent au code source mais ne contrôlent pas les versions, les feuilles de route ou les décisions de gouvernance », ne sont pas responsables, « même s'ils y ont contribué du code », et « la simple existence d'autorisations techniques, telles qu'un accès en écriture, n'est pas suffisante ». L'exemple 13 est la pull request : la personne qui soumet un correctif que les mainteneurs examinent et fusionnent « est un "contributeur" et n'est pas soumise au CRA ».

Les paragraphes 86 et 87 bouclent la boucle pour les entreprises : un fabricant qui intègre un composant et contribue à sa maintenance ne devient pas responsable de ce composant, et intégrer un composant dans un produit monétisé « n'a aucune incidence sur le statut de ce composant FOSS au titre du CRA ». L'application du règlement à un composant « dépend uniquement de la question de savoir si la personne physique ou morale qui le publie le met sur le marché ».

Les sept tests

1. Faire payer le logiciel. Paragraphe 51 : faire payer le logiciel lui-même, « par exemple en faisant payer les binaires précompilés », c'est le mettre sur le marché, et la personne qui fait payer est un fabricant.

2. Une édition payante à côté d'une édition gratuite, open core compris. Le paragraphe 52 les traite comme deux produits. La version payante est mise sur le marché ; « la version fournie gratuitement (ou version communautaire) n'est pas monétisée et n'est donc pas considérée comme mise sur le marché ». Cela vaut « lorsque la version payante est une version commerciale "enrichie", qui étend la base de code de la version fournie gratuitement, ou incorpore cette version dans un produit plus large (par exemple dans le cas du modèle "open core") ». Le paragraphe 53 ajoute le piège pour les entreprises : une personne morale qui fournit la version communautaire en est le gestionnaire ; une personne physique est hors du règlement pour celle-ci.

3. Monétiser d'autres services par le logiciel, ou exiger des données personnelles. Paragraphe 54 : un projet est mis sur le marché lorsque l'éditeur « monétise d'autres produits comportant des éléments numériques ou services » par son intermédiaire, ou « exige comme condition d'utilisation le traitement de données à caractère personnel pour des raisons autres qu'exclusivement l'amélioration de la sécurité, de la compatibilité ou de l'interopérabilité du logiciel ». L'exemple 14 est une application de place de marché gratuite qui gagne des commissions ou de la publicité ; l'exemple 15 un client VPN gratuit qui vend l'accès à des serveurs supplémentaires ; l'exemple 16 une application de fitness gratuite dont l'utilisation est conditionnée au traitement de données pour de la publicité ciblée. Les trois sont sur le marché.

4. Les services de support. Les paragraphes 55 à 57 tracent la ligne sur laquelle vivent la plupart des entreprises open source. Offrir du support payant ne rend pas « en tant que tel » le logiciel commercial : « le facteur décisif est de savoir si l'accès au FOSS lui-même, y compris sa maintenance, est conditionné à une rémunération, plutôt que la simple offre de services professionnels autour d'un produit librement disponible ». L'exemple 18, un outil en ligne de commande librement téléchargeable avec du conseil payant optionnel, n'est pas sur le marché. L'exemple 17, un système d'exploitation avec une version payante « qui comprend des services de support, tels qu'une assistance technique ou une optimisation des performances », l'est, et le paragraphe 57 le dit « indépendamment du fait qu'un logiciel fonctionnellement équivalent soit également disponible gratuitement ». Pour les particuliers, le paragraphe 58 ajoute la règle de recouvrement des coûts du considérant 15 : lier l'assistance à l'accès reste non commercial « si le prix demandé ne sert qu'à récupérer les coûts réels », lesquels « incluent les frais de subsistance raisonnables de la personne ».

5. Les dons. Paragraphe 61, d'après le considérant 15 : « accepter des dons sans intention de réaliser un profit ne devrait pas être considéré comme une activité commerciale », et un lien de don n'est pas une intention de profit « même lorsque le montant collecté par les dons dépasse les simples coûts », rémunération raisonnable des contributeurs et frais de subsistance compris. « Un FOSS soutenu uniquement par des dons est donc peu susceptible d'être considéré comme mis sur le marché. » Le paragraphe 62 donne l'exception : des dons « de facto équivalents à faire payer un prix », lorsque « l'accès au FOSS, à des fonctionnalités essentielles ou aux mises à jour est en pratique conditionné à un don ». L'exemple 21 ne fournit les versions et les mises à jour de sécurité qu'aux donateurs : sur le marché. L'exemple 22 publie le code source mais ne donne « les binaires précompilés, les mises à jour régulières et les correctifs de sécurité garantis qu'aux donateurs » : sur le marché.

6. Le sponsoring et le développement financé. Paragraphes 63 à 65 : subventions, bug bounties, sponsoring et développement de fonctionnalités rémunéré « ne devraient pas être pris en compte pour déterminer la nature commerciale de cette activité ». L'exemple 23 est une entreprise qui paie un mainteneur individuel pour ajouter une fonctionnalité ensuite ouvertement partagée ; le mainteneur n'a rien mis sur le marché, et l'entreprise doit la diligence raisonnable de l'article 13(5) lorsqu'elle intègre le résultat.

7. Les éditeurs à but non lucratif. Paragraphe 66 : une personne morale « constituée de manière à garantir que tous les revenus après coûts sont utilisés pour atteindre des objectifs non lucratifs » ne met pas son logiciel sur le marché, même lorsqu'il est directement monétisé. L'exemple 24 est un navigateur « directement monétisé par des partenariats avec des moteurs de recherche » dont les revenus après coûts vont à des objectifs non lucratifs : pas sur le marché, et l'éditeur est un gestionnaire.

Le paragraphe 67 ajoute le cas pour lequel tout le régime du gestionnaire existe : un logiciel « destiné à être intégré par d'autres fabricants dans leurs propres produits » n'est pas mis sur le marché à moins que l'éditeur ne le monétise aussi ; la personne morale qui le publie en est le gestionnaire si elle apporte un soutien durable. Les exemples 25 et 26 sont une bibliothèque d'interface et des implémentations de référence qu'une entreprise publie sans contrepartie.

Où atterrit chacun des trois

Les scénarios illustratifs de la section 3.5 projettent les tests sur des formes réelles, et trois d'entre eux couvrent la plupart des lecteurs.

Le mainteneur individuel avec un lien de don (exemples 27 et 34) : pas sur le marché, aucune obligation au titre du règlement, quel que soit le nombre d'entreprises qui dépendent du projet et quel que soit le montant de leurs dons. Les entreprises qui l'intègrent doivent la diligence raisonnable de l'article 13(5) et, au titre de l'article 13(6), doivent au mainteneur les signalements de vulnérabilités qu'elles trouvent et les correctifs qu'elles écrivent.

L'entreprise avec une édition communautaire et une édition payante (exemples 29 et 30) : fabricant pour l'édition payante, avec tout le règlement attaché, et gestionnaire pour l'édition communautaire qu'elle fournit gratuitement, avec les obligations allégées de l'article 24 attachées à celle-ci. Les paragraphes 72 à 74 disent expressément qu'une personne morale peut être les deux à la fois, projet par projet, et doit décider « pour chaque FOSS spécifique qu'elle publie » lequel elle est.

La fondation (exemples 28, 32 et 33) : un gestionnaire, qu'elle soit financée par des subventions publiques, des dons, des projets en partenariat ou des cotisations, pourvu qu'elle soit constituée de manière à ce que les revenus après coûts servent des objectifs non lucratifs et qu'elle soutienne le logiciel. Ses membres et financeurs ne sont pas responsables de la conformité du logiciel ; les fabricants qui construisent dessus doivent la diligence raisonnable.

Ce qu'il faut écrire

Pour chaque projet que vous publiez, une page : s'il remplit les deux conditions de l'article 3(48) ; qui exerce le contrôle principal sur les versions ; lequel des sept tests, le cas échéant, il remplit, avec le numéro de l'exemple auquel il ressemble ; et le rôle qui en résulte, fabricant, gestionnaire ou ni l'un ni l'autre. Une entreprise qui publie plusieurs projets écrit cette page plusieurs fois, parce que le paragraphe 74 dit que la réponse est par projet. Un fabricant qui intègre des composants open source ne l'écrit pas pour eux ; il consigne à la place la diligence raisonnable de l'article 13(5) et les signalements en amont de l'article 13(6), là où les douze étapes les placent.

Sources

  • Règlement (UE) 2024/2847, article 3(14) et (48), article 13(5) et (6), article 24, considérants 15, 18 et 19.
  • Commission européenne, orientations de la Commission sur l'application du règlement (UE) 2024/2847, C(2026) 5252 final du 27 juillet 2026, annexe, section 3, paragraphes 42 à 89 et exemples 13 à 34.

Ceci n'est pas un avis juridique. La section 3 fait quatorze pages, et les 22 exemples sont la partie à lire ; la plupart des projets se reconnaîtront dans l'un d'eux.