Il y a ceux qui se morfondent à constater la crise actuelle de l’industrie musicale et qui croient naïvement que la loi Hadopi^[1] va résoudre leurs problèmes. Et puis il y a les autres, comme le chanteur Curt Smith, qui nous explique calmement et sereinement en quoi les licences Creative Commons sont un choix contemporain simple et pertinent, pour ne pas dire « naturel », quand on souhaite autoriser la diffusion de sa musique sous certaines condition (ici la non exploitation commerciale).

Curt Smith (à ne pas confondre avec Robert Smith) ne vous dira peut-être rien, mais certains vieux (comme moi) se souviennent de son groupe Tears for Fears dont les quelques chansons suivantes bercèrent la jeunesse new wave des années quatre-vingts : Mad Word, Change, Shout ou encore Sowing the seeds of love.

Depuis Curt Smith^[2] poursuit une carrière solo et a donc placé son dernier album Halfway, pleased sous licence Creative Commons By-Nc-Sa. Il s’en explique dans cette interview vidéo donnée le mois de novembre dernier sur le site de Dave Harris RetroRewind. La clarté de ses propos associée au climat tendu que fait régner la « menace Hadopi » nous ont donné envie de faire acte de résistance et de subversion en traduisant et sous-titrant^[3] ci-dessous le début de l’entretien.

—> La vidéo au format webm

On le sait, les préjugés ont la peau dure, et le logiciel libre a bien du mal à se débarrasser de ceux qu’il traîne derrière lui. Quels que soient ces préjugés, d’où qu’ils viennent, il est assez aisé d’y répondre et de les corriger lorsqu’on s’intéresse un tant soit peu au monde du libre, mais la méconnaissance du « grand public » et les efforts des adversaires du libre pour le dénigrer ont ancré ces idées dans l’esprit de pas mal de gens^[1].

Il faut croire que les campagnes de FUD de Microsoft et consorts ont porté leurs fruits, même si heureusement des acteurs du libre tels que Firefox, Wikipédia, OpenOffice.org et Ubuntu, entre autres, contribuent à faire connaître davantage les logiciels libres et à transformer les mentalités. Cependant, malgré les progrès accomplis depuis quelques années, la visibilité croissante et l’image positive qu’est en train de gagner le libre, certaines idées fausses perdurent et constituent sans doute un frein à une adoption plus vaste des logiciels et systèmes d’exploitation libres.

Voici donc un article synthétique^[2] qui dresse la liste des cinq idées fausses les plus répandues concernant le Libre, et les arguments à y opposer lorsqu’au détour d’une conversation sur Internet ou chez vos amis un vilain troll pointe le bout de son nez…

Comment mal comprendre le Logiciel Libre

How to Misunderstand Free Software

27 juin 2008 – GetGNULinux.org
(Traduction Framalang : Thomas P., Vincent L., Daria et Yostral)

Cinq idées fausses à propos du Logiciel Libre, avec leurs corrections.

1. L’industrie du logiciel ne peut plus fonctionner si les programmeurs ne sont pas payés.

Commençons par un simple fait: les programmeurs de Logiciel Libre aiment être payés, et ils ont tous besoin d’acheter un déjeuner à un moment ou à un autre. Lorsque nous parlons de Logiciel Libre, nous faisons référence à la liberté, pas au prix. En réalité, vous pouvez payer pour obtenir du Logiciel Libre (ou du logiciel à « source ouverte »), que vous pouvez ensuite étudier, modifier et copier à volonté.

Comment est-ce que cela fonctionne ? Vous pouvez voir cela de cette manière : le logiciel est seulement du code, le code est seulement des mathématiques. Lorsque vous voyez le logiciel comme des mathématiques utiles, un langage élaboré, pas comme de la propriété ordinaire, alors il n’y a pas de raison de limiter son utilisation par d’autres.

Comme pour les mathématiques (où personne ne revendiquerait la propriété d’une équation), le logiciel requiert des connaissances avancées pour être adapté, amélioré, appliqué correctement. C’est là que les programmeurs génèrent des revenus : de nombreux clients, en particulier les entreprises, sont prêtes à payer pour des mises à jour de sécurité régulières et des améliorations de logiciel.

Les entreprises du Logiciel Libre bénéficient d’un système de développement très décentralisé avec un grand nombre de contributeurs bénévoles. Les revenus dans l’industrie du Logiciel Libre sont peut-être plus minces que dans sa contrepartie propriétaire, mais ils ne sont en aucun cas négligeables. Au final, les particuliers finissent généralement par utiliser du Logiciel Libre gratuitement.

