Le 11 novembre nous est une date bien connue parce qu’elle marque la fin de la Première Guerre mondiale.

Mais cette année, dans un format de date à 6 chiffres, elle s’écrira… 11-11-11, à savoir une magnifique et parfaite date binaire^[1] !

Sans avoir beaucoup plus d’informations sur l’initiative, des internautes hispanophones libristes se proposent malicieusement de marquer le coup comme il se doit (à 11h11 si possible).

Nous leur avons emboîté le pas en traduisant l’appel glané sur le Web grâce à notre petite mais active section espagnole de Framalang (merci à Thibz et TV).

« Un autre logiciel est possible et il se trouve être Libre »

À propos du 11-11-11

Sobre el 11-11-11

Bonjour à toutes et à tous de la communauté du Logiciel Libre.

Un groupe de personnes et d’organisations de différents pays est en train de se former pour organiser une célébration le vendredi 11 novembre 2011.

En effet la date de ce jour (11/11/11) sera la dernière date binaire qu’il y aura avant longtemps, la prochaine date du même genre sera le 01/01/00 (ou 010100) en 2100.

Pour faire honneur à cette date clin d’œil du calendrier, nous avons décidé de nous réunir ce jour-là, non pas pour célébrer cette « dernière » date binaire, mais bien au contraire pour profiter de cette excuse numérique afin de célébrer « le début du siècle du Logiciel Libre ».

S’il s’agit bien d’une célébration symbolique, nous ne pouvons manquer cette occasion de partager ce moment sans doute unique dans nos vies. Un moment que l’on pourrait mettre à profit pour dynamiser le mouvement du Libre et chercher des points communs et d’appui entre les différentes communautés pour stimuler et développer les initiatives, diffuser les progrès et joindre nos efforts autour du Logiciel Libre, expression d’une culture solidaire, libératrice et engagée dans la défense des valeurs éthiques et des libertés fondamentales de la technologie, comme par exemple le droit pour toutes et tous à l’accès au savoir, la solidarité sociale et le principe fondamental de pouvoir partager.

Ce jour-là nous nous réunirons en groupes de personnes de différentes communautés dans différentes parties du monde pour célébrer le début du siècle du Logiciel Libre. Aujourd’hui (et depuis un certain temps déjà) on peut utiliser des distributions GNU/Linux sans composants privatifs pour nos tâches informatiques quotidiennes (à quelques exceptions près). Et avec l’aide de toutes et tous nous arriverons un jour à éliminer de notre société les systèmes de dépendance et de domination dont elle n’a pas besoin, et à créer des modèles novateurs de développement, de créativité et des opportunités pour stimuler les talents aux quatre coins de la planète.

Ce jour sera également l’occasion de persuader et convaincre beaucoup plus de personnes et de gouvernements de s’engager à adopter les technologies de l’information libres, et à offrir un plus grand soutien aux activistes, aux développeurs, aux associations, aux organisations et aux communautés du Logiciel Libre dans le monde, parce que « un autre logiciel est possible et il se trouve être Libre ».

Il y a plusieurs collectifs qui œuvrent pour le 11-11-11. Nous espérons être nombreux à accompagner cette célébration de forme libre et créative dans les réseaux sociaux, canaux IRC, listes de diffusion, radios et moyens alternatifs et communautaires, blogs et toute forme de communication.

Le 111111, vive la liberté d’être, de créer, connaître et partager… Ne manquez pas le rendez-vous… On vous attend !

« Android représente une étape majeure vers un téléphone portable libre qui soit contrôlé par l’utilisateur, mais il y a encore beaucoup de chemin à parcourir. Les hackers travaillent sur Replicant, mais c’est un gros travail de rendre un nouveau modèle compatible, et il reste encore le problème du micrologiciel. Même si les téléphones Android d’aujourd’hui sont considérablement moins mauvais que les smartphones d’Apple ou de Windows, on ne peut pas dire qu’ils respectent vos libertés. »

Ainsi se termine l’article de Richard Stallman consacré à Android et la liberté des utilisateurs. On y évoque donc le projet Replicant qui vise à produire un dérivé entièrement libre du système d’exploitation de Google.

Or il se trouve que nous avons la chance d’avoir l’un des développeurs du projet parmi les membres traducteurs de Framalang. Il eut été alors dommage de ne pas en profiter pour en savoir plus et comprendre la difficulté qu’il y a à tenter de libérer totalement un téléphone portable.

On notera que ce développeur est encore lycéen, ce qui fournit au passage un excellent témoignage d’une jeunesse qui, ayant découvert le logiciel libre, n’a plus forcément envie de passer tout son temps sur Facebook 🙂

Le projet Replicant, présenté par le développeur PaulK

Présentation de PaulK, un des deux développeurs du projet Replicant

Je m’appelle Paul et me présente souvent sous le pseudo « PaulK ». Je suis actuellement lycéen (en filière scientifique) et utilise du logiciel libre depuis 2008.

J’ai commencé avec l’utilisation de Ubuntu 8.04, en dual boot avec Windows à l’époque. En décembre 2009, j’ai décidé de passer sur Fedora, qui respectait mieux ma vision de l’informatique libre (en mettant en avant la liberté et non le seul caractère « Open Source »). Déjà à l’époque, j’étais un fervent lecteur du framablog et enthousiaste des projets de Framasoft. J’ai progressivement commencé à appendre la programmation (en C) et me suis finalement débarrassé de mes partitions Windows. J’ai aussi commencé à contribuer à certains projets proches du monde du logiciel libre, comme OpenStreetMap.

