path: root/talermerchantdemos/blog/articles/es/funding-art-vs-funding-software.html

<!--#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>