C’est notre ligne de front à nous. À Framasoft on n’est pas de gauche ou de droite mais on est clairement pour la défense des biens communs que certaines logiques économiques tentent de s’approprier à grands coups de lois et de brevets dont on ne me fera plus croire qu’ils sont nécessairement là pour protéger et favoriser l’innovation.

Le bien commun qui nous est cher c’est évidemment le logiciel libre mais fort de notre expérience et de notre culture, il est difficile de ne pas être également sensible aux autres champs qui sont mis à mal actuellement, à commencer par l’écologie qui sur le même modèle humaniste et résistant tente de préserver rien moins que notre planète.

La traduction que nous vous proposons aujourd’hui est une illustration aussi malheureuse qu’emblématique de ces trop nombreux jusqu’où iront-ils ? puisqu’on touche ici directement à notre patrimoine, à notre bien-être et à notre santé. Il s’agit d’évoquer les tentatives de captation marchande du… yoga, avec une pertinente mise en parallèle sur le situation de l’industrie pharmaceutique^[1].

L’occasion pour moi de rappeler la sortie en poche de l’excellent livre Du bon usage de la piraterie de Florent Latrive dont le sujet est au cœur même de ce qui est exposé ici et qu’il est donc tout à fait recommandé de parcourir pour aller plus loin et ne pas se réveiller un jour pour constater que nos moindres faits et gestes appartiennent désormais à un je-ne-sais-quel-obscur ayant droit !^[2]

Pouvez-vous breveter la sagesse ?

Can you patent wisdom?

Suketu Mehta – International Herald Tribune – 7 mai 2007
(Traduction Framalang : Mben, Penguin, Olivier et Daria)

J’ai grandi en voyant mon père se tenir sur la tête tous les matins. Il faisait le sirsasana, une position de yoga qui explique qu’il ait l’air si jeune à 60 ans passés. Maintenant il serait peut-être obligé de payer une redevance à un détenteur de brevet américain s’il enseignait le secret de sa bonne santé aux autres.

L’office des brevets et des marques américain a publié 150 copyrights liés au yoga, 134 brevets sur des accessoires de yoga, et 2315 marques de yoga. Il y a beaucoup d’argent à gagner en se tordant comme un bretzel — 3 milliards par an dans la seule Amérique. C’est un mystère pour la plupart des Indiens que quelqu’un puisse faire autant d’argent en enseignant un savoir qui n’est pas supposé être acheté ou vendu tel de vulgaires saucisses.

Le gouvernement indien prend la chose au sérieux. Il a mis en place une cellule qui est en train de cataloguer la connaissance traditionnelle, y compris les remèdes ayurvédiques et les centaines de poses de yoga, pour les empêcher d’être piratés et copyrightés par les revendeurs étrangers. Les données seront traduites à partir du Sanskrit ancien et des textes tamouls, stockées numériquement, et disponibles dans cinq langues internationales, de sorte que les offices des brevets des autres pays puissent voir que le yoga n’est pas originaire d’une communauté de San Francisco.

Il est important de remarquer que les premiers à breveter la sagesse traditionnelle indienne sont des Indiens, la plupart du temps à l’étranger. Nous savons saisir une occasion lorsqu’elle se présente et nous avons exporté des générations de gourous, experts dans la vente ambulante de l’épanouissement pour un dollar. Mais, en tant qu’Indiens, ils devraient savoir que l’idée même de faire breveter la connaissance est une grossière violation de la tradition du yoga.

En Sanskrit, « yoga » signifie « union ». Les Indiens croient en un esprit universel — brahman — dont nous sommes tous une partie, et qui médite éternellement. Chacun a accès à cette connaissance.

La connaissance dans l’Inde antique a été protégée par les règles des castes, et non celles de la loi ou de l’argent. Le terme « propriété intellectuelle » était un oxymore : l’intellect ne pouvant être la propriété de quiconque. Peut-être est-ce pour cette raison que les Indiens ne se sentent pas obligés de payer pour la connaissance. Des copies pirates de mon livre sont ouvertement vendues dans les rues de Bombay, pour le quart de son prix officiel. La plupart des intrigues et des musique des films de Bollywood sont tirées d’Hollywood.

Pourtant, les Indiens sont irrités à chaque fois qu’ils entendent les rapports – souvent pompeux – des Occidentaux volant leur sagesse ancienne à travers le mécanisme du droit d’auteur. Leurs craintes sont peut-être exagérées, mais elles sont répandues et reflètent l’expérience mitigée de l’Inde avec la mondialisation.

Les entreprises pharmaceutiques occidentales se font des milliards avec des médicaments qui ont souvent été au départ découvert dans des pays en voie de développement. Mais les plantes médicinales comme la margose ou le curcuma, qui sont connus pour être efficaces contre tout, du diabète aux hémorroïdes, ne rapportent rien aux pays dont les sages en ont en premier isolés les vertus. Le gouvernement indien estime que dans le monde, 2000 brevets basés sur des médicaments traditionnels indiens, sont déposés chaque année.

Les médicaments et le hatha yoga ont le même but : nous aider à mener une vie en meilleure santé. L’Inde a offert au monde le yoga gratuitement. Il n’est pas étonnant que beaucoup de personnes dans le pays trouve que le monde devrait rendre la politesse en rendant disponible à faible coût des médicaments pouvant sauver des vies, ou au moins laisser les entreprises indiennes fabriquer des génériques à faible coût. Si la position du lotus appartient à tout l’humanité, alors la formule du Glivec doit l’être aussi, le médicament pour la leucémie dont le brevet sert de base au procès d’une entreprise pharmaceutique Suisse contre le gouvernement indien.

Pendant des années, la loi indienne a autorisé ses entreprises pharmaceutiques à répliquer des médicaments brevetés en Occident et les vendre à un prix plus faible aux pays trop pauvres pour pouvoir se les offrir autrement. De cette façon, l’Inde a fourni la moitié des médicaments utilisés par les personnes séropositives dans les pays en voie de développement. Mais en mars 2005, le parlement indien, sous la pression de mettre le pays en accord avec les lois sur la propriété intellectuelle de l’Organisation Mondiale du Commerce, a voté une loi déclarant illégale la production de copie générique de médicaments brevetés.

Cela a mis des médicaments anti-rétroviraux pouvant sauver des vies hors de portée de la majorité des 6 millions d’Indiens qui ont le SIDA. Les multinationales du médicament qui protègent bec et ongles leur brevets s’opposent aux tentatives de l’Inde de modifier les règles de l’Organisation Mondiale du Commerce pour protéger leurs remèdes traditionnels. Il y a plus que simplement de l’argent dans la bataille. Il y a aussi la perception que le système commercial mondial est injuste, que les dés sont pipés en défaveur des pays en voie de développement. Si la copie des médicaments occidentaux est illégal, alors le brevetage du yoga doit l’être aussi. Il s’agit également de piratage intellectuel, ou alors la propriété intellectuelle marche sur la tête.

Suketu Mehto est l’auteur de "Maximum City: Bombay Lost and Found."

Je ne sais si c’est un regret mais je ne suis pas développeur. Du coup ma connaissance du logiciel libre est exogène et non endogène et par là-même inévitablement partielle. C’est pourquoi je suis souvent à l’affût d’informations sur les modes opératoire des projets communautaires libres qui me permettent de combler certaines lacunes et parfaire ma culture en la matière. J’y trouve également des sources d’inspiration pour notre propre projet qui est celui d’animer collectivement le réseau Framasoft avec quelque part le même état d’esprit qu’une communauté de développeurs open source.

Tout ça pour dire que cette nouvelle traduction concerne avant tout ceux qui voudraient rejoindre pour la première fois la communauté d’un logiciel libre mais également tous ceux qui en fins observateurs souhaitent un peu mieux comprendre comment ça marche de l’intérieur. Parce qu’effectivement, et Framasoft est là pour en témoigner en aval, force est de constater que le logiciel libre ça marche et même plutôt bien 🙂

Nous avons conservé tout le long l’expression open source utilisée par l’auteur. Même si parfois sujet à précision voire controverse, elle est ici pour nous pleinement synonyme de logiciel libre (free software).

Je signale au passage que sur le même thème notre dynamique petite équipe de traduction (baptisée Framalang) a entrepris une autre chantier autrement plus ambitieux : traduire le livre de Karl Fogel Producing Open Source Software dont nous espérons la matérialisation en un joli Framabook dans le courant de l’été^[1].

10 règles d’or pour démarrer avec l’open source

10 golden rules for starting with open source

Tobias Schlitt – 19 avril 2007
(Traduction Framalang : Daria, Olivier et Yostral)

Êtes-vous nouveau en open source ? Si ce n’est pas le cas, vous rappelez-vous encore ce que c’était, quand vous avez commencé pour la première fois avec l’open source? J’ai récemment essayé de me rappeler ces jours… c’était en 2001, quand j’ai découvert PEAR et que, peu de temps après, j’ai commencé à travailler sur mes propres paquets pour PEAR…

Je suis presque sûr d’avoir violé au moins 9 des 10 règles que je vais essayer d’écrire ici, règles que vous devriez connaître et prendre à coeur si vous voulez faire partie de la communauté open source. En tout cas, vous devrez garder ces règles en tête si vous voulez entrer dans la communauté PHP, mais je suis presque sûr que cela s’applique aussi à d’autres communautés.

Si vous voulez vous lancer tout de suite dans le développement open source, soyez sûr de lire les règles suivantes avant d’aller plus loin. Je suis sûr que vous avez beaucoup, beaucoup de grandes idées à l’esprit et que vous ne pouvez pas attendre pour en parler et les réaliser. Mais, prenez d’abord une grande respiration et lisez les règles suivantes, pensez-y, prenez-les à coeur, puis recommencez et repensez-y encore…

1. Collez à votre niveau de Karma

