La licence que vous choisirez n'aura certainement que peu d'importance pour l'adoption de votre projet tant que c'est une licence open source. Les utilisateurs choisissent en général un logiciel en fonction de ses qualités et de ses fonctionnalités, pas pour des détails concernant la licence. Néanmoins vous devez maîtriser un minimum les questions relatives aux licences, à la fois pour vous assurez que celle que vous choisissez pour votre projet soit en accord avec ses objectifs et aussi pour être capable de débattre du choix de celle-ci avec d'autres personnes. N'oubliez pas par contre que je ne suis pas avocat et que rien dans ce chapitre ne doit être pris comme un vrai conseil légal. Si vous en avez besoin vous devrez engager un avocat à moins que vous ne le soyez vous même.

Dans toute discussions sur les licences libres, ce qui saute aux yeux est la variété de mots différents pour désigner la même chose : free software (logiciel libre), Open Source (logiciel ouvert), FOSS, F/OSS et FLOSS. Commençons par les rassembler, les trier, puis les compléter par d'autres termes.

Logiciel qui peut être librement partagé et modifié en y incluant son code source. Le terme a été à l'origine inventé par Richard Stallman qui l'a codifié pour donner la Licence Publique Générale (GNU - General Public License) et qui a fondé la Fondation pour le Logiciel Libre (Free Software Foundation, http://fsf.org/), afin d'en promouvoir le concept.

Bien que le logiciel libre couvre le même champ de logiciels que l' « Open Source », la FSF, entre autres, préfère le terme initial parce qu'il englobe l'idée de liberté et le concept de logiciel librement redistribuable et préfère l'idée d'un mouvement social à celui d'un mouvement technique. La FSF reconnaît que le terme est ambigu, il peut signifier « free » comme dans « zéro-coût », au lieu de « free » comme dans « liberté » , mais tout bien réfléchi, il semble que ce soit le meilleur terme et les autres possibilités en anglais ont chacune leur propre ambiguïté (Tout au long de ce livre, le terme « free » est utilisé au sens de « freedom » et non au sens de « zéro-coût »). [NdT : Notez qu'en français, on préfèrera le terme de « Logiciel Libre », pour éviter toute confusion, mais que le terme de free software est tout de même usité.]

Logiciel Libre sous un autre nom. Mais ce nom différent reflète une différence philosophique : l' « Open Source » a été inventé par l'Open Source Initative (http://www.opensource.org/) comme une alternative délibérée au logiciel libre afin de rendre ce type de logiciel plus attractif pour les entreprises en le présentant comme une méthodologie de développement plutôt que comme un mouvement politique. Ils voulaient également tordre le cou à une autre idée préconçue : toute chose « free » (gratuite) doit être de mauvaise qualité.

Bien que toute licence libre soit également Open Source, et vice et versa (avec cependant quelques exceptions), la majorité des personnes a tendance à utiliser un terme plutôt qu'un autre et à le privilégier. En général, ceux qui préfèrent le « logiciel libre » embrassent plutôt l'aspect moral ou philosophique sous-jacent, tandis que ceux qui préfèrent le terme « Open Source » ne donnent pas de connotation idéologique à leur choix ou alors ne désirent pas mettre cet aspect en avant. Voir la section appelée « Libre contre Open Source » dans le Chapitre 1, Introduction pour plus de détails sur l'histoire de ce schisme.

La Free Software Foundation fait une excellente interprétation, totalement arbitraire, mais nuancée et juste, de ces deux termes ici : http://www.gnu.org/philosophy/free-software-for-freedom.fr.html. L'Open Source Initiative développe son point de vue sur ces deux pages : http://www.opensource.org/advocacy/case_for_hackers.php#marketing et http://www.opensource.org/advocacy/free-notfree.php.

On dit « jamais deux sans trois » et c'est aussi vrai pour les termes relatifs au logiciel libre. Le monde académique, cherchant peut-être précision et exhaustivité plus qu'élégance, semble s'être accordé sur FOSS, ou parfois F/OSS, pour « Free / Open Source Software ». Une autre variante rejoignant la liste est FLOSS, pour « Free / Libre Open Source Software » (libre est familier dans beaucoup de langues et ne souffre pas des ambiguïtés de « free » ; voir http://fr.wikipedia.org/wiki/FLOSS pour plus de précisions).

Tous ces termes signifient essentiellement la même chose : un logiciel qui peut être modifié et redistribué par chacun, parfois, mais pas toujours, avec l'exigence que l'œuvre dérivée soit librement redistribuable sous les mêmes termes.

Conforme au contrat social Debian (http://www.debian.org/social_contract).

C'est un test largement utilisé pour savoir si une licence donnée est vraiment Open Source (free, libre, etc.). La mission du projet Debian est de maintenir un système d'exploitation entièrement libre, afin qu'en l'installant personne ne puisse jamais douter de son droit de modifier et de redistribuer tout ou une partie du système. Le contrat social Debian est l'ensemble des exigences que la licence d'un programme doit remplir pour qu'il soit inclus dans Debian. Parce que le projet Debian a passé beaucoup de temps à réfléchir à la conception d'un tel test, la charte qu'ils ont conçue a prouvé sa robustesse (voir http://fr.wikipedia.org/wiki/DFSG) et à ma connaissance aucune objection sérieuse n'a été levée contre eux par la Free Software Foundation ou l'Open Source Initiative. Si vous savez qu'une licence est conforme à la charte, alors vous savez qu'elle garantie toutes les libertés importantes (comme la possibilité de faire des fourches, même contre les souhaits de l'auteur original) requises pour soutenir les dynamiques d'un projet Open Source. Toutes les licences discutées dans ce chapitre sont conformes à la charte Debian.

Approuvé par l'Open Source Initiative. Il s'agit d'un autre test largement usité pour savoir si une licence confère toutes les libertés nécessaires aux utilisateurs. La définition de l'OSI pour le logiciel libre est basée sur le contrat social Debian et toute licence qui remplit l'une des définitions remplit presque toujours l'autre. Il y a eu quelques petites exceptions au cours des années, mais elles mettaient seulement en cause des licences marginales, aucune de celles vraiment importantes présentées ici. À la différence du Projet Debian, l'OSI maintient une liste des licences qu'il a approuvées à l'adresse http://www.opensource.org/licenses/ pour qu'être « approuvé OSI » soit sans équivoque : une licence est ou n'est pas dans la liste.

La Free Software Foundation entretient aussi une liste de licences à l'adresse http://www.gnu.org/licenses/license-list.fr.html. La FSF classe les licences en catégories, non seulement en fonction de leur caractère libre, mais aussi en fonction de leur compatibilité avec la licence GNU General Public License. La compatibilité avec la GPL est un sujet important, couvert dans la section intitulée « La licence GPL et la compatibilité des licences », plus tard dans ce chapitre.

L'opposé de « libre » ou « Open Source ». Il renvoie au logiciel distribué sous des termes traditionnels, basé sur un schéma de redevance dans lequel l'utilisateur paie chaque copie, ou sous sous d'autres termes suffisamment restrictifs pour empêcher les dynamiques de l'Open Source d'opérer. Même un logiciel distribué gratuitement reste propriétaire si sa licence ne permet pas la libre redistribution et modification.

Généralement « propriétaire » et « fermé » sont synonymes. Cependant, « fermé » implique en outre que le code source ne peut pas être vu. A partir du moment où le code source ne peut pas être vu, ce qui est le cas de la plupart des logiciels propriétaires, la distinction n'a plus lieu d'être. Cependant, certains développeurs placent leurs logiciels sous une licence qui permet aux autres d'avoir accès au code source. Ils appellent ceci « Open Source » ou « proche Open Source », etc., mais ce n'est qu'une tromperie. La visibilité du code source ne fait pas tout ; l'important est ce que l'on vous autorise à faire avec. Ainsi, la différence entre propriétaire et « fermé » est souvent non pertinente et les deux termes peuvent être considérés comme synonymes.

Quelque fois, « commercial » est utilisé comme synonyme de « propriétaire », sauf qu'à proprement parler les deux ne sont pas identiques. Un logiciel libre peut être un logiciel commercial. Après tout, un logiciel peut être vendu, tant que les acheteurs peuvent toujours en distribuer eux-mêmes des copies. La commercialisation peut prendre plusieurs formes avec par exemple la vente de service, de support ou de certification. Aujourd'hui, des entreprises très rentables se sont construites autour du logiciel libre, le logiciel libre n'est donc clairement ni anti-commercial, ni anti-corporate. D'un autre côté, le logiciel libre est anti-propriétaire par nature et c'est le point essentiel sur lequel il diffère du modèle traditionnel d'une seule licence par copie.

&Oelig;uvre dont personne ne détient les droits, cela signifie que personne ne peut restreindre le droit de copier l'œuvre. « Domaine Public » n'est pas synonyme de « sans auteur ». Tout a un auteur et même si l'auteur ou les auteurs ont choisi de placer leurs travaux dans le Domaine Public cela ne change rien au fait qu'ils l'ont écrit.

Quand une œuvre est placée dans le Domaine Public, le code peut être incorporé dans un travail protégé par le droit d'auteur, par la suite une copie de cette œuvre sera placée sous le même droit d'auteur que l'ensemble de l'œuvre. Mais cela n'affecte en rien la disponibilité du travail originel qui reste toujours dans le Domaine Public. Ainsi, placer une œuvre dans le Domaine Public revient techniquement à la rendre libre, si l'on s'en réfère à la plupart des organisations certifiées logiciel libre. Cependant, il y a de bonnes raisons pour utiliser une licence plutôt que d'opter pour le Domaine Public : avec un logiciel libre, certaines restrictions peuvent être utiles, pas seulement au détenteur du droit d'auteur, mais également aux utilisateurs, comme la prochaine partie le précisera.

Une licence qui utilise le droit d'auteur légal pour atteindre un résultat opposé au droit d'auteur traditionnel. Suivant les personnes auxquelles vous vous adressez cela peut désigner une licence qui comprend les libertés présentées dans ce chapitre, ou plus rigoureusement, une licences qui ne permet pas seulement ces libertés mais les renforcera, en déclarant que les libertés doivent suivre l'œuvre. La Free Software Foundation utilise exclusivement la seconde définition ; d'autre part, c'est une alternative : beaucoup de personnes utilisent le terme de la même manière que le fait la FSF, mais d'autres, y compris ceux qui écrivent pour les médias à la mode, choisissent d'opter pour la première définition. Il n'est pas sûr que tous ceux qui utilisent ce terme soient conscients qu'il y a une distinction à faire entre ces deux définitions.

Le meilleur exemple, le plus strict et le plus proche de cette définition, est la GNU General Public License, qui stipule que tout travail dérivé doit également être placé sous cette même GNU GPL ; voir la section « La licence GPL et la compatibilité des licences » plus loin dans ce chapitre pour plus de détails.

Bien qu'il existe de nombreuses licences de logiciel libre différentes, elles se rejoignent toutes dans leurs principaux aspects : que n'importe qui puisse modifier le code, que n'importe qui puisse le redistribuer tant sous forme originale que modifiée et que les détenteurs des droits d'auteur et les auteurs ne fournissent de garantie d'aucune sorte (l'exonération de responsabilité est particulièrement importante, étant donné que les gens pourraient utiliser des versions modifiées sans même le savoir).

Les différences entre des licences se résument à quelques détails récurrents :

Compatibilité avec les licences propriétaire

Quelques licences libres permettent au code couvert d'être utilisé dans des programmes propriétaires. Cela n'affecte pas les termes de licence du programme propriétaire : il est toujours aussi propriétaire, contenant seulement une certaine proportion de code de source non propriétaire. La Licence Apache, la Licence Consortium X, la licence de type BSD et la licence de type MIT sont toutes des exemples de licences compatibles-propriétaires.

Compatibilité avec d'autres licences libres

La plupart des licences libres sont compatibles entre elles, cela signifie que le code soumis à l'une des licences peut être combiné avec le code soumis à une autre et que le résultat peut être distribué sous l'une ou l'autre des licences sans violer les termes de la seconde. L'exception majeure à ceci est la Licence Publique Générale (GPL) GNU, qui exige que n'importe quel logiciel utilisant du code sous GPL soit lui-même distribué sous licence GPL et ce sans ajouter de restrictions supplémentaire au-delà de celles que la GPL requiert. La GPL est compatible avec quelques-unes des licences libres, mais pas avec toutes. Ceci est discuté plus en détail dans la section appelée « la GPL et la compatibilité de licences » plus tard dans ce chapitre.

L'obligation de crédit

Quelques licences libres stipulent que toute utilisation du code couvert doit être accompagnée par une notice, dont l'emplacement et l'affichage sont d'habitude spécifiés, donnant crédit aux auteurs ou détenteurs des droits d'auteur sur le code. Ces licences sont souvent compatibles-propriétaire : elles n'exigent pas nécessairement que le travail dérivé soit libre, mais simplement que la paternité soit reconnue sur le code libre

La protection de marques déposées

Une variante d'exécution de crédit. Des licences protégeant les marques déposées spécifient que le nom du logiciel original (ou ses détenteurs de droit d'auteur, ou leur institution, etc.) ne peut être utilisé dans des travaux dérivés sans une permission écrite préalable. Bien que l'obligation de crédit contraint à l'usage d'un certain nom et que la protection de marque déposée contraint à son non-usage, elles expriment toutes deux le même désir : que la réputation de l'auteur du code original soit préservée et transmise, mais non ternie par l'association (d'idées).

