Nous pouvons nous réjouir du succès croissant que connaît le logiciel libre depuis quelques années, emmené par quelques projets phares tels que Firefox, Wikipédia, OpenOffice.org et Ubuntu pour les plus connus d’entre eux.

Les solutions Open Source sont de plus en plus utilisées sur les ordinateurs personnels et plus seulement dans le monde des serveurs, et entre le fiasco Vista et la crise, on se prend à rêver de jours radieux pour le libre…

Sauf que… Tout n’est pas rose au royaume du code ouvert ! Ces belles réussites cachent parfois des problèmes plus ou moins inquiétants : Firefox, fort de son record de téléchargements pour sa version 3.0, pourrait voir sa juteuse alliance avec Google menacée par les ambitions du géant de la recherche dans le domaine des navigateurs. Wikipédia mène en ce moment même une campagne d’appel aux dons massive pour lui permettre de poursuivre son développement. OpenOffice.org, adoptée par de plus en plus d’administrations et de particuliers, connaît quant à elle quelques couacs en coulisses, où des tensions se créent entre Sun et la communauté (nous traiterons de ce sujet dans un prochain billet).

Alors même si l’heure n’est pas à l’alarmisme^[1], il convient de ne pas se laisser griser par le succès et de garder à l’esprit qu’il y a encore du boulot…

L’excellent Bruce Byfield, dont nous avons déjà traduit plusieurs articles dans les colonnes du Framablog, a publié un billet où il dresse avec une grande pertinence une liste de neuf problèmes de comportement qu’il a relevés chez les partisans du libre (et chez lui…) qui nuisent au développement des projets Open Source et à la communauté. Il y parle entre autres de l’acharnement aveugle contre Microsoft, de l’hostilité envers les nouveaux venus, et de la tentation d’accepter des compromis qui au bout du compte, pour quelques parts de marché en plus, risquent de nuire à long terme au mouvement du libre.

Bien sûr, en homme raisonnable, il propose à chaque fois une solution pour y remédier et faire en sorte que le libre poursuive sa marche vers "la domination du monde", comme il l’évoque en plaisantant dans les lignes que vous allez lire.

Neufs bonnes résolutions pour bien commencer l’année 2009, donc… (J’en profite au passage pour adresser mes meilleurs vœux aux lecteurs du Framablog).

Neuf problèmes de comportement qui font du tort au logiciel libre

Nine Attitude Problems in Free and Open Source Software

Bruce Byfield – 15 octobre 2008 – Datamation
(Traduction Framalang : Don Rico et Goofy)

Le logiciel libre et Open Source (NdT : Free and Open Source Software ou FOSS), j’adore ça. C’est une cause, une extension de la liberté d’expression, que je peux défendre en tant qu’auteur, et les membres de la communauté, en plus d’être brillants, sont à la fois passionnés et pragmatiques. C’est un domaine stimulant, et celui dans lequel j’ai choisi de travailler.

Parfois, néanmoins, le pire ennemi de la communauté, c’est la communauté elle-même. Certains comportements, souvent enracinés, nuisent à son unité et à ses objectifs communs, tels que fournir une alternative au logiciel propriétaire ou prêcher la bonne parole du FOSS. Au sein de la communauté, presque tout le monde s’est un jour rendu coupable d’un de ces comportements fâcheux, moi y compris, mais nous en discutons rarement. C’est pour cette raison que ces comportements perdurent et gênent les efforts de la communauté.

Admettre l’existence de ces comportements me semble être un bon début pour y remédier, alors voici neuf de ceux que j’ai le plus souvent constatés chez moi comme chez d’autres.

1) Se tromper d’ennemi

Chaque fois qu’une communauté se construit sur un certain idéalisme ou des convictions, les luttes intestines semblent être la norme. Cela s’applique aux groupes religieux et politiques, et il n’y a donc rien de surprenant à ce que ce soit aussi la norme au sein du FOSS, où les opinions de beaucoup sont souvent très tranchées.

Trop souvent, hélas, les conflits internes semblent l’emporter sur les objectifs communs. Plusieurs grands pontes professionnels ou semi-professionnels se forgent un nom en s’en prenant à d’autres membres de la communauté (peu importe leur nom, si vous vous intéressez à la question, vous savez de qui il s’agit, et je me refuse à les encourager dans leur démarche en leur faisant de la publicité gratuite).

