En programmation, les commentaires sont des portions du code source ignorées par le compilateur ou l’interpréteur, car ils ne sont pas nécessaires à l’exécution du programme, nous dit Wikipédia.

De fait ils sont le plus souvent utilisés pour expliquer le code, et contrairement à ce dernier qui nécessite un langage de programmation, les commentaires se font dans une langue humaine, généralement en anglais.

C’est une opération indispensable et une partie intégrante du travail du développeur, afin qu’un autre puisse comprendre et éventuellement modifier le code initial (quitte à ce que cet autre soit l’auteur même des commentaires, reprenant son code quelques temps plus tard).

De par le fait que sa nature en autorise l’accès et le ré-appropriation, on comprendra que ces commentaires soient encore plus importants dans le cas d’un logiciel libre.

Il se trouve cependant que, par paresse, manque de temps ou mépris pour ce qui ne serait pas de la programmation stricto sensu, ils sont parfois quelque peu négligés par les développeurs.

Or l’hypothèse défendue ici est qu’il y aurait une corrélation directe en la qualité des commentaires et la qualité du code.

Affirmer ainsi péremptoirement que l’un n’irait pas sans l’autre est somme toute assez osé. Mais cela a le mérite d’évoquer cette « face cachée » de la programmation qui fait aussi partie des compétences attendues d’un bon développeur^[1].

Si les commentaires sont moches, le code est moche

If the comments are ugly, the code is ugly

Esther Schindler – 15 novembre 2009 – IT World
(Traduction Framalang : Goofy)

C’est un peu dur, je sais, mais finalement je crois que c’est vrai.

Le développeur de Plone Martin Aspeli m’a signalé un billet assez judicieux dans lequel un programmeur en C faisait part de trois règles apprises à ses dépens. Celle qui a particulièrement attiré l’attention de Martin (et la mienne) est la suivante :

Les bons programmes ne comportent aucune faute d’orthographe ni de faute de grammaire. Je pense que cela vient probablement d’une attention soutenue aux moindres détails ; dans les programmes excellents tout est correct à tous les niveaux, jusqu’aux points qui terminent les phrases de commentaires.

« Allez, tu charries ou quoi ? ». Vous pourriez croire que pinailler à ce point est indigne de vous, « Et bien je m’en vais commencer à vous signaler les erreurs dans votre code lui-même ». J’ai été bien embarrassé les deux ou trois fois où ça m’est arrivé.

La programmation, que vous la pratiquiez en enthousiaste de l’open source ou parce que vous êtes au service du patron, est un exercice qui exige de l’attention aux détails. Quiconque écrit un logiciel doit être pointilleux, sinon le code ne fonctionnera pas. Je suis sûre que je n’ai pas besoin de vous citer la série des célèbres bogues de programmation dont s’est rendu coupable un programmeur qui a utilisé une virgule et non un point, ou des plantages aléatoires provoqués par deux lignes de code placées au mauvais endroit ?

Il est possible que mon jugement soit faussé par mes fonctions d’écrivain et d’éditrice, mais je crois fermement que si vous ne pouvez pas trouver le temps d’apprendre les règles de syntaxe de la langue (y compris la différence entre « c’est » et « ces », ou encore « m’a » et « ma »), je ne crois pas que vous puissiez être beaucoup plus consciencieux pour écrire du code en respectant les bonnes pratiques. Si vos commentaires sont négligés, je m’attends à trouver du code négligé.

Mon postulat vient de ce que m’a enseigné un éditeur très brillant, il y a dix ans (Laton McCartney, si tu lis ça : merci !). Si tu peux écrire le chapeau, disait-il, tu peux écrire l’article très facilement. Si tu ne peux pas écrire le chapeau, c’est que tu ne comprends pas encore ce que tu veux dire, et tu ne devrais pas commencer à écrire (le « chapeau » est le petit paragraphe d’accroche qui suit le grand titre, qui dit en un mot de quoi il est question et invite gentiment le lecteur à en savoir plus). De filandreuses « explications » du code dans les commentaires de l’application (c’est-à dire, ceux qui se lisent comme de bonnes excuses) indiquent que le développeur ne savait probablement pas ce qu’il faisait au juste. Ce qui signifie que son code est éligible au titre de nid à bugs.

Se plaindre de la mauvaise documentation interne est un vieux refrain, mais il existe une raison pour laquelle il est important de la faire bien. Vos commentaires sont la seule façon dont vous disposez pour communiquer avec la prochaine personne qui regardera votre logiciel (il se peut même que ce soit vous) en profondeur, et pas juste une ligne ou deux. À quoi pensiez-vous en écrivant ce code ? D’accord, du code « auto-documenté » c’est l’idéal, mais c’est un peu arrogant de prétendre que vous l’avez atteint, et ça l’est tout autant de ma part si je prétends que mes phrases n’ont pas besoin d’être révisées (elles en ont besoin, je suis bien contente d’avoir un correcteur).

Un autre problème habituel dans la médiocrité des commentaires apparaît lorsque les développeurs mettent à jour le code sans mettre à jour les commentaires ; comme l’a expliqué un consultant, les commentaires ne sont pas testés. Mais est-ce qu’il ne s’agit pas là encore d’un manque d’attention aux détails ? À chaque fois que vous n’êtes pas totalement attentif, vous êtes prédisposé à laisser tomber un petit bout de logique.

Vous voulez quelques exemples ?

En voici un tiré d’une explication à propos d’un choix de conception. (« oui, je devine que c’était probablement intentionnel », a écrit le programmeur qui m’a montré cet exemple. « mais c’est bien là le problème : il faut que je devine ».)

 «... des questions prévues pour injustifier un débat...» 

Voici maintenant une authentique ligne de code avec un commentaire. Notez que le commentaire met l’accent sur la faute d’orthographe. Sans compter que le commentaire vous indique que le programmeur n’avait pas la moindre idée de ce qu’il faisait au départ. Particulièrement parce qu’il n’aurait pas dû écrire « finished » (NdT : fini) dans ce bout de code, mais qu’il aurait dû essayer « complete » (NdT : terminé).

 if item.getState() == 'finsihed': #est-ce correct? 

Bon, je vous accorde quelques exceptions. Si l’anglais n’est pas votre langue maternelle, il est possible que les commentaires que vous laissez dans votre code montrent que vous n’êtes pas à l’aise pour écrire en anglais. Cependant, en ce qui me concerne je n’ai pas trouvé que c’était le cas. Comme beaucoup d’Américains s’en sont rendu compte, les capacités en anglais des « étrangers » sont généralement bien meilleures que les nôtres. Parmi les développeurs que je connais, ceux qui ont des lacunes dans leur maîtrise de la langue anglaise en sont conscients et font tout leur possible pour qu’un anglophone passe en revue leur documentation.

Je ne me lancerai pas dans des considérations sur l’indentation du code et des commentaires, c’est une guerre de religions. Mais j’ai rencontré des développeurs qui réagissaient aussi violemment devant un formatage de code « moche » que moi devant une grammaire moche.

