De Framalang Wiki.

Chapitre 8 : Encadrer les volontaires

Page d'accueil du projet

Annexe A

---

Sommaire 1 Chapitre 9 : Licences, droits d'auteur et brevets 1.1 Terminologie 1.2 Les aspects des Licences 1.3 La GPL et la Compatibilité de Licence 1.4 Le choix d'une Licence 1.4.1 La Licence MIT/X Window System 1.4.2 La GNU General Public License 1.4.2.1 La GPL, libre ou pas ? 1.4.3 Et à propos de la Licence BSD ? 1.5 Attribution des droits d'auteur et propriété 1.5.1 Ne rien faire 1.5.2 Accord de Licence du Participant 1.5.3 Transfert du droit d'auteur 1.6 La double licence 1.7 Brevets 1.8 Plus de références 2 Notes

Chapitre 9 : Licences, droits d'auteur et brevets

La licence choisie n'aura certainement que peu d'importance dans l'adoption de votre projet s'il s'agit une licence Open Source. Les utilisateurs adoptent, en général, un logiciel pour ses qualités et ses fonctionnalités, pas pour des détails de licence. Néanmoins, vous devez avoir une connaissance minimale des questions relatives aux licences, à la fois pour vous assurer que celle choisie pour votre projet est en accord avec ses objectifs, mais aussi pour être capable de débattre de son choix. N'oubliez pas, par contre, que je ne suis pas avocat et qu'aucun conseil, dans ce chapitre, ne doit être vraiment considéré comme légal. En cas de besoin, vous devrez engager un avocat à moins de l'être vous même.

Terminologie

Dans toute discussion 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 libre

Logiciel livré avec son code source, qui peut être librement partagé et modifié. Le terme fut à l'origine inventé par Richard Stallman, qui l'a codifié pour donner la Licence Publique Générale (GNU - General Public License) et qui fonda 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. Elle privilégie aussi l'idée d'un mouvement social à celui d'un mouvement technique. La FSF reconnaît que le terme « free » est ambigu, il peut signifier « gratuit » ou « libre», mais réflexion faite, il semble que ce soit le meilleur terme, les autres possibilités en anglais ayant 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 « gratuit »). [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 Open Source

