summaryrefslogtreecommitdiff
path: root/talermerchantdemos/blog/articles/es/funding-art-vs-funding-software.html
diff options
context:
space:
mode:
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.html215
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.&nbsp;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">&lt;gnu@gnu.org&gt;</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">&lt;webmasters@gnu.org&gt;</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">
+
+ &lt;web-translators@gnu.org&gt;</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">&lt;web-translators@gnu.org&gt;</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 &copy; 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>