Les environnements de développement modernes procurent la discutable possibilité aux développeurs d’être négligents sans effets pervers ; une interface glisser-déposer vous permet de créer une application vite fait bien fait (ou plutôt mal fait, j’en ai peur) avec bien moins d’horribles dommages collatéraux qu’à l’époque où les logiciels étaient généralement écrits en assembleur. Pourtant, d’une certaine façon, j’ai du mal à considérer le « je peux être négligent » comme un avantage réel.

La règle du commentaire « moche » vaut autant pour les applications propriétaires que pour les logiciels open source. Mais les développeurs de FOSS (NdT : Free and Open Source Software, les logiciels libres et open source) doivent faire beaucoup plus attention encore pour deux raisons. La première, c’est qu’au bureau, vous avez de grandes chances de croiser le développeur du code mal fichu et de pouvoir lui poser des questions (ou de lui en coller une, si c’était vraiment horrible). De plus, dans la communauté open source, davantage de gens regardent dans le code et ont besoin de le comprendre.

Toutefois, lorsque j’ai suggéré à des développeurs que « si les commentaires sont moches, le code est moche », beaucoup n’étaient pas d’accord. Et vous non plus peut-être. J’aimerais savoir pourquoi, et je vous invite donc à laisser un… commentaire.

Voici une traduction intéressante à plus d’un titre.

D’abord parce qu’elle donne la parole à un développeur de logiciel libre (dont nous n’oublions pas ce que nous leur devons, c’est-à-dire tout). En l’occurrence il s’agit de Zed Shaw, bien connu dans la communauté Python et RoR (Ruby on Rails).

Ensuite parce qu’elle évoque la classique opposition à l’intérieur même des licences libres entre celles de type GPL et celle de type BSD. C’est toute la question du copyleft et de la viralité de la licence. Le copyleft est une apparente restriction, puisqu’il impose de diffuser le code modifié sous la même licence. Mais peut-être que cette contrainte est paradoxalement une garantie supplémentaire de liberté pour l’utilisateur ?

Enfin parce qu’elle aborde de nombreuses problématiques liées à l’open source et au monde de l’entreprise. Le fait de cacher à ses clients que l’on a utilisé du logiciel libre dans les solutions que l’on propose est une attitude malheureusement très fréquente (permettant de faire croire à moindre frais que l’on est hyper-compétent et que l’on a travaillé dur sur le projet). Il y a aussi toute la logique des startups, dont on attend un retour sur investissement presque immédiat, et qui du coup font de la rétention de code pourtant libre au départ.

Et puis il y a la question morale de la reconnaissance et celle très concrète du gagne-pain du développeur, frustré d’être ainsi ignoré et constatant non sans une certaine irritation que d’autres en profitent à sa place.

Voilà donc, entres autres arguments, pourquoi l’article ci-dessous mérite attention. Fatigué qu’une énième personne vienne lui demander pourquoi son code n’est pas sous licence BSD, Zed Shaw a décidé de réagir avec ce plaidoyer pugnace pour la licence GPL.

« Je veux que les gens apprécient le travail que j’ai fait et la valeur de ce que j’ai réalisé. Pas qu’ils passent en criant « pigeon » au volant de leurs voitures de luxe. »

Remarque : L’auteur concentre dans son titre les trois licences de la famille : la GNU/GPL, la LGPL et l’AGPL^[1].

Pourquoi je (A/L)GPLise

Why I (A/L)GPL

Copyright Zed A. Shaw – 13 juillet 2009 – Blog personnel
Avec l’aimable autorisation de l’auteur
(Traduction Framalang : Poupoul2 et Cheval boiteux – Remerciements à Léviathan)

Dans le monde de Python, la GPL est fréquemment critiquée, la plupart préférant utiliser une licence plus permissive telle que BSD, MIT ou Python. Il est donc compréhensible que des gens soient en colère parce que j’ai placé Lamson (NdT : Serveur SMTP développé en Python) sous licence GPL. Nombreux sont ceux qui détestent cette licence, pensant qu’elle contrevient à l’esprit de Python.

J’aimerais cependant expliquer pourquoi moi j’utilise la GPL, après des décennies d’écriture de logiciels open source et quelques projets reconnus. Ce sont mes raisons de l’utiliser, elles ne s’appliquent qu’à moi et à ce que je souhaite faire de mon logiciel dorénavant. Vous êtes libres de vos opinions et choix, et j’espère que vous respecterez les miens.

C’est le droit de l’auteur

Je crois que ce qu’un auteur souhaite faire avec son travail est son droit le plus strict. Il l’a écrit, alors que tout le monde lui expliquait que ça ne fonctionnerait pas. Il s’est enchaîné à ce travail plutôt que de sortir avec des amis. Il en a corrigé les bogues, écrit sa documentation de façon à ce que tout le monde puisse l’utiliser. Il a peut-être même passé du temps à en assurer la promotion et à aider les gens. Tout cela gratuitement, et pour des raisons qui lui appartiennent.

Lorsque vous dénigrez un projet ou une personne pour son choix de licence, vous êtes un gigantesque abruti. L’auteur a travaillé sur ce projet, pas vous. Au minimum, vous insultez les croyances de cette personne dans le logiciel libre et open source, mais aussi son sentiment que le logiciel libre et open source fait progresser notre culture.

Au pire, vous êtes un gros et ingrat malotru, parce que quelqu’un vous donne un logiciel, alors que vous insultez son travail non pas sur des critères techniques, mais sur une licence que vous désapprouvez.

Je me fiche totalement de la licence que les autres utilisent pour leurs logiciels, c’est leur logiciel et râler à cause de la licence qu’ils ont choisi est injurieux. Ils l’ont écrit, y ont sué sang et eau, et vous devriez être reconnaissant d’avoir le privilège de simplement y avoir accès.

Voici la première raison pour laquelle j’utilise la GPL :

Parce que c’est mon choix, et si vous n’êtes pas d’accord avec ça, n’utilisez pas mon logiciel. C’est aussi simple que ça.

Je ne veux plus être ignoré

J’ai écrit Mongrel (NdT : Serveur et librairie HTTP pour Ruby on Rails) et puis je l’ai donné, avec l’espoir que ça en aiderait d’autres et que le donner me rapporterait d’une manière ou d’une autre. Peut-être un boulot, ou un peu de respect, ou encore ma propre entreprise créant d’autres logiciels tels que celui-ci.

Mongrel a eu un grand succès, et de très nombreuses entreprises gagnent beaucoup d’argent avec. Non seulement permet-il à Rails de fonctionner, mais également à quasiment tous les frameworks Web Ruby, tel que les serveurs web Ruby, et a même été porté dans d’autres langages. Mongrel est et a été un super projet et j’en suis réellement fier.

