Logiciel open source Docker et licences open source Conformité FOSS / Conformité Open Source
Faut-il uniquement respecter les conditions de licence pour l'image Docker ?
Non, si des images Docker ou d'autres images de solutions de virtualisation de conteneurs sont utilisées, les conditions de licence de tous les composants logiciels doivent être respectées. Dans ce cas, en raison de la "couche" supplémentaire apportée par Docker ou l'autre solution de conteneur, il convient de respecter les conditions de licence pour le logiciel contenu dans l'image et, en outre, les conditions de licence pour le logiciel au niveau du conteneur. Au niveau du conteneur, il faut donc respecter par exemple les conditions de licence pour les scripts de construction.
Peut-on se fier aux indications fournies par des portails tels que Docker Hub ou Git Hub ?
Sur les portails tels que Docker Hub, Git Hub et autres portails, on trouve souvent des indications sur les conditions de licence pertinentes. En règle générale, ces informations ne sont pas contraignantes. Si des informations incorrectes y figurent, il y a tout de même violation de la licence. Les indications figurant sur ces portails peuvent donc fournir une première orientation, par exemple lors de la recherche d'images appropriées. Avant l'utilisation définitive de l'image, il convient toutefois de vérifier les informations relatives à la licence.
Que faire si les données de licence de l'image Docker manquent ?
Il peut arriver que les conditions de licence pour les logiciels au niveau de la solution de conteneur, comme Docker, ne contiennent pas d'indications de licence. Que se passe-t-il alors ?
Les logiciels sont protégés par le droit d'auteur (du moins dans l'UE). L'auteur du logiciel détient les droits d'utilisation déterminants. Si les droits d'utilisation ne vous sont pas accordés par le biais de conditions de licence, les actes relevant du droit d'auteur, tels que les reproductions, ne peuvent pas être effectués. En l'absence de conditions de licence, vous ne pouvez donc pas utiliser l'image Docker.
Toutefois, l'absence de conditions de licence est généralement le résultat d'une erreur. Il peut être utile de prendre contact avec les auteurs afin de résoudre la situation. Les scripts de construction d'images Docker sont régulièrement placés sous la licence Apache License 2.0. En outre, des dispositions particulières peuvent découler des conditions générales de la plateforme utilisée. On y trouve parfois des dispositions selon lesquelles certains droits d'utilisation sont automatiquement accordés lorsque des contenus sont mis en ligne, sans que des conditions de licence particulières soient mentionnées.
Faut-il également tenir compte des conditions de licence des logiciels non utilisés ?
Les images Docker contiennent souvent un grand nombre de composants logiciels différents. Il est probable que vous n'ayez pas besoin de tous ces composants logiciels. Devez-vous également respecter les conditions de licence pour ces composants ?
Oui, car de tels composants logiciels sont également utilisés de manière pertinente du point de vue du droit d'auteur, par exemple en reproduisant l'image avec les logiciels qui ne sont pas techniquement nécessaires.
Quelle est l'étendue des obligations d'information ?
Il existe de nombreuses licences open source. La très grande majorité des licences open source contiennent - entre autres exigences - la condition de respecter certaines obligations d'information en rapport avec le type de licence concerné. Dans le cadre des images Docker et d'autres solutions de virtualisation de conteneurs, ces obligations d'information doivent également être respectées pour tous les "niveaux".
Toutefois, toutes les informations ne doivent pas nécessairement être fournies à un endroit précis. Les différentes conditions de licence contiennent en partie des exigences différentes. Par exemple, dans le programme finalement réalisé via l'image Docker ou une autre image, les conditions de licence applicables au moins à ce programme doivent être respectées et les informations correspondantes doivent être fournies.
Les logiciels peuvent-ils être utilisés dans le cadre d'images Docker ?
La question de savoir si certains logiciels peuvent être utilisés dans des images Docker est souvent négligée dans la pratique et reste non vérifiée. En fin de compte, il faut examiner les conditions de licence de chaque logiciel utilisé dans l'image Docker ou autre image pour répondre à cette question. Chaque auteur de logiciel peut avoir des exigences particulières à ce sujet. La plupart du temps, les conditions de licence open source typiques ne devraient toutefois pas poser de problèmes empêchant l'utilisation dans la pratique.
Une infection peut-elle se produire sur l'ensemble du conteneur ?
Certaines conditions de licence open source contiennent ce que l'on appelle l'effet copyleft, qui conduit à une "infection" de son propre logiciel ou d'autres logiciels. La General Public License (GPL) est probablement le type de licence le plus connu de ce genre. Si un composant logiciel sous GPL est utilisé de manière trop étroitement dépendante avec d'autres logiciels, par exemple le logiciel que l'on a soi-même programmé en complément, ces autres logiciels doivent - en résumé - être également licenciés sous GPL, c'est-à-dire qu'ils doivent être mis gratuitement à la disposition de tiers dans leur code source.
Dans le cas d'une utilisation propriétaire, il s'agit en général d'éviter à tout prix cet effet, car les investissements dans le propre logiciel ainsi que le savoir-faire de l'entreprise peuvent être perdus. Le problème se pose d'abord de manière directe en ce qui concerne les logiciels propres qui intègrent éventuellement des logiciels GPL.
On peut toutefois se demander si l'infection peut s'étendre à l'ensemble de l'image Docker ou à une autre image si elle contient un composant GPL. Il s'agit d'une question complexe qui doit être examinée en détail en tenant compte des composants logiciels contenus dans l'image Docker ou autre image. Par exemple, le noyau Linux est certes sous GPL, mais avec une exception spéciale pour les applications en espace utilisateur. Il convient alors d'examiner dans quelle mesure cette exception s'applique à l'image Docker concrète.
Au préalable, il convient toutefois d'examiner si le simple fait d'agréger des composants logiciels sous une licence copyleft, comme la GPL, crée une dépendance si étroite que l'effet copyleft et donc une "infection" se produisent. Il y a de bonnes raisons de penser que non, car la simple agrégation dans une image Docker ou autre peut être comparée à la simple distribution du composant copyleft dans une distribution Linux. Il n'existe toutefois pas encore de jurisprudence établie à cet égard. En outre, la jurisprudence actuelle suscite plutôt des doutes quant à la comparaison ci-dessus. Par exemple, le tribunal de grande instance de Berlin a décidé que le micrologiciel d'un routeur constituait une œuvre collective au sens de l'article 4, paragraphe 1, de la loi sur le droit d'auteur et que cette œuvre collective déclenchait l'effet copyleft de la GPL (LG Berlin, jugement du 08.11.2011, Az. 16 O 255/10 - "Surfsitter").
Conclusion
L'utilisation d'images Docker ou d'autres solutions de virtualisation de conteneurs permet d'utiliser une technologie moderne qui permet un "Continuous Deployment" et un "Continuous Delivery". Il ne sera plus possible de renoncer à cette technologie à l'avenir, en particulier sur les systèmes utilisés de manière intensive et qui ne permettent pas de temps d'arrêt. Toutefois, l'utilisation de cette couche logicielle supplémentaire ne simplifie pas les questions de licence en ce qui concerne les logiciels open source, mais ajoute plutôt une couche supplémentaire de complexité. L'ajout d'une autre "couche" par l'utilisation supplémentaire de solutions d'orchestration telles que Kubernetes (K8s) augmente encore le degré de complexité.
En règle générale, ces thèmes ne constitueront finalement pas un obstacle à l'utilisation dans la pratique. Toutefois, ils ne doivent pas être négligés et ne doivent pas rester sans aménagement juridique et factuel. Dans le cas contraire, on risque d'être confronté à des revendications également possibles par ailleurs, par exemple en matière d'injonction et de dommages et intérêts, ou du moins à un marketing négatif en raison de prétendues violations de licence.