En novembre dernier, Richard Stallman faisait paraître dans le magazine Wired un article important sur l’épineuse et dangereuse question des brevets logiciels (ou plutôt « brevets sur des idées informatiques » comme nous le verrons ci-après).

Un article que nous nous sommes empressés de traduire via notre circuit, désormais classique, compte Twitter + Framapad, et qui a été relu et corrigé par la liste « trad-gnu » de l’April.

Protéger le secteur du logiciel des brevets

Giving the Software Field Protection from Patents

Richard Stallman – version du 02 février 2013 – Gnu.org (CC BY-ND)
(Traduction Framalang : satbadkd, Thérèse, DarthMickey, geecko, Marc, igor, EEva, greygjhart)

Une première version de cet article a été publiée sur Wired en novembre 2012.

Les brevets menacent chaque concepteur de logiciel, et les guerres de brevet que nous avons longtemps craintes ont éclaté. Les développeurs et les utilisateurs – soit, dans notre société, la plupart des gens – ont besoin de logiciels libres de tout brevet.

Les brevets qui nous menacent sont souvent appelés « brevets logiciels », mais ce terme est trompeur. Ces brevets ne concernent aucun programme en particulier. En fait, chaque brevet décrit une idée applicable en pratique, et affirme que quiconque utilise cette idée peut être poursuivi en justice. Il est donc plus clair de les appeler « brevets sur des idées informatiques », ou « brevets sur des algorithmes ».

Le système de brevets américain ne différencie pas les « brevets logiciels » des autres. Seuls les développeurs font la distinction entre les brevets qui nous menacent – ceux qui concernent des idées pouvant être implémentées dans des logiciels – et les autres. Par exemple : si l’idée brevetée est la forme d’une structure physique ou une réaction chimique, aucun programme ne peut implémenter cette idée ; ce brevet ne menace pas le secteur du logiciel. Si par contre l’idée qui est brevetée est un algorithme, alors le canon de ce brevet est braqué sur les développeurs et les utilisateurs.

Cela ne veut pas dire que les brevets couvrant des algorithmes concernent seulement les logiciels. Ces idées peuvent être aussi implémentées dans du matériel… et beaucoup d’entre elles l’ont été. Chaque brevet couvre typiquement les implémentations matérielles et logicielles de l’idée.

Le problème particulier du logiciel

Toujours est-il que c’est dans le domaine du logiciel que les brevets sur des algorithmes posent un problème particulier. Il est facile de combiner des milliers d’idées dans un seul programme. Si 10% de ces idées sont brevetées, cela signifie que des centaines de brevets le menacent.

Quand Dan Ravicher, de la Public Patent Foundation (Fondation publique des brevets) a étudié en 2004 un programme de taille importante (Linux, qui est le noyau du système d’exploitation GNU/Linux), il a trouvé 283 brevets américains qui semblaient couvrir des algorithmes implémentés dans son code source. Cette année-là, on estimait la part de Linux dans le système GNU/Linux complet à 0,25%. En multipliant 300 par 400, on peut estimer que le nombre de brevets qui menacent le système dans son ensemble est de l’ordre de 100 000.

Si la moitié de ces brevets était supprimée pour cause de « mauvaise qualité » – c’est-à-dire pour cause de ratés du système de brevets – cela ne changerait pas grand chose. Que ce soit 100 000 ou 50 000 brevets, la catastrophe est la même. C’est pourquoi c’est une erreur de limiter nos critiques des brevets logiciels aux seuls patent trolls ou aux brevets de « mauvaise qualité ». En ce sens Apple, qui n’est pas un « troll » selon la définition habituelle, est actuellement l’entreprise la plus dangereuse quand elle se sert de ses brevets pour attaquer les autres. Je ne sais pas si les brevets d’Apple sont de « bonne qualité », mais plus la « qualité » du brevet est élevée, plus la menace est grande.

Nous devons corriger l’ensemble du problème, pas seulement une partie.

Pour corriger le problème sur le plan législatif, on suggère habituellement de changer les critères d’octroi des brevets – par exemple, d’interdire la délivrance de brevets sur les pratiques algorithmiques et les systèmes nécessaires à leur mise en œuvre. Mais cette approche a deux inconvénients.

