Contraintes techniques

Que l'on veuille distribuer son logiciel sous une licence libre, ou que l'on cherche simplement à respecter les termes de licences dont on est licencié, 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, libre 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 : 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 style 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 plus simples à utiliser.

Les licences modulaires

Les premières des licences modulaires sont probablement la NPL (non libre) et la MPL, utilisée pour Netscape et Firefox.

Contrairement aux premières licences évoquées, 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 cettedite licence. Pour l'exemple, tout fichier contenant du code sous 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, 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 en présence d'une contradiction au sein du contrat qui le lie au concédant, situation qui risque de lui profiter puisque c'est habituellement la règle favorable à la personne qui se trouve devoir respecter deux termes contradictoires qui est retenue : annulant alors tous les effets recherchés par l'interprétation.

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 (lorsqu'elle confère plus de droits : puisqu'étant plus favorable au licencié, c'est celle-ci qui prévaudra).

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 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é sur ne seule machine, le serveur, afin que quiconque puisse l'utiliser via Internet (c'est ce que l'on appelle SOA, ou 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 s'en servir de ce que l'on a nommé l' « ASP loophole » pour utiliser à profusion des logiciels qu'elles modifient 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 la « Remote Network Interaction »

Le postulat de base de l'AGPL est qu'il s'agit d'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 être 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érents (article 13). Ainsi, la clause 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), mais son absence d'automaticité risque d'inciter les développeurs à nier leur modification (ou les considérer comme indépendantes et séparées du programme) pour ne pas avoir à distribuer le logiciel (et la contrefaçon ne sera de toute façon possible qu'au moment de la distribution...).

La solution retenue par l'Open Software License

Avant ça, et plus simplement, Lawrence Rosen avait usé d'ingéniosité, en assimilant tout simplement 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 donner le code source aux côtés de la licence et des droits afférents. D'autres licences reprirent cette idée, telle l'APL.