Le Logiciel Libre n’a pas pour objet de supprimer les motivations des programmeurs. Il s’agit de voir le code comme de la connaissance qui ne doit pas être cachée à l’utilisateur. Cela fonctionne avec un modèle économique différent, grâce auquel de nombreuses entreprises fonctionnent déjà bien.

2. L’innovation est tuée dans le Logiciel Libre.

Une croyance répandue est que si n’importe qui peut copier des idées, l’innovation va être étouffée.

En réalité, la liberté est souvent la clé d’un logiciel innovant et à succès :

• N’importe qui est autorisé et encouragé à travailler dessus;
• De nombreuses personnes sont prêtes à participer;
• Il n’est pas nécessaire de tout ré-inventer, les idées peuvent être améliorées directement.

Les logiciels non-propriétaires apparaissent dans de nombreux domaines, prenons juste quelques exemples :

• Applications : Firefox (navigateur web), Inkscape (logiciel de dessin vectoriel).
• Systèmes complets : Apache (serveur web), OpenBSD (système d’exploitation), et bien sûr GNU/Linux.
• Formats et protocoles : HTML (pages web), BitTorrent (partage de fichiers), ODF (documents bureautiques).
• Applications serveur : Drupal (Système de gestion de contenu), WordPress (blog).

3. Tout ce qu’on attend d’un logiciel, c’est que ça fonctionne (qui se soucie du code source ?)

Tout le monde devrait se préoccuper de savoir si son logiciel est libre. Imaginez que vous achetez une voiture dont vous avez interdiction d’ouvrir le capot. Peu importe que vous sachiez comment fonctionne une voiture – le fait est que personne ne sera en mesure de vérifier le moteur. Comment pouvez-vous avoir confiance dans votre voiture, si personne ne peut s’assurer qu’elle est fiable, qu’elle ne fuit pas, qu’elle n’est pas nuisible à la société et à l’environnement ?

L’idée est la même avec le logiciel – excepté que le code fait bien plus que de bouger des voitures. Le logiciel fait tourner nos ordinateurs, téléphones, TV, lecteurs multimédia et bien plus encore, transportant de l’information et notre culture.

Le logiciel libre est aussi important que l’expression libre, que le libre marché. Si le logiciel est libre, les utilisateurs en ont le contrôle tout en gardant leur indépendance vis-à-vis de lui.

Bonnes nouvelle : en plus de tout, le logiciel libre aussi, « Ça fonctionne ». Et en fait, bien souvent, il fonctionne mieux. Démarrez votre PC sur un live-CD GNU/Linux, pour essayer un système bien organisé, tout compris, sans installation, afin de vous en rendre compte par vous-même.

4. Le logiciel libre ne respecte par les droits d’auteurs et les logiciels brevetés.

Pour répondre correctement à ceci, nous devons faire une nette distinction entre le droit d’auteur et les brevets. Le droit d’auteur est un droit attribué à l’auteur sur sa création (par exemple le texte d’un livre, ou le code source d’un programme). Un brevet, quant à lui, est un contrôle exclusif enregistré, payé, sur un processus ou l’application d’une idée.

Les droits d’auteur sont très importants dans le logiciel libre. C’est le mécanisme même, central à la GNU General Public License, qui assure que le logiciel demeure libre, et que les auteurs voient leur travail crédité. Les programmes sont sujets à droits d’auteur, qu’ils soient libres ou propriétaires.

N’importe quel auteur de logiciel propriétaire peut facilement vérifier que son droit d’auteur n’a pas été violé dans une application du logiciel libre, puisque son code source est facilement disponible.

Les brevets logiciels, d’un autre côté, sont un concept très controversé. Pour faire bref : il n’y a rien de tel qu’un « logiciel breveté ». En enregistrant un brevet, toutefois, quelqu’un peut revendiquer sa propriété d’un processus. Le brevet s’applique alors à tous les logiciels qui utilisent ce processus, qu’ils soient propriétaires ou libres. Les brevets logiciels :

• Sont onéreux et sont délivrés seulement quelques semaines après leur application;
• Sont limités géographiquement (un brevet délivré aux USA est inutile en Europe);
• Ont une longue durée de vie (souvent 20 ans) dans une industrie qui bouge vite;
• Sont souvent complètement triviaux (c’est à dire sans innovation réelle).

En tant que tel, ils sont rarement utilisés pour bénéficier aux innovateurs (et en fait, rarement utilisés par les innovateurs eux-mêmes).