Parfois, comme le mentionne Jeremy Allison, ces pontifes osent émettre des critiques que nul autre n’oserait exprimer. Mais la plupart du temps, leur motivation semble n’être que d’attirer l’attention sur eux, sans se soucier des divisions qu’ils créent au sein de la communauté, et en lisant les propos de ces pontes, nous encourageons ces divisions.

Pis encore, les dissensions entre les défenseurs du logiciel libre et ceux du logiciel Open Source. Certes, ce sont deux philosophies différentes : le logiciel libre (free software) s’attache à la liberté de l’utilisateur, alors que l’Open Source se soucie surtout de la qualité du logiciel. Pourtant, malgré ces distinctions fondamentales, les membres des deux camps travaillent sur les mêmes projets, avec les mêmes licences, et ont beaucoup plus de points qui les unissent que de points qui les opposent.

Alors pourquoi s’attarder sur les différences ? À l’évidence, les partisans du logiciel libre et ceux de l’Open Source ne trouveront personne d’autre avec qui ils ont plus en commun.

2) Ennuyer le monde avec des histoires de logiciels

Le logiciel étant l’un des éléments centraux de la communauté du FOSS, ses membres passent logiquement beaucoup de temps à en discuter. Pourtant, si vous essayez d’intéresser quelqu’un au FOSS, parler de logiciel ne fonctionne que si vous vous adressez à un auditoire de développeurs. Pour les autres, même la gratuité du FOSS n’a pas grand intérêt, sinon les partagiciels ou shareware seraient beaucoup plus utilisés.

Pour la plupart des gens, le logiciel en soi n’a pas grand intérêt, même s’ils passent de dix à douze heures par jour devant leur ordinateur.

Comme l’a signalé Peter Brown, le président de la Free Software Foundation, il y a quelques années, le FOSS doit s’inspirer des méthodes des partisans du recyclage. Ces partisans du recyclage ne défendent pas leur cause en expliquant où sont amenés les matériaux recyclables pour leur donner une seconde vie, ni en expliquant comment on fait fondre le verre pour le réutiliser plus tard… non, ils présentent les bénéfices du recyclage dans le quotidien de tout un chacun.

De la même façon, au lieu de parler du logiciel ou de ses licences, la communauté du FOSS doit davantage évoquer les problèmes tels que les droits, la protection de la vie privée et de la liberté d’expression des utilisateurs, des questions qui vont bien au-delà du clavier et de l’écran.

3) Se contenter d’imiter d’autres systèmes d’exploitation

Pendant des années, le FOSS a dû s’efforcer de rattraper le développement de Windows et d’OS X. C’était une nécessité incontournable, parce que le FOSS a commencé plus tard, et pendant longtemps, a disposé de moins de ressources que ses rivaux du monde propriétaire.

En outre, les utilisateurs changent d’autant plus facilement de système d’exploitation pour passer au libre que ce dernier ressemble à ce qu’ils connaissent. Et les développeurs ne vont pas non plus perdre leur temps à réinventer l’ordre des entrées de menu dans une fenêtre ou les raccourcis clavier pour copier ou coller.

Cependant l’imitation pose aussi des problèmes. Elle peut mener à copier à l’aveugle, par exemple à placer le menu principal en bas à gauche alors que c’est en haut à gauche qu’on le trouve le plus vite. Cela signifie aussi qu’on a toujours un train de retard, ce qui n’attire guère de nouvelles recrues – après tout, qui voudrait s’embarrasser d’un système d’exploitation qui n’est pas à jour ?

La vérité, c’est que dans un nombre croissant de domaines, y compris celui du bureau d’ordinateur et de la suite bureautique, le FOSS a déjà rattrapé les systèmes propriétaires, ou est en passe de le faire. Dans certains cas, tels que KDE4, le FOSS a pris la tête en ce qui concerne l’expérimentation. Mais la majeure partie de la communauté n’est pas encore passée de l’idée d’imitation à celle d’innovation, et cette absence de prise de conscience risque d’entraver les progrès du FOSS.

