Présentation détaillée des principales licences de logiciels libres

Présentation détaillée des principales licences de logiciels libres

Chapitre I – Description et qualification de la licence GPL

Section 1 : Description de la Licence GPL

Après une présentation détaillée de quelques licences de logiciel libre (S. Sect1), nous procéderons à une étude comparée de ces différentes licences quant au droits qu’ils confèrent aux utilisateurs S.(Sect 2)

S. Sect 1

Présentation détaillée des principales licences de logiciels libres

Notre but n’est pas d’étudier toutes les licences du logiciel libre qui existent sur le marché; mais de présenter quelques licences importantes à notre sens afin de comprendre ce qu’est effectivement la GPL et en quoi il se distingue des autres. Pour choisir ces quelques licences, nous avons tenu compte essentiellement du nombre de projets initiés; aussi nous avons pris les licences ayant plus de 300 projets d’après SourceForge3 (SouceForge.net)

P1 / la GNU Général Public Licence (GPL) version 2 de Juin 1991

Cette licence est constituée d’un préambule, de 13 sections et d’une notice bien expliquée sur le site Internet de la FSF. La GPL a été créée par la FSF dans l’optique de promouvoir le logiciel libre, et empêcher ainsi qu’un logiciel libre développé par quelqu’un puisse être intégré dans un logiciel propriétaire.

Elle donne le droit (sous conditions) à un « licencié » (utilisateur) d’accéder au code source, de dupliquer, de modifier et de redistribuer le logiciel à la condition que toutes les redistributions du logiciel, y compris les modifications qui y auraient été apportées (lorsqu’elle sont distribuées avec le logiciel initial), soient soumises à la licence GPL. De la sorte, l’utilisateur ne détient aucun droit de propriété sur le logiciel qu’il utilise, ni sur les modifications qu’il y apporte, et dont il devra communiquer le code source (lorsqu’elles sont distribuées avec le logiciel initial).

Les conditions posées sont notamment l’apposition d’une notice de copyright, d’une clause de renonciation à garantie, l’obligation de joindre la licence GPL, l’identification des modifications avec mention de la date et du nom de l’auteur, et l’obligation de joindre une offre sur la fourniture des codes sources.

Le principe reste la distribution « à titre gracieux » mais il est possible de facturer le transfert physique (frais de copie), et non un montant correspondant à des droits sur le logiciel. L’utilisateur n’a pas le droit de réclamer à l’auteur initial le bénéfice d’une garantie ou d’une maintenance, mais rien ne s’oppose à ce que l’auteur initial ou l’auteur d’une version modifiée ou encore un tiers le lui propose.

Dès lors que des composants significatifs du logiciel soumis à la GPL sont intégrés dans un ensemble « non-GPL », le résultat devra être soumis à la GPL ou bien ne pas être effectué. L’intégration complète du logiciel avec d’autres logiciels ne sera donc la plupart du temps possible que si ceux-ci sont également soumis à la licence GPL. Il est cependant interdit aux licenciés de redistribuer le logiciel initial par le biais d’une sous-licence, car c’est toujours le donneur de licence initial qui continuera à occuper la place du donneur de licence au fur et à mesure que de nouveaux partenaires s’impliqueront dans le développement coopératif du logiciel.

P2/ La GNU Lesser General Public Licence – LGPL version 2.1 de Février 1999

La licence LGPL est constituée de 17 sections, et d’un préambule ainsi que d’une notice d’adjonction de la LGPL. Elle a vocation à ne s’appliquer qu’aux bibliothèques logicielles (« the Software Libraries »). i.e. « une collection de fonctions logicielles et/ou de données préparée aux fins d’être adéquatement reliées avec des programmes applicatifs pour constituer des exécutables ».

Elle ne s’applique pas aux programmes distincts de la bibliothèque, ou qui ne font pas partie d’un ensemble basé sur celle-ci. Créée par la Free Software Foundation, elle autorise l’intégration de ses bibliothèques avec presque tout type de logiciel, y compris les logiciels propriétaires.

La licence est compatible avec la GPL, et la communauté des développeurs encourage la mise sous GPL de bibliothèques qui n’ont pas d’équivalents en logiciels propriétaires. Il est possible à tout moment de convertir un exemplaire d’une bibliothèque LGPL en GPL, par contre l’action inverse n’est pas autorisée.

En ce qui concerne les droits et obligations sur la bibliothèque et les modifications qui y sont apportées par les utilisateurs, la LGPL est assez proche de la GPL (obligation d’apposer une notice de copyright, d’ajouter une clause de renonciation à garantie, de joindre la licence LGPL et surtout de permettre l’accès aux codes sources, mais aussi d’annoncer la modification et sa date du code source initial et de laisser la bibliothèque dans son répertoire).

Par la distinction qui est faite entre le travail « basé sur la bibliothèque LGPL » et qui reste soumis à la LGPL, et le travail (dérivé) qui « utilise une bibliothèque LGPL », qui peut être soumis à une autre licence que la LGPL, la licence peut ouvrir la problématique des combinaisons de licences.