Début 2010, j’ai commencé à m’intéresser aux différentes solutions des plus libres dans le domaine de la téléphonie mobile. Je suis finalement tombé sur le site web du projet Replicant et suis allé jeter un œil sur le canal irc du projet (#replicant sur irc.freenode.net) : j’y ai trouvé le développeur principal du projet, qui, connaissant très bien la question m’a exposé les différentes solutions existantes. J’ai opté pour le Neo FreeRunner, le téléphone « le plus libre » (100% de logiciel libre tournant sur le CPU) avec à la fois une communauté francophone et internationale dédiée au projet. Je l’ai utilisé comme téléphone principal mais l’ai endommagé (avec mon fer à souder) par mégarde , après de nombreux mois d’utilisation. Pour trouver un successeur, je suis revenu sur le salon IRC du projet Replicant pour finalement choisir un HTC Dream, sur lequel j’ai installé Replicant. J’ai ensuite commencé à vouloir aider au développement du projet, après avoir compilé mes premières images du système.

En effet, depuis que j’ai commencé à utiliser GNU/Linux, mon intérêt pour la programmation n’a cessé de croitre et j’ai finalement manipulé un certain nombre de languages : C, Perl, Javascript, Lua… Contribuer au projet Replicant m’a, entre autres, permis d’apprendre les bases de Git, de comprendre et modifier des drivers du noyau, de mettre en application très concrète mes connaissances en C…

Depuis plusieurs mois, je concentre mon attention sur le support du Nexus S, le dernier téléphone de Google/Samsung.

Présentation du projet Replicant

Le projet Replicant vise à produire un dérivé entièrement libre d’Android, le système d’exploitation destiné au matériel embarqué (et originellement aux téléphones) produit par l’« Android Open Source Project » (désigné par AOSP) , dirigé par l’« Open Handset Alliance », qui est menée par Google. La version d’Android telle que produite par l’AOSP contient du code provenant de divers horizons et distribué sous diverses licences : du code sous GNU GPL, du code sous BSD et par exemple pour ce qui a été écrit par l’AOSP, du code sous licence Apache 2. A l’exception de quelques micro-logiciels (firmwares), le code d’Android tel que fourni par l’AOSP est libre.

On peut donc télécharger ce code source, éventuellement retirer ces firmwares et le compiler afin d’obtenir un système totalement libre. Le problème principal ici est qu’une telle version d’Android serait absolument inutilisables sur un téléphone. Seul l’émulateur Android (celui présent dans le « SDK ») fonctionnerait sans poser de soucis.

En effet, la grande majorité des téléphones fonctionnant sous Android nécessitent, à un moment ou à un autre, des librairies, programmes ou firmwares non-libres. La quasi-totalité de ces composants non-libres touchent directement à la communication avec le matériel : du traitement des données en provenance des accéléromètres jusqu’au composant en charge de dialoguer avec le modem (ce qui gère toutes les fonctions liées à la téléphonie, à l’envoi des messages, à la connexion 3G, etc).

Le projet Replicant a donc deux objectifs :

• fournir un système basé sur Android entièrement libre
• écrire des remplacements aux composants non-libres afin de pouvoir utiliser le téléphone avec Replicant « pour de vrai ».

Chaque appareil ayant ses particularités, son propre matériel, il faut un noyau particulier par appareil, une image du système avec les librairies et les configurations adaptées par appareil, ce qui demande de faire le travail séparément pour chaque appareil : il n’y a pas de remplacement miracle qui marcherait avec tous les appareils Android d’un coup lorsqu’il s’agit de fonctions bas-niveau touchant au matériel. Ceci rend donc le travail très long et demande aussi au développeur de posséder chaque téléphone sur lequel il travaille.

L’état actuel du projet

Pour l’instant, le nombre de téléphones supportés par le projet Replicant est relativement réduit : en effet, seuls deux développeurs font partie du projet, mêmes si des aides extérieures sont souvent là pour participer au développement. A l’heure actuelle (fin 2011), les modèle suivants sont utilisables : HTC Dream, HTC Magic, Google Nexus One (nécessite des firmwares non-libres pour que l’audio fonctionne) et le Google Nexus S n’est pas encore prêt dans le sens où les fonctions liées à la téléphonie n’ont pas encore été libérées (mais le travail est en cours).

La liste plus détaillée des fonctionnalités présentes avec Replicant pour chaque téléphone est disponible sur cette page.

De plus, le projet dispose d’un site web, où sont postées les dernières nouvelles du projet, d’une liste de diffusion et d’un canal IRC.

Petit historique du projet

Replicant n’est pas un projet très ancien : démarré à l’été 2010 afin de rassembler plusieurs initiatives isolées visant à produire une version entièrement libre dérivée d’Android pour le premier « Google phone », le HTC Dream, le projet a vite abouti à l’écriture de code pour remplacer les parties non-libres : le premier composant non-libre à avoir été remplacé a permis à l’audio de fonctionner sans composants non-libres. L’idée de créer un dépôt libre d’applications, s’accompagnant d’un logiciel client pour Android (et donc Replicant) a également été envisagé assez rapidement, mais cette première tentative n’a pas abouti. Plus tard, le projet Fdroid viendra combler ce manque, fournissant un dépôt d’applications libres faisant directement office de remplacement à l’« Android market ». La partie gérant la communication avec le modem (dite « RIL ») a ensuite été remplacée par du code libre, rendant ainsi le téléphone utilisable. Une librairie pour le GPS a aussi été adaptée à partir de code libre destiné à un autre téléphone. L’horizon du projet s’est également élargie avec le début du port de Replicant sur le Nexus One, qui a d’ailleurs été offert au développeur principal par Google, preuve de leur intérêt ou curiosité pour le projet Replicant. Maintenant, c’est le Google Nexus S qui est en train d’être porté sur Replicant (mais aussi sur GNU/Linux, au sein du projet SHR).

Le problème des firmwares malveillants, ou le problème principal auquel Replicant ne peut pas apporter de solutions

Si nous nous efforçons de produire des remplacements libres pour la plupart des composants non-libres présents les version d’Android distribuées avec les téléphones, il y a certains composants qu’il nous est (pour l’instant) impossible de remplacer. C’est en effet particulièrement le cas de certains firmwares, tels que le logiciel (non-libre) qui est exécuté sur le modem. Aucun des développeurs du projet n’a les compétences techniques pour réaliser une alternative libre à ce composant et de toute façon, il ne serait pas légal d’exécuter un tel logiciel sur les réseaux des opérateurs. En effet, ceux-ci ne seraient pas certifiés. Le seul projet de remplacement libre du logiciel contenu dans le modem se nomme OsmocomBB et devrait fonctionner sur un nombre très réduit de téléphones, incluant le Neo FreeRunner (qui n’a par défaut pas de logiciel libre sur le modem mais bien un logiciel propriétaire). Pour plus de détails, reportez-vous à la page présentant les aspects légaux du projet.

Si le logiciel exécuté sur le modem est forcément non-libre, alors tout ce qui est connecté directement au modem est nécessairement compromis : si le GPS est attaché au modem et non au processeur principal, le GPS est contrôlé par un logiciel non-libre qui, s’il gère par exemple également la connexion de données (3G), ce qui est le cas pour un modem, pourra éventuellement recevoir ou envoyer des informations obtenues du GPS, telles que la position très précise de l’utilisateur, à tout moment et sans aucun contrôle possible de la part de l’utilisateur. Ainsi, si le matériel est fait d’une telle sorte, utiliser Replicant sur le processeur n’aidera pas à solutionner ce genre de problème.

Un des freins majeurs au développement de Replicant : l’incapacité d’installer une image non-officielle d’Android sur beaucoup de téléphones

En effet, un nombre très important (pour ne pas dire la majorité) des téléphones Android n’offrent aucun moyen à l’utilisateur d’installer un système non-officiel sur son téléphone. Comme s’il était interdit et impossible de changer le système d’exploitation de son ordinateur. Toutefois, sur certains téléphones, il est possible, d’une manière ou d’une autre, de permettre à l’utilisateur de replacer son système actuel par une autre version, pas nécessairement officielle, d’Android. Cette pratique s’appelle le « rooting » du téléphone. Il s’agit généralement d’exploiter une faille de sécurité présente sur le système Android afin d’obtenir les droits root et ainsi de pouvoir écrire un petit logiciel qui permettra par la suite de remplacer le système d’exploitation du téléphone. D’autres méthodes de « rooting » du téléphone consistent à modifier le chargeur de démarrage (dit « bootloader ») du téléphone afin que celui-ci propose l’installation de nouvelles images (il s’agit des fichiers contenant le système Android, le noyau, etc). Alors que la première technique est souvent sans danger, même si elle va dans la plupart des cas rompre la garantie, la seconde technique peut rendre le téléphone inutilisable : si le chargeur de démarrage est altéré au point de ne plus pouvoir fonctionner, le téléphone ne démarrera plus. Ceci n’est, dans la plupart des cas, pas irréversible mais demandera un matériel adapté et une connaissance spécifique pour remettre le téléphone en état.

Toutefois, la plupart des constructeurs réalisent maintenant qu’il est dans leur intérêt de proposer des chargeurs de démarrage permettant d’installer d’autres systèmes d’exploitation, et encouragent parfois le développement de tels systèmes. Le projet CyanongeMod^[1], dérivé d’Android et sur lequel Replicant se base en est un bon exemple : plusieurs constructeurs tels que Samsung ou Sony Ericsson sont en effet très favorables au développement de CyanogenMod pour leurs téléphones (même s’il ne s’agit pas encore de vendre des téléphones avec CyanogenMod pré-installé).

De plus, les « Google phones », le T-Mobile G1, le Nexus One et le Nexus S sont eux-aussi munis d’un chargeur de démarrage permettant l’installation de systèmes non-officiels.

Promouvoir le Web ouvert est l’une des missions de Mozilla.

Mission parfaitement assumée et réussie il y a quelques années avec l’avènement de Firefox qui obligea Internet Explorer à quitter son arrogance pour rentrer dans le rang et se montrer plus respectueux des standards et donc des internautes.

Sauf qu’aujourd’hui la donne a sensiblement changé.

Avec la mobilité, les stores, les apps, les navigateurs intégrés, etc. c’est en effet un Web bien plus complexe qui se présente devant nous. Un Web enthousiasmant^[1] mais plein d’embûches pour ceux qui sont attachés à son ouverture et à sa neutralité.

C’est tout l’objet de ce très intéressant récent billet du développeur Mozilla Robert O’Callahan.

Des changements dans la façon de promouvoir le Web Ouvert

Shifts In Promoting The Open Web

Robert O’Callahan – 30 septembre 201 – Blog personnel
(Traduction Framalang : Antistress et Goofy)

Historiquement Mozilla a dépensé pas mal d’énergie pour promouvoir l’usage du « Web ouvert » plutôt que de plateformes propriétaires et de code spécifique à des navigateurs non standards (IE6). Cette évangélisation reste nécessaire mais le paysage s’est modifié et je pense que notre discours doit s’adapter.

Les plateformes dont nous devons nous préoccuper ont beaucoup changé. Au lieu de WPF, Slivertlight and Flash, les outils propriétaires pour développeurs avec lesquelles il faut rivaliser dorénavant sont iOS et Android. En conséquence, les fonctionnalités que le Web doit intégrer sont à présent orientées vers la mobilité. Nous devons abattre les barrières qui incitent les développeurs d’applications mobiles à écrire des applications natives plutôt que des applications Web, et nous devons promouvoir (et c’est ce que nous faisons !) le développement et l’usage d’applications Web au lieu d’applications natives. Les démonstrations qui ne fonctionnent que sur les navigateurs des micro-ordinateurs sont moins importantes.

Le Web ouvert doit également faire face à de nouvelles plateformes rivales intéressantes : des plateformes qui sont conçues sur les standards du Web mais qui brident l’installation d’applications pour créer une plateforme entièrement contrôlée par le fabricant. L’app store (plateforme de téléchargement d’applications) de Chrome et celle du futur Windows 8 Metro en sont des exemples. J’ai été très déçu de voir que les versions hors connexion de Gmail et Google Calendar n’étaient proposées que sous la forme d’applications pour Chrome. Et même si Angry Birds fonctionne très bien sur Firefox, son affiliation commerciale à Chrome laisse certainement croire qu’il ne fonctionne que sur Chrome. Pour contrer cela nous devons nous assurer que la compétition entre navigateurs reste forte et offre aux développeurs des app stores indépendants des navigateurs. Mozilla travaille dessus, bien sûr :-). Nous devons également exprimer clairement que les app stores dédiés à un navigateur vont à l’encontre d’un Web ouvert.