Comme l’indiquait justement Mark Shuttleworth de Canonical l’été dernier, il ne suffit pas d’égaler Apple. Le but devrait être de le dépasser.

4) Se méfier des nouveaux venus

Toute communauté tend à se replier sur elle-même. Du fait qu’elle est constituée de réseaux d’associations qui existent depuis des années, et que le statut de chacun y dépend de ses contributions, la communauté FOSS est probablement plus insulaire que la plupart. Un nouveau venu au FOSS doit à la fois maîtriser un certain volume d’expertise technique mais aussi tout un répertoire de connaissances et de principes implicites, avant de pouvoir espérer intégrer la communauté.

Tout cela est compréhensible, mais ne peut justifier l’impatience affichée ni le dédain que beaucoup de membres de la communauté infligent aux nouveaux venus. Trop souvent, j’ai vu des débutants animés de bonnes intentions, même s’ils étaient trop peu informés, perdre tout intérêt pour le FOSS parce que leurs questions basiques déclenchaient des répliques cinglantes dans lesquelles le commentaire dominant était : « RTFM » (NdT : Read The Fucking Manual, soit « Lisez Le Putain De Mode d’Emploi »).

Apparemment, beaucoup de membres de la communauté doivent encore prendre conscience que la plupart des gens ont pour premier réflexe de demander l’aide de quelqu’un avant de se documenter, ou que poser une question au lieu de se renseigner par soi-même est souvent autant une tentative d’établir le contact qu’un appel à l’aide.

Certes, tout le monde n’a pas la capacité d’assurer une aide technique. Mais si l’on créait un code de bonne conduite traitant spécifiquement de l’accueil des nouveaux venus, la communauté pourrait accueillir quelques recrues supplémentaires au lieu de les faire fuir. Ce serait aussi davantage en accord avec les quatre libertés du mouvement du logiciel libre, et avec la définition de l’Open Source, comme le soulignait récemment un blog sur GNUMedia.

5) Accorder aux développeurs un statut privilégié

Le mouvement du FOSS a pris naissance chez les développeurs, et leur travail reste un élément central du mouvement. Mais ce qui semble échapper à beaucoup, c’est que la communauté s’est étendue bien au-delà de son cercle d’origine. En ce qui concerne les projets d’envergure, en particulier, responsables de la documentation, testeurs, artistes, responsables du marketing et chefs de projet – sans parler des utilisateurs finaux – sont devenus des rouages essentiels. De plus en plus, la conception d’un logiciel libre prend la forme d’une collaboration entre personnes issues de divers domaines de compétence.

Malgré ce changement, néanmoins, on traite dans de nombreux projets les non-développeurs comme des collaborateurs de second ordre. Souvent, ils ne peuvent devenir membres à part entière du projet et n’ont pas voix au chapitre. Si un non-développeur émet une suggestion susceptible d’améliorer le projet, trop souvent la réponse qu’il obtiendra d’un développeur sera "Nous attendons ton code avec impatience", le développeur sachant très bien qu’il ne s’adresse pas à un codeur.

En de telles circonstances, difficile de reprocher aux non-développeurs de perdre leur enthousiasme pour un projet. Et sans eux, la plus grosse partie du travail nécessaire à un logiciel moderne ne sera simplement pas effectuée.

6) Passer son temps à cracher sur Microsoft

La communauté tout entière se méfie de Microsoft, et ce à juste titre, nulle autre entreprise de logiciel propriétaire n’a fait preuve d’autant d’hostilité à l’égard du FOSS, et ses tentatives récentes pour un réchauffement diplomatique sont trop hésitantes pour convaincre qui que ce soit. Toutefois, certains au sein de la communauté semblent plus motivés par l’envie exprimer bruyamment leur hostilité inébranlable à l’encontre de Microsoft que par le souci de défendre la liberté informatique.

Il serait bon de s’élever contre cette hostilité, et ce pour plusieurs raisons. Tout d’abord, elle se révèle contre-productive et ne contribue en rien à promouvoir les objectifs du FOSS. Comme le fait remarquer Joe Brockmeier, chef de file de la communauté openSUSE, et qui fut aussi mon collègue chez Linux.com, il semblerait que ceux qui passent leur temps à cracher sur Microsoft ne contribuent jamais à aucun projet.