Laissez moi vous expliquer à quel point Mongrel est avancé. Vous rappelez vous de la nouvelle attaque récemment publiée sur Apache appelée Slowloris (NdT : attaques par Déni de Service via des requêtes HTTP partielles) ? J’avais en fait prévu cette attaque, et écrit Mongrel de manière à ce qu’il y soit résistant (autant que Ruby me l’ait permis). Je l’avais appelé la « trickle attack » (NdT : attaque par écoulement), et j’en avais même fait la démonstration. C’était en 2004. Il y a cinq ans. Je l’avais même ajouté comme attaque à RFuzz en 2005.

Malheureusement, le succès de Mongrel ne m’est pas revenu. Bien que tout le monde utilise mon logiciel, la grande majorité des entreprises utilisatrices étaient des startups, et la dernière chose que les startups admettent c’est qu’elles ne possèdent pas leur propriété intellectuelle. Elles souhaitent que tout le monde, et particulièrement les sociétés de capital risque et les investisseurs, croit qu’elles sont des génies qui ont « innové » dans tout ce qu’elles font fonctionner.

Lorsque je regardais autour de moi, les entreprises n’avaient aucun problème à admettre qu’elles utilisaient Ruby on Rails, mais elles n’en disaient pas plus, ce qui signifiait que lorsque j’essayais de trouver du travail, il m’était impossible d’expliquer l’ampleur de l’impact de Mongrel. Pour elles, il ne s’agissait que d’un simple serveur Web que leur administrateur système devait utiliser, Ruby on Rails était le véritable pourvoyeur d’argent.

Voici la seconde raison pour laquelle j’utilise la GPL :

À cause de l’expérience Mongrel, j’ai presque besoin que les entreprises soient obligées d’admettre qu’elles utilisent mon logiciel. Je préfèrerais à la limite que personne n’utilise mon logiciel, plutôt que de me trouver dans une situation où tout le monde l’utilise et personne ne l’admet.

Pire, tout le monde l’utilise, et en même temps me dit que je ne sais pas développer.

Le capital risque a changé l’industrie

L’industrie du logiciel a changé depuis l’an 2000. Je mettrais en fait le curseur à l’entrée en bourse de Google, mais je ne peux pas dire exactement à quel moment. Ce que je peux dire, c’est que les méthodes actuelles de progression des entreprises technologiques induisent l’exploitation du code source plutôt que la contribution.

Je ne peux pas réellement en vouloir à ces startups, elles sont conçues ainsi. Une entreprise adossée à un capital-risqueur aura presque toujours un objectif de gain à court terme, dans l’espoir d’apporter plus tard un joli retour sur investissement. Pour un capital-risqueur, un retour sur 20 ans n’est pas acceptable, particulièrement si vous prévoyez de faire cela sans offre et des stocks options disponibles pour tout le monde.

Pour une entreprise financée par un capital-risqueur, il ne s’agit toujours que d’augmenter des revenus pour donner l’illusion de la croissance, afin que les actionnaires investissent et mènent le prix de l’action aussi haut que possible. Il n’est pas dans leur intérêt de ne pas faire d’offre. Ils veulent de l’argent maintenant, autant que possible, et ne sont pas intéressés par l’investissement technologique ou humain.

Ce qu’elles veulent, ce sont des tonnes de technologie gratuite qu’elles peuvent cacher aux investisseurs. Elles sont ravis que cette technologie soit maintenue par des gens qui ne l’ont pas écrite, pour que les employés ne puissent pas réclamer leur dû plus tard.

Cette gestion à courte vue, combinée au financement limité de départ, signifie que ces entreprises exploitent l’open source. Elles l’utiliseront, gagneront leur argent, et partiront lorsque ceci sera fait. Ce qui, en fait, est parfaitement logique, parce que ainsi vont les choses, et honnêtement, si vous êtes une entreprise qui cherche à gagner de l’argent de cette manière, c’est ce que je vous suggèrerais de faire.

Pourtant, le contrat tacite entre les entreprises et les développeurs open source est désormais révolu. Je n’ai aucune raison de leur offrir un usage sans restriction de mon logiciel, puisqu’ils ne sont intéressés que par la transformation de mon logiciel en offre alléchante de mise sur le marché à court terme, à deux ou cinq ans.

Voici la troisième raison pour laquelle j’utilise la GPL :

Les entreprises du secteur technologique sont désormais conçues pour être créées et détruites rapidement au bénéfice de gros capital-risqueur, tout en maintenant des coûts très bas. Cela signifie qu’elles n’ont aucune prime économique à donner, aussi n’ai-je aucune prime sociale à leur « donner » mon logiciel.

Les développeurs sont des plagiaires

Ne nous voilons pas la face, tout le monde a besoin de manger et de payer son loyer. Pour beaucoup de gens, leurs besoins en argent sont modestes, et si vous travaillez sur quelque chose, vous espérez en retirer quelque chose qui vous aidera à satisfaire ces besoins. Il se peut que ce ne soit pas de l’argent. Peut-être est ce que ce sera du respect, ou des honneurs, mais vous espérez réellement quelque chose de votre travail.

Nous sommes d’accord. Aussi je trouve étrange un message twitter tel que celui-ci :

ericholscher @zedshaw Ce serait chouette si l’interface/code était sous licence BSD. Très utile au travail. L’interface REST marche aussi très bien.

Éric est un garçon très sympathique, aussi je ne vais pas m’acharner sur lui, mais si je traduis le message, ça pourrait donner ça : « Hey ! Ton logiciel est fantastique ! Je peux l’avoir gratuitement, pour pouvoir l’utiliser au boulot, plaire à mon patron et me faire de l’argent ? »

Honnêtement, combien d’administrateurs disent à leur patron que ce qu’ils utilisent provient du logiciel libre ? Combien d’entre vous disent aux investisseurs que toute votre infrastructure logicielle est basée sur un truc qu’un autre gars a écrit en plusieurs mois ? Combien d’entre vous vont voir leur dirigeants en disant : « Vous savez, il y a ce gars, Zed, qui a écrit le logiciel que nous utilisons, pourquoi ne pas l’embaucher comme consultant ? »

Vous ne le faites pas. Aucun d’entre vous. Vous prenez le logiciel, et vous l’utilisez tel Excalibur terrassant le dragon, et vous en ramassez ensuite tous les lauriers. Vous ne rendez rien, et en fait, j’ai croisé une grande majorité d’entre vous qui assènent constamment que je ne sais pas développer, histoire de plus encore protéger son cul.

Il n’est désormais plus pardonnable et acceptable que vous tous plagiez le travail que vous utilisez. Comme vos employeurs ont besoin de l’illusion de « l’innovation », vous avez besoin de l’illusion d’être intelligent. Ce qui vous amène à mentir, et à voler tout ce qui vous tombe sous la main, comme si cela vous appartenait.

Ok, mais cela signifie que vous avez cassé le contrat tacite avec les développeurs et défenseurs de logiciels libres et open source. Aussi longtemps que vous me rendez ma paternité et que vous assurez la promotion de mon travail, je vous donnerai mon logiciel. Puisqu’aucun d’entre vous ne le fait, je n’ai aucune motivation à vous donner mon logiciel, de la même manière que je n’ai pas besoin de me conformer au contrat passé avec l’entreprise nourrie au capital-risque.