Autre nom pour désigner les logiciels libres, mais un nom différent qui reflète une philosophique distincte : l' « Open Source » a été inventé par l'Open Source Initiative (http://www.opensource.org/) comme une alternative délibérée au logiciel libre afin de rendre ce type de logiciel plus attractif aux entreprises en le présentant comme une méthodologie de développement plutôt qu'un mouvement politique. Il était également question de tordre le cou à une autre idée préconçue : toute chose « free » (gratuite) est de mauvaise qualité.

Bien que toute licence libre soit également Open Source, et vice versa (avec cependant quelques exceptions), la majorité des personnes tendent à utiliser un terme plutôt qu'un autre et à le privilégier. En général, ceux qui préfèrent « 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, tout du moins, 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.

FOSS, F/OSS, FLOSS

On dit « jamais deux sans trois » et c'est aussi vrai pour les termes relatifs au logiciel libre. Le monde universitaire, 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 désignent essentiellement la même chose : un logiciel pouvant ê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 DFSG

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, ainsi en l'installant personne ne peut douter de son droit de modifier et de redistribuer tout ou partie du système. Le contrat social Debian regroupe l'ensemble des exigences que la licence d'un programme doit remplir pour qu'il soit inclus dans Debian. Le projet Debian ayant passé beaucoup de temps à réfléchir à la conception d'un tel test, la charte conçue a prouvé sa robustesse (voir http://fr.wikipedia.org/wiki/DFSG) et, à ma connaissance, ni la Free Software Foundation, ni l'Open Source Initiative n'ont formulé d'objection sérieuse à son encontre. Si vous savez qu'une licence est conforme à la charte, alors vous savez qu'elle garantit 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é OSI

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 du logiciel libre est basée sur le contrat social Debian, toute licence qui remplit l'une des définitions satisfait presque toujours l'autre. Il y eut quelques petites exceptions au cours des années qui ne remettaient en cause que des licences marginales et aucune de celles vraiment importantes présentées ici. À la différence du Projet Debian, l'OSI maintient une liste des licences approuvées à l'adresse http://www.opensource.org/licenses/ ainsi, « approuvé OSI » est 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 des libertés qu'elles offrent, 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 loin dans ce chapitre.

Propriétaire, source fermée

L'opposé de « libre » ou « Open Source ». Il renvoit aux logiciels distribués sous des termes traditionnels, basés sur un schéma de redevance où l'utilisateur paie chaque copie, ou sur d'autres termes suffisamment restrictifs pour empêcher de satisfaire les dynamiques de l'Open Source. Même un logiciel distribué gratuitement reste propriétaire, si sa licence ne permet pas sa libre redistribution ou modification.

Généralement, « propriétaire » et « fermé » sont synonymes. Cependant, « fermé » implique, en outre, que le code source ne peut être vu. À 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 à tout un chacun 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 : ce sont les libertés associées qui comptent. Ainsi, la distinction entre « propriétaire » et « fermé » est rarement pertinente, et les deux termes peuvent être considérés comme synonymes.

Quelque fois, on emploiera « commercial » 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, si les acheteurs peuvent toujours en distribuer eux-mêmes des copies, rien n'empêche un logiciel libre d'être vendu. Son exploitation commerciale peut prendre plusieurs formes comme par exemple la vente de service, de support ou de certification. De nos jours, des entreprises très rentables se sont construites autour du logiciel libre. Il est donc clairement ni anti-commercial, ni anti-capitaliste. 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 où une copie équivaut à une licence.

Domaine public

Œuvre dont personne ne détient les droits. Concrètement, personne ne peut restreindre le droit de copier l'œuvre. « Domaine Public » n'est pas synonyme de « sans auteur ». Toute œuvre a un auteur. Que le ou les auteurs aient choisi de placer leurs travaux dans le Domaine Public, ne change rien au fait qu'ils en sont les créateurs.

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.

Copyleft

Une licence qui utilise le droit d'auteur légal pour atteindre le résultat opposé. Suivant votre interlocuteur, vous aurez deux définitions. Une plus laxiste qui comprend les libertés présentées dans ce chapitre, ou une plus rigoureuse qui ne permet pas seulement ces libertés mais les renforcera en les imposant aux travaux dérivés de l'œuvre. La Free Software Foundation utilise exclusivement la seconde définition. Une majorité de personnes adoptent la définition de 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 de l'importance de la distinction 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.

Les aspects des Licences

Malgré la diversité des licences de logiciels libres, elles partagent toutes une base commune : n'importe qui peut modifier le code, n'importe qui peut le redistribuer, tant sous sa forme originale que sous une forme modifiée. De plus, les détenteurs des droits d'auteur et les auteurs ne fournissent aucune garantie (l'exonération de responsabilité est particulièrement importante, étant donné que l'on pourraient utiliser des versions modifiées sans même le savoir).

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

Compatibilité avec les licences propriétaire

Quelques licences libres permettent aux programmes propriétaires d'incorporer du code couvert. Les termes de la licence du programme propriétaire n'en sont pas affectés pour autant. Il reste fermé, mais il intègre une certaine proportion de code d'origine non-propriétaire. La Licence Apache, la Licence Consortium X, la licence de type BSD et la licence de type MIT sont autant d'exemples de licences compatibles avec une licence propriétaire.

Compatibilité avec d'autres licences libres

La plupart des licences libres sont compatibles entre elles. Du code, soumis à l'une de ces licences, peut être combiné avec du code régit par une autre. Le résultat peut être distribué sous l'une ou l'autre des licences sans violer les termes de la seconde. La Licence Publique Générale (GPL) GNU fait notoirement exception. Elle exige que tout logiciel utilisant du code sous GPL soit, lui aussi, distribué sous licence GPL, et ce sans ajouter de restrictions autres que celles que la GPL requiert. La GPL est compatible avec quelques licences libres, mais pas avec toutes. Nous aborderons ce point plus en détail dans la section « La GPL et la compatibilité de licences » plus loin 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 avec du code propriétaire : elles n'imposent pas nécessairement la liberté du travail dérivé, mais simplement la reconnaissance de la paternité du 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 des détenteurs du droit d'auteur, ou de leur institution, etc.) ne peut être utilisé dans des travaux dérivés sans une permission écrite préalable. Opposées dans leur application, l'obligation de crédit impose de citer l'auteur tandis que la protection de marque déposée a l'effet inverse, elles expriment toutes deux le même désir : la réputation de l'auteur du code original doit être préservée et transmise, mais sans être ternie par association (d'idées).

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

