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.

On ne compte plus les interventions publiques de Frédéric Couchet en tant que délégué général de l’April.

Mais il est plus rare (et plus émouvant) qu’il nous parle de lui en nous narrant son parcours personnel et ce qui l’anime, à savoir avant tout une belle et utile aventure humaine.

C’était en mai dernier lors du premier TEDx de Bordeaux.

—> La vidéo au format webm

Le Framablog poursuit son petit dossier sur l’impression 3D, histoire de faire comprendre à certains de quoi il s’agit et de donner à d’autres le goût d’entreprendre.

Après une courte vidéo explicative et un article de fond sur l’impact actuel et futur de la propriété intellectuelle sur l’impression 3D, voici une leçon pratique et concrète réalisée à partir du logiciel de modélisation 3D Blender.

Ce qui est intéressant ici, c’est d’abord le fait que Blender soit un logiciel libre mais c’est aussi le fait que vous n’avez pas besoin d’avoir une imprimante 3D à la maison, c’est le service en ligne Shapeways qui se charge de matérialiser l’objet à partir de votre fichier Blender et qui vous envoie le tout par la Poste.

Conclusion : on peut déjà s’y mettre !

PS : On nous signales dans les commentaires l’existence de la société Sculpteo qui propose en français un service similaire à Shapeways.

Créer des figurines imprimées 3D avec Blender et le service d’impression Shapeways

Creating 3D Printed Models with Blender and the Shapeways Printing Service

Terry Hancock – 26 mai 2011 – Free Software Magazine
(Traduction Framalang : Lolo le 13)

Un des sujets technologiques les plus intéressants de ces récentes années a été la montée en puissance de la technologie « d’impression 3D » pour le prototypage rapide de formes peines. J’avais déjà évoqué le sujet pour le Free Software Magazine, mais ce mois-ci j’ai finalement décidé de l’essayer pour mon propre compte, en créant matériellement des « figurines d’étude » (un joli synonyme de jouets) pour mon projet vidéo, Lunatics.

Dans cet article, je vais vous décrire le processus complet, depuis la création des modèles 3D jusqu’à la réception du produit fini dans ma boîte aux lettres.

La principale raison pour laquelle j’ai fait ce projet, c’est que je voulais tester les capacités du service d’impression 3D de Shapeways. Ils ont associé ce service d’impression avec une conception collaborative en ligne, ce qui crée un environnement fun et motivant pour créer et commander des figurines. C’est un service très facile à utiliser et la qualité d’impression semble être au rendez-vous. Ils proposent aussi une grande variété de matériaux d’impression comme la céramique cuite, des métaux et des plastiques.

Figure 1 : Conçu dans Blender, exporté et téléversé chez Shapeways, livré en tant que figurine plastique imprimée – C’est cool non ?

La deuxième raison est que je désirais avoir quelque chose d’un peu plus tangible pour élaborer mon projet Lunatics. J’aime travailler avec des ordinateurs, mais parfois vous voulez avoir quelque chose de tangible à tenir et à manipuler avec vos mains quand vous essayez de figer les scènes et planifier les scripts.

Il nous fallait constuire une maquette de la colonie lunaire dans laquelle se déroule la plupart des actions du film. D’ordinaire c’est une affaire de mousse avec des plans de sols imprimés, un peu comme un jeu de plateau. Et comme pour un jeu de plateau, nous allions donc avoir besoin de figurines représentant nos personnages. Nous aurions pu opter pour des pions de Cluedo ou utiliser ceux des échecs avec un code couleur ou encore des petits chevaux, mais ça aurait été bien plus sympa si nous avions des figurines qui ressemblent réellement à nos personnages.

À la même échelle (1/100e) que ces personnages, J’ai aussi voulu créer quelques véhicules spatiaux. J’ai décidé de commencer avec le Moon Truck, un rover lunaire pressurisé conçu pour transporter fret et passagers.

Comme j’ai eu quelques difficultés à imaginer concrètement ce véhicule, il m’a semblé utile d’essayer d’externaliser cette tâche à la fois comme une maquette 3D dans un ordinateur et comme une maquette physique à tenir et à regarder.

Figurine des personnages

J’ai commencé par créer les silhouettes de mes personnages dans un brouillon Inkscape. Elles sont basées sur des figurines d’architecture du domaine public que j’ai grandement modifiées. J’en ai fait des pions comme de simples découpes sur une base ronde (à la différence de soldats de plomb ou des pions Cluedo).

Puis, j’ai sélectionné chaque personnage depuis mon dessin original sous Inkscape et je les ai copiées dans des fichiers SVG séparés (Figure 2). Je les ai sauvegardés en tant que Plain SVG pour un maximum de compatibilité.

Figure 2 : J’ai d’abord copié le dessin des silhouettes en SVG dans des fichiers séparé et sauvegardé ceux-ci au format Plain SVG.

J’ai importé chaque SVG dans Blender en tant que curves (Figure 3). Il y avait huit personnages principaux (plus deux extras). Pour les mettre à la bonne taille (à l’échelle 1/100e, un mètre est réduit à un centimètre) j’ai décidé de prendre la convention qu’un Bender Unit (BU) serait égale à 1 cm. J’ai donc mis à l’échelle les courbes de cette façon.

Figure 3 : J’ai importé les objet SVG dans Blender en tant que curves.

Les courbes (curves) sont des objets spéciaux et limités dans Blender. Il vaut mieux utiliser le format mesh pour l’impression 3D. Donc, après avoir importé les courbes depuis le fichier original en SVG, j’ai du les convertir en meshes (soit ALT+C au clavier, soit Changer le type d’objet… depuis le menu Objet).

