On peut s’extasier béatement devant les prétendues capacités technologiques de la nouvelle génération, née une souris dans la main, et baptisée un peu vite les « digital natives ».

Mais s’il ne s’agit que de savoir manier de nouveaux objets, sans conscience, sans recul, et sans compétence ni curiosité pour en soulever les capots, alors nous nous mettons peut-être en danger^[1].

Or, parmi ces nouveaux objets, il y a les logiciels, dont tout le monde aura noté la place croissante qu’ils occupent dans nos sociétés contemporaines. Nous écarterons d’autant plus facilement ce danger que nous serons toujours plus nombreux à accorder de la valeur à la liberté des logiciels.

C’est la thèse que défend ici Hugo Roy en évoquant, par analogie avec la démocratie, une approche systémique de la situation.

PS : Pour l’anecdote, il s’agit d’une traduction que nous avons entamée sans savoir qu’Hugo Roy était… français ! Du coup c’est la première fois qu’on se retrouve avec une traduction relue par l’auteur même de l’article d’origine !

Logiciel Libre, Société Libre : À propos de la Démocratie et du Hacking

Free Software, Free Society: Of Democracy and Hacking

Hugo Roy – 8 novembre 2009 – Blog de la FSFE
(Traduction Framalang : Gilles Coulais et Hugo Roy)

Lorsqu’on explique pourquoi le logiciel libre est important, une question revient souvent :
« Ai-je réellement besoin de la liberté du logiciel ? »

L’utilité de la liberté du logiciel n’est pas évidente pour tous. Tout le monde n’est pas capable de comprendre le code source d’un programme, et ils sont encore moins nombreux à pouvoir le modifier. Seuls les hackers et les développeurs peuvent en effet jouir pleinement des quatre libertés d’un logiciel libre. Il est alors difficile de convaincre quelqu’un d’abandonner le logiciel propriétaire pour le simple bénéfice de la liberté, tant qu’il ne comprend pas l’utilité de cette liberté.

Il est essentiel de penser ce problème non pas comme un simple engagement envers la liberté, mais plus comme un problème de systèmes.

Tout d’abord, ne pas jouir d’une liberté n’implique pas pour autant qu’on ne bénéficie pas des effets de cette liberté. L’analogie la plus évidente ici sont les systèmes politiques. La Constitution est à la souveraineté ce que la licence des logiciels libres est au droit d’auteur. La Constitution qui définit notre système politique donne à chaque citoyen des libertés et des droits, tel que le droit de se porter candidat à une élection.

Tout le monde peut se présenter à une élection, ce qui ne signifie pas pour autant que tout le monde le fera. Tout le monde n’a pas la compétence ou l’envie de devenir politicien. Cela étant, diriez-vous que la démocratie n’a aucune importance juste parce que vous ne souhaitez pas personnellement entrer en politique ? Je crois que la plupart des gens ne diraient pas cela.

C’est la même chose avec le logiciel libre. Chacun peut utiliser, partager, étudier ou améliorer le programme. Mais le fait que vous ne le ferez pas ne doit pas vous amener à penser que ce n’est pas important pour vous. C’est important pour le système lui-même. Et plus le système devient important, plus cette liberté prend de la valeur.

À moins, bien sûr, que vous ne partiez du principe que le logiciel n’est pas important, et par conséquent son degré de liberté également. Mais alors, je suggère que vous éteigniez votre ordinateur et que vous arrêtiez de me lire. Prenez un avion et passez le reste de votre vie sur une île déserte.

Regardons maintenant de plus près l’utilité de la liberté logicielle. Alors que de plus en plus de logiciels sont utilisés dans notre société pour faire toujours davantage, nous devrions être de plus en plus nombreux à être capables de comprendre le logiciel. Sauf à vouloir donner à certains un contrôle total sur vous-même. Et alors les autres façonneront le système à votre place, en vue d’obtenir toujours plus de pouvoir au sein de ce système.

