1. Une ligne de code à trente millions

Clodomir est CEO d’un SaaS spécialisé dans l’orchestration de funnels d’achat.
Après une levée de fonds en Série A « réussie », la société prépare un deuxième tour de financement avec l’ambition de lever 30 millions d’euros.

Assez vite après le début de la due diligence, l’équipe reçoit une question de la part des avocats des investisseurs sur le produit :

« Pourriez-vous nous fournir la liste précise des composants open source qui sont utilisés dans le produit, la fonctionnalité concernée ainsi que la licence applicable ? »

Clodomir transfère l’email à son CTO, accompagné d’un « Priorité absolue : peux-tu faire me faire le point sur ça d’ici 24h maximum ? »

ATTENTION FLASHBACK

Retour en arrière : deux ans plus tôt.

Deux ans plus tôt, le produit souffrait de trop de frictions sur le parcours utilisateur.

Cela créait des lenteurs importantes qui agaçaient les clients et faisaient exploser le churn.

Clodomir avait mis la pression à Paul son CTO : « Tu as une équipe de 5 dévs à plein temps, maintenant tu me règles ce problème d’ici la semaine prochaine ou on va avoir besoin d’une conversation sérieuse toi et moi ».

Paul avait été soulagé de trouver une bibliothèque open source permettant d’intégrer exactement la fonctionnalité dont il avait besoin. Une bibliothèque c’est un morceau de code développé, librement accessible et réutilisable pour répondre à son besoin.

Pas besoin de tout coder, seulement à intégrer le code déjà prêt.

La bibliothèque en question était distribuée en double licence :

• Soit l’option 1 : la licence GNU-GPL v2, gratuite, mais contraignante : publication du code, mention des auteurs, redistribution libre.
• Soit l’option 2 : la licence commerciale, payante, avec support.

Paul avait choisi l’option 1 dans un premier temps pour voir si cela réglait rapidement le problème. Il n’avait pas envie de tendre encore un peu plus son boss en réclamant du budget supplémentaire.

A ce moment-là, le CTO avait vaguement en tête qu’il y a des obligations à respecter pour utiliser un composant sous licence GNU-GPL mais se dit qu’il verra ça plus tard lorsque cela sera déployé.

Finalement, le « plus tard » se transforme en deux ans.

RETOUR AU PRESENT

C’est en lisant les emails des avocats que Clodomir lui transfère, accompagnés d’un « tu peux me faire le point sur ça ? », que Paul retrouve la mémoire.

Le CTO a deux options.

Option 1 : Soit il s’explique :

– Il devra dire qu’il a intégré une brique GNU-GPL sans respecter les conditions de la licence

– Il devra admettre que, par sa négligence, le produit est passé sous licence GNU-GPL, avec à la clé l’obligation de publier le code.

Clodomir ne va pas du tout apprécier car cela pourrait mettre en péril la levée de fonds.

Option 2 : Soit il se tait pour gagner du temps et espérer que personne ne creusera le sujet (ou qu’il partira avant).

Il fixe l’écran. Il décide de la jouer à pile ou face.

Pile : il parle. Face : il enterre.

De l’autre côté du mur, Clodomir est au téléphone. Il parle de valorisation et rêve encore de sa levée à 30 millions d’euros.

A votre avis, que s’est-il passé ?

2. Open source ≠ open bar

Depuis quelques années, c’est acté : violer les conditions d’une licence open source n’est pas un simple écart contractuel mais une contrefaçon.

Cette position a été confirmée :

· par la CJUE (18 décembre 2019, IT Development c/ Free Mobile, C-666/18), qui considère que le Anon-respect d’une clause liée à la propriété intellectuelle dans une licence logicielle relève de la contrefaçon,

· par la Cour de cassation (5 octobre 2022, n°21-15.386), et la Cour d’appel de Paris (14 février 2024, Entr’Ouvert c/ Orange).

Quel est l’impact ?

En cas de contrefaçon, le tribunal peut prendre en compte les éléments suivants dans l’évaluation des dommages et intérêts (article L331-1-3 du Code de la propriété intellectuelle) :

– La réparation des conséquences économiques négatives du fait de l’atteinte aux droits, dont le manque à gagner et la perte subis par la partie lésée

– Le préjudice moral causé au titulaire du droit, notamment lorsque le nom du titulaire n’a pas été cité

– Le montant des bénéfices injustement réalisés par le contrevenant.

C’est donc beaucoup plus vaste que lorsque la responsabilité est recherchée sur le fondement contractuel. A titre d’exemple, dans l’affaire Entr’Ouvert c/ Orange, Entr’Ouvert a obtenu plus de 800.000€ de dommages et intérêts.

Il est donc primordial de respecter les exigences des licences applicables aux composants open source qui seraient utilisés au sein d’une entreprise.

Par exemple, la licence GNU-GPL impose les exigences suivantes en cas d’intégration d’un composant :

• communiquer un avis de modification et les dates de modifications,
• redistribuer le logiciel final à titre gratuit sous la même licence,
• mettre à disposition l’intégralité du code source du logiciel final, et
• mentionner l’auteur du code au titre du droit à la paternité.

Ces exigences sont propres à chaque licence open source (et il y a en a des dizaines de différentes). Elles doivent donc être vérifiées au cas par cas pour ne pas risquer de commettre une contrefaçon.

A faire dès cette semaine si vous êtes juriste d’une entreprise de logiciels :

– Demandez au DSI/CTO une cartographie des composants open source critiques pour le produit et la licence associée

– Vérifiez la compatibilité entre les exigences de la licence et l’usage qui en est fait

– Conservez une preuve de la licence en vigueur au moment de l’intégration.

– Désignez un “réfèrent open source” dans l’équipe tech pour que vous soyez informez en temps utile de toute nouvelle décision de recourir à un tel composant.