Quelques licences (la Licence Artistique, celle qui couvre la plus populaire implémentation du langage de programmation Perl, et la licence de Donald Knuth TeX, par exemple) exigent que le code modifié soit clairement identifié comme tel. Elles permettent essentiellement les mêmes libertés que les autres licences libres, mais imposent certaines contraintes rendant l'intégrité du code original facile à vérifier. La popularité de ces licences ne s'étant pas étendues au-delà des programmes spécifiques pour lesquels elles furent écrites, elles ne seront pas traitées dans ce chapitre ; elles sont mentionnées ici dans un seul soucis d'exhaustivité.

Ces conditions, pour la plupart, ne s'excluent pas entre elles, et quelques licences en intègrent plusieurs. Elles ont ceci en commun que, si elles attribuent aux usagers le droit d'utiliser et/ou de redistribuer le code, en contrepartie elles imposent certaines contraintes. Par exemple, quelques projets veulent que leur nom et leur réputation se répandent avec le code, ce qui justifie la contrainte supplémentaire d'une clause de marque déposée ou de crédit. Si celle-ci est trop pesante, ce fardeau peut potentiellement détourner les utilisateurs vers un paquet utilisant une licence moins exigeante.

La GPL et la Compatibilité de Licence

Les licences peuvent être regroupées en deux grandes catégories selon qu'elles sont, ou pas, compatibles avec les licences propriétaires. On distingue donc la GNU General Public License de toutes les autres licences. Parce que l'objectif premier 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. Tout logiciel dérivé, tout logiciel contenant une quantité signifiante 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 intégrant ce code. L'emploi de code sous GPL dans un programme fermé est donc strictement impossible. Cependant, ces mêmes clauses rendent aussi la GPL incompatible avec certaines autres licences libres. C'est typiquement le cas des licences imposant une exigence supplémentaire comme, par exemple, une clause de crédit. L'incompatibilité avec la GPL est flagrante puisque cette dernière stipule que « Vous ne pouvez pas imposer de nouvelles restrictions... ». Du point de vue de la Free Software Foundation, ces effets secondaires sont recherchés, ou en tout cas, ils ne sont pas regrettables. Non seulement la GPL assure la liberté de votre logiciel, mais elle en fait aussi un agent poussant les autres logiciels à devenir libres.

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. Retenez surtout que la compatibilité de votre licence avec la GPL est un aspect à ne pas négliger. La GPL est de loin la licence Open Source la plus populaire. Elle est choisie par 68% des projets répertoriés sur Freshmeat (http://freshmeat.net/stats/#license). La deuxième licence la plus populaire ne concerne que 6% des projets. 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 compatible avec la GPL. La plupart des licences Open Source compatibles avec la GPL le sont aussi avec les licences propriétaires : ainsi, un code sous une telle licence peut être incorporé à 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 seront incompatibles 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 directement.

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 abordées dans ce chapitre sont présentes dans cette liste, dans une catégorie ou l'autre.

Le choix d'une Licence

Quand vous décidez de la licence à appliquer à votre projet, essayez de ne pas réinventer la roue si possible. Ces deux arguments devraient vous convaincre d'opter pour une licence déjà existante :

• La familiarité. Si vous optez pour l'une des trois ou quatre licences les plus populaires, les utilisateurs ne se sentiront pas contraints de lire les dispositions légales avant d'utiliser le code, ils les connaissent déjà.
• La qualité. À 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 mûres 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.

La Licence MIT/X Window System

Si vous cherchez une licence qui permettra l'adoption de votre code par le plus grand nombre de développeurs et de travaux dérivés possible, et que sa possible intégration à du code propriétaire ne vous dérange pas, choisissez la licence 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.)

La GNU General Public License

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 la finalité est d'être utilisée par d'autres programmes, veillez attentivement à ce que les restrictions imposées par la 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, plutôt que la GNU GPL, je vous recommande d'opter simplement pour la licence MIT/X-style dans ce cas.

La GPL, libre ou pas ?

En choisissant d'appliquer la licence GNU GPL à votre code, vous vous exposez, ainsi que votre projet, à de possibles débats sur le respect 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, elle n'est pas complètement libre, si ? 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 amè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 votre choix a été guidé par la reconnaissance d'une licence, 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 de vous laisser embarquer dans un débat sur le caractère « plus » ou « moins » libre de la GNU GPL. La liberté est un vaste sujet, débattre de la terminologie ne vous mènera à rien.

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. Dire que cela restreint la liberté, pour moi, revient à 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.)