Premièrement, les avocats reformulent les brevets de manière astucieuse pour qu’ils correspondent à toute règle applicable ; ils transforment toute tentative de limiter un brevet sur le fond en une simple exigence de forme. Par exemple, de nombreux brevets américains sur des algorithmes décrivent un système qui comprend une unité de traitement arithmétique, un séquenceur d’instruction, une mémoire ainsi que des contrôles pour mener à bien un calcul précis. C’est une manière assez particulière de décrire un programme tournant sur un ordinateur pour effectuer un certain calcul ; elle a été élaborée pour que la demande de brevet se conforme aux critères que, pendant quelques temps, l’on a cru être ceux du système américain de brevets.

Deuxièmement, les États-Unis ont déjà plusieurs milliers de brevets sur des algorithmes, et changer les critères pour empêcher d’en créer d’autres ne permettrait pas de se débarrasser de ceux qui existent. Il faudrait attendre pratiquement 20 ans avant que le problème ne soit entièrement résolu du fait de l’expiration des brevets. Et abolir les brevets existants par la loi est probablement anticonstitutionnel (de manière assez perverse, la Cour suprême a insisté pour que le Congrès puisse étendre les privilèges privés au détriment des droits du public mais ne puisse pas aller dans l’autre direction).

Une approche différente : limiter l’effet des brevets, pas la brevetabilité

Ma proposition est de changer l‘effet des brevets. Il faut inscrire dans la loi que développer, distribuer ou exécuter un programme sur des systèmes informatiques polyvalents ne constitue pas une violation de brevet. Cette approche a plusieurs avantages :

• elle n’impose pas de classer les brevets selon qu’ils sont logiciels ou non ;
• elle apporte aux développeurs ainsi qu’aux utilisateurs une protection contre les brevets sur des algorithmes, existants ou futurs ;
• les avocats spécialistes des brevets ne peuvent plus trouver d’échappatoire en changeant la formulation de leurs demandes.

Cette approche n’invalide pas entièrement les brevets existants sur des algorithmes, parce qu’ils continueront à s’appliquer aux implémentations utilisant du matériel dédié. C’est un avantage dans le sens que cela supprime un argument mettant en question la validité de cette proposition du point de vue législatif. Les États-Unis ont légiféré il y a quelques années afin d’immuniser les chirurgiens contre les procès en contrefaçon de brevet, de sorte que même si des procédures chirurgicales sont brevetées, les chirurgiens sont protégés. Cela fournit un précédent pour ce type de solution.

Les développeurs et les utilisateurs de logiciels ont besoin de protection contre les brevets. Cette proposition est la seule solution législative qui apporte une protection totale à tous. Nous pourrions ensuite retourner à notre monde de concurrence ou de coopération… sans craindre qu’un inconnu ne vienne balayer notre travail.

Voir également : Une réforme des brevets n’est pas suffisante

Crédit photo : OpenSourceWay (Creative Commons By-Sa)

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : Nyx, lamessen, Sphinx, peupleLà, lerouge, Sky, Julius22, Astalaseven, Alpha, HgO, michel, Sputnik, goofy, HanX, KoS

Ne vous inquiétez pas, faites confiance

Shaun McCance

Shaun McCance est impliqué dans la documentation de GNOME depuis 2003 en tant que rédacteur, chef de la communauté et développeur d’outils. Il a passé la plupart de ce temps à se demander comment inciter davantage de personnes à écrire une documentation de meilleure qualité, avec un certain succès à long terme. Il propose son expérience de la documentation communautaire à travers sa société de conseil, Syllogist.

Alors que je m’apprêtais à écrire cet article, il s’est passé quelque chose d’énorme : GNOME 3 est sorti. C’était la première version majeure de GNOME depuis neuf ans. Tout était différent et toute la documentation existante devait être réécrite. Au même moment, nous changions notre façon de l’écrire. Nous avions jeté nos vieux manuels et étions repartis sur une nouvelle base, avec un système d’aide dynamique par sujet, en utilisant Mallard.

Quelques semaines avant la sortie, une partie d’entre nous s’est réunie pour élaborer la documentation. Nous passions nos journées à travailler, à planifier, à écrire et à réviser. Nous avons écrit des centaines de pages malgré les changements incessants liés aux ultimes modifications du logiciel. Nous avions des contributeurs en ligne qui proposaient de nouvelles pages et corrigeaient ce qui existait déjà. Je n’avais jamais vu notre équipe de documentation aussi productive.