Une forme de compétition moins évidente résulte de développeurs d’applications se focalisant sur un seul navigateur ou un seul moteur de rendu. Google demande explicitement à ses développeurs de cibler uniquement Chrome avant de penser aux autres navigateurs. C’est compréhensible, mais ça reste perturbant. Une autre préoccupation est de constater que beaucoup de sites pour appareils mobiles ne ciblent que WebKit (parfois implicitement en codant en fonction des bogues de WebKit, le plus souvent explicitement en codant des fonctions propres à WebKit). Beaucoup de développeurs de sites pour appareils mobiles, y compris des développeurs de sociétés renommées comme Google, sont réticents à changer de comportement. C’est un immense problème pour le Web ouvert. Nous avons besoin d’une campagne de promotion des standards du Web ouvert à destination des développeurs de sites pour appareils mobiles. Nous devons être clairs sur le fait que proposer des applications qui ne tournent que sur un seul moteur de rendu, quel que soit ce moteur, va à l’encontre d’un Web ouvert.

C’est malheureux de constater que, parmi les principaux concepteurs de navigateurs, seul Mozilla (et peut-être Opera) n’a pas d’intérêt particulier au succès d’une plateforme Web non ouverte. Je suis content de travailler ici.

Une chose formidable concernant le Web actuellement est l’explosion de nouvelles fonctionnalités et standards pour les développeurs Web. Pourtant nous devons distinguer avec soin les bons standards ouverts des imitations poussées unilatéralement. Toutes les propositions de standards ne sont pas bonnes pour le Web, même si elles sont accompagnées d’une implémentation open-source. Maciej Stachowiak désigne quelques projets de Google – VP8, SPDY, Pepper, and Native Client – qui, bien qu’étant peut-être de bonnes idées, échouent plus ou moins à être de véritables standards ouverts (le manque d’une bonne spécification pour VP8 est un problème que nous pouvons et devrions régler nous-mêmes à Mozilla). Il y a aussi des cas où, même si une bonne spécification collégiale existe et est attendue par certains développeurs, la fonctionnalité n’est pas bonne pour le Web et doit être repoussée. C’est pourquoi je pense que, lorque nous faisons la promotion du Web ouvert, nous devons faire très attention aux spécifications que nous mettons en avant. Ce n’est pas parceque quelqu’un lance une ébauche de spécification avec « CSS » (ou « HTML » ou « Web ») dans le nom en même temps qu’une implémentation embryonnaire, que cette spécification fait partie ou devrait faire partie du Web ouvert. Les gens doivent se demander : est-ce que cette fonctionnalité est bonne pour le Web ? Est-ce qu’il existe une ébauche exhaustive de la spécification qui ne nécessite pas de rétro-ingénierie sur une implémentation existante ? Existe t-il plusieurs implémentations ? Est-ce que la spécification est activement mise à jour pour tenir compte des retours des concepteurs de navigateurs et des développeurs Web ?

C’est une période stimulante et excitante. En dépit des menaces que je viens d’évoquer, c’est super de constater l’investissement massif dans l’amélioration des technologies du Web ouvert. C’est super de voir Microsoft abandonner Silverlight pour une plateforme basée sur les standards. Nous avons remporté quelques batailles, mais la guerre pour les standards du Web ouvert n’est pas finie et nous devons poursuivre le combat, sur les fronts correctement choisis.

Voilà, on y est. Après la musique, c’est désormais la sphère du livre qui est pleinement impactée, voire bousculée, pour l’arrivée inopinée et intempestive du numérique.

Le second connaîtra-t-il les mêmes difficultés et résistances que le premier ?

On en prend le chemin… Sauf si l’on décide de s’inspirer fortement de la culture et des outils du logiciel libre.

Le samedi 24 septembre prochain, dans le cadre du BookCamp Paris 4e édition, Chloé Girard animera avec François Elie un atelier intitulé « Fabrication mutualisée d’outils libres pour les métiers de l’édition ».

Il s’agira de réflechir ensemble à comment « soutenir et coordonner l’action des professionnels du livre pour promouvoir, développer, mutualiser et maintenir un patrimoine commun de logiciels libres métiers » en développant notamment un forge dédiée destinée à « l’ensemble des acteurs de l’édition (éditeurs, distributeurs, diffuseurs, privés, publics, académiques…) »

L’expérience et l’expertise du duo sont complémentaires. François Elie, que les lecteurs du Framablog connaissent bien, sera en effet ici Monsieur Forge (en théorie dans son livre Économie du logiciel libre et en pratique depuis de nombreuses années au sein de la forge pour les collectivités territoriales ADULLACT). Chloé Girard, partenaire de Framasoft dans le cadre du projet Framabook, fera quant à elle office de Madame Métiers de l’édition.

C’est un entretien avec cette dernière que nous vous proposons ci-dessous.

C’est évidemment l’occasion de mieux connaître l’ambition et l’objectif de cette forge potentielle, en profitant de la tribune pour lancer un appel à compétences. Mais nous avons également eu envie d’en savoir davatange sur la situation générale et spécifique de l’édition d’aujourd’hui et de demain, sans taire les questions qui fâchent comme celle concernant par exemple Google Books 🙂

Remarque : Même si le site est encore en construction, nous vous signalons que les avancées du projet pourront être suivies sur EditionForge.org.

Edit : Finalement François Elie ne sera pas disponible pour l’atelier. Mais il reste bien entendu partie prenante du projet.

Une forge Métiers de l’édition – Entretien avec Chloé Girard

Chloé Girard bonjour, peux-tu te présenter succinctement à nos lecteurs ?

Je travaille depuis quatre ans avec David Dauvergne au développement d’un logiciel libre pour les éditeurs, La Poule ou l’Oeuf. C’est une chaîne éditoriale destinée à une édition mixte, papier et électronique.

Nous avons parallèlement créé une entreprise de service en informatique libre pour l’édition et travaillons avec plusieurs éditeurs et prestataires de services aux éditeurs pour de la production, parfois industrielle, de livres numériques. Nous travaillons également à la mise en place d’un processus interne de fabrication électronique lié au traditionnel processus papier.

Je suis également responsable de fabrication papier et électronique pour l’éditeur suisse d’érudition La Librairie Droz, et aborde le problème depuis le point de vue de l’éditeur, aspect financier compris.

Je suis donc au croisement entre l’édition associative, l’intégration et le service en logiciel libre métier et la fabrication de livres, papier et numérique chez un acteur traditionnel de la profession. Ces différentes expériences m’ont naturellement portées à me poser certaines questions qui sont à l’origine de mon intérêt pour cette notion de forge. Questions que nous ne sommes d’ailleurs pas les seuls à nous poser. Les différents BookCamp, salons du livre, commissions du CNL (Centre national du livre), associations professionnelles et éditeurs s’interrogent eux aussi sur les besoins, les outils, les limites, les possibles interactions, les manques, les évolutions, les formes, ou encore les formats dans la fabrication et l’exploitation des livres dans leur(s) version(s) numérique(s).

Comment vois-tu l’évolution actuelle du monde de l’édition, fortement impacté si ce n’est secoué, par les nouvelles technologies ?

Chez les petits éditeurs rien n’a changé. Les processus de fabrication sont toujours les mêmes, les livres sont conçus pour sortir en version papier, les processus de fabrication électronique, quand il y en a, sont externalisés et fortement subventionnés. Car peu d’éditeurs ont les ressources techniques, humaines et financières pour mettre au point de nouveaux mode de production en interne. Et leurs partenaires traditionnels n’en savent souvent pas plus qu’eux, d’autant que la question se pose encore de ce qu’il faut faire, de la pérénité des sources électroniques produites aujourd’hui, de ce qu’il faudra re-produire demain. Le marché s’amorce grace aux subventions à la production électronique. Elles se tariront forcément une fois le marché établi.

