Patentes de software: Un obstáculo para el desarrollo de software

por Richard Stallman

---

Posiblemente estén familiarizados con mi trabajo en el software libre. Esta charla no trata sobre eso. Trata sobre una forma de abuso legal 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.

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 patentes de software 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.

Diferencias entre copyright y patentes

Probablemente hayan oído una expresión engañosa, «propiedad intelectual». Como pueden ver, es una expresión sesgada porque 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 la cuestión más básica en cualquier ámbito que se esté considerando. No contribuye a pensar de forma clara y con amplitud de miras.

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. Cubren 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.

Por citar algunas de las mayores diferencias entre el copyright y las patentes:

• El copyright cubre la expresión particular de una obra, no las ideas. Es un error legal considerar que el copyright cubre las ideas. Las patentes, en cambio, cubren únicamente ideas y el uso de las ideas.

• El copyright se aplica automáticamente, mientras las patentes las otorga la oficina de patentes en respuesta a una solicitud. Cuesta mucho dinero, y pagar a los abogados para que redacten la solicitud cuesta aún más 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.

• 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 dueño, pero es demasiado para la escala temporal de un ámbito como el del software.

  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.

• El copyright cubre la copia. Si alguien escribe una novela que resulta ser idéntica, palabra por palabra, a Lo que el viento se llevó y puede demostrar que nunca antes había visto Lo que el viento se llevó, eso le serviría para defenderse ante cualquier acusación de infracción de copyright.

  Una patente, por otro lado, 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.

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.

El sistema de patentes

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 podría conseguir con 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: «¡Dame 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.

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 The Economist 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.

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.

Veamos entonces, ¿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, porque 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. 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 había dado cuenta de que ya no se podían usar sin peligro las ideas que se encontraban en una revista.

Pero dejemos a un lado ese 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. UU. hay cientos de miles de patentes de software.

Por ejemplo, había una patente de software, que quizá haya ya expirado, sobre el «recálculo en 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 recálculo todo queda actualizado. Las primeras hojas de cálculo hacían el recálculo de arriba hacia 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ó: «¿Por qué no realizar las operaciones de recálculo de modo que cada elemento se recalcule en función del elemento del que depende? Haciéndolo en el orden correcto, todos se actualizarán». 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», porque no se mencionaba esa expresión. Tampoco buscando «orden natural» o «clasificación topológica» porque en la patente no aparecían estos términos. De hecho, se describía como un «método de compilar fórmulas en código objeto». Creo que la primera vez que la vi pensé que no era esa la patente que buscaba.

Supongamos que disponemos de una lista de patentes y queremos saber qué nos está prohibido. Al tratar de estudiar estas patentes descubrimos que es demasiado complicado entenderlas, ya que están escritas en un lenguaje legal muy enrevesado cuyo significado es difícil comprender. De hecho, lo que dicen las oficinas de patentes a menudo no significa lo que parece significar.

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 el idioma de las patentes».” [risas]

Esto no es una simple teoría. Hacia 1990, un programador llamado Paul Heckel 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 «invenciones». No se parecían similares. 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 no es verdad, ¡yo simplemente no entendía el alcance de mi protección!». [risas]  Y yo le contesté: «Sí, eso es lo que yo estaba diciendo». [risas]

De modo tal que, de hecho ,pasaremos mucho tiempo hablando con los abogados para descifrar qué es lo que estas patentes nos 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». [risas por lo bajo]

Cómo puede un desarrollador afrontar las patentes

Ahora que conocemos el terreno que pisamos para hacer negocios, [risas por lo bajo] ¿qué haremos? Bien, hay tres formas de afrontar la cuestión, y todas son aplicables en ciertos casos.

Son las siguientes:

1. Evitar la patente
2. Obtener la licencia de la patente
3. Revocar la patente en los tribunales

Describiré estas tres soluciones y lo que las hace viables o inviables.

1. Evitar la patente

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 Emacs 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. [risas]  Descubrí que era patentable porque ¡otra persona la patentó después! De hecho, habían probado los tres enfoques. Primero intentaron negociar con el dueño 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. 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 ese caso se trataba de una patente bastante limitada sobre una funcionalidad muy específica. Pero, ¿qué se puede hacer con relación a la patente de British Telecom 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. [risas]

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. UU. La patente caducó en 1997. Hasta entonces, obstruyó enormemente el uso de ese tipo de cifrado en EE. UU. Un buen número de programas que la gente empezaba a desarrollar se vieron frustrados y nunca llegaron a estar verdaderamente disponibles debido a las amenazas de los propietarios de las patentes. Posteriormente un programa escapó: PGP, que inicialmente se publicó como software libre. Al parecer, los dueños 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 manera de evitar esa patente. No se podía hacer nada más.

