Skip to Content

1.1. Prise en compte de la dimension contractuelle : processus d'analyse des licences

dim, 10/03/2010 - 22:20 — Benjamin Jean

Afin de maîtriser les enjeux liés au respect des licences, c'est-à-dire veiller à ce que la redistribution des résultats se fasse conformément aux termes des licences attachées à chacun des composants distribués, il est nécessaire de mettre en place une procédure adaptée dès la conception du logiciel. Celle-ci doit favoriser une interaction forte entre les équipes juridiques et techniques.

En effet, si la licence attachée aux développements spécifiques conçus dans le cadre d’un projet peut être sélectionnée de façon discrétionnaire, cette liberté est fortement limitée lorsque ces développements sont distribués en combinaison avec une multitude d'autres composants logiciels, tous ayant leur usage conditionné au respect de leur licence.

Ainsi, chacune des licences attachées aux composants du livrable doit être minutieusement analysée afin d'appréhender très justement sa portée et ses obligations : ce qui amène notamment à distinguer les licences permissives - seules les obligations doivent être transmises par les licences postérieures - de celles dites copyleft pour lesquelles tant les obligations que les droits doivent s'y retrouver1.

Ainsi, pour rester en cohérence avec certaines de ses obligations de licenciée, la société sera amenée à proposer une licence qui prendra la forme soit d'une Licence Open Source unique, soit d’une combinaison de licences Open Source.

Deux postulats gouvernent le choix de la ou des licences régissant le statut du produit final2 :

  • être en mesure de céder effectivement tous les droits que la licence finale confère aux licenciés subséquents ;
  • ne pas obliger moins ces derniers que ce à quoi l'on est soi-même obligé.
  • 1. Il convient dans les faits de procéder à une analyse fine des différents termes des licences afin d'apprécier in fine la compatibilité de la licence utilisée lors de la redistribution (sur ce point, cf. infra Par tie 3).
  • 2. In fine la compatibilité de la licence utilisée lors de la redistribution (sur ce point, cf. infra Par tie 3).

1.1.1. Tenue d'un inventaire

Tenir un état des lieux : exercice qui ne se réussit que dans la constance et la rigueur. La tenue d'un inventaire clair et précis des composants logiciels utilisés est une nécessité et nulle société ne peut en faire l'économie – ne serait-ce que parce qu'il s'agit bien souvent de l'objet même du contrat.

Simple formalisme lorsqu'il est intégré dans un processus de réutilisation de code tiers – ou véritable accouchement lorsqu'il est réalisé peu de temps avant la distribution, il convient de mettre en place un processus qui soit fluide et permette aux équipes juridiques et techniques d'interagir rapidement. Idéalement, il sera fluidifié par la mise en place d'un portail dédié qui permettra :

  • d'encadrer et de guider la reprise de composants Open Source (et donc d'éviter toute reprise non contrôlée),
  • d'unifier les versions des logiciels utilisés,
  • et de faciliter leur prise en main.

La maitrise de l'usage de l'Open Source (par exemple en fonction du type ou du domaine d'application) pourra aussi être envisagée au sein de la politique Open Source de la société (qu'elle soit éditrice, intégratrice ou simple utilisatrice de logiciel).

Préalable indispensable, c'est sur cette liste de composants et de licences que l'équipe juridique pourra ensuite se prononcer (la plupart du temps moyennant un certain nombre d'aller-retour pour obtenir les précisions nécessaires).

Back to Top

1.1.1.1. Rôle de l'équipe technique de développement ou de conception

Les processus varient et dépendent fréquemment de ceux déjà en place au sein de chaque structure, mais deux documents techniques (au moins) sont nécessaires :

  • Le premier pour réunir toutes les informations sur les composants inclus dans la solution – qu'il s'agisse de développements spécifiques ou non :
    • informations relatives aux composants (nom, URL d'origine),
    • à leur licence (nom, version, URL, éventuellement les termes additionnels qui conditionnent son usage),
    • et à leurs auteurs (nom, informations permettant de les contacter et éventuellement société).
  • Le second décrivant précisément toutes les interactions entre ces composants (il prendra généralement la forme d'un ou plusieurs schémas et/ou d'une présentation écrite/orale). Les différents types de relations seront bien renseignés :
    • relation explicite (l'appel du composant B est codé dans le composant A),
    • relation implicite (l'appel du composant B n'est pas codé en tant que tel dans le composant A, mais le composant A appelle d'autres composants par paramétrage et le projet B fait partie de ces composants),
    • relation possible (l'utilisateur de l'application fournie par le projet peut paramétrer lui même des relations entre les composants et un appel de B par A fait partie de cette éventualité).

Cette liste doit être mise à jour au fur et à mesure et il peut être nécessaire de conserver un historique de ce fichier. Il doit être à la disposition du service juridique et sera in fine annexé (de préférence en l'état) au contrat.

Back to Top

1.1.1.2. Rôle de l'équipe juridique

Se basant sur les documents élaborés par l'équipe technique, l'équipe juridique va réaliser un audit de l'ensemble des composants listés et décrits afin de déterminer :

  • si ceux-ci sont propriété (ou copropriété) de la société ou de ses partenaires,
  • si les licences utilisées sur les composants répondent à la politique de la société et/ou du projet.

En cas d'inadéquation, le problème sera relevé et transmis à l'équipe technique.

Les risques juridiques liés à une contestation de l'utilisation faite de composants par rapport à leur(s) licence(s) sont, par nature, à apprécier par les responsables de l'entreprise susceptibles d'être mis en cause. En conséquence, il est nécessaire que l'entreprise ait défini une politique en matière de licences, avant même qu'un premier projet ne soit réalisé. À défaut, il est prudent pour les équipes de développement de proposer et de faire valider a priori par les services juridiques une telle politique (qui peut limiter l'usage de certains composants logiciels, de certaines licences Open Source, ou mettre en place un processus particulier).

Par ailleurs, chaque licence présente dans le code fera l'objet d'une fiche synthétique permettant de faciliter la comparaison et d'apprécier leur portée respective1.

  • 1. Un exemple de fiche générique figure en annexe 2
Back to Top

1.1.2. Choix de la licence Open Source

Dans la mesure du possible, les équipes veillent à ce que les licences utilisées sur les composants développés spécifiquement permettent une reprise et une réutilisation de ces dernières. De plus, elles doivent être adaptées au type du logiciel, aux autres logiciels de la société, à l'écosystème dans ce domaine, etc.

Afin de faciliter le choix, une politique claire en matière de licence doit être décidée, rédigée et respectée. Le but ici est la livraison d’un logiciel « sécurisé », c’est-à-dire respectueux des licences applicables aux composants logiciels qui le composent – étant entendu que, bien souvent, la rédaction de cette politique traduira l'acceptation d'un niveau de risque juridique.

Par ailleurs, dans un objectif de simplicité, les logiciels seront distribués en limitant au strict minimum le nombre de licences différentes utilisées (Cf. infra Partie 3 décrivant les exceptions et interprétations qui permettent de réutiliser des licences tout en les adaptant aux besoins spécifiques).

Back to Top


Theme by Dr. Radut.