Pour autant il faudra bien le suivre ! Or les acteurs en bout de chaîne sont difficilement contrôlables. Par exemple les exigences de validité des fichiers ePUB par Apple sur le eBook Store changent régulièrement et renvoient des messages d’erreur que seuls des développeurs peuvent comprendre, et encore. Bref, beaucoup reste à faire. Une chose a changé au cours des trois dernières années c’est que les éditeurs ont compris qu’ils n’ont plus d’autre que d’y aller.

Je pense qu’il faut donner les moyens à tous les éditeurs de prendre les rênes de ces nouvelles technologies pour maintenir dans l’offre électronique une diversité de contenus et de formes que eux seuls, avec leurs auteurs, peuvent imaginer.

Une « forge Métiers de l’édition », mais quel est donc cet ambitieux nouveau projet ?

Une forge est une forme de département de recherche et développement (R&D) externalisé et, surtout, mutualisé. L’idée est de donner aux professionnels de l’édition les moyens de faire développer et évoluer ensemble les logiciels dont ils ont besoin pour leur métier.

Cela consiste en deux choses : d’une part réunir en un même lieu, atelier et magasin, les outils et compétences informatiques qui peuvent travailler ensemble, si nécessaire. Et, d’autre part, encadrer les éditeurs, imprimeurs, distributeurs, dans la rédaction des cahiers des charges de ces nouveaux outils (bureau d’étude).

Évidemment il est plus que souhaitable que ces outils soient libres, pour des questions d’interopérabilité, d’extensibilité, de transfert de compétences… mais aussi d’économies. Le code étant libre il est payé une fois pour son développement puis disponible pour tous. Disponible pour utilisation mais aussi pour le faire évoluer en fonction de nouveaux besoins, de nouveaux outils, de nouveaux support…

Tu évoques aussi « une place de marché entre clients métier, entrepreneurs et communauté du logiciel libre ». Peux-tu nous en dire plus et nous donner quelques exemples réels ou fictifs de situations où la forge est potentiellement un avantage ?

Les forges logicielles, horizontales, réunissent les acteurs du développement d’une application. Ici nous avons une forge cliente mise en place par les utilisateurs (professionnels de l’édition) qui y rencontrent les développeurs (représentés par les forges logicielles) aussi bien que les sociétés leur permettant de créer et de mettre en production ces outils. Les professionnels de l’édition peuvent donc lancer des appels d’offre auprès de prestataires qui peuvent y répondre ensemble ou séparément. Nous avons donc une réelle place de marché métier avec des clients et des vendeurs.

L’intérêt, par rapport à un système d’achat/vente classique de service informatique, c’est la mutualisation des expertises, du code et des services. Les éditeurs aujourd’hui rencontrent de nouveaux besoins, très techniques. Juger de la façon d’y répondre demande une expertise rare et coûte cher (voire très cher). Très peu d’éditeurs savent et peuvent assumer cela seuls et risquent d’y perdre beaucoup.

Imaginons qu’un éditeur convertisse aujourd’hui son catalogue d’ouvrages dans un format donné de livres électroniques. Que fera-t-il, ou plutôt comment fera-t-il si les supports de lecture de livre de demain, ebooks, tablettes ou PC, lisent un autre format que celui-là ou une version plus récente ? Nous sommes ici dans une situation parfaitement concrète et déjà réelle.

Sachant que la conversion d’un ouvrage papier en ePUB aujourd’hui coûte au minimum 1€ la page, qu’environ 60 000 ouvrages sont publiés par an en France et que le patrimoine à convertir regroupe des centaines de milliers d’ouvrages on peut imaginer les conséquences s’il faut re-produire ces fichiers.

Aujourd’hui cette conversion est largement subventionnée. Mais lorsque le marché du livre électronique sera suffisamment amorcé, ces subventions baisseront ou disparaîtront. Il faudra alors que les éditeurs assument seuls l’évolution de leur catalogue électronique. Et qu’ils en assurent l’évolution régulière. Une forge leur permettrait par exemple, si le format de départ est ouvert, de faire développer collectivement un outil de mise à jour automatisée du catalogue. Et de faire évoluer cet outil, avec une réactivité bien plus importante que s’il fallait attendre d’un éditeur de logiciel propriétaire qu’il décide lui-même de la sortie de la mise à jour nécessaire.

Les éditeurs y gagnent en matière d’autonomie, de réactivité sur leur marché et de capacité d’innovation. D’autant que les acteurs logiciels de la forge peuvent y déposer des « appels de demandes » c’est-à-dire des propositions d’innovation ou de développements auxquels les clients n’auraient pas forcément pensé. On a donc un lieu de propositions techniques en même temps que de marché, dans un cadre d’expertise partagée.

L’exemple simple d’évolutivité des formats est un problème que les éditeurs connaissent déjà bien ou qui les retient de se lancer dans l’édition numérique. Mais ils sont confrontés à bien d’autres problèmes : la réunion des processus papier et électronique (PDF imprimeur/ePUB, XML InDesign/XML divers…), l’exploitation des contenus en réseau (schémas de métadonnées, protocoles de communication entre catalogues et serveurs, schémas XML de description de contenus), le chiffrement des fichiers électroniques garantissant l’intégrité d’un document, l’enrichissement d’un ouvrage avec des contenus dynamiques ou multimédia, le lien livres et réseaux sociaux, l’offre de sorties s’adaptant à des écrans divers (graphisme), à des lecteurs divers (niveau de lecture, multilinguisme), sans perdre la notion de référence intellectuelle commune, les livres-applications, la gestion documentaire, les liens éditeurs/distributeurs/diffuseurs, la gestion des droits d’auteur, le lien entre l’exploitation du catalogue et les outils internes de gestion, de facturation, etc. Et encore, ces exemples ne sont qu’un petit apperçu des besoins et questions. Sachant que les réponses vont devoir évoluer au même rythme que les supports de lecture et les systèmes d’exploitation. Et que les problématiques ne sont pas les mêmes selon que l’on édite des romans, des thèses, des livres d’art, des manuels scolaires de la documentation technique ou des revues scientifiques.

Évidemment, chaque éditeur peut faire développer ses propres outils ou payer des licences pour chaque logiciel nécessaire. Mais gérer l’interopérabilité entre ces applications et un système un peu intégré deviendra impossible ou extrêmement onéreux. J’en suis témoin au quotidien. Les professionnels de l’édition ne pourront suivre l’évolution de leur métier, et la maîtriser, que collectivement.

Sauf s’ils décident de tout confier à Google Books !

Il faut considérer Google comme un prestataire comme les autres. Sauf que, étant donné la puissance du prestataire il vaut mieux être théoriquement et technologiquement averti et exigeant ! D’où la nécessité d’avoir ses propres outils pour ne pas être trop vulnérable.

En ce qui concerne leurs livres épuisés Google offre aux éditeurs une solution de facilité pour remettre sur le marché des livres qui n’y sont plus et n’y seront plus sans cela, étant donné le coût que cela représente. Pourquoi pas. La difficulté est alors de rester maître du cahier des charges et il vaut sans doute mieux posséder ses propres sources à négocier auprès de Google Books que de laisser Google convertir puis discuter des conditions.

Dans le passé beaucoup d’éditeurs ont confié la mise en page et l’impression de leurs ouvrages à des prestataires extérieurs, plus petits, plus locaux que Google, sans jamais réclamer en retour ni leurs fichiers natifs ni même les PDF imprimeurs ! Ils sont ainsi aujourd’hui dans certains cas obligés de racheter leurs propres fichiers à ces prestataires ou repartent du papier pour reconstituer leurs sources ! À eux de voir si ils veulent renouveler l’expérience.

Avoir des outils disponibles pour produire leurs sources efficacement et les faire évoluer, leur permettrait de négocier différemment avec Google aujourd’hui mais aussi demain. Parce que demain Google va offrir de nouveaux services sur ces sources. S’il est encore le seul à pouvoir, techniquement, les offrir, il sera à nouveau en position de force. Or ces épuisés constitueront sans doute une part non négligeable des ventes. Il vaut donc mieux se préparer à récupérer ces sources et à les exploiter intelligemment soi-même. Face aux équipes de développement de Google un éditeur seul, ou n’importe lequel de ses prestataires en édition numérique, à intérêt à avoir de sacrés moyens pour offrir des solutions concurrentes.