Voici la quatrième raison pour laquelle j’utilise la GPL :

J’utilise la GPL pour que vous restiez honnête. Vous devez désormais dire à vos patrons que vous utilisez mon boulot. Et ils s’en pisseront dessus de trouille. Parfait. Parce que j’ai aussi une solution pour ça.

Si c’est bien, payez pour l’avoir

J’aime travailler sur Lamson, parce que faire des application de messagerie est tellement plus drôle que des applications Web. Lorsque je m’assois pour construire une application de courriel, ça ne nécessite qu’un ensemble de technologies et c’est terminé. Si j’ai besoin de faire une application Web, cela implique du design, des templates, du javascript, des bases de données, et plein d’autres machins.

L’autre raison pour laquelle j’aime écrire des logiciels de courriels est que personne d’autre ne le fait. Vous tous êtes de grosses buses, parce que même avec un projet tel que Lamson, vous êtes encore tous effrayés par le gros monstre SMTP. Le jour où j’ai dit que je pourrais faire du Mail over REST, vous avez presque fait dans votre slip. Oui, parce que ça aurait été tellement plus simple.

Et j’aime donner Lamson, parce que c’est une partie de moi-même. C’est ce parfait mélange de camelote, bidouillages techniques, marketing et écriture que j’aime, et dans lequel j’excelle. Même si j’en arrive à faire des montagnes d’argent en construisant des choses avec Lamson, Lamson restera libre pour que je puisse rester honnête.

Mais j’écris aussi mes propres logiciels et projets avec Lamson. Je l’utiliserai pour créer autant d’incroyables services de courriel que je pourrais. Certains gratuits, certains payés par la pub, certains payants, mais tous utiliseront Lamson pour botter des culs avec du courriel.

Maintenant, compte tenu du fait qu’il n’y a aucune motivation pour une entreprise à admettre qu’elle utilise mon travail, et qu’il n’y a aucune motivation pour un développeur à me rendre mon travail, posez vous cette simple question :

Pourquoi diable est ce que je ne facturerais pas des gens qui ne sont pas capables d’utiliser correctement la GPL ?

Je sais, je sais, les conservateurs du logiciel libre pensent que cela fait de moi un traître, mais réfléchissez-y. Vous avez le logiciel, sous licence GPL, et aussi longtemps que vous êtes un projet open source taillé dans la pierre qui publie son code, vous êtes libre de l’utiliser et d’en faire ce que vous voulez.

J’aime l’open source, mais qu’en est-il des entreprises qui l’utilisent ? Les entreprises vont devoir payer à présent. C’est ainsi que fonctionne l’économie. Si c’est assez bon pour que vous l’utilisiez, alors c’est assez bon pour que vous le payiez.

Voici la cinquième raison pour laquelle j’utilise la GPL :

Je serai toujours un développeur open source, mais très franchement, nous crevons parce que des entreprises qui utilisent nos logiciels ne rendent rien. L’ironie de la situation est que pour pouvoir accroître ma motivation à faire de l’open source, j’ai besoin de me faire payer.

Je ne demanderai évidemment jamais rien à un projet open source puisqu’ils honorent le contrat tacite : si je donne, vous donnez.

Mais les jours des entreprises-minutes et des développeurs ingrats qui gagnent de l’argent sur mon dos avec mon logiciel sont terminés. Ma nouvelle devise est :

L’open source à l’open source, le business au business.

Si vous faites de l’open source, vous êtes mon héros et je vous soutiens. Mais si vous êtes une entreprise, alors parlons affaires.

Finalement, la valeur

Au final, je voudrais également donner une petite raison pour laquelle j’utilise la GPL : La valeur perçue. Lorsque les gens peuvent obtenir quelque chose gratuitement sans même avoir besoin d’y penser, ils lui donnent même moins de valeur que quelque chose pour lequel ils paient même pour une somme dérisoire. C’est juste la manière d’être des gens, et il n’y a pas grand chose à faire contre ça.

Ma dernière raison d’utiliser la GPL est que je crois que mes projets ont de la valeur, et je veux que les gens qui les utilisent perçoivent cette valeur. Ils ont même tellement de valeur que je veux les associer à un document légal complexe et totalement non testé comme preuve de leur utilité. Si je voulais faire simple, je les placerais simplement sous licence BSD et tout le monde les utiliseraient.

Je veux que les gens apprécient le travail que j’ai fait et la valeur de ce que j’ai réalisé.

Pas qu’ils passent en criant « pigeon » au volant de leurs voitures de luxe.

Et si le plus grand danger qui guettait désormais le logiciel libre n’était pas exogène mais endogène ?

Si, comme le pensent certains, ce n’était plus le logiciel propriétaire qui menace, mais une dilution des valeurs et de la culture du logiciel libre dans une soupe open source de… confusion et d’opacité, au grand dam de l’utilisateur qui ne serait plus alors acteur potentiel d’une communauté ?

On aurait même inventé une expression pour caractériser ces logiciels aux processus de développement privés et fermés qui, et je caricature à dessein^[1], finissent par n’avoir d’open source que la licence : les « fauxpen source ».

Personnellement j’aime beaucoup ce néologisme. Il a été inventé par Phil Marsosudiro le 2 mai 2009 au cours d’une soirée (arrosée ?) quelque part en Caroline du Nord. Comment le sais-je ? Parce que je me suis rendu sur le site, ou plutôt la page, fauxpensource.org pardi !

Et il est repris ici par Matt Asay^[2] dont je ne partage pas forcément l’optimisme (et les contradictions) mais qui évoque une problématique dont nous n’avons pas fini d’entendre parler.

Quand l’open source ne l’est pas assez (open)

When open source isn’t (open enough)

Matt Asay – 10 novembre 2009 – CNET News (The Open Road)
(Traduction Framalang : Yonnel et Cheval boiteux)

Certains logiciels open source ne sont peut-être pas assez ouverts. Alors que « open source » fait référence à la licence sous-jacente au logiciel et à son adhésion à la définition de l’open source, on trouve de nombreux exemples de projets open source qui offrent une licence ouverte mais un processus de développement relativement fermé.

On a appelé cela « fauxpen source », ou pire encore, mais nous devons peut-être nous y habituer. Cela semble être la nouvelle norme du développement open source. Seules les fondations open source comme Eclipse, Apache Software Foundation et Mozilla semblent en mesure d’y échapper totalement.

Java est souvent cité comme exemple emblématique de « fauxpen source ». Lundi, le directeur technique de SAP, Vishal Sikka, a appelé de ses vœux un processus plus ouvert pour le développement de Java, mettant en avant que Sun exerce un contrôle trop strict sur le développement de Java. C’est un reproche qui mine la communauté Java depuis des années.