Mais après la conversion, je n’avais que le squelette, c’est-à-dire les sommets et les arêtes qui les reliaient. Pour créer une face (surface) représentant la silhouette, j’ai utilisé la fonction Beauty Fill (avec le raccourci clavier Alt+F ou en sélectionnant Mesh > Faces > Beauty Fill dans le menu Option du Mode d’édition accessible via la touche Tab). En fait, ça ne crée pas une seule surface, mais plusieurs, l’espace est alors rempli automatiquement par des triangles.

J’ai ensuite passé quelques temps à simplifier la forme. La chose la plus importante est de s’assurer que les petites surfaces sont coplanaires (appartiennent à un même plan).

Figure 4 : Extrusion de la silhouette.

Ensuite, il m’a fallu donner de l’épaisseur à la découpe. J’ai décidé de les faire d’un millimètre de large, ce qui correspond ici à un dixième de Blender Unit. Pour ce faire, j’ai sélectionné le mesh, puis j’ai basculé sur la vue le long de l’axe X (en tapant 3 sur le pavé numérique). Puis j’ai tapé sur Tab pour passer en Mode édition et j’ai sélectionné tous les sommets (tapez A pour basculer la sélection sur tous les sommets). Enfin, tapez la séquence E (extrude), Y (direction) et 0.1 : cela créera l’extrusion de la silhouette dans la dimension Y (Figure 4).

Figure 5 : La représentation du personnage d’Anya montre comment la silhouette extrudée chevauche la base cylindrique.

J’ai répété l’opération pour mes dix figurines : création d’une base mesh et extrusion en cylindre mesh, en faisant se chevaucher les figurines extrudées et la base (voir Figure 5).

Il n’est pas nécessaire de fusionner les objets dans Blender, ce qui me sauve d’une trop grande complexité, mais qui donnera une légère surcharge de travail à Shapeways (en effet le calcul actuel est basé sur une analyse des meshes et ils ne compte pas les chevauchements, ainsi, vous serez facturés en double pour les volumes chevauchés).

Figure 6 : Toutes mes dix figurines dans Blender.

Téléverser le modèle

J’ai fait cela plus d’une fois : au départ téléverser juste un des personnages puis essayer différentes combinaisons. Heureusement Shapeways ne fait pas attention si une forme consiste en une simple pièce ou en une douzaine, mais ils facturent un supplément par forme pour la plupart de leurs matériaux. Ça veut dire qu’il est généralement moins cher d’imprimer une petite collection d’objets en tant que forme simple (si vous le pouvez) en particulier dans le cas où, comme moi ici, elles sont de petite taille.

Figure 7 : Exportation d’une forme Blender en format STL pour l’impression 3D chez Shapewys.

Quand vous avez fini votre conception, l’étape suivante est de les exporter dans un format que Shapeways va comprendre. Celui que j’ai trouvé le plus simple à utiliser est le format STL (Figure 7). Ce format est commandé par le menu d’export standard dans Blender (File > Export > STL).

Pour impimer la forme en utilisant Shapeways, j’ai commencé par aller sur le site pour m’identifier. J’ai ensuite cliqué sur le bouton “upload” tout en haut qui m’a renvoyé vers un formulaire d’envoi de ma forme (Figure 8). Le formulaire permet aussi de créer des formes pour votre propre utilisation ou pour le rendre public. En fait, comme avec d’autres service de fabrication communautaire, si vous mettez vos formes à la vente, vous toucherez une commission. N’étant pas tout à fait prêt pour rendre ces fomes libres, j’ai donc juste cliqué sur la boite privée.

Figure 8 : Téléversement de la figurine Anya chez Shapeways.

Il est possible que vous ayez besoin de modifier ce qui a été téléversé si vous voulez que l’image apparaisse correctement, J’ai suivi quelques mauvais conseils et j’ai orienté l’axe Y en tant que “up” (haut) à la place de l’axe Z, ce qui a eu pour résultat la malheureuse Figure 9. Ça aurait été bien imprimé, mais ça donne un rendu de prévisualisation affreux.

Figure 9 : Ooops ! L’axe Z devrait être en haut si vous voulez une prévisualisation correcte (là j’ai mis Y).

Une fois que vous avez bien téléversé votre forme, vous pouvez commander une impresion 3D avec comme matériau une variété de plastiques, des pierres recomposées, quelques différents types de métal et différents finis de verre (Figure 10).

De façon pratique, l’interface calcule automatiquement le volume et le prix de chaque matériau pour que vous puissiez comparer. Le coût de pour mon lot de 10 figurines va de $3.20 avec de la pierre recomposée jusqu’à $64.40 pour de l’argent (j’ai fait mes figurines en plastique “Indigo strong and flexible” vu que j’avais utilisé de l’indigo pour les travaux artistiques des Lunatics). Le coût a été facturé en fonction des volumes calculés des formes (pas le bounding box, la vraie forme), plus un coût de base par forme.

Figure 10 : Matériaux disponibles et prix pour mon lot de figurines.

Camion lunaire

Après le téléversement de figurines et ma tentative de les commander, j’ai découvert une autre particularité du service Shapeways : Il y a un minimum de commande de 25 dollars. Donc si je ne voulais pas gâcher mon argent, il me fallait commander autre chose. J’ai donc décidé de créer une autre forme au 1/100e, cette fois un des véhicules créés pour mon projet Lunatics (Figure 11). Je ne vais pas vous faire le détail de la création, mais c’est bien entendu une conception plus complexe.

Figure 11 : La conception du camion lunaire dans Blender (je n’ai pas imprimé le module passager sur la droite).

J’ai fait un camion en plusieurs parties qui seront assemblables après coup. C’était en partie pour permettre un assemblage modulaire avec des pièces d’autres modèles (les boogies à quatre roues sont supposés être enlevables sur le camion réel par exemple). Pour d’autres il a été plus facile de faire des formes creuses avec des paroies fines qui ne coûteraient pas tant que ça à imprimer. Le couvercle amovible sur le module l’est aussi pour pouvoir accéder à l’intérieur, bien qu’il n’y ait pas vraiment de détails à l’intérieur (mais je pourrai en ajouter dans une prochaine version).