À quoi avons-nous finalement abouti ? Beaucoup de facteurs sont entrés en jeu, et je pourrais écrire un livre entier sur les nuances de la documentation open source. Mais ce que j’ai fait de plus important a été de m’effacer et de laisser les autres faire le travail. J’ai appris à déléguer ; et à déléguer dans les règles de l’art.

Revenons huit ans en arrière. J’ai commencé à m’impliquer dans la documentation de GNOME en 2003. Je n’avais pas vraiment d’expérience en tant que rédacteur technique à cette époque. Mon emploi m’amenait à travailler sur des outils de publication et j’ai commencé à travailler sur les outils et sur le visualiseur d’aide utilisés par la documentation de GNOME. Peu de temps après, je me suis retrouvé à la rédaction de la documentation.

En ce temps-là, la majeure partie de notre documentation était entre les mains de rédacteurs techniques professionnels de chez Sun. Ils s’occupaient d’un manuel, l’écrivaient, le relisaient et l’envoyaient sur notre dépôt CVS. Après quoi nous pouvions tous le regarder, y apprendre quelque chose et lui apporter des corrections. Mais il n’existait pas d’efforts concertés pour impliquer les gens dans le processus d’écriture.

Ce n’est pas que les rédacteurs de Sun essayaient de protéger ou de cacher quoi que ce soit. Ils étaient avant tout rédacteurs techniques. Ils connaissaient leur travail et le faisaient bien. D’autres personnes auraient pu les remplacer pour d’autres manuels mais ils auraient écrit leurs travaux d’une manière habituelle. Utiliser un groupe de collaborateurs novices, aussi enthousiastes soient-ils, pour chaque page, revient à perdre un temps inimaginable sur des détails. C’est tout simplement contre-productif.

De manière inévitable, le vent a tourné chez Sun et leurs rédacteurs techniques ont été affectés à d’autres projets. Cela nous a laissés sans nos rédacteurs les plus prolifiques, ceux qui disposaient des meilleures connaissances. Pire que cela, nous étions laissés sans communauté et personne n’était là pour ramasser les morceaux.

Il y a des idées et des processus standards dans le monde de l’entreprise. J’ai travaillé dans le monde de l’entreprise. Je ne crois pas que quiconque remette ces idées en cause. Les gens font leur travail. Ils choisissent des missions et les terminent. Ils demandent aux autres de faire une relecture, mais ils n’ouvrent pas leur travail aux nouveaux venus et aux rédacteurs moins expérimentés. Les meilleurs rédacteurs écriront sans doute le plus.

Ces idées sont d’une plate évidence, mais elles échouent lamentablement dans un projet communautaire. Vous ne développerez jamais une communauté de contributeurs si vous faites tout vous-même. Dans un projet de logiciel, vous pouvez avoir des contributeurs compétents et suffisamment impliqués pour contribuer régulièrement. Dans la documentation, cela n’arrive presque jamais.

La plupart des gens qui s’essayent à la documentation ne le font pas parce qu’ils veulent être rédacteur technique ni même parce qu’ils aiment écrire. Ils le font parce qu’ils veulent contribuer. Et la documentation est la seule manière qu’ils trouvent accessible. Ils ne savent pas coder. Ils ne sont artistiquement pas doués. Ils ne maîtrisent pas assez une autre langue pour faire de la traduction. Mais ils savent écrire.

C’est là que les rédacteurs professionnels lèvent les yeux au ciel. Le fait que vous soyez instruit ne signifie pas que vous puissiez écrire une bonne documentation pour l’utilisateur. Il ne s’agit pas simplement de poser des mots sur le papier. Vous devez comprendre vos utilisateurs, ce qu’ils savent, ce qu’ils veulent, les endroits où ils cherchent. Vous avez besoin de savoir comment présenter l’information de façon compréhensible et savoir où la mettre pour qu’ils puissent la trouver.

Les rédacteurs techniques vous diront que la rédaction technique n’est pas à la portée de tous. Ils ont raison. Et c’est exactement pourquoi la chose la plus importante que les rédacteurs professionnels puissent faire pour la communauté est de ne pas écrire.

