Quelles obligations pour un SaaS utilisant des composants open source ?

Introduction

Tout logiciel moderne intègre des centaines de composants tiers. Leur conformité est rarement vérifiée avant qu’un acquéreur ou un investisseur ne la demande.

Les catégories de licences

Les licences permissives autorisent l’usage, la modification et la redistribution, sous réserve principalement de conserver les mentions de droits d’auteur et le texte de la licence.

Les licences à réciprocité, dites copyleft, imposent que les travaux dérivés soient distribués sous la même licence, avec mise à disposition du code source.

Les licences à réciprocité limitée n’imposent cette obligation que pour les modifications apportées au composant lui-même, non pour l’ensemble du logiciel qui l’utilise.

Les licences réseau étendent le déclenchement à l’utilisation du logiciel à travers un réseau.

Cette classification détermine l’exposition.

Le déclenchement par la distribution

La plupart des licences à réciprocité font naître leurs obligations lors de la distribution du logiciel, entendue comme sa mise à disposition de tiers.

L’exploitation d’un logiciel comme service, sans remise d’une copie à l’utilisateur, ne constitue généralement pas une distribution.

Cette analyse explique qu’un SaaS puisse intégrer des composants sous licence à réciprocité sans déclencher l’obligation de publier son code.

Elle doit toutefois être vérifiée composant par composant, les licences n’ayant pas toutes la même rédaction.

Les licences réseau

Certaines licences ont été rédigées précisément pour couvrir cette situation.

Elles prévoient que l’utilisation du logiciel modifié à travers un réseau déclenche l’obligation de mettre le code source correspondant à la disposition des utilisateurs.

L’intégration d’un composant sous une telle licence dans un SaaS peut donc imposer la publication du code des modifications, voire de l’ensemble selon la portée retenue.

L’identification de ces composants est le premier point de vérification.

Les autres situations de distribution

Un agent installé chez le client.

Une application mobile.

Une version installable sur site.

Un composant fourni au client pour intégration.

Une image de conteneur remise au client.

Chacune de ces situations constitue une distribution et déclenche les obligations correspondantes.

Un éditeur proposant à la fois un service en ligne et une version installable doit donc conduire deux analyses distinctes.

Les obligations des licences permissives

Elles sont légères mais réelles.

Conservation des mentions de droits d’auteur.

Reproduction du texte de la licence.

Mention des modifications, selon les licences.

Interdiction d’utiliser le nom des auteurs pour promouvoir le produit sans autorisation.

Leur méconnaissance constitue une contrefaçon, la licence étant un contrat dont le non-respect fait perdre l’autorisation.

Une page de mentions listant les composants et leurs licences satisfait l’essentiel de ces obligations.

L’inventaire des composants

Il est la base de toute démarche.

Il liste chaque composant, sa version, sa licence, son mode d’intégration et les obligations qui en découlent.

Il doit être produit automatiquement par la chaîne de construction, faute de quoi il devient obsolète immédiatement.

La documentation technique exigée par le règlement européen sur la cyberrésilience comportera une nomenclature des composants pour les produits comportant des éléments numériques, à compter de la pleine application du règlement en décembre 2027.

Les obligations de signalement des vulnérabilités de ce règlement sont quant à elles applicables depuis le 11 septembre 2026.

La gestion des vulnérabilités

Un composant obsolète ou non maintenu constitue un risque de sécurité et, désormais, un risque réglementaire.

Le suivi des vulnérabilités affectant les composants et l’application des correctifs doivent être organisés et documentés.

Ce point est examiné par les clients structurés et lors des audits.

La politique interne

Une liste de licences autorisées, de licences soumises à validation et de licences interdites.

Une procédure de validation avant l’ajout d’un composant.

Une vérification automatisée dans la chaîne de construction.

Une revue périodique de l’inventaire.

Cette politique évite l’introduction d’un composant contaminant, dont le retrait ultérieur peut imposer une réécriture.

L’enjeu lors d’une opération

L’audit d’un éditeur comporte systématiquement une revue des composants tiers.

La présence d’un composant sous licence réseau, ou d’un composant à réciprocité dans une version distribuée, constitue une réserve.

Sa régularisation peut imposer un remplacement, une réécriture ou l’acquisition d’une licence commerciale auprès de l’auteur, lorsque celle-ci existe.

Le délai nécessaire justifie d’anticiper cette revue bien avant l’opération.

Inventorier avant d’être audité

Un composant contaminant se remplace plus facilement à froid. Notre expertise en propriété intellectuelle, média et art conduit ces revues.

En résumé

• L’exploitation comme service ne constitue généralement pas une distribution.
• Les licences réseau font exception et peuvent imposer la publication du code.
• Agent installé, application mobile et version sur site constituent des distributions.
• Les licences permissives imposent la conservation des mentions, sous peine de contrefaçon.
• Produire l’inventaire automatiquement et anticiper la revue avant toute opération.