Vous pouvez commander les pièces en utilisant un simple système de vérification, comme n’importe quel site d’e-commerce. En tant que produits fabriqués à la demande, il y a des délais de fabrication en plus des délais de livraison à inclure dans le bon de commande (Figure 12).

Figure 12 : Shapeway s’engage sur un délai de fabrication de 10 jours dans la vue du panier d’achat.

Livraison

Bon, cet article ne serait pas complet sans les photos des produits tels que je les ai reçus ! Ils arrivent dans de jolis petits emballages, un par forme, comme vous pouvez le voir sur la Figure 13.

Figure 13 : Mes objets, tels qu’ils me sont arrivés depuis Shapeways.

J’étais content de voir qu’il n’y a pas eu de figurines cassées (séparées de leur socle). Le camion est arrivé en pièces comme prévu (Figure 14).

Figure 14 : Le camion a été imprimé en cinq parties (châssis principal et cabine, deux boogies à quatre roues, un conteneur et le toît de la cabine).

L’assemblage du camion a marché dès le premier essai. Les roues sont plus glissées qu’emboitées, mais elles restent en place comme il faut. La prise du sas était passablement dure à ajuster et il a fallu un peu forcer mais le plastique a résisté (Figure 15).

Figure 15 : Assemblage des composants du camion lunaire.

Il est intéressant d’examiner la texture de près. Il est possible de voir les faces du modèle original sous Blender (les formes cylindriques sont en fait des polygones à très grand nombre de côtés, comme dans le haut du boogie à quatre roues de la Figure 16)

Figure 16 : Zoom sur un des boogies, notez les lignes dûes à la méthode d’impression.

Et voila !

Il faut vous avouer que j’avais espéré que les roues tournent. J’ai essayé de concevoir un modèle articulé comme un challenge, mais apparemment je n’ai pas dû laisser suffisamment de jeu pour ça et elles sont donc coincées comme si elles étaient imprimées en bloc. C’est un des nombreux problèmes de conception que j’étudierai avant de tenter d’imprimer ces figurines à nouveau.

La Figure 17 montre les figurines assemblées avec un sous et un DVD pour donner une idée de l’échelle. Je suis ravi d’avoir pu tester cette technologie sur quelle j’écrirai certainement à nouveau et j’espère avoir fait quelques émules parmi les courageux lecteurs.

Figure 17 : Mes pièces complètes avec un penny et un DVD pour l’échelle.

Mais je vais arrêter d’écrire. J’ai trop envie de jouer là avec ma voiture lunaire 🙂

Ne point nous haïr mais au contraire se rassembler pour ensuite envisager en confiance de construire ensemble.

Tel est le court et optimiste message de ce membre grec de la FSF Europe^[1].

Vous y verrez peut-être un excès d’idéalisme voire de la naïveté. Possible… mais il n’est pas anodin que constater que le logiciel libre est capable de susciter de tels espoirs, dans un monde qui en a bien besoin.

PS : Il semblerait qu’il y ait un mouvement de contestation intéressant qui prend forme en ce moment même en Espagne. Vous avez plus d’informations ?

Logiciel Libre : Une bougie dans la pénombre

Free Software & Digital Rights Noopshere

Kostas Boukouvalas – 19 mai 2011 – FSFE Blog
(Traduction Framalang : Pandark)

C’est certain, nous vivons des temps troublés, et la crise financière n’est point la dernière à blâmer. C’est une situation fort tendue que connaît mon pays actuellement, où colère et discorde se répandent parmi le peuple.

La communauté du logiciel libre fait partie intégrante de la société. C’est pourquoi elle est également affectée par ces phénomènes.

Or bien des gens ne réalisent pas une chose. Les logiciels libres, de leur origine jusqu’à nos jours, ne sont pas seulement une alternative aux logiciels infectés de virus ou des logiciels donnés gratis. C’est une autre art de vivre. Un autre façon de voir les choses. Un autre modèle de développement, qui peut participer à aider à combattre le fléau de la crise. Une crise dont le cœur est avant tout culturel et éthique ; une crise des valeurs, et accessoirement, une crise financière.

Que peut-on apprendre des logiciels libres ?

Premièrement, à ne point haïr son prochain. Cela ne va pas de soi aujourd’hui. C’est pourquoi je n’irais pas jusqu’à dire « Aimez-vous les uns les autres ».

Deuxièmement, à se rassembler. Non pas dans l’angoisse et l’adversité, mais tranquillement, sereinement, un pas après l’autre.

Troisièmement, à travailler volontiers ensemble, de concert.

Et même si des erreurs ou des incompréhensions surviennent, nous aurons la patience de nous asseoir et de discuter en évitant les critiques inappropriées.

Après tout, nous ne sommes pas si nombreux, et le logiciel libre est une bougie dans la pénombre.

Faisons en sorte qu’elle brille !

Pour un débutant participer au logiciel libre peut être si intimidant qu’on n’hésite pas à évoquer « un aquarium à requins » pour qualifier la communauté !

Un blogueur explique pourquoi il ne contribue pas au logiciel libre (alors qu’au fond de lui il le souhaite sincèrement). Un autre lui répond, en théorie mais aussi en pratique en s’appuyant sur GitHub (qui a le vent en poupe actuellement chez les développeurs). Telle est la petite passe d’armes que nous vous proposons traduite ci-dessous^[1].

En ce qui nous concerne, c’est aussi pour cela que l’on a publié notre framabook Produire du logiciel libre. Afin de participer à ce qu’il y ait de plus en plus de développeurs francophones, notamment parmi les plus jeunes qui ne reçoivent pour le moment aucune sensibilisation ou formation pendant leur cursus scolaire.

Pourquoi je ne contribue toujours pas à l’open source

Why I still don’t contribute to open source