On peut dire sûrement que n’importe quelle partie de taille moyenne d’un logiciel viole des brevets, dans plusieurs pays, qu’il soit libre ou non. En fonction de la capacité de la société détentrice à couvrir de lourds frais juridiques et à se défendre contre des actions légales vengeresses, des royalties et des restrictions peuvent être appliquées grâce à ces brevets.

5. Le logiciel libre est comme le communisme.

Les partisans de cette idée soutiennent qu’il ne peut y avoir de propriété privée avec le logiciel libre (ou « Open Source »). Répondons à ceci avec un exemple.

Supposons que vous utilisez une application qui est du logiciel libre, chez vous et dans votre société. Vous trouvez une belle façon de l’améliorer, de telle manière que maintenant avec votre version modifiée, votre ordinateur fonctionne mieux, et vos usines tournent deux fois plus vite !

Cette version modifiée est votre propre version. Vous n’êtes pas obligés d’en parler à quiconque, ni de partager aucun profit que vous avez fait en l’utilisant. Vous exercez simplement votre liberté à utiliser et modifier le logiciel libre.

Ce que demande la licence sur le logiciel libre est que si vous redistribuez le logiciel, alors vous devez le laissez libre. A savoir, si vous vendez des CD avec votre logiciel, ou commencez à laisser des personnes en dehors de chez vous ou de votre société l’utiliser, alors vous devez :

• Soit donner à chacun les mêmes droits que lorsque vous aviez obtenu le logiciel original, c’est-à-dire, la liberté d’inspecter, modifier et redistribuer la version modifiée;
• Ou, séparer clairement le logiciel original et vos ajouts secrets (c’est-à-dire que vos ajouts ne doivent rien contenir de l’oeuvre originale).

Vous « possédez » donc davantage un logiciel libre qu’un logiciel propriétaire, dont le concepteur décide de ce que vous pouvez ou ne pouvez pas en faire.

Le logiciel libre n’a rien à voir avec un système politique. Vous pouvez faire tourner du logiciel libre au-dessus de logiciel propriétaire, aussi bien que l’inverse. La licence sur le logiciel libre est simplement un contrat éthique entre le programmeur et l’utilisateur final.

Qu’est-ce qu’un « film libre » ? Est-ce qu’une œuvre cinématographique qui interdit la modification et la commercialisation (typiquement sous licence Creative Commons By-Nd) peut encore se considérer comme tel alors même qu’elle assure pourtant le « minimum syndical » de la libre circulation ? On pourrait alors penser qu’il suffit de lever ces clauses (typiquement avec une licence Creative Commons By-Sa) par avoir à faire avec certitude à du « cinéma libre ». Mais là encore ça peut coincer car quid d’une telle œuvre qui ne fournirait pas ses « sources » (rushes en haute définition, musiques, textes…) ? Le logiciel libre n’a pas le monopole de la liberté mais si l’on se réfère uniquement à la définition donnée par les fameuses quatre libertés du logiciel libre (dont deux nécessitent le code source) alors non nous ne sommes toujours pas en présence d’un « film libre ».

C’est pourquoi, au delà de ses qualités artistiques intrinsèques^[1], nous avons trouvé intéressant d’évoquer le film anglophone « en construction » Valkaama en traduisant le billet dédié du blog des Creative Commons (et en ajoutant la bande-annonce ci-dessous). L’occasion de rappeler qu’en France nous avons Ralamax Prod qui tente de faire quelque chose de similaire avec leur projet de film sous licence Art Libre Varsovie-Express.

Les sources du film libre Valkaama disponibles en téléchargement

Files seeded for Valkaama, "open source movie"

Michelle Thorne – 16 janvier 2009 – Creative Commons Blog
(Traduction Framalang : Don Rico)

Les fichiers sources de Valkaama, tout nouveau « film Open Source » collaboratif filmé à Cracovie, en Pologne, ont été mis en ligne. Tim Baumann, son réalisateur, a choisi de de procéder à toute la post-production de ce long métrage de façon ouverte, avec l’aide de bénévoles, qu’ils soient amateurs ou professionnels.

Nous publions sur cette page toutes nos sources audio et vidéo afin de vous donner la possibilité de les utiliser comme matière de base. Si vous souhaitez participer à ce projet, en nous aidant à terminer le film, en créant des montages, en proposant une nouvelle bande-annonce, ou si vous voulez publier quoi que ce soit en rapport avec Valkaama, veuillez nous contacter.

Valkaama est une comédie dramatique qui se déroule en Suède et en Finlande, tournée par les élèves d’une école de théâtre et des amateurs venus de Cracovie et ses environs. On y suit les pérégrinations de deux jeunes gens très différents l’un de l’autre, que le destin pousse sur la route de Valkaama. Leurs chemins finissent par se croiser, mais ils ne se rendent pas compte combien leur voyage est déjà déterminé par leurs passés respectifs.