Pour les publications récentes et nouvelles la question se pose différemment. La question n’est pas seulement de mettre en ligne, de mettre à disposition pour achat, mais bien aussi de créer des versions numériques qui apportent quelque chose de plus par rapport au papier : pour le lecteur, pour l’exploitation des savoirs, pour la conservation du patrimoine. C’est un acte éditorial, ce n’est donc pas Google qui peut s’en charger.

Après, si Google offre des solutions libres assurant l’interopérabilité avec les outils internes de fabrication et de gestion des éditeurs, distributeurs, imprimeurs, etc. Si Google produit des sources ouvertes que les éditeurs peuvent récupérer, retirer, si l’on peut interfacer des outils libres de gestion de droits avec Google Books, si… alors bienvenue à Google au sein de la forge « métiers de l’édition » ! À voir…

Face à Google comme face à n’importe quel prestataire et plateforme d’exploitation il faut que les éditeurs travaillent ensemble, et avec leurs distributeurs, diffuseurs, etc, à des solutions qui leurs permettent de maîtriser leurs oeuvres et leur métier.

Après Google, en quoi cette forge se distingue-t-elle des API censés « ouvrir le contenu aux développeurs » telles que proposées par Amazon ou tout récemment par Pearson ?

L’initiative de Pearson est géniale ! « L’idée est de regarder si la créativité des développeurs permet d’amener l’exploitation de ces contenus dans des directions que les éditeurs n’avaient pas explorées jusqu’alors ». Mais ce qui est intéressant dans l’article de Guillaud c’est aussi sa dernière phrase : « Assurément, Pearson lance un mouvement que les plus gros ne devraient pas tarder de prolonger… »

Que vont faire les petits et moyens éditeurs pendant ce temps-là ? Et les diffuseurs, les libraires ? Je crois que la forge, la mutualisation, un patrimoine d’outils communs, leur permettront justement d’accéder à ce type de moyens d’exploitation, de plateformes éditoriales ouvertes aux codeurs, aux innovations. Demandez aux éditeurs, au hasard, si ils savent ce qu’est une API ! Il faut une sacrée expertise pour mettre en oeuvre ce type d’accès et les faire évoluer, sur les plans technique mais aussi juridique d’ailleurs. Même les gros éditeurs ont besoin, pour la plupart, de mutualiser, au moins en partie, les frais de R&D pour développer et innover dans de tels services. Or c’est ce que tous cherchent à faire. Mais je ne suis pas sûre que Pearson va leur donner ses trucs demain !

Est-ce une application directe et concrète des propositions de François Elie dans son livre Économie du logiciel libre ?

Oui, absolument. Et François Élie nous accompagne dans la réflexion et la présentation du projet, fort de son expérience de l’Adullact (Association des Développeurs et des Utilisateurs de Logiciels Libres pour l’Administration et les Collectivités Territoriales) et de son verbe coloré. La killer application openCimetiere fait toujours son petit effet !

« On ne peut utiliser que des logiciels qui existent » et « un logiciel libre est gratuit une fois qu’il a été payé ». Ces deux phrases extraites de son livre résument bien l’intérêt que peuvent trouver clients et développeurs libres au sein d’une telle forge : 1) coté client : maîtriser ses outils métier, gagner en réactivité, faire, éventuellement, des économies 2) coté développeurs : financer en amont le développement libre, intégrer une place de marché active réunissant des compétences multiples pour ne pas réinventer la roue.

Quels sont les principaux freins que vous risquez de rencontrer et qu’il faudra dépasser d’après toi ? Le poids des habitudes ? L’absence d’une réelle culture de la mutualisation ? La concurrence non libre ?

La forge Adullact, comme son nom l’indique, s’adresse à des clients et des fonds publics. L’idée de dépenser des fonds publics une seule fois pour tous est (semble !) naturelle. Dans le cas d’une forge métiers de l’édition nous nous adressons en grande partie à des acteurs privés. Et le premier frein que nous avons rencontré est bien celui de la mutalisation des fonds : « pourquoi est-ce que je paierais pour des logiciels dont tous bénéficieront, y compris ceux qui n’auraient pas participé ? » Le problème n’est pas seulement celui du partage mais de la perte d’un avantage concurenciel.

En ce qui concerne le partage ce n’est pas très difficile à argumenter : ceux qui en profiteront ne tarderont pas à participer, à hauteur de leurs moyens et de leurs besoins. D’autre part plus un logiciel sera utilisé plus il sera pérenne.

Pour la question de la concurrence c’est plus délicat puisque le service autour des livres électroniques devient un enjeu économique. Il ne s’agit plus seulement de vendre des exemplaires mais aussi des services sur les contenus. Or les outils de fabrication ont un impact sur les possibilités de services commerciaux en aval. Imaginons par exemple un outil offrant de fabriquer des livres avec plusieurs niveaux de contenus auxquels les lecteurs auraient accès ou non selon qu’ils sont acheteur unique, abonnés ou abonnés premium.

Mais les éditeurs sont libres de faire développer certains outils, qui leurs semblent moins concurrenciels dans cette logique de mutualisation, et de faire développer chacun pour soi des extensions ou des modules d’exploitation qui leurs seraient propres. Une forge n’implique pas d’y faire produire tous ses projets. Quitte à se rendre compte finalement qu’il est plus intéressant de les y verser pour les faire maintenir et évoluer collectivement.

Cette logique de mutualisation dans une économie privée et auprès d’acteurs dont les finances sont souvent fragiles n’est pas gagné. Pourtant nous travaillons avec plusieurs éditeurs qui en rêvent. Ils n’ont ni les compétences ni les moyens de faire développer seuls les outils qu’il leur faut et que personne ne leur propose aujourd’hui.

Un autre obstacle est l’absence de culture du logiciel libre dans l’édition : elle était celle que l’on peut imaginer dans un milieu très peu technophile et surtout préoccupé de ne pas avoir à mettre les mains dans le cambouis, l’image du logiciel libre étant celle de la ligne de code dans un terminal. D’autant que les besoins étaient en (très) gros jusqu’ici celui d’un seul outil, de mise en page, propriétaire, cher, produisant un PDF, unique besoin des imprimeurs.

Depuis quelques années la notion de format ouvert fait cependant son chemin, notamment avec le format ePUB et le XML. Mais on est encore dans la logique du bon format, plutôt que dans celle du format ouvert.

J’ai quand même entendu il y a un an et demi un responsable de l’édition électronique chez un éditeur important affirmer qu’il n’utiliserait plus en fabrication que des logiciels libres. Pour des questions de pérénité et de maîtrise de son catalogue.

Mais pour répondre à cela il faut des acteurs et des outils libres qui répondent aux besoins de marchés importants, de volumes importants et d’éditeurs pressés. Il faut des partenaires libres solides, aisément identifiables, dans un écosystème libre métier qui permet de répondre rapidement aux évolutions des besoins.

C’est ce à quoi nous appelons aujourd’hui. Nous devons présenter dès l’origine de cette forge les acteurs du logiciel libre, éditeurs de logiciels, communautés, intégrateurs, pertinents, compétents et innovants pour répondre aux besoins de ces métiers. Nous connaissons un certains nombre de ces ressources et acteurs, mais pas tous. D’autant que certaines des compétences dont ont besoin les éditeurs aujourd’hui étaient jusque-là exploitées dans d’autres domaines métiers, telles que la gestion documentaire.

Nous avons besoin de constituer un catalogue de ressources libres à présenter aux éditeurs pour amorcer cette forge.

Ensuite se posera la question de sa gouvernance puisque, comme pour l’Adullact, la forge est un outil monté par les clients pour les clients, donc par les éditeurs pour les éditeurs. Je pense qu’une association professionnelle métier devrait prendre en charge ce projet comme une forme de nouveau service offert à ces membres.

Deux réunions sont prévues pour envisager concrêtement les actions à mettre en oeuvre pour que cette forge soit effective : le 24 septembre au BookCamp Paris 4 qui se tiendra au Labo de l’Édition (atelier 13) et début octobre dans une réunion organisée par le MOTif, organisme de politique du livre de la Région Île de France.

Le noyau Linux a 20 ans. C’était en effet le 25 août 1991 que Linus Torvalds (qui fait justement l’objet de la librologie de la semaine) a en effet posté son célèbre message.

Pour l’occasion la Linux Foundation nous a proposé un petit clip anniversaire que nous avons non seulement sous-titré (merci Framalang) mais également doublé en français (merci Padoup-Padoup).

