Comment vérifier qu'un code généré ne viole pas une licence tierce ?

Introduction

La vérification des licences est devenue une exigence opérationnelle autant que juridique. Elle repose sur trois moyens complémentaires, dont aucun ne suffit seul.

Le premier moyen : l’analyse de composition logicielle

Elle identifie les composants tiers déclarés dans le projet et leurs licences.

Elle produit un inventaire complet, avec les versions et les licences applicables.

Elle détecte les vulnérabilités connues affectant ces composants.

Elle est intégrable dans la chaîne de construction, avec un blocage en cas de licence non autorisée.

Sa limite est essentielle : elle ne détecte que les composants déclarés, non les portions de code reproduites.

Le deuxième moyen : la détection de similarité

Elle compare le code du projet à des bases de code public.

Elle identifie les portions correspondant à des projets existants et signale les licences applicables.

C’est le seul moyen de détecter une reproduction non déclarée.

Sa limite tient à la couverture de sa base de comparaison et au seuil de similarité retenu : un seuil trop bas produit du bruit, un seuil trop élevé laisse passer des reproductions partielles.

Son intégration dans la chaîne de construction est souhaitable, à défaut une exécution périodique sur l’ensemble du projet.

Le troisième moyen : la revue humaine

Elle détecte les indices que les outils ne signalent pas.

Mentions de licence ou de droits d’auteur apparaissant dans le code.

Commentaires en langue étrangère ou faisant référence à un projet.

Noms de variables ou de fonctions sans rapport avec le contexte.

Structures manifestement importées, avec une cohérence interne différente du reste du projet.

Elle doit être ciblée sur les portions substantielles et sur les fonctions sensibles, une revue exhaustive n’étant pas praticable.

Les filtres des outils

Ils constituent une ligne préalable.

Les principaux outils proposent des fonctions destinées à supprimer les productions correspondant à du code public.

Leur activation est fréquemment une condition du bénéfice des garanties offertes.

Elle doit être vérifiée, documentée et jamais désactivée.

L’inventaire

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

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

Il constitue la pièce demandée lors des audits et alimente la documentation technique.

Pour les produits comportant des éléments numériques, une nomenclature des composants figurera dans la documentation technique exigée par le règlement européen sur la cyberrésilience, à compter de sa pleine application en décembre 2027, les obligations de signalement des vulnérabilités étant quant à elles applicables depuis le 11 septembre 2026.

La politique de licences

Elle traduit la vérification en règles.

Une liste de licences autorisées, généralement les licences permissives.

Une liste de licences soumises à validation, selon le mode d’intégration et le mode de distribution du produit.

Une liste de licences interdites, notamment les licences réseau pour un produit exploité en ligne.

Une procédure de dérogation, tracée.

Cette politique doit être connue des équipes et appliquée par la chaîne de construction, non seulement écrite.

La double analyse selon le mode de distribution

Un même composant peut être acceptable dans un service en ligne et prohibé dans une version installable.

La politique doit donc distinguer les modes de distribution du produit.

Un éditeur proposant plusieurs modes doit maintenir deux analyses.

La conservation des rapports

Elle est la finalité juridique de l’ensemble.

Les rapports d’analyse, de détection de similarité et de revue doivent être conservés, datés.

Ils démontrent la diligence en cas de réclamation et constituent la réponse aux questionnaires d’audit.

Un dispositif de vérification non documenté a la même valeur qu’un dispositif inexistant.

Le traitement des alertes

Une procédure doit être définie : qui analyse, dans quel délai, selon quels critères, et comment la décision est tracée.

Une alerte ignorée est plus dommageable qu’une absence de vérification : elle établit la connaissance du risque.

Automatiser plutôt que vérifier ponctuellement

Une vérification manuelle est obsolète dès la contribution suivante. Notre expertise en droit du numérique construit ces dispositifs.

En résumé

• Trois moyens complémentaires : composition logicielle, détection de similarité, revue humaine.
• L’analyse de composition ne détecte que les composants déclarés.
• Activer et ne jamais désactiver les filtres des outils, condition des garanties offertes.
• Distinguer les modes de distribution : un composant acceptable en ligne peut être prohibé installé.
• Conserver les rapports datés : un dispositif non documenté vaut un dispositif inexistant.