Et Java n’est pas le seul. Si Google s’attire les compliments pour ses investissements dans l’open source, certains n’hésitent pas à prétendre que Google garde une communauté Android fermée. Le même genre de plaintes a vu le jour à propos de la gestion de Chrome et de Chrome OS.

Même Red Hat, la quintessence des entreprises open source, est d’abord connue pour ce qu’elle distribue, pas pour ce qu’elle développe. Red Hat, bien sûr, travaille aux côtés d’IBM et d’autres développeurs salariés ou indépendants à l’écriture du noyau Linux, et publie scrupuleusement ses logciels sous licences open source. Mais lorsqu’il s’agit du développement de sa distribution Red Hat Enterprise Linux, de son middleware JBoss ou d’autres technologies (par ex. KVM), bonne chance si vous voulez trouver des contributions externes significatives.

MySQL ? C’est grosso modo la même chose. L’entreprise (maintenant Sun Microsystems) fait virtuellement tous ses développements en interne, ce qui est vrai pour chaque entreprise privée open source qui me vient en tête. C’est une des raisons pour lesquelles Richard Stallman n’a pas à rougir de s’inquiéter de l’avenir de MySQL, même si c’est sa licence GPL préférée qui est utilisée.

La source est peut-être open, mais le processus pas nécessairement.

Il y a de très bonnes raisons pour que Google, Red Hat, MySQL et d’autres agissent de la sorte sur leurs efforts de développement open source. Ils sont responsables, fiscalement et légalement, devant leurs clients, et doivent être en capacité de garantir qualité et sécurité. On peut comprendre qu’ils exercent un certain contrôle pour s’assurer que les produits qu’ils distribuent protègent l’intégrité de leur marque.

Toutefois ceci témoigne d’un réel fossé entre « l’open source » en tant que licence et « l’open source » en tant que mode de développement et de distribution de logiciels complètement transparent. Le premier modèle est simple à mettre en place, le second beaucoup moins et demande une réelle volonté de la part de l’éditeur.

Les entreprises qui semblent mieux réussir sont celles qui ne comptent pas sur un retour sur investissement direct avec les logiciels libres. En d’autres termes, si vous ne vendez pas de l’open source, il est plus facile d’être ouvert. Doc Searls exprime cela de manière tout à fait pertinente quand il dit que « vous gagnez de l’argent grâce à (l’open source), pas de l’open source ».

Les exemples ne manquent pas. IBM en est un, Google également, bien que je sois d’accord avec ceux qui le critiquent car il peut assurément mieux faire. On peut également citer Facebook, Oracle et quelques autres.

À l’avenir, je pense que nous allons voir cette « fauxpen source » décliner, les entreprises séparant clairement leurs efforts dans l’open source et leurs modèles de ventes. L’open source peut offrir une plate-forme directe de gains, mais ce n’est pas le meilleur moyen pour véritablement générer de l’argent. Pas pour la plupart des entreprises en tout cas.

Un peu de storytelling aujourd’hui sur le Framablog, avec cette histoire de fourmis qui n’avaient pas d’images dans Wikipédia.

Nous le savons, l’encyclopédie libre est très certainement l’une des plus belles aventures humaines jamais imaginées.

Mais son influence est telle qu’elle a aujourd’hui également la capacité d’influencer directement ou indirectement la politique de licences des contenus produits par les organismes publics, universités en tête^[1].

AntWeb passe sous licence Creative Commons BY-SA

AntWeb goes CC-BY-SA

Waldir Pimenta – 6 novembre 2009 – All The Modern Things
(Traduction Framalang : Poupoul2)

Saviez vous que l’insecte le plus venimeux au monde est une fourmi ? En effet, une piqûre de la fourmi Maricopa Harvester équivaut à douze piqures d’abeilles, ce qu’il faut pour tuer un rat de plus de deux kilos.

J’ai découvert cela il y a plus d’un an dans le livre des insectes de l’Université de Floride. Je me suis immédiatement tourné vers Wikipedia pour savoir ce qu’on en disait, mais à ma grande surprise, aucun article n’existait. J’en ai donc commencé un à partir d’un page blanche, en utilisant des informations glanées sur plusieurs sites consacrés aux fourmis. Finalement, les gens ont commencé à enrichir l’article, jusqu’à ce qu’il contienne une somme d’informations de bonne qualité à propos de cette espèce fascinante. Mais il y manquait toujours quelque chose, qui à lui seul pouvait rendre l’article dix fois meilleur : Une image.

Ainsi, en cherchant des images afin d’illustrer cet article, j’ai découvert les fantastiques images d’AntWeb, un projet de l’Académie des Sciences de Californie, qui a pour objectif d’illustrer l’énorme diversité des fourmis dans le monde. J’étais particulièrement heureux qu’ils utilisent une licence Creative Commons, mais j’ai rapidement déchanté en constatant que celle qu’ils utilisaient (la licence Creative Commons BY-NC) n’était pas appropriée pour Wikipédia, ou plus généralement pour ce que les Creative Commons appellent elles-mêmes les « œuvres culturelles libres » (Ndt : voir à ce sujet ce billet du Framablog).

Je leur ai donc envoyé un courriel, suggérant de changer la licence. Lorsqu’ils m’ont répondu, j’ai découvert qu’en fait, des discussions internes à propos de la licence étaient déjà en cours. Je suis resté en contact avec eux, et me suis assuré de leur parler des avantages de voir leurs travaux placés dans des vitrines telles que Wikipédia, Commons ou Wikispecies.

J’aime à penser que ma modeste intervention a participé à leur prise de décision, quelque temps plus tard, non seulement de changer de licence pour une Creative Commons BY-SA, mais également de téléverser leurs images dans Commons eux-mêmes. Il s’agissait d’une partie de leur mission globale : « L’accès universel aux informations sur les fourmis ». Auparavant, le projet AntWeb, se concentrait sur la numérisation de contenus et le développement d’un portail web : ils ont désormais décidé d’exporter le contenu d’AntWeb pour en améliorer l’accès. Mettre les images et les méta-données associées dans Commons fut un exemple en matière d’organisation.

Cette initiative a été saluée par la communauté, et il y a eu de nombreuses contributions à ce massif téléversement, afin de rendre les images plus faciles à trouver et à utiliser pour illustrer des articles, et autres pages pertinentes. Le processus a pris plusieurs jours, mais au final ce sont pas moins de 30 000 images qui auront été téléversées, intégralement associées à leurs données EXIF, mais également aux informations taxonomiques et géographiques, chaque fois qu’elles étaient disponibles.

Tout ceci n’est pourtant quelque part qu’une première pierre. Puisque, comme d’habitude dans le monde des wikis, vous pouvez contribuer. Il existe des articles à illustrer dans toutes les langues de Wikipedia (l’outil de recherche d’images libres FIST de Magnus arrive à point nommé pour cela). Il y a des pages à illustrer sur Wikispecies. Il y a des catégories à créer dans Commons, afin de faciliter la navigation dans l’arbre des catégories des fourmis et d’y rendre chaque image de fourmi accessible. Et plus important, il y a cette nouvelle fantastique à diffuser, afin de faire savoir à tous ceux qui sont intéressés par les fourmis qu’ils peuvent désormais compter sur ce qui est sans doute la plus importante ressource en ligne d’images de fourmis, toutes de grandes qualité.