Les films open-source et à contenu libre restent rares. Valkaama est un des premiers films à être distribué gratuitement, et à garantir en outre l’accès libre à tous les matériaux sources utilisés et créés au cours de sa production. Ce projet est placé sous des licences Creative Commons By-Sa 3.0 afin d’assurer une utilisation et réutilisation très souple du matériau produit. À presque chaque texte, image et vidéo, ainsi que qu’à tous les médias téléchargeables, est associé une licence. Les licences sont même parfois incluses dans les fichiers médias eux-mêmes.

Remixez bien !

On risque d’en parler longtemps. Imaginez-vous en effet un album de musique sous licence Creative Commons, disponible gratuitement et légalement sur tous les sites de partage de fichiers, et qui arrive pourtant en tête de meilleurs ventes 2008 sur la très fréquentée plate-forme de vente en ligne Amazon !

Voilà une nouvelle qui fait du bien et qui va à l’encontre de bon nombre d’idées reçues véhiculées notamment par certaines pontes de l’industrie culturelle (et leurs amis politiques). Une véritable petite bombe en fait, surtout en temps de crise. Les mentalités et les comportements évoluent et cela bénéficie indirectement aux logiciels libres qui sont « gratuits » ou « payants » selon que vous décidez ou non de soutenir le logiciel libre considéré^[1].

Nine Inch Nails : l’album MP3 sous licence Creative Commons s’est vendu comme des petits pains

NIN’s CC-Licensed Best-Selling MP3 Album

Fred Benenson – 5 janvier 2009 – Creative Commons Blog
(Traduction Framalang : Don Rico)

L’album de Nine Inch Nails (NIN) diffusé sous licence Creative Commons, Ghosts I-IV, a fait un bon nombre de gros titres.

Pour commencer, l’opus a été salué par la critique et récompensé par deux nominations aux Grammy Awards, ce qui atteste la qualité musicale de cette œuvre. Mais ce qui nous emballe vraiment, c’est le formidable accueil qu’a reçu cet album chez les adeptes de musique. En plus d’avoir généré plus d’un 1,6 million de dollars de gains pour Nine Inch Nails dès la première semaine et d’avoir atteint la première place du classement de Billboard dans la catégorie musique électronique, Ghosts I-IV figure à la quatrième place des albums les plus écoutés de 2008 sur Last.fm, fort de 5 222 525 écoutes.

Mais le plus enthousiasmant, c’est que Ghosts I-IV a été l’album MP3 le plus vendu en 2008 sur la plateforme de téléchargements de MP3 d’Amazon.

Songez un peu à ce que ça signifie.

Les fans de NIN auraient pu utiliser n’importe quel réseau de partage de fichiers pour télécharger légalement l’album entier, puisqu’il est sous licence Creative Commons BY-NC-SA. Beaucoup l’on d’ailleurs fait, et des milliers continueront à le faire. Alors pourquoi les fans prendraient-ils la peine de payer des fichiers identiques à ceux qui sont disponibles sur les réseaux P2P ? On peut d’abord l’expliquer la facilité d’accès et d’utilisation des pages de téléchargements de NIN et d’Amazon. Mais il y a aussi le fait que les fans ont compris qu’acheter des fichers MP3 allait directement profiter à la musique et à la carrière d’un groupe qu’ils apprécient.

La prochaine fois qu’on tentera de vous convaincre que produire de la musique sous licence Creative Commons entamerait les ventes de musique numérique, souvenez-vous que Ghosts I-IV a prouvé le contraire, et soumettez cet article à votre interlocuteur.

Dans un billet précédent, aKa constatait que les utilisateurs des licences Creative Commons (ou CC) optaient dans leur grande majorité pour les clauses les plus restrictives qu’elles proposent.

C’est justement le cas de Ryan Cartwright, auteur régulier de billets sur le Free Software Magazine (FSM), surtout connu pour The Bizarre Cathedral, sa série de comic strips ayant pour sujet le monde de GNU/Linux et des logiciels libres. Cartwright a choisi de publier ses vignettes sous la licence CC BY-NC-SA, c’est-à-dire en bon français Attribution / Pas d’utilisation commerciale / Partage à l’identique^[1].

Certains ont reproché ce choix à Cartwright, avançant que ces clauses restrictives allaient à l’encontre de l’esprit du logiciel libre et de ses quatre libertés. Dans un billet publié sur le FSM, dont nous vous proposons la traduction, Cartwright a répondu à ces critiques et justifié son choix, expliquant que selon lui des licences adaptées au code et aux logiciels ne pouvaient pas forcément s’appliquer à des œuvres de création, et que ces clauses permettaient surtout de protéger « l’utilisateur final », dans ce contexte le lecteur de The Bizarre Cathedral.