The Daily Flux – 3 mai 2011 – Brandonhays.com
(Traduction Framalang : Pandark)

Je suis tellement hypocrite. Il y a quelques mois, je me demandais dans un billet comment surmonter ma peur de contribuer aux logiciels open source ?¹?.

Depuis, je n’ai toujours pas vraiment participé. Sur Twitter, j’ai écrit que les FOSS ressemblent à un aquarium de requins pour les newbies, et il faut que je le confirme.

Le fait est que je contribue activement d’une manière ou d’une autre à plusieurs projets open source. Cependant, je me sens toujours extérieur au projet, car mes contributions ne sont généralement pas liées au code. Alors pourquoi est-que je ne m’implique pas complètement dans le FOSS (et je pense, beaucoup d’autres comme moi) ?

Au risque de prêter aux autres mon ressenti personnel, j’aimerais vous faire part des obstacles qui peuvent, selon moi, intimider les nouveaux devs qui voudraient contribuer à des logiciels open source.

Il n’y a pas de certification, de cérémonie ou de badge du mérite disant « Tu es prêt à contribuer au FOSS ». (Il y en a cependant un pour après)

Il n’est pas évident de savoir par où commencer. D’après ce que j’entends, beaucoup de contributions aux FOSS surviennent parce que quelqu’un a besoin d’une fonctionnalité qui n’existe pas dans un logiciel, ou trouve un bug. Il peut proposer une procédure de test reproductible, voire un patch. Dans mon utilisation quotidienne, je ne croise pas beaucoup de ces situations. Il n’y a pas beaucoup de devs qui agitent les bras en demandant spécifiquement de l’aide sur un projet, et encore moins qui voudraient prendre un nouveau développeur sous leur aile.

Les règles de participation (guidelines) rendent souvent la vie d’un mainteneur plus facile, et compliquent la mienne. Oui, maintenir un projet open source est une tâche ardue et ingrate. Cependant, j’ai vu des règles/lignes de conduite pour contribuer qui transformaient une simple idée de correction en un mur de brique bureaucratique digne de Microsoft. La page d’accueil aux contributions accompagnée d’un tutoriel vidéo de Wayne Seguin est une exception remarquable à cela.

L’open source est pour les gens qui sont meilleurs que moi. J’ai bien conscience que c’est une excuse pour ne pas me lancer, mais je ne suis simplement pas à l’aise de me retrouver à un endroit où je pourrais publier des logiciels suffisamment bons pour que de véritables développeurs les utilisent.

Essayer de contribuer et échouer me donne le sentiment d’être stupide. J’ai déjà soumis plusieurs requêtes de pull et aucune n’a été acceptée, sans commentaire expliquant pourquoi. C’est comme si l’univers confirmait que oui, je suis un idiot, et mon « aide » n’est pas utile. Quelle perte de temps profondément déprimante !

J’ai pas le temps. J’ai des enfants, un nouveau boulot, et un nombre grandissant de responsabilités. Cela me prend entre 3 et 10 fois plus de temps pour écrire du code qu’un développeur plus expérimenté. Maintenant, mes contributions non liées au code mangent le temps que je passais à coder. Oui, tout le monde a la même excuse, du genre qui se dissipe si les autres excuses disparaissent, mais ça vaut le coup de le mentionner.

C’est une activité solitaire. Je pense que la plupart des gens comprennent ces choses par eux-même, et que ce serait donc un peu trop demander que d’attendre d’être pris par la main. Mais est-ce vraiment une démarche spirituelle où personne ne peut vous accompagner, de crainte que vous n’appreniez rien ?

Donc oui, le FOSS peut sembler intimidant, voire autant qu’un aquarium de requins. Je n’ai pas toutes les réponses à ces problèmes, mais je voudrais voir plus de mainteneurs cherchant des contributions avec une certaine spécificité, et répondant ensuite aux requêtes de pull, un appel pour des cas de tests supplémentaires, des corrections de bugs et, oui, de la documentation.

Github a beau être on ne peut plus ouvert, il n’y a pas de système type Quora/StackExchange qui permette de savoir quel projets ont besoin de quelque chose qui correspond à ce que vous pouvez faire. Ça pourrait être une bonne fonctionnalité.

Toi (oui, toi !), tu devrais contribuer à l’open source

You (yes, you!) should contribute to open source

Steve Klabnik – 10 mai 2011 – TheChangelog.com
(Traduction Framalang : Pandark)

Si vous lisez ce blog, vous vous souciez évidemment de l’open source. Si vous n’avez jamais contribué à un projet open source, cependant, vous êtes peut-être frileux à ce propos. Donc, inspiré par le concours de documentation Ruby 1.9.3, j’ai écrit un billet pour mon blog à propos de la manière de contribuer à la documentation de Ruby. J’ai reçu des retours comme celui-ci :

@steveklabnik Hé, c’est génial. Il est temps pour moi de m’engager et de me mettre au boulot. Merci pour la motivation supplémentaire !

Je me suis donc dit que quelque chose de plus général pourrait vous encourager à vous impliquer dans n’importe lequel des projets open source que vous utilisez, même si ce n’est pas en Ruby. Tout projet peut avoir besoin d’un coup de main supplémentaire, en particulier les petits.

Un petit aparté à propos du fait d’être frileux.

Si vous ne contribuez pas parce que vous pensez que vous n’êtes pas prêt, ne vous inquiétez pas pour ça ! Je sais que c’est plus facile à dire qu’à faire, mais vraiment, vous êtes prêt. Un de mes amis a publié un article à propos des raisons pour lesquelles il ne contribue pas, et je suis sûr que beaucoup de personnes partagent ce genre de peurs. Greg Brown a répondu et a dissipé certaines de ses inquiétudes, mais la plupart des gens auxquels j’ai parlé s’y refusent principalement pour deux raisons :

• C’est trop dur
• Je ne suis pas assez bon pour contribuer
• Je n’ai pas le temps

