Source :

• GnuPG a 16 ans et est en campagne (Framablog)

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)

Vous n’êtes que des enfants gâtés qui ne veulent pas payer, nous dit l’industrie du copyright…

Un argument que ne veut vraiment plus entendre Rick Falkvinge, en comparant la situation à l’affaire de la taxe sur le thé de Boston qui déclencha la révolte des Amériques contre la domination anglaise au XVIIIe siècle.

Imbéciles ! Cela n’a jamais été une histoire d’argent : Similitudes entre les cauchemars du monopole du copyright et l’affaire de la taxe sur le thé de Boston

It Was Never About The Money, Stupid: The Similarities Between Copyright Monopoly Madness & Boston Tea Taxes

Rick Falkvinge - 29 décembres 2013 - TorrentFreak
(Traduction : sinma, Peekmo, Sylvain, eve, emchateau, goofy, brandelune, Jeey_PPMP, KoS, Asta, benjamin, Sky + anonymes)

« Vous n’êtes que des enfants gâtés qui ne veulent pas payer », nous dit l’industrie du copyright, voyant les citoyens partager culture et connaissance par Internet. « Vous n’êtes que des enfants gâtés qui ne veulent pas payer », disaient les Anglais aux révoltés du Boston Tea Party. Les mécanismes sous-jacents sont les mêmes.

À chaque nouvelle découverte, d’anciennes raretés deviennent abondantes et de nouvelles raretés apparaissent autour des nouvelles abondances. Quand les ménages ont été électrifiés, la réfrigération des aliments est devenue chose courante, l’industrie de la glace s’est retrouvée sans marché du jour au lendemain et les électriciens ont pris le devant de la scène. Quand les lampadaires électriques arrivèrent, la profession d’allumeur de réverbères devint obsolète et encore une fois, il fallait plus d’électriciens. Quand le courrier électronique arriva, les services postaux et les postiers sont devenus largement obsolètes mais les administrateurs systèmes étaient devenus nécessaires à la place.

Quand les ordinateurs et Internet nous permettent aujourd’hui de fabriquer nos propres copies de la culture et du savoir, c’est au tour de l’industrie du copyright — qui gardait un monopole sur ce genre de duplication, maintenant la rareté de la culture et du savoir — de devenir obsolète, et en face de cette nouvelle abondance de culture et de savoir, de nouvelles raretés apparurent. Par exemple, quand vous avez plus ou moins toute la musique du monde sur votre disque dur, il devient fatigant et laborieux de les classer pour écouter ce que vous voulez.

Quand le service de musique Pandora a été lancé, il fit exactement cela : il résolut la nouvelle rareté, la capacité à trier parmi l’abondance. Je suis le 110e abonné sur plus de 20 millions aujourd’hui (et j’ai aussi payé pour contourner la ridicule tentative de blocage de ce service aux États-Unis). Il est facile de le vérifier.

Ceci est remarquable car les pirates ne sont pas disposés à payer pour la culture et les services (de diffusion) des connaissances. Cependant, les pirates (et par les « pirates », je veux dire les 150 millions de jeunes américains, 250 millions d’européens, et environ la moitié des jeunes du reste de la population mondiale) ne sont pas disposés à payer pour des services obsolètes, telles que la duplication. Les pirates sont les utilisateurs de la première heure (NdT : early adopters).

Reprenons cela, car il s’agit de l’élément clé pour arrêter de répéter tel un perroquet la sentence inexacte du « je ne veux pas payer » à propos des personnes qui partagent joyeusement en ligne culture et savoir :

Les pirates sont des utilisateurs de la première heure, en avance sur leur temps. Si vous leur mettez quelque chose de nouveau et brillant entre les mains, ils vous jetteront de l’argent. Inversement, ils seront les premiers à identifier un marché dépassé et l’abandonneront. De plus, ils n’accepteront – jamais – les lois qui les enferment avec un service qu’ils n’ont pas demandé, surtout quand ils peuvent faire la même chose eux-mêmes pratiquement sans aucun effort, comme fabriquer leurs propres copies de films, musiques, jeux ou logiciels avec leur propre matière première et leur travail.

