Beaucoup de décideurs se trouvent souvent confrontés à l’épineuse question du choix d’une solution informatique pour résoudre un problème donné. Ils ont à choisir entre prendre une solution libre et l’adapter selon leur convenance et faire appel à une société informatique qui elle développera pour eux la solution à leur convenance. Au delà des aspects techniques que nous n’aborderons pas, ils se posent des questions de droits qui parfois peuvent être déterminantes pour orienter leur choix. Nous analyserons la nature des droits conférés qu’il s’agisse de l’utilisation interne (P1) que de la distribution (P2)
P1/ les droits conférés pour une utilisation interne
D’après les critères fixés par la FSF et complétés par l’OSI le logiciel libre permet de jouir de dix droits; ce qui le distingue des autres logiciels en général et des progiciels classiques en particulier. Notre étude comparative portera sur ces droits ainsi que les conditions de leur mise en œuvre. Il s’agit des droits de :
I / Le droit d’accès au code source, au code objet ou à l’exécutable
L’accès au code source est la condition sine qua non pour l’existence des logiciels libres. La licence GPL dit : ’our General Public Licences are designed to make sure that …you receive source code or can get it if you want it’. En d’autres termes notre GPL a été conçue pour s’assurer que vous recevriez le code source ou que vous pourriez l’avoir si vous le désirez. L’accès au code source se fait en principe sur le site de la FSF, mais peut aussi se faire sur d’autre site. La seule condition posée par la GPL est que cet accès n’altère pas la lisibilité du code source et qu’il se fasse gratuitement. Quant aux modifications subséquentes, les différents contributeurs disposent des droits sur leurs modifications, mais ils ont l’obligation d’annoncer la modification du code source initial et la date; cela vaut également pour le droit d’usage et le droit de duplication.
Parlant des LGPL l’accès au code source est obligatoire et doit se faire sans altérer la lisibilité de celui-ci. Pour ce qui est des modifications apportées à la bibliothèque l’on distingue selon que celles ci sont ou non soumises à la LGPL. Dès lors que la modification crée un travail dérivé qui contient du code de la bibliothèque, qu’il s’ajoute à celle-ci ou qu’il la modifie, ou qu’il la traduise dans un autre langage informatique, on parlera de « WORK BASED ON THE LIBRARY » (Intro et sections 0 et 2).
Dès lors, les utilisateurs-auteurs des modifications disposent des droits sur leurs modifications, et peuvent les aménager, dans le cadre de la LGPL; notamment, obligation d’annoncer la modification du code source initial (et la date) et de laisser la bibliothèque dans son répertoire (sect 2b). Si l’application est exclue de la licence LGPL, il y a possibilité de créer un programme privatif, mais dès lors qu’il comporte un lien avec la bibliothèque, il constitue un travail dérivé (« combined or derivative work ») : cependant, si ce travail dérivé ne contient pas de code de la bibliothèque, mais qu’il recourt à la bibliothèque pour fonctionner, on parlera de « WORK THAT USES THE LIBRARY » – Intro et sections 2 et 5
Alors le travail dérivé pourra être soumis à une autre licence que la LGPL, mais la bibliothèque initiale reste sous LGPL.
Les utilisateurs-auteurs des modifications disposent dans ce cas de la totalité des droits de la propriété intellectuelle sur leurs modifications et créations, et peuvent librement en aménager les droits
L’accès au code source n’est pas autorisé dans les logiciels classiques qui demeurent la propriété de leur l’auteur. L’on a seulement accès à l’exécutable. Toutefois dans la pratique beaucoup d’entreprises exigent la disponibilité du code source. Il en est de même de l’administration qui dans les Cahiers des Clauses Administratives Générales ou particulières (CCAG et CCAP) exigent presque toujours le code source des prestations.
C’est une source de sécurité qui permet ainsi de ne pas être totalement dépendant de l’auteur du logiciel et surtout de pouvoir assurer la maintenance préventive ou évolutive du logiciel en cas de disparition du fabricant. Ainsi on a recours presque toujours à un tiers de dépôt chez qui on dépose le logiciel d’après les conditions qui ont été fixées d’un commun accord.
Toutefois il convient de remarquer que cette pratique est presque franco-française, les éditeurs d’autres pays interdisant purement et simplement l’accès au code source. Par ailleurs, l’utilisateur légitime a le droit d’analyser le programme d’après l’art 5 paragraphe 3 de la Directive. Ce droit doit est reconnu sans pour autant permettre à ce dernier de faire des actes d’ingénierie inverse (Reverse Inggineering) qui consistent à copier les aspects commercialement attractifs d’un programme.Cette solution s’applique aussi au shareware et au freeware.
Par ailleurs dans la ZPL, l’accès au code source est implicite sur le site de ZOPE. Quant aux modifications, l’on distingue deux situations. D’une part le nouveau logiciel reste sous ZPL 2 et donc les utilisateurs-auteurs des modifications disposent des droits sur leurs modifications, ils peuvent les aménager en respectant les droits tirés de ZPL2. Toutefois ils ont l’obligation d’annoncer la modification du code source initial et la date; et Zope Corporation est libre d’accepter ou de refuser l’intégration des modifications.
D’autre part, si le nouveau logiciel est soumis aux clauses d’une autre licence, les auteurs-utilisateurs des modifications, dès lors que le nouveau logiciel reprend les conditions de ZPL2, ne porte pas le nom de Zope, et respecte les principes de libre distribution. Obligation d’annoncer la modification dans des patch distincts du code source initial; mais rien n’est dit sur l’accès à la version initiale. Il en va de même pour le droit d’usage et le droit de duplication.
La licence Berkeley Software Design (BSD) consacre le droit d’accès au code source. Pour ce qui est des modifications apportées au logiciel, si le nouveau logiciel reste sous BSD l’accès au code source ou binaire est total; par contre si le nouveau logiciel est soumis aux clauses d’une autre licence l’accès au code source est possible selon les clauses.
La Massachusetts Institute of Technologie (MIT) parle de software pour identifier le logiciel initial. L’accès au code source est consacré bien que la licence ne parle que de ‘software’ fourni, et non pas de code source; il en est de même des modifications soumis au MIT. Pour celles soumises aux clauses d’une autre licence, l’accès au code source dépend des clauses sur le nouveau logiciel (voire sur la seule partie modifiée, mais alors, avec un risque de problème de combinaison des licences).
Quant à Apache Software Licence, le terme ‘software’ désigne le logiciel initial de Apache Software Foundation et le terme ‘ voluntary contributions’ identifie les contributeurs ayant apportés les améliorations ‘pour le compte de Apache Software Foundation’. Le code source est disponible pour les software ainsi que pour les voluntary contributions si le nouveau logiciel reste sous Apache. Si par contre il est possible de soumettre le nouveau logiciel aux clauses d’une autre licence, l’accès au code source est possible selon les clauses.
L’Artistic Licence parle de ‘package’ pour désigner l’ensemble composé du logiciel initial et des modifications subséquentes qui elles sont soumises à Artistic. Sont aussi comprises les patchs et correctifs de bogues; mais le scripts et les bibliothèques crées par ou à l’occasion du programme, ni les sous-programmes PERL et C qui seraient liés au programme(au niveau de l’exécutable). Le code source est disponible pour le logiciel de base ainsi que les modifications soumises sous Artistic. Dans le cas contraire, les modifications peuvent être mise en libre accès sous une autre licence libre, ou dans le domaine public
Pour la Mozilla Public Licence (MPL) l’accès au code source est garantie sans royauté et à titre non exclusif. Il en est de même des modifications si le nouveau logiciel doit rester sous MPL. Toutefois le contributeur a l’obligation de ne pas toucher aux noms des auteurs précédents, d’anoncer sa modification du source initial, avec la date. Dans le cas de la combinaison de MPL avec une autre licence, le code source est disponible pour les fichiers de code initial ou modifié. Pour les autres fichiers ajoutés, la disponibilité du code source dépend des clauses.
II/ Le droit d’usage
Dans la GPL ce droit est presque absolu. L’utilisateur a le droit de se servir du logiciel sous GPL, il peut dupliquer autant d’exemplaires qu’il désire partout où il le souhaite. Il n’y a pour ainsi dire aucune limitation de principe quant au nombre, quant à la situation géographique, quant à la durée.
Comme pour le droit d’accès au code source et le droit de duplication, chaque auteur dispose d’un droit privatif qu’il peut aménager sur ses créations dès lors qu’elles n’ont pas été ajoutées ou qu’elles ne se fondent pas sur le logiciel GPL. Toutefois, dès lors qu’elles sont fournies avec le logiciel, il doit respecter la licence GPL et la faire respecter par les utilisateurs du logiciel modifié.
Ceci n’est pas le cas pour les logiciels propriétaires où le droit d’usage est limité très souvent à une copie dans un une région donnée et parfois même pour une certaine durée. En effet, les droits exclusifs de l’auteur sont tempérés par deux exceptions pour les ‘opération courantes’ et pour la décompilation; le but étant de ‘faciliter l’utilisation du programme par celui qui a le droit de s’en servir’ afin d’éviter ‘que le droit d’auteur ne soit mis en échec par des pirates’ : Valerie-Laure Benabou, Droit d’auteur droits voisins et droit communautaire.
La LGPL parle de ‘freedom of use’ pour désigner ce droit qui est obligatoirement acquis. Il est de même de la BSD dont la restriction n’est admise que pour les modifications si le nouveau logiciel est soumis aux clauses d’une autre licence.
Cette situation est semblable au MIT à la seule condition que le droit d’usage est gratuit ‘free of charge’ même pour les modifications si le nouveau logiciel reste sous MIT. L’Apache Software Licence consacre le droit d’usage dans toutes les situations, ce qui n’est pas le cas de l’Artistic Licence (AT) où ce droit n’est reconnu qu’implicitement. Dans la MPL ce droit est consacré de la même manière que le droit de duplication et le droit d’extraire les composants du logiciel.
III/ Le droit de duplication
Le droit de duplication pour les logiciels propriétaires est limité à l’exemplaire de sauvegarde. Celle-ci est autorisée dans la mesure où elle est nécessaire pour préserver l’utilisation du logiciel. Art (L.122-6.1-II du CPI) la copie de sauvegarde est à distinguer avec la copie privée qui concerne toute les œuvres de l’esprit à l’exception du logiciel. (Art L 122-5 CPI). Il s’agit d’une copie de secours exclusivement, exclusivement destinée à être utiliser en cas de défaillance du logiciel principal.
En pratique, l’on constate un paradoxe entourant la validité de la copie de sauvegarde. D’une part, les éditeurs ont le droit d’introduire dans les logiciels des dispositifs techniques destinés à empêcher des copies fussent-t-elles de sauvegarde : CA Paris 20 Oct 1988; Petites Affiches 1989 n° 106. D’autre part la commercialisation des logiciels dits de ‘déplommage’ permettant la suppression ou la neutralisation des dispositifs techniques de protection des logiciels contre la copie, n’est pas interdite mais est strictement encadrée. Art L 122-6-2 du CPI.
Il est tout à fait concevable que l’auteur d’un logiciel puisse interdire contractuellement la copie de sauvegarde en fournissant par exemple à l’utilisateur une seconde copie. Aussi celui-ci n’aura plus juridiquement aucun justificatif à dupliquer le logiciel; ce qui n’est pas le cas dans la GPL
En effet le droit de dupliquer est de l’essence du logiciel libre. Il est mentionné au préambule de la GPL . ‘This licence gives you legal permission to copy’ et repris plusieurs fois dans les dispositifs.’ You may copy and distribute the Program’. Aussi l’utilisateur a le droit de dupliquer le programme en autant d’exemplaire qu’il le souhaite.
La GPL pose quatre conditions (l’apposition du copyright, la clause de renonciation à garantie, l’adjonction de la licence GPL, l’adjonction des informations sur la fourniture des codes sources). Ces dispositions se trouvent aussi dans la LGPL.
Dans la BSD et l’Apache Software Licence (ASL) le droit de duplication est implicitement reconnu. Il est toutefois restreint pour les modifications si le nouveau logiciel est soumis aux clauses d’une autre licence. Il en va de même du droit d’extraire des composants du logiciel.
Quant au MIT, le droit de duplication est reconnu si mention du copyright et mention de la licence MIT. La duplication des modifications est possible si le logiciel reste sous MIT, dans le cas contraire la duplication dépendra des clauses de la nouvelle licence. Dans l’AL, le droit de duplication est possible si l’on y joint la licence Artistic. Dans le cas de la combinaison de MPL avec une autre licence, le code source est disponible pour les fichiers de code initial ou modifié. Pour les autres fichiers ajoutés, la disponibilité du code source dépend des clauses.
IV/ Le droit d’extraire des composants du logiciels
Ce droit est formellement interdit dans les logiciels propriétaires, aussi bien pour les shareware que pour les freeware. Dans la GPL ce droit est consacré. Il doit être soumis à la même licence que l’ensemble d’où il est extrait.
Cela a pour conséquence d’étendre la GPL sur l’ensemble qui ‘se fonde’ sur une base en GPL. (sect2) Quant aux modifications le principe est que l’ensemble fondé sur une base en GPL est soumis à la GPL (sect2) alors, si les autres composants sont soumis à une licence qui ne permet pas cette extension, l’assemblage n’est pas autorisé. (sect 8) Cette disposition se trouve presque à l’identique dans la LGPL, à la seule différence que pour les applications limités de la licence, en cas de combinaisons de licences, l’extraction de la bibliothèque est possible sous LGPL.
L’extraction du travail dérivé est aussi possible selon la licence et selon les clauses. Le problème de combinaison de licence est aussi visible dans la ZPl où le droit d’extraction est implicite et a pour conséquence d’étendre la licence ZPL.
Le principe voudrait que tout soit soumis à la ZPL en cas de modifications; mais il n’est pas mentionné d’interdire d’assembler le logiciel avec des composants qui sont soumis à d’autres licences. La déclaration de compatibilité avec la GPL permet d’intégrer un composant Zope dans la GPL. Pour le MIT, le droit d’extraire est consacré sans conditions seulement en cas de modification si le nouveau logiciel est soumis aux clauses d’une autre licence; aussi l’extraction dépendra des clauses. Il en va de même pour l’AL
V/ Droit de procéder à des modifications avec intégration dans un autre logiciel
Il est formellement interdit dans les logiciels propriétaires. Toutefois l’utilisateur légitime dans les exceptions prévues par la Directive a le droit de procéder à la décompilation qui consiste ‘à transcrire en Langage intelligible les informations contenues dans le programme en code machine’ : Valerie-Laure Benabou précité.
Cette opération est très limitée par la loi et aussi par la pratique. Dans la GPL, ce droit est consacré avec implicitement dans la licence, obligation de ne pas faire de discriminations, obligation d’annoncer la modification du code source initial et la date(section 2), ce qui permet la conservation du nom de l’auteur initial.
Pour ce qui est des modifications, toute modification du logiciel a pour conséquence d’étendre la licence GPL sur l’ensemble qui « se fonde » sur une base en GPL (section 2), mais si les autres composants sont soumis à une licence qui ne permet pas cette extension, l’assemblage n’est pas autorisé. Dans la LGPL l’on trouve des dispositions presque semblables à la seule différence en matière d’application limitée de la licence LGPL. Si la modification de la bibliothèque est possible, il n’en va pas de même du travail dérivé, et selon la licence choisie.
Quant à la ZPL, les modifications sont possibles avec obligation d’annoncer la modification du code source initial et la date. La combinaison des licences est possible même si cela n’est pas expressément prévu. La BSD reconnaît le droit de modification, mais ne mentionne pas d’obligation d’annoncer la modification du code source initial et la date. L’on retrouve les mêmes dispositions dans la MIT et à l’Apache Software Licence à la seule différence que selon les clauses ‘ les modifications de l’ASL ‘ produit dérivé’ ne doit pas user du nom Apache sans autorisation.
L’artistic Licence est un cas tout à fait particulier.(section 3). Le droit de modification est à priori reconnu uniquement pour les modifications «raisonnables». Mais obligation de permettre de distinguer la modification de la version initiale et la date (section 3 a) et c) et par la mention du nom de l’auteur de la modification (section 8 et section 3) joindre notice de non garantie visible. Si le nouveau logiciel est soumis à l’AL, les modifications peuvent être aussi intégrées
dans la « standard version »(section 3a). Dans le cas contraire, – section 3 il convient de rendre le code source de la modification accessible sous licence libre ou usage purement interne ou mettre l’exécutable sous un nom différent et/ou négocier la redistribution avec l’auteur.
Dans la MPL le droit de procéder aux modifications est garantie tout en distinguant la « modification », qui porte sur un fichier ou une partie du code source identifié, et qui doit être annoncée. la combinaison d’un fichier du code initial et d’un fichier de code nouveau, l’ensemble constituant un « larger work » et qui doit annoncer les modifications portant sur les fichiers du code initial.
VI/ Droit de réclamer de l’auteur initial le bénéfice d’une garantie ou d’une maintenance
Dans les logiciels propriétaires, ce droit est possible et très souvent payant, mais en pratique la licence peut en conditionner l’exercice. Dans la GPL le principe est l’absence de garantie. Toutefois la garantie est possible si l’auteur le propose. Quant aux modifications, la garantie de l’ensemble n’est pas possible.
Qu’à cela ne tienne l’auteur des modifications assume sa propre garantie de la même manière que c’est à l’auteur initial de donner sa libre autorisation pour la garantie. Il en va de même de la LGPL à la seule différence que pour les modifications le problème ne se pose pas puisque l’utilisateur est lui même l’auteur des modifications tout comme dans la ZPL où la garantie n’est pas possible quoique l’on puisse recourir aux services de Zope accessibles sur son site.
Pour ce qui est de la MIT le droit de réclamer la garantie n’est pas reconnu même pour les modifications, sauf si le nouveau logiciel est soumis aux clauses d’une autre licence auquel cas cela dépendra des clauses. C’est aussi le cas de l’Apache Software Licence, de l’Artistic Licence. Quant au MPL; les contributeur devant avertir s’il a connaissance de réclamations en proriété intellectuelle sur ses modifications (sect 3.4)