A veces se patenta un algoritmo determinado. Por ejemplo, existe una patente sobre una versión optimizada de la transformada rápida de Fourier (FFT), que funciona aproximadamente 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.

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 Gzip, 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. Quien 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 GIF. 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. De hecho, ¡durante diez años no pudimos hacerlo! Tan pronto como empezaron a llegar amenazas judiciales por usar archivos GIF, se comenzó a utilizar el algoritmo de Gzip para definir otro formato de imagen. 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».” [risas]

De hecho, la inercia en el uso del formato GIF era tan grande que no pudimos lograr que la gente 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.

En realidad la situación es todavía más grotesca, porque de hecho hay 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.

Si fueran patentes sobre procesos químicos, sería mucho más fácil, porque 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.

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. 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; pues bien, también sobre ese algoritmo se habían emitido en EE. UU. dos patentes. Por lo que se ve, no es nada inusual.

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.

Hay otra cuestión que debo mencionar. A veces una empresa o un consorcio puede hacer que un formato o protocolo sea un 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 World Wide Web Consortium propuso que se empezaran a adoptar estándares cubiertos por patentes. La comunidad protestó y se retractaron. Se echaron atrás y volvieron a insistir en que cualquiera debería poder implementar libremente cualquier patente, y en que cualquiera debería tener la libertad de implementar los estándares. 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.

2. Obtener la licencia de la patente

La segunda posibilidad consiste en conseguir una licencia para la patente, en lugar de evitarla. Esta no es necesariamente una opción. El dueño 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 le decía: «Nosotros tenemos las patentes. Usted no está autorizado a fabricar estas cosas. Cierre su negocio».

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.

Ya ven que la oficina de patentes cree que es una idea brillante hacer cualquier cosa más de una vez. [risas]  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 dos veces en vez de una sola vez, ha inventado algo. Eso debe de significar que se trata de un genio, que nadie puede llevarle la contraria y que tiene derecho a dar órdenes y restringir 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.

No obstante, muchos dueños 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. UU. Según me han dicho, ese era el precio reducido anterior al juicio. En caso de juicio, si el dueño de la patente acababa ganando, exigiría 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 ellos. ¿Y si hubiera que obtener la licencia de veintiuna patentes?

La gente del sector me decía que, en la práctica, dos o tres licencias de esas harían inviable cualquier negocio.

