summaryrefslogtreecommitdiff
path: root/talermerchantdemos/blog/articles/es/software-patents.html
diff options
context:
space:
mode:
Diffstat (limited to 'talermerchantdemos/blog/articles/es/software-patents.html')
-rw-r--r--talermerchantdemos/blog/articles/es/software-patents.html1290
1 files changed, 1290 insertions, 0 deletions
diff --git a/talermerchantdemos/blog/articles/es/software-patents.html b/talermerchantdemos/blog/articles/es/software-patents.html
new file mode 100644
index 0000000..35c35db
--- /dev/null
+++ b/talermerchantdemos/blog/articles/es/software-patents.html
@@ -0,0 +1,1290 @@
+<!--#set var="ENGLISH_PAGE" value="/philosophy/software-patents.en.html" -->
+
+<!--#include virtual="/server/header.es.html" -->
+<!-- Parent-Version: 1.90 -->
+
+<!-- This file is automatically generated by GNUnited Nations! -->
+<title>Patentes de software - Proyecto GNU - Free Software Foundation</title>
+
+<!--#include virtual="/philosophy/po/software-patents.translist" -->
+<!--#include virtual="/server/banner.es.html" -->
+<h2>Patentes de software: Un obstáculo para el desarrollo de software</h2>
+
+<p>por <strong>Richard Stallman</strong></p>
+
+<p>
+<i>Esta es la transcripción de una charla impartida por Richard Stallman el
+25 de marzo de 2002 en el <a href="http://www.cl.cam.ac.uk/">Laboratorio de
+Informática</a> de la Universidad de Cambridge, organizada por la <a
+href="http://www.fipr.org/"><cite>Foundation for Information Policy
+Research</cite></a>. Transcripción y <a
+href="http://audio-video.gnu.org/audio/#patent-cambridge-2002-03-25">grabación</a>
+realizadas por Nicholas Hill. La versión original se encuentra en <a
+href="http://www.cl.cam.ac.uk/~mgk25/stallman-patents.html">
+http://www.cl.cam.ac.uk/~mgk25/stallman-patents.html</a> (preparación de la
+página y enlaces realizados por Markus Kuhn).</i>
+</p>
+
+
+<p>
+Posiblemente estén familiarizados con mi trabajo en el <a
+href="/philosophy/free-sw.html">software libre</a>. Esta charla no trata
+sobre eso. Trata sobre una forma de <a
+href="https://web.archive.org/web/20150329103351/http://www.progfree.org/Patents/against-software-patents.html">abuso
+legal</a> que convierte el desarrollo de software en una actividad
+peligrosa. Trata acerca de lo que sucede cuando la ley de patentes se aplica
+al campo del software.
+</p>
+
+<p>
+Que se patente el software no es la cuestión. Esa es una manera engañosa de
+describir el asunto, pues el problema no es que se patenten programas
+individuales. Si así fuera, carecería de importancia, sería algo básicamente
+inocuo. Lo que sucede es que se patentan ideas. Toda patente cubre alguna
+idea. Las <a
+href="https://web.archive.org/web/20150329143651/http://progfree.org/Patents/patents.html">patentes
+de software</a> son patentes que cubren ideas que tienen que ver con el
+software, ideas que pueden usarse para desarrollar software. Es eso lo que
+las convierte en peligrosos obstáculos para el desarrollo de software.
+</p>
+
+<p>
+Probablemente hayan oído una expresión engañosa, «<a
+href="http://www.wipo.org/about-ip/en/">propiedad intelectual</a>». Como
+pueden ver, es una expresión sesgada. Da por sentado que, sea cual fuere la
+cosa de la que se está hablando, ha de considerarse como un tipo de
+propiedad, cuando en realidad esa es solo una entre muchas otras
+posibilidades. Con la expresión «propiedad intelectual» se prejuzga lo más
+básico en cualquier ámbito que se esté considerando. No contribuye a pensar
+de forma clara y con amplitud de miras.
+</p>
+
+<p>
+Existe otro problema que no tiene nada que ver con fomentar ningún punto de
+vista en particular, y es que constituye un obstáculo a la comprensión de
+los hechos. La expresión «propiedad intelectual» es un cajón de sastre en el
+que se incluyen campos legislativos completamente dispares, como por ejemplo
+la ley de copyright y la ley de patentes, que son totalmente
+distintas. Todos sus aspectos son diferentes. Mete también en el mismo saco
+las marcas, que difieren aún más, y varias otras cosas que aparecen con
+mayor o menor frecuencia. Ninguna de ellas tiene nada en común con las
+demás. Históricamente, sus orígenes no tienen ninguna relación.
+Esas leyes se diseñaron de manera independiente y cubrían diferentes
+actividades y aspectos de la vida, lo que dio lugar a medidas políticas sin
+ninguna relación entre sí. Si intentamos analizarlas metiéndolas todas en el
+mismo saco, seguramente llegaremos a conclusiones disparatadas. No se puede
+tener ninguna opinión sensata y lúcida en absoluto acerca de la «propiedad
+intelectual». Si queremos pensar con claridad, no las mezclemos. Analicemos
+el copyright y luego las patentes. Estudiemos la ley de copyright y
+estudiemos la ley de patentes por separado.
+</p>
+
+<p>
+Por citar algunas de las mayores diferencias entre el copyright y las
+patentes: el copyright cubre la expresión particular de una obra, no cubre
+ninguna idea; las patentes solo cubren ideas y el uso de ideas; el copyright
+se aplica automáticamente; las patentes son emitidas por una oficina de
+patentes, previa solicitud.
+</p>
+
+<p>
+Las patentes cuestan mucho dinero. Es mayor incluso el precio que hay que
+pagar a los abogados para que redacten la solicitud que lo que hay que
+abonar al presentarla. Normalmente la solicitud tarda algunos años en ser
+estudiada, aun cuando las oficinas de patentes las examinan de manera muy
+descuidada.
+</p>
+
+<p>
+El copyright dura muchísimo tiempo. En algunos casos puede durar hasta 150
+años. Las patentes, por el contrario, duran 20 años, lo cual no es tanto
+como para que sobrevivan a su titular, pero es demasiado para la escala
+temporal de un ámbito como el del software.
+</p>
+
+<p>
+Volvamos la vista veinte años atrás, cuando un PC era algo
+novedoso. Imaginemos que nos viéramos obligados a desarrollar software
+utilizando solo las ideas ya conocidas en 1982.
+</p>
+
+<p>
+El copyright cubre la copia. Si alguien escribe una novela que resulta ser
+idéntica, palabra por palabra, a <i>Lo que el viento se llevó</i> y puede
+demostrar que nunca antes había visto <i>Lo que el viento se llevó</i>, eso
+le serviría para defenderse ante cualquier acusación de infracción de
+copyright.
+</p>
+
+<p>
+Una patente es un monopolio absoluto sobre el uso de una idea. Aun cuando
+alguien pueda probar que concibió la idea por sí mismo, no serviría de nada
+si la idea ya ha sido patentada por otra persona.
+</p>
+
+<p>
+Espero que durante el resto de esta charla se olviden del copyright, ya que
+esta charla trata acerca de las patentes y nunca hay que meter en el mismo
+saco las patentes y el copyright. Se trata de que comprendan estas
+cuestiones legales. Imaginen cuál sería su comprensión de la química
+aplicada si no supieran distinguir entre el agua y el etanol.
+</p>
+
+<p>
+Cuando alguien nos habla del sistema de patentes, normalmente lo hace desde
+el punto de vista de quien espera obtener una patente. Nos cuenta lo que se
+consigue al obtener una patente, cómo sería si pudiéramos ir por la calle
+con una patente en el bolsillo y, de vez en cuando, apuntar a alguien con
+ella y decirle: «¡Deme su dinero!». Este sesgo tiene su razón de ser, y es
+que la mayoría de la gente que le hablará acerca de este sistema de patentes
+tiene intereses en él, y quiere que a usted le guste.
+</p>
+
+<p>
+Hay otra razón, y es que el sistema de patentes es como una lotería, pues
+solo una ínfima parte de las patentes reportan algún beneficio a quienes las
+poseen. De hecho, en cierta ocasión <cite><a
+href="https://www.economist.com/leaders/2011/08/20/patent-medicine">The
+Economist</a></cite> se refirió a él como «una lotería que requiere mucho
+tiempo». Si hemos visto anuncios de lotería, habremos observado que siempre
+nos invitan a pensar en lo que sucedería si ganáramos. No nos invitan a
+pensar en perder, aun cuando esto es mucho más probable. Lo mismo sucede con
+la publicidad del sistema de patentes. Siempre nos invitan a pensar en lo
+que sucederá si somos nosotros los que ganamos.
+</p>
+
+<p>
+Para compensar este punto de vista sesgado, voy a describir el sistema de
+patentes desde el punto de vista de sus víctimas. Es decir, desde el punto
+de vista de alguien que quiere desarrollar software pero está obligado a
+vérselas con un sistema de patentes de software que podría conducir a una
+demanda judicial.
+</p>
+
+<p>
+Veamos, ¿qué es lo primero que habría que hacer una vez que se tiene una
+idea del tipo de programa que se va a escribir? Lo primero que quizá se
+quiera hacer para lidiar con el sistema de patentes es descubrir qué
+patentes pueden cubrir el programa que se quiere escribir. Pero esto es
+imposible. La razón de ello es que algunas de las solicitudes de patente que
+están pendientes son secretas. Pueden publicarse después de cierto tiempo,
+por ejemplo 18 meses. Pero eso es tiempo suficiente para escribir el
+programa e incluso publicarlo, sin saber que va a haber una patente y que
+nos van a presentar una demanda.
+Esto no es una mera hipótesis. En 1984 se escribió el programa Compress, un
+programa para la compresión de datos. En aquel momento no había ninguna
+patente para el algoritmo de compresión LZW que utilizaba. Más tarde, en
+1985, EE.&nbsp;UU. emitió una patente sobre este algoritmo, y durante los
+años siguientes los que distribuían el programa Compress empezaron a recibir
+amenazas. No había forma de que el autor de Compress se hubiera dado cuenta
+de que podía ser demandado. Todo lo que hizo fue usar una idea que encontró
+en una revista, como siempre han hecho los programadores. No se dio cuenta
+de que ya no se podían usar sin peligro las ideas que se encontraban en una
+revista.
+</p>
+
+<p>
+Dejemos a un lado este problema... La oficina de patentes publica las
+patentes emitidas, de modo que se puede consultar toda su larga lista y ver
+exactamente lo que dicen. Pero, por supuesto, no sería posible leer la lista
+entera porque son demasiadas. En EE.&nbsp;UU. hay cientos de miles de
+patentes de software.
+</p>
+
+<p>
+No hay manera de examinarlas todas. Habría que tratar de encontrar las que
+sean relevantes. Hay quien dirá que eso debería ser sencillo en estos
+tiempos modernos en que disponemos de ordenadores. Se podría buscar por
+palabras clave, etc. Pero eso solo funciona hasta cierto punto. Así se
+encontrarán algunas patentes relevantes, pero no necesariamente
+todas. Había, por ejemplo, una patente de software, que quizá haya ya
+expirado, sobre el «cálculo del orden natural» en las hojas de cálculo.
+Esto significa básicamente que cuando se hace que ciertas celdas dependan de
+otras todo se vuelve a calcular en función de aquello de lo que depende, de
+modo que después de una operación de cálculo todo queda actualizado. Las
+primeras hojas de cálculo hacían sus operaciones de arriba a abajo, de
+manera que si se hacía que una celda dependiera de otra situada más abajo, y
+esto se repetía varias veces, había que recalcular todo varias veces para
+que los nuevos valores se extendieran hacia arriba. Había que disponer los
+elementos de manera que dependieran de las celdas superiores.
+Entonces alguien pensó que por qué no realizar las operaciones de cálculo de
+modo que cada elemento se calcule en función del elemento del que
+depende. Este algoritmo se conoce como clasificación topológica. La primera
+referencia a él que he podido encontrar es de 1963. La patente cubría varias
+docenas de maneras diferentes de implementar la clasificación topológica,
+pero no se podría haber encontrado esta patente buscando «hoja de
+cálculo». Tampoco buscando «orden natural» o «clasificación topológica». En
+ella no aparecían estos términos. Se describía como un método de compilar
+fórmulas en código objeto. La primera vez que lo vi pensé que no era esa la
+patente que buscaba.
+</p>
+
+<p>
+Supongamos que disponemos de una lista de patentes y queremos saber qué nos
+está prohibido. Al tratar de estudiar estas patentes descubriremos que es
+demasiado complicado entenderlas, ya que están escritas en un lenguaje legal
+muy enrevesado cuyo significado es difícil comprender. Lo que dicen las
+oficinas de patentes a menudo no significa lo que parece significar.
+</p>
+
+<p>
+En los años ochenta, el Gobierno australiano realizó un estudio del sistema
+de patentes. Concluyó que, aparte de la presión internacional, no había
+razones para disponer de un sistema de patentes. No ofrecía ningún beneficio
+para la sociedad, y recomendaba abolirlo de no ser por la presión
+internacional. Uno de los hechos que se señalaron fue que los ingenieros ni
+siquiera intentan leer las patentes para averiguar algo, ya que resulta
+demasiado complicado comprenderlas. Citaban a un ingeniero que decía: «No
+logro reconocer mis propias invenciones en las patentes».
+</p>
+
+<p>
+Esto no es una simple teoría. Hacia 1990, un programador llamado <a
+href="http://www.atarimagazines.com/startv2n3/hypercard.html">Paul
+Heckel</a> demandó a Apple alegando que Hypercard infringía dos de sus
+patentes. Cuando vio Hypercard por primera vez, no pensó que tuviera nada
+que ver con sus patentes, con sus «invenciones». No se parecían. Pero cuando
+su abogado le dijo que se podía interpretar que las patentes se aplicaban a
+una parte de Hypercard, decidió atacar a Apple.
+Cuando di una charla sobre esto en Stanford, él estaba entre el público y
+dijo, «Eso <a
+href="http://www.swiss.ai.mit.edu/6805/articles/int-prop/heckel-debunking.html">no
+es verdad</a>, ¡yo simplemente no entendía el alcance de mi protección!». Y
+yo le contesté, «Sí, eso es lo que yo estaba diciendo». De manera que habría
+que dedicar mucho tiempo a hablar con abogados para hacerse una idea de lo
+que esas patentes prohíben hacer.
+Al final dirán algo así: «Si haces esto, seguro que pierdes; si haces
+aquello, hay serias posibilidades de que pierdas, y si de verdad quieres
+estar a salvo, mantente al margen de esta área. Y, por cierto, el azar juega
+un importante papel en el resultado de cualquier proceso judicial».
+</p>
+
+<p>
+Ahora que conocemos el terreno que pisamos para hacer negocios(!), ¿qué
+haremos? Bien, hay tres formas de afrontar la cuestión, y todas son
+aplicables en ciertos casos.
+</p>
+
+<p>Son las siguientes:</p>
+
+<ol>
+<li>Evitar la patente</li>
+<li>Obtener la licencia de la patente</li>
+<li>Revocar la patente en los tribunales</li>
+</ol>
+
+<p>
+Describiré estas tres soluciones y lo que las hace viables o inviables.
+</p>
+
+<h3>1) Evitar la patente</h3>
+
+<p>
+Esto significa no utilizar la idea que está cubierta por la patente, lo cual
+puede ser fácil o difícil según la idea de que se trate. En algunos casos,
+lo que se patenta es una funcionalidad, de modo que la patente se evita no
+implementando esa funcionalidad. Entonces la cuestión es cuán importante es
+esa funcionalidad. En algunos casos, se puede prescindir de ella. Hace algún
+tiempo, los usuarios del procesador de textos XyWrite recibieron una
+actualización regresiva por correo. La actualización eliminaba una
+funcionalidad que permitía predefinir abreviaturas. Es decir, cuando se
+escribía una abreviatura seguida de un signo de puntuación, se reemplazaba
+inmediatamente por la secuencia de caracteres completa.
+De ese modo se podía asignar una abreviatura para alguna frase larga,
+escribir la abreviatura y entonces en el documento aparecía la frase
+entera. Ellos me escribieron sobre esto porque sabían que el editor <a
+href="/software/emacs/">Emacs</a> tiene una funcionalidad similar. De hecho,
+la tiene desde los años setenta. Fue interesante, porque me hizo ver que
+había tenido al menos una idea patentable en mi vida. ¡Supe que era
+patentable porque otra persona la patentó después! De hecho, habían probado
+los tres enfoques.
+Primero intentaron negociar con el titular de la patente, pero resultó que
+este no negociaba de buena fe. Luego se plantearon si podrían tener alguna
+oportunidad de invalidar la patente. Y finalmente decidieron eliminar esa
+funcionalidad del programa. Se puede vivir sin ella. Si el procesador de
+texto solo carece de esta funcionalidad, quizá la gente lo use igualmente,
+pero si se empiezan a eliminar varias funcionalidades, al final la gente
+pensará que el programa no es muy bueno y probablemente lo rechace. En este
+caso se trataba de una patente bastante limitada sobre una funcionalidad muy
+específica.
+</p>
+
+<p>
+Pero, ¿qué se puede hacer con relación a la <a
+href="https://patents.justia.com/patent/4873662">patente de British
+Telecom</a> sobre la navegación por hipervínculos mediante acceso
+telefónico? Hoy en día, la navegación por hipervínculos es absolutamente
+esencial en el uso corriente de los ordenadores. El acceso telefónico
+también es esencial. ¿Cómo arreglárselas sin esta funcionalidad que, por
+cierto, ni siquiera es una funcionalidad sino en realidad una combinación de
+dos funcionalidades yuxtapuestas de forma arbitraria? Es como tener una
+patente sobre un sofá y un televisor que estén en la misma habitación.
+</p>
+
+<p>
+A veces la idea patentada es tan amplia y básica que prácticamente abarca
+todo un campo. Por ejemplo, la idea de cifrado mediante clave pública, que
+fue patentada en EE.&nbsp;UU. La patente caducó en 1997. Hasta entonces,
+obstruyó enormemente el uso de ese tipo de cifrado en EE.&nbsp;UU. Un buen
+número de programas que la gente empezaba a desarrollar se vieron
+frustrados. Nunca llegaron a estar verdaderamente disponibles debido a las
+amenazas de los propietarios de las patentes.
+Posteriormente apareció un programa, <a href="http://www.pgpi.org/">PGP</a>,
+que inicialmente se publicó como software libre. Al parecer, los titulares
+de las patentes se proponían atacar, pero se dieron cuenta de que eso podría
+crearles muy mala imagen. De modo que impusieron restricciones, limitándolo
+solo a usos no comerciales, lo que significaba que no podría hacerse muy
+popular. De esta manera, limitaron fuertemente el uso del cifrado mediante
+clave pública durante una década o más. No había alternativas a esa
+patente. No se podía hacer nada más.
+</p>
+
+<p>
+A veces se patenta un algoritmo determinado. Por ejemplo, existe una patente
+sobre una versión optimizada de la transformada rápida de Fourier (<abbr
+title="Fast Fourier Transform">FFT</abbr>), que funciona el doble de
+rápido. Es posible evitarla utilizando en el programa la FFT ordinaria. Esa
+parte del programa tardará el doble de tiempo en ejecutarse. Quizás eso no
+tenga gran importancia, quizá represente una pequeña parte del tiempo de
+ejecución del programa, quizá ni siquiera se note que es el doble de
+lento. O quizás el programa no funcione en absoluto si le lleva el doble de
+tiempo hacer su tarea. Los efectos varían.
+</p>
+
+<p>
+En algunos casos se puede encontrar un algoritmo mejor. Esto podría ser
+bueno o no. Como no podíamos usar Compress, en el proyecto GNU empezamos a
+buscar algún algoritmo alternativo para la compresión de datos. Alguien nos
+escribió diciendo que tenía uno. Había escrito un programa y decidió
+ofrecérnoslo. Íbamos ya a publicarlo cuando por casualidad hojeé un ejemplar
+del New York Times en el que aparecía la columna semanal sobre patentes (no
+solía hojear el Times más que una vez cada varios meses). Así que le eché un
+vistazo, y decía que alguien había conseguido una patente por «inventar un
+nuevo método de compresión de datos».
+Pensé que habría que echarle un vistazo a esa patente. Conseguí una copia y
+resultó que cubría el programa que íbamos a publicar en tan solo una
+semana. Ese programa murió antes de nacer. Más adelante encontramos otro
+algoritmo que no estaba patentado. Este se convirtió en el programa <a
+href="/software/gzip/"> gzip</a>, que ahora es el estándar de facto para la
+compresión de datos. Como algoritmo para utilizar en un programa de
+compresión de datos estaba muy bien. Cualquiera que quisiera comprimir
+datos podía utilizar gzip en lugar de compress. Pero el mismo algoritmo
+patentado de compresión LZW se utilizaba también en formatos de imagen tales
+como <a href="/philosophy/gif.html">GIF</a>.
+Y como en este caso lo que se quería hacer no era simplemente comprimir
+datos, sino elaborar una imagen que cualquiera pudiera visualizar con su
+software, resultaba extremadamente complicado cambiar a un algoritmo
+diferente. ¡Durante diez años no hemos podido hacerlo! Tan pronto como
+empezaron a llegar amenazas judiciales por usar archivos GIF, se comenzó a
+utilizar el algoritmo de gzip para definir <a
+href="http://www.w3.org/Graphics/PNG/">otro formato de imagen</a>. Cuando
+empezamos a pedir que se abandonara el uso de archivos GIF en favor de este
+otro formato, nos respondían: «No podemos cambiar, los navegadores no
+admiten todavía el nuevo formato». Y los desarrolladores de navegadores
+decían: «No tenemos ninguna prisa. Después de todo, nadie utiliza este nuevo
+formato».
+</p>
+
+<p>
+De hecho, la inercia en el uso del formato GIF era tan grande que no pudimos
+lograr que se cambiara. En la práctica, el uso del formato GIF por parte de
+la comunidad todavía sigue llevando a que los sitios web utilicen ese
+formato, con el resultado de que son vulnerables a las amenazas.
+</p>
+
+<p>
+En realidad la situación es todavía más grotesca. Hay de hecho dos patentes
+que cubren el algoritmo de compresión LZW. La oficina de patentes ni
+siquiera se dio cuenta de que estaban concediendo dos patentes sobre la
+misma cosa. No estaba al tanto, y hay un motivo para ello: hay que dedicar
+una buena cantidad de tiempo al estudio de estas dos patentes para darse
+cuenta de que en realidad cubren lo mismo.
+</p>
+
+<p>
+Si fueran patentes sobre procesos químicos, sería mucho más fácil. Se podría
+verificar qué sustancias se están empleando, qué se introduce, qué se
+obtiene y qué acciones físicas se llevan a cabo. Sea cual sea su
+descripción, se comprobaría en qué consisten esos procesos y se vería que
+son similares.
+</p>
+
+<p>
+Si algo es puramente matemático, existen muchas maneras muy diferentes de
+describirlo. Su similitud no se aprecia a simple vista. Hay que
+comprenderlas muy bien para apreciar que se refieren a lo mismo, y la
+oficina de patentes no tiene tiempo para hacerlo. Hace algunos años, la
+Oficina de Patentes de EE.&nbsp;UU. empleaba una media de 17 horas por
+patente. No es tiempo suficiente para examinarlas cuidadosamente, de modo
+que comenten errores como este, por supuesto. Ya les he hablado del programa
+que murió antes de nacer. También sobre ese algoritmo se habían emitido en
+EE.&nbsp;UU. dos patentes. Por lo que se ve, no es nada inusual.
+</p>
+
+<p>
+Evitar las patentes puede ser fácil, o imposible. Puede ser fácil, pero el
+programa puede acabar resultando inútil. Depende de la situación.
+</p>
+
+<p>
+Hay otra cuestión que debo mencionar. A veces una empresa o un consorcio
+puede hacer que un formato o protocolo sea el estándar de facto. En tal
+caso, si ese formato o protocolo se patenta es un auténtico desastre. Hay
+incluso estándares oficiales que están restringidos por patentes. El pasado
+mes de septiembre se produjo un gran revuelo político cuando el <a
+href="http://www.w3.org/TR/patent-practice"><cite>World Wide Web
+Consortium</cite></a> propuso que se empezaran a adoptar estándares
+cubiertos por patentes. La comunidad protestó y se retractaron.
+Se echaron atrás e insistieron en que cualquiera debería poder implementar
+libremente cualquier patente y en que los estándares tenían que ser libres
+para que cualquiera los implementara. Es una victoria interesante. Creo que
+ha sido la primera vez en que una organización de estándares ha tomado esta
+decisión. Es habitual que los organismos de normalización estén dispuestos a
+añadir a un estándar algo restringido por patentes, de modo que a la gente
+no se le permita implementarlo libremente. Tenemos que dirigirnos a otros
+organismos de normalización y reclamarles que cambien sus reglas.
+</p>
+
+<h3>2) Obtener la licencia de la patente</h3>
+
+<p>
+La segunda posibilidad consiste en conseguir una licencia para la patente,
+en lugar de evitarla. Esta no es necesariamente una opción. El titular de la
+patente no tiene por qué ofrecernos una licencia, no está obligado a
+hacerlo. Hace diez años, alguien cuyo pequeño negocio familiar consistía en
+la fabricación de máquinas tragamonedas para los casinos (que ya entonces
+usaban ordenadores) envió una carta a la Liga para la Libertad de
+Programación en la que solicitaba ayuda porque había recibido una amenaza de
+otra empresa que decía que ellos tenían la patente: «Usted no está
+autorizado a fabricar estas cosas. Cierre su negocio».
+</p>
+
+<p>
+Examiné esa patente. Cubría el montaje de una serie de ordenadores en red
+para jugar distintos juegos, de modo que cada ordenador disponía de más de
+un juego y permitía jugar a más de un juego a la vez.
+</p>
+
+<p>
+Ya ven que la oficina de patentes cree que es una idea brillante hacer
+cualquier cosa más de una vez. No se dan cuenta de que en informática esa es
+la forma más obvia de generalizar algo. Se ha hecho una vez y ahora se puede
+hacer cualquier número de veces, se puede escribir una subrutina. Creen que
+si alguien hace algo más de una vez, eso debe de significar que es un genio,
+que nadie puede llevarle la contraria y que tiene derecho a dar órdenes a
+todo el mundo. En cualquier caso, a esa persona no le ofrecieron la
+licencia. Tuvo que cerrar. Ni siquiera pudo afrontar el costo de acudir a
+los tribunales. Yo diría que esa patente concreta era una idea obvia. Es
+posible que un juez hubiera pensado lo mismo, pero nunca lo sabremos porque
+esa persona no se pudo permitir ir a juicio.
+</p>
+
+<p>
+No obstante, muchos titulares de patentes sí ofrecen licencias, pero a
+menudo piden mucho dinero por ellas. La compañía que concedía licencias para
+la patente sobre el recálculo en orden natural pedía un cinco por ciento de
+los ingresos brutos por cada hoja de cálculo vendida en EE.&nbsp;UU. Según
+me han dicho, ese era el precio reducido anterior al juicio. En caso de
+juicio, si el titular de la patente acaba ganando, exigirá más. Quizá uno
+pueda permitirse ese cinco por ciento por la licencia de una patente, pero
+¿y si para desarrollar el programa hiciera falta la licencia de veinte
+patentes? Pues en ese caso todo el dinero que se consiga se lo llevarán las
+patentes. ¿Y si hay que obtener la licencia de ventiuna patentes?
+</p>
+
+<p>
+La gente del sector me decía que, en la práctica, dos o tres licencias de
+esas harían inviable cualquier negocio.
+</p>
+
+<p>
+Hay una situación en la que obtener una licencia por el uso de la patente es
+una muy buena solución. Es lo que les ocurre a las megacorporaciones
+multinacionales. Como estas empresas poseen muchas patentes e intercambian
+licencias entre ellas, se libran de la mayor parte del daño que provoca el
+sistema de patentes y disfrutan de todas sus ventajas. IBM publicó un <a
+href="https://web.archive.org/web/20150329104135/http://progfree.org/Links/prep.ai.mit.edu/ibm.think.article">artículo</a>
+en la revista <cite>Think</cite> (creo que era el número cinco de 1990)
+acerca de su cartera de patentes, donde se decía que IBM obtenía dos tipos
+de beneficios de sus 9.000 patentes estadounidenses (hoy en día el número
+debe de ser aún mayor). Estos eran, en primer lugar, los ingresos por
+regalías, y en segundo lugar, el acceso a las patentes de otros. Decían que
+el segundo beneficio era mucho mayor que el primero. De tal modo que el
+beneficio obtenido por IBM al permitírsele utilizar las ideas patentadas por
+otros multiplicaba por diez el beneficio directo que obtenía por ofrecer
+licencias. ¿Qué significa esto en realidad?
+</p>
+
+<p>
+¿Cuál es el beneficio de IBM al tener acceso a las patentes de otros?
+Esencialmente es el beneficio de verse libre de los problemas que el sistema
+de patentes puede ocasionar. El sistema de patentes es como una lotería: con
+una patente determinada puede no ocurrir nada, suponer una gran cantidad de
+dinero para su titular o un desastre para todos los demás. Pero IBM es una
+empresa tan grande que le compensa. Pueden hacer una estimación general de
+las ventajas y desventajas del sistema de patentes.
+Para ellos, los problemas del sistema de patentes podrían haber sido diez
+veces mayores que las ventajas. Digo «podrían haber sido» porque mediante el
+intercambio de licencias IBM evita esos problemas. Los problemas son solo
+potenciales, en realidad no les afectan. Pero cuando evalúan los beneficios
+de evitarlos, su estimación es que de esa manera multiplican por diez el
+valor del dinero que obtienen por sus patentes.
+</p>
+
+<p>
+Este fenómeno del intercambio de licencias desmiente un mito muy común, el
+mito del «genio en la miseria», el mito de que las patentes «protegen» al
+«pequeño inventor». Estas son expresiones propagandísticas y no deberíamos
+emplearlas. Nos presentan la siguiente historia: imaginemos un brillante
+diseñador de lo que sea. Imaginemos que ha pasado años de privaciones en su
+ático diseñando algún nuevo y maravilloso prototipo y ahora quiere
+fabricarlo. ¿No es una vergüenza que las grandes empresas entren en
+competición con él, se queden con todo su negocio y él «se muera de hambre»?
+Debo señalar que aquellos que trabajan en sectores de alta tecnología
+normalmente no lo hacen por su cuenta, que las ideas no salen de la nada,
+sino que se apoyan en las ideas de otros, y que hoy por hoy esas personas
+tienen muchas oportunidades de conseguir un trabajo en caso de que lo
+necesiten. Así que este cuento, la posibilidad de que una idea brillante sea
+el fruto de esta brillante persona que trabaja sola, no es realista, al
+igual que la idea de que se encuentre en riesgo de pasar hambre. Pero sí es
+concebible que alguien tenga una idea que junto con otras cien o doscientas
+ideas pueda servir de base para la fabricación de algún tipo de producto, y
+que las grandes compañías puedan querer competir con esta persona.
+Veamos pues qué sucedería si esa persona intentara usar una patente para
+impedirlo. Él dirá: «Ah, no, IBM, no puedes competir conmigo. Tengo esta
+patente». E IBM responderá: «Veamos. Echemos un vistazo a tu
+producto. Mmmm. .. Yo tengo esta patente, y esta otra, y esta otra, y esta
+otra, y esta otra, y esta otra, que son infringidas por algunas partes de tu
+producto. Si crees que puedes luchar contra todas ellas en los tribunales,
+volveré y encontraré unas cuantas más. Así que, ¿por qué no intercambias
+licencias conmigo?». Y entonces el brillante pequeño inventor dirá: «Bueno,
+vale, intercambiemos licencias». Entonces podrá volver a su casa y fabricar
+ese maravilloso lo que sea, pero también IBM podrá hacerlo. IBM obtiene
+acceso a su patente y el derecho a competir con él, lo que significa que esa
+patente no lo «protegió» en absoluto. En realidad el sistema de patentes no
+sirve para eso.
+</p>
+
+<p>
+Las megacorporaciones se ven libres de la mayor parte del daño que ocasiona
+el sistema de patentes. Fundamentalmente disfrutan de sus ventajas, por eso
+quieren que existan patentes de software: son las únicas que se beneficiarán
+de ello. Pero si se es un pequeño inventor o se trabaja para una pequeña
+empresa, esa pequeña empresa no podrá hacerlo. Lo intentan, pero el problema
+es que no pueden conseguir una cantidad suficiente de patentes como para
+hacerlo. Toda patente apunta en una dirección determinada. De modo que si
+una pequeña empresa tiene patentes que apuntan aquí, ahí y allá, y alguien
+llega y le apunta con una patente diciendo: «Dame tu dinero», se ve
+indefensa..
+IBM puede hacerlo porque con esas 9.000 patentes apuntan a todas partes; no
+importa dónde estemos, probablemente haya una patente de IBM que apunte
+hacia nosotros. De modo que IBM casi siempre puede hacernos intercambiar
+licencias. Las empresas pequeñas rara vez pueden hacer que alguien
+intercambie licencias con ellas. Dicen que quieren las patentes con fines
+defensivos, pero no conseguirán las suficientes para poder defenderse.
+</p>
+
+<p>
+Hay casos en los que ni siquiera IBM puede hacer que alguien intercambie
+licencias con ella. Es lo que ocurre cuando hay una compañía cuyo único
+negocio es obtener patentes para sacarle dinero a la gente. La empresa que
+tenía la patente sobre el recálculo en orden natural era exactamente ese
+tipo de empresa. Su única actividad consistía en amenazar a la gente con
+demandas judiciales y sacarle dinero a quienes realmente estaban
+desarrollando algo.
+</p>
+
+<p>
+No hay patentes que cubran procedimientos legales. Supongo que los abogados
+comprenden lo penoso que sería tener que vérselas ellos mismos con el
+sistema de patentes. En consecuencia, no hay forma de obtener una patente
+para hacer que esa empresa intercambie licencias, lo que les permite ir por
+ahí exprimiendo a todo el mundo. Pero supongo que empresas como IBM calculan
+que eso es parte del precio que hay que pagar por hacer negocios, de manera
+que pueden vivir con ello.
+</p>
+
+<p>
+Así pues, esa es la opción de obtener la licencia de una patente, lo cual
+será posible o no, dependiendo de si uno puede permitírselo.
+</p>
+
+<h3>3) Revocar la patente en los tribunales</h3>
+
+<p>
+Supuestamente, para que algo se patente tiene que ser nuevo, útil y no
+obvio. Es el léxico usado en EE.&nbsp;UU. Creo que en otros países emplean
+términos diferentes que son prácticamente equivalentes. Por supuesto, cuando
+la oficina de patentes entra en juego, comienza por interpretar lo que es
+«nuevo» y «no obvio». «Nuevo» viene a significar «no lo tenemos en nuestros
+archivos» y «no obvio» suele significar «no obvio para alguien con un
+cociente intelectual de 50».
+</p>
+
+<p>
+Alguien que estudia la mayoría de las patentes de software emitidas en
+EE.&nbsp;UU. &mdash;o que al menos lo hacía, no sé si todavía puede con la
+cantidad que hay&mdash; decía que el 90% de ellas no pasaría el «test de
+Cristal City» [Cristal City es la zona de Washington donde se encuentra la
+oficina de patentes], con lo quería decir que si el personal de la oficina
+de patentes bajara al kiosco y adquiriera algunas revistas de informática,
+comprobaría que esas ideas ya se conocían.
+</p>
+
+<p>
+La oficina de patentes hace cosas tan obviamente estúpidas que ni siquiera
+es necesario estar al tanto de la tecnología más reciente para ver que son
+estúpidas. Esto no se limita al software. Una vez vi la famosa patente del
+ratón de Harvard, que se obtuvo mediante ingeniería genética inoculando un
+gen cancerígeno a una cepa de ratones. El gen cancerígeno ya era conocido y
+se inoculó empleando técnicas conocidas en una variedad de ratón ya
+conocida. La patente que obtuvieron cubría la inoculación de cualquier gen
+cancerígeno en cualquier tipo de mamífero empleando cualquier método. No
+hace falta saber nada de ingeniería genética para darse cuenta de que esto
+es ridículo.
+</p>
+
+<p>
+Me han dicho que estos excesos en las reivindicaciones son moneda corriente,
+y que la Oficina de Patentes de EE.&nbsp;UU. a veces invita a los
+solicitantes a ampliar aún más sus reivindicaciones. Básicamente, se trata
+de ampliar las reivindicaciones hasta que se sospeche que entran en colisión
+con alguna otra cosa que sin lugar a dudas es una técnica anterior. Este
+enfoque les permite calcular la tajada de espacio intelectual que pueden
+confiscar.
+</p>
+
+<p>
+Cuando los programadores echan un vistazo a las patentes de software, suelen
+decir: «¡Esto es ridículamente obvio!». Pero los burócratas de las patentes
+ponen todo tipo de pretextos para ignorar lo que piensan los
+programadores. Dicen: «¡Ah!, pero tienen que considerarlo teniendo en cuenta
+cuál era la situación hace diez o veinte años». Y descubrieron que
+repitiendo algo hasta la saciedad pueden hacer que uno acabe perdiendo el
+norte. Cualquier cosa puede parecer no obvia si se divide en partes cada vez
+más pequeñas y se analiza lo suficiente. Uno acaba perdiendo toda noción de
+obviedad, o al menos la capacidad de justificar cualquier criterio para
+discernir lo obvio de lo que no lo es. Luego, por supuesto, describen a
+todos los titulares de las patentes, sin excepción, como brillantes
+inventores. Por tanto, no podemos cuestionar su autoridad para decidir sobre
+lo que podemos o no podemos hacer.
+</p>
+
+<p>
+Si se va a juicio, los jueces tienden a ser un poco más estrictos acerca de
+lo que es obvio y lo que no lo es. El problema es que ir a juicio cuesta
+millones de dólares. Una vez oí hablar de un caso sobre patentes, recuerdo
+que la parte demandada era Qualcomm, y creo que el fallo fue finalmente de
+trece millones de dólares, cuya mayor parte se destinó a pagar a los
+abogados de ambas partes. Quedaron unos pocos millones de dólares para el
+demandante, ya que Qualcomm perdió.
+</p>
+
+<p>
+La validez de una patente depende en gran medida de circunstancias
+históricas. Las circunstancias son muchas, tales como qué es lo que se
+publicó exactamente y en qué fecha. Y de toda esa información, qué es lo que
+no se ha perdido y realmente se puede encontrar, como fechas concretas y
+cosas parecidas. Son muchas las circunstancias históricas que determinan si
+una patente es válida o no.
+
+De hecho, resulta extraño que la <a
+href="https://patents.justia.com/patent/4873662">patente de British Telecom
+sobre el seguimiento de hipervínculos mediante acceso telefónico</a> se
+solicitara, según creo, en 1975. Creo que fue en 1974 cuando por primera vez
+desarrollé el paquete info. Este paquete permite utilizar hipervínculos, y
+la gente usaba el teléfono para conectarse y acceder al sistema. Así que lo
+cierto es que yo produje con anterioridad una obra que utilizaba la técnica
+descrita en esa patente. De modo que esa es la segunda idea patentable que
+he tenido en mi vida, aunque creo que no tengo ninguna prueba de ello, no
+pensé que fuera lo suficientemente interesante como para publicarla. Después
+de todo, la idea de seguir un hipervínculo la tomé de la demo del editor de
+Englebart. Fue él quien tuvo una idea que merecía publicarse.
+A lo que había hecho lo llamé «hipertexto del pobre», dado que tenía que
+implementarlo en el contexto de TECO. No tenía tanta capacidad como el
+hipertexto de Englebart, pero al menos era útil para hojear documentación,
+que era todo lo que pretendía. Y en cuanto a que hubiera acceso telefónico
+al sistema, bueno, lo había, pero no se me ocurrió que lo uno tuviera
+ninguna relación particular con lo otro. No iba a publicar un artículo para
+decir: «¡Oh!, he implementado el hipertexto del pobre, y sabéis qué,
+¡también hay acceso telefónico en el ordenador!». Sospecho que no hay manera
+de precisar en qué fecha implementé esto. Y ¿fue publicado en algún sentido?
+Bueno, invitamos a la gente a que entrara en ARPAnet y se registrara en
+nuestra máquina, de modo que pudieran buscar documentación utilizando info y
+ver cómo funcionaba todo. Si nos hubieran preguntado, habrían descubierto
+que teníamos acceso telefónico. Como pueden ver, una circunstancia histórica
+determina si una técnica es original o no.
+</p>
+
+<p>
+Claro que ahora hay una publicación de Englebart sobre el hipertexto, que se
+presentará en los tribunales. De todos modos, no creo que diga nada sobre
+disponer de acceso telefónico en el ordenador, de manera que no está claro
+si resultará suficiente. Así pues, esta es una opción, la posibilidad de
+acudir a los tribunales para revocar una patente.
+</p>
+
+<p>
+Debido a los gastos que supone, normalmente ni se plantea, aun cuando se
+puedan encontrar pruebas sólidas de la existencia de una técnica anterior
+que deberían bastar para revocar la patente. En consecuencia, una patente
+inválida, que teóricamente no debería existir (aunque en realidad existen
+muchas de ellas) es un arma peligrosa. Si alguien nos ataca con una patente
+inválida, puede causarnos serios problemas. Podemos tratar de disuadirlo
+mostrándole la técnica anterior. Quizá de ese modo se asuste, o puede que
+piense: «Estás fingiendo, sabemos que en realidad no puedes ir a juicio, no
+te lo puedes permitir, así que te demandaremos de todos modos».
+</p>
+
+<p>
+Estas tres son opciones que a veces se pueden utilizar, pero a menudo no es
+posible. De modo que hay que hacer frente a una patente tras otra. Cada vez
+que descubrimos que podemos utilizar una de esas opciones, enseguida aparece
+una nueva patente, y luego otra, y otra. Es como cruzar un campo de minas. A
+cada paso que se da, a cada decisión de diseño que se toma, es probable que
+no nos topemos con una patente, de modo que es posible dar unos cuantos
+pasos sin que se produzca una explosión. Pero la probabilidad de cruzar todo
+el campo de minas y llegar a desarrollar el programa que se quiere
+desarrollar sin toparse con ninguna patente es tanto menor cuanto mayor es
+el programa.
+</p>
+
+<p>
+La gente solía decirme: «Bueno, hay patentes en otras áreas, ¿por qué habría
+que excluir el software?». Observen qué suposición más grotesca hay ahí, la
+de que todos tenemos que someternos al sistema de patentes de alguna
+manera. Es como decir: «Algunos contraen cáncer, ¿por qué tú deberías verte
+libre de él?». Tal como yo lo veo, que una persona no contraiga cáncer es
+algo bueno. Pero tras esto hay una pregunta menos tendenciosa, una buena
+pregunta: ¿Es el área del software diferente de las demás? ¿Debería la
+política de patentes ser diferente en las diferentes áreas y, en tal caso,
+por qué?
+</p>
+
+<p>
+Permítanme... El efecto de las patentes no es el mismo en todas las áreas
+donde se aplican porque la relación de las patentes con los productos es
+diferente según el área de especialización.
+</p>
+
+<p>
+En uno de los extremos tenemos a las empresas farmacéuticas, donde se
+patenta una fórmula química, de modo que esa patente cubre un solo
+producto. Cualquier nuevo producto no estaría cubierto por la patente que ya
+existe. En caso de que el nuevo producto se patente, el titular de la
+patente será quien haya elaborado el nuevo producto.
+</p>
+
+<p>
+Eso se ajusta a la idea ingenua que tenemos del sistema de patentes, la idea
+de que si alguien diseña un producto nuevo, va a conseguir «la patente», la
+idea de que hay una patente por producto y que la patente cubre la idea de
+ese producto. En algunas áreas esto se aproxima a la verdad, en otras está
+muy lejos de ser cierto. En el área de la informática los paquetes de
+software suelen ser muy grandes. Utilizan muchas ideas diferentes en nuevas
+combinaciones. Si el programa es nuevo, y no simplemente copiado,
+probablemente utilice una combinación diferente de ideas, combinadas, por
+supuesto, con código nuevo, porque no es posible hacer que esas ideas
+funcionen mágicamente con solo pronunciar sus nombres. Hay que
+implementarlas todas.
+Hay que implementarlas todas en esa combinación. La consecuencia es que
+incluso cuando se escribe un programa se utiliza gran cantidad de ideas
+diferentes, cada una de las cuales puede estar patentada por alguien. Un par
+de ellas podría estar patentada como combinación por alguien. Puede haber
+varias maneras diferentes de describir una idea, que puede estar patentada
+por distinta gente. Así que posiblemente haya miles de cosas, miles de
+aspectos vulnerables en el programa, que podrían estar ya patentados por
+alguien. Por eso las patentes de software suelen obstaculizar el progreso
+del software, la tarea de desarrollar software.
+</p>
+
+<p>
+Si cada patente correspondiera a un solo producto, esas patentes no
+obstaculizarían el desarrollo de nuevos productos, porque al desarrollar un
+nuevo producto éste no podría estar ya patentado por otra persona. Pero
+cuando en un producto se combinan muchas ideas diferentes es muy probable
+que ese producto esté ya patentado por otra persona. De hecho, hay estudios
+económicos que demuestran que la imposición de un sistema de patentes en un
+campo en el que se da una innovación incremental puede ralentizar el
+progreso.
+Los defensores de las patentes de software dicen: «Bueno, sí, puede que haya
+problemas, pero más importante que cualquier problema es el hecho de que las
+patentes deben promover la innovación, y esto es tan importante que los
+problemas que causen son irrelevantes». Claro que esto no lo dicen en voz
+alta porque es ridículo, pero implícitamente quieren haceros creer que el
+sistema de patentes promueve el progreso y que eso compensa cualquier coste
+posible. En realidad no hay razones para creer que promueva el
+progreso. Ahora tenemos un modelo que demuestra claramente el modo en que
+las patentes pueden ralentizar el progreso. El caso en el que se aplica ese
+modelo, la innovación incremental, describe muy bien el área del software.
+</p>
+
+<p>
+¿Por qué se encuentra el software en ese extremo del espectro? El motivo es
+que en el campo del software desarrollamos objetos matemáticos ideales. Se
+puede construir un complejo castillo y hacerlo descansar sobre una fina
+línea, y se mantendrá en pie, porque no pesa nada. En otras áreas la gente
+tiene que hacer frente a la obstinación de la materia, de los objetos
+físicos. La materia hace lo que tiene que hacer. Se puede tratar de
+construir un modelo, pero si el comportamiento real no se ajusta al modelo
+entonces tenemos un problema, porque el reto es construir objetos físicos
+que funcionen en la realidad.
+</p>
+
+<p>
+Si quiero poner una declaración <cite>if</cite> dentro de una declaración
+<cite>while</cite>, no tengo que preocuparme de que la declaración
+<cite>if</cite> pueda oscilar a una determinada frecuencia, friccionar con
+la declaración <cite>while</cite> y llegar a romperse. No tengo que
+preocuparme de que oscile a una frecuencia demasiado alta y genere una señal
+que modifique el valor de alguna otra variable. No tengo que preocuparme de
+cuánta corriente puede requerir la declaración <cite>if</cite> y si podrá
+disipar el calor dentro de la declaración <cite>while</cite>. O de si habrá
+una caída de tensión en la declaración <cite>while</cite> que impida que la
+declaración <cite>if</cite> funcione.
+No tengo que preocuparme de que si ejecuto el programa en un entorno de agua
+salada, el agua pueda introducirse entre las declaraciones <cite>if</cite> y
+<cite>while</cite> y provocar corrosión. Cuando hago referencia al valor de
+una variable, no tengo que preocuparme de que se exceda ningún límite si eso
+sucede veinte veces. Cuando hago referencia a la variable tampoco tengo que
+preocuparme de su capacitancia, ni de si habrá tiempo suficiente para que se
+cargue su valor. Cuando escribo el programa no tengo que preocuparme de cómo
+ensamblaré físicamente cada copia ni de si podré arreglármelas para insertar
+la declaración <cite>if</cite> dentro de la declaración
+<cite>while</cite>. No tengo que preocuparme de cómo acceder a la
+declaración <cite>if</cite>, en caso de que se rompa, para retirarla y
+sustituirla por una nueva.
+</p>
+
+<p>
+Hay muchos problemas de los que no tenemos que preocuparnos en el
+software. Eso lo hace esencialmente más sencillo. Es mucho más sencillo
+escribir un programa que diseñar un objeto físico que funcione. Esto puede
+parecer extraño, porque habrán oído hablar de lo difícil que es diseñar
+software, de los enormes problemas que supone y de cómo ingeniárselas para
+resolverlos. En realidad no están hablando de lo mismo que yo. Yo estoy
+comparando sistemas físicos y sistemas de software de la misma complejidad,
+con el mismo número de elementos. Estoy diciendo que un sistema de software
+es mucho más fácil de diseñar que un sistema físico. Pero la inteligencia de
+la gente que trabaja en estos terrenos diferentes es similar, de modo que
+¿qué hacemos cuando nos encontramos en un terreno sencillo? ¡Lo hacemos
+avanzar! Llevamos nuestras capacidades al límite.
+Si los sistemas del mismo tamaño son sencillos, hagamos sistemas diez veces
+más grandes, ¡así será complicado! Y es lo que hacemos. Hacemos sistemas de
+software que son mucho mayores que los sistemas físicos con respecto al
+número de partes que los componen. Un sistema físico cuyo diseño contiene un
+millón de piezas diferentes es un megaproyecto. Un programa informático cuyo
+diseño contiene un millón de piezas puede tener unas 300.000 líneas, unas
+pocas personas pueden escribirlo en un par de años. No sería un programa
+gigantesco. GNU Emacs contiene ya varios millones de piezas, creo. Tiene un
+millón de líneas de código. Es un proyecto realizado prácticamente sin
+financiación, realizado en su mayor parte por gente en su tiempo libre.
+</p>
+
+<p>
+Hay otra gran ventaja. Si usted ha diseñado un producto físico, el siguiente
+paso será diseñar la fábrica para construirlo. Edificar esa fábrica puede
+costar millones o decenas de millones, mientras que para hacer copias del
+programa no hay más que escribir «copiar». La misma orden de copiar copiará
+cualquier programa. ¿Queremos copias en CD? De acuerdo, entonces grabamos un
+CD maestro y lo enviamos a una planta de CD. Utilizarán el mismo
+equipamiento para copiar cualquier contenido en un CD, no tenemos que
+levantar una fábrica para hacer este producto. Hay una tremenda
+simplificación y una tremenda reducción de costes en el diseño.
+
+La consecuencia, digamos para una compañía automovilística que se gastará 50
+millones de dólares en levantar una planta para fabricar un nuevo modelo, es
+que puede contratar a unos cuantos abogados para que se ocupen de las
+negociaciones relativas a las patentes. Podrían incluso afrontar un proceso
+judicial si quisieran. Diseñar un programa de la misma complejidad puede
+costar 50.000 o 100.00 dólares. En comparación, el coste de lidiar con el
+sistema de patentes es devastador. De hecho, concebir un programa de la
+misma complejidad que el diseño mecánico de un coche llevaría probablemente
+un mes de trabajo. ¿Cuántas partes tiene un coche (uno que no contenga
+ningún ordenador)?[<a href="#f1">1</a>] No son muchas. Esto no quiere decir
+que diseñar un buen coche sea sencillo, sino solo que no contiene muchas
+piezas diferentes.
+</p>
+
+<p>
+La programación es muy diferente de otros campos porque trabajamos con
+objetos matemáticos, cuyo diseño es muchísimo más sencillo, y debido a ello
+habitualmente hacemos sistemas que son muchísimo más grandes, y eso con tan
+solo un puñado de personas. El resultado es que entonces el sistema de
+patentes con el que nos encontramos, en lugar de ser del tipo «un producto,
+una patente», es un sistema en el que un producto comprende multitud de
+ideas que podrían estar ya patentadas.
+</p>
+
+<p>
+La mejor manera de explicarlo es comparándolo con una sinfonía. Una sinfonía
+es también larga y contiene muchas notas, y probablemente utiliza muchas
+ideas musicales. Imaginen que los Gobiernos europeos del siglo XVIII
+hubieran decidido que querían promover el progreso de la música sinfónica
+estableciendo una Oficina Europea de Patentes Musicales que concediera
+patentes para todo tipo de ideas musicales que pudieran expresarse en
+palabras. Imaginen ahora que se encuentran en 1800, ustedes son Beethoven y
+quieren componer una sinfonía. Descubrirían que conseguir que su sinfonía no
+infringiera ninguna patente sería más complicado que escribir una buena
+sinfonía.
+
+Si protestaran por ello, los titulares de las patentes dirían, «Ah,
+Beethoven, reniegas solo porque no tienes ideas propias. Lo único que
+pretendes es apropiarte de nuestras invenciones». Lo cierto es que Beethoven
+concibió multitud de ideas musicales nuevas, pero tenía que utilizar muchas
+ideas musicales ya existentes a fin de componer música reconocible, a fin de
+componer música que pudiera gustar a los oyentes, música que estos pudieran
+reconocer como tal. Nadie es tan brillante como para reinventar la música y
+componer algo que la gente quiera escuchar. <a
+href="http://en.wikipedia.org/wiki/Pierre_Boulez">Pierre Boulez</a> dijo que
+intentaría hacerlo, ¿pero quién escucha a Pierre Boulez?
+</p>
+
+<p>
+Nadie es tan brillante como para reinventar la informática desde cero. Si lo
+hiciera, lo que escribiera les resultaría a los usuarios tan extraño que no
+querrían utilizarlo. Si miran hoy un procesador de textos encontrarán, creo,
+cientos de funcionalidades diferentes. Si se desarrolla un nuevo procesador
+de textos de calidad e innovador, eso quiere decir que contendrá algunas
+ideas nuevas, pero ha de contener también cientos de viejas ideas. Si no se
+nos permite utilizarlas, no podremos hacer un procesador de textos
+innovador.
+</p>
+
+<p>
+Dado que la tarea de desarrollar software es tan grande, no necesitamos
+ningún plan artificial para incentivar ideas nuevas. Solo se necesita gente
+que escriba software, y ellos concebirán algunas ideas nuevas. Si queremos
+escribir un programa y hacer que sea bueno, tendremos algunas ideas y
+encontraremos la manera de utilizar algunas de ellas. Lo que solía suceder,
+puesto que yo trabajé en el campo del software antes de que hubiera patentes
+de software, es que la mayoría de los desarrolladores publicaban cualquier
+nueva idea que consideraran relevante, que pensaran que podía reportarles
+reconocimiento o consideración.
+
+No publicaban las ideas menores o insignificantes porque sería tonto
+hacerlo. Ahora se supone que el sistema de patentes estimula la divulgación
+de ideas. De hecho en los viejos tiempos nadie mantenía las ideas en
+secreto. Mantenían en secreto el código, es cierto. Al fin y al cabo, el
+código representaba el grueso del trabajo. Mantenían en secreto el código y
+publicaban las ideas, de manera que los empleados obtenían reconocimiento y
+se sentían bien. Tras la aparición de las patentes de software, seguían
+manteniendo el código en secreto y patentaban las ideas, así que lo cierto
+es que no se ha fomentado la divulgación de ninguna manera. Las mismas cosas
+que se mantenían en secreto antes se siguen manteniendo en secreto ahora,
+pero las ideas que solían publicarse y podíamos utilizar, ahora son
+probablemente patentadas y quedan fuera de alcance durante veinte años.
+</p>
+
+<p>
+¿Qué puede hacer un país para cambiar esto? ¿Qué política deberíamos adoptar
+para resolver este problema? Hay dos maneras de abordar la cuestión. Una
+apunta al lugar donde se solicitan y emiten las patentes, la oficina de
+patentes. La otra se refiere al momento en que se solicitan las patentes, la
+cuestión de qué es lo que cubre una patente.
+</p>
+
+<p>
+Cambiar los criterios para emitir una patente, o simplemente adoptar un buen
+criterio para emitir patentes, puede funcionar en un país que aún no haya
+autorizado las patentes de software, por ejemplo en la mayor parte de
+Europa. Bastaría con consolidar las normas de la Oficina Europea de Patentes
+que dicen que el software no es patentable. Esta es una buena solución para
+Europa. Europa está ahora tomando en consideración una directiva sobre las
+patentes de software. La directiva, supongo, puede abarcar más cosas, pero
+una de sus implicaciones importantes es para las patentes de
+software. Simplemente modificando esto para decir que las ideas de software
+no pueden patentarse, la mayor parte de Europa se libraría del problema, con
+excepción de algunos países que han aceptado el problema por sí solos. Por
+desgracia, uno de ellos es el Reino Unido. Por desgracia para ustedes.
+</p>
+
+<p>
+Esta estrategia no sirve en EE.&nbsp;UU. La razón es que EE.&nbsp;UU. tiene
+ya gran cantidad de patentes de software y ningún cambio en los criterios
+para emitir patentes nos libraría de las ya existentes.[<a href="#f2">2</a>]
+En realidad estas patentes no están oficialmente identificadas como patentes
+de software. Yo hablo de patentes de software, pero ¿qué quiero decir en
+realidad? Me refiero a patentes que podrían aplicarse al software, patentes
+que podrían hacer que nos demandaran por escribir software.
+
+La oficina de patentes no distingue entre patentes de software y otro tipo
+de patentes. De manera que, de hecho, cabe la posibilidad de que cualquier
+patente podría hacer que nos demandaran por escribir software. Así que, en
+EE.&nbsp;UU., la solución consistiría en modificar la aplicabilidad, el
+alcance de las patentes, diciendo que una simple implementación de software
+que se ejecute en un ordenador genérico y que en sí misma no infrinja la
+patente no está cubierta por ninguna patente y no puede ser objeto de
+denuncia. Este es otro tipo de solución.
+</p>
+
+<p>
+El primer tipo de solución, la que se refiere al tipo de patentes que pueden
+ser válidas, es una buena solución para utilizar en Europa.
+</p>
+
+<p>
+Cuando en EE.&nbsp;UU. se empezaron a introducir las patentes de software,
+no hubo debate. De hecho, nadie lo advirtió. El mundo del software, en su
+mayor parte, ni siquiera se dio cuenta. En 1981 hubo una decisión del
+Tribunal Supremo relativa a una patente sobre un proceso de curado del
+caucho. La sentencia decía que el hecho de que el aparato incluyera un
+ordenador y un programa como parte del proceso para curar el caucho no lo
+inhabilitaba para ser patentado.
+Al año siguiente, un tribunal de apelación especializado en los casos de
+patentes invirtió los términos. Dijeron que el hecho de que algo contenga un
+ordenador y un programa lo hace patentable. Así es cómo EE.&nbsp;UU. comenzó
+a introducir patentes sobre procedimientos industriales. Esto se debe a que
+los procedimientos industriales se realizan en un ordenador, y eso los hacía
+patentables. El caso es que se tomó esa decisión, y creo que la patente
+sobre el cálculo en orden natural fue una de las primeras, o incluso puede
+que fuera la primera. En los años ochenta no lo sabíamos.
+</p>
+
+<p>
+Fue alrededor de los noventa cuando los programadores de
+EE.&nbsp;UU. empezaron a darse cuenta del peligro que representaban las
+patentes de software. De modo que yo conocía cómo funcionaba la informática
+antes y después, y no he visto ningún aumento del progreso a partir de
+1990. En EE.&nbsp;UU. no hubo debate, pero en Europa ha habido un amplio
+debate político. Hace unos años hubo presiones para enmendar el tratado de
+Munich que estableció la <a href="http://www.epo.org/">Oficina Europea de
+Patentes</a>. Hay una <a
+href="http://www.epo.org/law-practice/legal-texts/html/epc/1973/e/ar52.html">cláusula
+que dice que el software no es patentable</a>. La ofensiva pretendía
+enmendarla para que se permitieran las patentes de software. Pero la
+comunidad se dio cuenta de esto, y fueron los desarrolladores y usuarios de
+software libre quienes lideraron la oposición.
+</p>
+
+<p>
+Pero no somos los únicos amenazados por las patentes de software. Todos los
+desarrolladores de software están amenazados, e incluso los usuarios. Por
+ejemplo, cuando Paul Heckel vio que sus amenazas no intimidaban demasiado a
+Apple, amenazó con empezar a demandar a los clientes de Apple. Eso sí asustó
+a Apple. Calcularon que no podían permitirse que sus clientes fueran
+demandados de esa manera, aun cuando al final ganaran. De modo que también
+los usuarios pueden ser denunciados, bien como forma de atacar a un
+desarrollador, o simplemente como un medio para sacarles dinero o provocar
+confusión.
+</p>
+
+<p>
+Todos los desarrolladores y usuarios de software son vulnerables, pero fue
+la comunidad del software libre europea la que tomó el liderazgo para
+organizar la oposición. De hecho, los países que gobiernan la Oficina
+Europea de Patentes han votado ya dos veces en contra de enmendar el
+tratado. Luego intervino la UE, y cada Dirección General adoptó una posición
+diferente.
+</p>
+
+<p> La Dirección que se ocupa de promover el software es contraria a las
+patentes de software, pero ellos no se encargaban de este asunto. Quien está
+al cargo es la Dirección General del Mercado Interno, cuyo líder es
+favorable a las patentes de software. Ignoraron por completo la opinión
+pública y propusieron una directiva que permitía las patentes de
+software.[<a href="#f3">3</a>] El Gobierno francés ya ha dicho que se opone
+a esa directiva. En varios otros países europeos ya se está trabajando para
+oponerse a las patentes de software, y es vital que aquí se empiece a hacer
+lo mismo. </p>
+
+<p>
+Según Hartmut Pilch, que es uno de los líderes de la lucha europea contra
+las patentes de software, la que hace más fuerza es la <a
+href="http://www.patent.gov.uk/">Oficina de Patentes del Reino Unido</a>. La
+Oficina de Patentes del Reino Unido tiene una predisposición favorable a las
+patentes de software. Llevó a cabo una encuesta pública y la mayoría de las
+respuestas fueron contrarias a las patentes de software. Luego redactaron un
+informe diciendo que la gente parecía estar conforme con ellas, ignorando
+por completo las respuestas. Resulta que la comunidad del software libre
+pidió que se enviaran las respuestas a la Oficina de Patentes, y también a
+ellos, para así publicarlas. De modo que las publicaron, y la mayoría eran
+contrarias. A la vista del informe de la Oficina de Patentes del Reino Unido
+nadie habría pensado que era así.
+</p>
+
+<p>
+Ellos (la Oficina de Patentes y Marcas Comerciales del Reino Unido) utilizan
+un concepto que llaman «efecto técnico». Es un concepto que se puede estirar
+enormemente. Se supone que hay que pensar que significa que la idea de un
+programa solo es patentable si está estrechamente relacionada con
+actividades físicas concretas. Si la interpretación es esa, el problema
+estaría prácticamente resuelto. Si las únicas ideas de software que pudieran
+patentarse fueran las que realmente están relacionadas con una técnica
+particular, con un resultado físico concreto que podría haberse patentado
+sin utilizar un programa, eso estaría bien. El problema es que se puede
+ampliar esa condición. Se puede describir como un resultado físico el
+resultado que se obtiene ejecutando algún programa. ¿En qué se diferencia
+este resultado físico de cualquier otro? En que es el resultado de esa
+computación. La consecuencia es que la Oficina de Patentes del Reino Unido
+está planteando una propuesta que parece conducir a la resolución del
+problema y que en realidad da carta blanca para patentar casi todo.
+</p>
+
+<p>
+En el mismo ministerio hay personas que se ocupan también del copyright, que
+en realidad no tiene nada que ver con las patentes de software, solo que las
+personas al cargo son las mismas. La cuestión es cómo se interprete la
+reciente directiva de la UE sobre el copyright, una horrible ley como la <a
+href="http://www.eff.org/issues/dmca">Ley de Copyright del Milenio Digital
+de EE.&nbsp;UU.</a>. Pero cada país dispone de cierto margen en cuanto a la
+modalidad de implementación. El Reino Unido está proponiendo la forma más
+draconiana posible de implementar esta directiva. Si se implementara de
+manera apropiada se podría reducir en gran medida el daño que produce, pero
+el Reino Unido quiere maximizar el efecto tiránico de la directiva. Parece
+que hay cierto organismo, el <a
+href="http://webarchive.nationalarchives.gov.uk/20070603164510/http://www.dti.gov.uk/">Departamento
+de Comercio e Industria</a>, al que hay que poner freno. Es necesario poner
+límites a sus actividades e impedirle crear nuevas formas de poder.
+</p>
+
+<p>
+Las patentes de software enredan a todos los desarrolladores de software y a
+todos los usuarios de ordenadores en una nueva forma de burocracia. Si las
+empresas que utilizan ordenadores se dieran cuenta de la cantidad de
+problemas que esto puede ocasionarles se pondrían en pie de guerra y estoy
+seguro de que podrían detenerlo. A las empresas no les gustan las trabas
+burocráticas.
+</p>
+
+<p>
+Claro que a veces cumple una función importante. Hay algunos terrenos en los
+que desearíamos que el Gobierno del Reino Unido hiciera una labor más
+cuidadosa imponiendo trámites burocráticos a ciertas empresas, como cuando
+se trata de trasladar animales de un lugar a otro.[<a href="#f4">4</a>] Pero
+en ciertos casos, cuando no sirve más que para crear monopolios artificiales
+que permiten que alguien interfiera en el desarrollo del software y exprima
+a los desarrolladores y usuarios, entonces hemos de rechazarla.
+</p>
+
+<p>
+Debemos hacer que los directivos de las empresas sean conscientes de lo que
+las patentes de software les pueden hacer. Anímelos a apoyar la <a
+href="http://www.ffii.org/">lucha contra las patentes de software en
+Europa</a>.
+</p>
+
+<p>
+La batalla no ha terminado. Aún se puede ganar.
+</p>
+
+<h3>Notas</h3>
+<ol>
+ <li id="f1">Una transmisión automática consta de entre 300 y 400 partes únicas, y por lo
+general la transmisión es el componente más complicado de un
+automóvil. Diseñar una transmisión puede llevar de seis meses a un año, y
+luego puede llevar aún más tiempo construirla y hacerla funcionar. Sin
+embargo, un programa con entre 500 y 600 partes funcionales tendría entre
+200 y 300 líneas de código, y a un buen programador le llevaría entre un día
+y una semana escribirlo, probarlo y depurarlo.</li>
+
+ <li id="f2">Digo «patentes de software», pero ¿qué quiero decir en realidad? La oficina
+de patentes de EE.&nbsp;UU. no divide oficialmente las patentes en patentes
+de software y las demás. De modo que, de hecho, cualquier patente, si puede
+aplicarse a algún software, podría servir para demandar a quien escribe
+software. Las patentes de software son patentes que podrían aplicarse al
+software, patentes que podrían servir para demandar a quien escribe
+software.</li>
+
+ <li id="f3">El 6 de julio de 2005, el Parlamento europeo rechazó la directiva de
+patentes de software con 648 votos negativos de 680. No obstante, no debemos
+dejar que este asunto caiga en el olvido, ya que quienes presionaron en
+favor de las patentes están tratando de resucitar la directiva recientemente
+rechazada. También hemos de asegurarnos de que la Oficina Europea de
+Patentes y las oficinas nacionales de los diferentes países de la UE dejen
+de conceder patentes para el software que está incluido en otro tipo de
+invenciones.</li>
+
+ <li id="f4">Para evitar que se extienda la fiebre aftosa.</li>
+</ol>
+
+<hr />
+<blockquote id="fsfs"><p class="big">Este ensayo está publicado en el libro <a
+href="http://shop.fsf.org/product/free-software-free-society/"><cite>Software
+libre para una sociedad libre: Selección de ensayos de Richard
+M. Stallman</cite></a>.</p></blockquote>
+
+<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; 2002, 2015, 2016, 2017, 2018, 2019, 2020 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.-->
+<strong>Traducido originalmente por la editorial Traficantes de Sueños,
+2004.</strong> Revisión: Equipo de traductores al español de GNU, 2020.</div>
+
+<p class="unprintable"><!-- timestamp start -->
+Última actualización:
+
+$Date: 2020/07/08 22:30:13 $
+
+<!-- timestamp end -->
+</p>
+</div>
+</div>
+<!-- for class="inner", starts in the banner include -->
+</body>
+</html>