L’open source n’est pas une démocratie. Vous avez entendu autre chose ? C’est faux. Gardez toujours à l’esprit : l’open source n’est pas une démocratie. Chaque développeur a un certain niveau de Karma (inexprimé et inexprimable), ce qui lui permet de décider (ou même de dicter) des choses et d’utiliser certaines infrastructures de la communauté (comme leur système de versionnage , leurs serveurs…). Pensez au Karma comme à votre niveau de points dans un jeu de rôle. Plus le nombre de niveau auxquels vous avez joué augmente, plus vous résolvez des énigmes, plus votre niveau de Karma s’élève. Mais prenez garde, il peut aussi baisser si vous n’agissez pas correctement.

Cela étant, si vous êtes nouveau dans cette communauté, votre niveau de Karma est de 0, par défaut. Vous devrez toujours garder cela en tête. Donc, qu’est-ce que c’est tous ces trucs autour du Karma ? Le Karma représente essentiellement la confiance que la communauté a en vous. Il n’est pas possible de mesurer le Karma avec un nombre ou même de le deviner, parce qu’il y a tellement de facteurs influençant votre Karma, et votre niveau de Karma est différent pour chaque individu de la communauté. Par exemple votre niveau d’expérience technique influence habituellement grandement votre Karma : plus vous en savez à propos du sujet de votre projet et au sujet de l’environnement technique, plus votre Karma sera élevé. Un autre facteur est la quantité de travail que vous investissez dans le projet : si vous êtes membre de ce projet depuis longtemps et que vous avez déjà passé des milliers d’heures à travailler dessus, votre Karma sera probablement élevé aussi.

Il y a beaucoup d’autres facteurs qui influencent votre Karma de développeur open source, comme vous allez l’expérimenter dans les prochaines semaines et prochains mois. Ce que vous devez avant tout vous rappeler est ceci : si vous êtes nouveau dans la communauté votre niveau de Karma est de 0 (ou proche). Pour augmenter votre Karma vous avez besoin de montrer à la communauté que vous êtes digne de confiance. Vous y parviendrez en respectant simplement les 9 règles suivantes.

2. L’information est le Karma

La première chose que vous voudriez probablement faire c’est poser une question ou proposer une idée cool à la communauté. Il y a de bonnes chances pour que vous le fassiez sur une liste de diffusion, qui est le moyen de communication le plus commun dans le monde de l’open source. Evitez de faire cela tout d’abord ! Les gens se fatiguent vraiment très vite si vous leur demandez quelque chose qui est évident à leurs yeux ou si vous proposez une idée/posez une question qui a été proposée/posée par d’autres avant (surtout si cela est déjà arrivé plusieurs fois).

Donc, que devrez-vous effectivement faire avant de poster une question ? Cherchez l’information ! Essayez Google, les sites des projets, les archives des listes de diffusion, la sphère des blogs du projet et toutes les ressources que vous pourrez imaginer. N’effectuez pas une seule recherche, mais affinez votre recherche pour voir s’il n’y a vraiment rien de relatif à votre question. Il n’y a rien? Essayez encore de chercher ! Il n’y a vraiment rien ? Ok, alors allez-y et écrivez votre billet. Mais soyez sûr de lire les 8 règles suivantes avant de le faire !

Et que faire si vous avez une idée ? Faites la même chose que ce que vous devez faire pour les questions ! Regardez si quelqu’un d’autre n’a pas eu la même idée ou une idée similaire. Vous ne trouvez rien ? Vraiment sûr ? Faites alors des recherches sur le sujet. N’écrivez pas simplement quelque chose comme « Ne serait-il pas cool de… » ou « J’ai eu l’idée de… ». Effectuez des recherches sur le sujet dont vous voulez parler avec pédantisme. Comment d’autres projets (peut-être dans d’autres langages ou sur d’autres systèmes d’exploitations) résolvent-ils la question ? N’y a-t-il rien de similaire qui existe ? Pensez aux autres besoins des utilisateurs. Est-ce que c’est quelque chose spécialement pour vous ? Alors commencez à écrire une prétendue proposition. Choisissez un sujet explicite pour votre billet (pas seulement « J’ai une idée » ou quelque chose comme ça). Commencez à écrire une spécification : quel est votre problème ? Quelle est votre idée pour le résoudre ? Comment cela s’intégre-t-il dans le projet ? Qu’est-ce qui est nécessaire pour le faire ? Soyez prolixe sur tout cela. Dans la plupart des cas, les autres personnes ont une perspective complètement différente de la situation globale.

3. S’y habituer

Un point très important avant que vous ne commenciez à devenir un « contributeur » est de vous habituer à ce avec quoi vous travaillez et au sujet dont vous parlez. Vous n’aurez probablement jamais utilisé certains des outils qui sont employés couramment pour le projet, ou bien les outils utilisés sont différents de ceux dont vous avez l’habitude. Habituez-vous à ces outils et, plus important encore, habituez-vous au projet lui-même. Connaître tous les processus qui sont mis en oeuvre dans votre communauté est un point important. Devenir un habitué des outils qu’ils utilisent l’est encore plus.

L’un des ces outils importants est GNU patch, un outil qui applique des modifications (communément appelé un diff pour difference) à une version existante du code. Générer un patch est en général réalisé avec l’outil GNU diff. Si vous voulez produire un patch pour du code, vous aurez probablement besoin de cet outil. Beaucoup de projets utilisent un système de versionnage pour archiver leur code source. Les programmes les plus courants sont CVS et son petit frère plus récent SVN. Habituez-vous à ces systèmes et utilisez les activement ! Ces deux systèmes vous autorisent à extraire (check out en anglais) une certaine version de la source, à la manipuler et automatiquement à génerer un diff pour vos changements.

Si vous avez déjà fait ça, continuez et lisez les 7 prochaines règles !

4. Ne vous surestimez pas

Vous êtes un geek cool. Vous faites du développement depuis des années et, dans votre entourage, vous êtes un des gars les plus intelligents. C’est super. Mais ne présumez pas que cela vaut aussi pour le projet que vous voulez rejoindre. L’open source est habituellement réalisée par des gens qui sont extrêmement intéressés par le sujet, qui sont parfois beaucoup plus intelligents que vous et qui ont probablement une centaine de fois plus d’expérience que vous dans ce sujet spécifique. Restez calme et soyez plutôt timide qu’arrogant. Réfléchissez aux réponses données par les membres du projet, même si vous les trouvez stupides de prime abord ou si elles vous semblent grossières. Etudiez les sujets dont les gens parlent avant d’écrire une réponse. Prenez les réponses à vos demandes sérieusement, même si elles peuvent vous sembler illogiques.

5. Agir signifie Karma

Comme dit auparavant, le Karma est une valeur appréciable, qui dépend d’une centaine de facteurs. Un de ces facteurs est la comparaison entre ce que vous dites et ce que vous faites. Si vous avez une idée pour un projet et que vous êtes capable de la réaliser : allez-y et mettez la en œuvre. Si vous avez besoin d’une fonctionnalité, vous la ferez probablement de toute façon et utiliserez votre patch pour votre usage personnel. Si cela fonctionne, allez à la règle 2 et attachez votre patch à la proposition que vous avez écrite ! Cependant, avant d’agir, finissez de lire les 5 règles suivantes.

6. Soyez amical et ouvert

La plupart des développeurs open source avec qui vous traiterez auront probablement fait de l’open source depuis des années. Ils sont déjà stressés par des utilisateurs qui attendent que quelque chose se passe mal et par les nouveaux développeurs qui ne collent pas aux règles que vous êtes en train de lire. Souvenez-vous de ceci quand vous lisez leurs mails. Ces gars ne sont pas inamicaux ou grossiers, ils sont seulement occupés et ennuyés. Vous arriverez dans un état, où vous aurez à lire 20 listes de diffusion avec des milliers de posts, garder un oeil sur le grand nombre de lignes de code, intervenir dans beaucoup de discussions et interagir avec beaucoup de personnes différentes. Quand vous lirez les mails, prenez juste l’essence objective des mots que vous lisez et ignorez la tonalité que vous pourriez ressentir.

7. S’énerver est mauvais !

Cette règle^[2] est presque la même que la règle 6, mais c’est toujours très important. Lisez chaque conversation avec attention. Je connais ce sentiment assez bien, lorsque vous pensez que votre interlocuteur « est un idiot ». Il ne l’est pas ! Il n’y a pas d’idiot ici. Il a juste un point de vue différent du votre, ou a une base technique différente. Restez calme, réfléchissez à votre réponse pendant quelques minutes/heures/jours, puis écrivez-la quand vous ne serez plus en colère. Essayez d’énoncer vos arguments avec des mots polis et expliquez en détails pourquoi vous avez une opinion différente. Si vous sentez votre colère revenir pendant que vous écrivez, gardez votre réponse et revoyez-la encore plus tard. Les discussions enflammées sont vraiment une mauvaise chose et polluent les canaux de communication de votre projet. Elles ne cesseront jamais d’être mais c’est ainsi. La seule chose que vous pouvez faire contre cela, c’est de ne pas y prendre part.

8. Respecter le code étranger

Chaque partie du code que vous verrez a été écrite dans un but précis. Si vous parcourez le code d’autres personnes, vous penserez souvent « Quoi !!! ». Ne changez pas immédiatement le code pour qu’il fonctionne comme vous l’attendez personnellement. Prenez contact avec le développeur qui a écrit le code (par exemple en utilisant « svn blame », voir la règle 3). Discutez de votre point de vue avec lui. Ne faites pas cela en public tant que cela n’affecte pas une grande partie du projet. Si vous le faîtes, référez-vous au système de communication générale de votre projet et annoncez le problème à cet endroit. Souvenez-vous à tout prix des règles 2, 3 et 4. Si vous ne pouvez pas décider si un problème y a sa place, prenez contact avec des gens du projet que vous connaissez déjà et demandez-leur de l’aide. Si vous êtes sympa et que vous leur décrivez ce que vous voulez, ils vous aideront sûrement.

9. N’attendez rien