En bonus, je vous livre une traduction à la volée d’une précision sur les arguments de Cartwright publiée sur le site des Creative Commons par Rob Myers (dessinateur, auteur et bidouilleur membre de la FSF et du CC Network) :

Définir la clause SA comme une restriction comparable à la clause NC est une rengaine à la mode, mais erronée. Cartwright en convient mais finit tout de même par écrire que les deux clauses reviennent au même.
Ce n’est pas de la perspicacité, c’est un vieux bobard éculé. La clause SA empêche que soient ajoutées plus tard des restrictions supplémentaires, et la clause NC est une restriction supplémentaire. Qu’y a-t-il de difficile à comprendre ?

Pourquoi la licence de The Bizarre Cathedral est-elle « non libre » ?

Why is the Bizarre Cathedral Licence "Non-Free"

Ryan Cartwright – 21 octobre 2008 – Free Software Magazine
(Traduction Framalang : Joan, Don Rico et Olivier)

Depuis plusieurs semaines je crée les petites bandes dessinées The Bizarre Cathedral pour le magazine Free Software Magazine. Chacun d’entre eux est mis à disposition sous une licence Creative Commons BY-NC-SA : Paternité – Pas d’utilisation commerciale – Partage des conditions initiales à l’identique. J’ai récemment reçu quelques mails arguant du fait que c’est une licence « non-libre » et remettant en question l’usage que j’en fais ici. Certains de ces mails sont très polis, d’autres m’ont demandé de changer immédiatement la licence (sous-entendu « ou sinon… »). Je ne vais pas modifier la licence, et voici pourquoi.

Les quatre libertés s’appliquent au logiciel, pas à l’art

Les quatre libertés ne peuvent s’appliquer aux travaux créatifs – et particulièrement à quelque chose comme une bande dessinée. Il n’y a pas de code source que les utilisateurs pourraient étudier et modifier. Le copyleft par contre peut s’appliquer aux projets artistiques et les licences Creative Commons sont la forme la plus courante de licences copyleft appliquées à des œuvres artistiques. La FSF (à laquelle la plupart de mes correspondants semblent faire référence dans leurs arguments) indique que les licences Creative Commons sont incompatibles avec la GNU GPL ou la GNU FDL.

Chacun de ceux qui m’ont écrit à propos du choix de la licence pense que le problème réside dans la clause « Pas d’utilisation commerciale » (NC). Apparemment je passe du côté « non-libre » en stipulant aux lecteurs qu’ils ne doivent pas vendre mes travaux. Ce que je ne comprends pas, c’est comment les clauses « Partage des conditions initiales à l’identique » et « Paternité » sont plus libres. En 2004, quand le projet Xfree86 – serveur graphique X-Window – à l’époque omniprésent – a ajouté une nouvelle clause à sa licence indiquant qu’une mention de paternité dans le code ne pouvait être retirée, la communauté du logiciel libre s’est mise en action. Il me semble me souvenir que « scandale » était un mot très en vogue à l’époque. Le projet (libre) X.Org fit un fork et devint le serveur de choix. Pourquoi donc une clause de paternité est-elle libre dans le monde de l’art mais pas dans celui du logiciel ?

Tant qu’on y est, la clause « Partage des conditions initiales à l’identique » ne restreint-elle pas également la liberté ? Ne devrait-on pas avoir le droit de distribuer The Bizarre Cathedral sous la licence de son choix ? Certains clament que la licence GNU-GPL n’est pas vraiment libre car le copyleft restreint la liberté des utilisateurs à redistribuer le logiciel. La même chose peut s’appliquer aux licences CC.

Au bout du compte, la recherche de la liberté absolue pour une licence débouche sur une seule conclusion : pas de licence ou domaine public. « Faites-en ce que vous voulez », tel est le message des travaux du domaine public.

Pourquoi j’utilise cette licence « non-libre »

Il existe parfois de bonnes raisons de limiter les libertés de certains pour assurer une plus grande liberté pour tous. C’est la raison pour laquelle on met les assassins en prison – leur liberté est réduite pour assurer au plus grand nombre la liberté de vivre sans être assassiné (en tous cas, c’est la théorie). Le copyleft procède de la même logique, en réduisant certaines libertés lors de la redistribution, il assure une plus grande liberté pour les utilisateurs finaux. C’est pourquoi j’ai choisi la licence CC BY-NC-SA pour The Bizarre Cathedral.