Parlons de chacun de ces points dans l’ordre inverse. C’est vrai, vous pouvez avoir une vie remplie. Je ne connais pas votre emploi du temps personnel. Cependant, je suis sûr que vous pouvez trouver une heure ou deux, peut-être un week-end ? Il n’en faut pas plus pour commencer. La plupart des projets sont construits sur la base de milliers de minuscules commits. Vous n’avez pas besoin de faire une grosse contribution, même les petites sont importantes.

Si vous avez peur que la qualité de votre code ne soit pas suffisante, eh bien la seule manière de vous améliorer est de pratiquer. Alors lancez-moi cet éditeur et soumettez un patch ! En général, si quelque chose ne va pas dans votre soumission, il y aura une discussion à son propos sur GitHub et tout le monde peut y apprendre quelque chose.

Prenez cette demande de pull, par exemple. À l’origine, Colin a soumis un patch qui faisait un lien vers la mauvaise url ; wilkie l’a mentionné, et Colin a mis le code à jour. Cela sera intégré dès que j’aurai fini d’écrire ce billet pour The Changelog. 🙂 Mais c’est généralement ce qui arrive si votre première proposition est un peu inexacte. N’ayez pas peur ! C’est comme ça que l’on a tous appris, les uns des autres.

Cette lamentation « c’est trop dur » débouche souvent sur un « je ne suis pas assez bon ». Cela peut aussi arriver si vous essayez de contribuer à un gros projet ayant beaucoup de règles. Les lignes de conduite pour contribuer, obligation de relecture du code, mise à jour des fichiers AUTHORS et CHANGELOG… les gros projets doivent avoir des procédures pour gérer le grand nombre de contributeurs, mais cela peut certainement créer une barrière à l’entrée pour les nouveaux venus. Si ces procédures vous intimident, j’ai une suggestion : commencez petit ! Les petits projets ont généralement peu, voire pas du tout de procédure. De plus, vous vous sentirez incroyablement bien. Pensez à ça : Python reçoit un tas de patchs tous les jours, mais si vous avez un petit outil que vous avez écrit sur GitHub, et que soudainement vous recevez un courriel « Hé, quelqu’un a un patch pour vous, » je parie que vous en serez rudement content.

Le B.A BA

Lorsque l’on contribue à un projet open source sur GitHub, il y a un processus que presque tous les projets suivent. Trois étapes : fork, commit, demande de pull.

GitHub rend l’étape du fork très simple. Cliquez simplement sur le bouton « fork » trouvé sur la page de n’importe quel projet. Utilisons Ruby comme exemple. La page du projet est ici. Vous pouvez voir le bouton fork en haut à droite. Il ressemble à ceci :

Cliquez dessus, et vous verrez certaines « hardcore forking action, » puis vous serez dans votre propre fork ! C’est votre propre version du projet, et elle apparait sur votre page GitHub. Par exemple, voici mon fork de Ruby. Vous verrez une URL sur la page, qui vous permettra de cloner ce projet lui-même.

$ git clone git@github.com:steveklabnik/ruby.git

Cela crée un répertoire « ruby » avec tout le code à l’intérieur. Ensuite, ajouter un lien vers le projet parent pour pouvoir suivre les modifications qu’il fait.

$ cd ruby
$ git remote add upstream https://github.com/ruby/ruby.git
$ git fetch upstream

À partir de maintenant, à n’importe quel moment, nous pouvons récupérer les modifications du dépôt Ruby principal en faisant un rebase :

$ git rebase upstream/master

Une petite remarque : ruby continue d’utiliser à la fois svn subversion et git, ils appellent donc leur branche maîtresse trunk. Si vous faites cela pour Ruby, vous devrez faire git rebase upstream/trunk. Maintenant que vous avez cloné, vous pouvez faire votre boulot ! J’aime travailler dans des branches par fonctionnalités, parce que cela rend les choses plus propres et jolies, et que je peux travailler sur deux fonctionnalités à la fois.

$ git checkout -b feature/super-cool-feature
$ vim something
$ git add something
$ git commit -m "Fixed something in something"

Une fois que vous avez obtenu des commits qui fixent votre problème, envoyez les (faites un push) sur GitHub :

$ git push origin feature/super-cool-feature

Ensuite, vous cliquez sur le bouton pull request :

Choisissez votre branche, modifiez la description comme vous le souhaitez, et vous êtes prêt à vous lancer ! Le mainteneur du projet y jettera un coup d’œil et vous aurez peut-être droit à une discussion, et bientôt vous aurez quelque chose accepté quelque part !

À quoi devrais-je contribuer ?

Le meilleur moyen de contribuer est d’aider un projet que vous utilisez effectivement. De cette manière, vous arriverez à tirer profit du fruit de votre labeur. Vous serez plus motivé, vous comprendrez déjà le projet et ce qu’il fait, ce qui vous rendra tout ça plus facile.

Si vous ne voulez pas ou ne pouvez pas trouver comment fonctionne quelque chose que vous utilisez, le deuxième meilleur moyen est de commencer à utiliser de nouveaux logiciels ! Continuez à lire The Changelog et choisissez un projet qui a l’air intéressant, utilisez le quelques semaines, puis contribuez !

Nous sommes tous dans le même bateau

J’espère que ceci vous encouragera à vous salir les mains, vous retrousser les manches, et contribuer. Même le plus petit des patchs est important, alors s’il vous plaît, trouvez un moment dans votre emploi du temps, choisissez un projet et faites un essai. Mais attention, vous pourriez vite vous retrouver accro !

À l’occasion de la sortie du framabook Produire du logiciel libre (dont notre secret espoir est qu’il suscite des vocations chez les jeunes et les moins jeunes), nous avons posé quelques questions à son auteur Karl Fogel.

