diff options
Diffstat (limited to 'talermerchantdemos/blog/articles/es/funding-art-vs-funding-software.html')
-rw-r--r-- | talermerchantdemos/blog/articles/es/funding-art-vs-funding-software.html | 215 |
1 files changed, 215 insertions, 0 deletions
diff --git a/talermerchantdemos/blog/articles/es/funding-art-vs-funding-software.html b/talermerchantdemos/blog/articles/es/funding-art-vs-funding-software.html new file mode 100644 index 0000000..2273a38 --- /dev/null +++ b/talermerchantdemos/blog/articles/es/funding-art-vs-funding-software.html @@ -0,0 +1,215 @@ +<!--#set var="ENGLISH_PAGE" value="/philosophy/funding-art-vs-funding-software.en.html" --> + +<!--#include virtual="/server/header.es.html" --> +<!-- Parent-Version: 1.84 --> + +<!-- This file is automatically generated by GNUnited Nations! --> +<title>El financiamento del arte frente al financiamento del software - GNU Project +- Free Software Foundation</title> + +<!--#include virtual="/philosophy/po/funding-art-vs-funding-software.translist" --> +<!--#include virtual="/server/banner.es.html" --> +<h2>El financiamento del arte frente al financiamento del software</h2> + +<p>por <a href="http://www.stallman.org/"><strong>Richard Stallman</strong></a></p> + +<p>He propuesto dos nuevos sistemas para financiar a los artistas en un mundo +en el que hayamos legalizado la práctica de compartir obras publicadas +(redistribución sin fines comerciales de copias exactas). Uno consiste en +que el Estado recaude impuestos para ello y que divida el dinero entre los +artistas según la raíz cúbica de la popularidad de cada uno (medida mediante +encuestas a muestras de la población). El otro, en que cada dispositivo +reproductor tenga un botón de «donar» que envíe anónimamente una pequeña +suma (por ejemplo 50 centavos en EE. UU.) al autor de la última obra +reproducida. Estos fondos irían a los artistas, no a sus editores.</p> + +<p>La gente a menudo se pregunta por qué no propongo estos métodos para el +software libre. Hay una razón para ello: es difícil adaptarlos para obras +que son libres.</p> + +<p>Desde mi punto de vista, las obras diseñadas para realizar tareas prácticas +deben ser libres. Quienes utilizan tales obras merecen tener el control de +sus tareas, para lo cual es necesario que tengan el control de las obras que +utilizan a fin de realizarlas, y para ello es a su vez fundamental que +disfruten de las cuatro libertades (ver <a href="/philosophy/free-sw.html"> +http://www.gnu.org/philosophy/free-sw.html</a>). Entre las obras para +realizar tareas prácticas se incluyen los recursos educativos, las obras de +referencia, las recetas, los tipos de letra y, por supuesto, el +software. Estas obras deben ser libres.</p> + +<p>Este argumento no es válido ni para las obras de opinión (como este +artículo) ni para el arte, ya que este tipo de obras no han sido diseñadas +para que se las use para realizar tareas prácticas. Por lo tanto, no creo +que tales obras deban ser libres. Debemos lograr que sea legal compartirlas +y utilizar fragmentos para hacer obras totalmente nuevas, pero esto no +incluye publicar versiones modificadas de las mismas. Esto significa que +podremos identificar a los autores de estas obras. Cada obra publicada puede +señalar quiénes son sus autores, y alterar dicha información puede ser +ilegal. </p> + +<p>Es ese el punto crucial que permite que los sistemas de financiación que +propongo funcionen. Implica que cuando usted escucha una canción y pulsa el +botón de «donar», el sistema puede individuar con certeza a quién enviar la +donación. Del mismo modo, si participa en la encuesta que calcula la +popularidad, el sistema sabrá a quién asignarle un poco más de popularidad +por el hecho de que usted escuchó aquella canción o hizo una copia de ella. </p> + +<p>Cuando son más de uno los artistas que componen una canción (por ejemplo, +varios músicos y un letrista), no se trata de algo casual. Saben que están +trabajando juntos y pueden decidir de antemano cómo repartir la popularidad +que conseguirá esa canción en el futuro o pueden aplicar las reglas +predefinidas para ese reparto. Este caso no crea ningún problema para las +dos propuestas de financiación porque nadie más modificará la obra una vez +realizada.</p> + +<p>Sin embargo, en el campo de las obras libres, una obra grande puede tener +cientos, incluso miles de autores. Puede haber varias versiones con +diferentes grupos de autores que se van sumando. Lo que es más, las +contribuciones de esos autores diferirán tanto en tipo como en +magnitud. Esto hace imposible establecer un modo correcto de repartir la +popularidad de la obra entre los colaboradores; es mucho más que una tarea +laboriosa y compleja. El problema plantea cuestiones filosóficas que no +tienen respuestas adecuadas. </p> + +<p>Consideremos, por ejemplo, el programa libre GNU Emacs. Nuestros registros +de contribuciones al código de GNU Emacs están incompletos para el periodo +en que aún no utilizábamos un sistema de control de versiones, de ese +periodo solo disponemos del histórico de cambios +(<cite>changelogs</cite>). Pero supongamos que tuviéramos todas las +versiones y pudiéramos determinar con precisión cuáles fueron las +contribuciones al código de cada uno de los cientos de colaboradores. Aun +así seguiríamos atascados.</p> + +<p>Si quisiéramos reconocer el trabajo de cada uno en proporción a las líneas +de código que aportó (¿o debería ser según los caracteres?), entonces +estaría claro, una vez que decidiéramos qué hacer con una línea que escribió +A y luego cambió B. Pero de ese modo se da por hecho que cada línea de +código es tan importante como cualquier otra. No me cabe duda de que eso es +un error, pues algunas líneas de código realizan tareas más importantes y +otras menos; hay códigos que son muy difíciles de escribir y otros más +sencillos. Pero no veo la manera de cuantificar esas diferencias, y los +desarrolladores podrían discutir sobre ello eternamente. Es posible que yo +merezca algún reconocimiento adicional por haber escrito el programa +inicial, y que algunos otros merezcan un reconocimiento adicional por haber +comenzado a escribir ciertos añadidos que luego fueron importantes, pero no +veo una forma objetiva de cuantificarlo. Me es imposible proponer una regla +plausible para repartir el reconocimiento por la popularidad de un programa +como GNU Emacs.</p> + +<p>En cuanto a pedir a todos los colaboradores que lleguen a un acuerdo, ni +siquiera podemos intentarlo. Ha habido cientos de colaboradores y a día de +hoy no podríamos localizarlos a todos. Contribuyeron a lo largo de 26 años y +en todo ese tiempo nunca decidieron trabajar juntos. </p> + +<p>Es posible que ni siquiera conozcamos el nombre de todos los autores. Si una +empresa donaba parte del código, no había necesidad de preguntar quiénes lo +habían escrito. </p> + +<p>¿Qué ocurre entonces con las bifurcaciones o las variantes modificadas de +GNU Emacs? Cada una representa un caso nuevo, igualmente complejo pero +diferente. ¿Cuánto reconocimiento por esa variante les corresponde a los que +trabajaron en ella y cuánto a los autores originales del código que tomaron +de otras versiones de GNU Emacs, de otros programas, etc.?</p> + +<p>La conclusión es que no hay manera de que podamos alcanzar un reparto del +reconocimiento por GNU Emacs que no sea arbitrario. Pero Emacs no es un caso +especial, es un ejemplo corriente. El mismo problema se presentaría con +muchos importantes programas libres y otras obras libres, como las páginas +de la Wikipedia.</p> + +<p>Estos problemas son la razón por la que no propongo usar esos sistemas de +financiación en campos como el software, las enciclopedias o la educación, +donde todas las obras deben ser libres. </p> + +<p>En esas áreas lo que tiene sentido es pedir a la gente que done dinero a los +<em>proyectos</em> destinados a realizar la obra <em>que proponen</em>. Ese +sistema es muy simple.</p> + +<p>La Free Software Foundation pide donaciones de dos tipos. Pedimos <a +href="https://my.fsf.org/donate/">donaciones genéricas para financiar el +trabajo de la fundación</a> y <a href="https://my.fsf.org/donate +/directed-donations">donaciones específicas para proyectos +concretos</a>. Otras organizaciones de software libre también lo hacen así.</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.es.html" --> +<div id="footer"> +<div class="unprintable"> + +<p>Envíe sus consultas acerca de la FSF y GNU a <a +href="mailto:gnu@gnu.org"><gnu@gnu.org></a>. Existen también <a +href="/contact/">otros medios para contactar</a> con la FSF. <br /> Para +avisar de enlaces rotos y proponer otras correcciones o sugerencias, +diríjase a <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>. --> +El equipo de traductores al español se esfuerza por ofrecer traducciones +fieles al original y de buena calidad, pero no estamos libres de cometer +errores.<br /> Envíe sus comentarios y sugerencias sobre las traducciones a +<a +href="mailto:web-translators@gnu.org"><web-translators@gnu.org></a>. +</p><p>Consulte la <a href="/server/standards/README.translations.html">Guía +para las traducciones</a> para obtener información sobre la coordinación y +el envío de traducciones de las páginas de este sitio web.</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>Esta página está bajo licencia <a rel="license" +href="http://creativecommons.org/licenses/by-nd/4.0/deed.es_ES">Creative +Commons Reconocimiento-SinObraDerivada 4.0 Internacional</a>.</p> + +<!--#include virtual="/server/bottom-notes.es.html" --> +<div class="translators-credits"> + +<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.--> + </div> + +<p class="unprintable"><!-- timestamp start --> +Última actualización: + +$Date: 2020/01/15 12:36:19 $ + +<!-- timestamp end --> +</p> +</div> +</div> +</body> +</html> |