Parce qu’il est important que la belle histoire de Mozilla se poursuive, soutenons la Fondation !
—> La vidéo au format webm
—> Le fichier de sous-titres
PS : Si vous avez un lien vers un format plus ouvert de la vidéo, je suis preneur, ainsi que le crédit aux traducteurs.
PS2 : On peut encore grandement améliorer la traduction selon moi, c’est par là…
Amazon a publié récemment le code source du système d’exploitation de sa nouvelle tablette liseuse Kindle Fire basée sur Android.
D’aucuns ont salué cette libération et souhaité la bienvenue à Amazon dans le club de l’open source.
D’autres, comme ici la Free Software Foundation de Stallman (ou Numerama), ne sont pas dupes et demandent légitimement d’aller beaucoup plus loin.
Il y a un monde entre respecter les licences et contribuer effectivement à la communauté[1].
Amazon’s Kindle source code: Much ado about nothing
Brett Smith – 30 novembre 2011 – FSF.org
(Traduction Framalang : Don Rico et Goofy)
Il y a eu cette semaine beaucoup de battage concernant la mise à disposition par Amazon du code source du logiciel de ses Kindle, incluant le Kindle Fire. Cette médiatisation à outrance est en grande partie injustifiée. Certes, on peut télécharger le code source qu’Amazon a été dans l’obligation légale de publier, mais la plupart des logiciels sur ces appareils restent privateurs, et chaque Kindle est encore « Defective by Design » (NdT: Défectueux par conception).
La principale source de confusion serait que le système d’exploitation du Kindle Fire est basé sur Android. Google distribue le code source d’Android sous licence Apache, une licence de logiciel libre qui n’est pas copyleft. En général, les appareils tournant sous Android comprennent aussi quelques logiciels non-libres, mais le code source suffit à créer un système d’exploitation libre et riche en fonctionnalités. Le projet Replicant en est la preuve : il vise à créer des systèmes entièrement libres pour divers appareils Android.
Lorsque Amazon a publié le code source de son Kindle Fire, certains journalistes semblent avoir présumé que l’étendue de cette publication serait similaire à celles de Google. Il n’en est rien – Amazon a seulement publié le code source des programmes placés sous licence GPL (GNU General Public Licence) et LGPL (Lesser General Public License). Ces licences exigent toutes deux d’Amazon qu’elle mette à disposition ce code source, afin qu’elle puisse distribuer les logiciels du Kindle Fire couverts par ces mêmes licences. Amazon s’est contenté de respecter ces obligations légales précises, sans aller plus loin. Aucune ligne du code source publié par Amazon n’est propre à Android, et n’inclut en aucun cas la moindre modification apportée par Amazon à l’interface utilisateur d’Android.
En outre, publier cette quantité minimale de code source ne résout en rien la question des Gestions de Droits Numériques (Digital Restrictions Management / DRM) d’Amazon. Les logiciels privateurs présents sur le Kindle empêchent toujours les utilisateurs de copier et de prêter les livres et les différents médias qu’ils ont pourtant achetés. Il est néanmoins possible que ce code source facilite la tâche de hackers (NdT : bidouilleurs) entreprenants qui souhaiteraient installer de nouveaux logiciels sur ces appareils en se débarrassant des DRM, mais personne ne devrait avoir à fournir des efforts herculéens dans le seul but de jouir des droits que leur aurait conféré un livre imprimé. Le meilleur moyen d’échapper à ces restrictions draconiennes des DRM est de refuser d’acheter un Kindle. Toutes nos critiques passées à l’encontre du Kindle et de son caractère « Défectueux par conception » restent d’actualité.
Si Amazon tient vraiment à faire un coup médiatique, elle devrait abandonner ses DRM et faire en sorte que tous les logiciels présents sur le Kindle soient des logiciels libres. Cela permettrait aux possesseurs de Kindle d’utiliser leur appareil et leurs médias comme bon leur semble. Voilà qui représenterait un véritable changement pour cette entreprise. La publication de code source dont elle s’est fendue n’a rien d’une telle révolution : Amazon ne fait que se conformer à une obligation légale (ce qu’elle fait depuis la première version du Kindle), et cela ne mérite même pas un entrefilet.
[1] Crédit photo : goXunuReviews (Creative Commons By)
Voici un billet un brin polémique qui affirme que le logiciel libre (et non l’open source) perd actuellement de son influence et que la Free Software Foundation de Richard Stallman en porte une lourde responsabilité.
Il est signé du chroniqueur Bruce Byfield que nous avons souvent traduit par le passé et qu’on ne peut soupçonner de troller pour troller. Il s’agit au contraire d’un réel et sincère amour déçu[1].
D’accord, pas d’accord ? Trop américano-centré ? En France, en Europe, il en va différemment ? Le logiciel libre se résume-t-il à la FSF ? etc. Il va sans dire que nous vous attendons dans les commentaires sinon c’est pas drôle 🙂
7 Reasons Why Free Software Is Losing Influence
Bruce Byfield – 22 Novembre 2011 – Datamation
(Traduction Framalang : Goofy)
Pourquoi les idéaux du logiciel libre sont-ils moins populaires qu’il y a cinq ans ? La réponse n’est pas évidente et un peu polémique.
Il y a cinq ans, quand la majeure partie du code Java a été publiée sous licence GPL (General Public License), Sun Microsystems a pris soin d’associer la FSF (Free Software Foundation) à l’annonce, d’obtenir une déclaration d’approbation de Richard Stallman, le président de la FSF, et d’Eben Moglen son conseiller juridique.
Aujourd’hui, on voit mal quelle entreprise serait susceptible de faire le même effort. Lentement mais sûrement, le logiciel libre a perdu l’influence qu’il exerçait au sein de la communauté qu’il a créée.
Pratiquement il est difficile d’employer l’expression FOSS (Free and Open Source Software) en espérant être compris. Dans la plupart des cas, l’expression « logiciel libre », que l’on n’entend pratiquement plus, a été remplacée par « open source ».
Que s’est-il donc passé ?
Je ne dispose pas de chiffres précis à l’appui mais je suggère ici au moins sept raisons possibles. Certaines externes à la FSF, d’autres résultant directement de ses prises de décision. Choix qui ont pu paraître sensés à une époque mais ont eu parfois des effets pervers à long terme, quand ils n’ont pas été effectués trop hâtivement…
La FSF fonctionne avec une équipe dirigeante de moins d’une douzaine de personnes, et avec des bénévoles. Ses revenus pour 2010 étaient de 1,23 million de dollars. Avec de telles ressources, elle soutient le projet GNU, aide des entreprises et des projets à se conformer aux licences libres, et lance une dizaine de campagnes, depuis la lutte contre les DRM et les initiatives anti-Windows jusqu’aux efforts pour convaincre le plus grand nombre d’utiliser des formats audio libres.
Tous ces efforts sont dignes d’intérêt en eux-mêmes, mais pour rarement mentionnés et relayés, ils ne trouvent que peu d’écho. Mais ce sont là des problèmes bien plus nombreux que ceux qu’a traités la FSF dans le passé, et elle le fait avec à peine quelques centaines de milliers de dollars de plus qu’en 2006, quand ses ressources lui permettent difficilement de mener à bien une seule de ces actions. Par conséquent la FSF finit par se révéler inefficace, et rares sont les campagnes qui captivent l’attention générale au sein de la communauté, plus rares encores celles qui atteignent leur objectif.
Ces cinq dernières années, la FSF s’est efforcée d’investir son activité sur les réseaux sociaux, pour atteindre un plus large public. Le mérite de ces efforts revient essentiellement aux actions du précédent directeur général Peter Brown, parce qu’il a une trajectoire personnelle d’activiste. C’est un pas en avant dont j’ai dit tout le bien que je pensais à l’époque, et je considère encore que c’est une bonne stratégie.
Malheureusement, cette tentative a largement échoué, certainement là encore victime de ressources trop limitées. Par ailleurs il s’agissait dans le mouvement d’établir une distinction entre la FSF et le plus technique projet GNU. J’ai entendu beaucoup de développeurs exprimer leur réticence quant aux positions activistes de la FSF en souhaitant qu’elle recentre ses activités sur le logiciel. Au final la FSF a aggravé son cas : échouant à gagner de nouveaux publics à sa cause, éloignant d’elle ses adeptes déjà existants.
Nombreux sont ceux qui ne s’en souviennent plus aujourd’hui, mais il y a cinq ans, la communauté Debian était une référence pour le logiciel libre. Elle n’était pas toujours d’accord avec la FSF, en fait, Debian était réputé pour suivre son propre chemin, imposer sa propre définition du logiciel libre, et se faire un avis autonome sur des questions comme celle de savoir si la licence GNU Free Documentation est vraiment une licence libre (oui, c’est Debian qui décidait après un long débat, dans certaines occasions). Et encore récemment quand la FSF a créé la version 3 de la GPL, elle a pris soin de consulter les représentants de Debian.
Toute aigreur mise à part, en tant que distribution basée sur la communauté la plus répandue, Debian a donné une crédibilité supplémentaire à la reconnaissance du logiciel libre. Tout du moins Debian a-t-elle aidé à donner l’impression d’une communauté suffisamment grande pour avoir des différences. Aujourd’hui, cependant, alors que Debian est une distribution plus influente que jamais, une bonne part de la notoriété dont elle jouissait a été captée par sa dérivée Ubuntu. Et ce n’est pas la faute d’Ubuntu qui, soutenue par une entreprise commerciale qui doit rechercher le profit, n’hésite pas à renoncer à certains principes du logiciel libre par commodité
Avec cet allié et partenaire de la FSF qui devient moins influent, c’est toute la cause du logiciel libre qui s’est affaiblie. À défaut de mieux, la controverse et les débats avec Debian ont aidé à garder présents à l’esprit de la communauté les problèmes de principes.
De nouvelles technologies aient été introduites ces cinq dernières années. Or la stratégie majeure de la FSF a été de les dénoncer, puis de les ignorer. Ces derniers temps, Stallman a ainsi vilipendé l’informatique dans les nuages, les e-books, les téléphones mobiles en général et Android en particulier.
Dans chaque cas, Stallman a souligné à juste titre les problèmes concernant la vie privée et les droits du consommateurs, ce que les autres ont souvent oublié de mentionner. Le problème c’est qu’en continuant d’ignorer ces nouvelles technologies on ne résout rien, et que le mouvement du logiciel libre devient moins pertinent dans la vie des gens. Beaucoup sont attirés par ces nouvelles technologies, et d’autres sont contraints de les utiliser pour échanger, travailler et communiquer avec la majorité.
La licence libre Affero GNU GPL de la FSF devait etre tout indiquée pour l’informatique dans le nuage. Pourtant, selon les statistiques de Black Duck, elle n’est dans le fait que trop rarement utilisée, seulement 401 logiciel sont sous cette licence alors qu’il existe des centaines de milliers de logiciels sous licence libre. En persistant à mettre l’accent sur l’ordinateur de bureau traditionnel, le logiciel libre se tient à distance des technologies actuelles pour lesquelles justement il serait le plus nécessaire.
En juin 2007, la FSF a publié la version 3 de la GPL. Cette mise à jour s’efforçait de prendre en compte les nouvelles technologies et les moyens de contourner les clauses de la version 2. Cette nouvelle version a été le résultat d’une concertation sans précédent entre la communauté et les entreprises parties prenantes.
Toutefois, cette consultation demandait d’atteindre un consensus. Lorsque Linus Torvalds a décidé que le noyau Linux resterait sous la GPLv2, la FSF est allée de l’avant vers la GPLv3 sans en tenir compte.
Sur le moment, la décision a paru sensée pour éviter une impasse. Mais on se retrouve actuellement avec une GPLv2 utilisée par 42,5% des logiciels libres contre moins de 6,5% pour la GPLv3 selon Black Duck.
Avant cette révision majeure, la licence GPL contribuait à unifier la communauté, et la FSF, en tant que créateur, promoteur et défenseur de la GPL, avait une forte présence en son sein. Or aujourd’hui, la GPLv2 est considérée comme la version que privilégient les supporters de l’open source, et la GPLv3 celle des défenseurs du logiciel libre. Et non seulement l’ensemble de la philosophie du logiciel libre en apparaît affaiblie, mais encore le fossé s’élargit entre logiciel libre et open source.
Plus encore, comme si la situation n’était pas déjà assez mauvaise, il semble qu’il y ait une tendance à adopter des licences permissives qui n’exigent pas le partage du code, comme le font toutes le versions de la GPL.
Richard Stallman et beaucoup d’autres membres de la FSF refusent de participer à des conférences qui n’utilisent pas l’expression exacte « GNU/Linux » en lieu et place du simple « Linux » dans leur intitulé et leur promotion. En fait Stallman est connu pour refuser de s’exprimer devant un groupe de journalistes qui n’utiliseraient pas la bonne nomenclature, c’est-à-dire la sienne (NdT : cf la librologie Les mots interdits de Richard Stallman).
La principale exception à ma connaissance est Eben Moglen, dont le travail à la Software Freedom Law Center implique beaucoup de gens qui se revendiquent comme des supporters de l’open source.
Je comprends que ce refus soit une question de principe. Cependant, en dépit de tous les moyens de communication qu’offre Internet, le contact et la communication directs demeurent importants pour la communauté. En maintenant coûte que coûte leurs idéaux, les défenseurs du logiciel libre se sont rendus invisibles, se coupant des réseaux sociaux et autres associations informelles qui émergent lorsque les gens se parlent dans la vraie vie.
En tant que fondateur et principal porte-parole de la FSF, Richard Stallman a joué un rôle décisif dans l’histoire du logiciel libre. Personne ne peut le contester et personne ne reviendra là-dessus
Mais l’entêtement de Stallman, qui a aidé la diffusion et l’essor des principes du logiciel libre, semble maintenant à beaucoup un handicap. Stallman affiche de façon continuelle son obsession des définitions qui détournent des principaux points pour lesquels la liberté logicielle est nécessaire. De plus, ces temps-ci, il semble ne vouloir jamais rater la moindre occasion de critiquer, pas toujours avec pertinence, la philosophie de l’open source,
Pire encore, Stallman a tout un passé de gaffeur, sans jamais admettre avoir eu tort. En juillet 2009, il a suscité la controverse en refusant de retirer une remarque sexiste qu’il avait faite au Desktop Summit à la Grande Canarie. Plus récemment, Stallman notait à propos de Steve Jobs « je ne suis pas content qu’il soit mort, mais je suis content qu’il soit parti », puis il a précisé son propos quelques semaines plus tard. Le problème ce n’est pas qu’il ait eu tort d’accuser Jobs de rendre populaires des technologies fermées, c’est que beaucoup de gens ont trouvé que ses déclarations étaient indélicates et inopportunes en parlant d’un homme qui venait de mourir, et qu’un responsable d’organisation aurait dû montrer plus de bon sens et ne pas faire de suite de telles remarques.
Stallman est loin de représenter à lui seul l’ensemble du logiciel libre, mais force est de constater que beaucoup de gens ont une mauvaise opinion de ce mouvement à cause de lui.
Aucune des raisons mentionnées ci-dessus ici n’est fatale en elle-même. Cependant, additionnées, elles forment une longue trame sur laquelle on peut expliquer pourquoi les idéaux de la FSF et des logiciels libres exercent moins d’influence qu’auparavant.
En tant que supporter du logiciel libre, je ne peux qu’espérer que ce manque d’influence pourra être renversé. Cinq ans c’est court, et je ne vois aucune raison qui pourrait empêcher le logiciel libre de récupérer le temps et le terrain perdus.
Le seul problème est de savoir si les membres influents du logiciel libre vont admettre les problèmes et les corriger… Je l’espère, mais je ne suis pas très optimiste quant à la réponse.
[1] Crédit photo : Steve Winton (Creative Commons By)
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 »
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 !
[1] Crédit photo : Chris McClanahan (Creative Commons By-Sa)
« 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 🙂
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.
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 :
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.
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.
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).
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.
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.
[1] CyanogenMod est un fork d’Android : des modifications sont apportées aux sources d’Android telles que mises à disposition par l’AOSP ainsi que le support pour tous les téléphones qui ne sont pas des « Google phones » (le code de l’AOSP ne couvre que les Google phones). Replicant est lui-même un fork de CyanogenMod et profite ainsi des améliorations apportées par ce projet.
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.
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.
[1] Crédit photo : SCA Svenska Cellulosa Aktiebolaget (Creative Commons By)
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.
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 au format webm
—> Le fichier de sous-titres
—> 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.
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.