L’application d’une politique de logiciels libres en entreprise peut s’avérer rapidement d’une très complexité juridique et opérationnelle. Et pourtant, les avantages de l’open source sont nombreux : le tarif, la maîtrise, la flexibilité, la pérennité, la sécurité sont souvent des arguments avancés pour souscrire aux logiciels libres.

D’autres évoquent des risques juridiques liés à l’incertitude de leur utilisation et leur possible incompatibilité entre les logiciels protégés par un droit de propriété intellectuelle. La difficulté peut également provenir du très grand nombre de licences libres. Pour ne citer que quelques-unes : GNU LGPL V3 ; Mozilla Public License 2.0 ; Apache License 2.0 ; MIT License ; Ecplipse ; BSD 3 Clause ; GNU GPL V2 ; License QPL., etc.
Avançons ici quelques pistes pour construire une stratégie open source dans son entreprise.

Les grands principes.

Le logiciel libre repose sur une logique collaborative de la création, valorisant l’enrichissement de la connaissance par la communauté. Ainsi, par opposition au logiciel propriétaire, le logiciel libre implique nécessairement l’ouverture et la redistribution des codes, pour permettre cette émulation. A ce titre, la licence libre vise à encadrer l’utilisation d’un logiciel et à contraindre tout utilisateur d’un logiciel libre à respecter les principes régissant la communauté dans laquelle ce logiciel a été créé.

A ce titre, une licence libre vise nécessairement à garantir le respect des quatre libertés suivantes :
• La liberté d’exécuter / utiliser un programme ;

• La liberté d’étudier et d’adapter le programme ;

• La liberté de redistribuer des copies du programme ;

• La liberté de modifier et de publier les modifications apportées à un programme.

La licence libre se définit ainsi comme un contrat de cession non exclusive des droits d’exploitation sur un logiciel, par lequel le détenteur d’une copie dudit logiciel est autorisé à exécuter certains actes lui permettant d’exploiter le logiciel dans le respect des libertés précitées.

Les différentes licences.

Les différentes licences libres se distinguent les unes des autres en fonction de :

• Leur caractère appropriable : il convient de déterminer si un logiciel soumis à une licence libre peut être redistribué, seul ou modifié, sous une licence propriétaire, c’est-à-dire ne respectant pas les principes de l’open source et l’obligation d’ouverture des codes sources au bénéfice de la communauté.

• L’étendue de la licence : il convient d’identifier les éléments sur lesquels s’appliquent la licence. Il s’agit ici de déterminer le niveau de contamination de la licence afin d’établir dans quelle mesure les éléments qui sont rattachés à un logiciel soumis à une licence libre subissent également les contraintes de la licence et seront soumis aux mêmes obligations en cas de redistribution du logiciel modifié ou, tout au contraire, pourront être distribués sous une autre licence.

• L’élément déclencheur : il convient de déterminer l’acte qui emporte les effets contraignants de la licence. Le mouvement du logiciel libre reconnaît en effet la possibilité pour tout utilisateur d’utiliser comme il le souhaite un logiciel libre, et notamment sans respecter les conditions d’ouverture et de partage des codes sources, dans ce qu’il considère comme étant une utilisation relevant de la sphère privée. Il est important de relever que chaque licence définit selon des critères qui lui sont propres, quel élément déclenche l’applicabilité de la licence.

Sur la base de ces trois critères, il est possible de répartir les licences libres en deux grandes catégories.

D’une part, les licences dites « non permissives » ou à réciprocité, appelées également licences copyleft, qui imposent que toute redistribution du logiciel, modifié ou non, se fasse sous les termes de la même licence ou sous les termes d’une licence expressément désignée comme étant compatible.

L’objectif de ce type de licence est d’empêcher l’appropriation du code mis en open source dans un code propriétaire. Les libertés concédées sont ainsi persistantes d’un utilisateur à un autre.

L’effet du copyleft peut être plus moins fort. Ainsi, la licence sera à :

• copyleft fort lorsqu’elle présente un caractère très contaminant, imposant que la redistribution de l’ensemble des composants du logiciel modifié respecte les mêmes principes (éléments dérivés ou même simplement liés) ;

• copyleft faible lorsque la licence ne s’étend pas aux composants simplement liés au logiciel libre. Dans ce cas de figure, seul le logiciel dérivé est obligatoirement soumis à la persistance de la licence d’origine.

D’autre part, les licences dites « permissives » ou sans copyleft, qui prévoient que seules les obligations du récepteur du logiciel doivent être transmises, chaque utilisateur étant libre d’ajouter des obligations.

On distingue les licences concédant à l’utilisateur :

• Le droit d’assembler des composants au logiciel qui demeure soumis à leur propre licence lors de leur redistribution. Dans ce cas de figure, seul le logiciel dérivé, c’est-à-dire le logiciel dont le code aura été modifié, reste obligatoirement soumis aux termes de la licence d’origine en cas de redistribution. Une telle licence est dite « permissive en composition ».

• Le droit de redistribuer le logiciel modifié, que ce soit par dérivation (modification du code source) ou par composition (assemblage de plusieurs composants), sous une autre licence, y compris une licence propriétaire. Il s’agit de la licence la plus permissive, dite de renonciation, et communément appelée « licence permissive en composition et en dérivation ».

Les enjeux du logiciel libre.

Il découle de ce qui précède qu’en raison du caractère plus ou permissif des différentes licences libres, un logiciel peut se composer de plusieurs composants soumis chacun à des licences différentes. Or la cohabitation entre ces différentes licences au sein d’un même logiciel faisant l’objet d’une redistribution n’est possible que sous réserve que les différentes licences soient compatibles entre elles, à défaut la redistribution est impossible, sous peine de violer les engagements pris dans le cadre de chaque licence.