Évidemment, cela signifie que vous ne pouvez pas obliger moralement les pirates à payer pour la fabrication de leurs propres copies en utilisant leur propre travail et matériaux, même si la loi dit que vous avez le droit de les taxer et de leur imposer une amende pour le faire. Cela apparaît comme extrêmement lourd et répressif.

Cela s’est produit de nombreuses fois auparavant, et ces situations ont tendance à se résoudre de la même façon. L’une des plus célèbres occurrences est celle qui a abouti à la grande manif du thé sur les quais de Boston. Ceci est advenu en dépit du fait que ces gens ne semblaient pas avoir un problème en tant que tel sur le fait de payer l’impôt sur le thé, le problème n’était pas un problème financier, ça ne l’a jamais été.

Vous pouvez dénigrer les pirates en prétendant qu’ils sont avares, et probablement assez aisés pour payer s’ils le voulaient, comme on pouvait alors dénigrer les buveurs de thé de l’époque comme des salauds avares qui pouvaient très bien payer la taxe sur le thé d’Angleterre. Ce faisant, vous êtes complètement à côté de la plaque, en choisissant, de manière grotesque, de déformer les éléments du débat afin d’éviter d’être déstabilisé, quitte à rester ignorant.

« Mais le Boston Tea Party concernait la taxation sans représentation » (NdT : c’est-à-dire que les populations américaines étaient taxées par un pouvoir étranger, auquel elles n’avaient aucune part, alors que les Anglais avaient une représentation populaire au Parlement qui votait l’impôt), diraient certains. « Le problème du monopole du copyright est différent ! »

L’est-il vraiment ?

Vraiment ?

Regardons les faits dont on dispose. Les lois sur le monopole du copyright ont été construites pour bénéficier au public, et au public seul. Dans la constitution des États-Unis, le but du monopole du copyright est clairement décrit comme « la promotion du progrès des sciences, et des arts utiles ». Rien de plus, rien de moins.

C’est important de noter cela, comme le but du monopole (« droit exclusif ») n’est pas, et n’a jamais été, d’autoriser quiconque à faire de l’argent à partir d’une activité particulière. Son but n’a jamais été, notamment, d’autoriser quelqu’un à continuer à faire de l’argent de la manière dont il l’avait toujours fait, même lorsque la technologie a modifié le paysage et que leur offre n’ajoutait plus aucune valeur supplémentaire.

Le monopole du copyright est un équilibre, mais c’est un équilibre entre deux intérêts publics qui entrent en conflit : l’intérêt public dans la promotion des nouvelles sciences et arts, et le même intérêt public d’avoir accès à ces sciences et arts. Les industriels du copyright n’ont aucune légitimité dans cette réglementation.

C’est là que le problème commence. Car, lorsque nous regardons comment la réglementation sur le monopole du copyright a été écrite et réécrite durant les dernières décennies, elle a été entièrement adaptée aux souhaits d’une industrie obsolète d’intermédiaires, augmentant de plus en plus les peines en cas de contournement de leur impasse monopolistique. L’intérêt du public – le seul acteur légitime – n’est plus, et n’a pas été, du tout pris en compte. Dit simplement : le public n’a pas voix au chapitre.

Donc si une loi qui force les gens à payer quelque chose inutilement et involontairement n’est pas une taxe, alors qu’est-ce que c’est ?

Et si leurs intérêts ne sont pas représentés^[1] dans cette législation… euh… ?