L’open source signifie habituellement travailler sur la base du volontariat. Ces gens fournissent (pour la plupart) des logiciels gratuits, donc ils ne font pas d’argent avec ce qu’ils réalisent de leurs mains. Ils le font pour différentes raisons. Certains sont juste idéalistes, d’autres veulent simplement partager quelque chose, d’autres veulent se faire connaître, d’autres veulent faire de l’argent avec les services qu’ils fournissent en plus et d’autres encore ont tout en même temps à l’esprit ou encore d’autres raisons… Quelle que soit leur raison pour faire de l’open source, ils le font gratuitement. Gardez toujours cela à l’esprit quand vous leur soumettez une requête.

Par exemple « les demandes de fonctionnalités » sont une bonne chose. Elles donnent aux développeurs une idée de ce dont ils pourraient aussi avoir besoin. Cependant, la majorité des développeurs open source implémenteront seulement les fonctionnalités dont ils ont aussi besoin, ou dans lequel ils voient un défi technique intéressant. Ne soyez pas ennuyé s’ils refusent d’implémenter une fonctionnalité dont vous auriez besoin. C’est leur strict droit de le refuser, jusqu’à ce que vous les payez pour le faire. Si une demande de fonctionnalité est refusée ou n’est pas implémentée, allez-y, implémentez-la vous-même ou envisagez de payer un développeur pour son implémentation. Les développeurs open source ont aussi besoin d’argent pour vivre et ils ne refuseront probablement pas de vous fournir un patch en échange d’un salaire. Quoi qu’il en soit, ils pourraient encore ne pas inclure votre idée dans leur projet ou l’implémenter d’une façon différente. Ne soyez pas fâché ! Ils ont le droit de le faire ! Essayez de faire avec leur conclusion ou essayez de les convaincre de le faire différemment, mais souvenez-vous toujours de respecter les 8 règles précédentes quand vous le faites.

Peu importe ce qui a été décrit avant, reconsidérez toujours votre idée plusieurs fois. Attendre quelque chose d’un développeur open source n’est pas la manière dont les choses marchent habituellement. Le faire vous-même est ce qui habituel.

10. Apprendre est tout

L’idée la plus importante derrière l’open source est l’apprentissage. Les gens fournissent leurs sources de manière ouverte pour permettre à d’autres personnes d’apprendre de leurs sources et d’apprendre des contributions des autres. C’est la même chose pour n’importe quel savoir ou connaissance fourni à propos du projet. Regardez simplement cet article et réfléchissez aux raisons pour lesquelles j’ai pu l’écrire ? C’est exact, c’est parce que je veux partager mon expérience de la communauté open source avec toute personne la découvrant et parce que je veux avoir des retours des autres, pour voir où je pourrais encore avoir des faiblesses et ce à quoi je n’ai pas prêté attention, pour le moment.

Soyez sûr d’apprendre quelque chose de chaque ligne que vous lisez, que ce soit du code ou une conversation. Vous pouvez apprendre de tout le monde, même si cela vous permet seulement d’apprendre comment une chose ne doit pas être faite…

Pendant que j’écrivais ces 10 règles, que je considère très importantes à lire pour chaque nouveau développeur open source, j’avais déjà d’autres règles en tête. Mais restons en là avec ces 10 règles, pour donner un point de départ. Si je pense à d’autres choses qui s’avèreraient être un ajout réellement intéressant, je les ajouterai plus tard. Nous verrons. Merci pour tous vos retours et j’espère que ce billet sera utile à chaque nouveau…

Kore m’a aussi conseillé de me référer à De la bonne manière de poser les questions, qui lui a rappelé ce billet, lorsqu’il le relisait. Je n’ai pas lu cet article avant (mais peut-être un autre semblable), mais cela a vraiment l’air approprié. Si vous avez d’autres ressources, n’hésitez pas à laisser un commentaire !

Pensez-vous par exemple que la pléthore de distributions GNU/Linux soit une qualité de l’OS et le témoignage de la vivacité de sa communauté ou bien au contraire qu’on aboutit à une situation confuse où trop de choix tue le choix ?

Sur cette thématique assez classique de la pertinence de la pluralité du choix, voici la traduction d’un article (un peu technique mais fort intéressant) d’un développeur américain James Turner sur le site d’O’Reilly.

Extrait :

Alors, quels sont les avantages d’une monoculture et pourquoi Microsoft gagne-t-il si souvent quand les gens doivent choisir une plateforme ? C’est en grande partie à cause de ce que la communauté open source voit comme une force mais que ceux qui essaient de faire leur boulot dans le monde réel voient comme une faiblesse. Nous célébrons la diversité de choix disponibles pour résoudre un problème et nous appelons cela la liberté. Les directeurs informatiques et les patrons de la branche informatique (IT managers et CIOs en anglais) y voient du chaos, de la confusion et des doutes.

Pour ceux qui comme nous sont attachés à la liberté, avoir le choix est bien entendu une valeur fondamentale. Mais il peut en aller autrement dans le monde pragmatique de l’informatique professionnelle où c’est souvent l’efficacité qui est privilégié. Et alors dans ce contexte Microsoft conserve de sérieux atouts avec ses offres monoculturelles sécures et rassurantes^[1].

Les vertus de la monoculture

The Virtues of Monoculture

James Turner – 24 avril 2007 – Opinion
(Traduction Framalang : Don Rico et Yostral)

Je ne dis certainement rien de nouveau ici, mais j’ai pensé que je pourrai partager quelques réflexions sur les raisons qui poussent les gens à suivre la voie Microsoft. J’ai récemment fait quelque chose dans mon travail de tous les jours auquel je pensais depuis longtemps, mais pour lequel je n’ai jamais vraiment pris la peine d’aller jusqu’au bout, je me suis inscrit pour participer à un projet Microsoft-centrique et pour apprendre le .NET.

J’avais fait des tentatives avortées par le passé pour apprendre à coder dans l’Univers Microsoft. J’avais fait un essai à la sale époque des COM, mais le nombre de numéros qu’on me demandait d’exécuter me demandait trop d’effort par rapport à ce que j’étais alors prêt à consentir. Depuis j’ai gardé ce mauvais goût au fond de la bouche et j’ai refusé d’ajouter une seul compétence Microsoft à mon répertoire, même si cela représentait parfois un vide dans mon curriculum vitæ.

J’ai souvent travaillé dans des environnements où il y avait ce Monsieur Microsoft, l’évangéliste qui vous répète sans cesse à quel point ça aurait été plus facile en .NET. Je les ai classés dans la catégorie adorateurs de Gates buveurs de Tang*. Mais, à la fin de la journée, je me suis dit que si je devais les critiquer je devais vraiment comprendre leur monde. Connais ton ennemi et tout ça.

J’ai passé la semaine dernière à apprendre dans l’ordre C#, .NET et VSTO (c’est Visual Studio Toolkit for Office, si les abréviations de Microsoft ne sont pas votre tasse de thé). J’ai utilisé le livre Learning C# de chez O’Reilly et j’ai fait quelque chose qui m’arrive rarement : je m’y suis mis de manière très méthodique (du moins pour la première moitié).

Et devinez quoi? Microsoft possède dans ses mains une suite de développement plutôt bonne. Pour être honnête, C# est vraiment ce que je ferai si je pouvais complètement ré-écrire Java sans me soucier de la compatibilité descendante. Il y a quelques fonctionnalités vraiment sympas, comme les mots-clés virtual, override, et new qui vous permettent de spécifier ce qu’il se passe lorsque vous transtypez une classe dans sa classe de base et que vous appelez une méthode qui est définie dans les deux.

Visual Studio est un outil habile qui vous permet vraiment de créer des applications (et avec VSTO des ajouts pour Office) en deux temps trois mouvements. ADO.NET n’est pas pire que JDBC et s’intègre de manière transparente dans Visual Studio. J’ai été capable, arrivé à la fin de la semaine, de développer des applications autonomes et des ajouts pour Office qui étaient capable de dialoguer avec les bases de données en n’ayant écrit que peu de code. D’après ce que j’en ai vu, ASP.NET réalise la même chose pour les applications web MVC (NdT : Model View Controller).

Alors, quels sont les avantages d’une monoculture et pourquoi Microsoft gagne-t-il si souvent quand les gens doivent choisir une plateforme ? C’est en grande partie à cause de ce que la communauté open source voit comme une force mais que ceux qui essaient de faire leur boulot dans le monde réel voient comme une faiblesse. Nous célébrons la diversité de choix disponibles pour résoudre un problème et nous appelons cela la liberté. Les directeurs informatiques et les patrons de la branche informatique (IT managers et CIOs en anglais) y voient du chaos, de la confusion et des doutes.

Est-ce que je devrais utiliser iBatis ou Hibernate? XFire ou AXIS? Perl, PHP ou Ruby? Debian, Fedora, Ubuntu ou Suse? Si vous prenez la mauvaise décision vous pouvez perdre énormément de temps, comme nous l’avons découvert sur un projet récent où nous avons gâché une semaine à essayer de faire marcher AXIS2 pour un projet de service web pour finalement nous rendre compte que XFire était ce qu’il nous fallait.

Pour Monsieur Microsoft cette confusion n’existe pas. Vous utilisez ADO.NET, ASP.NET, C# et Windows. Ils fonctionnent tous, ils sont tous bien documentés du point de vue des besoins des développeurs, sans un seul regarde le code source désobligeant. A chaque fois que je pensais que j’allais être bloqué il y avait une douzaine d’articles expliquant comment faire exactement ce que je voulais faire, avec un exemple de code qui était à jour avec les versions du logiciel que j’utilisais et qui répondait vraiment au problème que je cherchais à résoudre.

Microsoft apporte le confort de ne pas avoir à choisir. Avoir le choix n’est pas toujours bon et la communauté open source offre parfois bien trop de manières différentes de plumer un canard, des choix qui sont pris plus par fierté, ego ou entêtement que par une authentique nécessité d’avoir deux alternatives différentes. Je ne montrerai personne du doigt, tout le monde connaît des exemples.

