diff options
Diffstat (limited to 'talermerchantdemos/blog/articles/fr/funding-art-vs-funding-software.html')
-rw-r--r-- | talermerchantdemos/blog/articles/fr/funding-art-vs-funding-software.html | 224 |
1 files changed, 224 insertions, 0 deletions
diff --git a/talermerchantdemos/blog/articles/fr/funding-art-vs-funding-software.html b/talermerchantdemos/blog/articles/fr/funding-art-vs-funding-software.html new file mode 100644 index 0000000..5deda55 --- /dev/null +++ b/talermerchantdemos/blog/articles/fr/funding-art-vs-funding-software.html @@ -0,0 +1,224 @@ +<!--#set var="ENGLISH_PAGE" value="/philosophy/funding-art-vs-funding-software.en.html" --> + +<!--#include virtual="/server/header.fr.html" --> +<!-- Parent-Version: 1.84 --> + +<!-- This file is automatically generated by GNUnited Nations! --> +<title>Financer l'art vs financer le logiciel - Projet GNU - Free Software +Foundation</title> + +<!--#include virtual="/philosophy/po/funding-art-vs-funding-software.translist" --> +<!--#include virtual="/server/banner.fr.html" --> +<h2>Financer l'art vs financer le logiciel</h2> + +<p>par <a href="http://www.stallman.org/"><strong>Richard Stallman</strong></a></p> + +<p>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.</p> + +<p>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.</p> + +<p>À 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 (voir <a +href="/philosophy/free-sw.html">http://www.gnu.org/philosophy/free-sw.fr.html</a>). +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.</p> + +<p>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.</p> + +<p>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.</p> + +<p>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.</p> + +<p>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.</p> + +<p>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 +<cite>[changelogs]</cite>. 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.</p> + +<p>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.</p> + +<p>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.</p> + +<p>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.</p> + +<p>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. ?</p> + +<p>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.</p> + +<p>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.</p> + +<p>Ce qui a du sens dans ce type d'activité, c'est de demander aux gens de +faire un don à un <em>projet</em> pour le travail <em>qu'il se propose +d'accomplir</em>. C'est un système très simple.</p> + +<p>La <cite>Free Software Foundation</cite> sollicite les dons de deux +manières. Nous sollicitons des <a href="https://my.fsf.org/donate/">dons non +affectés pour financer le travail de la fondation</a>, et nous appelons +aussi à faire des <a +href="https://my.fsf.org/donate/directed-donations">dons affectés à certains +projets spécifiques</a>. D'autres organisations appartenant au monde du +logiciel libre le font aussi.</p> + +<div class="translators-notes"> + +<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.--> + </div> +</div> + +<!-- for id="content", starts in the include above --> +<!--#include virtual="/server/footer.fr.html" --> +<div id="footer"> +<div class="unprintable"> + +<p>Veuillez envoyer les requêtes concernant la FSF et GNU à <a +href="mailto:gnu@gnu.org"><gnu@gnu.org></a>. Il existe aussi <a +href="/contact/">d'autres moyens de contacter</a> la FSF. Les liens +orphelins et autres corrections ou suggestions peuvent être signalés à <a +href="mailto:webmasters@gnu.org"><webmasters@gnu.org></a>.</p> + +<p> +<!-- TRANSLATORS: Ignore the original text in this paragraph, + replace it with the translation of these two: + + We work hard and do our best to provide accurate, good quality + translations. However, we are not exempt from imperfection. + Please send your comments and general suggestions in this regard + to <a href="mailto:web-translators@gnu.org"> + + <web-translators@gnu.org></a>.</p> + + <p>For information on coordinating and submitting translations of + our web pages, see <a + href="/server/standards/README.translations.html">Translations + README</a>. --> +Nous faisons le maximum pour proposer des traductions fidèles et de bonne +qualité, mais nous ne sommes pas parfaits. Merci d'adresser vos commentaires +sur cette page, ainsi que vos suggestions d'ordre général sur les +traductions, à <a href="mailto:web-translators@gnu.org"> +<web-translators@gnu.org></a>.</p> +<p>Pour tout renseignement sur la coordination et la soumission des +traductions de nos pages web, reportez-vous au <a +href="/server/standards/README.translations.html">guide de traduction</a>.</p> +</div> + +<!-- Regarding copyright, in general, standalone pages (as opposed to + files generated as part of manuals) on the GNU web server should + be under CC BY-ND 4.0. Please do NOT change or remove this + without talking with the webmasters or licensing team first. + Please make sure the copyright date is consistent with the + document. For web pages, it is ok to list just the latest year the + document was modified, or published. + + If you wish to list earlier years, that is ok too. + Either "2001, 2002, 2003" or "2001-2003" are ok for specifying + years, as long as each year in the range is in fact a copyrightable + year, i.e., a year in which the document was published (including + being publicly visible on the web or in a revision control system). + + There is more detail about copyright years in the GNU Maintainers + Information document, www.gnu.org/prep/maintain. --> +<p>Copyright © 2013, 2017 Richard Stallman</p> + +<p>Cette page peut être utilisée suivant les conditions de la licence <a +rel="license" +href="http://creativecommons.org/licenses/by-nd/4.0/deed.fr">Creative +Commons attribution, pas de modification, 4.0 internationale (CC BY-ND +4.0)</a>.</p> + +<!--#include virtual="/server/bottom-notes.fr.html" --> +<div class="translators-credits"> + +<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.--> +Traduction : Framalang (fab, VifArgent, FanGio, LuD-up, Thérèse, Penguin, +Gatitac)<br /> Révision : <a +href="mailto:trad-gnu@april.org">trad-gnu@april.org</a></div> + +<p class="unprintable"><!-- timestamp start --> +Dernière mise à jour : + +$Date: 2019/05/01 14:01:20 $ + +<!-- timestamp end --> +</p> +</div> +</div> +</body> +</html> |