Est-ce que la situation a évolué depuis la première version du livre, en particulier avec les nouvelles forges comme GitHub (qui repose entre autres la question du fork) ? Est-ce un problème d’héberger des logiciels libres sur des plateformes propriétaires ? Est-ce que l’informatique devrait être enseignée en tant que telle aujourd’hui à l’école ?

Autant de questions auxquelles il apporte de très intéressantes réponses.

Entretien avec Karl Fogel

L’interview en version originale anglaise sur le blog de Karl (intéressants commentaires inside)

(Traduction Framalang : Don Rico pour les questions et Olivier Rosseler pour les réponses)

La version française de POSS vient tout juste d’être publié et votre livre a été traduit, ou est en cours de traduction, dans d’autres langues. Que pensez-vous de ces adaptations de votre œuvre, rendues possibles par le choix de le placer sous licence libre ?

Je suis absolument ravi. Je n’y vois vraiment aucun inconvénient. Les traductions permettent une diffusion plus large du livre, et c’est exactement ce que je souhaite.

Je suis extrêmement reconnaissant envers les traducteurs.

Si vous deviez écrire une deuxième version de POSS aujourd’hui, qu’est-ce que vous changeriez ou ajouteriez ? Et d’ailleurs, est-ce qu’une deuxième version est prévue ?

Et bien, en fait, j’y apporte toujours des petites modifications, à mesure que les pratiques de l’open source évoluent. La version en ligne change constamment. On pourra peut-être la nommer officiellement « Version 2.0 » à un moment donné, mais au fond, c’est vraiment un processus continu.

Par exemple, il y a cinq ou six ans, presque tous les projets avaient leur propre infrastructure de développement. Chacun avait son serveur, son système de contrôle de versions, son système de suivi de bogues, un responsable de la liste de diffusion, un wiki peut-être, c’étaient les outils de développement.

Mais depuis, on a assisté à des regroupements. De nos jours, seuls les très gros et les très petits projets possèdent leur propre infrastructure. La majorité des projets choisissent des sites pré-conçus, comme GitHub, Google Code Hosting, SourceForce, Launchpad, etc. La plupart des développeurs open source se sont familiarisés avec ces environnements.

Et par conséquent, j’ai mis à jour la partie du livre traitant des infrastructures d’hébergement, pour enrichir la section « Les sites Web » et parler des sites comme ceux mentionnés ci-dessus, plutôt que de ré-inventer la roue à chaque projet. Les gens se rendent bien compte qu’administrer son propre hébergement requiert énormément de ressources, malgré les avantages que l’on peut en tirer, et que donc, externaliser cette tache est devenu presque une obligation si on veut avoir un peu de temps pour effectivement travailler sur le projet.

J’ai également mis le livre a jour pour parler des nouvelles versions des licences open source (comme la GNU General Public License 3, qui est sortie après que le livre ait été publié), et j’ai également revu mes recommandations vis à vis de certains logiciels, car les temps changent. Par exemple, Git est de bien meilleure qualité aujourd’hui qu’à l’époque où j’ai rédigé la toute première édition.

La manière de produire des logiciels libres n’a pas tellement changée en cinq ans. Mais de nouvelles forges sont apparues, sur un modèle un peu différent de SourceForge. Je pense à Google Code mais surtout à GitHub. GitHub serait un peu le « Facebook des forges open source », avec ses fonctions de réseau social, son édition à même le navigateur… Son slogan est « Fork me on GitHub ». La notion de fork semble ne plus être tout à fait la même qu’avant. Que pensez-vous de tout cela ?

En fait, je pense que la notion de fork n’a pas changé. La terminologie, peut-être, mais pas le concept.

Si je me penche sur les dynamiques des rouages des projets open source, je ne vois pas de differences fondamentales selon que le projet utilise une forge ou l’autre. GitHub propose un produit fantastique, mais ils ont aussi un marketing fantastique. Ils encouragent les projets à inviter leurs utilisateurs à « créer une fork sur GitHub », c’est à dire « créer une copie pour jouer un peu avec ».

Et même si en un sens la copie d’un projet hébergé sur Git peut techniquement s’appeler un « fork », en pratique ça n’en est pas un. Le concept de fork est avant tout politique, pas technique.

À l’origine, initier un fork signifiait élever la voix pour dire : « nous pensons que le projet ne prend pas la bonne direction, nous avons pris la décision d’en faire une copie pour le poursuivre dans la bonne direction, que tout ceux qui partagent ce point de vue se joignent à nous ». Et les deux projets se retrouvaient alors publiquement en concurrence, à l’attention des développeurs et des utilisateurs, parfois aussi pour des questions d’argent. Parfois l’un des deux l’emporte, parfois ils fusionnent pour ne former à nouveau qu’un seul projet. Mais quelle qu’en soit l’issue, c’est avant tout un processus politique : susciter des adhésions pour continuer ensemble le projet.

Cette dynamique est toujours d’actualité, elle se poursuit tous les jours. Qu’on parle de « fork » pour designer quelque chose de différent, pourquoi pas, mais ça ne change pas la réalité, on utilise juste un terme différent pour décrire la réalité.

GitHub a commencé à parler de « fork » pour dire « créer une copie à bidouiller ». Maintenant, c’est vrai qu’avec ce genre de copie il est facile de s’éloigner du projet originel pour re-fusionner plus tard, c’est l’une des caractéristiques de Git et de tous les systèmes de contrôle de version décentralisé. Et c’est vrai que s’éloigner pour re-fusionner est plus compliqué avec les systèmes de contrôle de version centralisé comme Subversion et CVS. Mais tous ces « forks » créés sur Git ne sont pas des forks au sens premier du terme. En général, lorsqu’un développeur se fait une copie sur Git et la modifie, c’est en espérant que ses changements seront fusionnés dans la copie « maîtresse ». Et quand je dis « maîtresse », ce n’est pas au sens technique, mais bien au sens politique : la copie maîtresse est celle que la plupart des utilisateurs suivent.

