Annexes de la conférence sur « Le FreeSoftware dans l'entreprise » Table des matières Définition du « Free Software » selon la « Free Software Foundation »................................................................2 Logiciel Libre.............................................................................................................................................................4 Qu'est-ce que le copyleft ?........................................................................................................................................8 GNU GENERAL PUBLIC LICENSE (TRADUCTION NON OFFICIELLE)................................................................10 Le Projet GNU..........................................................................................................................................................15 Comparatif: La sécurité traitée par le logiciel propriétaire et par le libre...........................................................29 Sun Community Source License Principles............................................................................................................31 Linux makes a run for government .......................................................................................................................38 U.K. government backs open source .....................................................................................................................40 Free speech, free beer and free software...............................................................................................................41 Can Linux duck the Redmond death ray?.............................................................................................................43 The Growing Politicization of Open Source..........................................................................................................45 Lettre de l'état péruvien au directeur général de Microsoft Pérou.......................................................................47 Migration d'une entreprise vers un système libre: exemple concret....................................................................54 IT managers cite security and competition when choosing a Linux system .......................................................55 Définition du « Free Software » selon la « Free Software Foundation » (http://www.fsf.org) Nous maintenons cette définition du logiciel libre pour décrire clairement les conditions à remplir pour qu'un logiciel soit considéré comme libre. L'expression «Logiciel libre» fait référence à la liberté et non pas au prix. Pour comprendre le concept, vous devez penser à la «liberté d'expression», pas à «l'entrée libre». L'expression «Logiciel libre» fait référence à la liberté pour les utilisateurs d'exécuter, de copier, de distribuer, d'étudier, de modifier et d'améliorer le logiciel. Plus précisément, elle fait référence à quatre types de liberté pour l'utilisateur du logiciel: 0) La liberté d'exécuter le programme, pour tous les usages (liberté 0). 1) La liberté d'étudier le fonctionnement du programme, et de l'adapter à vos besoins (liberté 1). Pour ceci l'accès au code source est une condition requise. 2) La liberté de redistribuer des copies, donc d'aider votre voisin, (liberté 2). 3) La liberté d'améliorer le programme et de publier vos améliorations, pour en faire profiter toute la communauté (liberté 3). Pour ceci l'accès au code source est une condition requise. Un programme est un logiciel libre si les utilisateurs ont toutes ces libertés. Ainsi, vous êtes libre de redistribuer des copies, avec ou sans modification, gratuitement ou non, à tout le monde, partout. Être libre de faire ceci signifie (entre autre) que vous n'avez pas à demander ou à payer pour en avoir la permission. Vous devez aussi avoir la liberté de faire des modifications et de les utiliser à titre personnel dans votre travail ou vos loisirs, sans en mentionner l'existence. Si vous publiez vos modifications, vous n'êtes pas obligé de prévenir quelqu'un de particulier ou de le faire d'une manière particulière. La liberté d'utiliser un programme est la liberté pour tout type de personne ou d'organisation de l'utiliser pour tout type de système informatique, pour tout type de tâche et sans être obligé de communiquer ultérieurement avec le développeur ou tout autre entité spécifique. La liberté comme le exception liberté de de redistribuer des copies doit inclure les formes binaires ou exécutables du programme (tout code source) à la fois pour les versions modifiées ou non modifiées du programme. Il y a une s'il n'y a pas moyen de produire une version binaire ou exécutable, mais le public doit avoir la distribuer de telles formes s'ils ont un moyen d'en produire. Pour avoir la liberté d'effectuer des modifications et de publier des versions améliorées, vous devez avoir l'accès au code source du programme. Par conséquent, l'accessibilité du code source est une condition requise pour un logiciel libre. Pour que ces libertés soient réelles, elles doivent être irrévocables tant que vous n'avez rien fait de mal ; si le développeur du logiciel a le droit de révoquer la licence sans que vous n'ayez fait quoi que ce soit pour le justifier, le logiciel n'est pas libre. Cependant, certains types de règles sur la manière de distribuer le logiciel libre sont acceptables tant que ces règles ne rentrent pas en conflit avec les libertés fondamentales. Par exemple, le copyleft (pour résumer très simplement) est une règle qui établit que lorsque vous redistribuez les programme, vous ne pouvez ajouter de restrictions pour retirer les libertés fondamentales au public. Cette règle ne rentre pas en conflit avec les libertés fondamentales ; en fait, elle les protège. Ainsi, vous pouvez avoir à payer pour obtenir une copie d'un logiciel du projet GNU ou vous pouvez l'obtenir gratuitement. Mais indifféremment de la manière dont vous vous l'êtes procuré, vous avez toujours la liberté de copier et de modifier un logiciel et même d'en vendre des copies. «Logiciel libre» ne signifie pas «non commercial». Un logiciel libre doit être disponible pour un usage commercial. Le développement commercial de logiciel libre n'est plus l'exception ; de tels programmes sont des logiciels commerciaux libres. Les règles sur la manière d'empaqueter une version modifiée sont acceptables si elles n'entravent pas votre liberté de la publier. Les règles disant «si vous publier le programme par ce moyen, vous devez le faire par ce moyen aussi» sont acceptables aux mêmes conditions (notez que de telles règles doivent vous laisser le choix de publier ou non le programme). Dans le projet GNU, nous utilisons le «copyleft» pour protéger ces libertés. Mais des logiciels libres noncopyleftés existent aussi. Nous croyons qu'il y a de bonnes raisons qui font qu'il est mieux d'utiliser le copyleft, mais si votre programme est libre non-copylefté, nous pouvons tout de même l'utiliser. [...] Parfois le contrôle gouvernemental des exportations ou des sanctions économiques peuvent vous priver de la liberté de distribuer des copies de programmes à l'étranger. Les développeurs de logiciels n'ont pas le pouvoir d'éliminer ou de passer outre ces restrictions, mais ce qu'ils peuvent et doivent faire, est de refuser d'imposer eux-mêmes des conditions à l'utilisation des programmes. De cette manière, les restrictions n'affecteront pas les activités et les personnes se trouvant hors de la juridiction de leurs gouvernements. Quand vous parlez des logiciels libres, il est préférable de ne pas utiliser de termes comme «donner» ou «gratuit», car ils laissent supposer que la finalité des logiciels libres est le prix et non la liberté. Certains termes répandus comme «piratage» comportent des idées auxquelles nous espérons que vous n'adhérerez pas. Lisez Termes prêtant à confusion, que vous devriez éviter pour un essai sur l'utilisation de ces termes. Nous avons aussi une liste de traductions de «free software» dans de nombreuses langues. Enfin, notez que les critères tels que ceux développés dans cette définition du logiciel libre demandent une réflexion sérieuse quant à leur interprétation. Pour décider si une licence de logiciel particulière est est définie comme libre, nous la jugeons sur ces critères pour déterminer si elle convient à leur esprit tout comme à leur formulation précise. Si une licence inclut des restrictions innaceptables, nous la rejetons même si nous n'avons pas anticipé le problème dans ces critères. Si vous voulez savoir si une licence spécifique est définie comme «libre», reportez-vous à notre liste de licences. Si la licence qui vous intéresse n'y est pas listée, vous pouvez nous demander des précisions en nous envoyant un mail à . Autres textes à lire Un autre groupe à commencé à utiliser le terme «open source» pour exprimer quelque chose de proche (mais pas d'identique) au «logiciel libre». [...] Les demandes de renseignements et les questions sur la FSF & le projet GNU sont a adresser à gnu@gnu.org. Autres moyens de contacter la FSF. Les commentaires sur ces pages web sont a envoyer à webmasters@www.gnu.org, envoyez toute autre question à gnu@gnu.org. Copyright (C) 1996, 1997, 1998, 1999, 2000 Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. la copie mots pour mots de l'integralité de cet article est permise sur tous supports, à condition que cette note soit preservée. Logiciel Libre Un logiciel libre est un logiciel qui est fourni avec l'autorisation pour quiconque de l'utiliser, de le copier, et de le distribuer, soit sous une forme conforme à l'original, soit avec des modifications, ou encore gratuitement ou contre un certain montant. Ceci signifie en particulier que son code source doit être disponible. «S'il n'y a pas de sources, ce n'est pas du logiciel.» Ceci est une définition simplifiée; voir aussi la définition complète. [...] Du moment qu'il est libre, tout programme peut, potentiellement, faire partie d'un système d'exploitation libre tel que GNU, ou les versions libres du système GNU/Linux. Il existe de nombreuses façons de rendre un logiciel libre---beaucoup de détails peuvent être définis de différentes façons, tout en gardant au logiciel son caractère libre. Certaines de ces variations sont décrites ciaprès. Un logiciel est libre du point de vue de la liberté, et non du prix. Mais les sociétés éditrices de logiciels propriétaires utilisent parfois le terme «logiciel libre» pour parler de logiciels gratuits. Ce qui veut parfois dire que vous pouvez en obtenir une copie binaire gratuitement, ou qu'une copie de ce logiciel est comprise dans le prix d'achat de votre ordinateur. Ceci n'a rien à voir avec le terme de logiciel libre, tel que nous le définissons dans le projet GNU. A cause de cette confusion potentielle il serait souhaitable, chaque fois qu'une société informatique annonce que son produit est un logiciel libre, de vérifier les conditions de distribution, afin de s'assurer que les usagers disposent de toutes les libertés associées au logiciel libre. Parfois il s'agit, effectivement, d'un logiciel libre, parfois non. L'anglais utilise le même mot «free» pour «libre» et «gratuit». C'est pourquoi il y a souvent confusion sur la nature des termes "free software". Nous tenons à souligner qu'il ne s'agit pas du prix mais de la liberté d'utilisation. Le logiciel libre est souvent plus fiable que le logiciel non-libre. Logiciel Open Source Le terme logiciel «open source» (littéralement à source ouvert) est utilisé par certaines personnes pour signifier plus ou moins la même chose que logiciel libre. Nous préférons le terme «logiciel libre»; [...] Logiciel du domaine public Logiciel du domaine public veut dire logiciel non soumis aux droits d'auteurs. C'est un cas particulier de logiciel libre "non-copylefté", ce qui veut dire que certaines copies, ou certains versions modifiées, peuvent ne pas être du tout libres. Parfois, on utilise le terme «domaine public» d'une façon peu précise pour dire «libre» ou «disponible gratuitement». Toutefois, «domaine public» est un terme légal qui signifie précisément que le logiciel n'est pas «soumis au copyright». Afin d'être plus précis, nous conseillons d'utiliser le terme «domaine public» dans ce cas uniquement, et d'utiliser d'autres termes dans les autres cas. Logiciel copylefté (sous gauche d'auteur) Le logiciel sous copyleft (littéralement, gauche d'auteur) est un logiciel libre, dont les conditions de distribution interdisent aux nouveaux distributeurs d'ajouter des restrictions supplémentaires lorsqu'ils redistribuent ou modifient le logiciel. Ceci veut dire que chaque copie du logiciel, même si elle a été modifiée, doit être un logiciel libre. Dans le projet GNU, presque tous les logiciels que nous créons sont soumis au copyleft, car notre but est de donner à chaque utilisateur les libertés garanties par le terme «logiciel libre». Voir Qu'est-ce que le copyleft pour plus d'explications sur le fonctionnement du copyleft et savoir pourquoi nous l'utilisons. Le copyleft est un concept général; pour l'appliquer à un programme, vous avez besoin d'un ensemble de termes relatifs à sa distribution. Il y a de nombreuses façons d'écrire ces conditions de distribution. Logiciel libre non-copylefté Le logiciel libre non-copylefté est diffusé par son auteur avec la permission de le redistribuer et de le modifier, mais aussi d'y ajouter d'autres restrictions. Si un programme est libre, mais non-copylefté, alors certaines copies ou versions modifiées peuvent ne plus être libres du tout. Une société informatique peut compiler ce programme, avec ou sans modifications, et distribuer le fichier exécutable sous forme de produit logiciel propriétaire. Le Système X Window illustre bien ce cas. Le Consortium X distribue X11 avec des conditions de distribution qui en font un logiciel libre non-copylefté. Si vous le souhaitez, vous pouvez en obtenir une copie qui possède de tels termes de distribution et qui est libre. Toutefois, il existe aussi des versions non-libres, et il y a des stations de travail ainsi que des cartes graphiques pour PC pour lesquelles les versions non-libres sont les seules qui fonctionnent. Si vous utilisez ce matériel-là, pour vous, X11 n'est pas un logiciel libre. Logiciel couvert par la GPL La GNU GPL (Licence Publique Générale GNU) (20 K octets) est un ensemble spécifique de conditions de distribution pour copylefter un programme. Le projet GNU l'utilise comme conditions de distribution de la plupart des logiciels GNU. Le système GNU Le système GNU est un système d'exploitation libre complet façon Unix. Un système d'exploitation comparable à UNIX contient de nombreux programmes. Le système GNU comprend tous les logiciels GNU, ainsi que bien d'autres paquetages tels que le X Window System et TeX, qui ne sont pas des logiciels GNU. Nous développons et accumulons des composants pour ce système depuis 1984; la première mise à disposition en test d'un «système GNU complet» remonte à 1996. Aujourd'hui, en 2001, le système fonctionne correctement, et des gens travaillent pour faire fonctionner GNOME et PPP avec ce système. Dans le même temps, le système GNU/Linux, une ramification du système GNU utilisant Linux comme kernel, a obtenu un grand succès. Puisque doivent permet comme le but du GNU est d'être libre, chacun de ses moindres composants doit être un logiciel libre. Tous ne cependant pas être copyleftés; n'importe quel type de logiciel libre pourra y figurer légalement, s'il d'atteindre les objectifs techniques. Nous pouvons et nous utilisons des logiciels libres non-copylefté le X Window System. Programmes GNU Les «programmes GNU» sont équivalents aux Logiciels GNU. Un programme Toto est un programme GNU s'il est un logiciel GNU. Logiciel GNU Un logiciel GNU est un logiciel diffusé sous les auspices du projet GNU. La plupart des logiciels GNU sont soumis à un copyleft, mais pas tous; cependant, tous les logiciels GNU doivent être des logiciels libres. Si un programme est un logiciel GNU, nous disons aussi qu'il est un programme GNU. Certains des logiciels GNU sont réalisés par le personnel de la Free Software Foundation, mais la plus grande partie des logiciels GNU est apportée par des volontaires. Certaines contributions sont sous copyright de la Free Software Foundation; d'autres appartiennent aux auteurs du logiciel. Logiciel semi-libre Le logiciel semi-libre est un logiciel qui n'est pas libre, mais qui s'accompagne de la permission pour les personnes physiques de l'utiliser, de le copier, de le distribuer, et de le modifier (y compris pour la distribution des versions modifiées) dans un but non lucratif. PGP est un exemple de programme semi-libre. Un logiciel semi-libre est toujours mieux qu'un logiciel propriétaire, mais cela pose toujours des problèmes, et nous ne pouvons l'utiliser dans un système d'exploitation libre. Les restrictions du copyleft sont conçues pour Pour nous, la seule justification à la définition est d'empêcher l'ajout d'autres restrictions par restrictions supplémentaires, motivées par des protéger les libertés fondamentales pour tous les utilisateurs. d'une restriction substantielle sur l'utilisation d'un programme d'autres personnes. Les programmes semi-libres possèdent des buts purement égoïstes. Il est impossible d'inclure du logiciel semi-libre dans un système d'exploitation libre. Ceci est dû au fait que les conditions de distribution du système d'exploitation dans son entier sont la somme des conditions de distribution de tous les programmes qui le composent. Y ajouter un seul logiciel semi-libre rendrait le système tout entier seulement semi-libre. Il y deux raisons pour lesquelles nous ne voulons pas que cela se produise: Nous pensons que le logiciel libre doit l'être pour tout le monde -- y compris les entreprises, et pas seulement les écoles et les amateurs. Nous voulons inviter l'entreprise à utiliser le système GNU en entier et, par conséquent nous ne devons pas y inclure de logiciel semi-libre. La distribution commerciale de systèmes d'exploitation libres, incluant le système GNU/Linux, est très importante, et les utilisateurs apprécient la possibilité d'acheter des distributions commerciales sur CD-ROM. L'inclusion d'un seul programme semi-libre dans un système d'exploitation supprimerait la distribution commerciale de CD-ROM pour ce système. La Free Software Foundation étant elle-même non-commerciale, elle aurait donc le droit d'utiliser légalement un programme semi-libre «en interne». Mais nous ne le faisons pas, parce que cela minerait nos efforts pour obtenir un programme que nous pourrions alors inclure dans GNU. Si un travail nécessite l'utilisation d'un logiciel, alors tant qu'il n'existe pas de programme libre permettant de le réaliser, le système GNU contient une lacune. Nous devons dire aux volontaires, «Nous n'avons pas encore de programme pour faire ce travail dans GNU, et nous espérons donc que vous en écrirez un». Si nous mêmes nous utilisions un programme semi-libre pour faire le travail en question, cela minerait notre discours; et annulerait la nécessité (pour nous, et pour ceux qui suivraient notre point de vue) de développer un équivalent libre. C'est pourquoi nous ne le faisons pas. Logiciel propriétaire Le logiciel propriétaire est un logiciel qui n'est ni libre, ni semi-libre. Son utilisation, sa redistribution ou sa modification sont interdites, ou exigent une autorisation spécifique, ou sont tellement restreintes que vous ne pouvez en fait pas le faire librement. La Free Software Foundation suit une règle consistant à ne jamais installer un logiciel propriétaire sur nos ordinateurs, sauf à titre temporaire dans le but spécifique d'élaborer un remplacement libre à ce même logiciel. Exception faite de ce cas, nous pensons qu'il n'existe aucune excuse pour l'installation d'un programme propriétaire. Par exemple, nous estimons justifiée l'installation d'Unix sur nos ordinateurs dans les années 1980, parce que nous l'utilisions pour écrire une version libre en remplacement d'Unix. Actuellement, puisque des systèmes d'exploitation libres sont disponibles, l'excuse n'est plus valable; nous avons éliminé tous nos systèmes d'exploitation non-libres, et chaque ordinateur que nous installons doit fonctionner avec un système d'exploitation complètement libre. Nous n'insistons pas pour que les utilisateurs de GNU, ou ses contributeurs, suivent cette règle. C'est une règle que nous nous imposons nous-mêmes. Mais nous espérons que vous déciderez de la suivre également. Freeware Le terme «freeware» n'a pas de définition claire communément acceptée, mais elle est utilisée couramment pour des paquetages qui autorisent la redistribution mais pas la modification (et dont le code source n'est pas disponible). Ces paquetages ne sont pas des logiciels libres, donc n'utilisez pas, s'il vous plaît, «freeware» pour parler de logiciel libre. Shareware (partagiciel) Le partagiciel est un logiciel qui s'accompagne de la permission de redistribuer des copies, mais qui mentionne que toute personne qui continue à en utiliser une copie est obligée de payer des royalties. Les sharewares ne sont pas des logiciels libres ou même semi-libres. Pour deux raisons: * Pour les sharewares, le code source n'est pratiquement jamais fourni; et donc vous ne pouvez pas du tout modifier le programme. Avec le shareware, il ne vous est pas permis d'effectuer une copie et de l'installer sans vous acquitter du paiement d'un droit licence, même pour des individus impliqués dans des activités non lucratives. (En pratique, ces termes de distribution sont en général peu appréciés, et les gens le font quand même, même si ce n'est pas permis.) Logiciel commercial Le logiciel commercial est un logiciel développé par une entreprise dont le but est de gagner de l'argent sur l'utilisation du logiciel. «Commercial» et «propriétaire» ne sont pas synonymes ! La plupart des logiciels commerciaux sont propriétaires, mais il y a des logiciels libres commerciaux, et il y a des logiciels noncommerciaux non-libres. Par exemple, GNU Ada est toujours distribué sous les termes de la GPL GNU, et chaque copie est un logiciel libre; mais ses développeurs vendent des contrats de support. Quand leurs commerciaux parlent à de futurs clients, quelquefois ceux-ci disent, «Nous nous sentirions plus en sécurité avec un compilateur commercial.». Le représentant répond, «GNU Ada est un compilateur commercial; il est également un logiciel libre.» Pour le Projet GNU, l'accent est mis sur l'autre composante: la chose importante est que GNU Ada est un logiciel libre; que ce soit un logiciel commercial n'est pas un point crucial. Cependant, le développement supplémentaire de GNU Ada qui résulte de ce commerce est certainement bénéfique. Aidez-nous s'il vous plaît à faire prendre conscience que le logiciel libre commercial est possible. Vous pouvez y contribuer en faisant un effort pour ne pas dire «commercial» lorsque vous voulez dire «propriétaire». Qu'est-ce que le copyleft ? La manière la plus simple de rendre un programme libre est de le distribuer dans le domaine public, sans copyright. Cela autorise les gens à partager le programme et leurs améliorations si le coeur leur en dit. Mais cela autorise aussi des personnes indélicates à faire du programme un logiciel propriétaire. Ils peuvent très bien y effectuer des changements, juste quelques-uns ou plusieurs, et distribuer le résultat comme un logiciel propriétaire. Ceux qui recevront le programme dans sa forme modifiée n'auront pas la liberté que l'auteur original leur aura donné; l'intermédiaire l'aura fait disparaître. Dans le projet GNU, notre but est de donner à tous les utilisateurs la liberté de redistribuer et de modifier les logiciels GNU. Si des intermédiaires pouvaient enlever cette liberté, nous aurions beaucoup d'utilisateurs, mais ils n'auraient aucune liberté. Alors, au lieu de mettre les logiciels GNU dans le domaine public, nous les mettons sous "copyleft". Le copyleft indique que quiconque les redistribue, avec ou sans modifications, doit aussi transmettre la liberté de les copier et de les modifier. Le copyleft garantit cette liberté pour tous les utilisateurs. Le copyleft fournit aussi un encouragement aux autres programmeurs qui veulent ajouter des logiciels libres. Des programmes importants comme le compilateur C++ de GNU n'existent que grâce à lui. Le copyleft aide aussi les programmeurs qui veulent contribuer à des améliorations sur des logiciels libres à obtenir la permission de le faire. Ces programmeurs travaillent souvent pour des entreprises ou des universités qui feraient n'importe quoi pour plus d'argent. Un programmeur pourrait vouloir faire profiter la communauté de ses modifications, mais son employeur pourrait vouloir transformer le travail en un produit propriétaire. Quand nous expliquons à l'employeur qu'il est illégal de distribuer la version améliorée autrement que comme logiciel libre, celui-ci décide souvent de le distribuer librement plutôt que de le laisser tomber. Pour mettre un logiciel sous copyleft, nous déclarons d'abord qu'il est sous copyright, ensuite nous ajoutons les conditions de distribution, qui sont un outil légal donnant à chacun le droit d'utiliser, de modifier, et de redistribuer le code du programme, ou tous les programmes qui en sont dérivés, mais seulement si les conditions de distribution demeurent inchangées. Ainsi, le code et ses libertés sont légalement indissociables. Les développeurs de logiciels propriétaires utilisent le copyright pour restreindre la liberté des utilisateurs ; nous utilisons le copyleft pour la garantir. C'est pourquoi nous avons inversé le nom, en changeant "copyright" en "copyleft". Le copyleft est un terme général, il y a cependant beaucoup de variations qui rentrent plus dans le détail. Dans le projet GNU, les conditions de distribution spécifiques que nous utilisons sont contenues dans la GNU General Public License (disponible au formt HTML, texte, et Texinfo). La GNU General Public License est appelée la GNU GPL. Une forme alternative de copyleft, la GNU Lesser General Public License (LGPL) (disponible au format HTML, texte, et Texinfo), s'applique à quelques (mais pas à toutes) bibliothèques GNU. Cette licence était initialement appelée la Library GPL (GPL pour les bibliothèques), mais nous avons changé le nom car l'ancien nom encourageait l'utilisation de cette licence plus souvent qu'elle aurait dû être utilisée. Pour une explication sur les motivations qui nous ont convaincu que ce changement était nécessaire, lire l'article pourquoi vous ne devriez pas utiliser la LGPL pour votre prochaine bibliothèque. La GNU Library General Public License (27k d'HTML ou 25k de texte) est toujours disponible bien qu'elle ait été remplacée par la licence précédente. La GNU Free Documentation License (FDL) (disponible au format HTML, texte et Texinfo) est une forme de copyleft conçue pour être utilisée pour un manuel, un livre ou un autre document de manière à assurer à chacun la liberté effective de le copier et de le redistribuer, avec ou sans modifications, de façon commerciale ou non. La licence appropriée est incluse dans beaucoup de manuels et dans chaque distribution de code source GNU. La GNU GPL est conçue de façon à pouvoir être appliquée à votre programme si vous en détenez le copyright. Vous n'aurez pas à modifier la GNU GPL pour le faire, mais seulement à ajouter des références appropriées à la GNU GPL au programme. Si vous désirez mettre votre programme sous copyleft avec la GNU GPL ou la GNU LGPL, veuillez lire la page d'instructions de la GPL comme conseil. L'utilisation des mêmes conditions de distribution pour plusieurs programmes différents facilite la copie de code entre ces programmes. Avec les mêmes conditions de distribution, il n'y a plus de souci d'incompatibilité. La LGPL contient une clause qui vous autorise à modifier les conditions de distribution de la GPL ordinaire, ainsi vous pouvez copier du code dans un autre programme couvert par la GPL. [...] Traduction de la GPL Ces versions ne sont pas officielles. Légalement parlant, la version originale (anglaise) de la GPL est ce qui spécifie les vraies conditions de distribution pour les programmes GNU. Les raisons pour lesquelles la FSF n'autorise pas les traductions à être officiellement valides est que les vérifier serait difficile et coûteux (ceci nécessitant l'aide de juristes bilingues dans d'autres pays). Encore pire, si une erreur se glissait dans les traductions, les conséquences seraient désastreuses pour la communauté du logiciel libre toute entière. Tant que les traductions ne sont pas officielles, elles ne peuvent pas faire de mal, et nous espérons qu'elles aideront plus de personnes à comprendre la GPL. Nous permettons la publication de traductions de la GPL ou de la LGPL dans d'autres langues, du moment où vous (1) spécifiez dans vos traductions qu'elles ne sont pas officielles (voir plus loin comment faire), informez que vous ne comptez pas légalement comme substitution à la version originale, et (2) vous autorisez à ajouter des modifications à notre demande, si nous apprenons par d'autres amis de GNU que des modifications sont nécessaires pour rendre la traduction plus claire. Pour spécifier que votre traduction n'est pas officielle, nous voudrions que vous ajoutiez le texte suivant au début, à la fois en anglais et à la fois dans la langue de la traduction, en remplaçant «language» par le nom de cette langue : This is an unofficial translation of the GNU General Public License into language. It was not published by the Free Software Foundation, and does not legally state the distribution terms for software that uses the GNU GPL--only the original English text of the GNU GPL does that. However, we hope that this translation will help language speakers understand the GNU GPL better. Soit en français: Ceci est une traduction non officielle de la GNU General Public License en français. Elle n'a pas été publiée par la Free Software Foundation, et ne détermine pas les termes de distribution pour les logiciels qui utilisent la GNU GPL--seul le texte anglais original de la GNU GPL en a le droit. Cependant, nous espérons que cette traduction aidera les francophones à mieux comprendre la GNU GPL. GNU GENERAL PUBLIC LICENSE (TRADUCTION NON OFFICIELLE) Version 2, juin 1991 Copyright (C) 1989, 1991, Free Software Foundation Inc. 675 Mass Ave, Cambridge, MA02139, Etats-Unis. Il est permis à tout le monde de reproduire et distribuer des copies conformes de ce document de licence, mais aucune modification ne doit y être apportée. Préambule Les licences relatives à la plupart des logiciels sont destinées à supprimer votre liberté de les partager et de les modifier. Par contraste, la licence publique générale GNU General Public License veut garantir votre liberté de partager et de modifier les logiciels libres, pour qu'ils soient vraiment libres pour tous leurs utilisateurs. La présente licence publique générale s'applique à la plupart des logiciels de la Free Software Foundation, ainsi qu'à tout autre programme dont les auteurs s'engagent à l'utiliser. (Certains autres logiciels sont couverts par la Licence Publique Générale pour Bibliothèques GNU à la place). Vous pouvez aussi l'appliquer à vos programmes. Quand nous parlons de logiciels libres, nous parlons de liberté, non de gratuité. Nos licences publiques générales veulent vous garantir : * que vous avez toute liberté de distribuer des copies des logiciels libres (et de facturer ce service, si vous le souhaitez); * que vous recevez les codes sources ou pouvez les obtenir si vous le souhaitez ; * que vous pouvez modifier les logiciels ou en utiliser des éléments dans de nouveaux programmes libres; * et que vous savez que vous pouvez le faire. Pour protéger vos droits, nous devons apporter des restrictions, qui vont interdire à quiconque de vous dénier ces droits, ou de vous demander de vous en désister. Ces restrictions se traduisent par certaines responsabilités pour ce qui vous concerne, si vous distribuez des copies de logiciels, ou si vous les modifiez. Par exemple, si vous distribuez des copies d'un tel programme, gratuitement ou contre une rémunération, vous devez transférer aux destinataires tous les droits dont vous disposez. Vous devez vous garantir qu'euxmêmes, par ailleurs, reçoivent ou peuvent recevoir le code source. Et vous devez leur montrer les présentes dispositions, de façon qu'ils connaissent leurs droits. Nous protégeons vos droits en deux étapes: 1. Nous assurons le droit d'auteur (copyright) du logiciel, et 2. Nous vous proposons cette licence, qui vous donne l'autorisation légale de dupliquer, distribuer et/ou modifier le logiciel. De même, pour la protection de chacun des auteurs, et pour notre propre protection, nous souhaitons nous assurer que tout le monde comprenne qu'il n'y a aucune garantie portant sur ce logiciel libre. Si le logiciel est modifié par quelqu'un d'autre puis transmis à des tiers, nous souhaitons que les destinataires sachent que ce qu'ils possèdent n'est pas l'original, de façon que tous problèmes introduits par d'autres ne se traduisent pas par une répercussion négative sur la réputation de l'auteur original. Enfin, tout programme libre est en permanence menacé par des brevets de logiciels. Nous souhaitons éviter le danger que des sous-distributeurs d'un programme libre obtiennent à titre individuel des licences de brevets, avec comme conséquence qu'ils ont un droit de propriété sur le programme. Pour éviter cette situation, nous avons fait tout ce qui est nécessaire pour que tous brevets doivent faire l'objet d'une concession de licence qui en permette l'utilisation libre par quiconque, ou bien qu'il ne soit pas concédé du tout. Nous présentons ci-dessous les clauses et dispositions concernant la duplication, la distribution et la modification. Conditions d'exploitation portant sur la duplication, la distribution et la modification 1. Le présent contrat de licence s'applique à tout programme ou autre ouvrage contenant un avis, apposé par le détenteur du droit de propriété, disant qu'il peut être distribué au titre des dispositions de la présente Licence Publique Générale. Ci-après, le "Programme" désigne l'un quelconque de ces programmes ou ouvrages, et un "ouvrage fondé sur le programme" désigne soit le programme, soit un ouvrage qui en dérive au titre de la loi sur le droit d'auteur ; plus précisément, il s'agira d'un ouvrage contenant le programme ou une version de ce dernier, soit mot à mot, soit avec des modifications et/ou traduit en une autre langue (ciaprès, le terme "modification" englobe, sans aucune limitation, les traductions qui en sont faites). Chaque titulaire de licence sera appelé "concessionnaire". Les activités autres que la duplication, la distribution et la modification ne sont pas couvertes par la présente licence; elles n'entrent pas dans le cadre de cette dernière. L'exécution du programme n'est soumise à aucune restriction, et les résultats du programme ne sont couverts que si son contenu constitue un ouvrage fondé sur le programme (indépendamment du fait qu'il a été réalisé par exécution du programme). La véracité de ce qui précède dépend de ce que fait le programme. 2. Le concessionnaire peut dupliquer et distribuer des copies mot à mot du code source du programme tel qu'il les reçoit, et ce sur un support quelconque, du moment qu'il appose, d'une manière parfaitement visible et appropriée, sur chaque exemplaire, un avis approprié de droits d'auteur (Copyright) et de renonciation à garantie; qu'il maintient intacts tous les avis qui se rapportent à la présente licence et à l'absence de toute garantie; et qu'il transmet à tout destinataire du programme un exemplaire de la présente licence en même temps que le programme. Le concessionnaire peut facturer l'acte physique de transfert d'un exemplaire, et il peut, à sa discrétion, proposer en échange d'une rémunération une protection en garantie. 3. Le concessionnaire peut modifier son ou ses exemplaires du programme ou de toute portion de ce dernier, en formant ainsi un ouvrage fondé sur le programme, et dupliquer et distribuer ces modifications ou cet ouvrage selon les dispositions de la section 1 ci-dessus, du moment que le concessionnaire satisfait aussi à toutes ces conditions: a. Le concessionnaire doit faire en sorte que les fichiers modifiés portent un avis, parfaitement visible, disant que le concessionnaire a modifié les fichiers, avec la date de tout changement. b. Le concessionnaire doit faire en sorte que tout ouvrage qu'il distribue ou publie, et qui, en totalité ou en partie, contient le programme ou une partie quelconque de ce dernier ou en dérive, soit concédé en bloc, à titre gracieux, à tous tiers au titre des dispositions de la présente licence. c. Si le programme modifié lit normalement des instructions interactives lors de son exécution, le concessionnaire doit, quand il commence l'exécution du programme pour une telle utilisation interactive de la manière la plus usuelle, faire en sorte que ce programme imprime ou affiche une annonce, comprenant un avis approprié de droits d'auteur, et un avis selon lequel il n'y a aucune garantie (ou autrement, que le concessionnaire fournit une garantie), et que les utilisateurs peuvent redistribuer le programme au titre de ces dispositions, et disant à l'utilisateur comment visualiser une copie de cette licence (exception: si le programme par lui-même est interactif mais n'imprime normalement pas une telle annonce, l'ouvrage du concessionnaire se fondant sur le programme n'a pas besoin d'imprimer une annonce). Les exigences ci-dessus s'appliquent à l'ouvrage modifié pris en bloc. Si des sections identifiables de cet ouvrage ne dérivent pas du programme et peuvent être considérées raisonnablement comme représentant des ouvrages indépendants et distincts par eux-mêmes, alors la présente licence, et ses dispositions, ne s'appliquent pas à ces sections quand le concessionnaire les distribue sous forme d'ouvrages distincts. Mais quand le concessionnaire distribue ces mêmes sections en tant qu'élément d'un tout qui représente un ouvrage se fondant sur le programme, la distribution de ce tout doit se faire conformément aux dispositions de la présente licence, dont les autorisations, portant sur d'autres concessionnaires, s'étendent à la totalité dont il est question, et ainsi à chacune de ces parties, indépendamment de celui qu'il a écrite. Ainsi, cette section n'a pas pour but de revendiquer des droits ou de contester vos droits sur un ouvrage entièrement écrit par le concessionnaire; bien plus, l'intention est d'exercer le droit de surveiller la distribution d'ouvrages dérivée ou collective se fondant sur le programme. De plus, un simple assemblage d'un autre ouvrage ne se fondant pas sur le programme, avec le programme (ou avec un ouvrage se fondant sur le programme) sur un volume d'un support de stockage ou distribution, ne fait pas entrer l'autre ouvrage dans le cadre de la présente licence. 4. Le concessionnaire peut dupliquer et distribuer le programme (ou un ouvrage se fondant sur ce dernier, au titre de la Section 2), en code objet ou sous une forme exécutable, au titre des dispositions des Sections 1 et 2 ci-dessus, du moment que le concessionnaire effectue aussi l'une des opérations suivantes : a. Lui joindre le code source complet correspondant, exploitable par une machine, code qui doit être distribué au titre des Sections 1 et 2 ci-dessus sur un support couramment utilisé pour l'échange de logiciels ; ou bien b. Lui joindre une offre écrite, dont la validité se prolonge pendant au moins 3 ans, transmettre à un tiers quelconque, pour un montant non supérieur au coût pour le concessionnaire, réalisation physique de la distribution de la source, un exemplaire complet, exploitable par une machine, code source correspondant, qui devra être distribué au titre des dispositions des Sections 1 et 2 ci-dessus un support couramment utilisé pour l'échange des logiciels ; ou bien de de du sur c. Lui joindre les informations que le concessionnaire a reçues, pour proposer une distribution du code source correspondant (cette variante n'est autorisée que pour la distribution non commerciale, et seulement si le concessionnaire a reçu le programme sous forme exécutable ou sous forme d'un code objet, avec une telle offre, conformément à l'alinéa b) ci-dessus). Le code source d'un ouvrage représente la forme préférée de l'ouvrage pour y effectuer des modifications. Pour un ouvrage exécutable, le code source complet représente la totalité du code source pour tous les modules qu'il contient, plus tous fichiers de définitions d'interface associés, plus les informations en code machine pour commander la compilation et l'installation du programme exécutable. Cependant, à titre d'exceptions spéciales, le code source distribué n'a pas besoin de comprendre quoi que ce soit qui est normalement distribué (sous forme source ou sous forme binaire) avec les composants principaux (compilateur, noyau de système d'exploitation, etc.) du système d'exploitation sur lequel est exécuté le programme exécutable, à moins que le composant, par lui-même, soit joint au programme exécutable. Si la distribution de l'exécutable ou du code objet est réalisée de telle sorte qu'elle offre d'accéder à une copie à partir d'un lieu désigné, alors le fait d'offrir un accès équivalent à la duplication du code source à partir de ce même lieu s'entend comme distribution du code source, même si des tiers ne sont pas contraints de dupliquer la source en même temps que le code objet. 5. Le concessionnaire ne peut dupliquer, modifier, concéder en sous-licence ou distribuer le programme, sauf si cela est expressément prévu par les dispositions de la présente licence. Toute tentative pour autrement dupliquer, modifier, concéder en sous-licence ou distribuer le programme est répétée nulle, et met automatiquement fin aux droits du concessionnaire au titre de la présente licence. Cependant, les parties qui ont reçu des copies, ou des droits, de la part du concessionnaire au titre de la présente licence, ne verront pas expirer leur contrat de licence, tant que ces parties agissent d'une manière parfaitement conforme. 6. Il n'est pas exigé du concessionnaire qu'il accepte la présente licence, car il ne l'a pas signée. Cependant, rien d'autre n'octroie au concessionnaire l'autorisation de modifier ou de distribuer le programme ou ses ouvrages dérivés. Ces actions sont interdites par la loi si le concessionnaire n'accepte pas la présente licence. En conséquence, par le fait de modifier ou de distribuer le programme (ou un ouvrage quelconque se fondant sur le programme), le concessionnaire indique qu'il accepte la présente licence, et qu'il a la volonté de se conformer à toutes les clauses et dispositions concernant la duplication, la distribution ou la modification du programme ou d'ouvrages se fondant sur ce dernier. 7. Chaque fois que le concessionnaire redistribue le programme (ou tout ouvrage se fondant sur le programme), le destinataire reçoit automatiquement une licence de l'émetteur initial de la licence, pour dupliquer, distribuer ou modifier le programme, sous réserve des présentes clauses et dispositions. Le concessionnaire ne peut imposer aucune restriction plus poussée sur l'exercice, par le destinataire, des droits octroyés au titre des présentes. Le concessionnaire n'a pas pour responsabilité d'exiger que des tiers se conforment à la présente licence. 8. Si, en conséquence une décision de justice ou une allégation d'infraction au droit des brevets, ou pour toute autre raison (qui n'est pas limitée à des problèmes de propriétés industrielles), des conditions sont imposées au concessionnaire (par autorité de justice, par convention ou autrement), qui entrent en contradiction avec les dispositions de la présente licence, elles n'exemptent pas le concessionnaire de respecter les dispositions de la présente licence. Si le concessionnaire ne peut procéder à la distribution de façon à satisfaire simultanément à ces obligations au titre de la présente licence et à toutes autres obligations pertinentes, alors, en conséquence de ce qui précède, le concessionnaire peut ne pas procéder du tout à la distribution du programme. Par exemple, si une licence de brevet ne permettait pas une redistribution du programme, sans redevances, par tous ceux qui reçoivent des copies directement ou indirectement par l'intermédiaire du concessionnaire, alors le seul moyen par lequel le concessionnaire pourrait satisfaire tant à cette licence de brevet qu'à la présente licence, consisterait à s'abstenir complètement de distribuer le programme. Si une partie quelconque de cette section est considérée comme nulle ou non exécutoire dans certaines circonstances particulières, le reste de cette section est réputé s'appliquer, et la section dans son ensemble est considérée comme s'appliquant dans les autres circonstances. La présente section n'a pas pour objet de pousser le concessionnaire à enfreindre tous brevets ou autres revendications à droit de propriété, ou encore à contester la validité de une ou plusieurs quelconques de ces revendications; la présente section a pour objet unique de protéger l'intégrité du système de distribution des logiciels libres, système qui est mis en oeuvre par les pratiques liées aux licences publiques. De nombreuses personnes ont apporté une forte contribution à la gamme étendue des logiciels distribués par ce système, en comptant sur l'application systématique de ce système; c'est à l'auteur/donateur de décider s'il a la volonté de distribuer le logiciel par un quelconque autre système, et un concessionnaire ne peut imposer ce choix. La présente section veut rendre parfaitement claire ce que l'on pense être une conséquence du reste de la présente licence. 9. Si la distribution et/ou l'utilisation du Programme est restreinte dans certains pays, sous l'effet de brevets ou d'interfaces présentant un droit d'auteur, le détenteur du droit d'auteur original, qui soumet le Programme aux dispositions de la présente licence, pourra ajouter une limitation expresse de distribution géographique excluant ces pays, de façon que la distribution ne soit autorisée que dans les pays ou parmi les pays qui ne sont pas ainsi exclus. Dans ce cas, la limitation fait partie intégrante de la présente licence, comme si elle était écrite dans le corps de la présente licence. La Free Software Foundation peut, de temps à autre, publier des versions révisées et/ou nouvelles du General Public License. Ces nouvelles versions seront analogues, du point de vue de leur esprit, à la présente version, mais pourront en différer dans le détail, pour résoudre de nouveaux problèmes ou de nouvelles situations. Chaque version reçoit un numéro de version qui lui est propre. Si le programme spécifie un numéro de version de la présente licence, qui s'applique à cette dernier et "à toute autre version ultérieure", le concessionnaire a le choix de respecter les clauses et dispositions de cette version, ou une quelconque version ultérieure publiée par la Free Software Foundation. Si le programme ne spécifie pas de numéro de version de la présente licence, le concessionnaire pourra choisir une version quelconque publiée à tout moment par la Free Software Foundation. 10. Si le concessionnaire souhaite incorporer des parties dont les conditions de distribution sont différentes, il autorisation. Pour un logiciel soumis à droit d'auteur par Free Software Foundation; nous faisons quelquefois des du programme dans d'autres programmes libres devrait écrire à l'auteur pour demander son la Free Software Foundation, il devra écrire à la exceptions à cette règle. Notre décision va être guidée par le double objectif de protéger le statut libre de tous les dérivés de nos logiciels libres, et de favoriser le partage et la réutilisation des logiciels en général. ABSENCE DE GARANTIE 11. COMME LA LICENCE DU PROGRAMME EST CONCEDEE A TITRE GRATUIT, IL N'Y AUCUNE GARANTIE S'APPLIQUANT AU PROGRAMME, DANS LA MESURE AUTORISEE PAR LA LOI EN VIGUEUR. SAUF MENTION CONTRAIRE ECRITE, LES DETENTEURS DU DROIT D'AUTEUR ET/OU LES AUTRES PARTIES METTENT LE PROGRAMME A DISPOSITON "EN L'ETAT", SANS AUCUNE GARANTIE DE QUELQUE NATURE QUE CE SOIT, EXPRESSE OU IMPLICITE, Y COMPRIS, MAIS SANS LIMITATION, LES GARANTIES IMPLICITES DE COMMERCIALISATION ET DE L'APTITUDE A UN OBJET PARTICULIER. C'EST LE CONCESSIONNAIRE QUI PREND LA TOTALITE DU RISQUE QUANT A LA QUALITE ET AUX PERFORMANCES DU PROGRAMME. SI LE PROGRAMME SE REVELAIT DEFECTUEUX, C'EST LE CONCESSIONNAIRE QUI PRENDRAIT A SA CHARGE LE COUT DE L'ENSEMBLE DES OPERATIONS NECESSAIRES D'ENTRETIEN, REPARATION OU CORRECTION. 12. EN AUCUN CAS, SAUF SI LA LOI EN VIGUEUR L'EXIGE OU SI UNE CONVENTION ECRITE EXISTE A CE SUJET, AUCUN DETENTEUR DE DROITS D'AUTEUR, OU AUCUNE PARTIE AYANT LE POUVOIR DE MODIFIER ET/OU DE REDISTRIBUER LE PROGRAMME CONFORMEMENT AUX AUTORISATIONS CIDESSUS, N'EST RESPONSABLE VIS-A-VIS DU CONCESSIONNAIRE POUR CE QUI EST DES DOMMAGES, Y COMPRIS TOUS DOMMAGES GENERAUX, SPECIAUX, ACCIDENTELS OU INDIRECTS, RESULTANT DE L'UTILISATION OU DU PROGRAMME OU DE L'IMPOSSIBILITE D'UTILISER LE PROGRAMME (Y COMPRIS, MAIS SANS LIMITATION, LA PERTE DE DONNEES, OU LE FAIT QUE DES DONNEES SONT RENDUES IMPRECISES, OU ENCORE LES PERTES EPROUVEES PAR LE CONCESSIONNAIRE OU PAR DES TIERS, OU ENCORE UN MANQUEMENT DU PROGRAMME A FONCTIONNER AVEC TOUS AUTRES PROGRAMMES), MEME SI CE DETENTEUR OU CETTE AUTRE PARTIE A ETE AVISE DE LA POSSIBILITE DE TELS DOMMAGES. FIN DES CONDITIONS D'EXPLOITATION Le Projet GNU par Richard Stallman publié à l'origine dans le livre "Open Sources" (traduction Sébastien Blondeel) La première communauté qui partageait le logiciel En 1971, quand j'ai commencé à travailler au laboratoire d'intelligence artificielle (IA) du MITN.d.T. : Institut de Technologie du Massachusetts, l'une des universités les plus prestigieuses des États-Unis d'Amérique., j'ai intégré une communauté qui partageait le logiciel depuis de nombreuses années déjà. Le partage du logiciel n'était pas limité à notre communauté ; c'est une notion aussi ancienne que les premiers ordinateurs, tout comme on partage des recettes depuis les débuts de la cuisine. Mais nous partagions davantage que la plupart. Le laboratoire d'IA utilisait un système d'exploitation à temps partagé appelé ITS (Incompatible System, ou système à temps partagé incompatible) que les hackers de l'équipe avaient écrit et en langage d'assemblage pour le Digital PDP-10, l'un des grands ordinateurs de l'époque. membre de cette communauté, hacker système de l'équipe du laboratoire d'IA, mon travail améliorer ce système. Timesharing mis au point En tant que consistait à Nous ne qualifiions pas nos productions de «logiciels libres», car ce terme n'existait pas encore ; c'est pourtant ce qu'elles étaient. Quand d'autres universitaires ou quand des ingénieurs souhaitaient utiliser et porter l'un de nos programmes, nous les laissions volontiers faire. Et quand on remarquait que quelqu'un utilisait un programme intéressant mais inconnu, on pouvait toujours en obtenir le code source, afin de le lire, le modifier, ou d'en réutiliser des parties dans le cadre d'un nouveau programme. (1) L'utilisation du mot «hacker» dans le sens de «qui viole des systèmes de sécurité» est un amalgame instillé par les mass media. Nous autres hackers refusons de reconnaître ce sens, et continuons d'utiliser ce mot dans le sens «qui aime programmer et apprécie de le faire de manière astucieuse et intelligente.» (N.d.T. : en français, on peut utiliser le néologisme «bitouilleur» pour désigner l'état d'esprit de celui qui «touille des bits»). L'effondrement de la communauté La situation s'est modifiée de manière drastique au début des années 1980 quand la société Digital a mis fin à la série des PDP-10. Cette architecture, élégante et puissante dans les années 60, ne pouvait pas s'étendre naturellement aux plus grands espaces d'adressage qu'on trouvait dans les années 80. Cela rendait obsolètes la quasi-totalité des programmes constituant ITS. La communauté des hackers du laboratoire d'IA s'était effondrée peu de temps auparavant. La plupart d'entre eux avaient été engagés par une nouvelle société, Symbolics, et ceux qui étaient restés ne parvenaient pas à maintenir la communauté (le livre Hackers, écrit par Steve Levy, décrit ces événements et dépeint clairement l'apogée de cette communauté). Quand le laboratoire a, en 1982, choisi d'acheter un nouveau PDP-10, ses administrateurs ont décidé de remplacer ITS par le système de temps partagé de la société Digital, qui n'était pas libre. Les ordinateurs modernes d'alors, tels que le VAX ou le 68020, disposaient de leurs propres systèmes d'exploitation, mais aucun d'entre eux n'était un logiciel libre: il fallait signer un accord de non divulgation pour en obtenir ne serait-ce que des copies exécutables. Cela signifiait que la première étape de l'utilisation d'un ordinateur était de promettre de ne pas aider son prochain. On interdisait toute communauté coopérative. La règle qu'édictaient ceux qui détenaient le monopole d'un logiciel propriétaire était «Qui partage avec son voisin est un pirate. Qui souhaite la moindre modification doit nous supplier de la lui faire». L'idée que le système social du logiciel propriétaire - le système qui vous interdit de partager ou d'échanger le logiciel -est antisocial, immoral, et qu'il est tout bonnement incorrect, surprendra peut-être certains lecteurs. Mais comment qualifier autrement un système fondé sur la division et l'isolement des utilisateurs propriétaire de logiciels convaincre ? Les lecteurs surpris par cette idée ont probablement pris le système social du logiciel pour argent comptant, ou l'ont jugé en employant les termes suggérés par les entreprises vivant propriétaires. Les éditeurs de logiciels travaillent durement, et depuis longtemps, pour tout un chacun qu'il n'existe qu'un seul point de vue sur la question - le leur. Quand les éditeurs de logiciels parlent de «faire respecter» leurs «droits» ou de «couper court au piratage», le contenu réel de leur discours passe au second plan. Le véritable message se trouve entre les lignes, et il consiste en des hypothèses de travail qu'ils considèrent comme acquises ; nous sommes censés les accepter les yeux fermés. Passons-les donc en revue. La première hypothèse est que les sociétés éditrices de logiciels disposent d'un droit naturel, incontestable, à être propriétaire du logiciel et asseoir ainsi leur pouvoir sur tous ses utilisateurs (si c'était là un droit naturel, on ne pourrait formuler aucune objection, indépendamment du tort qu'il cause à tous). Il est intéressant de remarquer que la constitution et la tradition juridique des États-Unis d'Amérique rejettent toutes deux cette idée; le copyright n'est pas un droit naturel, mais un monopole artificiel, imposé par l'État, qui restreint le droit naturel qu'ont les utilisateurs de copier le logiciel. Une autre hypothèse sous-jacente est que seules importent les fonctionnalités du logiciel - et que les utilisateurs d'ordinateurs n'ont pas leur mot à dire quant au modèle de société qu'ils souhaitent voir mettre en place. Une troisième hypothèse est qu'on ne disposerait d'aucun logiciel utilisable (ou qu'on ne disposerait jamais d'un logiciel qui s'acquitte de telle ou telle tâche en particulier) si on ne garantissait pas à une société l'assise d'un pouvoir sur les utilisateurs du programme. Cette idée était plausible, jusqu'à ce que le mouvement du logiciel libre démontrât qu'on peut produire toutes sortes de logiciels utiles sans qu'il soit nécessaire de les barder de chaînes. Si l'on se refuse à accepter ces hypothèses, et si on examine ces questions en se fondant sur une moralité dictée par le bon sens, qui place les utilisateurs au premier plan, on parvient à des conclusions bien différentes. Les utilisateurs des ordinateurs doivent être libres de modifier les programmes pour qu'ils répondent mieux à leurs besoins, et libres de partager le logiciel, car la société est fondée sur l'aide à autrui. La place me manque ici pour développer le raisonnement menant à cette conclusion, aussi renverrai-je le lecteur au document Pourquoi le logiciel ne devrait appartenir à personne. Une profonde prise de décision Avec la fin de ma communauté, il m'était impossible de continuer comme de par le passé. J'étais au lieu de cela confronté à une profonde prise de décision. La solution de facilité était de rejoindre le monde du logiciel propriétaire, de signer des accords de non divulgation et promettre ainsi de ne pas aider mon ami hacker. J'aurais aussi été, très probablement, amené à développer du logiciel qui aurait été publié en fonction d'exigences de non divulgation, augmentant la pression qui en inciterait d'autres à trahir également leurs semblables. J'aurais pu gagner ma vie de cette manière, et peut-être me serais-je même amusé à écrire du code. Mais je savais qu'à la fin de ma carrière, je n'aurais à contempler que des années de construction de murs pour séparer les gens, et que j'aurais l'impression d'avoir employé ma vie à rendre le monde pire. J'avais déjà eu l'expérience douloureuse des accords de non divulgation, quand quelqu'un m'avait refusé, ainsi qu'au laboratoire d'IA du MIT, l'accès au code source du programme de contrôle de notre imprimante (l'absence de certaines fonctionnalités dans ce programme rendait l'utilisation de l'imprimante très frustrante). Aussi ne pouvais-je pas me dire que les accords de non divulgation étaient bénins. J'avais été très fâché du refus de cette personne de partager avec nous ; je ne pouvais pas, moi aussi, me comporter d'une telle manière à l'égard de mon prochain. Une autre possibilité, radicale mais déplaisante, était d'abandonner l'informatique. De cette manière, mes capacités ne seraient pas employées à mauvais escient, mais elles n'en seraient pas moins gaspillées. Je ne me rendrais pas coupable de diviser et de restreindre les droits des utilisateurs d'ordinateurs, mais cela se produirait malgré tout. Alors, j'ai cherché une façon pour un programmeur de se rendre utile pour la bonne cause. Je me suis demandé si je ne pouvais pas écrire un ou plusieurs programmes qui permettraient de souder à nouveau une communauté. La réponse était limpide: le besoin le plus pressant était un système d'exploitation. C'est le logiciel le plus crucial pour commencer à utiliser un ordinateur. Un système d'exploitation ouvre de nombreuses portes; sans système, l'ordinateur est inexploitable. Un système d'exploitation libre rendrait à nouveau possible une communauté de hackers, travaillant en mode coopératif - et tout un chacun serait invité à participer. Et tout un chacun pourrait utiliser un ordinateur sans devoir adhérer à une conspiration visant à priver ses amis des logiciels qu'il utilise. En tant que développeur de système d'exploitation, j'avais les compétences requises. Aussi, bien que le succès ne me semblât pas garanti, j'ai pensé être le candidat de choix pour ce travail. J'ai décidé de rendre le système compatible avec Unix de manière à le rendre portable, et pour le rendre plus accessible aux utilisateurs d'Unix. J'ai opté pour le nom GNU, fidèle en cela à une tradition des hackers, car c'est un acronyme récursif qui signifie «GNU's Not Unix» (GNU N'est pas Unix). Un système d'exploitation ne se limite pas à un noyau, qui suffit à peine à exécuter d'autres programmes. Dans les années 1970, tout système d'exploitation digne de ce nom disposait d'interpréteurs de commandes, d'assembleurs, de compilateurs, d'interpréteurs, de débogueurs, d'éditeurs de textes, de logiciels de courrier électronique, pour ne citer que quelques exemples. C'était le cas d'ITS, c'était le cas de Multics, c'était le cas de VMS, et c'était le cas d'Unix. Ce serait aussi le cas du système d'exploitation GNU. Plus tard, j'ai entendu ces mots, attribués à Hillel: If I am not for myself, who will be for me ? If I am only for myself, what am I ? If not now, when ? N.d.T.: on peut rendre l'esprit de ce poème comme suit : Si je ne suis rien pour moi-même, qui sera pour moi ? Si je suis tout pour moi-même, que suis-je ? Si ce n'est pas aujourd'hui, alors quand ? C'est dans cet état d'esprit que j'ai pris la décision de lancer le projet GNU. (1) En tant qu'athée, je ne suis les pas d'aucun meneur religieux, mais j'admire parfois ce que l'un d'entre eux a dit. Free comme liberté N.d.T. : en anglais, le «libre» de «logiciel libre» se dit «free». Malheureusement, ce mot a une autre acception, indépendante et incorrecte ici, il signifie également «gratuit». Cette ambiguïté a causé énormément de tort au mouvement du logiciel libre., le terme «free software» est mal compris - il n'a rien à voir avec le prix. Il parle de liberté. Voici donc la définition d'un logiciel libre : un programme est un logiciel libre pour vous, utilisateur en particulier, si: * Vous avez la liberté de l'exécuter, pour quelque motif que ce soit * Vous avez la liberté de modifier le programme afin qu'il corresponde mieux à vos besoins (dans la pratique, pour que cette liberté prenne effet, il vous faut pouvoir accéder au code source, puisqu'opérer des modifications au sein d'un programme dont on ne dispose pas du code source est un exercice extrêmement difficile) * Vous disposez de la liberté d'en redistribuer des copies, que ce soit gratuitement ou contre une somme d'argent * Vous avez la liberté de distribuer des versions modifiées du programme, afin que la communauté puisse bénéficier de vos améliorations. Puisque le mot «free» se réfère ici à la liberté, et non au prix, il n'est pas contradictoire de vendre des copies de logiciels libres. En réalité, cette liberté est cruciale : les compilations de logiciels libres vendues sur CDROM sont importantes pour la communauté, et le produit de leur vente permet de lever des fonds pour le développement du logiciel libre. C'est pourquoi on ne peut pas qualifier de logiciel libre un logiciel qu'on n'a pas la liberté d'inclure dans de telles compilations. Le mot «free» étant ambigu, on a longtemps cherché des solutions de remplacement, mais personne n'en a trouvé de convenable. La langue anglaise compte plus de mots et de nuances que toute autre langue, mais elle souffre de l'absence d'un mot simple, univoque, qui ait le sens de «free», comme liberté - «unfettered» (terme littéraire signifiant «sans entrave») étant le meilleur candidat, d'un point de vue sémantique, des mots comme «liberated» («libéré»), «freedom» («liberté»), et «open» («ouvert») présentant tous un sens incorrect ou un autre inconvénient. Les logiciels et le système du projet GNU C'est une gageure que de développer un système complet. Pour mener ce projet à bien, j'ai décidé d'adapter et de réutiliser les logiciels libres existants, quand cela était possible. J'ai par exemple décidé dès le début d'utiliser LaTex comme formateur de texte principal; quelques années plus tard, j'ai décidé d'utiliser le système de fenêtrage X plutôt que d'écrire un autre système de fenêtrage pour le projet GNU. Cette décision a rendu le système GNU distinct de la réunion de tous les logiciels GNU. Le système GNU comprend des programmes qui ne sont pas des logiciels GNU, ce sont des programmes qui ont été développés par d'autres, dans le cadre d'autres projets, pour leurs buts propres, mais qu'on peut réutiliser, car ce sont des logiciels libres. La genèse du projet En janvier 1984, j'ai démissionné de mon poste au MIT et j'ai commencé à écrire les logiciels du projet GNU. Il était nécessaire que je quitte le MIT pour empêcher ce dernier de s'immiscer dans la distribution du projet GNU en tant que logiciel libre. Si j'étais resté dans l'équipe, le MIT aurait pu se déclarer le propriétaire de mon travail, et lui imposer ses propres conditions de distribution, voire en faire un paquetage de logiciels propriétaires. Je n'avais pas l'intention d'abattre autant de travail et de le voir rendu inutilisable pour ce à quoi il était destiné: créer une nouvelle communauté qui partage le logiciel. Cependant, le professeur Winston, qui dirigeait alors le laboratoire d'IA du MIT, m'a gentiment invité à continuer à utiliser les équipements du laboratoire. Les premiers pas Peu de temps avant de me lancer dans le projet GNU, j'avais entendu parler du Free University Compiler KitN.d.T. : En anglais, le placement des mots ne permet pas de déterminer s'il s'agit d'un «kit compilateur libre de l'université» ou d'un «kit compilateur de l'université libre»., plus connu sous le nom de VUCK (en néerlandais, le mot «free» commence par un V). Ce compilateur avait été mis au point dans l'intention de traiter plusieurs langages, parmi lesquels C et Pascal, et de produire des binaires pour de nombreuses machines cibles. J'ai écrit à son auteur en lui demandant la permission d'utiliser ce compilateur dans le cadre du projet GNU. Il répondit d'un ton railleur, en déclarant (en anglais) que l'université était «free». M. Stallman ne sait pas s'il voulait ici dire «libre» ou «gratuite»., mais pas le compilateur. J'ai alors décidé que le premier programme du projet GNU serait un compilateur traitant de plusieurs langages, sur plusieurs plates-formes. En espérant m'épargner la peine d'écrire tout le compilateur moi-même, j'ai obtenu le code source du compilateur Pastel, qui était un compilateur pour plusieurs plates-formes, développé au laboratoire Lawrence Livermore. Il compilait, et c'était aussi le langage dans lequel il avait été écrit, une version étendue de Pascal, mise au point pour jouer le rôle de langage de programmation système. J'y ai ajouté une interface pour le C, et j'ai entrepris le portage de ce programme sur le Motorola 68000. Mais j'ai dû abandonner quand j'ai découvert que ce compilateur ne fonctionnait qu'avec plusieurs méga-octets d'espace de pile disponibles, alors que le système Unix du 68000 ne gérait que 64 Ko d'espace de pile. C'est alors que j'ai compris que le compilateur Pastel avait été mis au point de telle manière qu'il analysait le fichier en entrée, en faisait un arbre syntaxique, convertissait cet arbre syntaxique en chaîne d'«instructions», et engendrait ensuite le fichier de sortie, sans jamais libérer le moindre espace mémoire occupé. J'ai alors compris qu'il me faudrait réécrire un nouveau compilateur en partant de zéro. Ce compilateur est maintenant disponible, il s'appelle GCC ; il n'utilise rien du compilateur Pastel, mais j'ai réussi à adapter et à réutiliser l'analyseur syntaxique que j'avais écrit pour le C. Mais tout cela ne s'est produit que quelques années plus tard; j'ai d'abord travaillé sur GNU Emacs. GNU Emacs J'ai commencé à travailler sur GNU Emacs en septembre 1984, et ce programme commençait à devenir utilisable début 1985. Cela m'a permis d'utiliser des systèmes Unix pour éditer mes fichiers ; vi et ed me laissant froid, j'avais jusqu'alors utilisé d'autres types de machines pour éditer mes fichiers. C'est alors que j'ai reçu des requêtes de gens souhaitant utiliser GNU Emacs, ce qui a soulevé le problème de sa distribution. Je l'avais bien sûr proposé sur le serveur ftp de l'ordinateur du MIT que j'utilisais (cet ordinateur, prep.ai.mit.edu, a ainsi été promu au rang de site de distribution par ftp principal du projet GNU; quelques années plus tard, à la fin de son exploitation, nous avons transféré ce nom sur notre nouveau serveur ftp). Mais à l'époque, une proportion importante des personnes intéressées n'avaient pas d'accès à l'Internet et ne pouvaient pas obtenir une copie du programme par ftp. La question se posait en ces termes : que devais-je leur dire ? J'aurais pu leur dire : «Trouvez un ami qui dispose d'un accès au réseau et qui vous fera une copie.» J'aurais pu également procéder comme j'avais procédé avec la version originale d'Emacs, sur PDP-10, et leur dire: «Envoyez-moi une bande et une enveloppe timbrée auto-adressée, et je vous les renverrai avec Emacs.» Mais j'étais sans emploi, et je cherchais des moyens de gagner de l'argent grâce au logiciel libre. C'est pourquoi j'ai annoncé que j'enverrais une bande à quiconque en désirait une, en échange d'une contribution de 150 USD. De cette manière, je mettais en place une entreprise autour du marché de la distribution du logiciel libre, entreprise précurseur des sociétés qu'on trouve aujourd'hui et qui distribuent des systèmes GNU entiers fondés sur Linux. Un programme est-il libre pour chacun de ses utilisateurs ? Si un programme est un logiciel libre au moment où il quitte les mains de son auteur, cela ne signifie pas nécessairement qu'il sera un logiciel libre pour quiconque en possédera une copie. Le logiciel relevant du domaine public, par exemple (qui ne tombe sous le coup d'aucun copyright), est du logiciel libre; mais tout un chacun peut en produire une version propriétaire modifiée. De façon comparable, de nombreux programmes libres sont couverts par des copyrights mais distribués sous des licences permissives qui autorisent la création de versions modifiées et propriétaires. L'exemple le plus frappant de ce problème est le système de fenêtrage X. Développé au MIT, et distribué sous forme de logiciel libre sous une licence permissive, il a rapidement été adopté par divers constructeurs. Ils ont ajouté X à leurs systèmes Unix propriétaires, sous forme binaire uniquement, en le frappant du même accord de non divulgation. Ces exemplaires de X n'étaient en rien du logiciel plus libre que le reste d'Unix. Les développeurs du système de fenêtrage X ne voyaient là nul problème - ils s'attendaient à cela et souhaitaient un tel résultat. Leur but n'était pas la liberté, mais la simple «réussite», définie comme le fait d'«avoir beaucoup d'utilisateurs.» Peu leur importait la liberté de leurs utilisateurs, seul leur nombre revêtait de l'importance à leurs yeux. Cela a conduit à une situation paradoxale, où deux différentes façons d'évaluer la liberté répondaient de manières différente à la question «Ce programme est-il libre ?» Qui fondait son jugement sur la liberté fournie par les conditions de distribution de la distribution du MIT, concluait que X était un logiciel libre. Mais qui mesurait la liberté de l'utilisateur type de X, devait conclure que X était un logiciel propriétaire. La plupart des utilisateurs de X exécutaient des versions propriétaires fournies avec des systèmes Unix, et non la version libre. Le copyleft et la GPL de GNU Le but du projet GNU était de rendre les utilisateurs libres, pas de se contenter d'être populaire. Nous avions besoins de conditions de distribution qui empêcheraient de transformer du logiciel GNU en logiciel propriétaire. Nous avons utilisé la méthode du copyleft (1), ou «gauche d'auteur». Le gauche d'auteur utilise les lois du droit d'auteur, en les retournant pour leur faire servir le but opposé de ce pour quoi elles ont été conçues: ce n'est pas une manière de privatiser du logiciel, mais une manière de le laisser «libre». L'idée centrale du gauche d'auteur est de donner à quiconque la permission d'exécuter le programme, de le copier, de le modifier, et d'en distribuer des versions modifiées - mais pas la permission d'ajouter des restrictions de son cru. C'est ainsi que les libertés cruciales qui définissent le «logiciel libre» sont garanties pour quiconque en possède une copie; elles deviennent des droits inaliénables. Pour que le gauche d'auteur soit efficace, il faut que les versions modifiées demeurent libres, afin de s'assurer que toute oeuvre dérivée de notre travail reste disponible à la communauté en cas de publication. Quand des programmeurs professionnels se portent volontaires pour améliorer le logiciel GNU, c'est le gauche d'auteur qui empêche leurs employeurs de dire : «Vous ne pouvez pas partager ces modifications, car nous allons les utiliser dans le cadre de notre version propriétaire du programme.» Il est essentiel d'imposer que les modifications restent libres si on souhaite garantir la liberté de tout utilisateur du programme. Les sociétés qui ont privatisé le système de fenêtrage X faisaient en général quelques modifications pour le porter sur leurs systèmes et sur leur matériel. Ces modifications étaient ténues si on les comparait à X dans son ensemble, mais elles n'en étaient pas pour autant faciles. Si le fait de procéder à des modifications pouvait servir de prétexte à ôter leur liberté aux utilisateurs, il serait facile pour quiconque de s'en servir à son avantage. Le problème de la réunion d'un programme libre avec du code non libre est similaire. Une telle combinaison serait indubitablement non libre ; les libertés absentes de la partie non libre du programme ne se trouveraient pas non plus dans l'ensemble résultat de cette compilation. Autoriser de telles pratiques ouvrirait une voie d'eau suffisante pour couler le navire. C'est pourquoi il est crucial pour le gauche d'auteur d'exiger qu'un programme couvert par le gauche d'auteur ne puisse pas être inclus dans une version plus grande sans que cette dernière ne soit également couverte par le gauche d'auteur. L'implémentation spécifique du gauche d'auteur que nous avons utilisée pour la plupart des logiciels GNU fut la GNU General Public License (licence publique générale de GNU), ou GNU GPL en abrégé. Nous disposons d'autres types de gauche d'auteur pour des circonstances particulières. Les manuels du projet GNU sont eux aussi couverts par le gauche d'auteur, mais en utilisent une version très simplifiée, car il n'est pas nécessaire de faire appel à toute la complexité de la GNU GPL dans le cadre de manuels. (1) En 1984 ou 1985, Don Hopkins (dont l'imagination était sans bornes) m'a envoyé une lettre. Il avait écrit sur l'enveloppe plusieurs phrases amusantes, et notamment celle-ci : «Copyleft - all rights reversed.» (N.d.T. : «couvert par le gauche d'auteur, tous droits renversés.»). J'ai utilisé le mot «copyleft» pour donner un nom au concept de distribution que je développais alors. La Free Software Foundation, ou Fondation pour le Logiciel Libre Emacs attirant de plus en plus l'attention, le projet GNU comptait un nombre croissant de participants, et nous avons décidé qu'il était temps de repartir à la chasse aux fonds. En 1985, nous avons donc créé la fondation du logiciel libre (FSF), une association à but non lucratif, exemptée d'impôts, pour le développement de logiciel libre. La FSF a récupéré le marché de la distribution de logiciel libre sur bandes, auxquelles elle ajouta ensuite d'autres logiciels libres (GNU ou non), et par la vente de manuels libres. La FSF accepte les dons, mais la plus grande partie de ses recettes est toujours provenue des ventes - de copies de logiciel libre ou d'autres services associés. De nos jours, elle vend des CD-ROM de code source, des CD-ROM de binaires, des manuels de qualité (tout cela, en autorisant la redistribution et les modifications), et des distributions Deluxe (dans lesquelles nous construisons tous les logiciels pour la plate-forme de votre choix). Les employés de la fondation du logiciel libre ont écrit et maintenu un grand nombre de paquetages logiciels du projet GNU, en particulier la bibliothèque du langage C et l'interpréteur de commandes. La bibliothèque du langage C est ce qu'utilise tout programme fonctionnant sur un système GNU/Linux pour communiquer avec Linux. Elle a été développée par Roland McGrath, membre de l'équipe de la fondation du logiciel libre. L'interpréteur de commandes employé sur la plupart des systèmes GNU/Linux est BASH, le Bourne-Again Shell, qui a été développé par Brian Fox, employé de la FSF. Nous avons financé le développement de ces programmes car le projet GNU ne se limitait pas aux outils ou à un environnement de développement. Notre but était la mise en place d'un système d'exploitation complet, et de tels programmes étaient nécessaires pour l'atteindre. (1) «Bourne-Again Shell» est un clin d'oeil au nom «Bourne Shell», qui était l'interpréteur de commandes habituel sur Unix (N.d.T. : le mot anglais bash a le sens de «coup, choc» et la signification de cet acronyme est double ; c'est à la fois une nouvelle version de l'interpréteur de commandes Bourne, et et une allusion aux chrétiens qui se sont sentis renaître dans cette religion, et qu'aux États-Unis d'Amérique on qualifie de born again Christians) Assistance technique au logiciel libre La philosophie du logiciel libre rejette une pratique spécifique, très répandue dans l'industrie du logiciel, mais elle ne s'oppose pas au monde des affaires. Quand des entreprises respectent la liberté des utilisateurs, nous leur souhaitons de réussir. La vente de copies d'Emacs est une forme d'affaires fondées sur du logiciel libre. Quand la FSF a récupéré ce marché, j'ai dû chercher une autre solution pour gagner ma vie. Je l'ai trouvée sous la forme de vente de services associés au logiciel libre que j'avais développé. Cela consistait à enseigner des thèmes tels que la programmation de GNU Emacs et la personnalisation de GCC, et à développer du logiciel, principalement en portant GCC sur de nouvelles plates-formes. De nos jours, chacune de ces activités lucratives fondées sur le logiciel libre est proposée par de nombreuses sociétés. Certaines distribuent des compilations de logiciel libre sur CD-ROM; d'autres vendent de l'assistance technique en répondant à des questions d'utilisateurs, en corrigeant des bogues, et en insérant de nouvelles fonctionnalités majeures. On commence même à observer des sociétés de logiciel libre fondées sur la mise sur le marché de nouveaux logiciels libres. Prenez garde, toutefois - certaines des sociétés qui s'associent à la dénomination «open source» N.d.T.: littéralement, «[logiciel dont le] code source est ouvert». C'est une périphrase lourde et inélégante en français, mais qui résout en anglais l'ambiguïté discutée plus haut, bien que l'auteur rejette cette solution, pour des raisons expliquées à la fin de cet article. Il s'agit ici de sociétés qui font peu de cas du logiciel libre et choisissent un slogan calculé pour s'attirer les faveurs du public. fondent en réalité leur activité sur du logiciel propriétaire, qui interagit avec du logiciel libre. Ce ne sont pas des sociétés de logiciel libre, ce sont des sociétés de logiciel propriétaire dont les produits détournent les utilisateurs de leur liberté. Elles appellent cela de la «valeur ajoutée», ce qui reflète quelles valeurs elles souhaitent nous voir adopter: préférer la facilité à la liberté. Si nous faisons passer la liberté au premier plan, il nous faut leur donner le nom de produits à « liberté soustraite ». Objectifs techniques L'objectif principal du projet GNU était le logiciel libre. Même si GNU ne jouissait d'aucun avantage technique sur Unix, il disposerait d'un avantage social, en autorisant les utilisateurs à coopérer, et d'un avantage éthique, en respectant la liberté de l'utilisateur. Mais il était naturel d'appliquer à ce travail les standards bien connus du développement logiciel de qualité en utilisant par exemple des structures de données allouées dynamiquement pour éviter de mettre en place des limites fixées arbitrairement, et en gérant tous les caractères possibles encodables sur 8 bits, partout où cela avait un sens. De plus, nous rejetions l'accent mis par Unix sur les petites quantités de mémoire, en décidant de ne pas nous occuper des architectures 16 bits (il était clair que les architectures 32 bits seraient la norme au moment de la finalisation du système GNU), et en ne faisant aucun effort pour réduire la consommation mémoire en deçà d'un méga-octet. Dans les programmes pour lesquels il n'était pas crucial de manipuler des fichiers de tailles importantes, nous encouragions les programmeurs à lire le fichier en entrée, d'une traite, en mémoire, et d'analyser ensuite son contenu sans plus se préoccuper des entrées/sorties. Ces décisions ont rendu de nombreux programmes du projet GNU supérieurs à leurs équivalents sous Unix en termes de fiabilité et de vitesse d'exécution. Les ordinateurs offerts La réputation du projet GNU croissant, on nous offrait des machines sous Unix pour nous aider à le mener à bien. Elles nous furent bien utiles, car le meilleur moyen de développer les composants de GNU était de travailler sur un système Unix, dont on remplaçait les composants un par un. Mais cela a posé un problème éthique: était-il correct ou non, pour nous, de posséder des copies d'Unix ? Unix était (et demeure) du logiciel propriétaire, et la philosophie du projet GNU nous demandait de pas utiliser de logiciels propriétaire. Mais, en appliquant le même raisonnement que celui qui conclut qu'il légitime de faire usage de violence en situation de légitime défense, j'ai conclu qu'il était légitime d'utiliser paquetage propriétaire quand cela était crucial pour développer une solution de remplacement libre, qui aiderait d'autres à se passer de ce même paquetage propriétaire. ne est un en Mais ce mal avait beau être justifiable, il n'en restait pas moins un mal. De nos jours, nous ne possédons plus aucune copie d'Unix, car nous les avons toutes remplacées par des systèmes d'exploitation libres. Quand nous ne parvenions pas à substituer au système d'exploitation d'une machine un système libre, nous remplacions la machine. La GNU Task List, ou liste des tâches du projet GNU Le projet GNU suivant son cours, on trouvait ou développait un nombre croissant de composants du système, et il est finalement devenu utile de faire la liste des parties manquantes. Nous l'avons utilisée pour recruter des développeurs afin d'écrire ces dernières. Cette liste a pris le nom de GNU task list. En plus des composants manquants d'Unix, nous y avons listé plusieurs autres projets utiles, de logiciel et de documentation, que nous jugions nécessaires au sein d'un système réellement complet. De nos jours, on ne trouve presque plus aucun composant d'Unix dans la liste des tâches du projet GNU - ces travaux tous ont été menés à bien, si on néglige certains composants non essentiels. Mais la liste est pleine de projets qu'on pourrait qualifier d'«applications». Tout programme qui fait envie à une classe non restreinte d'utilisateurs constituerait un ajout utile à un système d'exploitation. On trouve même des jeux dans la liste des tâches - et c'est le cas depuis le commencement. Unix proposait des jeux, ce devait naturellement être également le cas de GNU. Mais il n'était pas nécessaire d'être compatible en matière de jeux, aussi n'avons-nous pas suivi la liste des jeux d'Unix. Nous avons plutôt listé un spectre de divers types de jeux qui plairont vraisemblablement aux utilisateurs. La GNU Library GPL, ou licence publique générale de GNU pour les bibliothèques La bibliothèque du langage C du projet GNU fait appel à un gauche d'auteur particulier, appelé la GNU Library General Public License (licence publique générale de GNU pour les bibliothèques, ou GNU LGPL), qui autorise la liaison de logiciel propriétaire avec la bibliothèque. Pourquoi une telle exception ? Ce n'est pas une question de principe ; aucun principe ne dicte que les logiciels propriétaires ont le droit de contenir notre code (pourquoi contribuer à un projet qui affirme refuser de partager avec nous ?). L'utilisation de la LGPL dans le cadre de la bibliothèque du langage C, ou de toute autre bibliothèque, est un choix stratégique. La bibliothèque du langage C joue un rôle générique; tout système propriétaire, tout compilateur, dispose d'une bibliothèque du langage C. C'est pourquoi limiter l'utilisation de notre bibliothèque du langage C au logiciel libre n'aurait donné aucun avantage au logiciel libre - cela n'aurait eu pour effet que de décourager l'utilisation de notre bibliothèque. Il existe une exception à cette règle: sur un système GNU (et GNU/Linux est l'un de ces systèmes), la bibliothèque du langage C de GNU est la seule disponible. Aussi, ses conditions de distribution déterminent s'il est possible de compiler un programme propriétaire sur le système GNU. Il n'existe aucune raison éthique d'autoriser des applications propriétaires sur le système GNU, mais d'un point de vue stratégique, il semble que les interdire découragerait plus l'utilisation d'un système GNU que cela n'encouragerait le développement d'applications libres. C'est pourquoi l'utilisation de la GPL pour les bibliothèques (ou LGPL) est une bonne stratégie dans le cadre de la bibliothèque du langage C. En ce qui concerne les autres bibliothèques, il faut prendre la décision stratégique au cas par cas. Quand une bibliothèque remplit une tâche particulière qui peut faciliter l'écriture de certains types de programmes, la distribuer sous les conditions de la GPL, en limitant son utilisation aux programmes libres, est une manière d'aider les développeurs de logiciels libres et de leur accorder un avantage à l'encontre du logiciel propriétaire. Considérons GNU Readline, une bibliothèque développée dans le but de fournir une édition de ligne de commande pour l'interpréteur de commandes BASH. Cette bibliothèque est distribuée sous la licence publique générale ordinaire de GNU, et non pas sous la LGPL. Cela a probablement pour effet de réduire l'utilisation de la bibliothèque Readline, mais cela n'induit aucune perte en ce qui nous concerne. Pendant ce temps, on compte au moins une application utile qui a été libérée, uniquement dans le but de pouvoir utiliser la bibliothèque Readline, et c'est là un gain réel pour la communauté. Les développeurs de logiciel propriétaire jouissent des avantages que leur confère l'argent; les développeurs de logiciel libre doivent compenser cela en s'épaulant les uns les autres. J'espère qu'un jour nous disposerons de toute une collection de bibliothèques couvertes par la GPL, et pour lesquelles il n'existera pas d'équivalent dans le monde du logiciel propriétaire. Nous disposerons ainsi de modules utiles, utilisables en tant que blocs de construction de nouveaux logiciels libres, et apportant un avantage considérable à la continuation du développement du logiciel libre. Gratter là où ça démange Eric Raymond affirme que «Tout bon logiciel commence par gratter un développeur là où ça le démange.». Cela se produit peut-être, parfois, mais de nombreux composants essentiels du logiciel GNU ont été développés dans le but de disposer d'un système d'exploitation libre complet. Ils ont été inspirés par une vision et un projet à long terme, pas par un coup de tête. Nous avons par exemple développé la bibliothèque du langage C de GNU car un système de type Unix a besoin d'une bibliothèque du langage C, nous avons développé le Bourne-Again Shell (BASH) car un système de type Unix a besoin d'un interpréteur de commandes, et nous avons développé GNU tar car un système de type Unix a besoin d'un programme d'archivage. Il en va de même pour les programmes que j'ai développé, à savoir le compilateur C de GNU, GNU Emacs, GDB, et GNU Make. Certains programmes du projet GNU ont été développés pour répondre aux menaces qui pesaient sur notre liberté. C'est ainsi que nous avons développé gzip en remplacement du programme Compress, que la communauté avait perdu suite aux brevets logiciels déposés sur LZW. Nous avons trouvé des gens pour développer LessTif, et plus récemment nous avons démarré les projets GNOME et Harmony, en réponse aux problème posés par certaines bibliothèques propriétaires (lire ci-après). Nous sommes en train de développer le GNU Privacy Guard (le gardien de l'intimité de GNU, ou GPG) pour remplacer un logiciel de chiffrement populaire mais pas libre, car les utilisateurs ne devraient pas devoir choisir entre la préservation de leur intimité et la préservation de leur liberté. Bien sûr, les gens qui écrivent ces programmes se sont intéressés à ce travail, et de nombreux contributeurs ont ajouté de nouvelles fonctionnalités car elles comblaient leurs besoins ou les intéressaient. Mais ce n'est pas là la raison première de ces programmes. Des développements inattendus Au commencement du projet GNU, j'ai imaginé que nous développerions le système GNU dans sa globalité avant de le publier. Les choses se sont passées différemment. Puisque chaque composant du système GNU était implémenté sur un système Unix, chaque composant pouvait fonctionner sur des systèmes Unix, bien avant que le système GNU ne soit disponible dans sa globalité. Certains de ces programmes sont devenus populaires, et leurs utilisateurs ont commencé à travailler sur des extensions et des ports - vers les diverses versions d'Unix, incompatibles entre elles, et parfois, sur d'autres systèmes encore Ce processus a rendu ces programmes bien plus complets, et a drainé des fonds et des participants vers le projet GNU. Mais il a probablement eu également pour effet de retarder de plusieurs années la mise au point d'un système en état de fonctionnement, puisque les développeurs du projet GNU passaient leur temps à s'occuper de ces ports et à proposer des nouvelles fonctionnalités aux composants existants, plutôt que de continuer à développer peu à peu les composants manquants. Le GNU Hurd En 1990, le système GNU était presque terminé ; le seul composant principal qui manquait encore à l'appel était le noyau. Nous avions décidé d'implémenter le noyau sous la forme d'une série de processus serveurs qui fonctionneraient au-dessus de Mach. Mach est un micro-noyau développé à l'université Carnegie-Mellon puis à l'université de l'Utah; le GNU Hurd est une série de serveurs (ou une «horde de gnous») qui fonctionnent au-dessus de Mach, et remplissent les diverses fonctions d'un noyau Unix. Le développement a été retardé car nous attendions que Mach soit publié sous forme de logiciel libre, comme cela avait été promis. L'une des raisons qui ont dicté ce choix était d'éviter ce qui semblait être la partie la plus difficile du travail: déboguer un programme de noyau sans disposer pour cela d'un débogueur au niveau du code source. Ce travail avait déjà été fait, dans Mach, et nous pensions déboguer les serveurs du Hurd en tant que programmes utilisateur, à l'aide de GDB. Mais cela prit beaucoup de temps, et les serveurs à plusieurs processus légers, qui s'envoyaient des messages les uns aux autres, se sont révélés très difficiles à déboguer. La consolidation du Hurd s'est étalée sur plusieurs années. Alix À l'origine, le noyau du système GNU n'était pas censé s'appeler Hurd. Son premier nom était Alix - du nom de celle qui à l'époque était l'objet de ma flamme. Administratrice de systèmes Unix, elle avait fait remarquer que son prénom ressemblait aux noms typiques des versions de systèmes Unix; elle s'en était ouverte auprès d'amis en plaisantant : «Il faudrait baptiser un noyau de mon nom.» Je suis resté coi, mais ai décidé de lui faire la surprise d'appeler Alix le noyau du système GNU. Mais les choses ont changé. Michael Bushnell (maintenant, il s'agit de Thomas), le développeur principal du noyau, préférait le nom Hurd, et a confiné le nom Alix à une certaine partie du noyau - la partie qui se chargeait d'intercepter les appels système et de les gérer en envoyant des messages aux serveurs du Hurd. Finalement, Alix et moi mîmes fin à notre relation, et elle a changé de nom; de manière indépendante, le concept du Hurd avait évolué de telle sorte que ce serait la bibliothèque du langage C qui enverrait directement des messages aux serveurs, ce qui a fait disparaître le composant Alix du projet. Mais avant que ces choses ne se produisissent, un de ses amis avait remarqué le nom Alix dans le code source du Hurd, et s'en était ouvert auprès d'elle. Finalement, ce nom avait rempli son office. Linux et GNU/Linux Le GNU Hurd n'est pas encore utilisable de manière intensive. Heureusement, on dispose d'un autre noyau. En 1991, Linus Torvalds a développé un noyau compatible avec Unix et lui a donné le nom de Linux. Aux alentours de 1992, la jonction de Linux et du système GNU, qui était presque complet, a fourni un système d'exploitation libre et complet (ce travail de jonction était lui-même, bien sûr, considérable). C'est grâce à Linux qu'on peut désormais employer une version du système GNU. On appelle cette version du système «GNU/Linux» pour signaler qu'il est composé du système GNU et du noyau Linux. Les défis à venir Nous avons fait la preuve de notre capacité à développer un large spectre de logiciel libre. Cela ne signifie pas que nous sommes invincibles et que rien ne peut nous arrêter. Certains défis rendent incertain l'avenir du logiciel libre; et il faudra des efforts et une endurance soutenus pour les relever, pendant parfois plusieurs années. Il faudra montrer le genre de détermination dont les gens font preuve quand ils accordent de la valeur à leur liberté et qu'ils ne laisseront personne la leur voler. Les quatres sections suivantes discutent de ces défis. Le matériel secret Les fabricants de matériel tendent de plus en plus à garder leurs spécifications secrètes. Cela rend plus difficile l'écriture de pilotes de périphériques libres afin de permettre à Linux et au projet XFree86 de reconnaître de nouveaux matériels. Nous disposons aujourd'hui de systèmes entièrement libres, mais cela pourrait ne plus être le cas dans l'avenir, si nous ne pouvons plus proposer des pilotes pour les ordinateurs de demain. On peut résoudre ce problème de deux manières. Les programmeurs peuvent analyser l'ensemble afin de deviner comment prendre en compte le matériel. Les autres peuvent choisir le matériel qui est reconnu par du logiciel libre; plus nous serons nombreux, plus la politique de garder les spécifications secrètes sera vouée à l'échec. L'ingénierie à l'envers est un travail conséquent ; disposerons-nous de programmeurs suffisamment déterminés pour le prendre en main ? Oui - si nous avons construit un sentiment puissant selon lequel le logiciel libre est une question de principe, et que les pilotes non libres sont inacceptables. Et seronsnous nombreux à dépenser un peu plus d'argent, ou à passer un peu de temps, pour que nous puissions utiliser des pilotes libres ? Oui - si la détermination afférente à la liberté est largement répandue. Les bibliothèques non libres Une bibliothèque non libre qui fonctionne sur des systèmes d'exploitation libres se comporte comme un piège vis-à-vis des développeurs de logiciel libre. Les fonctionnalités attrayantes de cette bibliothèque sont l'appât; si vous utilisez la bibliothèque, vous tombez dans le piège, car votre programme ne peut pas être utilisé de manière utile au sein d'un système d'exploitation libre (pour être strict, on pourrait y inclure le programme, mais on ne pourrait pas l'exécuter en l'absence de la bibliothèque incriminée). Pire encore, si un programme qui utilise une bibliothèque propriétaire devient populaire, il peut attirer d'autres programmeurs peu soupçonneux dans le piège. Ce problème s'est posé pour la première fois avec la boîte à outils Motif, dans les années 80. Même s'il n'existait pas encore de systèmes d'exploitation libres, il était limpide que Motif leur causerait des problèmes, plus tard. Le projet GNU a réagi de deux manières : en demandant aux projets de logiciel libre de rendre l'utilisation de Motif facultative en privilégiant les gadgets de la boîte à outils X, libre, et en recherchant un volontaire pour écrire une solution de remplacement libre à Motif. Ce travail prit de nombreuses années ; LessTif, développé par les Hungry Programmers (les «Programmeurs affamés»), n'est devenu suffisamment étendu pour faire fonctionner la plupart des applications utilisant Motif qu'en 1997. De 1996 à 1998, une compilation conséquente de logiciel libre, le bureau KDE, a fait usage d'une autre bibliothèque non libre de boîte à outils pour l'interface graphique utilisateur, appelée Qt. Les systèmes GNU/Linux libres ne pouvaient pas utiliser KDE, car nous ne pouvions pas utiliser la bibliothèque. Les systèmes GNU/Linux libres ne pouvaient pas utiliser KDE, car nous ne pouvions pas utiliser la bibliothèque. Cependant, certains distributeurs commerciaux de systèmes GNU/Linux n'ont pas été assez stricts pour coller au logiciel libre et ont ajouté KDE dans leurs systèmes - produisant un système disposant d'un plus grand nombre de fonctionnalités, mais souffrant d'une liberté réduite. Le groupe KDE encourageait activement un plus grand nombre de programmeurs à utiliser la bibliothèque Qt, et des millions de «nouveaux utilisateurs de Linux» n'ont jamais eu connaissance du fait que tout ceci posait un problème. La situation était sinistre. La communauté du logiciel libre a répondu à ce problème de deux manières : GNOME et Harmony. GNOME, le GNU Network Object Model Environment (environnement de GNU de modèle d'objets pour le réseau), est le projet de bureau de GNU. Démarré en 1997 par Miguel de Icaza, et développé avec l'aide de la société Red Hat Software, GNOME avait pour but de fournir des fonctionnalités de bureau similaires, en utilisant exclusivement du logiciel libre. Il jouit aussi d'avantages techniques, comme le fait de collaborer avec toute une variété de langages, et de ne pas de se limiter au C++. Mais son objectif principal est la liberté : ne pas imposer l'utilisation du moindre logiciel non libre. Harmony est une bibliothèque compatible de remplacement, conçue pour permettre l'utilisation des logiciels de KDE sans faire appel à Qt. En novembre 1998, les développeurs de Qt ont annoncé une modification de leur licence qui, quand elle sera effective, fera de Qt un logiciel libre. On ne peut pas en être sûr, mais je pense que cette décision est en partie imputable à la réponse ferme qu'a faite la communauté au problème que Qt posait quand il n'était pas libre (la nouvelle licence n'est pas pratique ni équitable, aussi demeure-t-il préférable d'éviter d'utiliser Qt). [Note ultérieure: en septembre 2000, Qt fut distribuée sous la GPL de GNU, ce qui résolvait essentiellement ce problème.] Comment répondrons-nous à la prochaine bibliothèque non libre mais alléchante ? La communauté comprendra-t-elle dans son entier la nécessité de ne pas tomber dans le piège ? Ou serons-nous nombreux à préférer la facilité à la liberté, et à produire un autre problème majeur ? Notre avenir dépend de notre philosophie. Les brevets sur les logiciels La pire menace provient des brevets sur les logiciels, susceptibles de placer des algorithmes et des fonctionnalités hors de portée des logiciels libres pendant une période qui peut atteindre vingt ans. Les brevets sur l'algorithme de compression LZW ont été déposés en 1983, et nous ne pouvons toujours pas diffuser des logiciels libres qui produisent des images au format GIF correctement compressées. En 1998, la menace d'une poursuite pour cause de violation de brevets a mis fin à la distribution d'un programme libre qui produisait des données sonores compressées au format MP3. Il existe plusieurs manières de répondre au problème des brevets: on peut rechercher des preuves qui invalident un brevet, et on peut rechercher d'autres solutions pour remplir une tâche. Mais chacune de ces méthodes ne fonctionne que dans certains cas; quand les deux échouent, il se peut qu'un brevet empêche le logiciel libre de disposer de fonctionnalités souhaitées par les utilisateurs. Que ferons-nous dans ce genre de situation ? Ceux d'entre nous qui prêtent de la valeur au logiciel libre par amour de la liberté continueront à utiliser du logiciel libre dans tous les cas. On pourra travailler sans utiliser de fonctionnalités protégées par des brevets. Mais ceux d'entre nous qui prêtent de la valeur au logiciel libre car ils s'attendent à trouver là des logiciels techniquement supérieurs sont susceptibles de critiquer l'idée même du logiciel libre quand un brevet l'empêchera de progresser plus avant. Ainsi, même s'il est utile de discuter de l'efficacité, dans la pratique, du modèle de développement de type «cathédrale», et de la fiabilité et de la puissance de certains logiciels libres, il ne faut pas s'en tenir là. Il nous faut parler de liberté et de principes. La documentation libre Il ne faut pas chercher les lacunes les plus graves de nos systèmes d'exploitations libres dans le logiciel - c'est l'absence de manuels libres corrects qu'on puisse inclure dans nos systèmes qui se fait le plus cruellement sentir. La documentation est essentielle dans tout paquetage logiciel; quand un paquetage logiciel important ne dispose pas d'un bon manuel libre, il s'agit d'un manque crucial. On en compte de nombreux aujourd'hui. La documentation libre, tout comme le logiciel libre, est une question de liberté, pas de prix encore, les anglais sont victimes de l'absence de mot adéquat pour signifier «libre». La raison manuel libre est très proche de celle d'un logiciel libre: il s'agit d'offrir certaines libertés utilisateurs. Il faut autoriser la redistribution (y compris la vente commerciale), en ligne et sur telle sorte que le manuel puisse accompagner toute copie du programme. N.d.T.: ici d'être d'un à tous les papier, de Il est également crucial d'autoriser les modifications. En règle générale, je ne pense pas qu'il soit essentiel d'autoriser tout un chacun à modifier toutes sortes d'articles et de livres. Je ne pense pas, par exemple, que vous ou moi soyons tenus de donner la permission de modifier des textes comme le présent article, qui expose nos actions et nos idées. Mais il existe une raison particulière, pour laquelle il est crucial de disposer de la liberté de modifier la documentation afférente au logiciel libre. Quand on jouit de son droit de modifier le logiciel, et d'ajouter des fonctionnalités ou de modifier les fonctionnalités présentes, le programmeur consciencieux mettra immédiatement à jour le manuel - afin de fournir une documentation précise et utilisable aux côtés du programme modifié. Un manuel qui n'autorise pas les programmeurs à être consciencieux et à terminer leur travail, ne remplit pas les besoins de notre communauté. Il est acceptable d'apposer certaines limites sur la manière dont les modifications sont faites. Il est par exemple envisageable d'exiger de préserver la notice de copyright de l'auteur original, les conditions de distribution, ou la liste des auteurs. D'exiger que les versions modifiées contiennent une notice qui stipule qu'elles ont été modifiées, et même d'interdire de modifier ou d'ôter des sections entières, pourvu que ces sections ne traitent pas de considérations techniques, ne pose pas non plus de problèmes, car cela n'interdit pas au programmeur consciencieux d'adapter le manuel afin qu'il corresponde au programme modifié par ses soins. En d'autres termes, cela n'empêche la communauté du logiciel libre d'utiliser pleinement le manuel. En revanche, il faut autoriser la modification des portions *techniques* du manuel, et la distribution du résultat de ces modifications par tous les médias habituels, à travers tous les canaux habituels; sans quoi, les restrictions font obstruction à la communauté, le manuel n'est pas libre, et il nous en faut un autre. Les développeurs de logiciels libres seront-ils déterminés, auront-ils conscience du fait qu'il est nécessaire de produire tout un spectre de manuels libres ? Une fois de plus, notre avenir dépend de notre philosophie. Il nous faut faire l'apologie de la liberté On estime aujourd'hui à dix millions le nombre d'utilisateurs de systèmes GNU/Linux et Red Hat Linux de par le monde. Le logiciel libre propose tant d'avantages pratiques que les utilisateurs s'y ruent pour des raisons purement pratiques. Cet état de fait a des développeurs intéressés comptent plus de clients commerciaux, plutôt que conséquences heureuses, qui n'échapperont à personne: on voit plus de par la production de logiciels libres, les entreprises de logiciels libres , et il est plus facile d'encourager les sociétés à développer des logiciels libres des produits logiciels propriétaires. Mais l'intérêt pour le logiciel libre croît plus vite que la prise de conscience de la philosophie sur laquelle il se fonde, et cela provoque des problèmes. Notre capacité à relever les défis et à répondre aux menaces évoqués plus haut dépend de notre volonté à défendre chèrement notre liberté. Pour nous assurer que notre communauté partage cette volonté, il nous faut répandre ces idées auprès des nouveaux utilisateurs au fur et à mesure qu'ils rejoignent notre communauté. Mais nous négligeons ce travail; on dépense bien plus d'efforts pour attirer de nouveaux utilisateurs dans notre communauté qu'on n'en dépense pour leur enseigner l'éducation civique qui lui est attachée. Ces deux efforts sont nécessaires, et il nous faut les équilibrer. «Open Source» En 1998, il est devenu plus difficile de sensibiliser les nouveaux utilisateurs à la notion de liberté dans le logiciel, quand une portion de notre communauté a choisi d'arrêter d'utiliser le terme «Free Software» pour lui préférer la dénomination «Open Source software» N.d.T. : encore et toujours cette ambiguïté de la langue anglaise. «software» signifie «logiciel». «free» signifie à la fois «libre», sens qui est pertinent ici, et «gratuit», qualité qui n'est qu'un effet de bord des logiciels libres. «open source» signifie «dont le code source est ouvert». Certains de ceux qui ont choisi ce nouveau nom avaient en tête de mettre fin à la confusion souvent constatée entre les mots «free» et «gratuit» - ce qui est un objectif valable. D'autres, au contraire, avaient pour objectif de laisser de côté le principe qui a depuis toujours motivé le mouvement du logiciel libre et le projet GNU, afin de cibler les cadres et les utilisateurs professionnels, dont beaucoup ont une idéologie où la liberté, la communauté, et les principes, cèdent le pas aux profits. Ainsi, la rhétorique de l'«Open Source» met l'accent sur le potentiel pour faire du logiciel puissant et de grande qualité, mais occulte délibérément les idées de liberté, de communauté, et de principes. Les magazines «Linux» illustrent clairement cet exemple - ils sont bourrés de publicités pour des logiciels propriétaires qui fonctionnent sur le système GNU/Linux. Quand le prochain Motif ou Qt poindra, ces magazines mettront-ils les programmeurs en garde en leur demandant de s'en éloigner, ou passeront-ils des publicités pour ces produits ? La communauté a beaucoup à gagner de la participation des entreprises; toutes choses étant égales par ailleurs, cette contribution est utile. Mais sacrifier à cette aide les discours traitant de liberté et de principes peut avoir des conséquences désastreuses; cela déséquilibre encore plus la situation précédente, où on voit que l'éducation civique des nouveaux utilisateurs s'avère difficile lorsqu'ils affluent. Les termes «Free Software» et «Open Source» décrivent tous deux plus ou moins la même catégorie de logiciels, mais correspondent à des conceptions différentes du logiciel et des valeurs qui lui sont associées. Le projet GNU continue d'utiliser le terme «Free Software» pour exprimer l'idée que la liberté est plus importante que la seule technique. Jetez-vous à l'eau La philosophie de Yoda (il ne faut pas essayer) est attirante, mais elle ne s'applique pas à moi. J'ai effectué la plupart de mes travaux sans savoir si j'étais capable de les mener à bien, et sans savoir si ces derniers, une fois menés à bien, suffiraient aux buts que je leur avais fixés. Mais j'ai tenté ma chance, car il n'y avait personne d'autre que moi entre l'ennemi et ma cité. À ma grande surprise, j'ai parfois réussi. J'ai parfois échoué; certaines de mes cités sont tombées. Je trouvais alors une autre cité menacée, et je me préparais pour une nouvelle bataille. Avec le temps, j'ai appris à reconnaître les menaces et à m'interposer entre ces dernières et ma cité, en appelant mes amis hackers à la rescousse. Maintenant, il arrive souvent que je ne sois pas seul. C'est pour moi un soulagement et une joie de constater que tout un régiment de hackers se mobilise pour faire front, et je réalise qu'il se peut que cette cité survive pour le moment. Mais les dangers grandissent chaque année, et maintenant la société Microsoft a explicitement pris notre communauté dans son collimateur. L'avenir de la liberté n'est pas un fait acquis. Ne le considérez pas comme tel ! Si vous souhaitez conserver votre liberté, il vous faut vous préparer à la défendre. Comparatif: La sécurité traitée par le logiciel propriétaire et par le libre. Une faille dans Explorer menace le commerce électronique Olivier Ménager, 01 Réseaux, le 06/09/2002 à 19h45 Le 5 août dernier une mauvaise implémentation de SSL dans Internet Explorer a été découverte. Traitée à la légère par Microsoft, la faille est jugée critique mais est restée sans correctif pour l'ensemble des platesformes touchées. Pour les experts en sécurité d'Althes, ce sont des pans majeurs de la sécurité du commerce électronique qui ont été mis en cause. Le 5 août dernier, Mike Benham, jeune développeur de San Francisco envoie à une liste de diffusion dédiée à la sécurité, une description d'une faille d'Internet Explorer (IE) liée à une mauvaise implémentation de SSL (Secure Sockets Layer). SSL est l'un des protocoles de sécurité les plus usités dans le monde du commerce électronique. La conséquence de cette faille est que presque n'importe qui peut se glisser dans une session sécurisée SSL, donc sur un serveur de commerce électronique. Les utilisateurs du navigateur de Microsoft - soit 90 % des internautes - ont ainsi pu être piraté à leur insu, et se voir dérober leurs codes d'accès ou numéro de carte bancaire. D'autant que Microsoft a mis un mois à fournir les premiers correctifs. Le jeune développeur démontre, dans son rapport et sur son site, un problème majeur de sécurité lié à la chaîne de validation de certificats par le navigateur de Microsoft, ce qui rend IE victime de l'attaque de l'« Intercepteur », plus connu sous le nom « The Man in the Middle ». Explorer, une véritable passoire Ainsi, IE (5, 5.5 et 6) accepte à tort une chaîne de certificats, même lorsque le certificat intermédiaire ne dispose pas d'une contrainte de base valide. Or, c'est la contrainte de base qui authentifie le certificat comme étant celui du détenteur de l'URL du site sécurisé. Le navigateur de Microsoft omet tout simplement de vérifier si ce certificat détient ou non une contrainte de base. Le pirate se glisse dans la session sécurisée entre le serveur de commerce électronique et le client, et recrée deux sessions indépendantes de telle sorte que sa présence passe inaperçue. Il peut se contenter de saisir les données qui sont échangées ou bien modifier, au cours d'une autre session, les données personnelles du client (faire un transfert de la banque du piraté vers son compte bancaire, par exemple). Comme l'explique Vincent Royer, directeur technique chez Althès : « Verisign délivre des certificats serveur SSL qui ne contiennent pas nécessairement de contraintes de base ». Et d'ajouter : « Les versions 5.0 et 5.5 de IE valident à tort une chaîne de certificats, y compris celles contenant un certificat intermédiaire dont la contrainte de base est notée comme fausse [Ndlr : ne correspondant pas à l'URL du serveur]. Un pirate peu donc utiliser n'importe quel certificat serveur SSL acheté auprès d'une autorité de certification commerciale reconnue par IE [Entrust,Thwate, etc.], pour fabriquer un faux certificat de serveur SSL. » La sécurité des transactions mise à mal Concrètement, vous pouvez, depuis votre bureau, récupérer un mot de passe et un numéro de carte bancaire d'un collègue qui se connecte à sa banque en ligne au travers d'une session SSL. Sur le site Thoughtcrime.com, la description de l'attaque est complète. « Notre équipe technique a reproduit cette attaque, qui contrairement aux premières assertions de Microsoft, est très simple à mettre en oeuvre », note Gilles Abouy, PDG d'Althès. Si la seule contrainte consiste pour le pirate à se brancher sur le commutateur par lequel transite la session SSL), Vincent Royer note que « l'attaque peut être aussi mise en oeuvre par du spoofing DNS, même si cela est plus compliqué ». Le spoofing DNS consiste à rediriger les internautes à leur insu vers des sites pirates. Pour Vincent Royer « la signature électronique S/MIME est aussi falsifiable, ainsi que la signature Authenticode pour codes mobiles ActiveX ». « Puisqu'aucun avertissement ne prévient l'utilisateur du danger, la confiance apportée par les infrastructures de clefs publiques [PKI], destinées à protéger le commerce électronique contre ce type d'attaque, s'effrite sérieusement », affirme Vincent Royer. Aujourd'hui, 6 septembre, beaucoup de mises à jour dans de nombreuses langues sont désormais disponibles, y compris en français. Reste à les appliquer sur l'ensemble serveurs et postes clients. Tout le monde est touché... Toutes les plates-formes Windows - à partir de Windows 98 - sont touchées. Pour le monde Windows, il est nécessaire de corriger l'API de cryptographie de Microsoft (CryptoAPI). Dans l'univers Apple, MS Office X ou l'édition 2001, Outlook Express 5.0.5, Internet Explorer (version Mac OS 8.1 à 9.x et X) pour Macintosh sont vulnérables. Aucun correctif n'est disponible pour l'heure côté Macintosh et Windows 2000. Ajoutons que pour les utilisateurs de Linu x, le problème a été corrigé en trois jours chrono (week-end inclus) pour KDE Konqueror. Les correctifs commencent à tomber En mars 2002, Bill Gates a lancé le concept de Trustworthy Computing. Objectif : sécuriser les produits de Microsoft avec une formation des développeurs à la sécurité. Entre la théorie et la pratique, Microsoft a du chemin à faire, d'autant que les failles engendrent généralement un effet de domino. Stéphane Sabbague, responsable marketing produits chez Microsoft France rappelle que « pour les produits en cours de développement [notamment la gamme .NET], Microsoft s'est attaqué deux mois durant [en mars et avril dernier] à une revue de code complète ». Le géant de Redmond sait bien que toute faiblesse d'un produit retarde son adoption. Reste que la nécessité de mettre à jour serveurs et postes clients font de cette faille un gigantesque travail pour les administrateurs. Pierre Bugnon, architecte chez Microsoft France, rappelle que le service Software Update Service « permet de reproduire au sein des entreprises l'infrastructure de Windows Update pour simplifier la mise à jour des correctifs de manière centralisée et après validation de l'administrateur ». Notons que Windows Update ne récupère pas encore les Services Packs des produits. En conclusion, il convient de surveiller les nouveaux correctifs mis à disposition par Microsoft. Sun Community Source License Principles by Richard P. Gabriel and William N. Joy Executive Summary Community Source creates a community of widely available software source code just as does the Open Source model, but with two significant differences requested by our licensees, as follows: * compatibility among deployed versions of the software is required and enforced through testing * proprietary modifications and extensions including performance improvements are allowed These important differences and other details make Community Source a powerful combination of the best of the proprietary licensing and the more contemporary open source technology licensing models. In the contemporary world of Internet business, the traditional principles of overly protective software ownership don't make as much sense as they used to. Today it is difficult for a single company to house all the expertise it needs to succeed. Especially when a company wishes to build infrastructure on which other businesses depend, it cannot presume to know how best to do that right out of the chute. The theory of separation of concerns and modularity work well once the dividing lines are known, but finding those lines is a collaborative effort, requiring cooperation between companies. As business practice has matured in the Internet world, it has become clear that there is good reason to expect that companies will be able to know when to cooperate, and so it makes sense to look at how to license software to take advantage of this emerging understanding. The Sun Community Source License (SCSL) is designed to balance the needs of organizations needing to innovate rapidly in order to grow with the needs of those organizations to leverage a community's expertise while maintaining proprietary advantages. Historical Perspective In the recent past there have been two alternative approaches to software licensing: traditional proprietary licensing and Open Source licensing. Open Source licensing is relatively new, being preceded by shareware and free software. Proprietary Licensing Proprietary licensing recognizes primarily binary use licenses which restrict software to execute-only formats, and only those who have bought a license are entitled to use the software. In some cases, the source to the code is available at extra charge and only for limited purposes. In this model, the value of the software is assumed to be contained entirely within that software, and as such, it is to be protected as dearly as any other company asset. Such a model has several advantages, as follows: It provides protection for intellectual property. * It guarantees structured innovation, which is innovation that is planned within a single responsible organization. * It is clear who owns what. On the other hand, proprietary licensing has a number of disadvantages revealed by the pace of Internet business, as follows: * Innovation and releases are scheduled, and the schedule may be ill timed for companies that depend on the software. Further, even when a schedule is acceptable for dependent companies, schedules can slip. * Binary-only products are classical black boxes, and the problem with a black box in an emerging sector is that the wrong things might be in the black box: code with a wrong performance profile, improper resource utilization, or over- or under-generalization. * The quality of the software depends entirely on the owner organization; this can be a problem if the owner organization does not place the same value on quality as the using organization, the owner organization has a different perspective on quality, or if quality resources are not allocated in ways that the using organization needs. In short, the benefits naturally fall out of the observation that proprietary software is completely black box, and that when the boundaries of the black box are optimally placed, the benefits are clear and effective. But if those boundaries are ill-placed or releases are ill-timed, the result is frustration and lost opportunities. Open Source Licensing Open Source licensing recognizes that different organizations have different concerns, and therefore the source code is freely available for any party to do what it will. Open Source licensing grew out of the tradition of shareware and free software, which were movements that embodied political beliefs about what can and cannot be owned. Open Source licensing, on the other hand, does not embody beliefs about ownership aside from recognizing the fact that some organizations wish to own software and others don't. However, Open Source licensing does recognize that certain common elements - for example, infrastructure - are important for a number of parties and that those elements should be freely and openly available. With Open Source licensing, the source code is available for any use, but there are incentives to "give back" to the Open Source community those improvements that are for the common good. Most importantly, the Open Source approach recognizes that the primary value of a piece of software is the expertise represented by the people who developed it. Thus, even when source is out in the open, the value still remains with those who can expertly manipulate it. Such a model has several advantages, as follows: * The code is open with published and, often, specified interfaces. * There are more developers looking and working on the common source code, so there is higher quality and more-rapid innovation. * There is no central owning organization that sets schedules and priorities that might conflict with a using organization's schedules and priorities. * There is a self-organizing effect in which the boundaries between proprietary concerns and community concerns are adaptively set. * A participating organization can reap the benefits of expertise not in its employ. There are disadvantages as well, as follows: * There is no clear control over compatibility issues and there may, therefore, be fragmentation. * There may be no responsible organization. Bugs introduced by another organization may be too difficult for a using organization to fix and of too low priority for the author to fix in a timely manner. * Progress can be chaotic and undirected. * There are limited financial incentives for improvements and innovations, leading commercial developers to use the proprietary model. Community Source License The Community Source licensing model takes the advantages from each of the proprietary and Open Source models and eliminates the disadvantages. In Community Source licensing there is a community of common interests centered around an infrastructure which is provided by a particular organization, called the developing organization. A group of other organizations may join the community, and generally those organizations will have an interest in building businesses around the infrastructure. For example, JiniTM connection technology licensing is based on a community of companies who wish to build and sell devices employing Jini technology. Sun Microsystems is the developing organization which invented, designed, and built the initial Jini technology infrastructure. This infrastructure is network based and provides a mechanism for devices and software services to gather into a spontaneous network of capabilities. The community comprises those who have agreed to the license, and within this community there is a mostly Open Source model of interaction. However, because the members of the community are bound by a common license, intellectual property is maintained and there is no requirement to share openly everything developed for the infrastructure. Moreover, the community comprises only those who have agreed to the license, not the general public. Three levels of participation in the license can be supported, as follows: * Research Use, which is not only for real research - for example, to improve the infrastructure - but for evaluating the technology and prototyping potential products. * Internal Deployment, which is both for (very) limited distribution and for testing before launching a product. * Commercial Use, which is for selling products. Principles The following summarizes the principles behind the design of the Sun Community Source License. Immediate, Open Access In order to encourage members to join the community defined by the license, there is an easy and risk-free way for a company to get access to the infrastructure source code. Any company or developer can become a Research Use licensee with a simple click-through license which grants broad experimentation and evaluation rights. The licensee may use the source code and its specifications in any way whatsoever short of deployment. With a Research Use license, a developer may take any approach to using the source code in order to determine whether the technology can be of use; in fact, the developer can do all the work leading up to deployment with such a license. The license and source code are available through the Net, and so the transition from interest to participation is immediate. Access is clearly open. Increased Innovation In order to increase the rate of innovation, improvements and additions to the original source code may be incorporated into the source code regardless of where they come from. There are two basic types of source code improvements that can be made: improvements to the core technology and improvements or additions to surrounding technology. With Jini connection technology, for instance, there is the basic infrastructure and there are services. Each sort of service - storage services, for example - will have common elements which can be improved by community efforts. In this case, acceptable modifications and additions are determined by the subcommunity of organizations who are working in that area using an open process. In such cases it is expected that change can be very rapid, and indeed, must be in order to gain widespread agreement and deployment. With infrastructure modifications and additions, change is expected to be less rapid because the base of organizations that depend on that infrastructure is large. However, because developers at organizations with different requirements are working with the core technology, over time it is expected that situations will arise that the original developers did not anticipate. These outside developers are able to evolve the technology for their products and markets more rapidly than the original developers would ordinarily be able to do using a traditional proprietary license. In short, there is a spectrum from the innermost portions of the infrastructure where change should be slow and deliberate to the outermost portions - which might represent applications - where change should be as rapid as the market requires. Increased Work Force In order to increase the effective work force, participation is not limited: Any organization can participate in the Research Use License without paying or negotiation. Increased Quality Simply stated, with more eyes looking at the code, there is more chance that errors will be caught and repaired, particularly when that code is used in situations and contexts not anticipated by the original developers and researchers. It might be thought that with an Open-source type of model there would be increased likelihood of errors in code, but the Open Source experience is largely the opposite - that because the source is published, developers are generally very careful while developing code in order to avoid public embarrassment. Moreover, the test code is also covered by the license, and the benefits of a larger community working accrue to the test suite as well as to the target technology. Faster Commercialization The Internal Deployment License makes the transition to commercial use easy. Once the technology has been evaluated and adapted through the Research License it can be deployed internally by conforming to the related test suites and specifications. In some cases we expect that Internal Deployment will be allowed without a fee, as it is for the core of the Jini connection technology. The Internal Deployment License is made available with the Research Use License, which means it is also immediate and easy. The Commercial License is tailored to provide a dependable platform for all third parties and to provide revenues to the developing organization, which can be used to fund both support for the entire community of licensees and also further development. Access to Students Researchers, teachers, and their students are particularly attuned to using technology at its limits, and therefore such people are especially encouraged to participate by special conditions of the SCSL. It is easy to use the source code in laboratories and in the classroom. Protection for Intellectual Property Licensees rightly enter into the community expecting that their intellectual property rights will be respected. Therefore it is not required that a participant give up intellectual property rights when joining the community. In order that the community remain open, however, the SCSL does require that any programming interfaces which extend the platform or infrastructure technology be open and specified, even while implementations and intellectual property embedded in the implementations may be held proprietary. The Best of Both Worlds The Sun Community Source License blends the best aspects of the proprietary and Open Source license models. The SCSL was designed to support a developing organization and a surrounding community of participants. The developing organization is generally building an infrastructure that will spawn a number of new marketplaces or business opportunities for the community of participants. The developing organization might itself act also as an ordinary participant in the community if, for example, that organization desires to take advantage of a new marketplace or business opportunity. Nevertheless, the two roles are separated in the SCSL. The developing organization deserves to reap some benefits for developing the infrastructure, and the SCSL recognizes that. The following lists the benefits of the SCSL that are shared with or derived from the proprietary model: * It provides protection for intellectual property. * While error corrections to the licensed technology must be given back to the community, other modifications can remain proprietary at the discretion of the participating organization that created them. * It guarantees structured innovation within a single responsible organization. * The developing organization is responsible for the original code base and the community is responsible for the contributed portions. Ultimately, the developing organization is responsible for the entire source code base including moving it forward. It is clear who owns what. * The infrastructure part of the original code and upgrades to it are owned by the developing organization and shared with the community. Error corrections are required to be given back to the community by all licensees. Community members may contribute shared modifications to the community, granting rights to the community to use these modifications, including intellectual property, specifications, and test suites. * Licensees may make modifications, such as performance enhancements or platform adaptations which are compatible with the licensed technology, or make extensions - these modifications and extensions may be kept proprietary, though extensions are required to have open interfaces. * There is clear control over compatibili