Choix d'une license open source
Cet article fait suite à:
Combien existe-t-il de licences Open-Source ?
Beaucoup!
De très nombreux auteurs ont décidé qu'une licence existante (notamment la licence GPL et son aspect viral) ne correspondait pas à leurs impératifs et ont créé la leur, souvent en modifiant une licence existante.
Il faut savoir aussi que certaines licences se prétendent "open source" sans l'être vraiment.
Une bonne liste de référence est fournie par l'Open Source Initiative.
Quelle licence choisir?
Le choix ne doit pas uniquement porter sur les caractéristique que l'on jugerait idéales. Il faut également choisir une licence qui sera compatible avec les codes tiers que l'on veut pouvoir intégrer à son projet.
"Compatible" signifie ici que les licences respectives de chaque morceau ou bibliothèque de code que l'on veut assembler doivent autoriser cet assemblage avec du code sous licence tierce.
A cet effet, il est généralement une mauvaise idée de créer une nouvelle licence. Il vaut mieux en utiliser une existante et dont la compatibilité est étendue.
On observe également une tendance grandissante consistant à diffuser du code sous plusieurs licences simulatnément, ce qui limite les incompatibilités en donnant la possibilité d'utiliser la bonne licence au bon moment.
Un point de départ intéressant peut être la consultation des Statistiques SourceForge en termes de répartition par licence.
On constate (évidemment) facilement l'écrasante domination de la licence GPL suivie (de loin!) par son pendant LPGL (Lesser GPL).
Quelles sont les principales alternatives ?
On peut classer les différentes licences open-source en 3 grandes catégories selon leur degré de permissivité par rapport à l'idéal du "Logiciel Libre":
Précisions sur la licence GNU GPL
Cet article fait suite à "Open Source & Sociétés Commerciales".
Avant tout, ATTENTION: bien que j'aie essayé de faire de mon mieux, je ne suis pas juriste et je ne peux en aucun cas garantir les informations ci-dessous. Qui plus est, la plupart des analyses disponibles dans ce domaine sont basées sur le droit américain et peuvent ne pas forcément se transposer au droit français, européen ou international...
En effet, il est important de prendre en compte le fait qu'à l'heure de l'Internet, les différentes contributions à un projet Open Source proviennent souvent de pays très divers. Identifier des règles de droit applicables à tous ces pays est au delà de mes compétences.
Les informations rassemblées ci-dessous sont donc à prendre à titre indicatif!
Pourquoi la licence GPL pose-t-elle problème?
Si vous diffusez un logiciel sous GPL et que d'autres équipes lui ajoutent des fonctionnalités intéressantes, vous pouvez à tout moment récupérer ces différents ajouts et les fusionner au projet initial.
Le revers de la médaille c'est que si vous voulez intégrer un morceau de code diffusé sous GPL dans l'un de vos propres logiciels, vous devez alors obligatoirement diffuser ce logiciel dans son entiereté sous licence GPL... ou bien ne pas le diffuser du tout.
On peut discuter longtemps de la pertinence de l'idéal derrière cette licence, mais il est un fait que dans une entreprise capitaliste, la manipulation de code sous licence GPL finit toujours par poser des problèmes auxquels il faut préter une attention particulière.
Et c'est sans compter le fait que la légalité même du texte de la licence GPL est remise en cause par différents avocats et juristes...
Quelle est la valeur légale des licences Open Source?
La réponse de Bruce Perens "s'appuie" ici sur le droit américain mais il y a quelques principes généraux à retenir: une licence logicielle est une combinaison des droits d'auteur ("copyright law" qui s'applique assez mal aux logiciels) et du droit contractuel (dans lequel on peut ajouter pratiquement toutes les restrictions imaginables tant qu'elles n'atteignent pas aux autres droits garantis par les lois). Mais de toutes façons, la plupart du temps les problèmes de non respect des licences se sont réglés avec succès en dénonçant publiquement les abus (mauvais pour l'image...) plutôt qu'en attaquant les contrevenants en justice.
On peut toutefois douter de l'efficacité d'une dénonciation publique sur une PME ou même un développeur indépendant qui abuserait d'un code open source dans un marché de niche... :|
Après avoir rendu public un logiciel sous licence GPL, est-il possible de changer la licence?
D'après Bruce Perens, oui et non. Non on ne peut pas se retracter sur la licence GPL portant sur les versions existantes. Mais oui, si personne d'autre n'a contribué, il est possible de sortir les nouvelles versions sous une autre licence. Il est également possible de sortir le même logiciel simultanément sous plusieurs licences (et pas forcément toutes Open Source).
Ce point est souvent contesté par les opposants à la GPL qui prétendent que la licence GPL empêche l'auteur même du logiciel de l'utiliser autrement que sous les termes de la GPL, y compris pour les travaux dérivés. J'oserai affirmer ici que c'est faux! La FSF le dit clairement dans sa FAQ sur la GPL:
The GNU GPL does not give users permission to attach other licenses to the program. But the copyright holder for a program can release it under several different licenses in parallel. One of them may be the GNU GPL.
The license that comes in your copy, assuming it was put in by the copyright holder and that you got the copy legitimately, is the license that applies to your copy.
I would like to release a program I wrote under the GNU GPL, but I would like to use the same code in non-free programs.
To release a non-free program is always ethically tainted, but legally there is no obstacle to your doing this. If you are the copyright holder for the code, you can release it under various different non-exclusive licenses at various times.
Si d'autres personnes ont contribué, elles sont propriétaires du "copyright" sur leurs modifications (et ça se transpose probablement aux droits d'auteur français, mais on doit pas être très loin...?). Plusieurs options pour changer la licence dans ce contexte:
- Eliminer le problème: supprimer le code contribué.
- Traiter le problème au niveau du copyright: demander un transfert du "copyright" aux auteurs concernés. On peut aussi envisager qu'il cède un copyright tout en conservant le sien ("split-copyright"). Pas sûr que tout celà puisse s'appliquer aux droits d'auteur français. Cette solution est intéressante car elle n'aliène pas le contributeur en lui imposant une licence plus restrictive que la GPL. Cette solution permet éventuellement de distribuer les modifications à la fois sous GPL et sous une autre licence en fonction des besoins.
- Traiter le problème au niveau de la licence: utiliser dès le départ une licence telle que la Netscape Public License (NPL) qui implique que les fichiers modifiés soient redistribuables sous une autre license... (mais pas forcément les nouveaux fichiers ajoutés par d'autres, dans le cas de la NPL). Sinon, si le projet est en GPL dès le départ par exemple, il est nécessaire d'obtenir le consentement de tous les contributeurs avant de changer la license. Voir l'exemple de Mozilla.org qui est engagée dans un processus de changement de licence où non seulement elle change les licences NPL en MPL (Mozilla Public License) mais où elle ajoute d'autres licences (GNU GPL et GNU LGPL) et où elle bascule des licences tierces vers MPL+GPL+LGPL avec le consentement des contributeurs concernés.
Un programme GPL peut-il inclure des modules non GPL?
Oui, mais la licence des modules doit être compatible avec la licence GPL. Dans le cas contraire, il faut prendre des dispositions particulières.
Sur la compatibilité des diverses licences open source avec la GPL, voir: Various Licenses and Comments about Them.
Un plug-in pour un programme GPL doit il forcément être ditribué sous GPL?
On entre dans une zone de flou...
La FSF prétend que le plugin doit être ditribué en GPL, mais s'il est distribué séparément... on est bien dans un cas où l'auteur peut distribuer son code sous la licence qu'il veut non?
Maintenant, le problème c'est qu'un plugin est généralement construit à partir d'une classe ou d'un template type, lequel est généralement soumis à la licence GPL... ce qui implique que le plug-in derivé soit GPL également. Mais si la classe ou le template de base existe sous différentes licences... tout semble permis, non?
Open Source & Sociétés Commerciales
Petit tour d'horizon...
Qu'est-ce qu'un logiciel Open Source? Qu'est-ce qu'un logiciel Libre?
Dans un monde dominé par Microsoft, la plupart des logiciels sont propriétaires; même s'ils ne fonctionnent pas correctement (ce qui est fréquent!) il est nécessaire de payer (généralement assez cher!) pour les utiliser et on ne dispose d'aucun autre droit! En particulier: on n'a pas le droit d'en étudier la conception (reverse engineering), de les corriger, de les modifier, de les copier, ni les redistribuer.
A l'autre extrême on trouve les logiciels du domaine public, relativement rares. Ils n'ont aucune restriction. Vous pouvez faire ce que vous voulez avec (et n'importe qui d'autre peut en faire autant).
Les logiciels open source et les logiciels libres se situent entre ces deux extrêmes. Open source, signifie que vous pouvez au minimum obtenir le code source afin de l'étudier et éventuellement d'identifier les problèmes. Les logiciels vraiment libres vont au delà puisqu'ils permettent en plus de modifier le code source, de dupliquer le logiciel et de le redistribuer. En fait il existe plusieurs dizaines de licences avec des droits différents. On a coutume d'appeler cet ensemble de licences sous le nom de licences open-source.
Note pour ceux qui auraient un doute: un logiciel "shareware" n'a rien à voir avec un logiciel open source. Un logiciel shareware est un logiciel commercial dont la seule différence avec un logiciel de Microsoft était originellement qu'on pouvait systématiquement l'essayer avant de l'acheter. Mais depuis plusieurs années, même la plupart des produits Microsoft peut être essayée avant de l'acheter!
On peut aussi se référer au diagrame de Chao-Kuei ci dessous:
Juste une seule question de néophyte: que signifie "code source"?
Un logiciel est écrit dans un language compréhensible par les humains (du moins par les programmeurs). Ce qu'écrit le programmeur s'appelle le code source. Ce code source est ensuite compilé et on obtient un code objet ou code exécutable. Pour schématiser on pourrait dire que la compilation consiste à traduire le language du programmeur en language machine.
Quand vous achetez un logiciel sur un CD de Microsoft par exemple, vous n'obtenez que le code exécutable.
La chose importante à retenir, c'est qu'il est pratiquement impossible d'analyser, diagnostiquer, corriger, modifier, améliorer ou faire évoluer un logiciel sans disposer de son code source.
Lorsqu'une société privée participe dans un projet open source, n'y a-t-il pas un conflit d'intéret?
Réponse de Bruce Perens. Il cite les exemples d'IBM et Apple. Il ne s'agit pas d'un conflit d'intérêt mais d'un équilibre entre ce que la société donne à la communauté OS et ce qu'elle en reçoit et réciproquement entre ce que la communauté donne à la société et reçoit en retour. On peut toutefois distinguer des degrés de coopération divers allant de parasite à symbiotique (Red Hat) à bienfaiteur (NASA). La nécessité de maintenir une bonne image publique freine les sociétés à trop tirer sur la corde et à devenir des parasites.
Voir aussi: Open Source Case for Business (OSI)
Oui mais... dans le cas où la société commerciale vend avant tout du logiciel (pas comme IBM et Apple où le soft OS n'est qu'un accessoire au matériel), elle ne peut pas se permettre de rendre son logiciel gratuit!?
Non, dans ce cas, tout ne doit pas être gratuit. Par exemple, Sendmail Inc. vend des add-ons commerciaux au Sendmail libre. Digital Creations (Zope) vend du service autour du noyau Zope libre, notamment afin d'en réaliser des intégrations verticales; ces "customizations" ne sont pas ajoutés au noyau libre. Voir: décision de Zope de rendre son code open source.
Quelle licence Open Source choisir?
La license open source qui accompagne le logiciel définit les droits que le ou les auteurs accordent aux utilisateurs dudit logiciel.
La licence GNU General Public License (GPL) constitue la référence en la matière, tant en âge qu'en nombre de projets l'utilisant. Celà est dû à la popularité de Linux, dont le noyau, la majorité des composants et add-ons sont distribués sous license GPL. (Note: Linux n'est pas pour autant un projet de la GNU/FSF même si la FSF tente plus ou moins insidieusement de le faire croire...)
La license GPL est très restrictive sur le fait d'être non restrictive! Elle accorde en effet presque tous les droits possibles à son utilisateur à l'exception du droit de supprimer ces droits en cas de modification du logiciel. Celà à pour conséquence qu'un code GPL devra rester GPL lorsqu'il est modifié et ne peut être assemblé qu'avec d'autres composants sous licence compatible avec la licence GPL.
La licence GPL est ainsi controversée par de nombreux développeurs refusant aujourd'hui de l'utiliser à cause de ceteffet "viral" ou "infectieux".
La licence BSD au contraire, donne le droit de ne plus distribuer le code source d'un projet BSD dès lors qu'on y a apporté des modifications.
Critique de la licence GPL par Michael Maxwell en faveur de la licence BSD. Cette critique a un parti pris évident, mais permet de saisir l'étendue des divergences qu'il peut y avoir d'une license open source à une autre.
En fait GPL et BSD se situent à deux extrêmes. La GPL est à l'extrême "open" alors que la BSD permet de rebasculer très vite vers du "closed source".
En réalité, la plupart des développeurs préféreraient une solution intermédiaire entre ces deux extrêmes.
Par ailleurs, au delà même des licences Open-Source, toutes les licences logicielles sont régulièrement contestées sur des points de droit particuliers, du fait que les logiciels constituent un artefact dont on ne sait pas très bien s'il est artistique, scientifique ou industriel et auquel les textes de loi existants s'adaptent souvent assez mal. Voir entre autres Donald K. Rosenberg.
De ces divers problèmes sont nées un myriade de licences intermédiaires pour tenter de concilier les choses, avec plus ou moins de succès... et en créant de nouveaux problèmes puisque ces licences se retrouvent fréquemment incompatibles entre elles, empêchant ainsi d'utiliser du code d'un projet dans un autre s'ils n'ont pas tous les deux la même licence.
Voir par exemple le problème de la biblothèque Qt de TrollTech expliqué par Donald K. Rosenberg.
Le choix (ou la rédaction) d'une licence doit prendre en compte toutes ces données: non seulement les droits accordés aux utilisateurs mais aussi les interactions possibles avec d'autres composants logiciels.
Il est également important de choisir correctement la licence la plus adaptée dès le départ car il ne sera pas forcément possible de revenir en arrière par la suite.
A voir: liste des licences open source recensées (et approuvées) par l'OSI.
Google PageRank (PR) Value Checker & Calculator Report without Toolbar
Also includes a long explanation on how PageRanks are (supposed to be) calculated.