Je trouve que ces fonctionnalités de Git et de GitHub sont géniales, et j’aime bien les utiliser, mais il n’y a rien de révolutionnaire ici. Il y a peut-être une évolution de la terminologie, mais la vraie dynamique des projets open source ne varie pas : les développeurs fournissent de gros efforts pour que leurs modifications soient intégrées a la distribution principale, car ils ne veulent pas s’embarrasser avec une copie privée qu’ils auraient a entretenir. Git réduit la pénibilité liée à la maintenance de modifications indépendantes, mais pas encore suffisamment pour que cet effort soit négligeable. Les développeurs intelligents forment des communautés et tentent de conserver un code de base unifié, car c’est la meilleure chose à faire. Ça n’est pas près de changer.

En juin 2010, Benjamin Mako Hill remarque dans son article Free Software Needs Free Tools (traduit ici sur le Framablog) qu’héberger un projet libre sur une plateforme propriétaire pose problème. À votre avis, quelle est l’importance de ce problème ?

Et bien, je connais Mako Hill, je l’apprécie et j’éprouve beaucoup de respect pour lui. Mais je dois dire que je ne partage pas son avis sur ce point, et ce, pour plusieurs raisons.

D’abord, il faut être réaliste. On ne peut pas être un développeur logiciel sans outils propriétaires de nos jours. Réduire arbitrairement la notion de « plateforme » n’est qu’un artifice pour croire qu’on travaille dans un milieu entièrement libre. Par exemple, je peux héberger mon projet chez Launchpad, qui est un logiciel libre, mais est-ce que je peux vraiment écrire du code sans utiliser le moteur de recherche de Google, qui n’est pas libre ? Bien sur que non. Tous les bons programmeurs utilisent en continu Google, ou un autre moteur de recherche propriétaire. Il faut inclure ces recherches Google dans la « plateforme », impossible de se voiler la face.

Mais on peut pousser la réflexion plus loin :

Qu’attendez-vous de l’hébergeur de votre projet, quelles sont les libertés importantes ? Vous utilisez une plateforme et vous demandez aux autres de l’utiliser aussi pour collaborer avec vous, donc, idéalement, la plateforme devrait être libre.

Ainsi, si vous souhaitez y apporter des modifications, vous pouvez : si quelqu’un veut créer un fork de votre projet (au sens ancien, politique, du terme), ils peuvent reproduire l’infrastructure d’hébergement ailleurs, où ils la contrôleront, si nécessaire. Alors, en théorie tout cela est très bien et très joli, mais honnêtement, même si le code source de Google Code, par exemple, était libre, vous ne pourriez pas reproduire Google Code Hosting. Il vous manquerait encore le personnel, le service, les data center de Google… toute l’infrastructure qui n’a rien à voir avec le code source. Ça n’est pas réalistiquement faisable.

Vous pouvez forker le projet, mais en général vous ne pouvez pas reproduire son hébergement, cela demande trop de ressources. Et puisque ça n’est pas votre propre service, vous ne pouvez pas l’adapter a votre convenance ; ce sont les gens qui font tourner les serveurs matériels qui décident de quels ajustements sont acceptables ou pas. Donc dans la pratique, vous ne disposez pas de ces libertés.

(Certains services d’hébergement tentent d’octroyer autant de libertés que possible a leurs utilisateurs. Par exemple, le code de Launchpad est open source, et ils intègrent les correctifs de leurs membres. Mais l’entreprise qui héberge Launchpad doit quand même approuver chaque modification puisque ce sont eux qui font tourner les serveurs. Je crois que SourceForge veut tenter la même expérience, si l’on en croit l’annonce faite récemment à propos d’Allura.)

Alors, en fonction de tout cela, quelles sont les libertés possibles ?

Il vous reste la liberté de faire entrer et sortir vos données. En d’autres termes, le noeud du problème se situe au niveau de la possibilité qu’on les interface de programmations (API pour Application Programming Interfaces) de déplacer les données d’un service à l’autre, de manière fiable et automatique. Si je peux écrire un programme qui peut récupérer toutes les données de mon projet depuis une forge pour les transférer à une autre, c’est une liberté utile. Je ne suis pas pieds et poings liés. Ça n’est pas la seule liberté qui compte, on est même loin d’une liberté idéale. Mais c’est une liberté utile dont on dispose dans un monde où utiliser ses propres serveurs est devenu inabordable.

Ce n’est pas que cette conclusion m’enchante. Mais les choses sont ainsi. La période de « chasseur/cueilleur » dans l’open source est terminée, nous sommes entrés dans l’ère agricole et urbaine. Vous ne pouvez plus creuser vos propres sillons d’irrigation ou votre propre système d’évacuation des eaux usées. C’est trop compliqué. Mais, au moins, si vous n’êtes pas satisfait du service rendu par un hébergeur, vous pouvez déménager chez un autre plus efficace grâce a la portabilité des données.

Donc ça m’importe assez peu de savoir que la plateforme GitHub est propriétaire, par exemple. Evidemment, ça serait mieux si elle était entièrement open source, mais le fait qu’elle ne le soit pas n’est pas vraiment un énorme problème. Le premier critère auquel je fais attention lorsque j’évalue un service d’hébergement est la richesse de leurs APIs. Est-ce que je peux récupérer toutes mes données si besoin ? Si leurs APIs sont riches, c’est bon signe, ils feront leur travail pour maintenir un service de qualité, car c’est le critère qui leur permettra de conserver leurs utilisateurs.

En France, les élevés de collège et de lycée ne suivent pas de cours d’informatique. Pensez-vous que l’informatique devrait être une matière a part entière, et pas seulement un outil pour les autres matières ?

Evidemment. La compréhension des données et du calcul formel est très importante désormais. C’est une forme d’alphabétisme. Sans aller jusqu’à maîtriser la programmation, il faut savoir comment les données fonctionnent. Cela fait écho à une discussion récente où je me suis rendu compte du gouffre qui peut exister.