C’est la raison pour laquelle nous avons besoin de démocratiser le hacking. Et cette démocratisation viendra naturellement si le logiciel libre est largement utilisé. Donnez aux gens la possibilité d’étudier et d’explorer quelque chose, et ils finiront par le faire, au moins par curiosité, de la même manière que l’Imprimerie a donné aux gens la volonté d’être capable de lire puis d’écrire. Il s’agit évidemment d’un long processus. Mais ce processus peut s’avérer beaucoup plus long si nous utilisons du logiciel propriétaire, un logiciel que vous ne pouvez ni lire, ni modifier, ni partager.

Souhaitons-nous une société d’illettrés numériques ou une société libre ?

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

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

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

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

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

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

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

Si les commentaires sont moches, le code est moche

If the comments are ugly, the code is ugly

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

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

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

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

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

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

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

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

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

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

Vous voulez quelques exemples ?

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

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

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

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

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

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

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

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

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

Un article majeur de l’un des gourous de la Toile, qui met le doigt là où ça peut faire bientôt très mal.

Hubert Guillaud, nous le présente ainsi sur l’agrégateur Aaaliens :

« Tim O’Reilly revient sur la guerre du Web : entre Facebook qui ne transforme par les liens en hyperliens, Apple qui rejette certaines applications menaçant son coeur de métier… Tim O’reilly répète depuis longtemps qu’il y a deux modèles de systèmes d’exploitation de l’Internet : celui de « l’anneau pour les gouverner tous » et celui des « petites pièces jointes de manières lâche », le modèle Microsoft et le modèle Linux.

Allons-nous vers le prolongement du modèle du Web interopérable ? Ou nous dirigeons-nous vers une guerre pour le contrôle du Web ? Une guerre des plateformes (Google, Apple, Facebook…) ? Il est temps pour les développeurs de prendre position : si l’on ne veut pas rejouer la guerre des PC ou celle des navigateurs, il faut prendre fait et cause maintenant pour les systèmes ouverts ! »

La guerre du Web aura-t-elle lieu ?^[1] La réponse dépend aussi de la capacité qu’aura « la communauté du Libre » à diffuser et défendre ses valeurs et ses idées.

On notera au passage un étonnante prédiction finale sur Microsoft, notre futur allié de circonstance !

La guerre du Web

The War For the Web

Tim O’Reilly – 16 novembre 2009 – O’Reilly Radar
(Traduction Framalang : Olivier Rosseler et Goofy)

Vendredi dernier, mon dernier message sur Twitter a également été publié automatiquement sur Facebook, comme d’habitude. À un détail près : le lien que contenait le message n’était plus actif, comme l’a remarqué Tom Scoville.

En fait, il est loin d’être le seul à l’avoir remarqué. Dès samedi matin, Mashable publiait un article à ce sujet : Facebook retire vos liens Twitter.

Si vous publiez des liens Web (Bit.ly, TinyURL) sur votre compte Twitter et que par le biais d’une application Twitter-Facebook vous les partagez également sur Facebook, ils perdent leur caractère d’hyperliens. Vos amis devront copier et coller l’adresse dans leur navigateur pour qu’ils fonctionnent.

Si Facebook tente d’améliorer son ergonomie, c’est une curieuse décision : il vaudrait mieux que ça soit juste un bogue, nous avons donc contacté Facebook pour en savoir plus. Toujours est-il que tout le site est affecté, et pas seulement vous.

Il se trouve que ce ne sont pas uniquement les liens postés depuis Twitter qui étaient affectés. Tous les liens externes ont été temporairement désactivés si les utilisateurs ne les avaient pas clairement ajoutés avec la fonction « Joindre ». Sur Facebook j’ai essayé de poster un lien direct vers ce blog dans mes nouveautés, mais le résultat est le même : les liens n’étaient plus automatiquement cliquables. Le premier lien de cet article renvoie à une image illustrant ma tentative.

