Financer l'art vs financer le logiciel

J'ai proposé deux nouvelles façons de financer les artistes dans un monde où l'on aurait légalisé le partage (la redistribution non commerciale de copies exactes d'œuvres publiées). Une de ces façons est de laisser l'État collecter des taxes dans ce but et de partager l'argent entre les artistes en proportion de la racine cubique de la popularité de chacun (mesurée par des sondages dans la population). L'alternative est que chaque lecteur multimédia ait un bouton « faire un don » afin d'envoyer anonymement une petite somme d'argent (pourquoi pas 50 cents aux États-Unis) aux artistes qui viennent d'être joués (ou lus ou visionnés). Ces fonds iraient aux artistes, pas à leurs éditeurs.

Les gens se demandent souvent pourquoi je ne propose pas ces méthodes pour le logiciel libre. Il y a une raison à cela : c’est difficile de les adapter à des œuvres qui sont libres.

À mon avis, les œuvres destinées à servir d'« outils » pour effectuer des tâches concrètes doivent être libres. Les gens qui les utilisent méritent de contrôler les tâches qu’ils effectuent, ce qui nécessite de contrôler les œuvres-outils qu'ils utilisent, et par conséquent de posséder les quatre libertés. Ces œuvres comprennent les ressources pédagogiques, les ouvrages de référence, les recettes, les polices de caractères et, bien sûr, les logiciels ; toutes doivent être libres.

Cet argument ne peut s'appliquer ni aux œuvres d'opinion (telles que cet article) ni à l'art, parce qu'ils n'ont pas été créés pour effectuer des tâches concrètes. Par conséquent, je ne pense pas que ces œuvres doivent être libres. Nous devons rendre légal le fait de les partager et d'en utiliser des extraits dans des remix qui créeront des œuvres entièrement nouvelles, mais cela n'inclut pas la publication de versions modifiées. Il s'ensuit qu'on peut en identifier les auteurs. Toute œuvre publiée peut renvoyer vers ses créateurs, et changer cette information peut être illégal.

C'est le point crucial qui permettra aux systèmes de financement que je propose de fonctionner. Cela signifie que si vous écoutez une chanson et appuyez sur le bouton « faire un don », le système peut à coup sûr retrouver à qui faire le don. De la même manière, si vous faites partie du panel de consommateurs qui évalue la popularité des artistes, le système sera capable d'augmenter la cote de l'artiste dont vous aurez écouté ou copié la chanson.

Quand une chanson est créée par différents artistes (par exemple, plusieurs musiciens et un auteur-compositeur), cela n'arrive pas par hasard. Ils savent qu'ils travaillent ensemble et ils peuvent décider à l'avance comment attribuer à chacun une part de la popularité que la chanson obtiendra par la suite – ou utiliser les règles standards par défaut pour effectuer cette répartition. Ce cas ne pose aucun problème pour mes deux propositions de financement car l'œuvre, une fois réalisée, ne peut être modifiée par d'autres.

Cependant, dans un monde d'œuvres libres, une œuvre unique de grande ampleur peut avoir des centaines, voire des milliers d'auteurs. Il peut y avoir diverses versions, avec des groupes d'auteurs totalement ou partiellement différents. De plus, les contributions de ces auteurs seront différentes, en nature comme en importance. Cela rend impossible d'attribuer à chacun une part de la popularité de l'œuvre selon une estimation correcte. Ce n'est pas seulement une lourde tâche ; ce n'est pas simplement complexe. Le problème soulève des questions philosophiques pour lesquelles il n'existe pas de bonne réponse.

Considérons, par exemple, le logiciel libre GNU Emacs. Nos archives concernant les contributions au code de GNU Emacs sont incomplètes pour la période où nous n'utilisions pas encore un système de gestion de version : à cette époque-là, nous n'avions que les journaux des modifications [changelogs]. Mais imaginons que nous possédions encore toutes les versions et que nous puissions déterminer avec précision qui a contribué à quoi, quelle partie du code revient à chacun des contributeurs, parmi des centaines. Nous serions toujours coincés.

Si nous souhaitions donner crédit à chacun en proportion du nombre de lignes de code qu'il a écrites (et pourquoi pas du nombre de caractères ?), alors tout serait très simple, une fois que nous aurions résolu la façon de gérer une ligne de code écrite par A puis modifiée par B. Mais cela suppose que toutes les lignes aient la même importance. Je suis certain que cela est faux – certains morceaux de code ont un rôle plus important que d'autres ; certains sont plus faciles à programmer que d'autres. Mais je ne vois aucune façon de quantifier ces distinctions et les développeurs pourraient en débattre pendant une éternité. Peut-être que je mérite plus de crédit pour avoir écrit le programme initial, et certains programmeurs méritent peut-être plus de crédit pour avoir été à l'origine de certains ajouts importants, mais je ne vois aucune façon objective de quantifier cela. Je ne peux proposer de règle logique pour donner à chacun le crédit qui lui revient pour la popularité d'un programme comme GNU Emacs.

Quant à demander à tous les contributeurs de s'entendre, il ne faut même pas y penser. Il y a eu des centaines de contributeurs, et de nos jours nous ne pourrions pas les retrouver tous. Les participations se sont étalées sur une période de 26 ans et jamais, à aucun moment, ces gens n'ont pris la décision de travailler ensemble.

Il se peut même que nous ne connaissions pas les noms de tous les auteurs. Si du code nous a été donné par des entreprises, nous n'avons pas eu besoin de demander qui avait écrit ce code.

Alors qu'en est-il des variantes de GNU Emacs issues de modifications du programme d'origine, ou de branches différentes de développement ? Chacune d'elles est un cas nouveau, tout aussi complexe que les autres, mais différent. À qui donner crédit, et dans quelles proportions ? Combien à ceux qui ont travaillé sur cette variante, combien aux auteurs initiaux du code récupéré sur d'autres variantes de GNU Emacs ou sur d'autres programmes, etc. ?

En conclusion, il n'y a aucun moyen de donner crédit individuellement aux auteurs de GNU Emacs autrement que de manière arbitraire. Mais Emacs n'est pas un cas isolé ; c'est un exemple typique. Les mêmes problèmes se poseraient pour de nombreux programmes libres importants, ainsi que pour d'autres œuvres libres telles que les pages de Wikipédia.

C'est à cause de ces problèmes que je ne propose aucun de ces deux systèmes de financement pour des secteurs comme le logiciel, les encyclopédies ou l'éducation, où toutes les œuvres doivent être libres.

Ce qui a du sens dans ce type d'activité, c'est de demander aux gens de faire un don à un projet pour le travail qu'il se propose d'accomplir. C'est un système très simple.

La Free Software Foundation sollicite les dons de deux manières. Nous sollicitons des dons non affectés pour financer le travail de la fondation, et nous appelons aussi à faire des dons affectés à certains projets spécifiques. D'autres organisations appartenant au monde du logiciel libre le font aussi.