La clé pour construire une communauté efficace autour de la documentation, c’est de laisser les autres prendre les décisions, faire le travail et en récolter eux-mêmes les fruits. Il ne suffit pas de leur donner du travail en continu. La seule solution pour qu’ils s’intéressent suffisamment et s’accrochent au projet, c’est qu’ils se sentent investis personnellement. Le sentiment de faire partie intégrante d’un projet est une source puissante de motivation.

Mais si vous ne travaillez qu’avec des rédacteurs débutants et que vous leur donnez tout le travail à faire, comment pouvez-vous avoir l’assurance que la documentation ainsi créée sera de qualité ? Une participation massive mais incontrôlée n’aboutit pas à de bons résultats. Le rôle d’un rédacteur expérimenté au sein de la communauté est d’être un professeur et un mentor. Vous devez leur apprendre comment rédiger.

Commencez par impliquer les gens tôt dans le planning. Planifiez toujours du bas vers le haut. La planification du haut vers le bas n’incite pas à la collaboration. Il est difficile d’impliquer les gens dans la réalisation d’une vue d’ensemble de haut niveau si tous n’ont pas la même perception de cette vue d’ensemble. Mais les gens sont capables de travailler sur des segments. Ils peuvent réfléchir à des sujets particuliers d’écriture, à des tâches que les gens réalisent, à des questions que les gens peuvent se poser. Ils peuvent regarder les forums de discussion et les listes de diffusion afin de voir ce que les utilisateurs demandent.

Écrivez vous-même quelques pages. Cela donne un exemple à imiter. Il faut ensuite répartir tout le reste du travail. Laissez à d’autres la responsabilité de rubriques ou de chapitres entiers. Précisez-leur clairement quelles informations ils doivent fournir, mais laissez-les écrire. C’est en forgeant qu’on devient forgeron.

Soyez constamment disponible pour les aider ou répondre aux questions. Au moins la moitié de mon temps consacré à la documentation est passée à répondre à des questions afin que les autres puissent effectuer leur travail. Quand des brouillons sont soumis, relisez-les et discutez des critiques et des corrections avec leurs auteurs. Ne vous contentez pas de corriger vous-même.

Cela vous laisse tout de même le gros du travail à faire. Les gens complètent les pièces du puzzle, mais c’est toujours vous qui les assemblez. Au fur et à mesure qu’ils acquièrent de l’expérience, les gens s’occuperont de pièces de plus en plus grandes. Encouragez-les à s’impliquer davantage. Donnez-leur davantage de travail. Faites en sorte qu’ils vous aident à aider plus de rédacteurs. La communauté fonctionnera toute seule.

Huit ans plus tard, GNOME a réussi à créer une équipe de documentation qui se gère elle-même, résout les problèmes, prend des décisions, produit une bonne documentation et accueille constamment de nouveaux contributeurs. N’importe qui peut la rejoindre et y jouer un rôle. Telle est la clé du succès pour une communauté open source.

Antirez est un développeur de logiciel libre… ou plutôt open source, car c’est l’expression qu’il semble privilégier.

Il nous livre ici le fruit de sa petit réflexion.

Ainsi il préfère les licences permissives à celles copyleft. Ce qui ne l’empêche pas de souhaiter voir plus de rétribution dans le domaine, parce que si l’on est obligé de payer sa facture autrement alors il y aura moins de code utile à disposition de tous.

Quelques réflexions sur le logiciel open source

A few thoughts about Open Source Software

Antirez – janvier 2013 – Blog personnel
(Traduction : FanGio, peupleLà, ehsavoie, Tibo, Sphinx, Penguin + anonymes)

Voilà plus de quinze ans que je contribue régulièrement à l‘open source, et cependant je m’arrête assez rarement pour réfléchir à ce que cela représente pour moi. C’est probablement parce que j’aime écrire du code et que c’est ainsi que je passe mon temps : écrire du code plutôt que réfléchir à ce que cela signifie… Cependant ces derniers temps, je commence à avoir des idées récurrentes sur l‘open source, ses relations avec l’industrie informatique et mon interprétation de ce qu’est le logiciel open source pour moi, en tant que développeur.

Tout d’abord, l‘open source n’est pas pour moi une manière de contribuer au mouvement du logiciel libre, mais de contribuer à l’humanité. Cela veut dire beaucoup de choses, par exemple peu m’importe ce que les autres font avec mon code ou qu’ils ne reversent pas leurs modifications. Je veux tout simplement que des personnes utilisent mon code d’une manière ou d’une autre.