• BY car je souhaite que les personnes qui obtiennent un seul épisode puissent venir apprécier les autres ici, à FSM.
• SA car je souhaite que tout le monde ait le même accès aux comic strips.
• NC car je souhaite que les gens puissent les apprécier sans aucune dépense. Je suis payé pour les faire, donc je veux qu’ils puissent être appréciés sans coût.

Pour préciser davantage mon sentiment sur la clause NC, je ne suis pas foncièrement opposé à la revente de mes travaux, mais par le passé j’ai découvert que certains se les appropriaient et en demandaient des sommes indécentes. Cela a réduit la portée et l’impact du projet. Plus jamais ça. Les licences CC permettent de retirer chaque restrictions que j’impose sur mes travaux sur simple demande. Donc, si vous souhaitez en vendre un, ou une œuvre dérivée, contactez-moi et nous en discuterons. Comme mentionné plus haut, je n’ai pas d’objections à ce qu’on demande de l’argent pour ce que je fais, j’exige simplement qu’on obtienne d’abord ma permission expresse.

Certains ont été un peu troublés par tout ce ramdam autour de la catégorisation « non-libre » due à la clause NC. Pour résumer, voici ce que vous pouvez faire avec les comic-strips The Bizarre Cathedral :

• Les redistribuer et les partager
• Les traduire
• Les utiliser dans d’autres projets
• Les étudier et les savourer

Vous pouvez faire tout ça à condition de :

• indiquer la source des originaux
• ne pas faire payer ceux à qui vous les proposez

La liberté a énormément de valeur à mes yeux : j’écris du logiciel libre, j’écris pour Free Software Magazine, et j’encourage la liberté dans la vie de tous les jours. Je suis en désaccord sur le fait que la clause NC à elle seule rend « non-libre » cette licence. Je dirais plutôt « moins libre » mais je maintiens qu’en soi elle n’est pas vraiment moins libre que les clauses BY ou SA ou que le copyleft. La GPL est-elle « non-libre » parce qu’on ne peut pas l’associer avec une librairie non copyleftée, ou est-elle seulement moins libre que la LGPL ?

Pour finir, et pour que ce soit clair pour tout le monde, The Bizarre Cathedral restera sous licence CC BY-NC-SA pour l’instant.

GMail, Google Apps, Zoho, Flickr, Del.icio.us, Box.net, Wuala, DropBox, Plaxo… Ça vous parle ? Vous savez, ces applications en ligne (ou Web Apps) pratiques et séduisantes qui poussent comme des champignons aux quatre coins de la Toile, souvent accompagnées de la mention beta pour faire hi-tech. On a même trouvé un terme pour englober tout ce petit monde, le très à la mode Cloud Computing, soit l’informatique dans les nuages ou dématérialisée^[1].

Que celui qui n’a pas un compte chez l’un de ces services en ligne me jette la première pierre. Reconnaissons qu’il est fort commode, notamment pour qui travaille sur plusieurs postes ou de façon nomade, de pouvoir accéder à ses courriels, à ses documents et à certaines données depuis n’importe quel PC (voire téléphone mobile) à condition de disposer d’une connexion Internet.

Mais n’est-on pas en droit de s’inquiéter de savoir que tant de nos données se baladent on ne sait trop où dans l’espace virtuel ? Plaxo, par exemple, avait été critiqué à ses débuts car assez porté sur le spam et l’exploitation peu scrupuleuse des carnets d’adresses qu’on lui confiait (même si ce service a depuis redressé la barre). Quid des documents créés avec Google Docs, des fichiers conservés chez Box.net, des mails échangés avec GMail ? De plus en plus de grands groupes ou de start-ups se lancent sur ce marché apparemment juteux et se battent pour posséder nos données.

Il y a quelque temps déjà, plusieurs voix s’élevaient contre contre ces services en ligne : Larry Ellison, le fondateur d’Oracle, qualifiait le Cloud Computing de mode, et Richard Stallman, dans un entretien accordé au quotidien anglais The Guardian, allait plus loin en taxant ces services en ligne de pièges. Stallman mettait en garde les utilisateurs contre ces Web Apps et le stockage de données personnelles sur les serveurs d’entreprises commerciales : selon lui, confier ses données à de tels services revient à en perdre le contrôle et pose donc les mêmes problèmes que l’utilisation des logiciels propriétaires.

Stallman, qui n’a pas l’habitude de faire dans la nuance, recommandait donc de n’utiliser aucun de ses services et de leur préférer nos bonnes vieilles applis en dur sur lesquelles nous gardons tout contrôle. (Nul doute qu’il pensait par là à la Framakey…)