La vidéo en VO STFR

—> La vidéo au format webm
—> Le fichier de sous-titres

La vidéo en VF

—> La vidéo au format webm

Sur le même sujet, on pourra également lire la très intéressante interview donnée par Torvalds à LinuxFr.

Transcript

URL d’origine du document

L’histoire de Linux (à l’occasion de son 20e anniversaire)

Notre histoire commence il y a vingt ans. Boris Elstine prenait ses fonctions, Jay Leno remplaçait Johny Carson au Tonight Show et les téléphones portables étaient très très gros.

C’est en août 1991 qu’un étudiant en informatique de 20 ans nommé Linus Torvalds s’est assis devant son écran à Helsinki pour envoyer un des plus célèbres messages de l’histoire de l’informatique

« Salut tout le monde… Je suis en train de faire un système d’exploitation libre (c’est juste un passe-temps, rien d’aussi professionnel ni énorme que GNU) il ne prendra sûrement jamais rien d’autre en charge que des disques durs AT puisque c’est tout ce que j’ai »

Et bien, son annonce de projet open source a vite fait le tour du monde et des développeurs de tous les coins ont contribué au code.

Linus a baptisé le noyau de son système d’exploitation Linux en choisissant un manchot comme mascotte après un petit incident au zoo.

Il a pris assez vite une décision qui allait être déterminante pour l’avenir de Linux autant que sa technologie. Il a choisi la licence GPL, créée par un visionnaire nommé Richard Stallman.

Le noyau Linux, accompagné de la licence GPL et d’autres composants GNU, ont révolutionné l’industrie informatique avec une liste de libertés très simples mais très importantes : La liberté d’utiliser le logiciel à son gré. La liberté de modifier le logiciel pour l’adapter à ses besoins. La liberté de partager le logiciel avec ses amis et ses voisins. Et la liberté de distribuer les modifications qu’on a faites

Ces principes radicaux ont propulsé la diffusion de Linux partout dans le monde et de façon un peu paradoxale Linux qui était une expérience d’amateur est devenu la base d’un vaste écosystème commercial qui se développe.

Des entreprises ont basé leur activité sur Linux. En 1999 le cours de l’action de Red Hat a triplé en devenant la première entreprise à utiliser Linux sur le marché. Cette même année IBM a dépensé un milliard de dollars pour améliorer et promouvoir Linux

(Et comment il s’appelle ? — son nom est Linux)

Rapidement, Linux a bousculé les poids lourds de l’industrie et a permis le développement accéléré d’Internet avec ses logiciels libres.

Bref : Linux a révolutionné le monde de l’informatique.

Bien sûr, dès qu’un phénomène aussi novateur s’impose, il essuie un feu croisé de critiques mais Linux ne s’est pas contenté de survivre, il a pris de l’ampleur. Aujourd’hui la communauté de développement du noyau compte des milliers de membres, et des centaines d’entreprises qui collaborent ensemble au développement de Linux. Tous les trois mois une nouvelle version de Linux voit le jour.

Donc où en est Linux aujourd’hui ? Il permet 75% des transactions boursières dans le monde, Il fait tourner les serveurs d’Amazon, de Facebook, de Twitter, d’eBay, et de Google. Vous vous servez de Linux littéralement à chaque fois que vous allez sur internet. C’est dans votre téléphone, votre télé, sur 95% des superodinateurs, et dans beaucoup d’autres appareils que vous utilisez tous les jours. Linux est partout.

Et qu’est devenu le programmeur d’Helsinki qui a tout commencé ? Il orchestre le travail de cette armée mondiale de développeurs depuis le bureau de sa maison à Portland en Oregon, en tant que membre de la Fondation Linux.

Alors que nous célébrons les 20 ans de Linux, nous pouvons nous retrouver dans cette histoire.

Merci d’avoir contribué à cette saga tout au long de ces 20 ans.

Tous nous connaissons, ou croyons connaître, Wikipédia. Mais nous sommes moins nombreux à avoir saisi que ce n’est que l’un des nombreux projets (mais quel projet !) de la Wikimedia Foundation.

Parmi ceux-ci il y a Wikimedia Commons ou Commons, une « médiathèque de 10 786 504 fichiers média librement réutilisables et que chacun peut enrichir ».

Christian Biasco, de la Wikimedia Italie, a pris l’excellente habitude de nous proposer de courtes vidéos didactiques pour nous présenter ces projets. Après Wikipédia et Wikisource, nous avons choisi de vous reproduire ci-dessous celle donc consacrée à Wikimedia Commons.

—> La vidéo au format webm
—> Le fichier de sous-titres

Remarque 1 : Mais, attention, ici, et plus encore que pour l’encyclopédie, le respect du droit d’auteur est strict et contraignant (droit du photographe, du photographié, droit des marques, de l’architecture, droit US, droit local, etc.).

Remarque 2 : Et tout ceci est une excellente occasion pour faire ensemble de fructueuses promenades comme en témoignent ces deux vidéos extraites de précédents billets : Google Art Project : Une petite note discordante dans un concert de louanges (bas de page) et Promenons-nous dans New York en photographiant pour Wikipédia.

Transcript

URL d’origine du document sur Commons

Wikimedia Commons (aussi appelé tout simplement Commons) est un site internet qui héberge des images, de l’audio et de la vidéo ainsi que d’autres ressources multimédia dont le but est d’illustrer ou d’éduquer. Les contenus de Commons peuvent être utilisées librement et l’utilisation commerciale est permise, tant que les conditions de la licence sont respectées.

Frère de Wikipédia, Commons a vu le jour en 2004 comme dépôt commun pour les différents projets de la Wikimedia Foundation. Commons a ensuite évolué en un projet avec ses propres règles.

Sur Commons il est possible de trouver des photos de lieux et de monuments, d’animaux, de plantes, de minéraux. Des photos de personnalités, d’objets communs et d’œuvres d’art. Ainsi que des enregistrements historiques et des versions numériques de livres anciens. Des schémas, des diagrammes, des graphiques et des cartes. Des vidéos et des enregistrements audio… et bien d’autres choses.

Dans certains cas les ressources ne sont plus couvertes par le droit d’auteur, dans d’autres cas, les auteurs ou les ayant-droits ont accordé une permission pour que les œuvres soient utilisables en respectant de simples conditions, comme l’attribution ou l’utilisation de la même licence pour les éventuelles œuvres dérivées.

Plus de sept millions de ressources sur Commons, librement téléchargeables et utilisables pour la recherche, les sites web, les manifestes, la publicité, les œuvres d’art…

Les ressources de Commons peuvent être insérées directement sur les pages de l’encyclopédie Wikipédia et sur tous les autres projets Wikimédia, bien sûr en respectant les règles du projet spécifique, de la communauté linguistique de référence et de la législation du pays de provenance.

Chaque fichier sur Commons a sa propre page wiki. Après le titre, on trouve la ressource multimédia ou une version réduite, comme dans le cas de photos très grandes. Une description (souvent traduite en plusieurs langues) est insérée ainsi que toutes les informations disponibles, comme la source, l’auteur, la date et les termes d’utilisation. L’historique du fichier liste toutes les éventuelles modifications. Car il est en effet possible de corriger et d’améliorer les fichiers téléversés par d’autres utilisateurs. Par ailleurs sont listées les pages de Commons et des autres projets de la Wikimedia Foundation qui ont lié et utilisé la ressource. En bas de la page on trouve des catégories, par le biais desquelles la ressource est cataloguée. Les catégories sont standardisés en anglais, mais pour les utiliser il est suffisant d’avoir une connaissance approximative de la langue.

Comment pouvez-vous contribuer à Commons ? Un amoureux de la photographie peut téléverser ses photos, un bon dessinateur peut ajouter des diagrammes et des animations, un musicien l’enregistrement d’œuvres libres. Des enregistrements de films et pièces théâtrales peuvent être insérés, à condition qu’il ne soient pas couverts par des droits d’auteur.

Afin de pouvoir téléverser un fichier sur Commons, il faut s’être préalablement enregistré. La création d’un compte, gratuite, est rapide et n’est pas nécessaire si on a déjà un compte sur un autre projet de la Wikimedia Foundation. Il est seulement possible de téléverser des ressources en format libre. Pas exemple, pour les vidéos seul le format Ogg Theora est admis. Il existe de nombreux convertisseurs open source qui peuvent être téléchargés et utilisées gratuitement.