L’entreprise qui développe des logiciels utilisant une bibliothèque LGPL peut décider de soumettre ses créations à la licence (libre ou propriétaire) de son choix, à condition que cette dernière licence n’aille pas à l’encontre du transfert des droits sur la bibliothèque, et que toute redistribution de l’ensemble permette la redistribution simultanée et en libre accès des bibliothèques originales sous LGPL, avec un avertissement sur la combinaison existante.

P3 / La Zope Public Licence (ZPL) version 2.0

La licence Zope a été créée par la Zope Corporation, et est constituée de 5 paragraphes, dont le 3e comporte 5 sections. Elle a été « déclarée compatible avec la GPL » par la FSF. Elle parle de « Software » pour identifier le logiciel initial de Zope Corporation, et de « specific contributions » pour identifier le travail des « individus contributeurs » ayant apporté les améliorations « pour le compte de Zope ». Les modifications de chacun restent la propriété de leurs auteurs, mais la société Zope souhaiterait de plus en plus encourager une propriété commune, pour s’assurer d’un meilleur contrôle sur les versions diffusées.

Toute modification doit être annoncée, avec la date, et en y apposant le copyright et une clause de renonciation à garantie (dans le code ou dans la documentation). Le nom de « Zope » ne peut être mentionné que si cela a été autorisé, et Zope Corporation est libre d’accepter ou de refuser l’intégration des modifications.

En cas de modification du logiciel, le principe est que le nouveau logiciel soit soumis à la licence ZPL, mais il n’est pas mentionné d’interdiction d’assembler le logiciel avec des composants qui sont soumis à une autre licence. La déclaration de compatibilité avec la licence GPL permet d’intégrer un composant Zope dans un ensemble GPL.

A priori, il n’est cependant pas expressément interdit d’inclure des composants ZPL dans un logiciel propriétaire. Aucune mention n’est faite sur un risque de perte des droits tirés de la licence initiale quand elle n’est pas respectée, et on ne devrait pouvoir obtenir un changement de cette licence qu’avec l’accord de tous les auteurs. A noter que la version 1.0 de la licence est en pratique toujours diffusée et permet plus facilement un changement de licence.

P4/ Berkeley Software Design (BSD) license 1998.

La licence BSD est constituée de 8 paragraphes et parle de « Software » pour identifier le logiciel initial. Cette licence autorise l’utilisateur à intégrer le logiciel initial (qui reste, lui, disponible en distribution sous licence BSD) dans un ensemble (« produit dérivé ») soumis à la même licence. Toutefois la licence n’est pas explicite sur ce point, à une autre licence, y compris propriétaire. Dans ce dernier cas, le logiciel (ou l’un de ses composants) incorporé devient propriétaire, à la condition de :

  •  mentionner le copyright,
  •  mentionner les conditions présentes dans la licence BSD,
  •  demander aux auteurs initiaux leurs autorisations si on désire citer leurs noms.

Par contre, et sans surprise, la redistribution sous BSD exige la mention du copyright de l’auteur, la réutilisation de la licence BSD non modifiée, le principe de l’absence de garantie (sauf si le distributeur accepte d’en proposer une), et la fourniture du code source.

P5/ Massachusetts Institute of Technology (MIT) License

La licence MIT est constituée de 4 paragraphes, et elle parle de « Software » pour identifier le logiciel initial. Elle est très similaire à la licence BSD, dont elle ne s’éloigne marginalement que sur le paragraphe de non garantie, et sur les détails de la redistribution.

Elle réaffirme le principe de gratuité (« free of charge »), et n’oblige pas expressément à annoncer la modification du code source initial et la date, même si cela devrait s’imposer pour qu’une altération du code source par un utilisateur ne puisse pas porter atteinte à la réputation du développeur initial.

L’entreprise qui souhaite modifier un logiciel sous licence MIT n’aura donc que peu de contraintes pour le faire, mais si elle redistribue sa version modifiée, elle peut craindre qu’un nouvel utilisateur ne s’approprie son travail en le plaçant sous une licence propriétaire. La réutilisation de la licence MIT oblige cependant à faire mention du copyright.

P6/ APACHE software license version 1.1, 2000.

La licence Apache est constituée de 5 paragraphes, dont le 2e comporte 5 sections.

Elle parle de « Software » pour identifier le logiciel initial de Apache Software Foundation, et de « voluntary contributions » pour identifier le travail des « individus contributeurs » ayant apporté les améliorations « pour le compte de Apache Software Foundation ».

Toute redistribution de la version non modifiée ou modifiée oblige à réutiliser la licence Apache, avec mention du copyright Apache, des conditions de la licence, de l’absence de garantie et l’indication de l’origine Apache et du site web.

Dans la version modifiée, le nom « Apache » ne peut être utilisé sans accord préalable des auteurs initiaux. Comme les licences BSD et MIT, la licence Apache n’autorise pas expressément que l’on puisse intégrer des composants Apache dans une version propriétaire, mais ne l’interdit pas non plus.