Le problème a été rapidement résolu, les liens apparaissent à nouveau cliquables. On a dit que c’était un bogue, mais certains mettent évidemment cette explication en doute, surtout compte tenu des efforts de plus en plus visibles de Facebook pour prévenir les gens qu’ils quittent Facebook pour se rendre sur le grand méchant Internet.

Tout cela part d’un bon sentiment, je n’en doute pas. Après tout, Facebook met en place un meilleur contrôle de la vie privée, pour que les utilisateurs puissent mieux gérer la visibilité de leurs informations et la visibilité universelle qui fait loi sur le Web n’est pas forcément la mieux adaptée aux informations postées sur Facebook. Mais ne nous voilons pas la face : Facebook est un nouveau type de site Web (ou une ancienne version largement reliftée), un monde à part, avec ses propres règles.

Mais ça ne concerne pas que Facebook.

L’iPhone d’Apple est l’appareil connecté le plus à la mode et, comme Facebook, même s’il est connecté au Web, il joue avec ses propres règles. N’importe qui peut créer un site Web ou offrir une nouvelle application pour Windows, Mac OS X ou Linux, sans demander la permission à qui que ce soit. Vous voulez publier une application pour iPhone ? Il vous faudra obtenir l’approbation d’Apple.

Mais il y a une lacune flagrante : n’importe qui peut créer une application Web et les utilisateurs peuvent y accéder depuis leur téléphone. Mais ces applications connaissent des limitations : toutes les fonctionnalités du téléphone ne leur sont pas accessibles. HTML5 aura beau innover autant qu’il veut, les fonctionnalités principales du téléphone resteront hors de portée de ces applications sans la permission d’Apple. Et si l’on s’en réfère à l’interdiction de Google Voice sur iPhone il y a quelques temps, Apple n’hésite pas à interdire les applications qui menacent leur cœur d’activité et celui de ses partenaires.

Et ce n’est pas tout, une autre salve a été tirée contre les règles tacites d’interopérabilité du Web : Rupert Murdoch menace de retirer le Wall Street Journal de l’index de Google. Même si, de l’avis général, ce serait du suicide pour le journal, des voix contraires s’élèvent pour insister sur l’influence qu’à Murdoch. Pour Mark Cuban, Twitter a maintenant dépassé les moteurs de recherche pour ce qui est des informations en temps réel. Jason Calacanis va même plus loin, quelques semaines avant les menaces de Murdoch, il suggérait déjà que pour porter un gros coup à Google il faudrait que tous les groupes de radio/presse/télévision devraient bloquer Google et négocier un accord d’exclusivité avec Bing pour ne plus apparaître que dans l’index de Microsoft.

Évidemment, Google n’encaisserait pas sans broncher et signerait également des accords de son côté, on assisterait alors à une confrontation qui ferait passer la guerre des navigateurs des années 90 pour une petite bagarre de cours d’école.

Je ne suis pas en train de dire que News Corp et les autres groupes d’information devraient adopter la stratégie prônée par Jason, ni même qu’elle fonctionnerait, mais je vois une se profiler une période de concurrence meurtrière qui pourrait être très néfaste à l’interopérabilité du Web telle que nous la connaissons aujourd’hui.

Si vous suivez mes commentaires sur le Web 2.0 depuis le début, vous savez que je pense que nous sommes engagés dans un projet à long terme dont la finalité est le système d’exploitation Internet (jetez un œil au programme de la O’Reilly Emerging Technology Conference de 2002 (pdf)). Je soutiens depuis des années qu’il y a deux modèles de systèmes d’exploitation, que je décris comme "Un anneau pour les gouverner tous" et "Des petits morceaux faiblement coordonnés", ce dernier étant illustré par une carte d’Internet.

Dans le premier : malheur au vaincu, c’est le monde que nous avons connu avec Microsoft Windows et le PC, un monde où priment la simplicité et l’accessibilité, mais où le choix de l’utilisateur et du développeur sont réduits au bon vouloir du fournisseur de système d’exploitation.

