Une interface VPN, un moteur GPL et un installateur : qu’est-ce qui est distribué ?

La question arrive comme une question de licence, mais la réponse commence par un inventaire. Une interface VPN, le moteur OpenVPN qu’elle pilote, une bibliothèque TLS et un installateur peuvent avoir quatre ensembles de conditions différents, et l’apparence du produit ne vous dit rien sur le fichier qui appartient à quel ensemble. Parcourez les artefacts dans l’ordre de leur distribution, et la question juridique devient bien plus étroite au moment où vous la confiez à quelqu’un de qualifié pour y répondre. Chaque étape la resserre davantage : ce qui est distribué, ce qui a été modifié et comment les parties communiquent.

Commencez par ce que l’installateur dépose sur le disque

Prenez l’installateur ou le paquet publié, pas une copie de développement, et listez chaque fichier qu’il place sur une machine propre. Notez les versions de l’interface, du moteur et de la bibliothèque TLS, et précisez si le moteur est un exécutable séparé ou une bibliothèque chargée dans le même processus.

Ce dernier fait façonne tout ce qui suit. Un exécutable séparé lancé via une socket soulève un ensemble de questions différent d’un code compilé en un seul binaire, et un installateur qui se contente de placer les deux côte à côte ne tranche pas la question dans un sens ou dans l’autre. Le regroupement est une décision d’empaquetage, tandis que la relation entre les programmes est d’ordre architectural.

Écrivez la liste avec les versions jointes, car les conditions diffèrent entre les versions majeures.

dpkg -L openvpn | head -n 40
openssl version -a

Séparez l’interface du moteur

Le fichier de copie d’OpenVPN indique la version 2 de la GPL et documente une exception de liaison pour OpenSSL, qui est une autorisation spécifique à portée définie et non une licence générale pour mélanger les conditions.

Capturez le texte de licence livré avec votre build, pas celui qui figure aujourd’hui sur le site du projet. Une publication qui a épinglé une branche plus ancienne porte le document de cette branche. Les captures d’écran d’une page de dépôt ne remplacent pas le fichier, car celui qu’il vous faut est à l’intérieur de l’artefact. Conservez-le à côté de l’installateur pour que le paquet soit complet.

Décrivez ensuite l’intégration honnêtement : l’interface lance-t-elle le moteur comme processus enfant et parle-t-elle un protocole textuel, ou lie-t-elle une bibliothèque et échange-t-elle des structures internes ? La seconde disposition est intime d’une manière que la première n’est pas, et c’est cette distinction qu’un relecteur demandera en premier.

Notez quels fichiers vous avez modifiés

Un code source modifié change l’analyse plus que n’importe quel détail d’empaquetage. Si vous avez corrigé le moteur, le correctif lui-même est une œuvre dérivée, et l’obligation pèse sur celui qui distribue le résultat.

Enregistrez chaque correctif, son objet et s’il a été envoyé en amont, car un correctif qui n’a jamais quitté votre dépôt fait toujours partie de ce que vous distribuez si vous distribuez le binaire.

Les fichiers de configuration, les thèmes et les traductions vivent généralement avec l’interface, mais une traduction qui intègre des chaînes du code du moteur rappelle discrètement que la frontière se situe par fichier et non par dossier. Conservez un diff entre la publication amont et votre build pour que la réponse soit disponible sur demande au lieu d’être reconstituée plus tard. Ce diff est aussi l’artefact le plus utile lorsqu’un auditeur demande ce qui a changé.

Vérifiez la version d’OpenSSL à part

OpenSSL 3.0 et les versions ultérieures sont distribués sous licence Apache 2.0, tandis que les versions plus anciennes portent les conditions OpenSSL/SSLeay. Ce sont des documents différents avec des obligations différentes, et un moteur intégré peut lier celui que votre système de build a trouvé.

Confirmez la version réellement livrée plutôt que celle nommée dans un script de build.

Une dépendance à OpenVPN ne transforme pas chaque modification d’OpenSSL en code GPL, et l’exception de liaison ne supprime pas les autres obligations liées à la redistribution de la bibliothèque. Traitez l’exception comme une clause d’une analyse plus large, et consignez les propres mentions de la bibliothèque TLS avec tout le reste.

Rassemblez le dossier de preuves

Le dossier comporte quatre parties : l’inventaire des fichiers avec les versions, la description de l’intégration, la liste des modifications avec les diffs et les textes de licence tels que livrés. Ajoutez le fichier de mentions que vous distribuez et l’endroit où le code source est proposé, si vos obligations exigent une offre.

Gardez le dossier sous un seul responsable pour qu’aucune publication ne puisse sortir sans lui.

Rien de tout cela ne tranche une question juridique, et c’est le but : cela donne à un relecteur qualifié les faits plutôt qu’un résumé assemblé de mémoire. La description marketing d’un fournisseur n’est pas une preuve de son architecture, et votre propre supposition à ce sujet n’en est pas une non plus.