J’étais chez le docteur, pour faire quelques tests. L’un d’eux consistait à filmer les battements de mon cœur grâce aux ultra-sons et toute la séquence était enregistrée. C’était incroyable a voir ! Et donc, une fois terminé, je demande à l’accueil si je pouvais avoir les données. Pour être précis, j’ai demandé : « Est-ce que je pourrai avoir les données de l’echocardiogramme ? » L’assistante m’a répondu qu’ils pouvaient m’imprimer des images basse-résolution. J’ai alors répondu : « Merci, mais ce sont les données que je veux ». Elle m’a répondu que c’est bien ce qu’elle me proposait. Pour elle, le mot « données » n’avait pas la même signification précise que pour ceux qui ont appris ce que sont les données. Ma question impliquait évidemment que je voulais toutes les données qu’ils avaient enregistres. C’est bien ce que signifie « Toutes les données », non ? Il ne devrait pas y avoir de perte d’information : c’est une copie bit par bit. Mais cela ne lui parlait pas. Pour elle, les données, c’est « quelque chose qui ressemble a ce que j’ai demandé ». Je parlais d’information, d’informatique, elle me parlait de perception.

Je suis bien conscient que mon point de vue est radical, mais je trouve que c’est une forme d’illettrisme de nos jours. Vous devez savoir faire la différence entre les vraies informations et les fausses informations et vous devez comprendre l’énorme différence d’application qui existe entre les deux. Si je me rends chez un autre médecin, vous imaginez bien la différence que ça fait si je lui présente la vidéo complète sur clé USB par rapport à des copies basse résolution d’images fixes. L’une est utile, l’autre ne sert strictement à rien.

Les entreprises qui comprennent le mieux la valeur des données, de données nous concernant, ont de plus en plus de moyens d’utiliser ces données à leur avantage, mais pas nécessairement dans le vôtre. Les cours d’informatique sont une forme de défense contre ceci, une réponse immunitaire à un monde dans lequel la possession et la manipulation des données se transforme de plus en plus en pouvoir. Vous êtes mieux à même de comprendre comment les données peuvent être utilisées si vous les avez déjà manipulées vous-même.

Donc oui, je suis pour les cours d’informatique… mais pas seulement comme moyen de défense :-). C’est aussi une formidable occasion pour les écoles de réaliser quelque chose de collaboratif. L’enseignement se focalise trop souvent sur des apprentissages « individuels ». D’ailleurs, la coopération à l’école est souvent prohibée et on appelle cela de la triche. Or en cours d’informatique, la chose la plus naturelle est d’initier des projets open source ou de participer à des projets open source.

Bien sûr, tous les étudiants ne seront pas forcément doués ou hyper motivés pour cela, mais c’est la même choses dans toutes les autres matières. Je pense donc que les cours d’informatique sont une bonne opportunité d’exposer les élèves aux plaisirs du développement collaboratif. Ces cours devraient avoir un impact incroyable sur certains élèves, comme, par exemple, les cours de musique.

Une toute dernière question : quel conseil donneriez-vous au programmeur en herbe qui souhaite découvrir la communauté des logiciels libres et open source ? Essayez de répondre en une phrase, pas avec un livre entier 🙂

Trouvez un projet ouvert que vous appréciez (et, idéalement, que vous utilisez) et commencez à y participer ; vous ne le regretterez pas !

Ce n’est plus une application qui vous permet d’accéder au Web, c’est un manifeste politique et un art de vivre !

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

Transcript du sous-titrage

URL d’origine du document

Nous sommes assez fiers d’être un navigateur à part.

Nous n’avons pas de titres ronflants quand nous sommes cités dans la presse. Nous n’avons pas de marge bénéficiaire. Nous n’avons ni icône ni gourou à vénérer à plat ventre.

Nous ne passons pas les mêmes accords, ne signons pas les mêmes contrats, ni ne serrons les mêmes mains, que tout le monde. Et cela ne nous dérange pas.

Nous sommes une communauté d’esprits indépendants, de gens farouchement anticonformistes qui font les choses un peu différemment.

Là où d’autres sociétés pourraient donner de l’importance aux résultats, nous donnons de la valeur… à nos valeurs.

Lorsqu’un concurrent songe à rendre quelque chose propriétaire, nous nous efforçons de le libérer. Et quand de nombreux produits et technologies sont développés derrière des portes closes, les nôtres sont cultivées au grand jour, là où chacun peut les voir.

Nous n’avons de comptes à rendre à aucun actionnaire. Nous ne rendons des comptes qu’à vous.

Et nous ne fonctionnons pas ainsi pour le plaisir, même si l’on s’amuse énormément. Nous fonctionnons ainsi parce que nous pensons que c’est la chose à faire.

Nous croyons que les principes sont plus importants que le profit. Nous croyons que l’honnêteté l’emporte sur le secret, et que la communauté prévaut sur les intérêts de l’entreprise.

Nous croyons qu’il faut prendre soin du Web et non s’en emparer, que c’est plus une ressource que nous devons protéger plutôt qu’un simple bien qui peut être vendu.

Et nous croyons fermement en l’innovation qui met l’utilisateur à l’avant, au centre et fermement aux commandes.

Mais surtout nous croyons en vous.

Nous croyons que le meilleur navigateur du monde est rendu possible par des ingénieurs, des programmeurs, des designers, et des gens comme vous, qui donnent de leur temps, leur talent, leur énergie et leur appui à la cause.

Et nous croyons qu’ensemble, en gardant cette cause en tête, nous pouvons innover au bénéfice de l’individu, et à l’amélioration du Web. Afin que toujours et à jamais il serve le bien commun.

Nous sommes tous Mozilla Firefox.

Nous ne sommes pas qu’une sorte différente de navigateur. Nous sommes un navigateur qui fait la différence.