Un grand merci à Brian Fisher, chef de projet AntWeb, qui a coordonné le processus de changement de licence, Dave Thau, ingénieur logiciel AntWeb, qui a écrit le script de téléversement et réalisé cette opération, et à toute l’équipe d’AntWeb pour leur formidable travail.

Le 26 août dernier la Free Software Foundation (FSF) lançait la campagne Windows7sins en vue d’alerter l’opinion sur le fait que Windows avait beau avoir changé, (le symbole du logiciel propriétaire qu’est) Microsoft demeurait toujours le même.

Grâce aux efforts communs et conjoints de Framasoft (traduction Framalang) et de l’April (relecture et mise en ligne^[1]), le site de la campagne est désormais traduit en français.

Cette campagne joue sur le numéro du dernier système d’exploitation pour se décliner en sept « péchés », malheureusement « capitaux » à freiner le développement et la diffusion du logiciel libre :

1. Empoisonnement de l’éducation
2. Invasion de la vie privée
3. Comportement monopolistique
4. Verrouillage
5. Blocage abusif des standards
6. Soutien des DRM
7. Menaces sur la sécurité de l’usager

Vous en trouverez quelques extraits ci-dessous mais nous vous invitons surtout à parcourir le site.

Remarque : Cette campagne a été diversement reçue par les internautes anglophones. Encore une critique de Microsoft, occupez-vous plutôt de mettre en avant les qualités du logiciel libre, envoyer une lettre aux 500 plus grandes sociétés américaines ne sert à rien^[2], a-t-on ainsi pu entendre ça et là. À vous ne nous dire (avec écoute et courtoisie) dans les commentaires si nous avons néanmoins bien fait de traduire le site.

Les 7 « péchés » de Windows 7

Péché 1 : Empoisonnement de l’éducation

À ce jour, on apprend à la plupart des enfants, dont l’éducation implique des ordinateurs, à utiliser le produit d’une seule entreprise : Microsoft. Cette firme dépense de fortes sommes pour que les groupes de pression et les commerciaux corrompent les services d’éducation. Une éducation qui mise sur la puissance des ordinateurs devrait ouvrir la voie de la liberté et de l’autonomie, et non ouvrir un boulevard au monopole insidieux d’une entreprise.
Pour en savoir plus..

Péché 2 : Invasion de la vie privée

Microsoft utilise des logiciels avec des noms fallacieux comme Windows Genuine Advantage pour inspecter le contenu des disques durs de ses utilisateurs. Les termes de la licence utilisateur que l’on est obligé d’accepter avant de pouvoir utiliser Windows préviennent bien que Microsoft se réserve le droit de faire ça sans avertissement.
Pour en savoir plus..

Péché 3 : Comportement monopolistique

Pratiquement tous les ordinateurs achètés sont vendus avec Windows pré-installé, et non par un libre choix. Microsoft impose ses dictats aux revendeurs de matériel informatique, pour qu’ils ne proposent pas de PC sans Windows pré-installé, bien que de très nombreux clients le leur demandent. Même les ordinateurs disponibles avec d’autres systèmes d’exploitations pré-installés tel que GNU/Linux incluaient souvent Windows au départ.
Pour en savoir plus..

Péché 4 : Verrouillage

Microsoft essaie régulièrement de contraindre ses utilisateurs à faire des mises à jour, en supprimant le support des versions précédentes de Windows et d’Office, et en augmentant le niveau du matériel requis. Pour beaucoup de gens, cela signifie qu’ils doivent mettre leur ordinateur au rebut juste parce qu’il n’est pas à la hauteur des exigences techniques requises par les nouvelles versions de Windows.
Pour en savoir plus..

Péché 5 : Blocage abusif des standards

Microsoft a essayé de bloquer le passage au standard libre pour les formats de documents, parce que des standards comme OpenDocument Format menaceraient le contrôle exercé pour le moment sur l’utilisateur avec les formats propriétaires de Word. Elle s’est lancée dans des manoeuvres en sous-main, qui peuvent aller jusqu’à la corruption de fonctionnaires, pour essayer de stopper de telles initiatives.
Pour en savoir plus..

Péché 6 : Soutien des DRM (Digital Restrictions Management)

Avec Windows Media Player, Microsoft collabore avec les grandes firmes des médias pour imposer des restrictions sur la copie de médias avec leur système d’exploitation. Par exemple, à la demande de NBC, Microsoft est capable d’empêcher les utilisateurs de Windows d’enregistrer des émissions télévisées qu’ils ont pourtant le droit d’enregistrer légalement.
Pour en savoir plus..

Péché 7 : Menaces sur la sécurité de l’usager

Windows a une longue histoire de failles de sécurité, ouvrant la porte à la diffusion des virus et permettant à des utilisateurs distants de prendre le contrôle des ordinateurs d’autres usagers et de les transformer en robots spammeurs. Puisque le logiciel est secret, tous les utilisateurs dépendent de Microsoft pour régler ces problèmes – mais Microsoft tient à ses propres intérêts en matière de sécurité, pas à ceux de ses usagers.
Pour en savoir plus..

Extraits du site Windows7Sins en version française.

Grande nouvelle pour le logiciel libre : le site de la Maison Blanche, Whitehouse.gov, vient de basculer sous Drupal ! Du coup, son créateur et principal animateur, Dries Buytaert, s’enthousiasme ci-dessous sur son blog et il a bien raison.

Et d’ailleurs si vous avez la curiosité de vous promener un peu sur le site (sous Creative Commons By !), vous constaterez peut-être avec moi qu’en terme d’ergonomie et vélocité, c’est très impressionnant.

À des années-lumière du site d’une Segolène Royal « par exemple », mais aussi et surtout très loin du site de l’Élysée.

Pour ce qui concerne sa politique en général, je ne saurais m’exprimer et m’engager, mais il est évident que l’administration Obama est en train de faire beaucoup pour la reconnaissance, la diffusion et la légitimité du logiciel libre et/ou open source, d’autres billets du Framablog peuvent en témoigner.

Whitehouse.gov utilise Drupal

Whitehouse.gov using Drupal

Dries Buytaert – 25 octobre 2009 – Blog personnel
(Traduction Framalang : Vincent)

Une grande et sensationnelle nouvelle ! Le site phare du gouvernement des USA, Whitehouse.gov, vient d’être relancé sous Drupal. C’est un grand jour pour Drupal, et pour l’Open Source dans le gouvernement, et quelque chose dont chacun peut être très fier dans notre communauté.