Il devrait être possible de modifier la licence d’un ensemble basé sur des développements d’origine Apache, à condition au minimum de citer les clauses de la licence Apache. Cette licence, agréée par l’OSI, ne mentionne pas d’obligation d’annoncer la modification du code source initial et la date, alors que c’est une condition OSI; il conviendrait donc en pratique de respecter ces règles.

P7/ L’Artistic License

C’est une licence constituée d’une introduction et de 9 sections (avec parfois une « section 8 » supplémentaire), qui a été déclarée « approuvée par l’OSI », et a pour objectif de maintenir un contrôle artistique de l’auteur sur son travail. C’est une licence qui autorise plusieurs versions personnalisées. Elle parle de « Package » pour décrire l’ensemble que constituent le logiciel initial et ses modifications tels que distribués par l’auteur.

La « Standard Version » fait référence à ce « Package » non modifié ou modifié conformément au souhait de l’auteur (correctifs de bogues, évolutions).La redistribution des versions améliorées doit permettre de distinguer la modification de la version initiale, sa date et le nom de l’auteur de la modification. Il faut également joindre une notice de non garantie, la mention du copyright et la licence Artistic. La modification peut être mise en libre accès dans le domaine public.

Il est possible de procéder à des modifications, avec intégration dans un autre logiciel, soumis à une autre licence (libre ou propriétaire, mais, sur ce dernier point, les clauses ne sont pas claires), à la condition de respecter une des obligations suivantes : rendre le code source accessible sous licence de domaine public, ou n’utiliser la version modifiée que dans un cadre interne, ou mettre l’exécutable sous un nom différent, ou enfin aller négocier la redistribution avec l’auteur, et à condition de permettre l’accès au code source ou à l’exécutable du logiciel initial (« Standard Version »).

Et en cas de distribution combinée à d’autres produits, de manière commerciale ou non, il faut cependant mentionner l’origine du produit. Selon les versions de licence disponibles, il est possible que figure une clause supplémentaire permettant la commercialisation du logiciel lorsqu’il est intégré dans une application plus large et que les interfaces du logiciel ne sont pas visibles de l’utilisateur final.

La vente du logiciel sous licence Artistic est interdite, le principe restant la gratuité, mais un Package combinant un logiciel sous licence Artistic et des logiciels commerciaux peut cependant être vendu. La licence n’impose pas de restrictions sur le script et les bibliothèques créés par ou à l’occasion du programme, ni sur les sous-programmes PERL et C qui seraient ajoutés au programme (au niveau de l’édition de liens).

P8/ Mozilla Public License (MPL)

La licence a été élaborée par la Mozilla organisation.. Elle est composée de 13 sections et d’une annexe A, et elle précise que la loi de la Californie (E.U.) lui est applicable, mais pas la Convention de Vienne sur les marchandises. En cas de disposition de cette licence qui serait contraire à la loi, le distributeur de la licence doit y inclure un avertissement sur les points affectés par la législation.

Elle distingue l’« initial developer » qui a réalisé l’« original code », et le « contributor » qui a procédé aux « modifications », et distingue aussi la « modification » du travail plus large (« larger work »). Les modifications de chacun restent la propriété de leurs auteurs, mais doivent être soumises à la MPL et être annoncées, avec la date.

Par contre, les fichiers sources développés sans utiliser de code source initial constituent un « larger work », qui peuvent être soumis à une autre licence, y compris propriétaire, à condition de toujours permettre l’accès au code original et aux modifications.

Par ailleurs, la licence autorise dans sa section 13 (Exhibit A) le développeur initial à réserver quelques parties du code original ou modifié pour le soumettre à une licence de son choix (y compris propriétaire).Du fait de cette appropriation partielle de certains développements, la licence MPL n’a pas été déclarée compatible avec la GPL, ce qui a amené la communauté Mozilla a publier les développements sous une triple licence : MPL, LGPL, GPL.

Il faut noter qu’en cas de non-respect des dispositions de la MPL, l’utilisateur ou le contributeur perd ses droits sur le code original, mais sans que celui à qui il a redistribué perde les siens.

Pour citer ce mémoire (mémoire de master, thèse, PFE,...) :
📌 La première page du mémoire (avec le fichier pdf) - Thème 📜:
La révocabilité des licences de logiciels libres : Cas de la GPL
Université 🏫: Université Paris-I PANTHÉON SORBONNE - U.F.R. 01 Droit Administration Et Secteurs Publics - DESS Droit de l’internet administration-entreprises
Auteur·trice·s 🎓:
ALEXIS NGOUNOU

ALEXIS NGOUNOU
Année de soutenance 📅: Mémoire de fin d’études - 2003-2004
Rechercher
Télécharger ce mémoire en ligne PDF (gratuit)

Laisser un commentaire

Votre adresse courriel ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Scroll to Top