Cet argument peut apparaître comme ésotérique et étrange à ceux qui défendent le monopole du droit d’auteur mais je garantis deux choses à ces gens : premièrement, répéter comme un perroquet : « tout ce que vous voulez c’est ne pas payer » apparaît comme tout aussi étrange et éloigné de la réalité à ces entrepreneurs qui repoussent les limites, conscients de la technologie et de la société d’aujourd’hui. Et deuxièmement, le mot d’ordre « pas de taxe sans représentation » suite au Boston Tea Party devait sembler tout aussi étrange aux oreilles de l’élite autoproclamée de l’époque.

Je ne veux plus jamais entendre « vous ne voulez juste pas payer » de ma vie. Nous fabriquons nos propres copies de ce que nous observons directement avec notre travail et notre matériel, et nous avons tous les droits moraux, philosophiques, éthiques, économiques, et naturels de le faire. Nous rejetons le droit d’une industrie obsolète à décréter des taxes privées sur notre propre travail. Si vous voulez faire partie du futur, essayez au moins de prendre nettement plus de recul.

J’espère que le débat en 2014 sera légèrement plus élevé que depuis toutes ces années où je m’y suis impliqué (c’est-à-dire depuis 1987 environ). C’est à nous tous de forcer le débat dans le bon sens.

Le travail intellectuel des programmeurs souffrirait-il d’un manque de visibilité et de reconnaissance aux yeux d’une logique managériale qui cherche à mesurer le travail effectif avec des critères dépassés ? C’est ce que laisse entendre ce témoignage qui au détour d’une plaisante anecdote met l’accent sur un relatif malaise d’une profession qu’il est difficile de cerner de l’extérieur, et même de l’intérieur d’une entreprise.

Are Your Programmers Working Hard, Or Are They Lazy? article paru sur le blog de l’auteur

Traduction Framalang : sinma, goofy, KoS

Vos programmeurs travaillent-ils dur, ou sont-ils fainéants ?

par Mike Hadlow

Quand quelqu’un effectue une tâche physique, il est facile d’évaluer à quel point il travaille dur. Vous pouvez le voir physiquement en mouvement et en transpiration. Vous pouvez aussi voir le résultat de son travail : le mur de briques s’élève, le trou dans le sol devient plus profond. Reconnaître et récompenser un dur labeur est un instinct assez fondamental chez l’être humain, c’est l’une des raisons pour lesquelles nous trouvons les sports d’endurance si fascinants. Cette reconnaissance d’un dur travail physique devient un problème quand on l’applique à la gestion de personnes qui travaillent à des activités techniques ou créatives. Souvent, les travailleurs intellectuels efficaces n’ont pas l’air de travailler très dur.

En 2004, j’étais développeur junior dans une grande équipe qui s’occupait du système de fourniture et de facturation d’une entreprise de télévision par câble. Comme tous les grands systèmes, il était constitué de plusieurs unités relativement indépendantes dont s’occupaient des personnes ou des équipes différentes. Les départements de TV analogiques et numériques étaient presque entièrement séparés, pris en charge par des équipes différentes.

L’équipe de la TV analogique avait décidé de fonder son système autour d’une pré-version de Microsoft Biztalk. Quatre gars de chez nous et une équipe de Microsoft le développaient et le faisaient tourner en production. Ils avaient tous l’air de travailler très dur. On les voyait souvent travailler tard dans la nuit et pendant le weekend.

Chacun laissait tomber ce qu’il était en train de faire si un problème survenait en production, ils se réunissaient souvent autour du bureau d’un type, faisaient des suggestions pour régler ce qui n’allait pas, ou pour réparer quelque chose. L’activité était permanente, et tout le monde pouvait voir non seulement qu’il y avait un véritable esprit d’équipe, mais que tout le monde travaillait très très dur.