Hay una situación en la que obtener una licencia por el uso de una 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 artículo en la revista Think (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 (creo que hoy en día el número es 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 un orden de magnitud 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? ¿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, o puede suponer un grande beneficio para su dueño y 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 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.

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 cualquier cosa. 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 esa persona. Veamos pues qué sucedería si esa persona intentara usar una patente para impedirlo. Dirá: «Ah, no, IBM, no puedes competir conmigo. Tengo esta patente». E IBM responderá: «Veamos. Echemos un vistazo a tu producto. Mmm. .. 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, encontraré unas cuantas más. Así que, ¿por qué no intercambias licencias conmigo?». Y entonces el brillante pequeño inventor [risas] 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.

Las megacorporaciones se ven libres de la mayor parte del daño que ocasiona el sistema de patentes. Fundamentalmente disfrutan de sus ventajas, es por eso quieren que existan patentes de software, son las únicas que se beneficiarán con ellas. Pero si se es realmente 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 obtener 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í [señalando hacia la izquierda], y alguien llega desde allá [señalando hacia la derecha] y le apunta con una patente diciendo: «Dame tu dinero», se ve indefensa porque posee patentes que apuntan allí o cerca de allí [señalando hacia la izquierda], pero no allá [señalando hacia la derecha]. 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.

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.

No hay patentes que cubran procedimientos legales. [risas] 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, Refac, 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.

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.

3. Revocar la patente en los tribunales

Supuestamente, para que algo se patente tiene que ser nuevo, útil y no obvio. Es el léxico usado en EE. UU. Creo que en otros países emplean términos diferentes que son prácticamente equivalentes. Claro que cuando la oficina de patentes entra en juego y comienza a 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».

Alguien que estudia la mayoría de las patentes de software emitidas en EE. UU. —o que al menos lo hacía, no sé si todavía puede con la cantidad que hay— 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 fuera al kiosco y adquiriera algunas revistas de informática, comprobaría que esas ideas ya se conocían.

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.

Me han dicho que estos excesos en las reivindicaciones son moneda corriente, y que la Oficina de Patentes de EE. 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.

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 dueños 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.

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ó.

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 patente de British Telecom sobre el seguimiento de hipervínculos mediante acceso telefónico 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. 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 alguna 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!». [risas]  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.

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. Pero 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 muchísimas 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 que la técnica ya existía. 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».

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 estas 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.

Características del área de la programación

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í, 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?». [risas] 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é?

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.

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 dueño de la patente será quien haya elaborado el nuevo producto.

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. El software se encuentra en el extremo opuesto. Esto se debe a que 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 distintas personas. 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.

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 hacernos 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.

¿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.

Si quiero poner una declaración if dentro de una declaración while, no tengo que preocuparme de que la declaración if pueda oscilar a una determinada frecuencia, friccionar con la declaración while y llegar a romperse. [risas]  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 if y si podrá disipar el calor dentro de la declaración while. O de si habrá una caída de tensión en la declaración while que impida que la declaración if funcione. No tengo que preocuparme de que si ejecuto el programa en un entorno de agua salada, el agua pueda introducirse entre las declaraciones if y while 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 demasiadas 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 if dentro de la declaración while. No tengo que preocuparme de cómo acceder a la declaración if, en caso de que se rompa, para retirarla y sustituirla por una nueva.[risas]

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! [risas] 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, porque tiene un millón de líneas de código. Fue un proyecto realizado prácticamente sin financiación, realizado en su mayor parte por gente en su tiempo libre.

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 copy. La misma orden copy 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.000 dólares. En comparación, el coste de lidiar con el sistema de patentes es devastador. 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?[1] No son muchas. Esto no quiere decir que diseñar un buen coche sea sencillo, sino solo que no contiene muchas piezas diferentes.

La programación es muy diferente de otros campos porque trabajamos con objetos matemáticos. El 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. Entonces el resultado es que el sistema de patentes, 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.

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 lograr que su sinfonía no infringiera ninguna patente sería más complicado que escribir una buena sinfonía. Si protestaran por ello, los dueños 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 tuvo 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. Pierre Boulez dijo que intentaría hacerlo, ¿pero quién escucha a Pierre Boulez? [risas]

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 creo que encontrarán 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.

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, queremos 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. Generalmente mantenían en secreto el código y publicaban las ideas. De manera que los empleados obtenían reconocimiento y se sentían bien, porque se sabe, se les permitía publicar artículos. 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.

Cómo abordar el problema de las patentes de software en las políticas públicas

¿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.

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.

Esta estrategia no sirve en EE. UU. La razón es que EE. 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. 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 si se pudiera aplicar al mismo. Así que, en EE. 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 ejecuta en un ordenador genérico y que en sí misma no infringe la patente no está cubierta por ninguna patente y no puede ser objeto de denuncia. Este es el otro tipo de solución.

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.

Cuando en EE. UU. se empezaron a introducir las patentes de software, no hubo debate político. 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 contenga un ordenador y un programa lo hace patentable. Cualquier cosa contenga un ordenador y un programa es patentable. Así es cómo EE. UU. comenzó a introducir patentes sobre procedimientos industriales, porque los procedimientos industriales se realizan en un ordenador, y eso los hacía patentables. Fue así 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.

Pero durante los años ochenta no sabíamos prácticamente nada de esto. Fue alrededor de los noventa cuando los programadores de EE. 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. 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 Oficina Europea de Patentes. Hay una cláusula que dice que el software no es patentable. 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.

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 si 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.

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.

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.[2] 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.

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 Oficina de Patentes del Reino Unido. 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, [risas] 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í.

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. El resultado que se obtiene ejecutando algún programa se puede describir como un resultado físico. ¿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.

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 Ley de Copyright del Milenio Digital de EE. UU.. 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 Departamento de Comercio e Industria, [risas] al que hay que poner freno. [risas] Es necesario poner límites a sus actividades e impedirle crear nuevas formas de poder.

Las patentes de software atrapan 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 ponerle fin. A las empresas no les gustan las trabas burocráticas.

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.[3] Pero en ciertos casos, cuando no sirve más que para crear monopolios artificiales para que alguien interfiera en el desarrollo del software y exprima a los desarrolladores y usuarios, entonces hemos de rechazarla.

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 lucha contra las patentes de software en Europa.

La batalla no ha terminado. Aún se puede ganar. [aplausos]

Notas

1. 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.
2. 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.
3. Para evitar que se extienda la fiebre aftosa.

---