diff options
Diffstat (limited to 'talermerchantdemos/blog/articles/es/limit-patent-effect.html')
-rw-r--r-- | talermerchantdemos/blog/articles/es/limit-patent-effect.html | 217 |
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. 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. 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"><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 © 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> |