L’équipe chargée de la TV numérique était tout à fait différente. Le code avait été, en majorité, écrit par une seule personne que l’on appellera Dave. Il était développeur de maintenance junior dans l’équipe. Au départ, j’ai eu beaucoup de difficultés à comprendre le code. Au lieu d’une seule longue procédure dans un endroit précis où tout le travail se serait effectué, il y avait des tas de petites classes et méthodes avec seulement quelques lignes de code. Plusieurs collègues se plaignirent que Dave rendait les choses extrêmement compliquées. Mais Dave me prit sous son aile et me conseilla de lire quelques livres sur la programmation orientée objet. Il m’apprit les patrons de conception, les principes SOLID, et les tests unitaires. Le code commença alors à avoir du sens, et plus je travaillais dessus plus j’appréciais l’élégance de sa conception. Il ne posait pas de problème en phase de production, il ronronnait dans son coin et faisait le boulot. Il était assez facile d’opérer des modifications dans le code, du coup l’implémentation de nouvelles fonctionnalités se faisait souvent sans aucun problème. Les tests unitaires permettaient de trouver la plupart des bugs avant la mise en production.

Le résultat de tout cela est que nous n’avions pas l’air de travailler très dur du tout. Je rentrais chez moi à 18h30, je ne travaillais jamais pendant les weekends, nous ne passions pas des heures attroupés autour du bureau de quelqu’un d’autre pour deviner le problème avec un quelconque système planté en production. De l’extérieur, notre tâche devait sembler beaucoup plus facile que celle des gens de la TV analogique. En vérité, les exigences étaient très similaires, mais nous avions un logiciel mieux conçu et implémenté, et une meilleure infrastructure de développement, notamment les tests unitaires.

La direction fit savoir que des augmentations seraient accordées sur la base de nos performances. Quand ce fut mon tour de parler au directeur, il expliqua qu’il était normal que les augmentations soient accordées à ceux qui travaillaient vraiment dur, et que l’entreprise ne semblait pas importer beaucoup à notre équipe, au contraire de ces héros qui lui consacraient leurs soirées et leurs weekends.

photo par nic’s events - CC BY-SA 2.0

Cette entreprise était l’un des rares laboratoires où l’on pouvait comparer directement les effets d’une bonne ou d’une mauvaise conception logicielle et le comportement d’une équipe. La plupart des organisations ne permettent pas une telle comparaison. Il est très difficile de dire si ce type, transpirant sang et eau, travaillant tard les soirs et weekends, constamment sur la brèche, fait preuve d’une grande volonté pour faire fonctionner un système vraiment très complexe, ou s’il est simplement nul. Sauf si vous pouvez vous permettre d’avoir deux ou plusieurs équipes concurrentes travaillant à résoudre le même problème, mais bon, personne ne fait ça, on ne saura donc jamais. Et au contraire, le type assis dans son coin, travaillant de 9 heures à 17 heures et qui semble passer beaucoup de temps à lire sur internet ? Est-il très compétent pour écrire un code stable et fiable, ou son boulot est-il plus facile que celui des autres ? Pour l’observateur moyen, le premier travaille vraiment dur, pas le second. Travailler dur c’est bien, la paresse c’est mal, n’est-ce pas ?

Je dirais qu’avoir l’air de travailler dur est souvent un signe d’échec. Le développement logiciel est souvent mal fait dans un environnement sous pression et dans lequel on est souvent interrompu. Ce n’est généralement pas une bonne idée de travailler de longues heures. Quelquefois, la meilleure façon de résoudre un problème est d’arrêter d’y penser, d’aller prendre l’air, ou encore mieux, de prendre une bonne nuit de sommeil et de laisser faire notre subconscient. Un de mes livres favoris est « A Mathematician’s Apology » (traduit sous le titre L’apologie d’un mathématicien) par G. H. Hardy, un des mathématiciens anglais les plus importants du XX^e siècle. Il y décrit sa routine : quelques heures de travail le matin suivies par un après-midi à regarder le cricket. Il dit qu’il est inutile et contre-productif d’effectuer un travail mental intensif plus de quatre heures par jour.

photo par sfllaw - CC BY-SA 2.0