Tous les fichiers téléversés doivent respecter : la loi des États-Unis, où est légalement implantée la Wikimedia Foundation ; les lois des pays dont est issue la ressource ; les lois du pays de l’utilisateur, qui reste responsable des contenus insérés. Il faut contrôler qu’on n’enfreint pas les lois sur la vie privée ou sur les marques déposées ou les restrictions d’utilisation des œuvres d’art de la part de certains musées.

Dans le cas d’œuvres déjà publiées ailleurs sans licence libre, l’auteur ou les ayant-droits doivent envoyer un courriel électronique dans lequel ils s’identifient en déclarant qu’ils permettent la publication de la ressource sous une licence libre.

Comme Wikipédia, Commons est un wiki, un site ouvert à tout le monde il est géré par des bénévoles du monde entier qui s’engagent à identifier et catégoriser les ressources, à compléter ou traduire les descriptions, à créer les galeries et les pages spécifiques selon le thème, à identifier et supprimer les ressources avec des licences ou des sources incomplètes.

Commons est un projet multilingue : un site unique qui contient toutes les traductions et les différentes communautés linguistique cohabitent dans le même espace.

Pour faciliter la recherche des ressources au sein de Commons, ainsi que dans les catégories, est possible chercher dans les galeries, qui sont des pages spécifiquement créées pour accueillir des ressources sur un sujet particulier.

Les discussions à propos d’un contenu spécifique ont lieu sur la page de discussion dédiée à côté de chaque ressource de Commons, tandis que les discussions générales ont lieu sur une page spécifique. Les communications sont faites principalement en anglais, mais des pages dédiées existent qui permettent d’échanger dans d’autre langues.

Pour les problèmes à caractère technique on trouve un bureau d’information et de nombreuses pages d’aide, traduites en différentes langues. Pour des questions spécifiques ou particulièrement complexes, on peut demander aux administrateurs, qui sont des bénévoles qui ont gagné avec le temps la confiance de la communauté grâce à leur connaissance du projet. Eux seuls sont autorisés à exécuter certaines opérations délicates, comme par exemple la suppression d’une ressource.

L’utilisateur d’une ressource de Commons doit toujours s’assurer que les lois de son propre pays de provenance sont respectées. Commons ne peut garantir la légalité de l’utilisation d’une ressource dans tous les contextes possibles, ni sa fiabilité ou son exactitude. mais il est incroyable de voir combien de ressources valables et utilisables ont été téléversées.

De plus en plus d’archives d’état, de musées, de bibliothèques, de collections privées effectuent des dons de ressources, petits ou grands qui deviennent ainsi un patrimoine utilisable par tous.

Plusieurs photographes professionnels publient leurs œuvres sur Commons, fiers de voir leur travail repris d’un bout à l’autre du monde. Il arrive aussi que des illustrateurs publient sur Commons des schémas ou des diagrammes particulièrement efficaces et élégants.

Il existe plusieurs mécanismes permettant de reconnaître les ressources de qualité : Par exemple, chaque année se tient un concours destiné à choisir la photo de l’année. Une autre sélection choisit les images les plus belles créées par les utilisateurs de Commons et une autre encore prime les images les plus efficaces dans leur catégorie. Tous les jours, une image particulièrement intéressante est sélectionnée et cette pratique existe aussi pour les autres ressources multimédia.

Pour soutenir Commons financièrement vous pouvez faire un don à la Wikimedia Foundation ou vous pouvez choisir de soutenir (aussi avec les 0,5% applicable en Italie).

Wikimedia Italia, une association à but non lucratif qui s’occupe de promouvoir, en Italie, Commons et les autres projets de la Wikimedia Foundation.

Dans l’un de nos récents framabooks, le professeur néerlandais Joost Smiers se pose la question suivante : Et si nous supprimions carrément le copyright ?

Pour en conclure que les cartes seraient évidemment redistribuées mais que le monde ne s’arrêterait pas de tourner. Et force est de reconnaître qu’il n’est pas le seul à envisager cette radicale solution.

Or, apparent paradoxe, il se trouve que, juridiquement parlant, les licences des logiciels libres sont adossées au copyright. Elles le respectent pour mieux, en quelque sorte, le retourner en leur faveur, à fortiori lorsque ces licences sont également copyleft, comme la plus célèbre d’entre elles, la licence GNU GPL.

C’est au père de cette dernière, Richard M. Stallman^[1], que Glyn Moody s’est adressé pour lui demander ce qu’il pense du copyright et de l’avenir du logiciel libre si le copyright n’existait plus.

Le logiciel libre pourrait-il exister sans le copyright ?

Could Free Software Exist Without Copyright?

Glyn Moody – 9 juillet 2010 – ComputerWorldUK
(Traduction Framalang : Vincent, Barbidule, Toufalk, Pablo, Goofy, et Petrus6)

Il y a quelques jours, j’écrivais sur la manière dont la licence GNU GPL de Richard Stallman utilise le copyright afin de garantir que les utilisateurs de la licence partagent le code qu’ils distribuent. S’ils ne le font pas, ils sont en violation de la GPL, et perdent donc leur protection contre les actions en violation de copyright.

Cela est bel et bon, mais comme beaucoup l’ont fait remarquer, cela a pour conséquence paradoxale que la licence GNU GPL dépend du copyright, un monopole intellectuel, pour promouvoir la liberté intellectuelle. De plus, cela semble condamner le logiciel libre à un sorte de symbiose avec le copyright, en le contraignant à défendre ce monopole sans lequel la GPL ne serait pas aussi puissante.

Voilà une perspective bien sûr légèrement dérangeante, et je m’étais donc dit il y a peu que je soulèverais la question avec RMS lui-même, puisqu’il avait forcément conscience du problème et qu’il avait peut-être une solution (ce que j’espérais). Ces derniers mois la question s’est posée à plusieurs reprises, j’ai donc pensé que ça valait le coup de publier ses réponses à mes interrogations, pour donner un éclairage sur ce débat crucial.

D’abord, je lui ai demandé comment nous devrions réformer le copyright, puisque c’est un monopole intellectuel dont abusent les éditeurs, mais que la GNU GPL en dépend.

Voici la réponse de Stallman :

« Pour la plupart des œuvres, je pense que le copyright pourrait être acceptable s’il était plus court (je propose 10 ans), s’il permettait une redistribution de copies verbatim non commerciale, et si les « remix » modifiant l’œuvre étaient clairement considérés comme un usage légitime (« fair use »).

Cependant, je pense que les logiciels et toutes les œuvres ayant une utilité concrète doivent être libres. »

Il a poursuivi :

« Je serais heureux que le copyright sur les logiciels soit aboli si c’était fait d’une manière telle que la liberté des logiciels soit garantie. Après tout, le but du copyleft est justement d’atteindre cet objectif pour les dérivés de certains programmes. Si tous les logiciels étaient libres, nous n’aurions pas besoin du copyleft.

Cependant, menée de la mauvaise manière, l’abolition du copyright pourrait n’avoir aucun effet sur les logiciels privateurs (car plus que le copyright, c’est le CLUF, Contrat de licence utilisateur final, et le caractère secret du code qui créent des restrictions), elle viendrait simplement remettre en cause la pratique du copyleft. Naturellement, dans ce cas je m’y opposerais.

En d’autre termes, je me sens plus concerné par l’effet de la loi sur les libertés des utilisateurs que par ce qui pourrait arriver au copyright en tant que tel. »

Je lui ai alors demandé comment l’abolition du copyright pourrait être menée pour que le logiciel libre soit encore possible.

« Il faudrait éliminer le copyright sur les logiciels, déclarer les CLUF juridiquement nuls et adopter des mesures de protection du consommateur qui imposent la distribution du code source aux utilisateurs et l’interdiction de la tivoisation. »

Stallman a expliqué ce qu’il entendait par « tivoisation » il y a quelques années, quand la GNU GPL v3 était en cours d’élaboration. C’est le fait d’élaborer une machine telle que, si l’utilisateur installe une version modifiée d’un programme, la machine refuse de l’exécuter.

Ce nom vient de Tivo, le premier produit dont j’ai su qu’il faisait ça. Le Tivo contient des logiciels libres sous GPL v2, dont le code source est fourni. L’utilisateur du Tivo peut donc modifier le programme, le compiler et installer la version modifiée sur sa machine. Celle-ci refusera cependant de fonctionner car elle aura décelé qu’il s’agit d’une version modifiée. Cela signifie qu’en théorie, l’utilisateur a la liberté numéro 1 (NdT : la liberté d’étudier le fonctionnement du programme), mais en réalité, il ne l’a plus, ce n’est qu’un leurre. Cette pratique est systématique, et elle constitue une menace générale pour la liberté de l’utilisateur.