La protection de l' « intégrité artistique »

Quelques licences (la Licence Artistique, utilisée pour la plus populaire implémentation du langage de programmation et la licence de Donald Knuth TeX, par exemple) exigent que la modification et la redistribution soient faites de manière à distinguer clairement la version originale du code de n'importe quelle version modifiée. Elles permettent essentiellement les mêmes libertés que les autres licences libres, mais imposent certaines exigences qui rendent l'intégrité du code original facile à vérifier. Ces licences ne sont pas devenues très populaires au-delà des programmes spécifiques pour lesquels elles furent écrites et ne seront pas discutées dans ce chapitre; elles sont mentionnées ici seulement dans une intention d'exhaustivité.

La plupart de ces conditions ne sont pas exclusives entre elles et quelques licences en incluent plusieurs. Le point commun entre ces licences est que ces stipulations sont la contrepartie des droits conférés au destinataire d'utiliser et/ou redistribuer le code. Par exemple, quelques projets veulent que leur nom et leur réputation soient transmis par le code, ce qui justifie la contrainte supplémentaire d'une clause de marque déposée ou de crédit ; si la contrainte est trop pesante, ce fardeau peut potentiellement détourner les utilisateurs vers un paquet utilisant une licence moins exigeante.

La frontière la plus marquée entre les licences repose sur leur incompatibilité ou leur compatibilité avec les licences propriétaire, c'est-à-dire entre la GNU General Public License et tout le reste. Parce que l'objectif primaire des auteurs de la GPL est la promotion du logiciel libre, ils créèrent délibérément la licence de façon à ce qu'il soit impossible d'intégrer du code sous GPL au sein de programmes propriétaires. En particulier, parmi les conditions de la GPL (voir http://www.fsf.org/licensing/licenses/gpl.html pour son texte intégral), on retrouve ces deux dispositions :

1. N'importe quel logiciel dérivé, n'importe quel logiciel contenant une quantité non insignifiante de code sous GPL, doit être distribué lui-même sous GPL.

2. Aucune restriction additionnelle ne peut être placée sur la redistribution du logiciel original ou dérivé. [NdT : La formulation exacte est : « You may not impose any further restrictions on the recipients' exercise of the rights granted herein. »]

Avec ces conditions, la GPL parvient à fabriquer une liberté contagieuse. Une fois qu'un programme est licencié sous GPL, ses termes de redistribution sont viraux, ils se transmettent à toute autre contenu dans lequel le code est incorporé, rendant efficacement impossible d'utiliser du code sous GPL dans un programme fermé.

Cependant, ces mêmes clauses rendent aussi la GPL incompatible avec certaines autres licences libres. Le cas le plus courant où cela arrive est celui ou l'autre licence impose une exigence, par exemple une clause de crédit exigeant que les auteurs originaux soient mentionnés, qui est incompatible avec celles de la GPL stipulant que « Vous ne pouvez pas imposer de nouvelles restrictions... ». Du point de vue de la Free Software Foundation, ces effets secondaires sont désirables, ou tout du moins non regrettables. La GPL tient non seulement votre logiciel libre, mais transforme efficacement votre logiciel en un agent poussant les autres logiciels à devenir libres dans les mêmes mesures.

Quant à savoir s'il s'agit ou non d'une bonne façon de promouvoir le logiciel libre, c'est l'un des trolls les plus persistants sur Internet (voyez la section appelée « Éviter les trolls » dans le Chapitre 6, Communication) et nous ne l'examinerons pas ici. Ce qui est important ici est que la compatibilité avec la GPL est une question importante lors du choix de la licence. La GPL est de loin la licence open-source la plus populaire; sur http://freshmeat.net/stats/#license, elle est à 68 % et la licence suivante la plus haute est à 6 %. Si vous voulez que votre code puisse se mélanger librement avec du code sous GPL, et il y a beaucoup de code sous GPL, alors vous devriez choisir une licence GPL-compatible. La plupart des licences open-source compatible avec la GPL le sont aussi avec les licences propriétaires : ainsi, un code sous une telle licence peut être utilisé par un programme sous GPL tout comme il peut être utilisé par un programme propriétaire. Bien sûr, les résultats de ces mélanges ne seront pas compatibles entre eux, puisque l'un serait sous GPL quand l'autre serait sous une licence propriétaire. Mais ce souci s'applique uniquement aux travaux dérivés et non pas au code que vous distribuez en premier lieu.

Heureusement, la Free Software Foundation entretient une liste rassemblant les licences compatibles avec le GPL et celles qui ne le sont pas sur la page http://www.gnu.org/licenses/license-list.html. Toutes les licences discutées dans ce chapitre sont présentes dans cette liste, dans un catégorie ou l'autre.

    •   Familiarity. If you use one of the three or four most popular licenses, people won't feel they have to
        read the legalese in order to use your code, because they'll have already done so for that license a
        long time ago.
    •   Quality. Unless you have a team of lawyers at your disposal, you are unlikely to come up with a leg-
        ally solid license. The licenses mentioned here are the products of much thought and experience; un-
        less your project has truly unusual needs, it is unlikely you would do better.
   

Quand vous choisissez une licence à appliquer à votre projet privilégiez l'utilisation d'une licence déjà existante plutôt que d'en créer une nouvelle si possible. Le choix d'une licence préexistante est conseillé pour deux raisons :

• Familiarité. Si vous optez pour l'une des trois ou quatre licences les plus populaires, les utilisateurs ne sentiront pas contraints de lire les dispositions légales avant d'utiliser le code, parce qu'ils l'ont déjà fait pour cette licence depuis longtemps.
• Qualité. A moins que vous n'ayez une équipe de juristes à votre disposition, il y a peu de chances que vous parveniez à réaliser une licence juridiquement solide. Les licences mentionnées dans ce livre sont les produits de l'expérience et de mures réflexions ; à moins que votre projet ait vraiment des besoins spécifiques c'est le meilleur choix que vous puissiez faire.

Pour appliquer l'une de ces licences à votre projet, rendez vous à la section « Comment appliquer une licence à votre logiciel » dans le Chapitre 2, Bien démarrer.

Si votre souhait est que votre code soit accessible au plus grand nombre de développeurs et de travaux dérivés possible et que le fait que votre code se retrouve sous une licence propriétaire ne vous dérange pas, choisissez la licence du MIT / X Window System (appelée ainsi parce que c'est sous cette licence que l'Institut de Technologie du Massachusetts a déposé son code du système X Window). Cette licence véhicule un message simple : « Vous êtes libre d'utiliser ce code comme vous le souhaitez ». Elle est compatible avec la GNU GPL, elle est succincte, simple et facile à comprendre.

    Copyright (c) <year> <copyright holders>
    Permission is hereby granted, free of charge, to any person obtaining
    a copy of this software and associated documentation files (the
    "Software"), to deal in the Software without restriction, including
    without limitation the rights to use, copy, modify, merge, publish,
    distribute, sublicense, and/or sell copies of the Software, and to
    permit persons to whom the Software is furnished to do so, subject to
    the following conditions:
    The above copyright notice and this permission notice shall be
    included in all copies or substantial portions of the Software.
    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
    EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
    MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
    NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
    LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
    OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
       WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
       (Tiré de http://www.opensource.org/licenses/mit-license.php.)

Si vous préférez que le code de votre projet ne soit pas utilisé par des programmes propriétaires ou que ce critère n'est pas décisif à vos yeux, choisissez la GNU General Public License (http://www.fsf.org/licensing/licenses/gpl.html), en français (http://fsffrance.org/gpl/gpl-fr.fr.html). La GNU GPL est probablement la plus utilisée des licences de logiciels libres dans le monde aujourd'hui ; cette reconnaissance mondiale est par ailleurs en soi l'un des principaux avantages de la GNU GPL. Quand vous codez une bibliothèque (library) dont le principal but est d'être utilisé par d'autres programmes, veillez attentivement à ce que les restrictions imposées par GNU GPL correspondent aux buts de votre projet. Dans certains cas, par exemple si vous essayez de remplacer une bibliothèque propriétaire concurrente qui fait la même chose, il serait plus stratégique d'appliquer à votre code une licence qui permette son incorporation dans des programmes propriétaires, même si vous ne le souhaitiez pas. La Free Software Foundation a conçu une alternative à la GNU GPL pour de telles pratiques : la GNU Library GPL, plus tard renommée en GNU Lesser GPL (plus communément désignée par l'acronyme GNU LGPL). La GNU LGPL est moins restrictive que la GNU GPL et peut être intégrée plus facilement à du code non-libre. Cependant, elle est également relativement complexe et demande un effort de compréhension, aussi, si vous ne comptez pas utiliser la GNU GPL, je vous recommande d'opter simplement pour la licence MIT / X-style.

L'une des conséquences du choix de la GNU GPL est la possibilité, faible mais pas insignifiante, de vous trouver, vous ou votre projet, embringué dans un débat sur la véracité de la « liberté » de la GNU GPL, étant donné qu'elle impose quelques restrictions sur l'utilisation du code, à savoir qu'il ne peut être redistribué sous aucune autre licence. Pour certains, l'existence de cette restriction signifie que la GNU GPL est « moins libre » que des licences plus permissives telles que la licence MIT/X-Style. Cet argument en entraîne souvent un autre : « plus libre » est mieux que « moins libre » (après tout, qui n'est pas en faveur de la liberté ?), il en découle alors que ces licences sont meilleures que la GNU GPL. Ce débat est encore un autre « troll » populaire (voir la section appelée « Éviter les trolls », Chapitre 6, Communication). Évitez de nourrir le troll, au moins dans les forums. N'essayez pas de prouver que la GNU GPL est « moins libre », « aussi libre » ou « plus libre » que les autres licences. Mettez plutôt en exergue les raisons spécifiques à votre projet qui ont motivé votre choix. Si la reconnaissance d'une licence était l'un des critères de choix, dites-le. Si l'un de vos critères était l'obligation d'utiliser une licence libre pour un travail dérivé, dites-le également, mais refusez d'être embarqué dans une conversation à propos de ce qui fait que le code est « plus » ou « moins » libre. La liberté est un vaste sujet et vous n'avez rien à gagner si la terminologie est utilisée comme prétexte pour trouver matière à débattre.

Comme j'écris un livre ici et que nous ne sommes pas sur une liste de diffusion, je peux vous confier que je n'ai jamais compris l'argument « La GPL n'est pas libre ». La seule restriction que la GPL impose est de ne pas imposer de restrictions supplémentaires. Penser que cela mène à moins de liberté m'a toujours semblé pareil que de dire que l'abolition de l'esclavage réduit la liberté parce qu'alors les gens ne peuvent plus posséder d'esclaves (Oh, et si vous finissez par être entraîné dans un tel débat, ne rendez pas les choses pires encore en faisant des analogies dangereuses).

              All advertising materials mentioning features or use of this software must display the
              following acknowledgement: This product includes software developed by the Uni-
              versity of California, Lawrence Berkeley Laboratory.

              Neither the name of the <ORGANIZATION> nor the names of its contributors may be
              used to endorse or promote products derived from this software without specific prior
              written permission.

Un assez grand nombre de logiciels Open Source sont distribués sous licence BSD (ou parfois une licence dérivée de la Licence BSD). La Licence BSD originale était employée pour le Berkeley Software Distribution, dans lequel l'Université de Californie a dévoilé des parties importantes d'une implémentation Unix. Cette licence (dont le texte exact se trouve à la section 2.2.2 à l'adresse http://www.xfree86.org/3.3.6/COPYRIGHT2.html#6) était proche de l'esprit de la Licence MIT/X, sauf pour une clause :

              All advertising materials mentioning features or use of this software must display the
              following acknowledgement: This product includes software developed by the Uni-
              versity of California, Lawrence Berkeley Laboratory.

              Tout support publicitaire faisant mention ou utilisant ce logiciel doit faire apparaître
              le message suivant : Ce produit inclut des logiciels développés par l'Université de Cali-
              fornie, Laboratoire Lawrence Berkeley

La présence de cette clause rendait non seulement la Licence BSD originale incompatible avec la GPL, mais elle établissait également un dangereux précédent : alors que d'autres organisations ajoutaient des clauses de publicité à leur logiciels libres, remplaçant par le nom de leur propre organisation la mention « the University of California, Lawrence Berkeley Laboratory », les revendeurs de logiciels devaient afficher de plus en plus de mentions. Heureusement, de nombreux projets qui utilisaient cette licence se sont aperçus du problème et ont simplement abandonné la clause concernant la publicité. En 1999, même l'Université de Californie en a fait de même. Il en résulte la Licence BSD révisée, qui est simplement la Licence BSD originale sans la clause de publicité. Cette histoire rend malgré tout le terme « Licence BSD » ambigu : parle-t-on de la version originale ou de la version révisée ? C'est pourquoi je préfère la Licence MIT/X qui est en gros équivalente et qui ne souffre pas de cette ambiguïté. Mais il y a peut-être quand même une raison pour préférer la Licence BSD dans sa forme révisée par rapport à la Licence MIT/X, la Licence BSD inclut cette clause :

              Neither the name of the <ORGANIZATION> nor the names of its contributors may be
              used to endorse or promote products derived from this software without specific prior
              written permission.

              Ni le nom de <ORGANISATION> ni les noms des participants ne peuvent être employés pour
              approuver ou promouvoir les produits dérivés de ce logiciel sans accord écrit préalable.

Sans cette clause il n'est pas clair si un bénéficiaire du logiciel aurait le droit ou pas d'utiliser le nom du propriétaire de la licence, mais la clause enlève tout doute possible. Pour les organisations qui se préoccupent du contrôle des droits d'auteur, la Licence BSD révisée serait donc légèrement plus adaptée que la Licence MIT/X. En général cependant, une licence de droit d'auteur libre n'implique pas que les bénéficiaires aient un quelconque droit d'utilisation ou de masquage de vos marques, les lois sur le droit d'auteur et sur la protection des marques sont deux choses différentes. Si vous désirez utiliser la Licence BSD révisée, un modèle est disponible à cette adresse : http://www.opensource.org/licenses/bsd-license.php.

Il existe trois approches de la détention des droits d'auteur sur un code libre, fruit du travail de plusieurs personnes. La première consiste à purement et simplement ignorer le problème du droit d'auteur (je vous le déconseille). La deuxième est de demander un Accord de Licence du Participant (ALP) à chaque personne travaillant sur le projet, accordant explicitement au projet le droit d'utiliser le code du participant. C'est en général suffisant pour la plupart des projets et le point positif est que dans certaines juridictions ces ALP peuvent être envoyés par courrier électronique. La troisième approche est d'obtenir des participants l'attribution complète des droits d'auteur afin que le projet (c'est-à-dire une entité légale, généralement à but non lucratif) soit le détenteur de tous les droits d'auteur. C'est la voie qui, légalement, est la plus sure, mais également la plus contraignante pour les participants, seuls quelques projets l'empruntent.

Notez que même si la propriété intellectuelle est centralisée le code demeure libre car les licences Open Source ne donnent pas au détenteur des droits la possibilité de rendre rétroactivement propriétaire toutes les copies du code. Donc même si le projet, en temps qu'entité légale, retourne soudainement sa veste et décide de distribuer le code sous une licence plus restrictive cela ne posera pas de problème à la communauté publique. Les autres développeurs n'auraient qu'à initier une fourche basée sur la dernière version libre du code et à continuer comme si rien ne s'était passé. Comme cette possibilité existe la plupart des participants coopèrent lorsqu'on leur demande de signer un ALP ou une attribution de droit d'auteur.

Les ALP offrent certainement le meilleur compromis entre sécurité et aspect pratique. Un ALP est typiquement un formulaire électronique qu'un développeur remplit et renvoie au projet. Dans de nombreuses juridictions l'envoi par courrier électronique est jugé suffisant. Une signature électronique sécurisée peut être requise, mais ce n'est pas toujours le cas, consultez un avocat pour savoir ce qui serait le mieux pour votre projet. La plupart des projets utilisent deux ALP légèrement différentes, une pour les personnes et une pour les entreprises. Mais dans les deux cas le langage de base est le même : le participant accorde au projet « ... un droit d'auteur perpétuel, dans le monde entier, non-exclusif, sans frais, libre de droit, irrévocable pour la reproduction, la préparation d'œuvres dérivées, pour l'exposition publique, la présentation publique, pour sous-licencier et distribuer [les] Contributions et toute œuvre dérivée. » Ici aussi vous devriez faire approuver votre ALP par un avocat, mais si vous réunissez tous ces adjectifs ça devrait être bon.

Lorsque vous demandez des ALP de la part des participants, insistez bien sur le fait que vous ne demandez pas une attribution des droits d'auteur. En fait de nombreux ALP commencent par un rappel au lecteur :

    • Individual contributor CLAs:
       • http://apache.org/licenses/icla.txt
       • http://code.google.com/legal/individual-cla-v1.0.html
    • Corporate contributor CLAs:
       • http://apache.org/licenses/cla-corporate.txt
       • http://code.google.com/legal/corporate-cla-v1.0.html

This is a license agreement only; it does not transfer copyright ownership and does not change your rights to use your own Contributions for any other purpose. Here are some examples:

    • Individual contributor CLAs:
       • http://apache.org/licenses/icla.txt
       • http://code.google.com/legal/individual-cla-v1.0.html
    • Corporate contributor CLAs:
       • http://apache.org/licenses/cla-corporate.txt
       • http://code.google.com/legal/corporate-cla-v1.0.html

ou en français :

Ceci n'est qu'un accord de licence, il n'y a pas de transfert de droit d'auteur et vous conservez le droit d'utiliser vos propres Contributions à toute autre fin. Voici quelques exemples :

    • ALP pour les participants individuels :
       • http://apache.org/licenses/icla.txt
       • http://code.google.com/legal/individual-cla-v1.0.html
    • ALP pour les entreprises participantes :
       • http://apache.org/licenses/cla-corporate.txt
       • http://code.google.com/legal/corporate-cla-v1.0.html

Le transfert du droit d'auteur signifie que le participant accorde au projet la propriété de ses contributions. Idéalement cela se fait sur papier et par envoi, soit par fax soit par courrier postal, au projet. Certains projets imposent une attribution complète des contributions car il peut s'avérer utile qu'une seule et même entité légale possède tous les droits d'auteur sur le code complet si les termes de la licence Open Source doivent être défendus devant un tribunal. Si ce n'est pas le cas, tous les participants pourraient être amenés à devoir coopérer mais certains pourraient ne pas avoir le temps ou ne pas être joignables lorsque le problème se pose. Selon les organismes la rigueur appliquée à la collecte des droits varie. Certains se contentent d'une déclaration informelle du participant sur une liste de diffusion publique, quelque chose comme : « J'accorde, par la présente, les droits sur ce code au projet, les mêmes termes de licence que ceux du projet s'appliquant ». Parmi les avocats à qui j'ai parlé, au moins un estime cela largement suffisant, certainement parce que cette déclaration est faite dans un cadre où l'attribution du droit d'auteur est normale et attendue de toute façon et parce que cela représente une preuve de bonne foi pour le projet pour s'assurer des intentions profondes du participant. D'un autre côté la Free Software Foundation va à l'extrême opposé : ils demandent aux participants de signer personnellement et d'envoyer par courrier postal un document contenant une déclaration formelle d'attribution de droit d'auteur, parfois juste pour une contribution, parfois pour toutes les contributions présentes et à venir. Si le développeur est employé par une entreprise, la FSF demande également que le document soit signé par l'employeur. La paranoïa de la FSF est compréhensible. Si une personne viole les termes de la GPL en incorporant du code sous licence GPL dans un programme propriétaire, il faut que la FSF puisse se défendre devant un tribunal et ils veulent que leur droit d'auteur soit inattaquable si le cas se présente. Puisque la FSF est détentrice des droits d'auteur de nombreux logiciels populaires ils doivent s'y préparer. En général, à moins que pour des raisons particulières votre projet nécessite une cession des droits en bonne et due forme, contentez vous des ALP, ils facilitent la vie à tout le monde.

   Most projects have a single legal entity own the copyright on the entire code base. This is done for vari-
   ous reasons. If the terms of the copyright ever need to be defended or enforced in court, it's much easier
   if a single entity has the right to do so; otherwise, all of the contributors would have to cooperate, and
   some might not have time or even be reachable when the issue arises. Also, if the code is the target of a
   copyright infringement suit, you wouldn't want the individual developers to be personally exposed to li-
   ability.
   Remember that centralized ownership of the copyright does not make the code any less free. Open
   source licenses do not give the copyright holder the right to retroactively proprietize all copies of the
   code. Even if the copyright-holding entity suddenly turned around and started distributing all the code
   under a restrictive license, it wouldn't cause a problem for the public project. The other developers
   would simply start a fork based on the latest free copy of the code, and continue as if nothing had
   happened. Because they know they can do this, most developers do not object when asked to assign
   copyright to some sponsoring organization.
   Different organizations apply different amounts of rigor to the task of collecting copyright assignments.
   For most, simply getting an informal statement from a contributor on the public list is
   enough—something to the effect of "I hereby assign copyright in this code to the project, to be licensed
   under the same terms as the rest of the code." At least one lawyer I've talked to says that's really enough,
   presumably because it happens in a context where copyright assignment is normal and expected anyway,
   and because it represents a bona fide effort on the project's part to ascertain the developer's true inten-
   tions. On the other hand, the Free Software Foundation goes to the opposite extreme: they require con-
   tributors to physically sign and mail in a piece of paper containing a formal statement of copyright assignment, 
   sometimes for just one contribution, sometimes for current and future contributions. If the developer is employed,
   the FSF asks that the employer sign it too.The FSF's paranoia is understandable. If someone violates the terms of 
   the GPL by incorporating some of their software into a proprietary program, the FSF will need to fight that in court, and they want their
    copyrights to be as airtight as possible when that happens. Since the FSF is copyright holder for a lot of
    popular software, they view this as a real possibility. Whether your organization needs to be similarly

La plupart des projets donnent l'entièreté des droits d'auteurs à une seule entité légale sur tout le code. Il y a plusieurs raisons à cela. Si les termes du droit d'auteur doivent un jour être défendus ou faits entendre devant une court, il est beaucoup plus aisé si une seule entité en a le droit, autrement, tous les contributeurs devraient coopérer alors que certains pourraient ne pas avoir le temps ou pourraient même ne pas être joignables lorsque le problème se présente. De plus, si le code fait l'objet d'une poursuite pour violation du droit d'auteur, vous ne voudriez pas que l'un de vos développeurs soit personnellement poursuivit. Souvenez vous que la concentration de la propriété du droit d'auteur ne rend pas le code moins libre. Les licences Open Source ne donnent pas le droit au détenteur du droit d'auteur de rendre rétroactivement propriétaire toutes les copies du code. Même si l'entité possédant les droits d'auteur retournait soudainement sa veste et décidait de distribuer le code sous une licence plus restrictive, cela ne poserait pas de problème au projet public. Les autres développeurs n'auraient qu'à commencer une fourche basée sur la dernière version libre du code et qu'à continuer comme si rien ne s'était passé. Comme ils savent qu'ils ont cette possibilité, ça ne pose pas de problème pour la plupart des développeurs d'attribuer les droits d'auteur à une organisation fournissant le support financier.

Selon l'organisation, la rigueur avec laquelle elle collecte les attributions de droits d'auteur varie. Pour la plupart, obtenir une déclaration de l'un des contributeurs sur la liste publique est suffisant, quelque chose comme « Par la présente, j'attribue les droits d'auteur sur ce code au projet, il devra être publié sous la même licence que le reste du code. » Au moins un des avocats à qui j'ai parlé dit que c'est largement suffisant, certainement parce que cela se déroule dans un contexte où l'attribution du droit d'auteur est normal et attendu de toute façon et parce que cela représente un acte de bonne foi de la part du projet pour s'assurer des réelles intentions des développeurs. D'un autre côté, la Free Software Foundation a choisi la solution opposée : ils demandent que les participants signent et envoient par courrier une lettre contenant une déclaration officielle de l'attribution des droits d'auteur, parfois pour une seule contribution, parfois pour toutes leurs contributions présentes et à venir. Si le développeur est un employé, la FSF demande également que l'employeur signe. La paranoïa de la FSF est compréhensible. Si quelqu'un viole les termes de la GPL en ajoutant certains de leurs logiciels dans des programmes propriétaires, la FSF devra alors se battre devant une court et ils veulent donc que leurs droits d'auteur soient aussi solides que possible quand cela arrive. Comme la FSF est détentrice des droits d'auteur d'un grand nombre de logiciels populaires, cette éventualité est très réel pour eux. C'est à vous de décider, avec l'aide d'avocats, si votre organisation doit être aussi prudente.

    Some projects try to fund themselves by using a dual licensing scheme, in which proprietary derivative
    works may pay the copyright holder for the right to use the code, but the code still remains free for use
    by Open Source projects. This tends to work better with code libraries than with standalone applications,
    naturally. The exact terms differ from case to case. Often the license for the free side is the GNU GPL,
    since it already bars others from incorporating the covered code into their proprietary product without
    permission from the copyright holder, but sometimes it is a custom license that has the same effect. An
    example of the former is the MySQL license, described at ht-
    tp://www.mysql.com/company/legal/licensing/; an example of the latter is Sleepycat Software's licens-
    ing strategy, described at http://www.sleepycat.com/download/licensinginfo.shtml.
    You might be wondering: how can the copyright holder offer proprietary licensing for a mandatory fee if
    the terms of the GNU GPL stipulate that the code must be available under less restrictive terms? The an-
    swer is that the GPL's terms are something the copyright holder imposes on everyone else; the owner is
    therefore free to decide not to apply those terms to itself. A good way to think of it is to imagine that the
    copyright owner has an infinite number of copies of the software stored in a bucket. Each time it takes
    one out of the bucket to send into the world, it can decide what license to put on it: GPL, proprietary, or
    something else. Its right to do this is not tied to the GPL or any other Open Source license; it is simply a
    power granted by copyright law.
    The attractiveness of dual licensing is that, at its best, it provides a way for a free software project to get
    a reliable income stream. Unfortunately, it can also interfere with the normal dynamics of Open Source
    projects. The problem is that any volunteer who makes a code contribution is now contributing to two
    distinct entities: the free version of the code and the proprietary version. While the contributor will be
    comfortable contributing to the free version, since that's the norm in Open Source projects, she may feel
    funny about contributing to someone else's semi-proprietary revenue stream. The awkwardness is ex-
    acerbated by the fact that in dual licensing, the copyright owner really needs to gather formal, signed
    copyright assignments from all contributors, in order to protect itself from a disgruntled contributor later
    claiming a percentage of royalties from the proprietary stream. The process of collecting these assign-
    ment papers means that contributors are starkly confronted with the fact that they are doing work that
    makes money for someone else.
    Not all volunteers will be bothered by this; after all, their contributions go into the Open Source edition
    as well, and that may be where their main interest lies. Nevertheless, dual licensing is an instance of the
    copyright holder assigning itself a special right that others in the project do not have, and is thus bound
    to raise tensions at some point, at least with some volunteers.
    What seems to happen in practice is that companies based on dual licensed software do not have truly
    egalitarian development communities. They get small-scale bug fixes and cleanup patches from external
    sources, but end up doing most of the hard work with internal resources. For example, Zack Urlocker,
    vice president of marketing at MySQL, told me that the company generally ends up hiring the most act-
    ive volunteers anyway. Thus, although the product itself is Open Source, licensed under the GPL, its de-
    velopment is more or less controlled by the company, albeit with the (extremely unlikely) possibility
    that someone truly dissatisfied with the company's handling of the software could fork the project. To
    what degree this threat preëmptively shapes the company's policies I don't know, but at any rate,

Certains projets tentent de s'auto-financer en adoptant une double licence, c'est un système dans lequel toute société peut payer le détenteur des droits d'auteur pour obtenir son accord pour utiliser le code dans un programme propriétaire, mais le code reste libre pour les projets Open Source. Cela fonctionne mieux pour des librairies de code que pour des applications autonomes évidemment. Les termes exactes varient d'un cas à l'autre. La licence pour l'aspect libre est la GNU GPL, puisqu'elle empêche déjà n'importe qui d'ajouter le code protégé dans un produit propriétaire sans l'autorisation du détenteur des droits, mais parfois c'est une licence personnalisée ayant les mêmes effets. Ainsi la licence MySQL décrite à l'adresse http://www.mysql.com/company/legal/licensing/ utilise la licence GNU GPL et on peut citer comme exemple de licence personnalisée le système de licence de Sleepycat Software décrit à l'adresse http://www.sleepycat.com/download/licensinginfo.shtml.

Vous vous demandez sûrement comment le détenteur des droits peut proposer une licence propriétaire contre une rémunération si les termes de la GNU GPL stipulent que le code doit être mis à disposition sous des conditions moins restrictive. La réponse est que les termes de la GPL sont imposés par le détenteur des droits à tout le monde sauf aux logiciels propriétaires, l'auteur est libre de décider de ne pas appliquer les mêmes termes pour lui même. Une bonne représentation de cela est de s'imaginer que le détenteur des droits possède un nombre infini de copies du logiciel rangées dans un sceau. A chaque fois qu'il sort une copie du sceau pour la donner au monde il peut décider quelle licence il lui applique : GPL, propriétaire ou une autre encore. Son droit de faire cela n'est pas lié à la GPL ou à aucune autre licence Open Source, c'est simplement un pouvoir qui lui est accordé par les lois du droit d'auteur.

L'attrait de la double licence est que, dans le meilleur des cas, elle donne un moyen à un projet de logiciel libre d'avoir une source de revenue sure. Malheureusement, cela peut aussi interférer avec la dynamique normale d'un projet Open Source. Le problème est que chaque volontaire apportant sa contribution au code participe maintenant aux deux entités : à la fois à la version libre et à la version propriétaire du code. Alors que ça ne lui posera pas de problème de contribuer à la version libre, puisque c'est la norme dans les projets Open Source, il pourrait ne pas désirer contribuer aux revenus constants semi-propriétaires de quelqu'un d'autre. Ce côté étrange est exacerbé par le fait que pour une double licence, le détenteur des droits doit vraiment recevoir une déclaration officielle, signée de l'attribution des droits d'auteur par tous les participants afin de se protéger si plus tard un participant mécontent prétend à un pourcentage des droits des revenus propriétaires. Le processus de collecte des attributions signifie que les participants sont bien prévenus que le travail qu'ils produisent enrichira quelqu'un d'autre.

Tous les volontaires ne se soucieront pas de ça, après tout leur contribution participe également au développement de l'édition Open Source et c'est bien là leur intérêt. Néanmoins, la double licence est un exemple où le propriétaire des droits d'auteur se donne à lui même un droit particulier que les autres personnes dans le projet n'ont pas, ce qui conduira tôt ou tard à des tensions, au moins avec quelques volontaires.

En pratique il semble que les entreprises qui travaillent sur des logiciels à double licence n'ont pas une communauté de développement vraiment égalitaire. Ils profitent des correctifs de bogues mineurs ou des maintenances proposés par des sources externes, mais ils font le gros du travail en interne. Par exemple, Zack Urlocker, vice président du marketing chez MySQL, m'a dit que l'entreprise finit souvent pas employer les volontaires les plus actifs de toute façon. Ainsi, le produit en lui-même est Open Source, sous une licence GPL, son développement est plus ou moins contrôlé par une entreprise, même si la probabilité (extrêmement faible) que quelqu'un de vraiment insatisfait de la gestion du logiciel par l'entreprise fasse une fourche existe. Je ne sais pas à quel point cette menace entre en compte dans la politique de l'entreprise, mais en tout cas, MySQL ne semble pas avoir de problème d'acceptation, que ce soit dans le monde de l'Open Source ou ailleurs.

   Software patents are the lightning rod issue of the moment in free software, because they pose the only
   real threat against which the free software community cannot defend itself. Copyright and trademark
   problems can always be gotten around. If part of your code looks like it may infringe on someone else's
   copyright, you can just rewrite that part. If it turns out someone has a trademark on your project's name,
   at the very worst you can just rename the project. Although changing names would be a temporary in-
   convenience, it wouldn't matter in the long run, since the code itself would still do what it always did.
   But a patent is a blanket injunction against implementing a certain idea. It doesn't matter who writes the
   code, nor even what programming language is used. Once someone has accused a free software project
   of infringing a patent, the project must either stop implementing that particular feature, or face an ex-
   pensive and time-consuming lawsuit. Since the instigators of such lawsuits are usually corporations with
   deep pockets—that's who has the resources and inclination to acquire patents in the first place—most
   free software projects cannot afford the latter possibility, and must capitulate immediately even if they
   think it highly likely that the patent would be unenforceable in court. To avoid getting into such a situ-
   ation in the first place, free software projects are starting to code defensively, avoiding patented al-
   gorithms in advance even when they are the best or only available solution to a programming
   problem.22
   Surveys and anecdotal evidence show that not only the vast majority of Open Source programmers, but a
   majority of all programmers, think that software patents should be abolished entirely.23 Open source
   programmers tend to feel particularly strongly about it, and may refuse to work on projects that are too
   closely associated with the collection or enforcement of software patents. If your organization collects
   software patents, then make it clear, in a public and irrevocable way, that the patents would never be en-
   forced on Open Source projects, and that they are only to be used as a defense in case some other party
   initiates an infringement suit against your organization. This is not only the right thing to do, it's also
   good Open Source public relations.
   Unfortunately, collecting patents for defensive purposes is a rational action. The current patent system,
   at least in the United States, is by its nature an arms race: if your competitors have acquired a lot of pat-
   ents, then your best defense is to acquire a lot of patents yourself, so that if you're ever hit with a patent
   infringement suit you can respond with a similar threat—then the two parties usually sit down and work
   out a cross-licensing deal so that neither of them has to pay anything, except to their intellectual property
   lawyers of course.
   The harm done to free software by software patents is more insidious than just direct threats to code de-
   velopment, however. Software patents encourage an atmosphere of secrecy among firmware designers,
   who justifiably worry that by publishing details of their interfaces they will be giving technical help to
   competitors seeking to slap them with patent infringement suits. This is not just a theoretical danger; it
   has apparently been happening for a long time in the video card industry, for example. Many video card
   manufacturers are reluctant to release the detailed programming specifications needed to produce high-
   performance Open Source drivers for their cards, thus making it impossible for free operating systems to
   support those cards to their full potential. Why would the manufacturers do this? It doesn't make sense
   for them to work against software support; after all, compatibility with more operating systems can only
   mean more card sales. But it turns out that, behind the design room door, these shops are all violating
   one another's patents, sometimes knowingly and sometimes accidentally. The patents are so unpredict-
   able and so potentially broad that no card manufacturer can ever be certain it's safe, even after doing a
   patent search. Thus, manufacturers dare not publish their full interface specifications, since that would
   make it much easier for competitors to figure out whether any patents are being infringed. (Of course,
   the nature of this situation is such that you will not find a written admission from a primary source that it
   is going on; I learned it through a personal communication.)
   Some free software licenses have special clauses to combat, or at least discourage, software patents. The
   22
      Sun Microsystems and IBM have also made at least a gesture at the problem from the other direction, by freeing large numbers
   of software patents—1600 and 500 respectively—for use by the Open Source community. I am not a lawyer and thus can't evaluate
   the real utility of these grants, but even if they are all important patents, and the terms of the grants make them truly free for use by
   any Open Source project, it would still be only a drop in the bucket.
   23
      See http://lpf.ai.mit.edu/Whatsnew/survey.html for one such survey.

   7. If, as a consequence of a court judgement or allegation of patent

Les brevets logiciels sont LE sujet délicat du moment pour les logiciels libres car ils représentent la seule vraie menace contre laquelle la communauté du logiciel libre ne peut pas se défendre. On peut toujours contourner les problèmes de droit d'auteur et de marque. Si une partie de votre code semble empiéter sur les droits d'auteur de quelqu'un il n'y a qu'à la ré-écrire. S'il se trouve que quelqu'un a déjà les droits sur le nom de votre projet, dans le pire des cas vous pouvez toujours changer le nom du projet. Même si cela est un désagrément temporaire, à long terme ça n'a pas d'importance puisque le code en lui-même accomplit toujours ce qu'il a toujours accompli. Mais un brevet vous interdit purement et simplement d'implémenter une idée précise. La manière d'écrire le code ou même la langage utilisé importent peu, dès que quelqu'un accuse un projet de logiciel libre de violer un brevet, le projet doit soit arrêter d'utiliser cette fonctionnalité particulière soit faire face à un procès coûteux en temps et en argent. Puisqu'en général ces procès sont intentés par des firmes aux poches bien remplies, ce sont celles qui ont les ressources et qui tendent à acheter les brevets, les projets de logiciel libre ne peuvent pas se permettre cette dernière solution et doivent immédiatement capituler même s'ils pensent qu'il y a peu de chance que le brevet soit défendable devant un tribunal. Pour tout simplement éviter de se retrouver dans cette situation les projets de logiciels libres se mettent à coder défensivement en évitant les algorithmes brevetés, même s'ils représentent la meilleure voire la seule solution possible à un problème de programmation.[22]

Des sondages ainsi que des preuves anecdotiques montrent que non seulement une vaste majorité des programmeurs Open Source, mais aussi une vaste majorité de tous les programmeurs pensent que les brevets logiciels devraient être abolis purement et simplement.[23] Les programmeurs Open Source les voient d'un très mauvais œil et parfois refusent de travailler sur des projets qui naviguent dans les eaux troubles de la collecte ou de la mise en application des brevets logiciels. Si votre organisation amasse des brevets logiciels, annoncez publiquement, clairement et de manière irrévocable que ces brevets ne seront jamais employés contre un projet Open Source et qu'ils ne seront utilisés qu'à des fins défensives au cas où une tierce partie lancerait une action en justice pour violation de brevet contre votre organisation. Ce n'est pas seulement votre unique alternative, c'est aussi un exemple de bonne communication dans le monde de l'Open Source.

Malheureusement, la collecte de brevets à des fins défensives est une action rationnelle. Le système de brevets actuel, au moins aux États-Unis, est de part sa nature une course à l'armement : si vos adversaires ont acquis de nombreux brevets, alors votre meilleure défense est d'en acquérir beaucoup à votre tour, ainsi, si l'on vous attaque pour violation de brevet, vous pouvez répondre part la même menace et par conséquent les deux parties en question se réuniront à la table des négociations et s'entendront sur un accord de licence croisée, ainsi, personne n'a rien à payer, sauf aux avocats spécialisés en propriété industrielle bien sûr.

Les dommages causés aux logiciels libres par les brevets logiciels sont plus insidieux que la simple menace sur le développement de code. Les brevets logiciels encouragent au secret chez les développeurs de firmware qui craignent, à juste titre, que s'ils publient les détails de leur interface ils fourniront une aide technique à leurs adversaires qui ne cherchent qu'à les attaquer pour violation de brevet logiciel. Ce n'est pas qu'un danger purement théorique, il semble que ça se soit produit pendant un certain temps dans l'industrie des cartes graphiques par exemple. Beaucoup de fabricants de cartes graphiques sont réticents à l'idée de publier les spécifications détaillées de leurs programmes qui sont pourtant nécessaires à la production de pilotes Open Source de très bonne qualité pour leur matériel, rendant de ce fait impossible le support de ces cartes à leur plein potentiel par les systèmes d'exploitation libres. Pourquoi les fabricants feraient-ils cela ? Il n'y a pas de raison pour qu'ils empêchent le support technique de leurs produits, après tout, si leurs cartes sont compatibles avec plus de systèmes d'exploitation cela ne peut que se traduire en une augmentation des ventes. La véritable raison est que derrière la porte de la salle de fabrication, ces vendeurs ne font que violer les brevets de leurs concurrents, parfois sciemment, parfois par accident. Les brevets sont si imprévisibles et potentiellement si vastes qu'aucun fabriquant de carte ne peut jamais être sûr de ne violer aucun brevet logiciel, même après avoir fait une recherche. Par conséquent les producteurs n'osent pas publier les spécifications complètes de leur interface puisque cela aiderait leurs concurrents à déterminer si certains de leurs brevets sont violés (évidemment, de par la nature de la situation vous ne trouverez aucun témoignage écrit d'une source sure vous confirmant cela, je l'ai appris grâce à un contact personnel).

Certaines licences de logiciel libre possèdent des clauses particulières pour combattre ou au moins décourager les brevets logiciels.

La GNU/GPL, par exemple, dit ceci :

7. Si, en conséquence d'un jugement du tribunal ou d'allégations de violation de brevet ou pour toute autre raison (pas nécessairement liée aux brevets), des restrictions vous sont imposées (que ce soit par ordre du tribunal, accord ou pour toute autre raison) qui contredisent les conditions de cette Licence, elles ne vous excusent pas des conditions de cette Licence. Si vous ne pouvez pas distribuer le Logiciel en conciliant vos obligations liées à cette Licence et toutes autres obligations pertinentes, alors, en conséquence, vous ne pourrez plus distribuer le Logiciel du tout. Par exemple, si une licence de brevet ne vous autorisait pas une redistribution libre de droits du Programme par tous ceux qui en reçoive une copie directement ou indirectement par vous, alors le seul moyen de satisfaire à cette obligation et aux obligations de la Licence serait de cesser la distribution du programme complètement.
    [...]
Le but de cette section n'est pas de vous amener à violer un brevet ou tout autre droit de propriété ou de contester la validité d'une telle revendication, le seul et unique objet de cette partie est de protéger l'intégrité des systèmes de distribution de logiciels libres qui sont mis en application par cette licence publique. De nombreuses personnes ont fait de généreuses donations à la grande variété de logiciels distribués par ce système avec confiance en l'application constante de ce système. Il revient à l'auteur/au donateur de décider s'il ou elle désire distribuer le logiciel par un autre système et une licence ne peut pas imposer ce choix.

La Licence Apache, dans sa version 2.0 (http://www.apache.org/licenses/LICENSE-2.0) contient également des pré-requis contre les brevets. En premier, elle stipule que toute personne distribuant le code sous cette licence doit y inclure implicitement une licence de brevet sans redevance pour tout brevet qu'elle pourrait détenir et qui pourrait s'appliquer au code. En deuxième, ce qui est plus ingénieux encore, elle punit quiconque initierai un procès pour violation de brevet sur le travail couvert en rompant automatiquement la licence de brevet implicite dès le moment où une telle revendication est faite :

3. Attribution d'une licence de brevet. Soumis aux termes et conditions de cette licence, chaque Participant, par la présente, Vous accorde un droit d'exploitation de brevet impérissable, universel, non-exclusif, sans frais, sans redevance, irrévocable (à l'exception des conditions décrites dans cette section) pour l'usage présent et passé, l'utilisation, la proposition à la vente, la vente, l'import et pour tout transfert de l'&Oelig;uvre. Cette licence ne vaut que pour les revendications de brevet que le participant peut licencier et qui sont nécessairement violées par leur(s) Contribution(s) seule(s) ou par une combinaison de leur(s) Contribution(s) et de l'&Oelig;uvre à laquelle une (des)telle(s) Contribution(s) a (ont) été soumise(s). Si vous établissez un contentieux contre une tierce partie (demande entre défenseurs ou demande reconventionnelle dans un procès comprises) alléguant que l'&Oelig;uvre ou qu'une Contribution incluse dans l'&Oelig;uvre constitue une violation directe ou contributive de toute licence de brevet Vous ayant été attribuée par les termes de cette Licence pour cette &Oelig;uvre deviendraient nulles à la date où ce contentieux est enregistré.

Bien qu'il soit important, à la fois légalement et politiquement, de construire une défense contre les brevets dans les licences logiciels libres de cette manière, au final ces mesures ne suffiront pas à repousser la menace que font peser les procès sur les logiciels libres. Seuls des modifications dans les textes ou dans leur interprétation des lois internationales sur les brevets pourront accomplir cela. Pour en savoir plus sur les brevets logiciels et comment ils sont combattus rendez-vous sur http://nosoftwarepatents.com/. L'article de Wikipedia (http://fr.wikipedia.org/wiki/Brevet_logiciel) contient également beaucoup d'informations utiles sur les brevets logiciels.

[22] Sun Microsystems et IBM ont aussi fait au moins un geste pour régler le problème du point de vu opposé en libérant un grand nombre de brevets logiciels, 1600 et 500 respectivement, pour que la communauté Open Source puisse en profiter. Je ne suis pas avocat et par conséquent je ne saurai évaluer la porté de ces dons, mais même si ce sont tous des brevets importants et que les termes de cette libération les rendent vraiment libres d'utilisation par n'importe quel projet Open Source, ça resterait toujours une goutte d'eau dans l'océan.

[23] Voir http://lpf.ai.mit.edu/Whatsnew/survey.html pour obtenir un exemple d'un de ces sondages.

  This chapter has only been an introduction to free software licensing issues. Although I hope it contains
    enough information to get you started on your own Open Source project, any serious investigation of li-
    censing issues will quickly exhaust what this book can provide. Here is a list of further resources on
    Open Source licensing:
    •  Understanding Open Source and Free Software Licensing by Andrew M. St. Laurent. Published by
       O'Reilly Media, first edition August 2004, ISBN: 0-596-00581-4.
       This is a full-length book on Open Source licensing in all its complexity, including many topics omit-
       ted from this chapter. See http://www.oreilly.com/catalog/osfreesoft/ for details.
    •  Make Your Open Source Software GPL-Compatible. Or Else. by David A. Wheeler, at ht-
       tp://www.dwheeler.com/essays/gpl-compatible.html.
       This is a detailed and well-written article on why it is important to use a GPL-compatible license
       even if you don't use the GPL itself. The article also touches on many other licensing questions, and
       has a high density of excellent links.
    •  http://creativecommons.org/
       Creative Commons is an organization that promotes a range of more flexible and liberal copyrights
       than traditional copyright practice encourages. They offer licenses not just for software, but for text,
       art, and music as well, all accessible via a user-friendly license selector; some of the licenses are co-
       pylefts, some are non-copyleft but still free, others are simply traditional copyrights but with some
       restrictions relaxed. The Creative Commons web site gives extremely clear explanations of what it's
       about. If I had to pick one site to demonstrate the broader philosophical implications of the free soft-
       ware movement, this would be it.

Ce chapitre ne vous dévoile qu'une partie de la problématique des licences pour les logiciels libres. Même si j'espère qu'il est assez complet pour vous permettre de commencer votre propre projet Open Source n'importe quelle recherche sérieuse sur cette thématique vous fournira sans problèmes plus d'informations que ne peut le faire ce livre. Voici une liste d'autres références sur les licences Open Source :

• Understanding Open Source and Free Software Licensing par Andrew St. Laurent. Publié par O'Reilly Media, première édition Août 2004, ISBN : 0-596-00581-4. C'est un livre complet qui traite des licences Open Source dans toute leur complexité, y compris pour les questions non-abordées dans ce chapitre.
• Make Your Open Source Software GPL-Compatible. Or Else. par David A. Wheeler, à l'adresse : http://www.dwheeler.com/essays/gpl-compatible.html. C'est un article détaillé et bien rédigé sur l'importance du choix d'une licence compatible avec la GPL même si vous n'utilisez pas la GPL en elle-même. L'article aborde également bien d'autres questions relatives aux licences et contient de nombreux liens intéressants.
• http://creativecommons.org/

Creative Commons est une organisation qui promeut toute une gamme de droits d'auteurs plus libres et plus flexibles que ce qu'encourage la pratique traditionnelle du droit d'auteur. Ils ne proposent pas uniquement des licences pour logiciels, mais pour le texte, l'art et la musique aussi, tous accessibles par un sélectionneur de licence facile d'emploi, certaines de ces licences sont des copylefts, d'autres ne le sont pas mais sont quand même gratuites, d'autres encore sont des droits d'auteur conventionnels mais dont certaines restrictions sont abandonnées. Le site Web Creative Commons propose des explications parfaitement claires de ce dont il s'agit. Si vous deviez choisir un site pour démontrer les implications philosophiques étendues du mouvement des logiciels libres c'est celui que je vous conseillerai.