Contraintes techniques

Que l'on veuille distribuer son logiciel sous une licence libre ou que l'on cherche simplement à respecter les termes de licences auxquelles on est soumis, différents critères « techniques » doivent être pris en considération :

• Les briques logicielles : est-ce que le logiciel est destiné à être utilisé par d'autres logiciels, ou peut-il l'être ?

• Utilisation par le réseau : est-ce que le logiciel est destiné à être utilisé comme un service — c'est-à-dire que ses fonctionnalités sont distribuées par le réseau sans que ce dernier le soit lui-même ?

La situation des logiciels destinés à être utilisés

Avant tout, un postulat : tout logiciel libre peut-être utilisé par d'autres logiciels, libres ou non, selon sa licence.

Néanmoins, certaines licences nécessitent que le logiciel utilisateur soit lui-même soumis à cette même licence. Cette transmission forcée de la licence est appelée copyleft. Et si cette contrainte peut être délibérée, voire conseillée, souvent pour des raisons philosophiques, afin de « forcer » la liberté des logiciels tiers, il a une répercussion très négative lorsque ces-dits logiciels tiers sont déjà sous une licence libre dont les termes ne sont pas compatibles (ou bien si plusieurs briques sous licences avec copyleft non compatibles sont réunies dans le même logiciel tiers).

Les logiciels libres étant réputés pour leur modularité, il fallut trouver des licences qui leur correspondent. Ainsi, plusieurs licences permettent au logiciel sur lequel elles portent d'être utilisé sans contraintes par d'autres.

Les licences copyleft ayant une étendue limitée

Parmi celles-ci, il faut distinguer celles qui permettent expressément cette utilisation de celles qui n'en ont que la conséquence.

Les licences permettant l'utilisation du logiciel

La licence la plus symbolique est ici la GNU Lesser General Public License (LGPL) : elle ressemble en tout point à la GNU GPL, à l'exception qu'elle permet expressément à un logiciel qui l'utilise de ne pas étendre la licence à ce logiciel utilisant (cf nouvelle LGPL). Ainsi, seul le logiciel utilisé reste obligatoirement libre, et la liberté qui lui est attachée est indéniablement pérenne.

Le problème de ce type de licence est qu'elle ne définissent pas l'acceptation que l'on doit avoir du terme d' « utilisation » et que, de fait, beaucoup de logiciels sont liés avec d'autres logiciels sous GNU LGPL sans être réellement « utilisé », mais plus pour étendre ces derniers. Dans un tel cas de figure, une application stricte de la licence revient à appliquer une étendue à la licence qui correspond à celle de la GNU GPL.

Les licences modulaires sont finalement plus simples à utiliser, comme nous allons le voir.

Les licences modulaires

Les premières licences modulaires apparues sont probablement la NPL (non libre) et la MPL, utilisée respectivement par Netscape et Firefox. Contrairement aux licences précédentes permettant l'utilisation, ces licences ont l'énorme avantage d'envisager une étendue « objective » des termes des licences.

Ainsi, celle-ci est le plus souvent limitée aux seuls fichiers contenant du code sous cette-dite licence. Pour l'exemple, tout fichier contenant du code sous MPL devra lui-même être licencié sous licence MPL (le critère est identique pour la licence française CeCILL-C, ou d'autres licences calquées sur la MPL comme la Nokia Public License).

En pratique l'utilisation de ce type de licences facilite énormément le développement de logiciels modulaire, mais multiplie aussi le nombre de licences qui peuvent porter au final sur un seul logiciel.

Les modérations de l'étendue de la licence

S'il est souvent plus simple de choisir la licence qui correspond au type de développement ou déploiement que l'on désire pour son logiciel, il peut aussi être opportun d'adapter une licence à ses attentes : en interprétant celle-ci (lorsqu'elle laisse place à interprétation), ou en ajoutant une exception, lorsque nécessaire.

Attention : ce mécanisme est particulièrement utile lorsqu'il consiste à conférer plus de droit, mais inversement désastreux lorsqu'utilisé dans l'autre sens puisqu'il fait perdre toute compatibilité à la nouvelle licence.

L'interprétation

Cette méthode est sujette à caution : il ne peut y avoir d'interprétation d'une licence que dès lors qu'il y a source d'interprétation... La technique permet alors de lever toute insécurité juridique en donnant expressément le sens qu'il faut donner aux termes litigieux.