En fait, à moins que vous ne pensiez que je me sois tourné vers le Côté Obscur, le GROS problème avec une monoculture, c’est que vous vendez plus ou moins votre âme pour la stabilité d’un ensemble de choix défriché pour vous. En empruntant le chemin .NET, en gros, vous vous y perdez à tout jamais, et ce malgré Mono. Vous travaillerez toujours sur une plateforme Windows. Vous avez le joli anneau en or, mais Sauron tire les ficelles et vous fait danser. Pour beaucoup d’entreprises, celles qui n’ont pas besoin de se soucier du déploiement dans un environnement hétérogène, c’est un pacte qu’elles sont plus que prêtes à conclure.

Voici ce que je retiens de toute cette réflexion : en quelque sorte, nous devons commencer à faire le tri. La massue de 350kg pour faire entrer certaines idées dans les têtes devrait être mise à disposition pour marteler les têtes de ceux qui fourchent (NdT : qui créent un fork une déviation indépendante d’un projet) pour la seule et unique raison qu’ils ne sont pas en accord avec la licence, ou de ceux qui prennent les décisions. Quand on entend parler de deux (ou plus) projets qui répondent à la même problématique, on devrait se demander « Pourquoi ne mettent-ils pas en commun leurs efforts pour fournir une très bonne solution? » plutôt que de célébrer la diversité uniquement pour l’amour de la diversité.

A-ton vraiment besoin de Ruby on Rails ET de Groovy on Grails? Quand ils ont annoncé le poisson d’avril de Python on Planes j’ai mis quelques secondes pour réaliser que c’était un canular, parce que c’est exactement le genre d’effort faire quelque chose pour l’amour de le faire qui fractionne la communauté des logiciels open source. Il n’y a aucun moyen d’empêcher les gens de commencer des projets en double, et nous ne le voudrions pas, mais bon sang, doit-on l’encourager activement ?

On passe beaucoup de temps à se plaindre des moyens démoniaques qu’emploie Microsoft pour s’imposer partout. En faisant cela, nous nous lavons automatiquement de toute responsabilité que nous pourrions nous-même porter pour leur succès ou nos échecs. Le fait est qu’il existe d’excellentes raisons pratiques qui poussent les gens dans les bras de la boîte à outil de Redmond et nous devons accepter ceci comme un fait et en tirer des leçons plutôt que d’agiter nos poings en blamant l’obscurantisme. Car nous avons trouvé notre ennemi et c’est nous, pas Microsoft, du moins pas tout le temps…

Traduction^[1] d’un article issu du blog des Cobra Punchers. Je suis loin d’adhérer à tout ce qui est dit mais je crois qu’aucun musicien aujourd’hui ne peut faire l’économie de s’interroger sur les évolutions liées à internet et aux nouvelles technologies. Quid des licences aposées à ma musique ? Quid de sa diffusion ? Quid des contrats avec les sociétés de gestion des droits d’auteur.(type SACEM) ? Quid des contrats avec les maisons de disques (type Majors) ?

Pour ce groupe très rock’n roll ça donne un témoignage que d’aucuns trouveront peut-être excessif voire naïf mais qui a cependant le mérite de poser de bonnes questions en proposant une alternative qui pourrait bien à l’avenir être de plus en plus crédible.^[2]

La nouvelle industrie musicale

The New Music Industry

Ce n’est plus un secret, l’industrie musicale va mal. Ils ont changé leur modèle économique, leur principale source de revenus n’est plus la vente de musique mais les procès intentés à leurs clients. Chacun peut voir que c’est un modèle économique ridicule. Pourtant, ceux qui devraient être les mieux informés à propos du bateau en perdition qu’est l’industrie musicale aujourd’hui ignorent complètement tous les signes et grimpent à bord du Titanic avec un abandon désespéré.

Je parle des groupes, ces pauvres groupes naïfs qui pensent toujours que signer d’un contrat est comme passer la ligne d’arrivée en tête et se voir offrir tous ses rêves sur un plateau d’argent. Ces pauvres groupes naïfs qui ne lisent pas les petits caractères et qui ne parviennent pas à comprendre la partie commerciale de l’industrie dont ils désirent tant faire partie. Ces groupes qui vendent deux millions d’albums et qui se retrouvent avec une dette de centaines de milliers de dollars envers leur maison de disque qui devait rendre tous leurs rêves les plus fous réalité.

Ce sont ces gens qui devraient apprendre la nouvelle première règle de l’industrie musicale. Ne signez pas chez une grande maison de disque. J’irai même jusqu’à conseiller de ne signer avec aucune maison de disque. Je ne pense pas en avoir besoin, mais je vois très bien en quoi de nombreux groupes tireraient profit d’un contrat avec un label indépendant plus petit. Tout musicien n’a pas forcément le sens des affaires et vice versa, mais je pense que nous entrons dans une ère de la musique où le pouvoir reposera uniquement dans les mains des musiciens qui peuvent voir leur musique différemment et voir comment gagner de l’argent en faisant ce qu’ils aiment.

Voilà quelques concepts que tous les musiciens aujourd’hui devraient comprendre

1. Les gens vont partager votre musique entre eux – Ne voyez pas le partage de fichiers comme du vol. La plupart de ceux qui téléchargent de la musique ne se voient pas comme des voleurs, ils ne se voient pas comme des pirates, ils veulent juste écouter votre musique. Le but final de l’industrie de la musique est que le plus de gens possible écoutent votre musique. Quand les gens échangent de la musique entre eux, ils rendent service à ce musicien en augmentant le nombre de personnes qui l’écoutent. C’est difficile de voir le partage de fichier comme un bienfait pour les musiciens puisque la plupart des musiciens voient leur musique comme un produit à vendre sous la forme d’un album. Si les gens partagent votre musique entre eux gratuitement, comment un musicien peut-il gagner sa vie ?

2. La musique n’est plus un produit, c’est un contenu – Lorsque la musique était liée au support qui la jouait, c’était un produit de la même manière qu’un lave vaisselle ou un aspirateur est un produit. Vous achetez un aspirateur parce que c’est un produit qui nettoie votre sol. Vous achetiez un CD parce que c’est un produit qui fait des sons plaisants.

Maintenant le contenu est séparé du produit. Vous n’avez désormais plus besoin du CD pour entendre les beaux sons. Maintenant que la musique est retirée du produit, la musique existe seulement en tant que contenu. Le dilemme de comment faire de l’argent à partir de la musique devient bien plus simple à résoudre une fois que vous voyez la musique comme un contenu et pas comme un produit. Beaucoup de médias différents ont utilisé du contenu pour faire de l’argent. Le meilleur exemple est l’industrie de la télévision qui a utilisé des contenus gratuits de qualité pour faire de l’argent pendant des années.

3. Soyez le fournisseur de votre propre contenu – Il y a des centaines de sites de torrent qui amassent des fortunes en fournissant du contenu gratuit. Ils passent de la pub aux milliers de gens qui visitent leurs site. Ils attirent des milliers de visiteurs en offrant du contenu gratuit. Du contenu créé par d’autres personnes.

C’est cet argent qui devrait arriver directement dans les poches des musiciens. Les musiciens devraient être moins énervés par le fait que les gens écoutent leurs chansons gratuitement que par le fait que le trafic se dirige vers les sites de torrent plutôt que vers leur propre site web.

Le meilleur moyen de récupérer l’argent de la publicité est d’entrer directement en compétition en proposant votre propre contenu gratuitement. Placé devant deux choix, celui de naviguer dans les eaux troubles des sites de torrent peu scrupuleux à la recherche de votre dernier single ou celui de le télécharger directement depuis le site de l’artiste gratuitement, le client téléchargera le contenu depuis votre site web de manière certaine.

4. Le contenu n’est plus limité par le produit lui-même – Un CD contient 70 minutes de musique. La plupart des CD sortis par les musiciens font environ 45 minutes et contiennent entre 10 et 15 chansons. Chaque CD est vendu avec une jolie couverture, une liste des chansons, des photos du groupe et les paroles. C’est le format que presque tous les groupes ont suivi depuis que je pouvais atteindre le bouton “Play” sur la chaine HiFi de mon père.

Puisque le contenu du CD n’est plus lié à ce disque brillant de 70 minutes, la façon dont la musique est commercialisée et vendue est maintenant libérée de ce vieux format usé. Je pense qu’iTunes a commencé à paver la route pour le retour des singles. Les groupes sortent leurs chansons à un rythme plus soutenu et constant, ils pondent une chanson tous les deux mois depuis l’intimité de leur maison.

L’artiste n’aura plus besoin de faire du “remplissage” pour allonger artificiellement la durée de leur album. Les fans n’auront plus à acheter 9 chansons qu’ils n’aiment pas afin d’en avoir 3 qu’ils adorent. Les fans n’auront plus à attendre des années entre deux albums. Les fans auront une nouvelle dose du groupe qu’ils aiment à chaque fois qu’il écrit une nouvelle chanson.

Ceux qui adopteront cette idée rapidement bénéficieront grandement du fait que leur groupe sera dans les médias plus souvent. Les groupes auront plus souvent l’occasion de faire leur promotion s’ils sortent une chanson tous les mois. Les singles profiteront aussi aux musiciens qui génèrent leurs revenus par les bénéfices de la publicité. S’ils sortent plus de chansons dans l’année, leur site web aura un trafic plus constant.

Beaucoup de musiciens et de maisons de disques grinceront des dents à l’idée de distribuer la musique gratuitement, mais cela ne peut pas être évité. Grâce à Internet, partager la musique que vous aimez est devenu plus simple que d’aller au magasin l’acheter. La prochaine étape pour les groupes est de rendre le téléchargement de leur musique encore plus aisé aux fans pour qu’ils puissent contrôler le contenu qu’ils créent et gagner de l’argent par la même occasion.

Une traduction d’un article de Richard Hillesley paru récemment sur Tux Deluxe et qui fait écho à la récente conférence de Stallman mis en ligne sur ce blog.