A ce titre, il est impératif d’apprécier les capacités de chaque composant d’un logiciel de cohabiter avec des composants soumis à des licences distinctes. Dans ce cadre, il convient de distinguer la compatibilité supérieure et la compatibilité inférieure des licences.

La compatibilité supérieure désigne la capacité d’un logiciel sous licence d’être soumis aux dispositions d’une autre licence que sa licence d’origine (pour un logiciel dérivé ou pour un logiciel composé) ou de cohabiter avec une autre licence dans un logiciel "plus grand" soumis à une autre licence (pour un logiciel composé uniquement). La compatibilité inférieure désigne la capacité d’une licence d’accueillir un composant ou un logiciel soumis à d’autres licences.

La compatibilité s’apprécie :

• Par rapport aux nouvelles versions de la licence. En effet, une licence s’apprécie au regard de la version dans laquelle elle est publiée. Il n’est pas rare que des versions successives d’une même licence emporte des obligations différentes, voire opposées et ne soient, dès lors pas compatibles entre elles.

• Par rapport aux clauses de la licence qui peuvent expressément prévoir la compatibilité avec des licences désignées comme compatibles, et sous quelles conditions elles sont compatibles.

• Par rapport au degré de permissivité de la licence en composition et/ou en dérivation, qui implique nécessairement une certaine compatibilité avec d’autres licences.
En d’autres termes, lorsqu’un utilisateur souhaite assembler plusieurs composants et/ou modifier tout ou partie du code source d’un logiciel, il doit apprécier les deux compatibilités de manière complémentaire.

Il est en effet impératif de vérifier :
(i) que le composant que l’on souhaite intégrer dans un logiciel soumis à une licence différente, peut être soumis à une autre licence ;
(ii) que le logiciel dans lequel le composant est intégré peut recevoir des composants soumis à une autre licence.

Une entreprise qui veut ainsi se lancer dans une véritable politique open source en effectuant un audit et sur cette base, analyser les risques liés à l’utilisation des licences visant à établir à quelle catégorie chaque licence appartient et leur niveau de compatibilité. L’établissement d’une gouvernance visant à déterminer des règles d’utilisation de chaque licence en fonction des situations est ensuite primordiale à mettre en place.

Comment y réussir ?

La gouvernance open source vise à définir l’ensemble des moyens à mettre en œuvre pour l’orientation, le contrôle et la coordination des équipes intervenant sur un projet open source afin d’assurer une gestion de projet optimal en termes d’efficacité et de sécurité.

Dans le cadre présent, la gouvernance vise à :
(i) Garantir une utilisation des modules de logiciels libres conformément aux termes des licences auxquelles ils sont soumis, notamment au regard de la compatibilité des licences entre elles, afin de prévenir tout risque de contrefaçon et de manquement contractuel engageant la responsabilité de la Société ;
(ii) S’assurer du choix des licences les plus adaptées en fonction de la finalité recherchée par la Société dans le cadre du développement d’un produit ou service incorporant des modules sous licence open source ;
(iii) Garantir la protection des intérêts, notamment au regard de la propriété intellectuelle et des enjeux économiques et concurrentiels de la commercialisation d’un produit ou service.

A ce titre, la gouvernance doit reposer sur trois axes :

• Premier axe : la mise en place d’une procédure de documentation par les services opérationnels des projets incluant de l’open source préalablement à leur mise en place, et tout au long de leur développement.

• Deuxième axe : la mise en place d’un comité de contrôle et de pilotage de la mise en œuvre de la politique open source de la Société, visant notamment à définir les risques et les gérer, ainsi qu’à faire évoluer, le cas échéant, la politique open source en fonction des besoins et de l’évolution de l’état de l’art.

• Troisième axe : la mise en place d’une procédure de gestion et de maintien de la conformité des pratiques au regard de la politique open source de la société.

Autrement dit, il est essentiel de :
• mettre à disposition des différents services un inventaire des licences open source dont l’utilisation est autorisée au sein de la société, contenant des fiches de présentation pratiques des caractéristiques de chaque licence et mis à jour régulièrement.
• mettre en place un code couleur permettant l’identification des licences et des projets en fonction de leur niveau de criticité et intégrer ce code dans l’inventaire des licences.
• éditer et mettre à disposition des différents services un guide pratique détaillant la politique open source de la Société et décrivant :
o comment qualifier la criticité d’un projet et d’une licence open source ;
o définir une politique de commercialisation des produits intégrant des modules open source ;
o les licences open source dont l’usage est autorisé, à l’exclusion de toute autre licence ;
o les règles d’utilisation et de contrôle des différentes licences mises en place par la Société et dont la mise en œuvre est garantie par le Comité de pilotage ;
o les cas de figure dans lesquels l’utilisation des licences est libre par les équipes, celle nécessitant l’accord du Comité de pilotage.

Le logiciel open source est donc certes libre …. mais parfois complexe à manier.
Cela ne veut pas dire qu’il faut renoncer, pour les entreprises qui souhaitent rester innovantes et concurrentielles, à réfléchir à mettre en place une vraie politique raisonnée de logiciels libres.

Jérôme Giusti, Associé fondateur de Metalaw Avocats associés Spécialiste en droit de la propriété intellectuelle et en droit des nouvelles technologies, de l'informatique et de la communication Géraldine Salord, Associé fondateur de Metalaw Avocats Associés Docteur en droit rpivé