Tout d’abord, je pense que Drupal est en parfaite adéquation avec la volonté du président Barack Obama d’avoir un gouvernement ouvert et transparent. Drupal fournit un mélange remarquable de fonctions de gestion de contenu web traditionnel et de fonctionnalités « sociales » qui permettent une participation et une communication ouverte. Cette combinaison est ce que nous appelons la « publication sociale » et c’est ce pourquoi autant de personnes utilisent Drupal. De plus, je pense que Drupal rentre bien dans l’optique de réduction des coûts et d’action rapide du président Barack Obama. La flexibilité et la modularité de Drupal permettent aux organisations de construire rapidement des sites, à un coût inférieur à d’autres systèmes. Autrement dit, Drupal correspond bien au gouvernement des USA.

Deuxièmement, ceci est un signal fort parce que les gouvernements se rendent compte que l’open source ne comporte pas de risques supplémentaires par rapport au logiciel propriétaire, qu’en quittant un logiciel propriétaire, ils ne sont plus enfermés dans une technologie particulière, et qu’ils peuvent bénéficier de l’innovation résultant des milliers de développeurs qui collaborent à Drupal. Cela prend du temps de comprendre ces choses et d’amener ce changement, et je félicite l’administration Obama de prendre cet important rôle de leader en considérant des solutions open source.

Etant l’un des plus grands utilisateurs de logiciels au monde, le gouvernement des USA n’est pas un nouvel utilisateur de Drupal. Plusieurs agences comme par exemple le Département de la Défense, le Département du Commerce, le Département de l’Education et l’Administration des Services Généraux utilisaient Drupal antérieurement. L’adoption de Drupal croît rapidement chez le gouvernement des USA. Toutefois, la transition de Whitehouse.gov sur Drupal va plus loin et au delà de toute autre installation de Drupal dans le gouvernement, et constitue un formidable témoignage pour Drupal et pour l’open source. Ceci va donner de la visibilité à Drupal à tout le gouvernement des Etats-Unis d’Amérique, et à d’autres gouvernements à travers le monde.

Personnellement, je suis enchanté par l’idée que Drupal puisse ainsi contribuer à aider les gouvernements à fournir une plus grande transparence, une plus grande vitesse et une plus grande flexibilité.

En septembre 2006, la francophonie réunie à Bucarest par l’OIF proposait sur le site officiel de l’évènement un très intéressant article intitulé Le choix des logiciels libres, que nous avons reproduit ci-dessous.

Il n’est donc pas étonnant mais tout à fait réjouissant de les retrouver dans ce petit reportage réalisé à Niamey au Niger par TV5 Québec Canada.

« Cette formation, qui va durer une semaine, permettra à une trentaine de nigériens issus de différents secteurs d’activités, l’administration publique en général, le secteur de l’éducation, le secteur privé, de bénéficier d’une formation de pointe en environnement libre. »

—> La vidéo au format webm

Le choix des logiciels libres

URL d’origine du document

Conformément aux Conférences ministérielles sur la culture (Cotonou, 2001) et sur la société de l’information (Rabat, 2003), la Francophonie favorise le développement, la diffusion et l’usage de logiciels libres…

La Francophonie favorise le développement, la diffusion et l’usage de logiciels libres pour éviter que les pays en développement ne se trouvent en situation de dépendance technologique vis-à-vis d’un fournisseur.

La liberté de choix technologique défendue par la Francophonie vise à favoriser une appropriation réelle et maîtrisée des technologies. Mettre en commun le savoir, le faire évoluer librement, l’enrichir par une dynamique collaborative et répondre ainsi au besoin légitime de tous de participer pleinement à l’édification de la société de l’information sont le fondement même du concept des logiciels libres.

L’expression « logiciel libre » fait référence à la liberté pour les utilisateurs d’exécuter le programme, d’étudier son fonctionnement et de l’adapter à leurs besoins, de redistribuer des copies, d’améliorer le programme et de publier les améliorations pour en faire profiter toute la communauté. Le choix de l’utilisation de normes et de standards ouverts permet d’éviter des incompatibilités techniques pouvant conduire à des pertes de données publiques.

Il s’oppose à toute restriction des échanges et encourage la diversité d’expression. Beaucoup plus qu’une solution technique, il défend le libre accès aux savoirs. Grâce à leur faible coût d’opération et surtout aux principes de liberté et de partage qu’ils sous-tendent, les logiciels libres représentent une opportunité pour soutenir le développement durable des pays francophones du Sud.

L’OIF a donc soutenu l’organisation des Rencontres africaines du logiciel libre (respectivement du 4 au 7 octobre à Ouagadougou et du 19 au 21 octobre à Libreville). Les Rencontres mondiales 2005 sur les logiciels libres de Dijon (France, 5-9 juillet) ont également été soutenues, ainsi que le 7e Forum international du logiciel libre de Porto Alegre (Brésil, 19-22 avril 2006).

L’AUF, en partenariat avec l’Association francophone des utilisateurs de Linux et logiciels libres, a mis en place un réseau de centres Linux et logiciels libres fondé sur le développement et l’utilisation de solutions technologiques et pédagogiques ouvertes dans les pratiques d’enseignement, de recherche ou de communication. Ces centres sont basés à Antananarivo, Bamako, Chisinau, Dakar, Hanoi et Rabat.

L’Intif met en place des Laboratoires TIC (Labtic), véritables espaces collectifs mutualisés servant de cadre à la démultiplication des transferts de compétences au niveau national, en associant les acteurs des secteurs public, privé et associatif. Les Labtic permettent ainsi de faire des formations tout en créant un environnement matériel et logiciel permettant aux stagiaires de poursuivre et de consolider leurs acquis de manière continue. Ces actions de formation favorisent une appropriation technologique réelle qui peut servir de base à une industrie nationale numérique. En 2006, 15 laboratoires sont en place auprès de partenaires locaux dans les pays en développement : Bulgarie, Burkina Faso, Cameroun, Côte d’Ivoire, Gabon, Guinée, Laos, Madagascar, Mali, Maroc, Mauritanie, Niger, Sénégal, Togo, Vietnam.

Le concept de logiciel libre n’étant pas toujours très simple à expliquer, la tentation est alors forte de lui trouver quelques comparaisons plus parlantes et signifiantes aux yeux du grand public.

La plus cèlèbre d’entre elles est la comparaison dite de la recette de cuisine. Selon le principe du libre, vous avez obtenu légalement cette recette par différentes sources (des revues, le bouche à oreille…), vous avez le droit de préparer cette recette à qui vous voulez et vous pouvez la modifier puis la redistribuer comme il vous plaît. Selon le principe du logiciel non libre, vous n’avez pas accès à la recette, mais uniquement au plat déjà fait, vous ne pouvez manger le plat que dans une seule cuisine, et personne d’autre que vous ne peut en manger. Quand bien même la recette serait fournie avec le plat, toute copie ou modification serait interdite^[1]

Nous vous proposons aujourd’hui une comparaison avec l’achat et l’utilisation d’une voiture^[2], que nous devons à Tal Schechter de la Free Software Foundation. Comparaison d’autant plus pertinente que, dans le monde automobile, l’électronique a pris désormais le pas sur la mécanique avec toutes les conséquences que cela implique sur la réparation, la garantie et le contrôle de la marque.