Le titre interrogatif de ce billet est directement inspiré d’une citation de Larry Lessig extraite de la traduction :

Chaque génération a son philosophe – un écrivain ou un artiste qui saisit l’imaginaire du moment. Parfois, ces philosophes sont reconnus en tant que tel ; souvent, il faut des générations pour faire le rapprochement. Mais reconnu ou non, une époque est marquée par les gens qui expriment leurs idéaux, que ce soit dans les murmures d’un poème, ou dans le grondement d’un mouvement politique. Notre génération a un philosophe. Ce n’est pas un artiste, ou un écrivrain professionnel. C’est un programmeur.

J’en profite pour signaler que nous avons entamé un projet ambitieux, celui de traduire collectivement via Wikisource la biographie de Stallman par Sam Williams Free as in Freedom. Avis donc à tout traducteur qui souhaiterait participer^[1].

Soyez réaliste. Demandez l’impossible

Be Realistic. Demand the Impossible

Richard Hillesley – 18 mars 2007
(Traduction Framalang : Penguin, Daria et Olivier)

Un des slogans favoris des Situationnistes, pendant les agitations sociales de Mai 68 en Europe, était « Soyez réaliste. Demandez l’impossible ». Vivez votre vie à fond, osez rêver, nagez à contre-courant, et vos rêves deviendront réalité. Ce slogan aurait pu être écrit pour décrire la mission de Richard Stallman, le père de GNU, de la licence GPL et du mouvement du logiciel libre, qui a consacré sa vie à réaliser le rêve d’un système d’exploitation qui soit écrit de A à Z et qui soit totalement libre.

Stallman est un esprit implacable, et a souvent été comparé à un prophète de l’Ancien Testament – « une sorte de Moïse geek portant les commandements GNU GPL, et essayant d’amener la tribu hacker à la terre promise de la liberté, qu’ils veuillent y aller ou non. Ses longs cheveux, tombant abondamment sur ses épaules, sa grosse barbe, et un regard intense contribuent évidemment à cet effet. » (Glyn Moody – Le Code du Rebelle p29)

Comme cela est suggéré, Stallman est un ascète qui ne tolère aucun compromis, et qui a consacré sa vie et sa fortune, notamment les 240.000 $ de la « bourse du génie » (« genius grant ») offert par la fondation MacArthur en 1990, pour parcourir le monde avec son portable exsangue, évangélisant et prêchant à qui veut l’entendre la nécessité du logiciel libre. « La seule raison pour laquelle nous avons un système d’exploitation totalement libre », a-t-il confié à Moody, « c’est grâce au mouvement qui a dit que nous voulions un système d’exploitation totalement libre, et pas libre seulement à 90%. Si vous n’avez pas la liberté pour principe, vous trouverez toujours une bonne raison de faire une exception. Il y aura toujours des moments où, pour une raison ou pour une autre, il y a un avantage pratique à faire une exception. »

Stallman clame que le plus grand effet de la bourse MacArthur a eu sur son style de vie, c’est qu’il lui a été plus facile de s’inscrire pour voter. Stallman vivait dans son bureau. Les autorités refusaient de croire que son bureau était aussi son lieu de résidence, jusqu’à ce qu’un article de journal concernant la bourse MacArthur confirma ses affirmations.

« Je vis vraiment à peu de frais. Je vis encore en gros comme un étudiant, car je n’ai jamais eu envie d’arrêter », déclara-t-il à Michael Gross en 1999^[2]. « Les voitures, les grandes maisons ne m’attirent pas. Pas du tout. Je n’étais pas un esclave de la soif de l’argent, et cela m’a permis de faire quelque chose qui en valait la peine. C’est pourquoi, lorsque j’ai commencé le projet GNU, j’ai aussi commencé à faire pousser mes cheveux. J’ai fait cela parce que je voulais dire : Je suis d’accord avec un aspect du mouvement hippie : ne faites pas de la réussite matérielle un but dans la vie. »

La vision ascétique et sans compromis de Stallman n’est pas universellement populaire, même parmi les hackers qui ont bénéficié de son dévouement. Car l’objectif du logiciel libre ne commence ou ne finit pas avec GNU/Linux, GNU Hurd, ou n’importe quel autre système d’exploitation, langage ou application qui a été, ou qui pourra être, développé sur le modèle ouvert que la GPL favorise. Stallman accorde moins d’importance au fait qu’un logiciel libre fonctionne mieux et soit plus efficace qu’à son caractère libre.

« Cela ne concerne pas l’argent », dit-il, « cela concerne la liberté. Si vous pensez que cela concerne l’argent, vous n’avez rien compris. Je veux utiliser un ordinateur librement, pour coopérer, pas pour restreindre ou interdire de partager. Le système GNU/Linux a obtenu du succès avec plus que cela. Le système est devenu populaire pour des raisons pratiques. C’est un bon système. Le danger réside dans le fait que les gens vont l’aimer parce qu’il est pratique et qu’il va devenir populaire sans que personne n’ait la plus vague idée des idéaux qui sont derrière, ce qui serait une manière ironique d’échouer. »

Stallman relate que lorsqu’il a fondé le projet GNU en septembre 1983, les gens disait, « Oh, c’est un boulot infiniment difficile; tu ne pourras tout simplement pas écrire un système comme Unix. Comment serait-il possible de faire tout cela ? Ce serait bien, mais c’est tout simplement sans espoir. »

La réponse de Stallman était qu’il allait le faire quand même. « C’est ici que je suis doué. Je suis doué à être très, très têtu et à ignorer toutes les raisons qui pourraient me faire changer de but, raisons qui pousseraient beaucoup d’autres personnes à le faire. Beaucoup de gens veulent être du côté gagnant. Je n’en avais rien à cirer. Je voulais juste être du côté de ce qui était bien, même si je ne gagnais pas, au moins, j’allais vraiment essayer. »

Neuf ans plus tard, Linus Torvalds annonçait sur comp.os.minix : « Je suis en train de faire un système (libre) d’exploitation (il s’agit juste d’un hobby, ce ne sera pas ambitieux ni professionnel comme GNU) pour les clones AT 386(486). » Du point de vue de Stallman, le noyau Linux est juste une partie du système d’exploitation. « Il n’existe pas de système d’exploitation appelé Linux. Le système d’exploitation appelé Linux est GNU. Linux est un programme – un noyau. Un noyau est une partie du système d’exploitation, le programme de niveau le plus bas du système qui surveille l’exécution des autres programmes et partage la mémoire et le temps de calcul du processeur entre eux. »

L’affirmation controversée de Stallman que Linux devrait correctement être connu sous le nom de GNU/Linux est motivé par son désir que « les gens comprennent que le système existe grâce une philosophie idéaliste. Si vous l’appelez Linux, vous allez à l’encontre de la philosophie. C’est un problème très grave. Linux n’est pas le système. Linux n’en est qu’une partie. (…) La vision idéaliste du projet GNU est la raison pour laquelle nous avons le système. »

La contribution particulière de Stallman au mouvement du logiciel libre a été de mettre en lumière les obstacles légaux et propriétaires de la libre distribution des logiciels et des idées. Le langage universel des contributeurs des projets open source (et de l’industrie du logiciel en général) a été influencé par les fondements philosophiques et politiques fournis par les écrits de Stallman, spécialement sa vision perspicace de la nature des lois concernant les copyrights et les brevets logiciels.

En introduction de Free Software, Free Society, une collection d’essais et de conférences de Richard Stallman, publiée par GNU press, Lawrence Lessig, professeur de droit à l’université de Stanford, déclare que « Chaque génération a son philosophe – un écrivain ou un artiste qui saisit l’imaginaire du moment. Parfois, ces philosophes sont reconnus en tant que tel ; souvent, il faut des générations pour faire le rapprochement. Mais reconnu ou non, une époque est marquée par les gens qui expriment leurs idéaux, que ce soit dans les murmures d’un poème, ou dans le grondement d’un mouvement politique. Notre génération a un philosophe. Ce n’est pas un artiste, ou un écrivrain professionnel. C’est un programmeur. »

Stallman n’est pas seulement le philosophe et la conscience (peut-être accidentels) du mouvement du logiciel libre, mais il est aussi considéré comme le hacker ultime, ayant contribué à de nombreux outils de base sans lesquels Linux n’aurait pu exister. Le code de Stallman réprésente l’une des contributions individuelles les plus importantes des distributions Linux classiques. Beaucoup de développeurs considèrent Emacs, le premier grand logiciel créé par Stallman, comme le système d’exploitation ultime au sein d’un système d’exploitation. Les outils GNU écrits par Stallman et la FSF (en particulier le compilateur GNU gcc) étaient les pré-requis pour construire le noyau qui deviendra Linux.

La plus grande réalisation de Stallman, la licence publique générale GNU (GPL), a amené beaucoup de bénéfices tout autant aux utilisateurs qu’aux développeurs, certains n’ayant même pas été nécessairement prévus au moment de sa création. La licence et son préambule sont une présentation en profondeur du but poursuivi par Stallman, de libérer le logiciel de chaînes propriétaires qui l’entravent, et de permettre aux hackers (dans le sens premier du mot, « un programmeur enthousiaste qui partage son travail avec les autres ») d’avoir la liberté de développer, d’améliorer et de partager leur code.

L’ingrédient essentiel de la GPL est le concept de Copyleft, qui utilise la puissance du copyright pour garantir qu’un logiciel libre restera libre. Le Copyleft inverse la loi du copyright en déclarant qu’un logiciel adapté d’un logiciel GPL et distribué au public doit rester aussi libre que la version du logiciel dont il est l’adaptation. La beauté de la GPL, comme tout développeur logiciel chevronné le reconnaîtra, c’est que, comme un morceau de code élégamment écrit, elle possède une simplicité et une transparence intrinsèques. La licence remplit ses objectifs, de protéger et de promouvoir les principes du logiciel libre, sans ambiguïté ni compromis, et reflète en cela la détermination et la personnalité de Stallman, qui par sa volonte a crée GNU, la GPL et le mouvement du logiciel libre.