Le second est une système d’exploitation qui fonctionne comme Internet lui-même, comme le Web et comme les systèmes d’exploitation Open Source comme Linux : un monde certes moins raffiné, moins contrôlé, mais un monde qui est par essence novateur car chacun peut apporter ses idées sans avoir à demander la permission à qui que ce soit.

J’ai déjà expliqué les tentatives des grands pontes comme Facebook, Apple et News Corp de grignoter le modèle « des petits morceaux faiblement coordonnés » de l’Internet. Mais peut-être que le plus grand danger réside dans les monopoles qu’a engendré l’effet réseau du Web 2.0.

Je ne cesse de répéter, à propos du Web 2.0, qu’il s’appuie sur un système auto-entretenu : plus il y a d’utilisateurs, plus l’expérience est intéressante. C’est un système qui tend naturellement vers des monopoles.

Nous nous sommes donc habitués à un monde où un seul moteur de recherche domine, où une seule encyclopédie en ligne domine, un seul cyber-marchand, un seul site d’enchères, un seul site de petites annonces dominent, et nous avons été préparés à un monde où un seul réseau social dominera.

Mais qu’advient-il lorsqu’une de ces entreprises, profitant de son monopole naturel, tente de dominer une activité connexe ? C’est avec admiration et inquiétude que j’ai observé Google utiliser sa mainmise sur la recherche pour tenter d’étendre son emprise sur d’autres activités concentrées sur les données. Le service qui m’a mis la puce à l’oreille était la reconnaissance vocale, mais c’est vraiment les services de géolocalisation qui ont eu le plus gros impact.

Il y a de cela quelques semaines, Google a lancé une application de navigation GPS gratuite pour les téléphones Android. Pour les clients c’est génial puisque auparavant ils devaient opter pour un GPS dédié ou des applications pour iPhone hors de prix. Mais il faut aussi y voir la compétitivité que le Web a acquise et la puissance que Google a gagnée en comprenant que les données sont le nouveau "Intel Inside" de la nouvelle génération d’applications pour ordinateurs.

Nokia a allongé 8 milliards de dollars pour NavTeq, leader de la navigation routière. Le fabricant de GPS TomTom a quant à lui payé 3,7 milliards de dollars pour TeleAtlas, numéro deux du secteur. Google développe un service équivalent dans son coin pour finalement l’offrir gratuitement… mais à ses seuls partenaires. Tous les autres doivent encore payer de lourdes redevances à NavTeq et TeleAtlas. Google va même plus loin puisqu’il y ajoute ses propres services, comme Street View.

Mais surtout, les camps sont maintenant bien établis entre Apple et Google (ne ratez pas l’analyse de Bill Gurley à ce sujet). Apple domine l’accès au Web mobile avec son appareil, Google contrôle l’accès à l’une des applications mobiles les plus importantes et limite son accès gratuit aux seuls terminaux Android pour l’instant. Google ne fait pas des merveilles que dans le domaine de la recherche, mais aussi en cartographie, en reconnaissance vocale, en traduction automatique et dans d’autres domaines adossés à des bases de données intelligentes phénoménales que seuls quelques fournisseurs peuvent s’offrir. Microsoft et Nokia disposent également de ces atouts, mais eux aussi sont en concurrence directe avec Apple et, contrairement à Google, leur économie repose sur la monétisation de ces atouts, pas sur la gratuité du service.

Il se peut qu’ils trouvent un moyen de co-exister pacifiquement, et dans ce cas nous pourrions continuer à jouir du Web interopérable que nous connaissons depuis deux décennies. Mais je parierais plutôt sur l’effusion de sang. Nous sommes à la veille d’une guerre pour le contrôle du Web. Au fond, c’est même plus que ça, c’est une guerre contre le Web en tant que plateforme interopérable. Nous nous dirigeons plutôt vers la plateforme Facebook, la plateforme Apple, la plateforme Google, la plateforme Amazon, les grandes entreprises s’étripant jusqu’à ce qu’il n’en reste plus qu’une.