Dans le cas contraire, le licencié se trouverait face à une contradiction au sein du contrat qui le lie au concédant, situation qui risque de lui profiter in fine (et donc aller à l'encontre de la volonté du concédant). En effet, la règle favorable à la personne qui se trouve devoir respecter deux termes contradictoires est habituellement retenue, annulant alors tous les effets recherchés par l'interprétation (mise en place par le concédant).

Pour pousser le raisonnement jusqu'à dans ses retranchements, il faut reconnaître qu'une telle conséquence ne serait réellement dommageable au concédant que dans l'hypothèse où l'interprétation était restrictive, et non dans le cas contraire. Dans le cas où elle conférerait en effet plus de droits, elle prévaudrait naturellement, étant plus favorable au licencié (dans ce cas précis, la règle la plus favorable au licencié serait celle édictée par le concédant).

Le meilleur exemple de cette technique est l'interprétation utilisée par Linus Torvalds pour l'utilisation de la GNU GPL sur le noyau Linux :

NOTE! This copyright does *not* cover user programs that use kernel

services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the linux kernel) is copyrighted by me and others who actually wrote it.

La technique de l'exception

L'idée de l'exception est bien de modifier la licence de base, en ajoutant dans une clause distribuée avec la licence (ou inscrite dans les en-têtes) une spécificité qui déroge aux termes de la licence de base. Ici, à la différence de l'interprétation, cette clause additionnelle peut être supprimée lors d'une redistribution si elle confère plus de droits au licencié, en l'absence de stipulation contraire ; tandis qu'elle ne pourra l'être si elle imposait des obligations supplémentaires (faisant de ce tout une nouvelle licence incompatible avec la dernière).

L'utilisation en tant que service

De plus en plus de logiciels ont vocation à être installés sur une seule machine, le serveur, afin que quiconque puisse l'utiliser via Internet. C'est ce que l'on appelle « Architecture orientée services » (Service Oriented Architecture, SOA), ou bien « Fournisseur de service d'application » (Application Service Provider, ASP). Dans une telle situation, le problème vient du fait que presque toutes les licences ne deviennent contraignantes qu'au moment où le logiciel est distribué, or il ne l'est pas lorsque seules ses fonctionnalités sont accessibles à l'utilisateur : en effet, l'objet de la protection, code source, objet,e etc?, reste sur le serveur, et donc les modifications apportées aussi.

Partant de ce constat, beaucoup d'entreprises ont pu se servir de ce que l'on a nommé l' « ASP loophole » pour utiliser à profusion des logiciels libres qu'elles ont modifier sans jamais en redistribuer les sources. D'autres, comme Affero, décidèrent au contraire qu'elles voulaient que la pérennité de la GNU GPL s'étende lors de l'utilisation par le réseau. Plusieurs solutions furent envisagées, les plus populaires restant le choix de l'Affero GPL et de l'OSL.

L'Affero General Public License et l'interaction par réseau distant (« Remote Network Interaction »)

L'idée fondatrice de l'AGPL est de se baser sur une GNU GPL suffisamment modifiée pour appréhender l'utilisation par le réseau, mais suffisamment proche de sa grande sœur pour lui rester compatible. Elle lui est donc en tout point identique, à l'exception près que si un licencié modifie le logiciel, il doit donner accès au code aux utilisateurs du service afférent (article 13).

Ainsi, la clause rajoutée a le bénéfice de la souplesse (je n'ai pas à distribuer ainsi un logiciel non modifié — ce qui ne serait de toute façon pas forcément utile), aux dépends d'un risque de contrefaçon : son absence d'automaticité pourrait inciter les développeurs à nier leur modification (ou les considérer comme indépendantes et séparées du programme) afin de ne pas avoir à distribuer le logiciel modifié. Cette contrefaçon serait en plus indécelable puisqu'elle ne pourrait être attestée qu'au moment de la distribution...

La solution retenue par l'Open Software License

Auparavant, et beaucoup plus simplement, Lawrence Rosen avait ingénieusement assimilé la mise à disposition par le réseau (« external deployement ») en une distribution. Ainsi, autant la distribution du logiciel que sa mise à disposition par le réseau induisent l'application de la licence, et donc l'obligation de distribuer le code source aux côtés de la licence et des droits afférents.

D'autres licences reprirent ensuite cette idée, telle l'APL.