Pour mesurer la réussite de Stallman, il suffit de voir comment la GPL a fait évoluer les mentalités dans l’industrie du logiciel. A l’origine le logiciel libre, extension des idéaux de Stallman appris au laboratoire d’I.A. du MIT au début des années 70, a été rejeté comme étant improbable et impraticable – une aire de jeu pour hackers, hippies et geeks – mais contre toute attente, le logiciel libre est devenu un paradigme acceptable pour le développement de logiciel, et la communauté perdue et tourmentée des hackers a enfin trouvé une maison.

« Vous ne changez pas les choses en vous battant contre la réalité. Pour changer quelque chose, construisez un nouveau modèle qui rend l’ancien modèle obsolète » – R. Buckminster Fuller

Richard Hillesley

Deuxième traduction^[1] du blog de Mark Shuttleworth connu entre autres choses pour être à l’initiative de la célèbre distribution GNU/Linux Ubuntu.^[2]

Il devient de plus en plus difficile pour les partisans des DRM de défendre et justifier leurs positions.

Combien de temps tiendront-ils encore ?

Note aux ayant-droits : les DRM sont inefficaces

Note to content owners: DRM doesn’t work

Mark Shuttleworth – 7 avril 2007

Certaines idées sont vouées à l’échec, mais suffisamment séduisantes pour certaines personnes pour qu’elles soient condamnées à être essayées encore et encore.

Les DRM en font partie.

Je me suis réjouis de voir, il y a peu, que les clés de chiffrement pour *tous* les disques HD émis jusqu’à aujourd’hui avaient été découvertes et publiées. J’ai espoir que cela aboutira au dévoilement des schémas de protection de contenu des Blu-Ray et HD-DVD avant que ces lecteurs n’aient atteint 1% de leur marché potentiel. C’est en effet une bonne nouvelle puisqu’elle pourrait amener les gens qui implantent de telles protections à reconsidérer leur position.

On est déjà passé par là. Le système de chiffrement DVD-CSS a été cracké très rapidement, avec style et légalement. Les ayant-doits, Hollywood Inc, étaient scandalisés et ont poursuivi toute personne faisant simplement référence au logiciel libre qui pouvait accomplir ce décryptage simple. Ils ont utilisé le DMCA pour renforcer les lois sur le droit d’auteur bien au delà de son but originel. Ils se sont comportés comme un cerf pris dans les phares, aveuglés par la vision apocalyptique d’un monde où leur contenu circule rapidement et efficacement, sans pouvoir entrevoir une issue sûre alors que les phares se rapprochent. Leur marché changeait, ouvrant de nouvelles possibilités et de nouvelles menaces, et ils voulaient ralentir le rythme de ce changement.

Les ayant-droits pensent que les DRM peuvent ralentir l’évolution naturelle du marché.

En ce qui concerne les films, une des raisons principales de l’adoption des DRM a été le refus de l’industrie de sortir de l’ère de l’anologique. Les films sont en général envoyés aux salles de cinémas sous forme de films en celluloïd, de grosses bobines de celluloïd. L’impression et la distribution de ces films aux cinémas qui vont les montrer coûtent très cher. La stratégie de sortie de la plupart des films était donc définie par les contraintes du monde réel. Les studios imprimaient donc un certain nombre de pellicules et les envoyaient aux cinémas dans quelques pays. Quand la diffusion est achevée ici alors ces films sont envoyés dans de nouveaux pays. C’est la raison pour laquelle les films sortent en général à des dates différentes dans différents pays. C’est purement et simplement dû à des contraintes physiques liées à l’organisation des déplacements de morceaux de celluloïd et cela n’a plus sa place dans notre ère de distribution numérique, instantanée, mondiale.

Evidemment, quand les DVD sont apparus, les ayant-droits ne voulaient pas que les gens achètent le DVD aux USA et se le fassent envoyer en Australie avant même que le film ne passe dans les cinémas là-bas. D’où la lésion cérébrale que nous appelons zonage, les ayant-droits ont implanté la protection CSS afin que le DVD ne soit pas seulement chiffré mais aussi pour qu’il contienne un marqueur de zone qui est censé l’empêcher d’être lu ailleurs que sur le marché pour lequel il a été prévu. Si vous vivez en dehors des USA et que vous avez déjà essayé de lire un por^Wo petit documentaire des USA vous saurez de quoi je parle en disant lésion cérébrale : vous ne pouvez pas le lire en dehors des USA et la demande dans votre zone n’est pas suffisante pour justifier une version spécifique à votre région, alors tant pis pour vous.

La vérité est que la survie sur un marché dépend de votre capacité à vous adapter aux possibilités. L’industrie cinématographique doit faire de gros efforts pour adopter une distribution numérique mondiale, cela leur permettra d’organiser des sorties mondiales le même jour (modulo la traduction), de la même manière que vous et moi pouvont tout voir sur Youtube le jour où c’est mis en ligne.

La vérité est aussi que, alors que l’horizon change, la viabilité des modèles économiques se fait et se défait. Ceux-là même qui tentent d’imposer les lois de l’analogique à du contenu numérique vont se retrouver du mauvais côté du raz-de-marée. Tant pis pour vous. Il est nécessaire d’innover (encore, parfois!) et rester à la pointe, peut-être même d’être disposé à cannibaliser vos propres marchés, bien que pour être honnête cannibaliser ceux des autres est bien plus attirant.

Voici quelques vérités :

• Tous les DRM ayant une clé de chiffrement hors-ligne seront crackés. Peu importe si cette clé est conservée pour la plus grande partie sur du matériel protégé, car tôt ou tard l’un des maillons sera brisé. Et si vous voulez que vos produits soient visibles sur la plupart des PC il vous faudra des logiciels de lecture. Ils sont encore plus facilement crackables. Donc, même si vous essayez de protéger chaque connexion analogique (mon idée préférée est de faire pression pour chiffrer la liaison entre le matériel hifi et les hauts-parleurs!) quelqu’un, quelque part aura accès à votre contenu brut. Le seul effet que cela aura est l’augmentation du prix du matériel. Je me demande quel est le coût de tout le chiffrement associé au HD-DVD/Blu Ray, quand vous prenez en compte la complexité, le design et le coût séparé de l’IP, du matériel et du logiciel pour chaque appareil HD qui existe.

• L’alternative au stockage hors-ligne de la clé est l’accès uniquement en flux continu et ce n’est pas non plus protégeable. Le système de flux classique, la diffusion par voie hertzienne, a été hacké quand les magnétoscopes sont apparus et c’était vu comme une utilisation normale. Aujourd’hui l’une des radios numériques diffusée par satellite (Sirius ou XM je crois) est accusée par les ayant-droits pour leur soutien à des appareils qui permettent d’enregistrer leur signal de qualité CD sur des lecteurs MP3. Les services de streaming par le web qui ne permettent pas l’enregistrement local du contenu sont une forme inutile de protection, facilement et régulièrement contournés. Et évidemment, tout le monde ne souhaite pas forcément être connecté pour avoir accès à vos programmes.

• Un crack suffit. Pour n’importe quel fichier numérique, il suffit d’une copie non protégée et vous pouvez être sûr que tous ceux qui le veulent l’auront. Que ce soit un logiciel sur un site de warez ou un MP3 sur un service de téléchargement en Russie ou un réseau de partage de fichiers, vous ne pouvez pas colmater toutes les brèches. Reconnaissez-le, soit les gens veulent vous payer pour vos fichiers soit ils ne veulent pas et la meilleure stratégie que vous puissiez adopter est de rendre les choses aussi simple que possible pour ceux qui veulent rester en accord avec la loi. Cela ne se traduit pas par des poursuites contre des grands-mères ou des enfants, cela se traduit par un accès pratique au contenu qui permet à chacun de faire ce qui est juste, facilement.

• Quelqu’un trouvera un modèle économique qui ne dépendra pas de l’ancienne conception et si ça n’est pas vous alors ils vous mangeront tout cru. Vous allez sûrement leur intenter une action en justice, mais ça ne sera qu’une manœuvre défensive tandis que l’industrie subira une réforme autour de ce modèle économique, sans vous. Et quand je parle d’industrie je ne parle pas de vos adversaires, ils se trouveront sans doute dans la même impasse, mais de vos fournisseurs et de vos clients. Ce sont les distributeurs de contenu qui courent un risque ici, pas les créateurs ou les consommateurs.

La peur de l’industrie musicale de Napster les a poussé dans le cul-de-sac des DRM. Microsoft, Apple, Sony et d’autres compagnies encore ont développé des systèmes de DRM et les ont présentés à l’industrie musicale comme l’approche "saine" de la distribution de musique en ligne. C’était un bel argument : "Tous les avantages de la distribution en ligne avec tous les avantages économiques des vinyles", en résumé.

Parmi les prétendants, Sony a clairement été écarté parce qu’ils font partie des ayant-droits et il était hors de question que le reste de l’industrie paye une taxe technologique à l’un de leur concurrent (un peu comme le système Symbian de Nokia qui n’a jamais rencontré le succès chez les autres grands groupes comme il était trop lié à Nokia). Microsoft n’entrait pas dans la compétition, parce qu’ils sont évidemment trop puissants et que l’industrie musicale pouvait voir un coup d’état venir à des kilomètres. Mais le mignon petit Apple ne pouvait faire de mal à personne! Alors iTunes et AAC ont été accueillis les bras ouverts et Apple a réussi à s’approprier un quasi-monopole sur la distribution et la lecture de musique numérique légale. Apple a magnifiquement joué le jeu et a su profiter pleinement de la peur de l’industrie musicale.

L’appel récent de Steve Jobs, à l’intention de l’industrie musicale pour abandonner les DRM, a apporté une douce touche d’ironie, donnant à Apple l’avantage moral. Très très bien joué en effet !