En particulier, je veux que les gens s’amusent, apprennent de nouvelles chose et se « fassent de l’argent » avec mon code. Pour moi, que d’autres se fassent de l’argent avec le code que j’ai écrit n’est pas une perte mais un gain.

1. J’ai beaucoup plus d’impact sur le monde si quelqu’un peut payer ses factures en utilisant mon code ;
2. Si N personnes gagnent de l’argent avec mon code, peut-être qu’elles seront heureuses de m’en faire profiter ou plus disposées à m’engager ;
3. Je peux être moi-même l’une de ces personnes qui gagnent de l’argent avec mon code, et avec celui d’autres logiciels open source.

Pour toutes ces raisons, mon choix se porte sur la licence BSD qui est en ces termes l’incarnation parfaite de la licence « faites ce que vous voulez ».

Cependant, il est clair que tout le monde ne pense pas de même, et nombreux sont les développeurs contribuant à l‘open source qui n’aiment pas l’idée que d’autres puissent prendre le code source et créer une entreprise qui ferait un logiciel commercial sous une autre licence.

Pour moi, les règles que vous devez suivre pour utiliser une licence GPL représentent une barrière qui réduit la liberté de ce que les personnes peuvent faire avec le code source. De plus, j’ai le sentiment qu’obtenir des contributions n’est pas tellement lié à la licence : si quelque chose est utile, des personnes vont contribuer en retour d’une manière ou d’une autre, car maintenir un fork n’est pas simple. La véritable valeur se trouve là où le développement se produit. Du code non corrigé, qui n’évolue pas, ne vaut rien. Si, en tant que développeur open source, vous pouvez apporter de la valeur, des parties tierces seront encouragées à faire intégrer leurs modifications.

Cependant, je suis beaucoup plus heureux quand il y a moins de correctifs à fusionner et plus de liberté du point de vue des utilisateurs, plutôt que l’inverse, il n’y a donc pas grand chose à discuter pour moi.

De mon point de vue, ce que l‘open source ne reçoit pas suffisamment en retour, ce ne sont pas les correctifs mais plutôt l’argent. Le nouveau mouvement des startups, et les faibles coûts opérationnels de nombreuses entreprises IT viennent de l’existence même de tout ce code open source qui fonctionne bien. Les entreprises devraient essayer de partager une petite partie de l’argent qu’elles gagnent avec les personnes qui écrivent les logiciels open source qui sont un facteur clé de leur réussite, et je pense qu’une manière saine de redistribuer cet argent est d’embaucher ces développeurs pour qu’ils écrivent du logiciel open source (comme VMware l’a fait pour moi), ou de faire des dons.

Beaucoup de développeurs travaillent pendant leur temps libre par passion, seul un petit pourcentage parvient à être payé pour leur contribution à l‘open source. Une éventuelle redistribution peut permettre à plus de gens de se concentrer sur le code qu’ils écrivent par passion et qui a peut être « un impact plus important » sur l’économie que le travail qu’ils font pour obtenir leur salaire chaque mois. Et malheureusement, il est impossible de payer les factures avec des PULL REQUESTS, c’est pourquoi je pense qu’apporter de l’aide à un projet sous forme de code est une bonne chose, mais ce n’est pas suffisant.

Vous pouvez avoir un point de vue différent sur tout cela, mais ce que j’observe, c’est que le logiciel open source produit beaucoup de valeur dans l’industrie informatique actuelle, et qu’il est souvent écrit sur son temps libre ou en jonglant entre les différentes tâches pendant son temps de travail, si votre employeur est assez souple pour vous permettre de le faire.

Ce que je pense, c’est que cela est économiquement sous-optimal, beaucoup de codeurs intelligents pourraient donner une impulsion à l’économie s’ils étaient plus libres d’écrire du code qu’ils aiment et que beaucoup de gens utilisent sans doute déjà pour faire de l’argent.

• Source : Hadopi : vers une amende systématique de 140 euros ? (Numerama)

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

Et si nous faisions en sorte qu’Internet nous permette de payer en toute liberté ?

Que nous sortions du double carcan de la somme fixe et unique pour tout le monde et du poids moral négatif induit par l’usage (de la copie) sans rétribution ?