C’est maintenant au développeur de s’affirmer. Si vous ne voulez pas voir l’histoire se répéter comme pour les PC, pariez sur les systèmes ouverts. N’attendez pas qu’il soit trop tard.

PS : Une prédiction : Microsoft sera le grand défenseur du Web ouvert, encourageant l’interopérabilité des services Web, tout comme IBM est devenu l’entreprise soutenant le plus Linux.

Je parlerai de ce sujet lors de mon discours d’introduction à la Web 2.0 Expo à New York mardi. J’espère vous y rencontrer.

La semaine dernière Microsoft a dû retirer de ses serveurs un logiciel qui permet d’installer Windows 7 à partir d’une image ISO, après qu’un bloggeur a découvert que le logiciel était une modification dissimulée d’un logiciel libre sous licence GPL dont Microsoft hébergeait lui-même les sources.

On attendait une réaction publique et officielle, la voici sous la plume de Peter Galli, rien moins que le « Open Source Community Manager for Microsoft’s Platform Strategy Group »^[1].

Mise à jour de l’outil USB/DVD de Windows 7

Update on the Windows 7 USB/DVD Tool

Peter Galli – 13 novembre 2009 – Port 25
(Traduction Framalang : Gilles)

Comme vous avez pu le lire, et tel que cela a été indiqué ici, nous avons mené une enquête concernant l’outil de d’installation de Windows 7 depuis une clé USB, qui pouvait contenir du code sous licence GPL V2. le WUDT (NDT : Windows 7 USB/DVD Download Tool) est un outil gratuit, offert par le Microsoft Store, qui permettait à nos clients de créer une clé USB amorçable ou un DVD de sauvegarde à partir de l’édition électronique de Windows 7, disponible sous forme d’image ISO.

Après avoir analysé le code en question, nous sommes désormais en mesure de confirmer que tel était bien le cas, bien que cela n’ait pas été fait de manière délibérée. Bien que nous ayons confié cet outil à un développeur externe, nous partageons la responsabilité de cette situation; ce code est passé au travers des mailles de notre processus de revue de code. Nous avons également procédé à une revue d’autres portions de code disponibles dans le Microsoft Store, et il s’agit du seul incident que nous avons pu y découvrir.

Lorsqu’il est porté à notre attention qu’un composant de Microsoft contient du code développé par un tiers, notre objectif est de respecter les termes contractuels selon lesquels ce code est partagé. En conséquence, nous publierons le code source, ainsi que les fichiers binaires, de cet outil dès la semaine prochaine, sous les termes de la licence General Public Licence V2 (GPL V2), et prenons également des mesures pour améliorer nos futures revues de code, grâce à cette expérience

Nous nous excusons auprès de nos clients pour tout désagrément que cela a pu leur causer.

Hadopi aura non seulement contribué à intéresser un grand nombre de nos concitoyens sur un sujet autrefois chasse gardée des industries culturelles, mais elle aura également permis de mettre le focus sur la France (en refroidissant d’ailleurs peut-être certains autres gouvernements dans leur velléités d’en faire autant).

Or justement qu’en est-il exactement de la situation hors de nos frontières sur toutes ces questions autour d’un droit d’auteur^[1] qui se trouve totalement bousculé par l’avènement des nouvelles technologies et pratiques en réseau qui en découlent ?

Force est de reconnaître qu’en dehors de notre propre pays et de celui, influence numérique oblige, des États-Unis, nous n’en avons bien souvent qu’une connaissance ponctuelle, partielle et parcellaire (même si des sites comme Numerama, FFII ou La Quadrature font de gros efforts pour nous tenir au courant, en particulier sur l’Europe).