Il y a quelques années j’étais à Davos, au Forum Economique Mondial. Ça devait être en 2002 ou 2003, quelques années après que la bulle Internet ait éclatée. C’était le tout début de l’iPaq, chacun à la conférence s’en était vu prêter un. Je me souviens très bien assister à une session qui était plus ou moins un confessionnal pour dirigeants, une sorte de fête de l’absolution par reconnaissance de stupidité. Les uns après les autres, des grands noms se sont succédés pour raconter des histoires d’épouvantes à propos de comment ils ont laissé les internés diriger l’asile et autorisé des jeunes, de vingt ans et quelques, à leur dire comment dépenser le capital de leurs actionnaires sur des projets .com. J’ai vraiment trouvé ça intéressant puisque j’ai passé toute la période .com à dire aux grandes entreprises de ne PAS sur-investir et se concentrer sur leurs relations avec leurs clients et partenaires de l’époque en utilisant le net, pas de conquérir le monde du jour au lendemain.

Mais le meilleur vint à la toute fin, quand le chef de Sony USA, également en charge de la division musicale, Sir Stringer, s’est présenté pour soulager sa conscience. Il pavoisait avec éloquence sur comment Sony n’avait PAS investi dans les .com et donc sur comment on se sentait en étant la seule personne dans la salle qui ne s’était pas fait avoir par des enfants. C’était un discours très amusant, très fin qui lui a valu des applaudissements et des rires. J’étais là à me demander s’il avait la moindre idée de combien de chansons pouvaient tenir dans l’iPaq dans sa poche ou combien de temps ça prendrait de les télécharger. Je ne pense pas. De tous les directeurs qui ont parlé ce jour là, j’ai pensé que ce serait probablement lui qui sera fortement touché, et rapidement, par la locomotive numérique.

Sir Stringer est maintenant Chef de la direction de Sony monde. Il est amusant alors que la PS3 de Sony ait dû être retardée pour terminer le travail sur son système de DRM.

C’est sûr maintenant, certaines mauvaises idées sont trop attirantes pour mourir.

J’ai récemment publié sur ce blog un billet, un peu provocateur, sur la relation entre Wikipédia et le logiciel libre : Wikipédia peut-elle rester neutre lorsque l’on touche au logiciel libre ?. Ce que je tentais (péremptoirement ?) de dire c’est que le logiciel libre sera toujours un champ un peu spécial dans l’encyclopédie de part la filiation étroite qu’il existe entre les deux projets, mouvements et communautés. Et de me permettre d’ajouter que cela me convenait fort bien 😉

Dans la liste de mon argumentaire en faveur d’une accointance entre l’encyclopédie et le logiciel libre, on trouvait cette célèbre citation de Jimbo Wales, fondateur de Wikipédia : « Imaginez un monde dans lequel chacun puisse avoir partout sur la planète libre accès à la somme de toutes les connaissances humaines. C’est ce que nous faisons. ».

J’ai voulu aller encore un peu plus loin ici en demandant à notre groupe de travail Framalang de traduire un article du même Jimbo Wales paru sur son blog en octobre 2004 Free Knowledge requires Free Software and Free File Formats qu’il me sembait intéressant d’apporter à un débat qui pour moi n’est pas (encore) clos.

Mais avant cela je voulais témoigner (une nouvelle fois) de mon admiration pour Wikipédia puisqu’il n’aura fallu que quelques jours à l’encyclopédie pour lever la controverse de neutralité sur la page Linux – 9 avril 2007 (Linux aujourd’hui) qui avait servie de pretexte à mon billet.

Cette controverse portait principalement sur un passage ambigu avec usage a priori non factuel des mots maturité et succès :

Le passage en question a été à ce jour ainsi modifié (9 avril 2007) :

Elle portait également sur l’absence de section Critiques sur la page Linux en comparaison notamment avec la page Windows Vista qui elle en avait une (et plutôt deux fois qu’une !). Cette absence n’est plus puisqu’elle est apparue (9 avril 2007) dans l’intervalle en trois paragraphes : Support matériel, Gestion numérique des droits et Sécurité.

Cet épisode est selon moi tout à fait révélateur de l’excellente réactivité et capacité de Wikipédia à résoudre ses problèmes. Après échanges et communication, parfois assez vifs, sur la page de discussion de l’article Linux (exemple 1 : Pourquoi absence d’une section Critiques et exemple 2 : Comment rédiger cette section Critiques), on se retrouve avec le compromis actuel qui n’est certes pas la panacée mais qui est selon moi effectivement bien meilleur que la situation précédente.

On notera que la concertation ne s’est pas arrêtée là. Elle s’est poursuivie sur une page dédiée à la controverse de neutralité de l’article Linux mais surtout mon humble billet a suscité un fort intéressant sondage spontané au sein de la communauté Wikipédia : Neutralité de Wikipédia et logiciels libres.

Au passage, cet épisode est également révélateur pour moi de la difficulté de parler d’un article de Wikipédia à l’instant t de l’auteur qui dans la plupart des cas ne correspond plus à l’instant t+1 du lecteur (d’où la présence des dates et du recours aux historiques des articles pour figer leur contenu).

Toujours est-il qu’en une semaine (à partir de la date d’emission de mon billet le 1er avril), on relève, sur l’historique de la page Linux, 84 modifications réalisées par 17 contributeurs !

C’est aussi et surtout ça Wikipédia. Et le professeur que je suis demeure pédagogiquement impressionné par le produit de cette mise en relation surtout pour un article tel que Linux où le consensus est une douce chimère.

Le simple spectateur de l’encyclopédie qui visite l’article vitrine Linux ne se rend pas forcément compte de toute l’effervescence collective qu’il y a eu dans les coulisses pour aboutir au résultat qui s’offre à lui à l’instant t. Qu’il ait alors l’envie ou la curiosité de cliquer sur "modifier" et il est susceptible de basculer dans une toute autre dimension, un peu comme Alice et son miroir.

Sinon pour en revenir au sondage, il est en cours de vote et je m’en garderai bien d’en tirer la moindre conclusion si ce n’est pour relever que je ne suis pas le seul à m’interroger sur la relation ténue et privilégiée qui existe entre Wikipédia et le logiciel libre. À commencer par son influent et charismatique fondateur Jimbo Wales qui écrivait il y a un peu plus de deux ans sur son blog un billet au titre évocateur Free Knowledge requires Free Software and Free File Formats dont nous vous proposons la traduction ci-dessous (merci Penguin).

Parce que si la connaissance libre nécessite conceptuellement le logiciel libre (et des formats ouverts) alors tout ce qui le favorise n’est-il pas à encourager et ce qui le freine à décourager ?

La connaissance libre nécessite le logiciel libre et les formats ouverts

Jimmy Wales – Octobre 2004

Des gens me demandent parfois pourquoi je suis si résolu à ce que Wikipedia utilise toujours des logiciels libres, même si dans certains cas un logiciel propriétaire pourrait être plus commode ou mieux adapté à un besoin particulier.

L’argumentation est la suivante : après tout, notre mission première est de produire de la connaissance libre, pas de promouvoir le logiciel libre, et bien que l’on puisse préférer les logiciels libres pour des raisons pratiques (puisqu’ils sont en général les meilleurs dans le domaine du web), nous ne devons pas faire une fixation là-dessus.

Je pense que cette argumentation est totalement erronée, et pas simplement pour des raisons pratiques, mais par principe. La connaissance libre nécessite le logiciel libre. C’est une erreur conceptuelle que de penser notre mission comme étant distincte de cela.

Qu’est-ce que la libre connaissance ? Qu’est-ce qu’une encyclopédie libre ? Son essence peut être immédiatement saisie par toute personne qui comprend le logiciel libre . Une encyclopédie libre, ou n’importe quelle connaissance libre, peut être lue librement, sans devoir obtenir la permission de personne. La connaissance libre peut être librement partagée avec d’autres. La connaissance libre peut être adaptée à vos propres besoins. Et vos versions modifiées peuvent être partagées librement avec d’autres.

Nous produisons un site web d’un volume très important, rempli d’une variété incroyable de connaissance. Si nous produisions ce site en utilisant un logiciel propriétaire, nous créerions des obstacles potentiellement insurmontables pour ceux qui voudraient prendre notre connaissance et faire la même chose que nous. Si vous devez demander l’autorisation d’un vendeur de logiciel propriétaire afin de créer votre propre copie de nos travaux, alors vous n’êtes pas totalement libres.

En ce qui concerne les formats propiétaires des fichiers, la situation est encore pire. Il est possible d’argumenter, même si ce serait à mon avis peu convaincant, que tant qu’il est possible d’ouvrir assez facilement le contenu Wikimedia dans un logiciel libre existant, alors une utilisation interne d’un logiciel propriétaire n’est pas si mauvaise. Pour les formats propriétaires, même cette séduisante erreur ne peut pas être acceptée. Si nous proposons des informations dans un format propriétaire ou avec la gêne d’un brevet, alors nous ne violons pas seulement notre propre engagement en faveur de la liberté, mais nous forçons ceux qui veulent utiliser notre connaissance prétendument libre à utiliser eux-mêmes des logiciels propriétaires.

Finalement, nous ne devrions jamais oublier en tant que communauté, que nous sommes l’avant-garde d’une révolution de la connaissance qui va transformer le monde. Nous sommes les pionniers et les guides de ce qui devient un mouvement mondial pour libérer la connaissance des contraintes propriétaires. Dans 100 ans, l’idée d’un manuel ou d’une encyclopédie propriétaire sera aussi bizarre et lointaine pour les gens qu’est pour nous l’utilisation de sangsues en médecine.

Grâce à notre travail, chaque personne sur la planète aura un accés aisé et à bas prix, à une connaissance libre qui leur donnera le pouvoir de faire ce qu’ils veulent. Et mon point de vue est qu’il ne s’agit pas d’un fantasme injustifié, mais bien de quelque chose que nous sommes déjà en train d’accomplir. Nous sommes devenus, en taille, l’un des plus grand site du monde, en utilisant un modèle d’amour et de coopération qui est encore presque totalement inconnu du plus grand nombre. Mais nous commençons à être connu, et nous serons connu, à la fois pour nos principes et nos réussites – car ce sont ces principes qui rendent ces réussites possibles.