Si c’est possible de le copier, alors vous le trouverez gratuitement sur Internet. Ceci n’est pas un slogan publicitaire mais une constatation. Nous vivons dans un monde où le contenu s’est affranchi de son support matériel et des limites inhérentes. Dans ce monde, les barrières de l’accès à la connaissance sont tombées. Tout le monde peut partager une réflexion philosophique, une analyse d’une œuvre de Monet. Ou une vidéo de chatons et le dernier clip d’un chanteur à la mode.

Au fond, c’est merveilleux. Cela devrait nous émerveiller tous les matins. Aucun auteur de Science-Fiction n’avait osé en rêver. C’est génial ! Sauf si on gagne sa vie à vendre du contenu sur un support physique. Auquel cas, la perspective est un peu inquiétante.

Alors que le support physique n’était jamais qu’un moyen comme un autre de diffuser de l’information, les vendeurs ont tout d’abord tenté de lier irrémédiablement le contenu avec son contenant. Voire de distribuer le contenu de manière virtuelle mais en ajoutant artificiellement les contraintes du matériel, quand bien même ce matériel n’existait plus.

Après cet échec prévisible, les industries du contenu cherchèrent d’autres méthodes de rentabilisation. Après tout, il existe des journaux gratuits, des chaînes de télévision gratuites. Le dénominateur commun étant le financement par l’ajout de publicité.

Outre les questions qu’elle pose, la publicité a le problème de dégrader l’expérience du contenu. Apprécierez-vous d’être interrompu au milieu d’une fugue de Bach par un slogan ventant des croquettes pour chat ? Pire : tout comme il est possible de tout trouver gratuitement, il est également possible de bloquer la publicité.

Un monde virtuel qui ne vivrait que de la publicité serait fortement limité. En effet, la publicité devrait forcément faire référence aux produits du monde réel, celui au grand plafond bleu, produits limités en quantité par le monde réel lui-même. À l’heure où l’on parle de décroissance, on ne peut imaginer augmenter à l’infini les publicités.

Lorsqu’il n’est physiquement plus possible de forcer quelqu’un à vous donner de l’argent, la seule solution est de faire appel à son sens moral. De le convaincre. Deux choix s’offrent au vendeur : la voie positive « C’est bien de donner » et celle négative « Ne pas donner, c’est mal ! ».

Devinez laquelle a été choisie ? Nous vivons dans un monde merveilleux où le partage est possible instantanément à travers la planète et nous avons réussi à transformer cette utopie futuriste, cette réalisation extraordinaire en un péché moral : « Ne pas payer, c’est mal ! », « Ne pas payer est illégal », « Si vous ne payez pas, vous serez poursuivi en justice », « Si vous ne payez pas, vos artistes préférés vont mourir de faim ».

Mais toute cette rhétorique négative se fonde sur une série de postulats.

1. Un artiste doit être payé pour ses réalisations.

FAUX. Cette vision se base sur une séparation nette entre les artistes d’un côté et les consommateurs de l’autre. Internet a démontré que nous sommes tous, à différents degrés, des artistes. Comme le dit Rick Falkvinge, un artiste c’est quelqu’un qui produit de l’art. À partir du moment où cette personne cherche à en tirer du profit, elle devient un entrepreneur. Et, à ce titre, c’est à elle de mettre en place un business model. On pourrait également appliquer cet argument au logiciel libre et dire que tout codeur doit être payé pour ses contributions. Pourtant, le logiciel libre prouve que c’est loin d’être le cas.

2. Tout travail mérite salaire.

FAUX. Le client paie généralement le produit d’un travail, pas le travail lui-même. Creuser un trou dans votre jardin est un travail dur. Le reboucher l’est tout autant. Pourtant, personne ne vous paiera pour cela. Le travail n’est donc rémunéré que lorsque quelqu’un estime intéressant de le faire, quelle que soit sa raison.

3. Il faut payer avant de consommer.

FAUX. Imaginez que vous puissiez entrer dans un restaurant, manger et que le prix soit laissé à votre appréciation. Si vous avez aimé, vous payez beaucoup. Sinon, vous payez moins ou juste assez pour couvrir le prix des produits. Utopiques ? C’est pourtant dans ce monde que nous vivons de plus en plus. La musique en est l’exemple le plus marquant : il n’est pas rare de rencontrer des audiophiles qui achètent un album qu’ils ont téléchargé depuis six mois sous prétexte : « C’est vraiment un bon CD, je l’adore, je l’écoute en boucle. Du coup, je l’achète pour soutenir l’artiste. ».

