par Richard Stallman
(Version du 24 avril 1992)
L'existence de logiciels soulève forcément la question de la façon dont devraient être prises les décisions concernant leur usage. Par exemple, supposons qu'une personne ayant une copie d'un programme, rencontre une autre personne qui en voudrait une copie. Il est possible pour eux de copier le programme; qui devrait décider si c'est possible? Les personnes elles-mêmes? Ou une tierce personne, son «propriétaire»?
Les développeurs de logiciels considèrent typiquement que le critère de réponse supposé est la maximisation de leurs profits. Le pouvoir politique des affaires a poussé le gouvernement à adopter à la fois ce critère et la réponse proposée par les développeurs : c'est-à-dire qu'un programme a un propriétaire, en général une société associée à son développement.
J'aimerais considérer la même question en utilisant un critère différent : la prospérité et la liberté du public en général.
Cette réponse ne peut pas être décidée par la loi actuelle - la loi devrait se conformer à la morale, pas l'inverse - ni par l'usage, bien qu'ils puissent suggérer des réponses possibles. La seule façon d'en juger, est d'observer qui bénéficie et qui est lésé en reconnaissant un propriétaire au logiciel, pourquoi et dans quelle mesure. En d'autres termes, nous devrions en évaluer le pour et le contre pour la société dans son ensemble, en prenant en compte aussi bien la liberté individuelle que la production de biens matériels.
Dans cet article, je décrirai les effets d'avoir des propriétaires, et je montrerai que les résultats sont préjudiciables. Ma conclusion est que les programmeurs ont le devoir d'encourager les autres à partager, distribuer, étudier et améliorer les logiciels que nous écrivons : autrement dit, d'écrire des logiciels libres.(1)
Ceux-là, qui bénéficient du système actuel où les programmes sont propriétaires, proposent deux arguments en leur faveur : l'argument affectif et l'argument économique.
L'argument affectif ressemble à ceci : «j'ai mis ma sueur, mon coeur, mon âme dans ce programme. Il vient de moi, c'est le mien!»
Cet argument ne nécessite pas de réfutation sérieuse. Les programmeurs peuvent cultiver ce sentiment de possession quand ça les arrange; ce n'est pas inévitable. Considérez, par exemple, comment ces mêmes programmeurs cèdent volontiers leurs droits à une grosse entreprise moyennant salaire; mystérieusement, l'attachement affectif disparaît. Faites le contraste avec ces grands artistes et artisans des temps médiévaux, qui ne signaient même pas de leur nom leurs travaux. Pour eux, le nom de l'artiste n'avait pas d'importance. Ce qui importait, c'était que le travail, et son but afférent, aient été faits. Cette façon de voir à prévalu pendant des centaines d'années.
L'argument économique est du style : «je veux devenir riche» (ce qui en général, se dit incorrectement «je veux gagner ma vie»), et si vous ne me permettez pas de devenir riche en programmant, eh bien je ne programmerai pas. Comme tout le monde me ressemble, personne n'écrira de programmes. Et vous serez coincés, car pas de programme du tout!» Cette menace est généralement déguisée en conseil amical venant de la bouche d'un sage.
J'expliquerai plus tard pourquoi cette menace est du bluff. J'aimerai d'abord mettre le doigt sur une supposition implicite qui est plus évidente dans une autre formulation de l'argument.
Cette formulation part de la comparaison entre l'utilité sociale d'un programme propriétaire et celle où il n'y a pas de programme, pour alors conclure que le développement de logiciels propriétaires est, globalement, bénéfique et qu'il devrait être encouragé. L'erreur, ici, vient de ne comparer que deux résultats - logiciel propriétaire contre pas de logiciel - et de supposer qu'il n'y a pas d'autres possibilités.
Dans un système reconnaissant la propriété intellectuelle, le développement logiciel est habituellement lié à l'existence d'un propriétaire qui contrôle l'utilisation du logiciel. Tant que ce lien existe, nous devons souvent faire face au choix d'un programme propriétaire ou pas de programme. Cependant, ce lien n'est pas inhérent ou inévitable; c'est une conséquence d'une décision politique, légale et sociale spécifique, que nous contestons : la décision qu'il y ait des propriétaires. Formuler le choix entre logiciel propriétaire contre pas de logiciel, c'est faire une pétition de principe.
La question qu'il faut poser, c'est : «Est-ce que le développement de logiciels doit être lié à un propriétaire qui en restreint l'usage?»
Pour pouvoir en décider, il nous faut juger chaque effet des deux activités suivantes sur la société, indépendamment : l'effet du développement de logiciels (indépendamment de ses termes de diffusion), et l'effet de la restriction de son emploi (supposant que le logiciel ait été développé). Si l'une de ces activités est utile et l'autre nocive, nous devrions les dissocier et nous lancer uniquement dans la première.
En d'autres termes, si restreindre la distribution d'un logiciel déjà développé est préjudiciable à la société dans son ensemble, alors un développeur moral rejettera cette activité.
Pour déterminer l'effet de la restriction du partage, nous avons besoin de comparer la valeur, pour la société, d'un programme restreint (par ex. propriétaire) avec le même programme, mais disponible pour tout le monde. Ce qui signifie comparer deux mondes possibles.
Cette analyse met aussi en exergue le simple contre-argument qui est parfois soulevé que «le bénéfice pour le voisin en lui donnant une copie d'un logiciel est annulé par le préjudice fait au propriétaire». Ce contre-argument suppose que les inconvénients et bénéfices sont équivalents dans leur ampleur. L'analyse implique de comparer ces étendues et elle montre que les bénéfices sont bien plus importants.
Pour mettre en lumière cet argument, prenons un autre domaine d'application : la construction routière.
Il serait possible de financer la contruction de toutes les routes avec des péages. Ce qui entraînerait d'avoir des postes de péage à tous les coins de rues. Un tel système inciterait grandement à améliorer l'état des routes. Il aurait aussi comme vertu de faire payer l'usager de la route concernée. Cependant, le péage n'est qu'une entrave artificielle à la fluidité du trafic, artificielle dans le sens où elle n'est pas une conséquence du fonctionnement des routes et des voitures.
Si on compare les routes avec ou sans péage, nous voyons que (si tout se déroule normalement) les routes sans péage sont meilleur marché à construire et à maintenir, plus sûres et plus efficaces à emprunter. (2) Dans les pays pauvres, les postes de péage rendent les routes inaccessibles à bien des citoyens. Les routes sans péage offrent ainsi plus de bénéfices à moindre coût ; elles sont préférables pour la société. C'est pourquoi la société devrait trouver d'autres moyens de financer les routes, sans recourir aux péages. L'usage des routes, une fois construites, devrait être libre.
Quand les partisans des postes de péage les proposent comme étant simplement une façon de lever des fonds, ils déforment le choix offert. Les postes de péage, effectivement, permettent de récolter des fonds, mais elles occasionnent aussi autre chose : elles dégradent les routes. La route à péage n'est pas aussi bonne que celle sans péage; nous donner plus de routes ou supérieures sur le plan technique, n'est peut-être pas une amélioration si cela signifie substituer aux routes gratuites des routes à péage.
Bien entendu, construire des routes sans péage coûte de l'argent, que, d'une façon ou d'une autre, le public doit payer. Mais ce n'est pas ce qui, inévitablement, implique des postes de péage. Nous, qui dans un cas comme dans l'autre, devrons payer, aurons tout intérêt pour notre porte-monnaie à acheter des routes sans péage.
Je ne suis pas en train de dire que les routes à péage sont pires que pas de route du tout. Ce serait vrai si les péages étaient tels que presque personne n'emprunterait la route - mais ce n'est pas une politique plausible pour un collecteur de péage. Cependant, tant que les postes de péage causeront des gaspillages et des inconvénients significatifs, il est plus avantageux de lever des fonds de façon moins obstructive.
Pour appliquer ce même argument au développement logiciel, je vais maintenant montrer que d'avoir des «postes de péage» sur des logiciels utiles, coûte cher à la société : cela rend le programme plus coûteux à élaborer, plus cher à distribuer et moins satisfaisant et efficace à utiliser. Je poursuivrai en disant que la construction du programme devra être encouragée autrement. Puis je m'attacherai à présenter d'autres méthodes d'encouragement et de financement du développement logiciel (dans la mesure réellement nécessaire).
Considérez un instant un programme qui a été développé et dont tous les financements nécessaires à son élaboration ont été pris ; maintenant, la société doit faire le choix entre le rendre propriétaire ou le rendre libre d'utilisation et de partage. Supposez qu'il est désiré que ce programme existe et soit disponible.(3)
Les restrictions sur la distribution et la modification du programme ne facilitent pas son utilisation. Elles ne peuvent qu'interférer. Ainsi, l'effet ne peut avoir qu'un impact négatif. Mais jusqu'à quel point? Et de quelle manière?
On distingue trois niveaux de préjudice matériel dans ce genre d'entrave :
Chaque niveau de préjudice matériel est concomitant à un préjudice psycho-social. Cela se réfère aux effets qu'ont les décisions des gens sur leurs sentiments, attitudes et prédispositions futurs. Ces changements dans la façon de penser des gens auront par la suite un effet sur leurs relations avec leurs concitoyens et peuvent avoir des conséquences matérielles.
Les trois niveaux de préjudice matériel gaspillent une partie de la valeur que le programme pourrait offrir, mais ne peuvent la réduire à zéro. S'ils gaspillent la presque totalité de la valeur du programme, alors l'écriture du programme cause du tort à la société, au plus à hauteur de l'effort qu'il a fallu fournir pour écrire ce programme. En effet, un programme dont la vente génère des profits fournit sûrement un net bénéfice matériel direct.
Cependant, tenant compte des préjudices psycho-sociaux concomitants, il n'y a pas de limite au préjudice que peut provoquer le développement d'un logiciel propriétaire.
Le premier niveau de préjudice gêne le simple emploi d'un programme. Une copie d'un programme a pratiquement un coût marginal de zéro (et ce prix, vous pouvez le payer en faisant le travail vous-même), ce qui veut dire que, dans un marché libre, elle aurait un prix avoisinant zéro. Une taxe via une licence est un découragement significatif à l'utilisation d'un programme. Si un logiciel largement utile est propriétaire, beaucoup moins de gens l'utiliseront.
Il est facile de montrer que la contribution totale d'un programme à la société est réduite si on lui assigne un propriétaire. Chaque utilisateur potentiel du logiciel, face à la nécessité de le payer pour l'utiliser, peut choisir de payer ou de renoncer à son usage. Si un utilisateur fait le choix de payer le programme, il y a un simple transfert de richesses entre deux parties. Mais chaque fois qu'une personne choisit d'outrepasser l'utilisation du programme, cela cause du tort à cette personne sans que quelqu'un y trouve son compte. La somme de nombres négatifs avec zéro, ça doit être négatif...
Mais cela ne réduit pas la somme de travail qu'il faut pour développer le programme. Donc l'efficacité du processus, calculée en divisant la satisfaction des utilisateurs par le coût du développement, en est diminuée.
Ceci reflète la différence cruciale entre la copie de programmes et celle de voitures, de chaises ou de sandwiches. À part dans la science-fiction, il n'existe pas de machine pouvant reproduire les objets matériels. Mais les programmes sont faciles à copier; n'importe qui peut faire autant de copies que nécessaire, sans gros effort. Ce qui n'est pas vrai dans le cas des objets matériels, vu que la matière est conservée : chaque copie nécessite des matières premières, tout comme la première.
En ce qui concerne les objets matériels, décourager leur usage est logique, car moins d'objets signifie moins de matières premières, moins de travail pour les construire. C'est vrai qu'il faut un coût pour démarrer, pour développer, coût réparti sur l'ensemble de la production. Mais tant que le coût marginal est significatif, y ajouter un pourcentage des coûts de développement ne provoque pas de différence qualitative. Et cela ne nécessite pas de restrictions sur la liberté des utilisateurs.
Cependant, imposer un prix à quelque chose qui, autrement, aurait pu être gratuit, c'est un changement qualitatif. Une taxe imposée, centralisée, sur la distribution de logiciels devient fortement décourageante.
De plus, la production centrale, telle qu'elle est pratiquée de nos jours, est inefficace, y compris dans son rôle de fournisseur de copies de logiciels. Ce système implique d'empaqueter des disquettes ou des bandes dans un emballage superflu, de les envoyer en nombre dans le monde entier puis de les stocker avant leur vente. Ces coûts sont présentés comme étant le prix à payer pour faire des affaires; en vérité, ils font partie du gaspillage causé par la présence d'un propriétaire.
Supposons que vous et votre voisin trouviez utile de faire tourner un certain programme. Dans un souci moral pour votre voisin, vous devriez sentir que la façon correcte d'appréhender la situation, est de permettre une utilisation de ce logiciel par vous deux. S'il n'y avait la possibilité que pour un seul d'entre vous de faire tourner ce programme, il y aurait division; ni vous, ni votre voisin ne trouveriez cela acceptable.
Signer un accord de licence logicielle typique revient à trahir votre voisin : «je fais la promesse de priver mon voisin de ce programme, ainsi je peux en avoir une copie pour moi-même». Les gens qui font de tels choix ressentent une pression psychologique interne pour se justifier, en diminuant l'importance d'aider leur voisin - c'est comme cela que le sens civique souffre. C'est un préjudice psycho-social associé au préjudice matériel de décourager l'utilisation du logiciel.
Beaucoup d'utilisateurs reconnaissent inconsciemment le tort de refuser le partage; ils décident alors d'ignorer les licences et les lois, et de partager tout de même les programmes. Mais ils s'en sentent souvent coupables. Ils savent qu'ils doivent enfreindre la loi pour être de bons voisins, mais ils continuent de penser que les lois font autorité et concluent qu'être un bon voisin (ce qu'ils sont), c'est vilain et honteux. C'est aussi une forme de préjudice psycho-social, mais on peut y échapper en prenant la décision que ces licences et ces lois n'ont pas de force morale.
Les programmeurs souffrent aussi de préjudices psycho-sociaux, sachant que bien des usagers ne pourront utiliser leurs travaux. Ceci conduit à une attitude de cynisme ou de dénégation. Un programmeur peut faire une description enthousiaste du travail qu'il pense techniquement excitant; puis, quand on lui demande «Est-ce qu'il me sera permis de l'utiliser?», son visage se ferme et il doit bien admettre que non. Pour éviter de se sentir découragé, soit il ignore ce fait la plupart du temps, soit il adopte une attitude cynique afin d'en minimiser l'importance.
Depuis la période reaganienne, la plus grande pénurie, aux États-Unis, ce n'est pas l'innovation technique, mais plutôt la volonté de travailler ensemble pour le bien public. Cela n'a pas de sens d'encourager l'un au détriment de l'autre.
Le deuxième niveau de préjudice matériel est l'impossibilité d'adapter les programmes. La facilité de modification du logiciel est un de ses grands avantages sur les technologies plus anciennes. Mais la plupart des logiciels commerciaux ne peuvent être modifiés, même après les avoir achetés. Ils sont à prendre ou à laisser, comme une boîte noire, un point c'est tout.
Un programme que vous pouvez exécuter se compose d'une série de nombres dont le sens est obscur. Personne, même un bon programmeur, ne peut aisément changer les nombres afin que le logiciel exécute autre chose.
Normalement, les programmeurs travaillent sur le «code source» d'un programme, écrit dans un langage de programmation comme le Fortran ou le C. Ils utilisent des noms pour désigner les données utilisées et des parties du programme, et ils représentent les opérations par des symboles comme le «+» pour une opération ou le «-» pour une soustraction. Le langage est conçu pour aider les programmeurs à déchiffrer et modifier les programmes. Voici un exemple : il s'agit d'un programme qui calcule la distance entre deux points d'un plan :
float
distance (p0, p1)
struct point p0, p1;
{
float xdist = p1.x - p0.x;
float ydist = p1.y - p0.y;
return sqrt (xdist * xdist + ydist * ydist);
}
Voici le même programme sous sa forme exécutable, sur l'ordinateur que j'utilise habituellement :
1314258944 -232267772 -231844864 1634862
1411907592 -231844736 2159150 1420296208
-234880989 -234879837 -234879966 -232295424
1644167167 -3214848 1090581031 1962942495
572518958 -803143692 1314803317
Le code source est utile (au moins potentiellement) pour chaque utilisateur d'un programme. Mais la plupart des utilisateurs n'ont pas la permission d'avoir des copies du code source. Normalement, le code source d'un programme propriétaire est tenu secret par son propriétaire, empêchant quiconque d'en apprendre quelque chose. L'utilisateur reçoit simplement des fichiers de nombres incompréhensibles que l'ordinateur exécutera. Cela signifie que seul le propriétaire du logiciel peut changer le programme.
Un jour, une amie me dit qu'elle travaillait comme programmeur dans une banque depuis environ six mois, écrivant un programme similaire à quelque chose de commercialement disponible. Elle croyait que, si elle avait accès au code source de ce programme commercial, elle pourrait facilement l'adapter à ses besoins. La banque souhaitait payer pour cela, mais elle n'y fut pas autorisée - le code source était un secret. Elle a dû alors travailler d'arrache-pied pendant six mois, un travail qui compte pour le PNB, mais qui était en fait du gaspillage.
Le Laboratoire d'Intelligence Artificielle du MIT reçut une imprimante graphique comme cadeau de la part de Xerox, aux alentours de 1977. Elle était pilotée par un logiciel libre, auquel nous avons ajouté de nombreuses caractéristiques bien commodes. Par exemple, le logiciel avertissait immédiatement l'utilisateur de la fin du processus d'impression. Si l'imprimante venait à rencontrer un problème, comme un bourrage ou un manque de papier, le programme avertissait de suite tous ceux qui avaient des travaux d'impression en cours. Ces fonctionnalités facilitaient la vie.
Plus tard, Xerox offrit au labo d'IA une nouvelle imprimante, plus rapide, une des premières laser. Elle était pilotée par un logiciel propriétaire qui tournait sur un poste dédié et séparé, nous ne pouvions donc ajouter aucune de nos fonctionnalités favorites. On pouvait s'arranger pour envoyer un message quand le travail d'impression se lançait sur le poste dédié, mais pas quand celui-ci se faisait effectivement (et les délais étaient habituellement importants). Il n'y avait aucun moyen de savoir si l'impression était faite; il fallait deviner. Et personne n'était informé d'un bourrage papier, l'imprimante attendait ainsi souvent une heure avant d'être rechargée.
Les programmeurs système du labo d'IA étaient capables de corriger de tels problèmes, probablement tout aussi capables que les auteurs du programme. Xerox n'avait pas envie de les corriger et choisit de nous en empêcher, nous avons donc été forcés de subir les problèmes. Ils n'ont jamais été corrigés.
La plupart des bons programmeurs ont fait l'expérience de cette frustration. La banque pouvait se permettre de résoudre son problème en écrivant un nouveau programme depuis le début, mais un utilisateur lambda, quelle que soit son habileté, ne peut que laisser tomber.
Laisser tomber provoque un préjudice psycho-social - sur l'esprit d'indépendance. C'est démoralisant d'habiter une maison qu'on ne peut réarranger selon ses besoins. Cela conduit à la résignation et au découragement, ce qui peut gagner d'autres aspects de la vie. Les gens qui se sentent ainsi ne sont pas heureux et ne font pas du bon travail.
Imaginez ce que ce serait si les recettes étaient logées à la même enseigne que les logiciels. Vous vous diriez «Voyons, comment modifier cette recette pour qu'il n'y ait plus de sel?», et le chef cuistot de vous répondre «Comment oses-tu insulter ma recette, fruit de mon cerveau et de mon palais, en tentant de la modifier? Tu n'as pas le jugement pour changer ma recette afin qu'elle marche mieux.»
«Mais mon docteur m'a recommandé de ne pas manger salé. Que puis-je faire? Pouvez-vous en ôter le sel pour moi?»
«Je serais heureux de le faire; mes honoraires ne sont que de 50000 dollars». À partir du moment où le propriétaire a le monopole sur les modifications, les honoraires tendent à gonfler. «De toute façon, je n'ai pas le temps maintenant. Je suis pris par une commission afin de créer une nouvelle recette de biscuits marins pour le Département de la Marine. Je reprendrai contact avec toi d'ici à peu près deux ans».
Le troisième niveau de préjudice matériel touche le développement logiciel. Il était autrefois un processus évolutif, où quelqu'un prenait un programme existant et en réécrivait une partie pour ajouter une nouvelle fonctionnalité; puis une autre personne en réécrivait aussi une partie pour y ajouter une autre fonctionnalité. Dans certains cas, cela a continué ainsi sur une période d'une vingtaine d'années. Entre-temps, certaines parties du programme auront été «cannibalisées» pour créer les prémices d'autres programmes.
L'existence de propriétaires empêche ce genre d'évolution, rendant nécessaire de repartir de rien si on veut développer un programme. Cela empêche également les nouveaux praticiens d'étudier les programmes existants pour en apprendre des techniques utiles ou même apprendre comment on structure de gros programmes.
Les propriétaires entravent aussi l'éducation, l'apprentissage. J'ai rencontré de brillants étudiants en informatique qui n'avaient jamais vu le code source d'un gros logiciel. Ils peuvent être bons à écrire de courts programmes, mais ils ne peuvent commencer à apprendre les techniques différentes de l'écriture d'un vaste programme, s'ils ne peuvent observer comment d'autres l'ont fait.
Dans tout domaine intellectuel, on peut atteindre de plus grandes hauteurs en se tenant sur les épaules des autres. Mais ce n'est généralement plus permis dans le domaine logiciel - vous ne pouvez vous tenir sur les épaules que de ceux qui font partie de votre propre compagnie.
Le préjudice psycho-social qui s'y rattache affecte l'esprit de coopération scientifique, qui était autrefois si fort que les scientifiques coopéraient même quand leurs pays étaient en guerre. C'est dans cet esprit que les océanographes japonais, abandonnant leur labo dans une île du Pacifique, ont soigneusement conservé leurs travaux pour les Marines qui commençaient à débarquer, et laissèrent un mot leur demandant d'en prendre bien soin.
Les conflits de profits ont détruit ce que les conflits internationaux avaient épargné. Aujourd'hui, les scientifiques de nombreuses disciplines ne donnent pas assez de détails dans leurs publications, qui permettraient aux autres de reproduire leur expérience. Ils ne publient que ce qui permet au lecteur d'être impressionnés par l'étendue de leurs travaux. C'est particulièrement vrai pour la recherche informatique, où le code source des programmes décrits dans les publications est en général secret.
J'ai parlé des effets d'empêcher les gens de copier, de modifier ou de se baser sur un programme existant. Je n'ai pas précisé comment cette obstruction était réalisée, car cela n'affecte pas la conclusion. Que ce soit par protection contre la copie, copyright, licences, cryptage, cartes ROM ou encore un numéro de série sur le matériel, si cela réussit à empêcher l'utilisation, alors il y a préjudice.
Les utilisateurs considèrent certaines de ces méthodes comme plus odieuses que d'autres. Je suggère que les méthodes les plus détestées sont celles qui accomplissent leur objectif.
J'ai montré comment le fait d'être propriétaire d'un programme, le pouvoir de restreindre sa modification ou sa copie, est une entrave. Ses retombées négatives sont vastes et importantes. Il s'ensuit que la société devrait se passer de propriétaires de logiciels.
Une autre façon de comprendre cela, est que ce dont a besoin la société, c'est de logiciels libres et que les logiciels propriétaires ne sont qu'un pauvre substitut. Encourager le substitut n'est pas une façon rationnelle d'obtenir ce dont nous avons besoin.
Vaclav Havel nous a conseillé de «travailler pour une chose parce qu'elle est bien, pas parce qu'elle a des chances de réussir». Un marché créant des logiciels propriétaires a des chances de réussir selon son propre point de vue, mais ce n'est pas ce qui est bon pour la société.
Si nous éliminons la propriété intellectuelle comme un moyen d'encourager les gens à développer des logiciels, au début, peu de programmes seront développés, mais ils seront plus utiles. Difficile de dire si la satisfaction d'ensemble des utilisateurs sera moindre. Mais si c'est le cas, ou si nous voulons malgré tout l'augmenter, il y a d'autres moyens d'encourager le développement, tout comme il y a des alternatives aux postes de péage pour tirer de l'argent des routes. Mais avant de parler de la façon dont cela peut se faire, je vais d'abord me demander dans quelle mesure un encouragement artificiel est vraiment nécessaire.
Certains domaines professionnels trouvent peu de candidats, sauf pour l'argent; la construction routière, par exemple. Il en est d'autres, touchant aux études ou à l'art, dans lesquelles il y a peu de chance de devenir riche, mais où les gens s'engagent par fascination ou à cause de sa valeur perçue pour la société. On peut y inclure par exemple, les mathématiques logiques, la musique classique et l'archéologie; puis l'organisation politique au sein des travailleurs. Les gens concourent, plus tristement qu'âprement, pour les quelques situations assises disponibles, aucune d'entre elles n'étant vraiment bien solide. Ils paieraient pour avoir la chance de travailler dans un de ces domaines, s'ils le pouvaient.
Un domaine peut se transformer du jour au lendemain, s'il commence à offrir la possibilité de devenir riche. Si un travailleur devient riche, les autres réclament la même opportunité. Bientôt tous demanderont de fortes sommes d'argent pour ce qu'ils avaient l'habitude de faire pour le plaisir. Puis quelques années passent, chaque personne en relation avec ce domaine tournera en dérision l'idée que le travail pourrait être fait sans salaires mirobolants. Ils conseilleront aux acteurs sociaux de s'assurer que de tels salaires soient possibles, en prescrivant des privilèges spéciaux et les pouvoirs, monopoles nécessaires pour que cela puisse se faire.
Ce changement est apparu dans le domaine de la programmation cette dernière décennie. Il y a quinze ans, des articles parlaient d'«accros à l'informatique» : les utilisateurs étaient «connectés» et vivaient modestement. Il était généralement compris que les accros de la programmation pouvaient briser leur couple. Aujourd'hui, il est généralement admis que personne ne ferait de la programmation, sans salaire élevé. Les gens ont oublié ce qu'ils savaient il y a quinze ans.
Même si à un moment précis, la plupart des gens travailleront dans un certain domaine uniquement pour un haut salaire, cela ne durera pas forcément. La tendance peut s'inverser, si la société donne une impulsion. Si nous laissons de côté les possibilités de gros gains, peu de temps après, quand les gens auront réajusté leurs attitudes, ils auront à nouveau à coeur de travailler dans leur domaine pour la joie de le faire.
La question «comment payer un programmeur» devient plus simple, quand nous réalisons que ce n'est pas la peine de les payer une fortune. Il est plus facile de leur assurer un niveau de vie correct sans plus.
Les institutions qui payent les programmeurs n'ont pas besoin d'être des «boîtes à logiciels». Beaucoup d'autres institutions existantes peuvent le faire.
Les constructeurs de matériels informatiques pensent qu'il est essentiel de supporter le développement logiciel, même s'ils ne peuvent contrôler l'usage du logiciel. En 1970, la plupart de leurs logiciels étaient libres, car ils ne pensaient pas à les entraver. Aujourd'hui, la volonté croissante de se joindre à des consortiums montre leur compréhension que de posséder le logiciel n'est pas ce qui est vraiment important pour eux.
Les universités mènent de nombreux projets de programmation. Aujourd'hui, elles en vendent souvent les résultats, mais, dans les années 70, elles ne le faisaient pas. Douterait-on que les universités développeraient des logiciels libres si elles n'étaient pas autorisées à vendre des logiciels? Ces projets pourraient recevoir le soutien de contrats gouvernementaux et de bourses qui soutiennent actuellement le développement de logiciels propriétaires.
Il est commun de nos jours que les chercheurs universitaires reçoivent une bourse pour développer un système, qu'ils le développent presque jusqu'à la finalisation, qu'ils le déclarent «fini», puis qu'ils créent des sociétés où ils le finiront effectivement et le rendront utilisable. Parfois, ils déclarent «libre» la version non terminée; s'ils sont vraiment corrompus, ils obtiendront une licence exclusive de la part de l'université. Ce n'est pas un secret, c'est ouvertement admis par les personnes concernées. Pourtant, si les chercheurs n'étaient pas exposés à ces tentations, ils continueraient quand même leurs recherches.
Les programmeurs qui écrivent des logiciels libres peuvent gagner leur vie en vendant des services liés au logiciel. J'ai reçu des honoraires pour le portage du compilateur GNU C sur un nouveau matériel et pour faire des extensions d'interfaces utilisateurs pour GNU Emacs. (J'ai offert ces améliorations au public, une fois qu'elles ont été réalisées). Je suis aussi payé pour enseigner dans des classes.
Je ne suis pas seul à travailler de cette façon; il existe maintenant une entreprise fructueuse, grandissante qui ne fait pas autrement. Plusieurs autres compagnies offrent aussi un support commercial aux logiciels libres issus du système GNU. C'est le début d'une industrie indépendante du support du logiciel libre, une industrie qui pourrait prendre de fortes proportions, si le logiciel libre devenait courant. Elle offre aux utilisateurs des options qui sont généralement indisponibles dans le cas de logiciels propriétaires, sauf pour les plus riches.
De nouvelles institutions, comme la Free Software Foundation, peuvent aussi financer les programmeurs. La majorité des fonds de la Fondation vient de l'argent récolté dans la vente de bandes par correspondance. Le logiciel présent sur la bande est libre, ce qui signifie que chaque utilisateur est libre de le copier et de le modifier, mais néanmoins, beaucoup payent pour en obtenir des copies. (Rappelez-vous que «free software» veut dire libre, et non gratuit). Certains utilisateurs achètent des bandes, alors qu'ils en possèdent déjà, simplement parce qu'ils sentent que nous méritons cette contribution. La Fondation reçoit aussi des donations considérables de la part de fabricants d'ordinateurs.
La Free Software Foundation est une organisation caritative et ses revenus sont dépensés en employant le plus possible de programmeurs. Si elle avait été érigée en business, distribuant les mêmes logiciels libres au public pour la même somme, elle pourrait maintenant offrir un très bon niveau de vie à son fondateur.
Parce que la Fondation est une organisation caritative, les programmeurs travaillent souvent pour la moitié de qu'ils pourraient toucher ailleurs. Ils le font parce qu'ils sont libres de toute bureaucratie et parce qu'ils ressentent de la satisfaction à savoir que leur travail pourra être utilisé par tous. Et, par-dessus tout, ils le font parce que programmer, c'est passionnant. Ajoutons que des volontaires nous ont écrit nombre de programmes (même des rédacteurs techniques ont récemment commencé à se proposer).
Ce qui confirme que la programmation est parmi les domaines les plus fascinants, au même titre que la musique et les arts. Nous n'avons pas à craindre que plus personne ne veuille programmer.
Il y a une bonne raison à ce que les utilisateurs de logiciels se sentent obligés moralement à contribuer à leur soutien. Les développeurs de logiciels libres contribuent à l'activité des utilisateurs, c'est à la fois loyal et - sur le long terme - aussi dans l'intérêt des utilisateurs que de les financer.
Cependant, ceci ne s'applique pas aux développeurs de logiciels propriétaires, vu que l'obstructionnisme appelle plutôt une sanction qu'une récompense.
Nous nous trouvons ainsi face à un paradoxe : le développeur de logiciels utiles a droit au soutien des utilisateurs, mais n'importe quelle tentative de transformer cette obligation morale en une exigence, détruit les bases de l'obligation. Un développeur peut soit recevoir une récompense, soit l'exiger, mais pas les deux.
Je crois qu'un développeur moral faisant face à ce paradoxe doit agir de manière à mériter la récompense, mais devrait aussi encourager les utilisateurs à donner volontairement. Tôt ou tard, les utilisateurs apprendront à soutenir les développeurs d'eux-mêmes, tout comme ils ont appris à soutenir les radios et les stations télé indépendantes.
Si les logiciels étaient libres, il y aurait toujours des programmeurs, mais peut-être en nombre moindre. Est-ce que cela serait mauvais pour la société?
Pas forcément. Aujourd'hui, les nations riches ont moins de fermiers qu'en 1900, mais nous ne pensons certainement pas que cela est mauvais pour la société, car ceux qui restent produisent plus de nourriture pour les consommateurs que tous ceux, plus nombreux, jadis. Nous appelons cela l'amélioration de la productivité. Le logiciel libre devrait demander moins de programmeurs pour satisfaire la demande, à cause de l'augmentation de la productivité logicielle à tous niveaux :
Ceux qui font objection à la coopération dans la mesure où elle diminuerait l'emploi des programmeurs s'opposent en fait à l'accroissement de la productivité. Pourtant les mêmes acceptent souvent la croyance largement répandue que l'industrie logicielle a besoin d'accroître sa productivité. Comment cela se fait-il?
La «productivité logicielle» peut vouloir dire deux choses : la productivité générale de tout développement logiciel ou la productivité de projets individuels. La productivité générale, c'est ce que la société aimerait améliorer et la voie la plus directe pour le faire est d'éliminer les obstacles artificiels à la coopération qui la réduisent. Mais les chercheurs qui se penchent sur la «productivité logicielle» se focalisent uniquement sur le deuxième sens, limité, du terme, où l'amélioration demande des avancées technologiques difficiles.
Est-il inévitable que les gens se mettent en concurrence, qu'ils essayent de dépasser leurs rivaux dans la société? Peut-être, oui. Mais la compétition en elle-même n'est pas nocive : ce qui est nocif, c'est le combat.
Il y a plusieurs façons de concourir. La compétition peut se présenter comme essayer d'aller plus loin, comme surpasser ce que d'autres ont déjà réalisé. Par exemple, jadis, il y avait concurrence entre les meilleurs programmeurs, afin que l'ordinateur fasse les choses les plus incroyables possible, ou encore à qui écrira le programme le plus court, le plus rapide pour une tâche donnée. Ce genre de compétition est bénéfique pour tous, tant que l'esprit de saine émulation est maintenu.
Une compétition constructive est suffisante pour pousser les gens à de grands efforts. Certains concourent pour être les premiers à avoir visité tous les pays du globe; il y en a même qui dépensent des fortunes pour cela. Mais ils ne corrompent pas les capitaines de navire pour que leurs rivaux soient échoués une île déserte. Ils se satisfont de laisser le meilleur gagner.
La compétition devient un combat quand les participants commencent à entraver les autres plutôt que de progresser eux-mêmes - c'est-à-dire quand le «que le meilleur gagne»fait la place au «laissez-moi gagner, que je sois le meilleur ou non». Le logiciel propriétaire est nocif, non parce qu'il est une forme de compétition, mais parce qu'il est une forme de combat au sein des citoyens de notre société.
La compétition dans les affaires n'est pas forcément un combat. Par exemple, lorsque deux épiceries sont en compétition, tout leur effort tend vers l'amélioration de leurs propres services, pas à saboter leur rival. Mais ce n'est pas ce qui démontre un engagement moral dans les affaires; plutôt qu'il existe une faible zone de combat dans ce genre de business, à la limite de la violence physique. Tous les domaines des affaires ne partagent pas cette caractéristique. La rétention d'information utile à tous, c'est une forme de combat.
L'idéologie, dans les affaires, ne prépare pas les gens à résister à la tentation de combattre, dans une compétition. Certaines formes de combat ont été interdites avec les lois anti-trusts, l'interdiction de la publicité mensongère, etc., mais plutôt que de généraliser le rejet du combat, les dirigeants inventent en général d'autres formes de combat qui ne sont pas spécifiquement prohibées. Les ressources de la société sont gaspillées économiquement, à l'instar d'une guerre civile entre factions.
Aux États-Unis, toute personne favorable à autre chose que le plus flagrant laissez-faire égoïste a souvent entendu ce genre de réflexion. On l'entend, par exemple, à l'encontre des partisans d'un système de santé publique, comme on en trouve dans les autres nations industrialisées. Ou encore à propos des partisans d'un soutien public des arts, tout aussi universel chez les nations avancées. L'idée que les citoyens aient une quelconque obligation de participer au bien public est considérée comme du communisme, aux États-Unis. Mais ce terme est-il bien approprié?
Le communisme, comme il était pratiqué en Union Soviétique, était un système de contrôle centralisé, où toutes les activités étaient passées au crible du régime, soi-disant pour le bien public, mais en fait pour le bien des membres du Parti Communiste. Système où les appareils permettant les copies étaient étroitement gardés, pour empêcher les copies illégales.
Le système américain de la propriété intellectuelle exerce un contrôle central sur la distribution d'un programme et surveille les copieurs grâce à des systèmes automatiques de protection contre la copie, pour empêcher les copies illégales.
Par opposition, je travaille à bâtir un système où les gens sont libres de décider de leurs propres actions; en particulier, libres d'aider leur voisin, de modifier et d'améliorer les outils qu'ils utilisent dans leur vie quotidienne. Un système basé sur la coopération volontaire et la décentralisation.
Du coup, si on doit juger ces points de vue par leurs ressemblances au communisme soviétique, alors ce sont les propriétaires de logiciels qui sont les communistes.
Je fais la supposition, dans cet article, que l'utilisateur d'un logiciel n'est pas moins important qu'un auteur ou même l'employeur d'un auteur. Autrement dit, lorsqu'on décide quelle est la meilleure marche à suivre, leurs intérêts et leurs besoins ont autant d'importance.
Cette prémisse n'est pas universellement acceptée. Beaucoup maintiennent que l'employeur d'un auteur est fondamentalement plus important que n'importe qui d'autre. Ils disent, par exemple, que le but, d'avoir des propriétaires de logiciels, est de donner à l'employeur les avantages qui lui sont dûs - indépendamment de l'effet sur le public.
Cela ne sert à rien de prouver ou non ces prémisses. Prouver demande des prémisses partagées. C'est pourquoi la majorité de mon discours s'adresse à ceux qui partagent les prémisses que j'utilise, ou qui, au moins, sont intéressés par leurs conséquences. Pour ceux qui croient que les propriétaires sont plus importants que tous les autres, pour ceux-là, cet article n'est tout simplement pas pertinent.
Mais pourquoi un grand nombre d'Américains accepteraient une prémisse qui élèverait certaines personnes au-dessus des autres? En partie à cause de la croyance que cette prémisse fait partie des traditions légales de la société américaine. Il y a des gens qui pensent que douter de la prémisse, c'est défier les bases de la société.
Il est important pour ces gens de savoir que cette prémisse ne fait pas partie de notre tradition légale. Ne l'a jamais été.
Ainsi, la Constitution dit que le but du copyright est de «promouvoir le progrès des sciences et des arts utiles». La cour Suprême l'a élaboré ainsi, énonçant dans la «Fox Film contre Doyal» que «l'intérêt unique des États-Unis ainsi que l'objet principal du monopole [du copyright], résident dans les bénéfices que retire le public du travail des auteurs».
Nous ne sommes pas obligés d'approuver la Constitution ou la Cour Suprême (il fut un temps où les deux ont approuvé l'esclavage). Leurs positions ne réfutent donc pas la prémisse de la suprématie du propriétaire. Mais j'espère que la conscience qu'il s'agit d'une supposition de la droite radicale, plutôt que d'une tradition reconnue, affaiblira son intérêt.
Nous aimons penser que notre société encourage à aider son voisin ; mais chaque fois que nous récompensons quelqu'un pour son obstructionnisme ou que nous l'admirons pour les richesses qu'il a accumulé ainsi, nous renvoyons le message contraire.
La thésaurisation de logiciels est un exemple de notre volonté d'ignorer le bien-être de la société pour le gain personnel. On peut en voir la trace depuis Ronald Reagan jusqu'à Dick Cheney, depuis Exxon à Enron, en passant par les échecs des banques et des écoles. Nous pouvons la mesurer à l'aune des sans-abri et de la population dans les prisons. L'esprit antisocial se nourrit de lui-même, parce que plus on voit que les autres ne nous tendront pas la main, plus il nous semble futile de les aider. Ainsi, notre société dégénère en jungle.
Si nous ne voulons pas vivre dans une jungle, nous devons changer nos attitudes. Nous devons commencer à lancer le message qu'un bon citoyen est un citoyen qui coopère quand il le faut, que ce n'est pas celui qui réussit en volant les autres. J'espère que le mouvement du logiciel libre contribuera à cela : au moins dans un domaine, nous remplacerons la jungle par un système plus efficace qui encouragera et se nourrira la coopération volontaire.
Texte