Plus grave encore, ces râleurs patentés criant plus fort que tout le monde, on les prend souvent à tort, vu de l’extérieur, pour la majorité de la communauté, et l’on s’imagine que tout le monde dans l’univers du FOSS est gueulard et parano. Une telle perception ne risque pas d’encourager grand monde à s’impliquer. Et de nos jours, s’en prendre à Microsoft est tellement à la mode que les gueulards, et donc le FOSS tout entier, risquent d’être noyés dans la masse.

Mais la principale raison pour laquelle il faut rejeter ces violents préjugés anti-Microsoft, c’est qu’à cause d’eux la communauté risque de ne se montrer assez vigilante à l’égard d’autres adversaires aussi dangereux. Personne, par exemple, ne semble s’inquiéter des actes liberticides d’Apple, même si à bien des égards cette entreprise est en train de devenir le principal ennemi du logiciel libre.

En bref, quel que soit l’angle sous lequel on le considère, cet acharnement contre Microsoft est un frein dont la communauté doit se débarrasser, ou qu’elle doit reléguer au second plan.

7) Prendre comme modèle de croissance le mode de développement des entreprises commerciales

Avec le succès viennent les problèmes d’échelle. Lorsqu’on les identifie, il faut rapidement s’atteler à les résoudre, aussi est-il peut-être naturel aux projets FOSS de s’inspirer des procédés de développement des entreprises commerciales pour gérer leur croissance.

Quelles qu’en soient les raisons, les gros projets FOSS agissent de plus en plus comme des entreprises commerciales de logiciels. Les dates de publication fixes, par exemple, sont devenues la norme pour de nombreux projets, tels que GNOME, Ubuntu et Fedora, qu’il y ait ou non nécessité de publier une nouvelle mouture. Depuis peu, Mark Shuttleworth propose en outre une publication synchronisée pour les projets les plus importants, de sorte qu’il soit plus facile aux distributions de prévoir leur dates de publication, même si jusqu’à présent cette idée n’a pas trouvé un écho très favorable.

Dans certains cas, emprunter des idées aux entreprises commerciales peut se révéler utile. Il faut néanmoins garder à l’esprit que, même si le FOSS peut s’accorder avec un mode de fonctionnement commercial, ses objectifs sont différents. Qu’advient-il, par exemple, de la politique propre à l’Open Source (ne publier un logiciel que lorsqu’il est prêt) si un projet s’engage à des dates de sortie régulières ? Tôt ou tard, on ne pourra échapper à des problèmes de contrôle de qualité.

Plus important encore, le développement du FOSS reste dans la plupart des cas fondamentalement différent du développement d’un logiciel commercial. Dans de nombreux cas, les développeurs du FOSS comptent parmi eux une forte proportion de bénévoles, et sont souvent dispersés en davantage de lieux que les membres d’une équipe de développement d’un projet commercial. Étant donné ces circonstances, le FOSS doit, comme depuis ses origines, organiser le déroulement de ses travaux au fur et à mesure. Par exemple, comment mener à bien des phases de test lorsque les testeurs sont tous bénévoles ? En ce domaine, comme dans bien d’autres, le FOSS doit innover plutôt qu’emprunter ses idées ailleurs.

8) Placer les parts de marché en tête des priorités

Une blague bien connue dans l’univers du libre dit que l’objectif du FOSS est de devenir le maître du monde. Et qui, au sein de la communauté, ne ressent pas une certaine fierté quand un gouvernement ou une entreprise choisit de passer au libre, ou qu’une application comme Firefox gagne quelques points de parts de marché ?

Toutefois, comme je l’ai déjà écrit, attirer de nouveaux utilisateurs n’a aucun intérêt si on le fait au détriment des idéaux du libre, ou si ces nouveaux utilisateurs ne les défendent pas. Même s’il est grisant d’obtenir enfin la reconnaissance qui lui est due, la communauté ne doit pas oublier que le but du jeu n’est pas seulement de fournir des logiciels alternatifs, mais aussi une philosophie et un rapport à l’informatique alternatifs.