C’est pourquoi la nouvelle initiative de l’Electronic Frontier Foundation est plus que bienvenue. Elle s’appelle Copyright Watch et vise à suivre et surveiller le droit d’auteur et ses évolutions dans chaque pays.

En effet, avoir ainsi à disposition eu un unique endroit des documents, liens et informations actualisées, indépendantes et localisées sur les législations en vigueur (ou en préparation) nous sera précieux pour étude, information, comparaison, action, etc.

Le projet débute à peine, il est pour ainsi en bêta actuellement. Le premier objectif étant de trouver des correspondants (NdT : des local copyright monitors) prêt à maintenir leurs informations nationales à jour. Une fois ceci réalisé nous serons alors en présence d’une ressource de référence nous permettant d’avoir une meilleure vue d’ensemble sur la situation internationale, pointant ici des lois liberticides et là des lois favorisant au contraire le partage et diffusion d’une culture des biens communs.

Une base de données d’autant plus bienvenue que tout le monde n’a pas forcément intérêt à ce que tout ceci soit facilement accessible 😉

Qu’est-ce que Copyright Watch ?

About Copyright Watch

Copyright Watch – Novembre 2009 – Traduction partielle de la page « About » du site
(Traduction Framalang : Siltaar et Goofy)

Avant, le détail des lois sur le droit d’auteur n’était important que pour une minorité travaillant dans les industries culturelles. Désormais, avec la croissance d’Internet, nous sommes tout concernés car nous sommes potentiellement tous des auteurs, éditeurs, et partageurs d’œuvres de création.

Notre rêve est ici de construire une ressource conviviale sur les lois nationales du droit d’auteur afin d’aider les citoyens du monde à entreprendre des recherches comparatives. Nous souhaitons en effet sensibiliser à l’importance d’un droit d’auteur équilibré dans la société de l’information, et attirer l’attention sur les points communs et les divergences dans l’approche législative des différents pays.

Nous avons aussi voulu créer un outil de partage d’information, où des correspondants locaux pourraient publier des informations à propos des amendements proposés sur leurs propres lois du droit d’auteur, et à comprendre les changements dans celles des autres.

Nous espérons que Copyright Watch sera une ressource maintenue et conduite par la communauté de l’accès au savoir (NdT : Access to Knowledge movement, c’est-à-dire nous tous si nous participons) et que ce système de veille sur le droit d’auteur dans chaque pays permettra de garder cette information pertinente et à jour.

Enfin, nous espérons que Copyright Watch aidera à documenter l’importance du droit d’auteur sur tous les aspects de la vie culturelle et des libertés fondamentales. Équilibrées et bien calibrées les lois sur le droit d’auteur sont extrêmement importantes dans notre société mondiale et mondialisée de l’information.

Le plus petit changement dans l’équilibre juridique entre les ayants droit et le public peut permettre ou détruire des modèles économiques, criminaliser ou libérer des comportements quotidiens, et transformer ou éradiquer de nouvelles technologies. Une loi qui est passée dans un pays peut rapidement être reprise par d’autres, par des accords commerciaux bilatéraux, des initiatives politiques régionales ou des traités internationaux.

Nous devons tous rester vigilants.

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

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

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

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

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

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

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

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

Pourquoi je (A/L)GPLise

Why I (A/L)GPL

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

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

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

C’est le droit de l’auteur

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

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

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

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

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

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

Je ne veux plus être ignoré

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

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

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

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

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

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

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

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

Le capital risque a changé l’industrie

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

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

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

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

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

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

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

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

Les développeurs sont des plagiaires

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

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

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

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

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

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

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

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

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

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

Si c’est bien, payez pour l’avoir

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Finalement, la valeur

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

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

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

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

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

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

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

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

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

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

When open source isn’t (open enough)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AntWeb passe sous licence Creative Commons BY-SA

AntWeb goes CC-BY-SA

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

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

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

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

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

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

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

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

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