4. Il est obligatoire de payer.

FAUX. Contrairement à l’exemple du restaurant, la reproduction de l’information à un coût tout à fait nul. Il n’y a donc aucune raison particulière de payer pour consommer du contenu. Nous écoutons de la musique chez des amis, nous lisons un livre trouvé sur un banc, nous entendons un voisin expliquer le sens de la vie par dessus sa haie : nous consommons en permanence du contenu sans le payer. Pire, un même contenu peut être consommé gratuitement à titre promotionnel puis rendu payant par après. Les distributeurs de contenu sont donc dans la position schizophrénique de devoir diffuser le contenu autant que possible tout en empêchant… qu’il soit trop diffusé.

Pourtant, cet argument de l’obligation de payer est tellement tenace qu’il en est devenu « Si c’est gratuit, c’est nul » jusqu’à un extrème « Si c’est cher, c’est bien » exploité par les grandes marques.

5. Chacun doit payer le même prix pour accéder au même contenu.

FAUX. De nouveau, aucune loi naturelle n’oblige à ce que chacun paie la même chose pour le même service. Nous sommes pourtant habitués à ce genre de choses : les militaires, les jeunes et les pensionnés ont des réductions dans les transports en commun. Les journalistes et les professeurs ont des entrées gratuites dans certains musées.

Quand on y pense, payer le même prix est foncièrement injuste. Une personne qui adore un contenu paiera autant que quelqu’un qui n’a agit que par réflexe suite à une publicité et ne le consommera qu’une ou deux fois.

Si nous arrivons à remettre en question ces postulats, alors peut-être arriverons-nous à sortir de cette pernicieuse morale négative. Peut-être pourrons-nous enfin être fiers de cet accomplissement humain : le partage du savoir à tous les niveaux.

Et des solutions commencent à se mettre en place. Ma préférée étant Flattr qui, justement, permet de donner une petite somme d’argent aux contenus que l’on apprécie et ce parfois automatiquement. Avec la subtilité que la somme donnée par mois est fixe, quelque soit la quantité de contenu consommé. Framasoft est sur Flattr et je milite activement pour qu’on puisse Flattrer les billets individuels ! Certes, Flattr est centralisé mais tout service gérant des transferts d’argent le restera tant que Bitcoin ne sera pas généralisé !

Les artistes eux-mêmes commencent à bouger. Après l’expérience de Radiohead en 2007, c’est au tour d’Amanda Palmer de voir dans le « Payez ce que vous voulez » l’avenir des artistes. Et pour ceux qui souhaitent vraiment s’investir dans la réussite d’un artiste, les plateformes de « crowdsourcing » comme Kickstarter sont en train de contourner de plus en plus le rôle des gros producteurs, de décentraliser les industries du contenu.

À ce genre de discours, il est courant d’objecter que, si ils ont le choix, les consommateurs vont éviter de payer. Pourtant, le choix est déjà là. La majorité des consommateurs choisit de payer pour des raisons morales le plus souvent négatives. Il existe également des domaines où le fait de donner volontairement est considéré comme normal : c’est le principe du pourboire. Je vous propose de tester le web payant pour vous faire votre propre idée.

Transformer Internet en une économie du « Payez ce que vous voulez » ne serait donc que transformer les raisons morales afin de les rendre positives. Et, à ce titre, rendre complètement obsolètes tous les fichages, les surveillances et autre HADOPI. Un retour à la liberté.

Flattr ne différencie pas les consommateurs des producteurs de contenu. Nous sommes tous des producteurs de contenu, nous somme tous des artistes. Et nous sommes tous également avides de nouveautés, d’art et d’idées. Finalement, n’est-ce pas un des fondement de l’égalité ?

Contrairement à un achat, où je me sens toujours extorqué de mon argent durement gagné, faire un micro don me réchauffe le cœur, me donne le sentiment d’être, à mon échelle, un contributeur. Un sentiment de fraternité.

Liberté, égalité, fraternité. C’est peut-être la définition du web et de l’art de demain.

Crédit photo : Flattr (Creative Commons By)