Si l’on emploie seulement ses efforts à gagner des parts de marché, ce qui semble être le cas d’un nombre croissant d’acteurs de la communauté, alors le libre assure sa défaite au moment même où il semble connaître le plus de succès.

9) Se contenter d’un système d’exploitation qui ne soit pas complètement libre

Maintenant que la communauté touche au but et qu’elle est à deux doigts de pouvoir proposer un système d’exploitation complètement libre, on pourrait croire que tout le monde voudrait donner un dernier coup de collier pour transformer l’essai. Pourtant, comme le montrent les réactions à la liste de priorités principales que la Free Software Foundation a récemment réactualisée, un nombre étonnant de membres de la communauté ne ressentent pas le besoin d’atteindre cet objectif final. Peu importe, disent-ils, s’ils doivent utiliser des pilotes propriétaires pour leur carte vidéo ou le Flash Player d’Adobe sur YouTube. D’après eux, nous sommes arrivés assez près du poste de travail libre pour ne pas chercher à combler les derniers trous, et au moins on peut télécharger gratuitement les éléments qui manquent.

Penser que la situation actuelle est assez satisfaisante n’est pas cohérent avec le souci d’excellence qui est la clé de voûte de l’Open Source. Plus important encore, cela signifie qu’on accepte l’échec, et qu’on abandonne le projet de fournir des systèmes d’exploitation alternatifs 100% libres. Pourquoi jeter l’éponge alors qu’on est si près du but ?

Débattre de ces problèmes

Ces comportements qui entravent le mouvement du logiciel libre sont bien sûr bien sûr une question de point de vue. J’imagine sans mal un défenseur de l’Open Source me rétorquer que se focaliser sur la liberté de l’utilisateur nuit à la diffusion en masse, ou le chef d’une entreprise dont l’activité est fondée sur le logiciel libre me répondre que considérer le libre comme un projet d’abord non commercial constitue un frein à la réussite.

Mais mon propos va au-delà de ces points précis. Le message que je veux vraiment faire passer, c’est que le libre a tellement gagné en importance, et si vite, qu’il n’a pas eu le temps de se demander si les comportements des débuts étaient encore pertinents ou si les nouvelles approches s’accordaient avec ses valeurs essentielles. Avant de croître davantage, la communauté doit se pencher sur ses modes de fonctionnement et les évaluer. Si elle ne le fait pas, elle risque, sinon de s’effondrer sous le poids des contradictions, du moins de se créer sans nécessité de lourds handicaps.

Tous les livres devraient-ils être « libres », au sens où ils seraient tous placés sous une licence libre ? Bien évidemment non. Si un auteur (romancier, essayiste, historien, poète…) ne souhaite pas voir son ouvrage modifié ou commercialisé sans son consentement, il en va de son plus respectable choix. Et puis n’oublions pas qu’au bout d’un certain temps le domaine public prend le relai (temps peut-être un peu trop long actuellement mais là n’est pas le propos).

Il existe cependant certains domaines bien précis où l’adoption de telles licences est à évaluer avec attention, surtout si l’objectif visé est l’édition, le partage et la diffusion de la connaissance, et plus particulièrement de la connaissance « en perpétuel mouvement ». On peut ainsi sans risque affirmer que l’encyclopédie Wikipédia et les manuels scolaires de Sésamath ne seraient pas ce qu’ils sont sans les licences libres qui les accompagnent.

Quant à la documentation des logiciels libres, ce choix apparait si ce n’est « naturel » en tout cas cohérent et pertinent. Car il s’agit non seulement d’une question de principe et de fidélité aux licences des logiciels libres mais également d’une question d’efficacité et de qualité collectivement déclinées. Avec à la clé une ressource utile et disponible constituant un atout supplémentaire pour faire connaître et diffuser le logiciel libre traité^[1].

C’est ce que vient nous rappeler cet article du site Gnu.org que nous avons choisi de reproduire ici et qui encourage les éditeurs à vendre des manuels sous licences libres lorsque le sujet de l’ouvrage est un logiciel libre (ce qui n’est pas le cas actuellement, à quelques rares exceptions près comme, désolé pour la citation réflexive, la collection Framabook).