Tim O’Reilly, dans son blog, s’est lui aussi penché sur la question et a publié un billet assez fourni, dans lequel il estime qu’il faudrait appliquer au Cloud Computing les principes de l’Open Source et rappelle qu’il avait déjà mis en garde contre le verrouillage du Web, pourtant basé sur des programmes et outils Open Source, par des applications Web 2.0.

Cette question de la confidentialité, du contrôle des données et de l’indépendance de l’utilisateur face au logiciel concerne tous ceux qui ont un usage intensif du Web et de l’outil informatique, mais semble cruciale pour les adeptes du logiciel libre, très sensibles à ces questions. Comme dans le software classique, certains acteurs du Cloud Computing proposent des solutions libres. C’est le cas de Clipperz, qui a développé un gestionnaire de mots de passe et d’informations personnelles sous licence GPL.

Sur le blog de Clipperz , un des auteurs appelle les utilisateurs et les développeurs à agir pour préserver la liberté et la confidentialité dans les nuages, et propose quelques mesures pour que les applications Web 2.0 soient en accord avec les valeurs du libre, du point de vue des licences et du comportements des navigateurs Internet par exemple. On y retrouve par billet interposé Richard Stallman, avec qui l’auteur s’est entretenu et qui y va lui aussi de ses conseils.

Histoire de redescendre un peu sur terre après tant de temps passé dans les nuages, nous vous présentons donc la traduction de ce billet, réalisée par notre équipe Framalang.

Liberté et protection de la vie privée en ligne : agissez !

Freedom and Privacy in the Cloud – a call for action

Marco – 30 mai 2008 – Clipperz
(Traduction Framalang : Olivier, Burbumpa et Don Rico)

Ce message traite de la liberté. La liberté de posséder vos données et la liberté d’utiliser des logiciels libres. Vous devriez aussi pouvoir exiger ces libertés et en jouir quand vous utilisez des applications web.

Si vous soutenez le mouvement du logiciel libre, vous pouvez facilement opter pour Gimp au lieu de Photoshop, pour Firefox au lieu d’Internet Explorer. Vous pouvez également protéger le caractère privé de vos données en utilisant les outils de cryptage disponibles (GPG, TrueCrypt…). Mais dès qu’il s’agit d’applications web, tout se complique.

Les avantages des applications web – ou web apps – (accessibles partout et tout le temps, mises à jour transparentes, stockage fiable, …) sont nombreux, mais bien souvent les utilisateurs perdent la liberté d’étudier, de modifier et de discuter du code source qui fait tourner ces web apps.

De plus, nous sommes contraints de confier nos données aux fournisseurs de ces web apps (marque-pages, documents rédigés, copies des discussions, informations financières et désormais… dossiers médicaux) qui ne résident alors plus sur nos disques durs mais qui sont rangés quelque part dans les nuages. Ce n’est pas vraiment une situation confortable de devoir choisir entre aspect pratique et liberté.

Que l’on soit clair : les web apps sont formidables et je les adore. Mais je pense que le moment est venu de réclamer plus de liberté et de confidentialité. Voilà comment nous pouvons obtenir ces deux résultats en trois étapes.

1. Choisissez l’AGPL

Quelle est l’importance de l’AGPL ? Si vous êtes un fournisseur de services et que vos services s’appuient sur des logiciels placés sous licence AGPL, vous devez rendre le code source disponible à toute personne utilisant ce service. La FSF suggère dans ses directives de placer un lien Source qui renvoie à une archive contenant le code source directement dans l’interface de l’application web.

(Ne me demandez pas pourquoi la communauté des logiciels libres a mis tant de temps à réagir !)

Mesures

• Aider Clipperz à mettre au point une suite AGPL : un ensemble d’applications web répondant aux besoins les plus courants.
• Cette suite devrait comprendre : un traitement de texte, un logiciel de discussion, un gestionnaire de mots de passe, un carnet d’adresses, un pense-bête, un calendrier, un gestionnaire de marque-pages … Et chaque web app devra être soumise à la licence AGPL ! Vous pourrez alors oublier Google, del.icio.us, Plaxo, Meebo … à moins qu’ils ne se mettent à l’AGPL aussi.
• Nous avons déjà deux candidats pour certains postes (Ajax Chat pour les discussions en ligne et, bien sûr, Clipperz pour le gestionnaire de mots de passe), mais la plupart des places sont encore à pourvoir !
• Aider Clipperz à diffuser les bienfaits de l’AGPL auprès des développeurs de projets web open-source. Demandez-leur de se convertir à l’AGPL.

