summaryrefslogtreecommitdiff
path: root/talermerchantdemos/blog/articles/es/limit-patent-effect.html
diff options
context:
space:
mode:
Diffstat (limited to 'talermerchantdemos/blog/articles/es/limit-patent-effect.html')
-rw-r--r--talermerchantdemos/blog/articles/es/limit-patent-effect.html217
1 files changed, 217 insertions, 0 deletions
diff --git a/talermerchantdemos/blog/articles/es/limit-patent-effect.html b/talermerchantdemos/blog/articles/es/limit-patent-effect.html
new file mode 100644
index 0000000..6568b0e
--- /dev/null
+++ b/talermerchantdemos/blog/articles/es/limit-patent-effect.html
@@ -0,0 +1,217 @@
+<!--#set var="ENGLISH_PAGE" value="/philosophy/limit-patent-effect.en.html" -->
+
+<!--#include virtual="/server/header.es.html" -->
+<!-- Parent-Version: 1.79 -->
+
+<!-- This file is automatically generated by GNUnited Nations! -->
+<title>Cómo proteger el software frente a las patentes - Proyecto GNU - Free
+Software Foundation</title>
+
+<!--#include virtual="/philosophy/po/limit-patent-effect.translist" -->
+<!--#include virtual="/server/banner.es.html" -->
+<h2>Cómo proteger el software frente a las patentes</h2>
+
+<p>por <a href="http://www.stallman.org/"><strong>Richard Stallman</strong></a></p>
+
+<p><em>Una versión de este artículo se publicó inicialmente en <a
+href="http://www.wired.com/opinion/2012/11/richard-stallman-software-patents/"><cite>Wired</cite></a>
+en noviembre de 2012.</em></p>
+
+<p>Las patentes son una amenaza para todo desarrollador de software, y las
+guerras de patentes que durante tanto tiempo hemos temido ya han
+estallado. Los desarrolladores y los usuarios de software, que en nuestra
+sociedad constituyen la mayoría, necesitan que el software esté libre de
+patentes.</p>
+
+<p>A las patentes que nos amenazan, a menudo se las llama «patentes de
+software», pero este término es engañoso, pues tales patentes no se refieren
+a programas concretos, sino que cada patente describe alguna idea práctica y
+dice que a cualquiera que aplique esa idea se lo puede demandar. Por eso
+resulta más claro llamarlas «patentes de ideas computacionales».</p>
+
+<p>El sistema de patentes estadounidense no califica las patentes de manera que
+se pueda decir que esta es una «patente de software» y aquella no lo es. Son
+los desarrolladores de software los que distinguen entre las patentes que
+suponen una amenaza para ellos (las que cubren ideas que pueden
+implementarse en software) y las demás. Por ejemplo, si la idea patentada es
+el diseño de una estructura física o una reacción química, ningún programa
+puede implementar esa idea, por lo que esa patente no representa ninguna
+amenaza para el área del software. Pero si la idea patentada es un cómputo,
+los desarrolladores y usuarios de software están en el punto de mira de esa
+patente.</p>
+
+<p>Esto no quiere decir que las patentes de ideas computacionales prohíben solo
+software. Esas ideas también pueden implementarse en hardware, y así ha sido
+en muchos casos. La patente normalmente cubre las implementaciones de la
+idea en hardware <em>y</em> en software.</p>
+
+<h3>El problema particular del software</h3>
+
+<p>Las patentes sobre las ideas computacionales ocasionan un problema
+particular en el área del software, donde es fácil implementar miles de
+ideas a la vez en un programa. Si el diez por ciento están patentadas, el
+programa queda bajo la amenaza de cientos de patentes.</p>
+
+<p>Cuando Dan Ravicher, de la <cite>Public Patent Foundation</cite>, estudió en
+2004 un programa grande (Linux, que es el núcleo del sistema operativo <a
+href="/gnu/gnu-linux-faq.html">GNU/Linux</a>), encontró 283 patentes
+estadounidenses que parecían cubrir ideas computacionales implementadas en
+el código fuente de ese programa. Ese mismo año, una revista estimó que
+Linux representaba el 0,25% de todo el sistema GNU/Linux. Multiplicando 300
+por 400, el orden de magnitud del resultado indica que el sistema en su
+conjunto se encontraba <em>amenazado por alrededor de cien mil
+patentes</em>.</p>
+
+<p>Si se eliminara la mitad de esas patentes por «mala calidad» (es decir, por
+errores del sistema de patentes), eso no cambiaría mucho las cosas. Sean
+cien mil o cincuenta mil, el desastre es el mismo. Por eso es un error
+reducir nuestra crítica del sistema de patentes a los «<cite>trolls</cite>»
+de patentes o a las patentes de «mala calidad». Apple, que no es un «troll»
+según la definición común del término, en
+la actualidad es la empresa más agresiva cuando se sirve de sus patentes
+para atacar. No sé si las patentes de Apple son de «buena calidad», pero
+cuanto mejor sea su «calidad», más peligrosas serán.</p>
+
+<p>Hemos de resolver todo el problema, no solo una parte.</p>
+
+<p>Para corregir este problema por la vía legislativa generalmente se sugiere
+cambiar los criterios para la concesión de patentes. Por ejemplo, prohibir
+la emisión de patentes sobre prácticas computacionales y sistemas para
+aplicarlas. Este planteamiento tiene dos inconvenientes.</p>
+
+<p>En primer lugar, los abogados especialistas en patentes reformulan
+hábilmente las patentes para que encajen en cualquiera de las normas que
+pudieran resultar pertinentes, y transforman en un requisito meramente
+formal todo intento de limitar la patente de manera sustancial. Por ejemplo,
+muchas patentes estadounidenses sobre ideas computacionales describen un
+sistema que incluye una unidad de procesamiento aritmético, un secuenciador
+de instrucciones, una memoria y unos controles para llevar a cabo un cálculo
+concreto. Esta es una manera peculiar de describir un ordenador que ejecuta
+un programa para realizar alguna operación. Se formuló de esta manera para
+hacer que la solicitud de la patente satisficiera los criterios que durante
+algún tiempo se creyó que mantenía el sistema de patentes estadounidense.</p>
+
+<p>En segundo lugar, en EE.&nbsp;UU. existen ya miles de patentes sobre ideas
+computacionales, y cambiar los criterios para evitar que se sigan emitiendo
+no nos libraría de las ya existentes. Tendríamos que esperar casi veinte
+años para que, con la expiración de dichas patentes, se solucionara el
+problema. Podríamos imaginar que se legislara la abolición de las patentes
+en vigor, pero eso probablemente sea inconstitucional. (El Tribunal Supremo
+ha insistido perversamente en que el Congreso puede ampliar los privilegios
+privados a costa de los derechos colectivos, pero que no puede hacerse en el
+sentido contrario.)</p>
+
+<h3>Otra forma de abordar el problema: limitar el efecto, no la patentabilidad</h3>
+
+<p>Lo que yo sugiero es cambiar el <em>efecto</em> de las patentes. Debemos
+legislar para que el desarrollo, la distribución y la ejecución de un
+programa no constituyan infracción de patentes. Esta solución tiene varias
+ventajas:</p>
+
+<ul>
+<li>No exige que se clasifiquen las patentes o solicitudes de patentes como
+«software» o «no software».</li>
+<li>Proporciona a desarrolladores y usuarios protección frente a las patentes
+sobre ideas computacionales actuales y futuras.</li>
+<li>Los abogados especialistas en patentes no pueden evitar el efecto que se
+pretende redactando las solicitudes de manera diferente.</li>
+</ul>
+
+<p>Esta solución no invalida por completo las patentes sobre ideas
+computacionales existentes, pues seguirían siendo aplicables a las
+implementaciones que utilicen hardware con un propósito específico. Hace
+unos años se aprobó en EE.&nbsp;UU. una ley que protegía a los cirujanos
+frente a pleitos sobre patentes, de modo que incluso si un procedimiento
+quirúrgico está patentado, los cirujanos están a salvo.</p>
+
+<p>Los desarrolladores y usuarios de software necesitan protección frente a las
+patentes. Esta es la única solución legislativa que proporcionaría
+protección completa para todos. Entonces podríamos volver a competir y
+cooperar sin miedo a que nadie echara por tierra nuestro trabajo.</p>
+
+<p><em>Véase también: <a href="/philosophy/patent-reform-is-not-enough.html">La
+reforma de las patentes no es suficiente</a></em></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; 2012, 2013, 2015, 2016 Free Software Foundation, Inc.</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.-->
+ <strong>Traducción: Javier Fdez. Retenaga, 2020.</strong> Revisión: Equipo
+de traductores al español de GNU.</div>
+
+<p class="unprintable"><!-- timestamp start -->
+Última actualización:
+
+$Date: 2020/06/02 09:00:53 $
+
+<!-- timestamp end -->
+</p>
+</div>
+</div>
+</body>
+</html>