Il est bien évident que le principal frein est d’ordre financier. Les éditeurs « traditionnels » du monde informatique en langue française (Eyrolles, Dunod, ENI, Pearson, Campus Press, Micro Application…) imaginent qu’une mise sous licence libre de leurs ouvrages aurait un impact négatif sur les ventes, les bénéfices et le retour sur investissement. Cela reste difficile à prouver car la perte de clients potentiels (qui se contenteraient de la version numérique « gratuite ») est susceptible d’être compensée par une plus large publicité faite aux ouvrages en particulier parmi l’active et influente communauté du logiciel libre francophone (sans même évoquer la question du « capital sympathie » de l’éditeur qui pourrait s’en trouver là renforcée).

Wikipédia a atteint en quelques semaines les objectifs de sa campagne de dons (six millions de dollars), Sésamath possède des salariés rémunérés avant tout grâce à la « vente physique » de leurs manuels pourtant sous licence libre. Quant au plus modeste projet Framabook, son volume sur Ubuntu dépasse aujourd’hui les trois mille exemplaires achetés quand bien même cet achat se fasse encore presque exclusivement en ligne (et ce n’est pas fini puisqu’Ubuntu est bien partie pour durer encore un petit bout de temps).

N’ayez pas peur, comme dirait l’autre. Il me tarde de voir par exemple l’excellente collection Accès Libre d’Eyrolles porter encore mieux son nom.

Logiciels et manuels libres

Free Software and Free Manuals

GNU.org – dernière mise à jour : 24 mars 2008
(Traduction : Benjamin Drieu)

Le plus grand défaut des systèmes d’exploitation libres n’est pas dans le logiciel, mais dans le manque de bons manuels libres que nous pouvons y inclure. Beaucoup de nos programmes les plus importants ne sont pas fournis avec des manuels complets. La documentation est une partie essentielle de tout logiciel; quand un logiciel libre important n’est pas fourni avec un manuel libre, c’est un manque majeur. Aujourd’hui, nous avons de nombreux manques importants.

Il y a de nombreuses années, j’ai voulu essayer d’apprendre Perl. J’avais une copie d’un manuel libre, mais je ne l’ai pas trouvé facile d’accès. Lorsque j’ai demandé à des utilisateurs de Perl s’il existait une alternative, ils me dirent qu’il y avait de meilleurs manuels d’introduction, mais que ceux-ci n’étaient pas libres.

Mais pourquoi cela ? Les auteurs de ces bons manuels les ont écrit pour O’Reilly Associates, qui les publie sous des termes restrictifs (pas de copie, pas de modification, les sources ne sont pas disponibles). Cela les exclut de la communauté du logiciel libre.

Ce n’était pas la première fois que ce genre de choses se produisait, et (malheureusement pour notre communauté) c’en est loin d’être fini. Les éditeurs de manuels propriétaires ont encouragé un grand nombre d’auteurs à restreindre leurs manuels depuis. J’ai souvent entendu un utilisateur de GNU me parler d’un manuel qu’il était en train d’écrire et avec lequel il comptait aider le projet GNU, puis décevoir mes espoirs en expliquant qu’il avait signé un contrat avec un éditeur qui restreindrait son manuel de telle manière que nous ne pourrions pas l’utiliser.

Etant donné la rareté de bons rédacteurs en langue anglaise parmi les programmeurs, nous ne pouvons pas nous permettre de perdre des manuels de cette manière.

L’intérêt d’une documentation libre (tout comme pour un logiciel libre) est la liberté, pas le prix. Le problème avec ces manuels n’était pas que O’Reilly Associates vende les versions imprimées de ses manuels, ce qui est bon en soi. (La Free Software Foundation vend aussi des impressions des manuels GNU). Mais les manuels GNU sont disponibles sous forme de code source, alors que ces manuels-là ne sont disponibles que sous forme imprimée. Les manuels de GNU sont distribués avec la permission de les copier et de les modifier; mais pas ces manuels de Perl. Ces restrictions sont le problème.