Et à propos de la Licence BSD ?

De nombreux logiciels Open Source optent pour la licence BSD (ou une variante). La Licence BSD originale fut créée pour la Berkeley Software Distribution. Par sa libération, 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 University of California, Lawrence Berkeley Laboratory.

ou en français :

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 Californie, 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, adaptant la mention « the University of California, Lawrence Berkeley Laboratory » à leur propre nom, les revendeurs de logiciels devaient afficher de plus en plus de messages. Heureusement, de nombreux projets soumis à cette licence, constatant le problème, abandonnèrent tout simplement cette clause. En 1999, même l'Université de Californie en fit de même.

La Licence BSD révisée n'est donc que la licence BSD originale épurée de 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 substance équivalente, et qui ne souffre pas de cette ambiguïté. Mais il peut y avoir une raison de préférer la Licence BSD dans sa forme révisée à 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.

ou en français :

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 : elle enlève tout doute possible. Pour les organisations attachant une importance particulière au contrôle des droits d'auteur, la Licence BSD révisée serait donc légèrement mieux 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, vous en trouverez un modèle à cette adresse : http://www.opensource.org/licenses/bsd-license.php.

Attribution des droits d'auteur et propriété

La gestion des droits d'auteur sur un code libre, fruit du travail de plusieurs personnes, est une question qu'il vous faudra résoudre, trois options s'offrent à vous. 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, le point positif étant que dans certaines juridictions ces ALP peuvent être envoyés par courrier électronique. La troisième possibilité est d'obtenir des participants l'attribution complète des droits d'auteur afin que le projet (c'est-à-dire une personne morale, généralement à but non lucratif) concentre tous les droits d'auteur. C'est la voie la plus sûre légalement, mais aussi la plus contraignante pour les participants, seuls quelques projets l'empruntent [31].

Notez que même si la propriété intellectuelle est centralisée, le code [32] 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 que personne morale, 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 de rien n'était. Cette possibilité existant, la plupart des participants coopèrent lorsqu'on leur demande de signer un ALP ou une attribution de droit d'auteur.

Ne rien faire

La plupart des projets ne demandent jamais aux participants de signer d'ALP ou d'attribution de droits d'auteur. Ils se contentent d'accepter les contributions. En demandant leur incorporation, les participants donnent implicitement leur accord.

En temps normal, c'est suffisant. Mais il est déjà arrivé qu'un participant décide d'intenter un procès pour violation de droit d'auteur, affirmant qu'il est le vrai propriétaire du code en question et qu'il n'avait jamais donné son accord pour qu'il soit distribué par le projet sous une licence Open Source. C'est, par exemple, l'origine du litige entre SCO et le projet Linux, voir http://fr.wikipedia.org/wiki/SCO_contre_Linux pour les détails. Ne détenant aucun document officiel attestant de la cession de leurs droits par les participants, le projet peut difficilement se défendre.

Accord de Licence du Participant

Les ALP [NdT: ou CLA en anglais, pour Contributor License Agreement] 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 pas toujours, 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. ». Par mesure de sécurité vous devriez faire valider votre ALP par un avocat, mais en réunissant tous ces adjectifs, il ne devrait rien trouver à redire.

Lorsque vous demandez aux participants de signer un ALP, 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 :

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.

ou en français :

Ceci n'est qu'un accord de licence, vous conservez vos droits d'auteur et 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

Transfert du droit d'auteur

En transférant ses droits d'auteur, le participant accorde au projet la propriété de ses contributions. Il signe simplement un papier qu'il transmet, par fax ou voie postale, au projet.

Certains projets imposent une attribution complète des contributions. Si les termes de la licence Open Source doivent être défendus devant un tribunal, une personne morale, possédant les droits sur tout le code, sera en meilleure position pour défendre ses arguments. Sinon tous les participants pourraient être amenés à coopérer, mais certains risquent de ne pas avoir le temps, ou de 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. ». Selon au moins un avocat avec qui je me suis entretenu, cette déclaration est suffisante, certainement parce qu'elle est faite dans un cadre où l'attribution du droit d'auteur est normale et attendue de toute façon. De plus, c'est aussi un moyen pour le projet de s'assurer de la bonne foi du participant, de ses intentions profondes. La Free Software Foundation, de son côté, demande aux participants de signer personnellement, et d'envoyer par voie postale un document contenant une déclaration formelle d'attribution des droits 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 quelqu'un 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, elle veut que ses droits d'auteur soient inattaquables. Puisque la FSF est détentrice des droits d'auteur de nombreux logiciels populaires, elle doit 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 de tout le monde.

La double licence

Certains projets tentent de s'auto-financer en adoptant une double licence, c'est un système par lequel toute société peut payer le détenteur des droits d'auteur afin d'obtenir son accord pour utiliser le code dans un programme propriétaire, le code restant libre pour les projets Open Source. Les librairies de code se prêtent évidemment mieux à cette double licence que des applications autonomes. Les termes exacts 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, 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, on peut aussi 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-il proposer une licence propriétaire contre rémunération si les termes de la GNU GPL stipulent que le code doit être mis à disposition sous des conditions moins restrictives. 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 s'imposer les mêmes termes. Imaginez que le détenteur des droits possède un nombre infini de copies du logiciel rangées dans un seau, à chaque fois qu'il sort une copie du seau pour la donner au monde, il peut décider quelle licence appliquer : GPL, propriétaire ou autre. Ce n'est pas la GPL ou une quelconque autre licence Open Source qui lui donne ce droit, ce sont les lois du droit d'auteur.

La double licence permet ainsi, dans le meilleur des cas, au projet de logiciel libre de s'assurer une source de revenus stable. Malheureusement, la dynamique normale d'un projet Open Source peut s'en retrouver altérée. 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. Contribuer à la version libre ne lui posera certainement pas problème, c'est la norme dans les projets Open Source, mais par contre, participer à la création de revenus semi-propriétaires au bénéfice de tiers lui conviendra peut-être moins. C'est d'autant plus vrai que, pour une double licence, les participants doivent céder leurs droits au projet par une déclaration écrite. Le projet doit se couvrir au cas où un participant mécontent prétendrait à un pourcentage sur les revenus propriétaires. À partir du moment où les participants signent cette attribution des droits, ils ne peuvent plus ignorer que leur production enrichira une autre personne.

Tous les volontaires ne se soucieront pas de cela, 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 du projet n'ont pas, ce qui conduira tôt ou tard à des tensions, du moins avec quelques volontaires.

En pratique, il semble que les entreprises développant des logiciels à double licence n'ont pas une communauté de développement vraiment égalitaire. Ils profitent de correctifs de bogues mineurs ou de petits travaux de bénévoles, mais font le gros du travail en interne. Par exemple, Zack Urlocker, vice président du marketing chez MySQL, m'a confié 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 licence GPL. Son développement est plus ou moins contrôlé par une entreprise, même si la possibilité d'initier une fourche en cas de profond désaccord existe (elle reste extrêmement faible cependant). Je ne sais pas comment cette menace affecte 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.

Brevets

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 droits d'auteur et de marque. Si une partie de votre code semble enfreindre le droit d'auteur de quelqu'un, il ne reste qu'à l'écrire de nouveau. 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 l'appellation. Même si cela est un désagrément temporaire, à long terme, c'est sans importance puisque le code en lui-même reste identique. Par contre, 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 qu'un projet de logiciel libre est accusé 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, leur puissance financière leur permettant d'acheter les brevets, les projets de logiciel libre n'ont pas le luxe de cette dernière option et doivent immédiatement capituler, peu importe la validité du brevet face à un tribunal. Pour éviter tout simplement de se retrouver dans cette situation, les projets de logiciels libres se mettent à coder défensivement en fuyant les algorithmes brevetés, même s'ils représentent la meilleure, voire la seule, solution possible à un problème de programmation. [33]

Des sondages et l'expérience 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. [34] 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. [35]

Malheureusement, la collecte de brevets à des fins défensives est une action rationnelle. Le système de brevets actuel, aux États-Unis en tout cas, 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 énormement à votre tour, ainsi, si l'on vous attaque pour violation de brevet, vous pouvez répondre par la même menace, en conséquence, les deux parties concernées 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. Les brevets logiciels encouragent au secret chez les développeurs de firmware qui craignent, à juste titre, qu'une publication des détails de leur interface ne fournisse une aide technique aux adversaires ne cherchant qu'à les attaquer pour violation de brevet logiciel. Tout ceci est loin de n'être que théorique, le secteur des cartes graphiques en est un bon exemple. Beaucoup de fabricants de cartes graphiques sont réticents à l'idée de publier les spécifications détaillées de leurs programmes. Elles sont pourtant nécessaires à l'écriture de pilotes Open Source de très bonne qualité pour leur matériel. Le support de ces cartes par les systèmes d'exploitation libres est donc largement incomplet. Pourquoi les fabricants font-ils cela ? Pourquoi empêcheraient-ils le support de leurs produits ? Après tout, si leurs cartes sont compatibles avec plus de systèmes d'exploitation, cela ne peut que se traduire par de meilleures ventes. C'est surtout un problème de discrétion. Dans le secret des salles de fabrication, ces vendeurs ne cessent de violer la propriété intellectuelle de leurs concurrents, parfois sciemment, parfois par accident. Les brevets sont si imprévisibles, et couvrent parfois des domaines si vastes, qu'aucun fabriquant de carte ne peut jamais être sûr de ne violer aucun brevet logiciel, même après une recherche d'antériorité. Par conséquent, les producteurs n'osent pas publier les spécifications complètes de leurs interfaces de peur de fournir à leurs adversaires le bâton pour se faire battre. (Évidemment, le sujet étant sensible, vous ne trouverez aucun témoignage écrit d'une source sûre le confirmant, 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) et que ces restrictions ne sont pas compatibles avec les conditions de cette Licence, elles ne vous dégagent pas des obligations de cette Licence. Si vous ne pouvez pas distribuer le Logiciel en conciliant le respect de cette Licence et toutes autres obligations pertinentes, alors vous ne pourrez plus distribuer le Logiciel. 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 de vous, alors le seul moyen de satisfaire à cette obligation et aux obligations de la Licence serait de cesser la distribution du programme complètement.

[...]

Cette section n'est en rien une incitation à la violation de brevets ou de tout autre droit de propriété intellectuelle, pas plus qu'il ne vous encourage à contester la validité des droits qui vous sont opposés. Le seul et unique objet de cette partie est de protéger l'intégrité des systèmes de distribution de logiciels libres qui reposent sur les licences publiques. Ces licences sont un gage de confiance, de pérennité. Grâce à elles, de nombreuses personnes croyant en ce système de distribution ont pu faire de généreuses donations à d'innombrables projets. Il revient à l'auteur/au donateur de décider s'il 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 initierait 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'Œ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'Œ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'Œuvre ou qu'une Contribution incluse dans l'Œ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 Œuvre deviendraient nulles à la date où ce contentieux est enregistré.

Aussi importante soit-elle, aussi bien légalement que politiquement, la défense érigée au sein des licences de logiciels libres contre les brevets ne suffira pas à repousser la menace que font peser les actions légales sur les logiciels libres. Seule une modification des lois internationales de la propriété intellectuelle, dans les textes ou dans leur interprétation, pourrait assurer la sécurité des logiciels libres. Pour en savoir plus sur les brevets logiciels et les combats menés, rendez-vous sur http://nosoftwarepatents.com/. L'article de Wikipédia (http://fr.wikipedia.org/wiki/Brevet_logiciel) contient également beaucoup d'informations utiles sur les brevets logiciels.

Plus de références

Ce chapitre ne vous dévoile qu'une partie du problème des licences pour logiciels libres. Même si je l'espère assez complet pour vous permettre de commencer votre propre projet Open Source, une recherche sérieuse sur ce thème vous fournira sans problème 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 éludé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. 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. Elle ne propose pas uniquement des licences pour logiciels, mais aussi pour l'écrit, l'art et la musique, tous accessibles par un sélectionneur de licence facile d'emploi. Certaines de ces licences sont des copylefts, d'autres non, malgré leur gratuité, d'autres encore traitent du droit d'auteur conventionnel auquel certaines restrictions ont été otées. Le site Web Creative Commons propose des explications parfaitement claires sur chacune des licences. 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.

Notes

[30] L'histoire de la licence et de son nom est un peu compliquée. La première version de la licence a été publiée à l'origine par Affero, Inc, qui l'avait écrite en prenant la GNU GPL version 2 comme base. On parlait alors de l'AGPL. Ensuite la Free Software Foundation a décidé d'adopter l'idée mais, entre temps, la version 3 de leur GNU GPL était publiée, ils ont donc basé leur licence « Affero » dessus et l'ont baptisée licence « GNU AGPL ». L'ancienne licence Affero est maintenant un peu raillée. Si vous voulez des clauses proches de l'Affero, vous devriez utiliser la version GNU. Pour éviter toute ambigüité appelez la « AGPLv3 », « GNU AGPL » ou pour un maximum de clarté « GNU AGPLv3 ».

[31] Le transfert de droit d'auteur est sujet aux lois nationales, les licences créées pour les États-Unis pourraient ne pas être adaptées partout (par exemple, en Allemagne, il n'est apparemment pas possible de transférer son droit d'auteur).

[32] Je parlerai de « code » à partir de maintenant pour parler indifféremment du code et de la documentation.

[33] Sun Microsystems et IBM se sont montrés de bons alliés dans cette bataille en libérant un grand nombre de brevets logiciels, 1600 et 500 respectivement, pour que la communauté Open Source puisse en profiter. N'étant pas avocat, je ne saurais évaluer la portée de ces dons. Mais, quand bien même ces brevets seraient importants et que les termes de cette libération les rendraient vraiment libres d'utilisation par n'importe quel projet Open Source, il n'en reste pas moins que cela ne serait qu'une goutte d'eau dans l'océan.

[34] À la page http://lpf.ai.mit.edu/Whatsnew/survey.html vous trouverez l'exemple d'un de ces sondages.

[35] Par exemple, RedHat a juré de ne jamais utiliser ses brevets contre un projet Open Source, voir http://www.redhat.com/legal/patent_policy.html.

---

Chapitre 8 : Encadrer les volontaires

Page d'accueil du projet

Annexe A