J’aimerais dire aux manageurs de juger les gens en regardant leurs résultats, leurs logiciels qui tournent bien, et non en regardant si les programmeurs ont l’air de travailler dur. C’est contre-intuitif, mais il est sans doute préférable de ne pas vous assoir tout près de vos développeurs, vous pourrez ainsi avoir une meilleure idée de ce qu’ils ont produit, sans être affecté par des indicateurs conventionnels ou intuitifs. Le travail à distance est particulièrement bénéfique ; vous devez apprécier vos employés pour leur travail, plutôt que par la solution de facilité qui consiste à les regarder assis à leur bureau 8 heures par jour, martelant de façon lancinante sur leur IDE, ou se pressant autour du bureau des autres pour offrir des suggestions « utiles ».

Source :

• Données de connexion saisies : 14 % seulement pour terrorisme ! (Numerama)
• Des smartphones rechargés à l’urine, une idée soutenue par Bill Gates (Numerama)

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)

Toujours et encore les conséquences des révélations de Snowden (qui a manqué de peu d’être élu « homme de l’année » par le Time Magazine).

Ici donc, Micosoft tente de montrer patte blanche avec Windows. Mais comme le rappelle la FSF ci-dessous : « une serrure sur votre propre maison pour laquelle vous n’avez pas la clé n’est pas un système sécurisé, c’est une prison ».

La FSF réagit suite à l’annonce de Microsoft sur la vie privée et le chiffrement

FSF responds to Microsoft’s privacy and encryption announcement

John Sullivan - 5 décembres 2013 - FSF News
(Traduction : Peekmo, Dalz, Sphinx, KoS, yannux, Asta, Penguin, Llu, Sky, Diin + anonymes)

Hier, lundi 4 décembre, Microsoft a annoncé un nouvel effort pour « protéger les données de ses clients contre l’espionnage du gouvernement ». Le directeur exécutif de la FSF a publié la déclaration suivante le mardi 5 décembre :

Microsoft a déjà fait par le passé des promesses de sécurité. Au final, ces promesses sont dénuées de sens. Un logiciel propriétaire comme Windows n’est fondamentalement pas sécurisé, non pas à cause des politiques de confidentialité de Microsoft, mais parce que son code est caché aux utilisateurs mêmes dont il est supposé protéger les intérêts. Une serrure sur votre propre maison pour laquelle vous n’avez pas la clé n’est pas un système sécurisé, c’est une prison.

Même sur des systèmes d’exploitation propriétaires comme Windows, il vaut mieux utiliser des programmes de chiffrement libres comme GNU Privacy Guard. Mais quand personne à part Microsoft ne peut voir les dessous du code, ou corriger les problèmes découverts, il est impossible d’avoir une vraie chaîne de confiance.

Si les révélations sur la NSA nous ont appris quelque chose, c’est que les journalistes, gouvernements, écoles, organisations de défense des droits, sociétés, et individus doivent utiliser un système d’exploitation dont le code peut être analysé et modifié sans l’accord de Microsoft ou de tout autre partie tierce. Si nous n’avons pas cela, les portes dérobées et la violation des droits privés sont inévitables.

L’annonce de Microsoft promet de la « transparence » pour rassurer les gens sur le fait qu’il n’y a pas de portes dérobées dans Windows, mais ce n’est certes pas une solution. La transparence dans le monde de Windows signifie uniquement des auto-évaluations commandées par Microsoft, ou un accès accordé à des tierces parties couvrant une portion très limitée du code source.

La liberté et la sécurité, ce n’est pas juste avoir le droit de jeter un œil au code. Microsoft a démontré à plusieurs reprises que sa définition d’une « porte dérobée » ne sera jamais la même que la notre. Découvrir qu’il existe une porte dérobée grande ouverte ne vous servira à rien s’il vous est interdit de la fermer.

La solution après l’annonce de Microsoft est la même qu’avant. Comme l’ancien conseiller principal de la sécurité (des données privées) de Microsoft : changez pour un système d’exploitation libre comme GNU/Linux, et ne regardez pas en arrière.