Nous avons donc décidé d’empêcher cela, en modifiant les conditions de distribution des binaires. Nous avons précisé que si vous distribuez les binaires dans un produit, ou pour être utilisés dans un produit, alors vous devez fournir tout ce dont l’utilisateur a besoin pour installer sa propre version modifiée et faire que le produit fonctionne de la même façon, sous réserve que les changements effectués dans le code ne modifient pas la fonction. L’important est que non seulement l’utilisateur puisse être capable d’installer et faire fonctionner une version modifiée, mais encore que celle-ci doit être capable de faire la même chose que l’original.

Il faut noter que Stallman ne croit pas nécessaire d’abolir complètement le copyright, il propose juste de le restreindre un peu ; la durée exacte pouvant faire l’objet de débat :

« Ma proposition de faire durer le copyright 10 ans à partir de la date de publication se veut conservatrice. Je pense que 5 ans suffisent et je n’ai rien contre une période plus courte encore mais je ne me battrai pas pour ça. »

D’après Stallman, l’avantage de cette « modeste proposition » est qu’elle ne requiert pas de grandes modifications législatives. Alors que ce serait bien le cas pour les mesures de protection de l’utilisateur qui seraient nécessaires afin de préserver la liberté du logiciel si le copyright venait à disparaître.

Il est plus facile de faire pression pour ramener le copyright à ses conditions d’origine (14 ans pour les nouvelles oeuvres avec, en option, 14 années supplémentaires) plutôt que pour l’abolir complètement. C’est ironiquement une approche très pragmatique, alors même que Stallman est souvent accusé du contraire.

Hier soir je suis tombé sur un article conseil en anglais de la FSFE qui déclinait quelques bonnes et mauvaises pratiques si vous voulez faire connaître le logiciel libre autour de vous (et tout le bien que vous en pensez).

Pour ne pas surcharger la barque Framalang (qui doit tanguer quelque part entre les Seychelles et les Maldives), j’ai choisi de m’adresser à d’autres esclaves bonnes volontés du Libre. Ceux de l’émérite site LinuxFr qui présente la particularité d’abriter en son sein des êtres prêts à tous les sacrifices pour faire avancer La Cause.

Et hop, un rapide journal bien senti avec un Framapad inside, et le tour est joué.

Suffit d’attendre et de ne pas oublier de bien saluer tous ceux qui franchissent le pad (par contre j’avais oublié la bière, désolé).

Et c’est ainsi qu’en plein samedi soir du mois d’août, nous traduisîmes en à peine trois heures et à plusieurs mains (une bonne petite vingtaine, soit, si vous me suivez, dix personnes) ce court exposé plein de bon sens (à la limite de l’enfonçage de portes ouvertes ?) qui devrait, à n’en pas douter, faire au moins doubler le taux de convertis dès la rentrée prochaine.

Ça a bossé dur et vite en tout cas, rien que pour le titre, on a eu les propositions suivantes : « De la communication efficace du logiciel libre », « Plaidoyer efficace pour le logiciel libre »^[1], « De l’évangélisation efficace du logiciel libre », « Défense efficace du logiciel libre », pour finalement retenir « Promouvoir efficacement le logiciel libre ».

Plus sérieusement, grand merci à mes (éphémères) compagnons de route (longue mais libre) pour ce traducthon improvisé. Je reste, comme au premier jour, fasciné par tout ce que l’on peut réaliser ensemble, de GNU/Linux à cette toute modeste traduction plurielle.

Promouvoir efficacement le logiciel libre

Effective Free Software advocacy

Sam Tuke – 10 août 2011 – FSFE
(Traduction collective LinuxFr : NeoX, mansuetus, Roro7302, Jeece, eastwind, crabs, fiuzzy, oktail, qdii et quelques autres anonymous)

Expliquer ce qu’est le logiciel libre est une tâche importante mais parfois délicate et difficile. Des concepts et une terminologie complexes, de subtiles variantes et un contexte social, politique et économique particulier, peuvent nous éloigner d’une communication efficace. Ces quelques lignes ont pour but de vous aider à présenter vos propos pour qu’ils soient à la fois plus clairs, cohérents et convaincants.

1) À faire : Dès qu’une occasion se présente, parler ouvertement et régulièrement du logiciel libre avec vos amis et vos proches.

1) À éviter : Critiquer les autres pour leur désintérêt ou leur manque de compréhension du logiciel libre. Essayez plutôt d’écouter ceux qui ne sont pas d’accord avec vous en n’essayant pas de les forcer à adopter votre point de vue. Le logiciel libre est un sujet intrinsèquement important. Mais si une personne en particulier ne peut en appréhender sa valeur, alors n’insistez pas et attendez de trouver quelqu’un d’autre qui sera prêt à poursuivre la discussion avec vous.

2) À faire : Présenter, de manière constructive, des exemples réels de problèmes posés par les logiciels propriétaires. Faire allusion au vendeur peut être tout aussi efficace que de mentionner le nom d’une entreprise.

2) À éviter : Focaliser sa critique du logiciel propriétaire sur une seule et unique entreprise. Si vous avez besoin de nommer une entreprise, essayez d’en citer d’autres. Les problèmes liés aux logiciels non libres sont génériques. Partir d’une situation globale affectant une pratique ou un marché donnera plus de poids à vos arguments et évitera les partis pris.

3) À faire : Citer les faits et les sources à chaque fois que cela est possible et être clair sur la provenance des informations. Si vous ne pouvez pas vous souvenir immédiatement de la référence, pensez à la transmettre plus tard par courrier électronique.

3) À éviter : Baser votre argumentation sur des informations non ou mal sourcées. Tenez-vous-en aux faits, et laissez les hypothèses de travail, les généralités et les suppositions pour les rares occasions où elles pourront être vraiment utiles.

4) À faire : Choisir avec soin vos arguments selon votre propre niveau de compréhension et celui de votre auditoire. Restez concentré sur les sujets que vous maîtrisez, ceux pour lesquels vous avez une expérience personnelle (même modeste) et dans lesquels vos auditeurs seront susceptibles de se reconnaître.

4) À éviter : Ennuyer ou irriter un auditoire inadapté et non préparé à un discours par trop technique ou philosophique. Vous êtes naturellement motivé pour parler en long et en large de vos sujets ou concepts favoris, mais rappelez-vous que si le but est de communiquer sur le logiciel libre, alors il vous faut déterminer au préalable l’interêt et le niveau technique de votre auditoire et adapter votre discours en conséquence.

5) À faire : Faire preuve de patience, de calme, de raison et d’objectivité dans votre communication. Évitez les situations de crises et sinon tentez de les désamorçer.

5) À éviter : Être pressant, aggressif ou trop impliqué personnellement dans vos propos. Vous n’avez rien à prouver et le logiciel libre continuera à vivre quel que soit l’avis d’un individu ou d’un groupe. Soyez simplement constructif dans vos propositions.

6) À faire : Rencontrer et discuter avec des personnes potentiellement intéressées par le logiciel libre. Sollicitez ces contacts et veillez à vous montrer disponible pour répondre à leurs demandes.

6) À éviter : Passer votre temps à contacter des personnes qui ont clairement manifesté leur désintérêt pour le sujet. Vous seriez plus utile en d’autres lieux.

7) À faire : Effectuer des démonstrations de logiciels libres de qualité, en particulier si vous les utilisez vous-même. Voir c’est retenir, et montrer comment vous tirez profit des logiciels libres au quotidien peut être plus percutant que n’importe quel argument idéologique.

7) À éviter : Promettre ou insinuer des choses que les logiciels libres ne peuvent pas apporter. Vous pouvez faire énormément de choses avec des logiciels libres, mais vous ne pouvez pas tout faire, et prétendre le contraire ne ferait que nourrir des attentes et mènerait à la frustation et la déception.

8) À faire : Trouver des moyens d’inviter les nouveaux venus à rencontrer d’autres partisans du logiciel libre et à assister à des évènements organisés par des groupes d’utilisateurs locaux. Essayez de réunir des personnes ayant des centres d’intérêts communs est également un terreau favorable pour les nouveaux arrivants dans le monde du logiciel libre.

8) À éviter : Espérer que chaque personne croisée souhaite adhérer et participer à vos groupes d’utilisateurs de logiciels libres (LUG) ou à votre hackerspace. La plupart des gens ne se déplacent à une manifestation, une rencontre, que si cela correspond à leurs centres d’intérêts et leur niveau de compréhension. Seuls certains de vos contacts sont prêts à accorder une partie de leur temps libre à ce genre d’évènement . Lorsque c’est le cas, n’oubliez pas de rester accueillant et patient.