2. Ajoutez-y une pointe de divulgation nulle de données

Les développeurs Web, comme les utilisateurs, connaissent encore assez peu les possibilités offertes par le chiffrage via un navigateur pour rendre les applications web aussi sécurisées et confidentielles que les logiciels classiques.

Chez Clipperz, nous voulons apporter une nouvelle vision que nous appelons les web apps à divulgation nulle de données (description plus détaillée ici) qui associe l’idée d’un hébergement auquel même l’hébergeur n’a pas accès et un ensemble de règles basées sur le credo confidentialité absolue.

Ce nom est aussi bien un hommage au chiffrage (une garantie de divulgation nulle de données est un protocole de chiffrage standard) que la promesse d’une relation particulière entre l’utilisateur et le fournisseur d’application. Le serveur hébergeant la web app peut ne rien savoir sur ses utilisateurs, pas même leurs identifiants ! Clipperz applique cette vision pour mettre en œuvre son gestionnaire de mots de passe en ligne.

Mesures

• Appliquer les techniques divulgation nulle de données à chaque composant de la suite AGPL. Convertir une application web à l’architecture divulgation nulle n’est pas simple, mais chez Clipperz nous avons développé un savoir-faire important et nous serons heureux de partager aussi bien ces connaissances que le code de base.

Nous pourrons ainsi finalement jouir d’un traitement de texte en ligne qui ne pourra pas lire nos documents, un logiciel de discussion qui n’enregistrera pas nos conversations, un wiki sur lequel on pourra conserver sans crainte des données importantes, etc.

• Établir et maintenir à jour une liste des Fournisseurs de Service d’Application (NdT : ASP pour Application Service Provider en anglais) qui hébergent la suite complète sous AGPL. Cette référence sera utile à tous ceux qui attachent de l’importance aux logiciels libres et à la confidentialité mais ne possèdent pas les compétences et les ressources pour faire tourner des web apps sur leur propre serveur.

3. Créer un navigateur plus intelligent

On y est presque, mais il nous reste encore à fournir aux utilisateurs de web apps un environnement encore plus flexible et sécurisé. Dans la pratique, du fait de l’architecture des web apps à divulgation nulle de données, le serveur réalise de façon générale les tâches suivantes :

• charger le code Javascript dans le navigateur de l’utilisateur (charger le programme) ;
• authentifier l’utilisateur (optionnel et par un protocole à divulgation nulle de données)
• rapatrier et stocker les données chiffrées demandées par le navigateur de l’utilisateur.

Logiciel libre est synonyme de contrôle total de ce qui se passe sur mon ordinateur. Se posent alors deux questions :

• Comment faire tourner une version modifiée du code Javascript à la place de celui chargé par le serveur ?
• Comment être alerté des modifications apportées au code Javascript que le serveur envoie à mon navigateur ?

J’ai récemment eu l’immense honneur d’échanger mes idées avec Richard Stallman lui-même au sujet de ces problèmes, et il a suggéré une solution futée pour les résoudre tous les deux.

Stallman propose d’ajouter une fonctionnalité au navigateur qui permette à l’utilisateur de dire : « Quand tu charges l’URL X, utilise le code Javascript de l’URL Y comme s’il venait de l’URL X ». Si l’utilisateur fait appel à cette fonctionnalité, il peut utiliser sa propre copie du code Javascript et peut toujours échanger des données avec le serveur hébergeant l’application web.

Un navigateur possédant cette capacité pourrait aussi facilement vérifier si le script Java de l’URL X est différent du script Java sauvegardé à l’URL Y. Si l’utilisateur fait confiance à la version courante du code Javascript de l’URL X, il peut en faire une copie à l’URL Y et sera ainsi alerté de tout changement. Cette solution protège l’utilisateur du code malveillant qu’il pourrait exécuter sans le savoir dans son navigateur, du code qui pourrait voler ses données et détruire l’architecture à divulgation nulle d’information.

Mesures :

• Écrire des extensions pour les principaux navigateurs libres (Mozilla, Webkit, …) qui mettent en œuvre l’idée de Stallman.

Militer pour l’adjonction de la "suite AGPL" et des navigateurs améliorés pré-cités dans les distributions GNU/Linux.

• Continuez à lire ce blog où je posterai de nouveaux articles régulièrement.
• Faites-moi part de vos commentaires et suggestions.
• Faites passez le message au travers de vos blogs, de vos messages sur les forums, …
• Faites un don.

Et le meilleur pour la fin : comment nommeriez-vous cet ambitieux projet ? Faites-moi part de vos idées dans les commentaires !

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.