Les conditions à remplir pour un manuel libre sont à peu près les mêmes que pour un logiciel; il s’agit de donner à tous les utilisateurs certaines libertés. La redistribution (y compris une distribution commerciale) doit être autorisée afin que le manuel accompagne chaque copie du programme, de manière électronique ou imprimée. Permettre les modifications est crucial aussi.

En règle générale, je ne crois pas qu’il soit essentiel que nous ayons la permission de modifier toutes sortes d’articles ou de livres. Les problèmes de l’écriture ne sont pas forcément les mêmes que ceux du logiciel. Par exemple, je ne crois pas que vous ou moi devrions nous sentir obligés de donner la permission de modifier des articles tels que celui-ci, qui décrivent nos actions et nos positions.

Mais il y a une raison particulière pour laquelle la liberté de modifier des documentations libres traitant de logiciels libres est cruciale. Lorsque les programmeurs exercent leur droit de modifier un logiciel et d’ajouter ou de modifier des fonctionnalités, s’il sont consciencieux, ils changeront aussi le manuel afin de pouvoir fournir une documentation précise et utilisable avec leur propre version du programme. Un manuel qui interdirait aux programmeurs d’être consciencieux et de finir leur travail, ou qui leur imposerait d’écrire un nouveau manuel à partir de zéro s’ils modifient le programme ne répond pas aux besoins de notre communauté.

Même si un refus total des modifications est inacceptable, quelques limites sur la manière de modifier une documentation ne pose pas de problème. Par exemple, il est normal d’avoir des injonctions de préserver la notice de copyright originale, les termes de distribution ou la liste des auteurs. Il n’y a pas non plus de problème à demander que les versions modifiées incluent une notice expliquant qu’il s’agit d’une version modifiée, et même d’avoir des sections entières qui ne puissent ni être supprimées ni être modifiées, du moment qu’il ne s’agit pas de sections ayant trait à des sujets techniques (certains manuels GNU en ont).

Ce type de restrictions n’est pas un problème, car d’une manière pratique elles n’empêchent pas le programmeur consciencieux d’adapter le manuel pour correspondre au programme modifié. En d’autres termes, elles n’empêchent pas la communauté du logiciel libre de faire son oeuvre à la fois sur le programme et sur le manuel.

De toutes façons, il doit être possible de modifier toute la partie technique du manuel ; sinon ces restrictions bloquent la communauté, le manuel n’est pas libre, et nous avons besoin d’un autre manuel.

Malheureusement, il est souvent difficile de trouver quelqu’un pour écrire un autre manuel quand un manuel propriétaire existe déjà. L’obstacle est que la plupart des utilisateurs pensent qu’un manuel propriétaire est suffisament bon, alors ils ne ressentent pas le besoin d’écrire un manuel libre. Il ne voient pas qu’un système d’exploitation libre a une fissure qui nécessite un colmatage.

Pourquoi ces utilisateurs pensent-ils que les manuels propriétaires sont suffisament bons ? La plupart ne se sont pas penchés sur le problème. J’espère que cet article sera utile dans ce sens.

D’autres utilisateurs considèrent les manuels propriétaires acceptables pour la même raison qu’énormément de personnes considèrent le logiciel propriétaire acceptable : ils pensent en termes purement pratiques, sans mettre la liberté en compte. Ces personnes sont attachées à leurs opinions, mais comme ces opinions découlent de valeurs qui n’incluent pas la liberté, ils ne sont pas un modèle pour ceux d’entre nous qui s’attachent à la liberté.

Je vous encourage à parler de ce problème autour de vous. Nous continuons à perdre des manuels au profit d’éditions propriétaires. Si nous faisons savoir que les manuels propriétaires ne sont pas suffisants, peut-être que la prochaine personne qui voudra aider GNU en écrivant de la documentation réalisera, avant qu’il soit trop tard, qu’elle devra avant tout la rendre libre.

Nous pouvons de plus encourager les éditeurs à vendre des manuels libres et dénués de copyright au lieu de manuels propriétaires. Une façon de le faire est de vérifier les termes de distribution de manuels avant de les acheter, et de préférer les manuels sans copyright à des manuels copyrightés.

La reproduction exacte et la distribution intégrale de cet article est permise sur n’importe quel support d’archivage, pourvu que cette notice soit préservée.