Dans ce but, ce sera un élément important de fierté pour nous que la fondation Wikimedia ait toujours utilisée des logiciels libres sur tous les ordinateurs que nous possédons, et que nous mobilisions toutes nos forces pour garantir que notre connaissance libre _soit_ réellement libre, en n’obligeant pas les gens à utiliser des logiciels propriétaires pour la lire, la modifier et la redistribuer commme il leur convient.

Voici la traduction d’un article anglais intitulé 10 things you did not know about Wikipedia qui nous a semblé intéressant en ce qu’il permet d’après nous de rapidement comprendre et appréhender l’encyclopédie (et de dissiper tout de suite quelques éventuels malentendus).

C’est aussi une manière pour nous (et nos traducteurs de chez Framalang) de rendre hommage au projet en apportant notre toute petite pierre à l’édifice.

Précisons qu’il ne s’agit pas d’un « texte officiel » de Wikipédia mais d’une simple initiative d’un des ses auteurs anglophones^[1].

Au fait, si vous d’aventure vous jugiez la traduction perfectible^[2] rendez-vous sur… Wikipédia où nous avons bien entendu reproduit l’article^[3].

10 choses à savoir sur Wikipédia

Ceci est un essai. Il ne s’agit ni d’une ligne officielle ni d’une série de directives, mais d’un texte qui reflète seulement certaines opinions de ses auteurs.

10 choses à savoir sur Wikipédia est une liste de considérations sur Wikipédia spécifiquement destinée à ceux qui ont une connaissance préalable limitée de ce projet, par exemple certains journalistes, nos nouveaux contributeurs ou nos nouveaux lecteurs. Ces explications ne surprendront guère les wikipédiens chevronnés mais nous espérons qu’ils aideront tous les autres à se forger une opinion éclairée de notre travail.

1. Nous ne sommes pas à vendre.

Si vous vous attendez à ce que Wikipedia soit rachetée par quelque sympathique géant de l’Internet, rassérénez-vous. Wikipedia est administrée par la Fondation Wikimedia, une association à but non lucratif dont le siège se trouve à St. Petersburg, en Floride. Notre financement repose sur des donations et des subventions et notre mission consiste à apporter des connaissances libres à l’ensemble du globe.

Pour plus d’informations : http://wikimediafoundation.org/wiki/Accueil

2. Nos travaux appartiennent à tous.

Wikipédia a emboîté le pas au système GNU/Linux et au navigateur Mozilla Firefox et s’est affranchie des restrictions imposées par le régime traditionnel de la propriété intellectuelle. Nous avons préféré opter pour ce que l’on appelle une « licence de contenu libre » : tout un chacun est et restera toujours libre de copier, modifier et redistribuer l’ensemble des textes et des images mis en ligne par nos utilisateurs. Notre seule exigence : que vous citiez l’auteur de l’oeuvre concernée et que vous ne soumettiez celle-ci ou l’amélioration que vous y apportez à aucune restriction nouvelle.

Pour plus d’informations : http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Copyright

3. Nous parlons le banyumasi.

…et environ 250 autres langues. Certes, seules une soixantaine de ces versions locales de Wikipedia contiennent actuellement plus de 10.000 articles — mais ce n’est pas faute d’y consacrer nos efforts. La Fondation Wikimedia s’appuie sur un réseau grandissant de branches indépendantes, présentes dans déjà sept pays, qui concourrent à nous faire connaître à l’échelle locale. Dans de nombreux pays, y compris les Etats-Unis, Wikipedia figure parmi les dix sites Internet les plus visités.

Pour plus d’informations :
http://meta.wikimedia.org/wiki/Liste_des_Wikip%C3%A9dias et
http://www.alexa.com/data/details/traffic_details?q=&url=wikipedia.org (en)

4. Vos modifications dans Wikipedia n’ont rien d’irréversible.

Wikipédia est une base de données pourvue d’une mémoire éternelle. A chacune de vos interventions, vous créez en fait une version modifiée de l’article et choisissez tacitement de la mettre à disposition de ses futurs lecteurs. Aucune version existante n’est plus jamais retouchée, ce qui nous permet de revenir en arrière à l’envi et d’annuler les modifications qui ne nous conviennent pas. En tant que lecteur, vous pouvez même citer la version spécifique de l’article que vous êtes en train de consultez. Il vous suffit pour cela de renvoyer à l’article en cliquant sur le lien « adresse de cette version » dans le coin en bas à gauche de l’écran et votre lien dirigera le lecteur vers une page dont le contenu ne sera jamais modifié.

Pour plus d’informations : http://fr.wikipedia.org/wiki/Wiki

5. Nous sommes très attentifs à la qualité de nos travaux.

Wikipedia est régie par une palette complète de règles à respecter et de procédés de contrôle de qualité. Nos éditeurs ont la possibilité de suivre les modifications au fur et à mesure qu’elles sont effectuées, de surveiller des sujets précis sur lesquels ils sont compétents, de suivre l’historique des contributions d’un utilisateur, d’étiqueter des articles problématiques pour que d’autres éditeurs y remédient et de débattre des mérites de chaque article avec d’autres utilisateurs. Les pages qui posent problème sont marquées pour être supprimées, quant aux meilleures, elles sont distinguées par l’estampille « article de qualité ». Les WikiProjects se concentrent sur l’amélioration d’une famille d’informations spécifique. Nous tenons à offrir un travail de qualité et nous sommes sans cesse en train de réfléchir à de nouveaux moyens d’y parvenir.

Pour plus d’informations : http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil

6. Nous ne voulons pas que vous nous accordiez une confiance aveugle.

Pour un projet en mouvement permanent tel que Wikipédia, c’est inévitable : alors que certains articles sont d’une excellente qualité, d’autres, il faut en convenir, ne valent pas un clou. Nous nous efforçons bien sûr de faire en sorte que le pourcentage d’articles excellents soit toujours le plus élevé possible et de trouver des moyens utiles de vous indiquer l’état d’avancement d’un article. Même au meilleur de ce qu’elle peut offrir, Wikipédia reste une encyclopédie et non une source primaire, avec toutes les limites qui en découle. Nous vous prions donc de ne pas condamner Wikipédia, mais de l’utiliser en connaissance de cause.

Pour plus d’informations :
http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Avertissements_g%C3%A9n%C3%A9raux

7. Nous ne sommes pas seuls.

Wikipédia fait partie d’un mouvement promouvant les Connaissances Libres, qui commence à se répandre au sein des milieux scientifique et scolaire. La Fondation Wikimédia travaille directement sur huit projets frères étroitement liés à l’encyclopédie : Wiktionary (ou Wiktionnaire – dictionnaire et thésaurus), Wikisource (bibliothèque de documents source), Wikimedia Commons (dépôt d’archives multimédia riche de plus d’un million d’images, de vidéos et de fichiers audio), Wikibooks (ou Wikilivres – collection d’ouvrages pédagogiques et de manuels), Wikiversity (espace pédagogique virtuel), Wikinews (portail expérimental de journalisme citoyen), Wikiquote (collecte de citations) et enfin Wikispecies (recensement des toutes les formes de vie). Comme Wikipédia, tous ces projets sont sous licence libre et ouverts aux contributions de tous.

Pour plus d’information : http://wikimediafoundation.org/wiki/Nos_projets

8. Nous ne faisons que collecter des informations.

Les articles de Wikipédia ne sont pas signés et leurs auteurs sont des collaborateurs bénévoles. Que vous vous présentiez comme professeur diplômé, sous votre véritable nom, ou sous couvert d’anonymat, les modifications que vous apportez ou les arguments que vous avancerez seront jugés selon leur pertinence. Nous exigeons que les auteurs citent leurs sources pour toutes les théories exposées et nous n’autorisons pas les éditeurs à publier leurs conclusions personnelles lorsqu’ils rédigent un article. Les Wikipédiens doivent toujours respecter une neutralité de point de vue rigoureuse et ne collecter que des opinions pertinentes provenant de sources fiables.

Pour plus d’informations :
http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Principes_fondateurs

9. Nous ne sommes pas une dictature.

La Fondation Wikimédia est dirigée par son Conseil d’administration, dont les membres doivent, selon le règlement, être issus de la communauté. Les membres du Conseil d’administration et de la Fondation Wikimedia n’interviennent jamais dans les questions éditoriales, les différents projets de la Fondation sont autonomes et conduits de façon collégiale. Le fondateur de Wikipedia, Jimmy Wales, joue parfois le rôle de médiateur final au sein de la Wikipédia anglophone, mais son influence repose sur le respect et non sur le pouvoir – il n’intervient que dans les cas où la communauté n’y voit pas d’inconvénient. Wikipédia fonctionne de façon transparente et pratique l’auto-critique. Les points qui sont sujets à controverse sont débattus de façon ouverte et même signalés dans les pages de Wikipédia lorsqu’ils atteignent un certain niveau d’intérêt.

Pour plus d’informations : http://en.wikipedia.org/wiki/Criticism_of_Wikipedia (en)

10. Nous sommes partis pour durer.

Nous voulons que Wikipédia existe encore dans des centaines d’années, à moins qu’elle mute en un projet d’une envergure plus grande encore. Tout dans Wikipédia tend vers vers cet objectif : les licences de nos contenus, notre organisation et notre système d’administration, notre ouverture internationale, notre stratégie de collecte de fonds, notre choix d’utiliser des logiciels libres et nos efforts acharnés pour accomplir notre rêve. Nous voulons vous faire entrevoir un monde où chaque être humain pourra partager ses connaissances et profiter de la somme du savoir universel. Tel est notre engagement –– et pour y parvenir, nous avons besoin de vous.

Pour plus d’informations : http://wikimediafoundation.org/wiki/Accueil