La comparaison avec une voiture

The car analogy

Tal Schechter – 13 octobre 2009 – FSF.org
(Traduction Framalang : Kovalsky et Goofy)

Et si nous comparions l’achat d’une nouvelle nouvelle voiture avec l’utilisation de logiciels non libres ? Même si l’exemple suivant peut sembler quelque peu tiré par les cheveux, c’est une très bonne analogie pour comprendre l’importance de la liberté des utilisateurs dans les logiciels.

Imaginez que vous voilà parti pour acheter une nouvelle voiture. Après avoir choisi une marque, vous allez chez le concessionnaire et commencez à regarder ce qu’on peut vous proposer. Vous vous décidez pour un modèle qui vous plaît, et le vendeur essaie de vous vendre toutes sortes de choses dont vous n’avez pas besoin, et d’autres qui vous laissent sceptique. Une sous-couche de peinture ? Est-ce bien nécessaire ? Après avoir signé un contrat avec le vendeur, vous avez vos clés en mains.

Vous avez refusé de payer pour l’usage du coffre. Comme il y a un coffre intégré, ils ont essayé de vous vendre l’option d’avoir une copie de la clé, « Je n’ai pas réellement besoin d’un coffre », pensez-vous. « Je l’ajouterai plus tard si j’en ai besoin »

En ouvrant la porte, vous trouvez une énorme pile de papiers attachés par une pince au siège avant. La première page dit « Merci d’avoir acheté cette nouvelle voiture PaLibre. Nous espérons que vous l’apprécierez pendant de nombreuses années à venir. En déverrouillant et en ouvrant la porte, vous avez implicitement accepté les termes de ce contrat. Merci de prendre le temps de lire la notice d’utilisation ». Outré, vous retournez au bureau du vendeur. « Qu’est ce que ça veut dire, que j’ai implicitement accepté les termes du contrat ? Ne suis-je pas supposé lire le contrat avant de le signer ? ». Il vous répond que tout le monde trouve que le contrat est très ennuyeux, et que pour satisfaire pleinement la clientèle, on le signe à votre place. Satisfait de cette réponse, vous ramenez votre voiture flambant neuve à la maison.

Quelques mois passent sans aucun problème, et vous appréciez généralement votre voiture. Un jour, en conduisant, vous faites un saut sur l’autoroute. Vous aimez le son que fait votre voiture lorsque vous poussez un peu le moteur. Attendez une minute, vous ne semblez pas pouvoir aller à plus de 90 kms/heure ! Vous entendez une voix de synthèse qui vous dit : « À cause d’une mise à jour de sécurité du constructeur, vous ne pouvez pas dépasser 90 kms/heure. Bonne conduite ». Vous haussez les épaules et pensez, « Bon d’accord, c’est pour la sécurité. Ça pourrait être pire ». Vous prenez la sortie et rentrez chez vous.

Le matin suivant en allant au boulot, vous remarquez de drôles de bruits venant de sous le capot. Vous avez une amie qui s’y connaît en voiture, donc vous lui demandez si elle peut passer après le travail. Quand elle voit votre voiture, elle vous dit « Non. Je ne peux rien faire pour toi. C’est une de ces voitures PaLibres. Je ne peux même pas ouvrir le capot ».

Donc vous l’amenez chez votre garagiste, et il ne prend même pas la peine de vous faire payer un devis. « Désolé Monsieur. C’est une voiture PaLibre. Même si j’avais les bon outils, je ne pourrais pas déverrouiller le capot, et encore moins voir ce qui ne va pas. C’est contre la loi ». Estomaqué, vous retournez chez le concessionnaire pour demander « Quel est le problème? »

Après avoir attendu une éternité, finalement une employée du service après-vente appelle votre nom. Vous expliquez le bruit que fait la voiture et toutes les étapes que vous avez franchies pour essayer de la faire réparer. Elle explique que pour préserver la bonne image de PaLibre, ils ne laissent pas n’importe qui s’occuper de leurs voitures. Vous devez avoir une formation et une accréditation. Vous demandez à voir le contrat que vous avez signé. Une des clauses précise que tout ajout de pièce détachée non-homologuée annulera la garantie. Vous demandez à l’employée à quoi cela s’applique, et elle vous explique que même repeindre votre voiture avec une couleur non approuvée par le concessionnaire supprimerait la garantie.

Votre voiture va au garage du concessionnaire. Ils vous font payer un devis, ainsi qu’une « surtaxe de licence de réparation homologuée ». Ils vous appellent pour que vous alliez récupérer votre voiture, et ils vous disent qu’il n’ont rien trouvé. Vous récupérez votre voiture, et elle continue à faire ce bruit désagréable. Vous demandez au garagiste qui vous répond « Oh, parfois les voitures PaLibres font ce bruit. Il n’y a pas à s’inquiéter».

Même si l’histoire peut sembler ridicule, c’est exactement ce qu’il se passe lorsqu’une personne choisit d’utiliser un logiciel non libre. Vous choisissez le logiciel qui correspond le mieux à vos besoins, et parfois un vendeur vous aide. Vous acceptez un contrat que vous n’avez probablement pas lu, et parfois vous acceptez implicitement les termes d’utilisation du programme. Vous utilisez le logiciel. Cependant, vous pouvez utiliser le logiciel uniquement comme l’éditeur l’a autorisé (conduire dans notre comparaison). Quand le logiciel dysfonctionne, ou même lorsque vous voulez améliorez quelque chose, vous ne pouvez aller nulle part ailleurs que chez l’éditeur. Vous ne pouvez pas aller chez un ami qui s’y connaît en informatique. Vous ne pouvez pas demander à une autre entreprise de vous régler ça. Vous devez aller chez les développeurs. Lorsque vous leur expliquez votre problème, ils vous répondent peut-être « Nous ne pouvons pas faire ça pour vous ». Ils peuvent dire « On y pensera pour la prochaine version ». Il est plus probable encore qu’ils disent « C’est une fonctionnalité, il n’y a rien à réparer ».

Les logiciels libres, de leur côté, proclament les libertés des utilisateurs. Les logiciels libres sont définis ainsi : des logiciels que vous pouvez utiliser dans n’importe quel but (pour conduire, servir de presse-papier, d’objet d’art, etc.) ; des logiciels que vous avez la liberté d’étudier et de modifier si vous voulez, avec l’accès au code source (ouvrir le capot et regarder ce qu’il y a à l’intérieur, réparer et modifier de la façon dont vous l’entendez) ; des logiciels qui peuvent être redistribués ; des logiciels auxquels vous pouvez apporter des améliorations que vous pouvez publier (ajouter un évent sur le capot et un turbocompresseur, et mettre les plans de ce que vous avez fait sur votre site favori).

Nous n’acceptons pas les violations de nos libertés lorsque nous achetons une voiture, donc pourquoi devrions-nous le faire avec les logiciels ?