path: root/talermerchantdemos/blog/articles/es/software-patents.html

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