English [en]   español [es]   français [fr]   русский [ru]  

Esta es una traducción de la página original en inglés.

El peligro de las patentes de software

por Richard Stallman

Esta es la transcripción de una charla impartida por Richard M. Stallman el 8 de octubre de 2009 en la Universidad Victoria de Wellington.

SF:

Me llamo Susy Frankel, y en nombre de Meredith Kolsky Lewis y en el mío propio quiero darles la bienvenida a este seminario organizado por el Centro de Derecho Económico Internacional de Nueva Zelanda. Brenda Chawner, que no es miembro del Centro de la Facultad de Derecho que acabo de mencionar, sino de la Escuela de Gestión Informática de la Universidad Victoria, es la verdadera responsable de que tengamos de nuevo a Richard Stallman en Nueva Zelanda y la organizadora de su gira por el país, incluida su escala en Wellington esta noche. Lamentablemente no puede acompañarnos en este momento porque está haciendo lo que solemos hacer en las universidades: dar clase.

Es para mí un placer darles la bienvenida a la conferencia «El peligro de las patentes de software». Richard Stallman propone una serie de temas para sus conferencias y, después de discutirlo con Brenda, elegí este porque por primera vez en la historia de Nueva Zelanda se está manteniendo un debate algo prolongado, pero importante, acerca de la reforma de la Ley de patentes, y muchos de los aquí presentes ejercen un papel de responsabilidad en el debate en torno a las patentes de software. Así que nos pareció de actualidad y muy oportuno. Gracias, Richard, por la propuesta.

Richard Stallman no necesita mucha presentación. Sin embargo, para quienes no hayan oído hablar de él, es el iniciador del desarrollo del sistema operativo GNU. Nunca antes había oído pronunciar GNU y acudí a la página de YouTube (qué sería de nosotros sin YouTube)...

RMS:
Vaya, no deberías recomendar YouTube, pues utilizan un formato de vídeo patentado.
SF:
Buena observación. Lo recomendaba solo para saber si se pronuncia G-N-U o GNU.
RMS:
La Wikipedia lo dice. [Hay que pronunciarlo como una sílaba sin vocal entre la g y la n; o, en español, como «ñu»].
SF:
Sí, pero en YouTube pude oír cómo lo pronunciabas [1]. No obstante, lo importante es que no es privativo. Pero lo más interesante es que Richard ha recibido muchos premios por su trabajo. Mi favorito, y por eso voy a mencionarlo, es el Premio Takeda al Mejoramiento Social y Económico, e imagino que hoy se va a hablar mucho de esto. Demos pues la bienvenida a Richard.
RMS:

En primer lugar me gustaría mencionar que una de las razones por las que estoy bebiendo esto [una lata de cola que no es Coca-Cola] es el boicot mundial a la compañía Coca-Cola por el asesinato de sindicalistas en Colombia. Echen un vistazo a la página killercoke.org. Ahí no hablan de los efectos de beber ese producto (a fin de cuentas son los mismos que los de otros muchos productos similares), sino de asesinatos. De modo que antes de comprar una bebida, miren la etiqueta para ver si está fabricada por la compañía Coca-Cola.

Se me conoce sobre todo por haber iniciado el movimiento del software libre y liderar el desarrollo del sistema operativo GNU, aunque la mayoría de los que lo usan creen erróneamente que es Linux y piensan que lo inició otra persona una década después. Pero hoy no voy a hablar de eso. Estoy aquí para hablarles de un peligro legal que se cierne sobre todos los desarrolladores, distribuidores y usuarios de software: el peligro de las patentes sobre ideas y técnicas computacionales, sobre cualquier idea para hacer algo con un ordenador.

Ahora bien, para entender este asunto, de lo primero que tenemos que darnos cuenta es de que la ley de patentes no tiene nada que ver con la ley de copyright, son totalmente diferentes. Cualquier cosa que sepamos sobre una de ellas seguramente no es aplicable a la otra.

Así, por ejemplo, cada vez que alguien dice algo sobre la «propiedad intelectual» está difundiendo la confusión, pues está metiendo en el mismo saco no solo estas dos leyes sino al menos una docena más. Todas son diferentes, y el resultado es que cualquier declaración que pretende referirse a la «propiedad intelectual» es una pura confusión: o bien la persona que la hace está confundida, o bien está tratando de confundir a los demás. En cualquier caso, sea a propósito o por inadvertencia, es una confusión.

Evitemos esta confusión rechazando cualquier declaración que haga uso de esa expresión. La única manera de hacer comentarios razonados y pensar con claridad acerca de alguna de estas leyes es, ante todo, distinguirla de todas las demás y mencionar o pensar en una en particular, de modo que podamos entender cuáles son sus efectos reales y así extraer luego conclusiones acerca de ella. De manera que voy a hablarles de la ley de patentes y de lo que sucede en aquellos países que han permitido que la ley de patentes ponga límites al software.

¿En qué consiste pues una patente? Una patente es un monopolio explícito, concedido por el Gobierno, para el uso de una idea. En la patente hay una parte llamada «reivindicaciones» que describe exactamente lo que se prohíbe hacer (si bien la redacción puede resultar incomprensible). Es extenuante tratar de hacerse una idea de lo que realmente significan esas prohibiciones, que pueden extenderse hasta ocupar muchas páginas en letra pequeña.

Normalmente la patente suele durar veinte años, que es mucho tiempo en nuestro campo. Hace veinte años no existía la red mundial de Internet, mientras que hoy en día una enorme cantidad de ordenadores opera en un área que en aquel entonces ni siquiera estaba en proyecto. De modo que todo lo que la gente hace en Internet es algo nuevo con respecto a veinte años atrás, nuevo al menos en algunos aspectos. Si se hubieran autorizado las patentes, todo lo que hoy hacemos estaría prohibido, y podría estar prohibido en aquellos países que han cometido la insensatez de adoptar esa política.

Quienes explican la función del sistema de patentes son casi siempre personas que tienen intereses creados en él. Puede tratarse de abogados especialistas en patentes, o puede que trabajen en la Oficina de Patentes o que formen parte de la sección de patentes de una megacorporación, de modo que su objetivo es hacer que el sistema nos resulte apetecible.

En cierta ocasión The Economist se refirió al sistema de patentes como «una lotería que consume mucho tiempo». Si alguna vez han visto publicidad de la lotería entenderán cómo funciona: hablan mucho de la posibilidad de ganar, lo que es muy improbable, pero no mencionan la apabullante probabilidad de perder. De esta manera, presentan intencional y sistemáticamente un panorama distorsionado de lo que muy posiblemente sucederá al apostar, sin que en realidad estén mintiendo sobre nada en particular.

Lo mismo sucede con la publicidad en favor del sistema de patentes: hablan de lo que significa ir por ahí con una patente en el bolsillo o, mejor, primero mencionan lo que implica conseguir una patente y luego lo que es tenerla en el bolsillo y sacarla a relucir de vez en cuando para apuntar a alguien diciéndole: «¡Dame tu dinero!».

Para compensar este punto de vista sesgado voy a describirlo desde el otro lado, el lado de la víctima: lo que implica para quienes quieren desarrollar, distribuir o utilizar software. Estas personas quedan sometidas al temor de que en cualquier momento alguien les aborde con una patente en la mano exclamando: «¡Dame tu dinero!».

En un país que permite las patentes de software, ¿cómo tendrán que proceder quienes quieran desarrollar software dentro del marco de la ley?

Una posibilidad sería que el programador intente enumerar todas las ideas que podrían estar incluidas en el programa que va a escribir, pero tengamos en cuenta que eso es algo que aún no se sabe cuando se comienza a escribir el programa; ni siquiera después de haber terminado de escribirlo se puede elaborar una lista de ese tipo.

La razón es que el programa se ha concebido de una manera determinada: el desarrollador dispone de una estructura mental que aplica al diseño del programa y esto le impide ver otras estructuras que alguien podría emplear para analizar el mismo programa. El programa no ha surgido de buenas a primeras, sino que se ha diseñado teniendo en mente una cierta estructura. Alguien que lo vea por primera vez podría observar una estructura diferente que incluye ideas diferentes, y sería complicado para el programador detectar cuáles son esas otras ideas. Y sin embargo están implementadas en su programa, y si esas ideas están patentadas el programa podría resultar ilícito.

Supongamos por ejemplo que existen patentes sobre las ideas para diseños gráficos y que usted quiere dibujar un cuadrado. Bien, descubriría que si existiera una patente sobre los bordes inferiores, su cuadrado sería ilegítimo. Podría incluir «borde inferior» en la lista de todas las ideas implementadas en su dibujo, pero quizá no caiga en la cuenta de que alguien que posea una patente sobre «ángulos hacia abajo» podría fácilmente demandarlo, pues podría coger su dibujo y girarlo 45 grados. Ahora su cuadrado sí tiene un ángulo hacia abajo.

De manera que nunca se podría hacer una lista completa de todas las ideas que en caso de estar patentadas afectarían a la legitimidad de un programa.

Lo que el programador podría hacer es tratar de descubrir todas la ideas patentadas que podría contener el programa, aunque en realidad esto tampoco es posible porque las solicitudes de patentes se mantienen en secreto al menos durante dieciocho meses. Es decir, simultáneamente la Oficina de Patentes podría estar considerando la emisión de una patente sin informar al programador. Y esto no es solo una posibilidad teórica.

Por ejemplo, en 1984 se escribió el programa Compress, un programa para comprimir archivos utilizando el algoritmo de compresión de datos LZW, y por aquel entonces no había ninguna patente sobre el uso de ese algoritmo para comprimir archivos. El autor tomó ese algoritmo de un artículo publicado en una revista. Eso sucedió cuando pensábamos que el propósito de las revistas de informática era publicar algoritmos para que la gente pudiera utilizarlos.

Escribió el programa, lo publicó, y en 1985 se emitió una patente sobre ese algoritmo. Pero el titular de la patente fue astuto y no empezó inmediatamente a decir a la gente que dejara de utilizarlo, sino que pensó: «Dejemos que sigan cavando su tumba». Pocos años más tarde empezaron a amenazar. Estaba claro que no podíamos utilizar Compress, así que pedí a la gente que sugiriera otros algoritmos que pudiéramos utilizar para comprimir archivos.

Alguien respondió diciendo: «He desarrollado otro algoritmo de compresión de datos que funciona mejor. He escrito un programa y quisiera dároslo». De modo que nos dispusimos a publicarlo, pero una semana antes de que estuviera listo para su publicación, leí la columna semanal sobre patentes del New York Times —cosa que rara vez hacía, quizá un par de veces al año—, y vi por casualidad que alguien había obtenido una patente por «inventar un nuevo método de compresión de datos». Así que dije que teníamos que analizar esto y, en efecto, vimos que cubría el programa que estábamos por publicar. Pero podría haber sido peor: la patente se podría haber emitido un año después, o dos, o tres, o cinco años más tarde.

De todos modos, alguien propuso otro algoritmo aún mejor, que se utilizaba en el programa gzip, y casi todo el mundo que quería comprimir archivos se pasó a gzip, lo que suena a final feliz. Pero no lo es del todo.

De manera que no se puede saber nada acerca de las solicitudes que la Oficina de Patentes está considerando, a pesar de que la obra del programador podría resultar ilícita una vez emitidas las patentes, pero sí es posible conocer las patentes ya emitidas. Todas están publicadas por la Oficina de Patentes. El problema es que uno no puede leerlas todas, pues son demasiadas.

En EE. UU. hay, según creo, cientos de miles de patentes de software, por lo que hacer un seguimiento de ellas sería un trabajo tremendo. De manera que habrá que buscar las patentes pertinentes. Y se encontrará un montón de ellas, pero no necesariamente todas.

Por ejemplo, en los ochenta y noventa había una patente sobre el «recálculo por ordenación natural» en las hojas de cálculo. Alguien me pidió una vez una copia de ella, así que busqué en el ordenador el archivo con el listado de patentes. La saqué del cajón, la fotocopié y se la envié. Y cuando la recibió me dijo: «Debes de haberte equivocado de patente. Esta trata de compiladores». Pensé que quizá llevaba un número equivocado. La busqué otra vez y efectivamente decía: «Un método para compilar fórmulas en código objeto». De modo que empecé a leerla para comprobar si de verdad me había equivocado de patente. Leí las reclamaciones y, en efecto, era la patente sobre el recálculo por ordenación natural, pero no utilizaba esos términos. No utilizaba la expresión «hoja de cálculo». De hecho, lo que la patente prohibía eran docenas de maneras diferentes de implementar la ordenación topológica, todas las que se les ocurrieron. Pero creo que no utilizaban la expresión «ordenación topológica».

Así que si alguien hubiese estado escribiendo una hoja de cálculo y hubiese tratado de encontrar las patentes relevantes podría haber encontrado multitud de ellas. Pero no habría encontrado esta, a menos que le hubiera comentado a alguien: «Mira, estoy trabajando en una hoja de cálculo», y este le dijera: «Vaya, ¿sabías que están demandando a otras compañías que están haciendo hojas de cálculo?». Así sí la habría descubierto.

Bien, no es posible encontrar todas las patentes mediante una búsqueda, pero se pueden encontrar muchas. Y luego hay que adivinar lo que quieren decir, pues las patentes están redactadas en un enrevesado lenguaje legal que hace muy difícil comprender su verdadero significado. De modo que hay que perder un montón de tiempo hablando con un costoso abogado para explicarle lo que se quiere hacer y así él pueda decirnos si estamos autorizados a hacerlo.

A menudo ni siquiera los titulares de las patentes son capaces de comprender lo que sus patentes significan. Por ejemplo, alguien llamado Paul Heckel, que publicó un programa para mostrar muchos datos en una pantalla pequeña, consiguió un par de patentes apoyándose en un par de ideas presentes en ese programa.

En una ocasión traté de hallar una manera sencilla de describir qué cubría la reivindicación 1 de una de esas patentes. Descubrí que no podía encontrar ninguna manera más simple de decirlo que como se formulaba en la patente misma. Y era una frase tal que por mucho que lo intentara no lograba repetirla toda de corrido.

Y tampoco Heckel la comprendía, pues cuando vio HyperCard lo único que advirtió es que no tenía nada que ver con su programa. No se le ocurrió que tal como estaba redactada la patente podría prohibir HyperCard, pero su abogado sí lo pensó y amenazó a Apple. Luego amenazó a los clientes de Apple y finalmente Apple llegó a un acuerdo con Heckel, pero el acuerdo es secreto, de modo que no sabemos quién ganó realmente. Y esto es sólo una muestra de lo complicado que puede ser para cualquiera entender qué prohíbe y qué no prohíbe una patente.

De hecho, una vez di esta charla y Heckle se encontraba entre el público. Cuando toqué este punto, Heckel se levantó de un salto exclamando: «Eso no es cierto, yo desconocía el alcance de mi protección». Y le respondí: «Sí, eso es lo que he dicho», ante lo cual se sentó y ese fue el final de mi experiencia de ser interrumpido por Heckel[2]. Si le hubiera respondido negativamente, probablemente habría encontrado la manera de entablar una discusión conmigo.

En cualquier caso, después de una larga y costosa conversación con un abogado, este responderá algo así:

Si hace algo en esta área, es casi seguro que perderá el pleito; si hace algo en esta área, existen bastantes posibilidades de que pierda el pleito; y si realmente quiere estar a salvo, tendrá que mantenerse alejado de esta área. Pero en cualquier pleito hay un amplio margen para el azar.

Entonces, ahora que disponemos de unas reglas claras y previsibles para hacer negocios, ¿qué es lo que vamos a hacer? Bien, hay tres cosas que se pueden hacer al enfrentarse a cualquier patente concreta. Una es evitarla, otra obtener una licencia y la tercera invalidarla. Me referiré a cada una de ellas.

Primero, existe la posibilidad de evitar la patente, lo que se traduce en no implementar lo que prohíbe. Pero, por supuesto, si es difícil saber lo que prohíbe, también será difícil saber cómo evitarla.

Hace un par de años, Kodak demandó a Sun apoyándose en una patente de algo que tenía que ver con la programación orientada a objetos. Sun no creía que estuviera infringiendo esa patente, pero el tribunal dictaminó que sí, y cuando otra gente consulta la patente no tiene la menor idea de si la decisión fue correcta o no. Nadie puede entender qué cubre o no cubre esa patente, pero Sun tuvo que pagar cientos de millones de dólares por violar una ley absolutamente incomprensible.

A veces uno puede saber lo que hay que evitar, y en ocasiones lo que tiene que evitar es un algoritmo.

Por ejemplo, vi una patente para algo parecido a la transformada rápida de Fourier (FFT), pero que corría el doble de rápido. Bueno, pues si la FFT clásica es lo bastante rápida para el programa que se está desarrollando, esta patente se puede evitar fácilmente. Esto se puede hacer casi siempre sin dificultad. Pero puede suceder que alguna vez se esté tratando de hacer un programa que para funcionar utilice FFT constantemente, y que el algoritmo más rápido sea apenas suficiente para el funcionamiento del programa. En ese caso no es posible evitarla, aunque quizá se pueda esperar un par de años para disponer de un ordenador más rápido. Pero esto raramente sucederá. Casi siempre será fácil evitar esa patente.

Por otro lado, una patente sobre un algoritmo puede ser imposible de evitar. Tomemos el algoritmo de compresión de datos LZW. Bien, como he explicado, encontramos un algoritmo de comprensión de datos mejor, y todos los que querían comprimir archivos se pasaron al programa gzip, que utilizaba ese algoritmo. La razón es que si se quiere comprimir un archivo para después descomprimirlo, puede decírsele a la gente que utilice este programa para descomprimirlo; luego se puede utilizar cualquier programa con cualquier algoritmo, lo único que importa es que funcione bien.

Pero el LZW se utiliza también para otras cosas. Por ejemplo, el lenguaje PostScript especifica operadores para compresión y descompresión LZW. De nada sirve disponer de otro algoritmo mejor porque formateará los datos de manera diferente. No son interoperables. Si se comprime con el algoritmo gzip, no se podrá descomprimir utilizando LZW. De modo que por bueno que sea el otro algoritmo, sea cual sea, no nos permitirá implementar PostScript de acuerdo a las especificaciones.

Pero me di cuenta de que es raro que los usuarios quieran que sus impresoras compriman algo. Por lo general lo único que quieren que hagan sus impresoras es descomprimir, y advertí también que las dos patentes sobre el algoritmo LZW estaban redactadas de tal modo que si el sistema puede solamente descomprimir, entonces no está prohibido. Estas patentes fueron redactadas de manera que cubrieran la compresión, y tenían otras reivindicaciones que cubrían la compresión y la descompresión, pero no había ninguna reivindicación que cubriera solo la descompresión. Así que si implementábamos únicamente la descompresión para LZW, estaríamos a salvo. Y, aunque no satisfaría las especificaciones, sería lo bastante útil para los usuarios, haría lo que en realidad necesitaban. Y así es como, por los pelos, evitamos las dos patentes.

Ahora existe el formato GIF para imágenes, que también utiliza el algoritmo LZW. No hizo falta mucho tiempo para que se ideara otro formato de imágenes llamado PNG, siglas que corresponden a «PNG's Not GIF» (PNG No es GIF). Creo que utiliza el algoritmo gzip. Y empezamos a decir a la gente: «No utilice GIF, es peligroso. Cámbiese a PNG». Y los usuarios dijeron: «Bueno, quizá algún día, pero ahora los navegadores aún no lo implementan», y los desarrolladores de navegadores dijeron: «Es posible que lo implementemos algún día, pero no hay mucha demanda de los usuarios».

Es bastante obvio lo que sucedía: GIF era un estándar de facto. Y pedir a la gente que se cambie a un formato diferente, en lugar de su estándar de facto, es como pedir a todos los habitantes de Nueva Zelanda que hablen en húngaro. La gente dirá: «Bueno, lo aprenderé cuando otros lo hagan». Y así sucedió que nunca conseguimos que la gente dejara de usar GIF, a pesar de que uno de los titulares de la patente andaba amenazando a los gestores de páginas web con demandarlos a menos que pudieran probar que todos los GIF de sus páginas habían sido hechos con software autorizado, con su licencia correspondiente.

De modo que GIF era una peligrosa trampa para gran parte de nuestra comunidad. Creíamos que teníamos una alternativa al formato GIF, el JPEG, pero entonces alguien dijo: «Estaba hojeando mi cartera de patentes» —creo que se trataba de alguien que compró patentes y las utilizó para amenazar— «y descubrí que una de ellas cubre el formato JPEG».

Ahora bien, JPEG no era un estándar de facto, es un estándar oficial, establecido por un comité de estándares; y el comité tenía también un abogado. El abogado dijo que no creía que esa patente cubriera en realidad el formato JPEG.

Entonces, ¿quién tiene razón? Bien, este titular de la patente demandó a una serie de compañías, y si hubiera una sentencia esta nos diría quien tenía razón. Pero yo no he tenido noticia de ninguna sentencia, ni siquiera estoy seguro de que haya habido alguna. Creo que llegaron a un acuerdo, y casi con seguridad el acuerdo es secreto, lo que significa que no podemos saber quién está en lo cierto.

Estos son casos de relativo poco peso: una patente sobre JPEG y dos patentes sobre el algoritmo LZW empleado en GIF. Ahora podríamos preguntarnos cómo es que hay dos patentes sobre el mismo algoritmo. Eso no debería suceder, pero sucedió. Y la razón es que los examinadores de patentes no pueden dedicar el tiempo necesario para analizarlo y compararlo todo, porque no se les permite tomarse tanto tiempo. Y como los algoritmos son solo matemáticas, no hay manera de determinar cuáles son las solicitudes y patentes que es preciso comparar.

En asuntos de ingeniería física, pueden apoyarse en la naturaleza física de lo que ocurre para restringir el campo. Por ejemplo, en ingeniería química, pueden plantearse: «¿Cuáles son las sustancias que se agregan?, ¿cuáles son las sustancias que se obtienen?». Si dos solicitudes de patente son diferentes en ese sentido, entonces no es el mismo proceso y no hay de qué preocuparse. En cambio en el campo de las matemáticas una misma cosa se puede representar de maneras que pueden parecer muy diferentes, y hasta que no se las estudie comparándolas, no es posible percatarse de que se están refiriendo a lo mismo. Y debido a esto es bastante habitual encontrarse con que la misma cosa ha sido patentada multitud de veces.

¿Recuerdan aquel programa que quedó fulminado antes de que lo publicáramos? Pues bien, también ese algoritmo fue patentado dos veces. Ya hemos visto que en un pequeño campo nos hemos tropezado con dos casos en los que el mismo algoritmo ha sido patentado dos veces. Bueno, creo que con mi explicación se entiende por qué pasa eso.

Pero los casos con una o dos patentes son bastante sencillos. ¿Qué sucede con MPEG2, el formato de vídeo? Una vez vi una lista de más de setenta patentes que lo cubrían, y las negociaciones para acordar la manera en que alguien pudiera obtener una licencia para todas esas patentes llevaron más tiempo que desarrollar el estándar mismo. El comité del JPEG quería desarrollar un estándar suplementario, pero desistieron. Dijeron que había demasiadas patentes y que no había forma de hacerlo.

En ocasiones lo que está patentado es una funcionalidad, y la única manera de evitar la patente es no implementar esa funcionalidad. Por ejemplo, los usuarios del procesador de textos Xywrite recibieron una vez por correo una actualización que suprimía una funcionalidad. Esta consistía en definir una lista de abreviaturas. Por ejemplo, si se define «exp» como abreviatura de «experimento», al escribir «exp-espacio» o «exp-coma», «exp» será automáticamente sustituido por «experimento».

Entonces alguien que había patentado esa funcionalidad los amenazó, y concluyeron que lo único que podían hacer era retirarla. De modo que enviaron a todos los usuarios una versión sin esa funcionalidad.

Pero también se pusieron en contacto conmigo, pues mi editor Emacs incluía una funcionalidad de ese tipo ya desde finales de los años setenta. Y como la funcionalidad estaba descrita en el manual de Emacs, pensaron que yo podría ayudarles a invalidar esa patente. Bueno, me alegra saber que al menos he tenido una idea patentable en mi vida, pero me apena que la haya patentado otro.

Afortunadamente esa patente fue finalmente invalidada, y en parte debido al hecho de que yo había publicado la descripción de la función con anterioridad. Pero mientras tanto ellos habían tenido que retirarla.

Eliminar una o dos funcionalidades puede no ser un desastre. Pero cuando se tienen que retirar cincuenta, puede hacerse, pero es probable que la gente opine: «Este programa no es bueno, le faltan todas las características que quiero». De modo que puede no ser la solución. Y a veces una patente es tan amplia que acaba con todo un campo, como la patente sobre el cifrado de clave pública, que de hecho prohíbe el cifrado de clave pública por unos diez años.

Así que esa es una opción para evitar una patente. A menudo es posible, pero otras veces no, y el número de patentes que se pueden evitar es limitado.

¿Y qué hay de la siguiente posibilidad, obtener una licencia para la patente?

Bueno, puede suceder que el titular de la patente no ofrezca una licencia. Depende completamente de él. Él podría decir: «Lo único que quiero es acabar con su actividad». Una vez recibí una carta de alguien que tenía una empresa familiar para hacer juegos de casino, que naturalmente estaban computarizados, y que recibió la amenaza del titular de una patente que quería hacer que su negocio cerrara. Me envió la patente. La Reclamación 1 era algo así como «una red con una multiplicidad de ordenadores, en la cual cada ordenador gestiona una multiplicidad de juegos y permite una multiplicidad de sesiones de juego al mismo tiempo».

Bueno, estoy seguro de que en los años ochenta una universidad había montado un aula con una red de estaciones de trabajo, y cada una disponía de algún tipo de sistema de ventanas. Todo lo que tenían que hacer era instalar múltiples juegos y eso permitiría desplegar múltiples sesiones de juego a la vez. Esto es tan trivial y carente de interés que nadie se habría molestado en publicar un artículo acerca de ello. Nadie habría tenido interés en publicar un artículo acerca de eso, pero sí mereció una patente. Si a uno se le hubiera ocurrido que podría conseguir el monopolio de esto que es tan trivial, entonces podría utilizarlo para obligar a sus competidores a cerrar el negocio.

¿Pero por qué la Oficina de Patentes emite tantas patentes que nos parecen absurdas y triviales?

No es porque quienes examinan las patentes sean estúpidos; es porque siguen un sistema, el sistema tiene sus reglas y esas reglas conducen a este resultado.

Si alguien ha confeccionado una máquina que hace algo una vez, y otro diseña una máquina que hace eso mismo pero N veces, para nosotros eso es un bucle for, pero para la Oficina de Patentes es una invención. Si hay máquinas que pueden hacer A, y máquinas que pueden hacer B, y alguien diseña una máquina que puede hacer A o B, para nosotros eso es una declaración if-then-else, pero para la Oficina de Patentes es una invención. De manera que tienen unos criterios muy laxos, y esos son los criterios que siguen. El resultado es que hay patentes que nos resultan absurdas y triviales. No puedo decir si son legalmente válidas o no, pero cualquier programador que las vea se echará a reír.

De todos modos, no pude sugerirle nada que le fuera de ayuda, y tuvo que cerrar su negocio. Pero la mayoría de los titulares de patentes ofrecen una licencia. Y es probable que sea bastante costosa.

Pero hay desarrolladores de software a quienes casi siempre les resulta bastante sencillo obtener licencias. Se trata de las megacorporaciones. En cualquier sector, las megacorporaciones generalmente poseen alrededor de la mitad de las patentes, se conceden entre ellas licencias cruzadas y pueden obligar a cualquiera que esté realmente produciendo algo a que les conceda licencias cruzadas. La consecuencia es que acaban teniendo licencias para casi todas la patentes sin mayores dificultades.

IBM publicó un artículo en Think, la revista de la compañía (creo que era el número cinco de 1990), acerca de los beneficios que obtuvo de las casi 9.000 patentes estadounidenses que poseía en aquel momento, que ahora ascienden a unas 45.000 o más. Decían ahí que uno de los beneficios era el dinero que les reportaban, pero que el principal provecho —que según afirmaban era quizá de un orden de magnitud mayor— consistía en «tener acceso a las patentes de otros», es decir, las licencias cruzadas.

Esto significa que, al disponer de tantas patentes, IBM puede hacer que casi todo el mundo le conceda una licencia cruzada, con lo cual queda casi por completo exenta del agobio que el sistema de patentes provoca a los demás. Es por esta razón que IBM es favorable a las patentes de software. Es por esta razón que las megacorporaciones en general son favorables a las patentes de software, porque saben que con las patentes cruzadas dispondrán de un club exclusivo en la cima. Y los demás nos quedaremos aquí abajo, sin posibilidad de llegar hasta allí. Si uno es un genio, podría montar una pequeña empresa y obtener algunas patentes, pero haga lo que haga, nunca ingresará en la liga de IBM.

Muchas compañías dicen ahora a sus empleados: «Consígannos patentes para que podamos defendernos», cuando en realidad lo que quieren decir es: «Las usaremos para tratar de obtener patentes cruzadas». Pero eso no funciona muy bien. No es una estrategia eficaz si solo se posee un pequeño número de patentes.

Supongamos que tenemos tres patentes. Una apunta hacia allí, otra hacia allá y otra hacia el otro lado, y alguien nos apunta con una patente. Pues bien, nuestras tres patentes no nos servirán de nada, pues ninguna de ellas apunta hacia él. Por otro lado, tarde o temprano alguien de nuestra compañía se dará cuenta de que una de nuestras patentes apunta de hecho hacia otras personas a las que podemos amenazar y sacarles dinero, sin importar que esa gente no nos haya atacado.

De modo que si su empleador le dice: «Necesitamos algunas patentes para defendernos, así que ayúdenos a conseguirlas», recomiendo la siguiente respuesta:

Jefe, confío en usted y estoy seguro de que solo utilizará esas patentes para defender a la compañía ante un ataque. Pero no sé quién será el presidente de esta compañía dentro de cinco años. Por lo que sé, es posible que Microsoft la compre. De manera que no puedo confiar en la palabra de la compañía de que utilizará esas patentes solo para defenderse, a menos que lo tenga por escrito. Ponga por favor por escrito que cualquier patente que yo proporcione a la compañía se utilizará únicamente para la autodefensa y la seguridad colectiva, y no para la represión, y así podré conseguir patentes para la compañía con la conciencia limpia.

Sería más interesante plantear esto no solo en privado con el jefe, sino también en la lista de discusión de la compañía.

Otra cosa que podría suceder es que la compañía quebrara y sus activos fueran subastados, incluidas las patentes, y que las patentes fueran adquiridas por alguien que se propone utilizarlas con malas intenciones.

Es muy importante entender la práctica de las licencias cruzadas, pues es esto lo que echa por tierra el argumento de los defensores de las patentes de software, que dicen que son necesarias para proteger a los genios que se mueren de hambre. Presentan un escenario con una serie de supuestos que es muy improbable que se produzcan.

Veámoslo. Tal como presentan el escenario, habría un brillante diseñador de alguna cosa que ha estado trabajando durante años por su cuenta en un ático y finalmente descubre una técnica mejor para hacerla. Y ahora que la cosa ya está lista, quiere montar un negocio para producirla a gran escala. Como la idea es tan buena, el éxito de su empresa está asegurado, excepto por un detalle: las grandes compañías competirán con él para echarlo del mercado, y debido a esto, casi con toda seguridad su negocio fracasará y él acabará en la miseria.

Bien, veamos todas las suposiciones improbables que hay aquí.

La primera es que él descubre la idea por sí solo. Eso es muy improbable. En el terreno de las altas tecnologías, la mayor parte del progreso se debe a gente que trabaja en un determinado sector en el que hace cosas y se comunica con otras personas del mismo sector. Pero no diría que es imposible, no eso por sí solo.

La otra suposición es que va a montar un negocio y que será un éxito. Bueno, que sea un brillante ingeniero no significa que sea capaz de llevar un negocio. La mayoría de los negocios nuevos fracasa; más del 95%, creo, fracasan en pocos años. De modo que eso es lo que probablemente le sucederá, independientemente de lo demás.

Bien, supongamos que además de ser un brillante ingeniero que descubre algo grande por su cuenta, también tiene talento para llevar un negocio. Si es bueno para los negocios, quizá no fracase. Al fin y al cabo, no todos los negocios fracasan, algunos pocos prosperan. Pero si sabe de negocios, en vez de tratar de competir con las grandes compañías, podría tratar de hacer cosas en las que las pequeñas empresas son mejores y así tendría más posibilidades de éxito. Podría tener éxito. Pero supongamos que de todos modos fracasa. Si es tan brillante y tiene habilidad para los negocios, estoy seguro de que no acabará en la miseria, pues alguien querrá contratarlo.

Así pues, una serie de supuestos tan improbables no conforman un escenario plausible. Pero examinémoslo de todos modos.

Porque esto les lleva a decir que el sistema de patentes «protegerá» a nuestro pobre genio, pues puede patentar su técnica. Y afirman que entonces, cuando IBM quiera competir con él, él podrá decir: «IBM, no puedes competir conmigo porque tengo esta patente», y que la reacción de IBM será: «¡Oh, no, otra vez no!».

Pues bien, lo que realmente sucederá es lo siguiente.

IBM dirá: «Oh, qué bien, tienes una patente. Bueno, pues nosotros tenemos esta, y esta, y esta, y esta, y esta otra, todas las cuales cubren otras ideas que están implementadas en tu producto, y si crees que puedes con estas sacaremos algunas más. De modo que firmemos un acuerdo de licencias cruzadas y así nadie sufrirá daños». Como hemos dado por sentado que nuestro genio sabe de negocios, se dará cuenta de que no tiene alternativa. Firmará el acuerdo de licencias cruzadas, como hace casi todo el mundo cuando IBM lo exige. Y esto quiere decir que IBM tendrá «acceso» a esta patente, lo que significa que IBM podrá competir con él como si no hubiera patentes, lo que significa a su vez que el supuesto beneficio que aducen que obtendría al tener esa patente no es real. No obtendrá tal beneficio.

La patente podría «protegerlo» de la competencia de ustedes o de la mía, pero no de IBM, no de las megacorporaciones que, según el escenario que acabamos de ver, lo amenazan. Cuando son los grupos de presión de las megacorporaciones quienes recomiendan una normativa supuestamente para proteger a sus pequeños competidores, se sabe de antemano que el razonamiento va a estar viciado. Si la normativa sirviera en realidad para eso, no la apoyarían. Pero esto explica por qué no sirven para eso.

Ni siquiera IBM puede hacerlo siempre, pues hay compañías, a las que llamamos troles de patentes o parásitos de patentes, cuya única actividad consiste en utilizar las patentes para sacarle dinero a la gente que realmente hace algo.

Los abogados especializados en patentes nos dicen que es estupendo tener patentes en nuestro sector, pero ellos no las tienen en el suyo. No hay patentes sobre la manera de enviar o redactar una carta amenazante, ni sobre cómo interponer una demanda, ni sobre el modo de persuadir a un juez o a un jurado. De manera que ni siquiera IBM puede imponer un acuerdo de patentes cruzadas a los troles de patentes. Pero IBM hace sus cálculos: «Nuestros competidores también tendrán que pagarles; esto no es más que parte del coste de hacer negocios y podemos vivir con ello». IBM y las demás megacorporaciones estiman que el predominio que obtienen con sus patentes en todas las actividades las beneficia, por lo que vale la pena pagar la mordida a los troles. Esa es la razón de que estén a favor de las patentes de software.

Hay también desarrolladores de software a quienes les resulta muy difícil obtener la concesión en licencia de una patente, son los desarrolladores de software libre. La razón es que la licencia habitual para patentes contiene condiciones que no nos es posible cumplir. Por ejemplo, estas licencias generalmente imponen un pago por copia, y cuando el software otorga a los usuarios la libertad de distribuir y hacer más copias, no tenemos manera de contar las copias que existen.

Si alguien me ofrece una licencia para una patente a cambio del pago de una millonésima parte de dólar por copia, la cantidad total de dinero que tendría que pagar está ahora en mi bolsillo. Quizá sean 50 dólares, pero yo no sé si son 50, o 49, o cuánto, porque no tengo manera de contar las copias que ha hecho la gente.

No obstante, el titular de una patente no está obligado a exigir un pago por copia, puede también ofrecerle una licencia a cambio del pago de una cantidad fija, pero estas cantidades tienden a ser elevadas, por ejemplo cien mil dólares.

Y la razón de que hayamos logrado desarrollar tanto software que respeta la libertad es que podemos hacerlo sin dinero, pero sin dinero no podemos pagar mucho dinero. Si se nos obliga a pagar por el privilegio de escribir software para el público, no podremos hacerlo mucho.

Bien, esa es la opción de obtener una licencia para la patente. La otra opción es invalidar la patente. Si un país considera que las patentes de software son fundamentalmente válidas y las permite, lo único que queda por ver es si esta patente concreta cumple los requisitos de validez. Acudir a los tribunales solo es útil si se puede presentar un argumento sólido capaz de imponerse.

¿Cuál sería ese argumento? Habrá que probar que años atrás, antes de que se solicitara la patente, esa idea ya se conocía. Y habrá que encontrar hoy pruebas que demuestren que en aquella época era conocida públicamente. De modo que los dados se echaron años antes, y si el resultado fue favorable a nosotros, y podemos probar ese hecho hoy, entonces disponemos de un argumento al que acogernos para tratar de invalidar la patente. Y podría funcionar.

Nos podría costar mucho dinero llevar adelante ese pleito, y si no tenemos mucho dinero, una patente probablemente inválida es un arma terrible con la que pueden amenazarnos. Hay gente, mucha gente, que no puede permitirse defender sus derechos. Los que pueden hacerlo son la excepción.

Pues bien, esas son las tres cosas que se podrían hacer cada vez que nos encontramos con una patente que prohíbe la implementación de algo en nuestro programa. La cuestión es que la posibilidad de llevarlas a cabo depende de los detalles y circunstancias de cada caso, de modo que algunas veces ninguna de ellas será factible. Y cuando esto sucede, el proyecto puede darse por muerto.

Pero en la mayoría de los países los abogados nos aconsejan: «No trate de encontrar las patentes de antemano», y la razón es que las sanciones por infracción son mayores si se demuestra que ya conocíamos la existencia de la patente. Así que lo que dicen es: «Cierre los ojos. No trate de investigar sobre las patentes. Tome las decisiones de diseño a ciegas con la esperanza de que no pase nada».

Claro, seguramente no tropezaremos con una patente en todas y cada una de las decisiones que tomemos. Quizá no suceda nada. Pero son tantos los pasos que hay que dar para atravesar ese campo minado que es muy improbable que salgamos indemnes. Y, por supuesto, los titulares de patentes no aparecen todos a la vez, de modo que nunca se sabe cuántos habrá.

El titular de la patente sobre el recálculo por ordenación natural solicitaba el 5% del precio en bruto de cada hoja de cálculo. Sería concebible pagar por unas pocas de tales licencias, ¿pero qué sucederá cuando aparezca el titular de patente número 20 y pretenda que le paguemos el último 5%? ¿Y qué sucederá cuando aparezca el titular de patente número 21?

La gente del mundo de los negocios opina que este escenario es divertido pero absurdo, pues el proyecto habría fracasado mucho antes de llegar a ese punto. Me han dicho que dos o tres de tales licencias harían ya fracasar el proyecto. Así que nunca se llegará a veinte. Aparecen una a una, de modo que nunca se sabe cuántas más están por llegar.

Las patentes de software son un desastre. Son un desastre para los desarrolladores de software, pero además imponen una restricción a todo usuario de ordenadores, pues las patentes de software limitan lo que cada uno puede hacer con su ordenador.

Hay una gran diferencia con otras patentes como por ejemplo las patentes sobre los motores de automóviles, porque estas imponen restricciones únicamente a las empresas que fabrican automóviles, pero no a ustedes ni a mí. En cambio las patentes de software sí nos imponen restricciones a ustedes, a mí y a cualquiera que utilice un ordenador. De modo que no podemos pensar en ellas en términos meramente económicos, no podemos juzgar esta cuestión en términos meramente económicos. Hay algo más importante en juego.

Pero incluso en términos económicos el sistema es contraproducente, pues se supone que su propósito es promover el progreso. Supuestamente, la creación de este incentivo artificial para hacer que la gente publique ideas contribuye al progreso en ese terreno. Pero lo que hace es justo lo contrario, pues la tarea fundamental en el software no es llegar con nuevas ideas, sino implementar miles de ideas juntas en un programa. Y las patentes de software ponen obstáculos a esto, de modo que son económicamente contraproducentes.

Y hay incluso estudios económicos que muestran que esto es así, que muestran que en un sector con mucha innovación incremental un sistema de patentes puede de hecho reducir la inversión en investigación y desarrollo. Y, por supuesto, dificulta el desarrollo también de otras maneras. De modo que, incluso si nos olvidamos de la injusticia de las patentes de software, incluso si las contemplamos dentro del marco estrictamente económico que suele proponerse, siguen siendo dañinas.

A veces la gente responde diciendo: «En otros sectores la gente ha convivido con las patentes durante décadas y se ha acostumbrado a ellas, ¿por qué ustedes deberían ser la excepción?».

Pues bien, esa pregunta parte de un supuesto absurdo. Es como decir: «Otros tienen cáncer, ¿por qué no usted también?». Yo creo que es bueno que alguien no contraiga cáncer, independientemente de lo que les suceda a los demás. Esa pregunta es absurda porque supone que de algún modo todos tenemos el deber de sufrir el daño ocasionado por las patentes.

Pero la pregunta contiene en sí misma otra más razonable, que es la siguiente: «Cuáles son las diferencias entre los diversos sectores que podrían hacer que un sistema de patentes resulte adecuado para algunos pero no para otros?».

Hay una diferencia fundamental entre los distintos sectores en cuanto al número estimado de patentes que podrían prohibir o cubrir partes de cualquier producto.

Tenemos una idea ingenua metida en la cabeza y trato de que nos libremos de ella, pues no es cierta. Y es que para cualquier producto hay una única patente, y que esa patente cubre el diseño completo de ese producto. De modo que si alguien diseña un producto nuevo, no puede estar ya patentado, y tendrá la oportunidad de obtener «la patente» de ese producto.

No es así como funcionan las cosas. Quizá lo era en 1800, pero no ahora. De hecho, hay todo un espectro de sectores en función del número de patentes por producto. El espectro comienza con una sola patente, pero hoy en día no hay ningún sector así; los sectores se encuentran en varios lugares dentro de ese espectro.

El sector más parecido a eso es el farmacéutico. Hace unas pocas décadas había realmente una sola patente por producto farmacéutico, al menos en cualquier momento dado, pues la patente cubría la fórmula química completa de esa sustancia en particular. Por aquel entonces, si alguien desarrollaba un nuevo medicamento podía estar seguro de que no había sido ya patentado por otra persona y de que podría obtener la patente de ese medicamento.

Pero no es así como funciona hoy en día. Ahora hay patentes más amplias, y podría suceder que alguien fuera capaz de desarrollar un nuevo medicamento y no se le permitiera hacerlo porque otro tiene ya una patente más amplia que lo cubre.

Incluso puede que haya varias patentes que cubran el nuevo medicamento simultáneamente, pero no serán cientos. La razón es que nuestra capacidad para la ingeniería bioquímica es tan limitada que nadie sabe cómo combinar tantas ideas para hacer algo útil en medicina. Si alguien puede combinar un par de ellas, ya lo está haciendo bastante bien para nuestro nivel de conocimientos. Pero en otros sectores se combinan más ideas para hacer una cosa.

En el otro extremo del espectro se encuentra el software, donde podemos combinar más ideas para obtener un diseño utilizable, pues nuestro campo es fundamentalmente más sencillo que otros. Supongo que en nuestro campo la gente es igual de inteligente que en el de la ingeniería física. No es que nosotros seamos mejores que ellos, es que nuestro campo es fundamentalmente más sencillo, pues nosotros trabajamos con matemáticas.

Un programa está hecho de componentes matemáticos, que están definidos, mientras que los objetos físicos no lo están. La materia hace lo que hace, de modo que debido a las perturbaciones de la materia es posible que un diseño no funcione de la manera que «debería» funcionar. Y es una tarea ardua. No se puede decir que la materia tiene un fallo y que habría arreglar el universo físico. Mientras que nosotros, los programadores, podemos levantar un castillo que descanse sobre una fina línea matemática. Y se sostiene, porque nada tiene ningún peso.

La ingeniería física se enfrenta con multitud de complicaciones de las que nosotros no tenemos que preocuparnos.

Por ejemplo, cuando yo pongo una condición if dentro de un bucle while,

  • no tengo que preocuparme de que si la frecuencia de repetición del bucle while es incorrecta, la condición if pueda generar vibración, entrar en resonancia y romperse.
  • no tengo que preocuparme de que si resuena mucho más rápido —digamos, millones de veces por segundo— pueda generar señales de radiofrecuencia que den lugar a valores erróneos en otras partes del programa;
  • no tengo que preocuparme de que fluidos corrosivos presentes en el ambiente puedan filtrarse entre la condición if y la sentencia while y comenzar a corroerlos hasta impedir el paso de las señales;
  • no tengo que preocuparme de que el calor generado por la condición if vaya a afectar a la sentencia while y la calcine; y
  • no tengo que preocuparme de cómo extraer la condición if si se rompe, quema o corroe y reemplazarla por otra condición if para que el programa vuelva a funcionar.

Tampoco tengo que preocuparme de cómo voy a insertar la condición if dentro de la sentencia while cada vez que hago una copia del programa. No tengo que montar una fábrica específica para hacer copias de mi programa, pues hay diversas órdenes generales que hacen copias de cualquier cosa.

Si quiero hacer copias en CD, solo tengo que escribir un máster; y hay un programa que puedo utilizar para hacer un máster a partir de cualquier cosa, para escribir los datos que quiera. Puedo hacer un máster en CD y enviarlo a una fábrica, ellos duplicarán cualquier cosa que les envíe. No tengo que montar una fábrica diferente para cada cosa que quiero duplicar.

En la ingeniería física a menudo hay que hacerlo, hay que diseñar productos para su fabricación. Diseñar la maquinaria puede ser una tarea aún mayor que la de diseñar el producto, y luego puede ser necesario gastar millones de dólares para levantar la fábrica. Así que, con tantas dificultades, no se podrán aplicar tantas ideas diferentes a un solo producto y hacerlo funcionar.

El diseño de un producto físico con un millón de elementos de diseño diferentes que no se repiten es un proyecto colosal. Un programa con un millón de elementos de diseño diferentes no es nada. Son unos pocos cientos de miles de líneas de código, y unas cuantas personas pueden escribirlo en pocos años, así que no es gran cosa. La consecuencia es que el sistema de patentes es proporcionalmente mucho más gravoso para nosotros que para la gente de cualquier otro sector que tenga que vérselas con las perturbaciones de la materia.

Un abogado hizo un estudio sobre un programa grande concreto, el núcleo Linux, que se utiliza junto al sistema operativo GNU que yo impulsé. Eso fue hace cinco años, y encontró 283 patentes estadounidenses diferentes, cada una de las cuales parecía prohibir algunos procesos de cómputo presentes en alguna parte del código de Linux. Al mismo tiempo vi un artículo que decía que Linux constituía el 0,25% de todo el sistema. De modo que si multiplicamos 300 por 400 podemos calcular el número de patentes que prohibirían algo en todo el sistema, unas cien mil. Esto es solo un cálculo aproximado. No disponemos de información más precisa, pues tratar de averiguarlo sería una tarea colosal.

Pero este abogado no publicó la lista de patentes, pues eso habría puesto en peligro a los desarrolladores del núcleo Linux, ya que haría que las sanciones se agravaran en caso de que fueran demandados. Él no quería perjudicarlos, lo que pretendía era demostrar la gravedad del problema, el estancamiento que producen las patentes de software.

Los programadores comprenden esto de inmediato, pero los políticos no suelen saber mucho de programación. Por lo general imaginan que las patentes son básicamente como el copyright, sólo que algo más sólidas. Imaginan que, puesto que el copyright no supone ninguna amenaza para los desarrolladores de software en su trabajo, tampoco la supondrán las patentes. Imaginan que, puesto que quien escribe un programa tiene el copyright, de la misma manera quien escribe un programa tiene también las patentes. Esto es falso, así que ¿cómo les hacemos ver lo que las patentes realmente hacen, lo que hacen en realidad en países como EE. UU.?

Me parece que es útil establecer una analogía entre el software y las sinfonías. Veamos por qué es una buena analogía.

Un programa o una sinfonía combinan muchas ideas. Una sinfonía combina muchas ideas musicales. Pero no se puede tomar un conjunto de ideas y decir: «Esta es mi combinación de ideas, ¿te gusta?», pues para hacer que funcionen hay que implementarlas todas. No se pueden tomar ideas musicales, ponerlas en una lista y decir: «¿Qué, te gusta esta combinación?». Uno no puede escuchar esa lista de ideas. Hay que escribir las notas que implementan todas esas ideas juntas.

Lo complicado de la tarea consiste en escribir todas esas notas de modo tal que el conjunto suene bien, algo que la mayoría de nosotros no sabría hacer. No hay duda de que muchos de nosotros podríamos escoger ideas musicales de una lista, pero no sabríamos cómo implementarlas en una sinfonía que sonara bien. Solo algunos de nosotros tienen ese talento. Esa es la limitación. Es probable que yo pudiera inventar algunas ideas musicales, pero no sabría cómo utilizarlas con eficacia.

Imaginemos ahora que nos encontramos en el siglo XVIII y que los Gobiernos europeos deciden que quieren promover el progreso de la música sinfónica estableciendo un sistema de patentes de ideas musicales, de modo que pudiera patentarse cualquier idea musical descrita con palabras.

Por ejemplo, podría patentarse el uso de una secuencia concreta de notas como tema musical, o podría patentarse una progresión de acordes, o un patrón rítmico, o la utilización de ciertos instrumentos por sí solos, o podría patentarse un formato de repeticiones dentro de un movimiento. Cualquier idea musical que pudiera describirse con palabras habría sido patentable.

Imaginen ahora que estamos en el siglo XIX, que ustedes son Beethoven y quieren escribir una sinfonía. Descubrirán que es mucho más difícil escribir una sinfonía por la que no puedan demandarlos que escribir una que suene bien, pues tendrá que abrirse paso entre todas las patentes existentes. Si ustedes se quejaran de esto, los titulares de las patentes les dirían: «Oh, Beethoven, estás celoso porque nosotros tuvimos esas ideas antes. ¿Por qué no concibes alguna idea por ti mismo?».

De hecho, Beethoven sí tuvo ideas propias. La razón de que se lo considere un gran compositor son justamente todas esas ideas nuevas que tuvo y utilizó. Y supo utilizarlas eficazmente, es decir, combinándolas con montones de ideas ya conocidas. En sus composiciones unía unas pocas ideas nuevas a muchas otras más antiguas e incontrovertidas. Obtuvo así piezas controvertidas, pero no tanto que la gente no pudiera acostumbrarse a ellas.

A nosotros la música de Beethoven no nos resulta polémica, aunque me han dicho que al principio sí lo fue. Pero como él combinó sus nuevas ideas con un montón de ideas ya conocidas, pudo darle a la gente la oportunidad de ampliar sus horizontes. Y pudieron hacerlo, que es por lo que a nosotros esas ideas nos suenan bien. Pero nadie, ni siquiera Beethoven, es tan genio como para reinventar la música desde cero y, sin utilizar ninguna de las ideas ya conocidas, componer algo que la gente esté dispuesta a escuchar. Como así tampoco nadie es tan genio como para reinventar la informática desde cero y, sin utilizar ninguna de las ideas ya conocidas, obtener algo que la gente quiera utilizar.

Cuando el contexto tecnológico cambia con tanta frecuencia sucede que lo que se hacía hace veinte años resulta ahora totalmente inadecuado. Hace veinte años no había internet. Sin duda la gente hacía entonces muchas cosas con los ordenadores, pero lo que quieren hacer hoy son cosas que funcionen con la red de Internet. Y no es posible hacerlo empleando solo las ideas que se conocían hace veinte años. Y supongo que el contexto tecnológico continuará cambiando, creando nuevas oportunidades para que alguien consiga patentes que lleven a la ruina a todo el sector.

Las grandes compañías pueden hacerlo incluso por sí solas. Por ejemplo, hace algunos años Microsoft decidió hacer un falso estándar abierto para documentos, y consiguió que se aprobara como estándar sobornando a la ISO (Organización Internacional de Estándares). Pero lo diseñaron utilizando algo que Microsoft había patentado. Microsoft es tan potente que puede empezar con una patente y diseñar después un formato o protocolo que hace uso de esa idea patentada (sea útil o no), de modo que no se puede lograr la compatibilidad a menos que se utilice esa misma idea. Y luego Microsoft puede hacer de ello un estándar de facto, con o sin la ayuda de organismos de estándares sobornados. Debido a su peso puede empujar a la gente a utilizar ese formato, lo que básicamente significa que consiguen un control absoluto en todo el mundo. Así que tenemos que mostrar a los políticos qué es lo que realmente está sucediendo aquí. Tenemos que mostrarles por qué es dañino.

Ahora he oído que la razón por la que Nueva Zelanda está considerando la posibilidad de aprobar las patentes de software es que una gran compañía quiere que se le concedan algunos monopolios. Imponer restricciones a todos los ciudadanos del país a fin de que una compañía gane más dinero es lo diametralmente opuesto al buen gobierno.

Llegados a este punto, me gustaría abrir un turno de preguntas.

P.
¿Cuál es la alternativa?
R.
Que no haya patentes de software. Sé que funciona porque yo trabajaba en este campo cuando todavía no había patentes de software. En aquel entonces la gente desarrollaba software, lo distribuía de diversas maneras y no tenía que preocuparse de que apareciera algún titular de patentes con demandas por infracción. De modo que todos estaban a salvo. Las patentes de software no resuelven ningún problema real, de manera que no tenemos necesidad de plantearnos qué otra solución puede haber.
P.
¿Cómo se recompensa a los desarrolladores?
R.

De muchas maneras. Las patentes de software no tienen nada que ver con eso. Recuerden que si ustedes son desarrolladores de software, las patentes de software no les ayudarán a alcanzar lo que sea que quieran conseguir.

Cada programador aspira a algo diferente. Yo desarrollé algunos programas relevantes en los años ochenta, y la recompensa que buscaba consistía en ver a la gente utilizar sus ordenadores en libertad. Y recibí esa recompensa, aunque no totalmente, pues no todo el mundo goza de esa libertad. Pero las patentes de software no habrían hecho otra cosa que detenerme.

Otros desarrollaban software porque querían dinero. Las patentes de software eran una amenaza también para ellos, y todavía lo son, pues no se conseguirá dinero si los titulares de las patentes exigen que se les dé todo el que se haya obtenido o si obligan a cerrar el negocio.

P.
¿Cómo evitar el plagio y...?
R.

El plagio no tiene nada que ver con este asunto. No tiene absolutamente nada que ver con este asunto.

Plagio significa copiar el texto de una obra y afirmar haberlo escrito uno mismo. Pero las patentes no se refieren al texto de ninguna obra en particular. Simplemente, no tienen nada que ver con esto.

Si usted escribe una obra y su obra incorpora algunas ideas (lo cual siempre sucede) no hay razón para pensar que las patentes que cubren esas ideas le pertenecen a usted. Es más probable que pertenezcan a muchos otros —la mitad de ellas a las megacorporaciones— que podrán demandarlo. Así que no hay que preocuparse de posibles plagios, pues mucho antes de que llegue el momento en que alguien pueda copiar su obra ya habrán acabado con ella.

Me temo que usted confunde las patentes con el copyright. No tienen nada en común. Les he explicado cómo afecta el sistema de patentes al software, pero pienso que usted no me cree porque ha oído hablar de la función del copyright y está confundiendo ambas cosas. Usted se ha formado una idea acerca de los efectos del copyright y supone que los efectos de las patentes son los mismos. No es así. Si usted escribe un código, el copyright de ese código le pertenece a usted, pero si el código implementa ideas que están patentadas, los titulares de esas patentes podrán demandarlo.

Con el copyright, si usted mismo escribe el código, no tiene que preocuparse de que alguien tenga ya el copyright de ese código y pueda presentarle una demanda, pues el copyright solo limita la copia. Incluso si escribe algo que es idéntico a lo que ha escrito otra persona, si puede probar que usted no lo copió, eso constituye defensa suficiente en el marco de la ley de copyright, pues la ley de copyright se refiere solo a la copia. La ley de copyright se ocupa únicamente de lo relativo a la autoría de la obra, no de las ideas incorporadas en ella, de modo que trata de algo muy distinto de la ley de patentes, y los efectos son totalmente diferentes.

Personalmente no estoy a favor de todo lo que la gente hace con el copyright, y lo he criticado. Pero es un tema totalmente diferente, sin relación alguna. Si usted cree que la ley de patentes es una ayuda para alguien que está desarrollando software, eso significa que se ha hecho una idea completamente equivocada de los efectos reales de la ley de patentes.

P.
No me malinterprete. Estoy de su parte.
R.
Sí, pero aun así usted se ha formado una idea equivocada. No le estoy culpando, simplemente usted ha sido mal informado.
P.
Si estoy escribiendo software con fines comerciales, ¿tendré una buena protección si lo encierro en una caja negra y lo mantengo en secreto?
R.
No quiero discutir esa cuestión porque no estoy a favor de ello. Creo que no es ético hacerlo, pero de todos modos es un asunto que no viene al caso.
P.
Lo entiendo.
R.
No quiero cambiar de tema y elogiar algo que desapruebo. Pero como es otro tema, prefiero no entrar en ello.
P.
Nuestra Fundación para la Investigación, la Ciencia y la Tecnología —que según creo es probablemente el equivalente de vuestra Fundación Nacional para la Ciencia— concede subvenciones para la investigación y el desarrollo, y una de las cosas que propone con bastante insistencia es que, de ser posible, las ideas que han financiado se aseguren por medio de patentes.
R.
Eso no debería aplicarse al software porque nadie, en ningún caso, debe tener la posibilidad de patentar ideas en el campo de la informática. Pero, más en general, lo que se aprecia ahí es la corrupción general de nuestra sociedad al poner los objetivos comerciales por delante de cualquier otro objetivo. No soy comunista y no quiero abolir los negocios, pero cuando los negocios están por encima de todo, cuando todos los aspectos de la vida se orientan hacia los negocios, eso es peligroso.
P.
Entonces, Richard, si hablas con la Fundación, quizá podrías sugerirles que hay mejores maneras de hacer dinero con el software en un pequeño país como Nueva Zelanda.
R.
Las patentes de software no ayudan a nadie a hacer dinero con el software. Lo que hacen es poner a quien lo intenta en riesgo de ser demandado.
P.
Lo cual dificulta a un país como Nueva Zelanda construir una base económica apoyándose en el software.
R.
Perdone, cuando dice “lo cual” no sé a qué se está refiriendo. Las patentes de software se lo dificultan a todo el mundo. Si Nueva Zelanda permite las patentes de software, eso dificultará a cualquiera en Nueva Zelanda desarrollar software y distribuirlo, pues le pondrá en riesgo de ser demandado. Las patentes de software no tienen nada que ver con desarrollar un programa y luego darle algún uso.
P.
De modo que, en lo que se refiere a su desarrollo económico, Nueva Zelanda estaría mejor protegida sin patentes de software.
R.

Sí. Mire, cada país tiene su propio sistema de patentes, y funcionan independientemente, salvo entre los países que han firmado un acuerdo que diga: «Si usted tiene una patente en tal país, puede venir aquí con su solicitud de patente y la evaluaremos basándonos en la fecha de su solicitud allí». Pero, por lo demás, cada país tiene sus propios criterios sobre lo que puede patentarse y posee su propio conjunto de patentes.

La consecuencia es que si EE. UU. permite las patentes de software y Nueva Zelanda no, eso significa que cualquier persona de cualquier lugar del mundo, incluidos los neozelandeses, puede conseguir patentes estadounidenses y demandarnos a nosotros, pobres estadounidenses, en nuestro país. Pero si Nueva Zelanda no permite las patentes de software, eso significa que ni ustedes ni nosotros podemos conseguir patentes de software neozelandesas para demandarlos a ustedes, los neozelandeses, en su país. Puede estar seguro de que casi todas las patentes de software estarán en manos de extranjeros que las utilizarán fundamentalmente para arremeter contra cualquier desarrollador de software neozelandés en cuanto se les presente la ocasión.

P.
Desde que sucedió el caso de Hughes Aircraft, que creo que fue en los años noventa...
R.
No conozco ese caso.
P.
Pues, básicamente, significa que Nueva Zelanda tiene patentes de software. No estamos entrando en un terreno virgen, las patentes existen ya.
R.

No lo sé, pero me han dicho que ahora se está decidiendo en el plano legislativo si permitirlas o no. Y las oficinas de patentes suelen ser receptivas a la presión que ejercen las megacorporaciones a través de la OMPI.

La OMPI, como se desprende de su nombre (Organización Mundial de la Propiedad Intelectual), no obra de buena fe, pues el uso de esa expresión aumenta la confusión. La OMPI obtiene buena parte de sus fondos de las megacorporaciones, y los utiliza para llevar a funcionarios de las oficinas de patentes a idílicos destinos turísticos para formarlos. Lo que les enseñan es el modo de torcer la ley para permitir las patentes en áreas en las que se supone que no están permitidas.

En muchos países hay leyes y sentencias judiciales que dicen que el software como tal no puede patentarse, que los algoritmos no pueden patentarse o que los algoritmos «matemáticos» no pueden patentarse (nadie está muy seguro de lo que significa que un algoritmo sea matemático o no), y varios criterios más que si se interpretaran de forma natural excluirían las patentes de software, pero las oficinas de patentes tuercen la ley para introducirlas de todos modos.

Por ejemplo, un montón de cosas que en la práctica son patentes de software se describen como un sistema que cuenta con una unidad de procesamiento central, una memoria, dispositivos de entrada/salida, capacidad de recibir instrucciones y medios para realizar una operación de cómputo particular. En realidad, han descrito explícitamente en la patente todas las partes de un ordenador común, y luego dicen: «Pues bien, este es el sistema físico que queremos patentar», pero lo cierto es que están patentando un determinado programa para ordenador. Son muchos los subterfugios que han empleado.

Por lo general, las oficinas de patentes tratan de torcer la ley para permitir más patentes. En EE. UU., las patentes de software se crearon a raíz de una sentencia judicial de 1982 emitida por el Tribunal de Apelación que se ocupa de todos los casos de patentes, que malinterpretó y aplicó incorrectamente una sentencia del Tribunal Supremo del año anterior. Ahora parece que por fin el Tribunal de Apelación ha cambiado de opinión y ha llegado a la conclusión de que todo aquello fue un error, y parece que con esta decisión nos libraremos de todas las patentes de software, a menos que el Tribunal Supremo la invalide. El Tribunal Supremo está ahora deliberando sobre ello, y en menos de un año sabremos si hemos ganado o no.

P.
En caso de que se fracasara, ¿hay algún movimiento en EE. UU. para adoptar una solución legislativa?
R.
Sí, y yo lo vengo promoviendo desde hace unos 19 años. Es una batalla que estamos librando una y otra vez en varios países.
P.
En su planteamiento, ¿dónde encajaría el caso I4i?
R.
No tengo idea de qué se trata.
P.
Es lo que ha hecho que Microsoft casi tuviera que dejar de vender Word, pues se ha descubierto que infringía una patente canadiense.
R.
¡Ah, eso! No es más que un ejemplo de lo peligrosas que son las patentes para todos los programadores. No me gusta lo que hace Microsoft, pero esa es otra cuestión. No es bueno que alguien pueda demandar a un desarrollador de software y decirle: «No te permitiré distribuir ese software».
P.
Obviamente, vivimos en un mundo imperfecto, y en algunos casos nos topamos con el asunto de las patentes de software. ¿Cree que deberíamos conceder a los investigadores el privilegio de sortear las patentes del mismo modo que la ley de copyright permite la investigación sobre obras sujetas a copyright?
R.
No, buscar soluciones parciales es un error, porque tenemos más posibilidades de alcanzar una solución completa. Todos los que están involucrados en el desarrollo, distribución y uso del software, excepto las megacorporaciones, en cuanto ven lo peligrosas que son las patentes de software abogan por su total rechazo. Mientras que una excepción para algún caso especial se ganará el apoyo de la gente solo para ese caso especial. Estas soluciones parciales son básicamente distracciones. La gente empieza a decir: «Estoy seguro de que en realidad no podemos solucionar el problema, así que me doy por vencido. Propongamos una solución parcial». Pero estas soluciones parciales no hacen que se pueda desarrollar software de un modo seguro.
P.
En cualquier caso, usted no se opondría a una solución parcial que no se dirija necesariamente solo a las patentes de software, como por ejemplo a su utilización en la experimentación, lo cual sería una buena solución para las patentes farmacéuticas.
R.
No me opondría a eso.
P.
Pero, para entendernos, lo que usted está diciendo es que no cree que eso sea aplicable al software.
R.
Algo que nos pone a salvo solo a unos pocos, o solo a ciertas actividades, o nos libra de la mitad de las patentes de software, es como decir: «Bien, quizá podamos limpiar de minas parte del terreno, o quizá podamos destruir la mitad de las que se encuentran en el campo minado». Pero eso no hace que podamos caminar sobre seguro.
P.
Usted ha estado repitiendo lo mismo por todo el mundo. ¿Qué acogida ha tenido? ¿Han cambiado de opinión los Gobiernos o han dejado de adoptar patentes de software?
R.
Algunos sí lo han hecho. Hace algunos años en India hubo un intento de cambiar la ley de patentes para permitir de forma explícita las patentes de software, pero se abandonó. Hace algunos años EE. UU. propuso un tratado comercial con Latinoamérica, un tratado de libre explotación, pero fue bloqueado por el presidente de Brasil, que dijo «no» a las patentes de software y a otros aspectos dañinos relacionados con la informática. Eso puso fin a todo el tratado. Al parecer ese era el único punto que EE. UU. pretendía imponer al resto del continente. Pero estas cosas no desaparecen para siempre; hay compañías que disponen de personal que trabaja a tiempo completo tratando de encontrar la manera de subvertir la ley en tal o cual país.
P.
¿Hay datos concretos de los efectos económicos sobre los colectivos dedicados a la innovación en aquellos países que no tienen patentes de software?
R.

No hay nada. Es casi imposible medir estas cosas. En realidad no debería decir que no hay nada, algo sí hay. Es muy difícil medir el efecto del sistema de patentes porque se está comparando el mundo real con un mundo hipotético, y no hay forma de estar seguro de qué es lo que pasaría.

Lo que puedo decir es que antes de la aparición de las patentes de software se desarrollaba mucho software, aunque no tanto como ahora, porque naturalmente entonces no había en absoluto tantos usuarios de ordenadores como ahora.

¿Cuántos usuarios de ordenadores había en 1982, incluso en EE. UU.? Era una pequeña parte de la población. Pero había desarrolladores de software, y no decían: «Necesitamos desesperadamente patentes de software». Cuando desarrollaban sus programas no se les acusaba de infringir patentes. Pero he visto algún estudio económico que al parecer indica que las patentes no promueven un incremento de la investigación, sino que parte de los fondos destinados a la investigación se desvían a la obtención de patentes.

P.
¿Cree que puede producirse un aumento del interés por los secretos comerciales?
R.
No. Antes de que hubiera patentes de software muchos desarrolladores de software guardaban en secreto los detalles de sus programas. Pero normalmente no mantenían ninguna de las ideas generales en secreto, porque se dieron cuenta de que para desarrollar buen software la tarea fundamental no consiste en la elección de ideas generales, sino en la implementación conjunta de muchas ideas. De modo que publicaban en revistas académicas —o permitían que sus empleados lo hicieran— cualquier nueva idea interesante que tuvieran. Pero ahora patentarán esas nuevas ideas. Eso tiene poco que ver con desarrollar un programa útil, y dar a conocer algunas ideas no significa entregar un programa. Además, la mayor parte de las ideas, las miles de ideas que se combinan en un programa, son ya conocidas en cualquier caso.
P.
Para respaldar lo que usted dice, escuché una entrevista con uno de los fundadores de Paypal en la que decía que su éxito se debía en un 5% a ideas y en el restante 95% a su ejecución, y esto apoya muy bien su tesis.
R.
Estoy de acuerdo.
SF:
Excelente. Richard tiene aquí unas pegatinas que creo que son gratuitas.
RMS:
Sí, y estos otros artículos están en venta.
SF:
Así que si quieren pueden pasar por aquí. Ha sido una gran disertación. Gracias, Richard.

Esta conferencia está publicada en el libro Software libre para una sociedad libre: Selección de ensayos de Richard M. Stallman.

Notas de traducción

[1] La pronunciación de «GNU» por Richard Stallman también se puede oír en http://www.gnu.org/gnu/pronunciation.html.
[2] «Heckled by Heckel». Juego de palabras entre el nombre del programador, Heckel, y el verbo «to heckle» que significa «interrumpir con preguntas».

VOLVER ARRIBA


[Logotipo de la FSF]«Nuestra misión es preservar, proteger y promover la libertad de usar, estudiar, copiar, modificar y redistribuir programas de ordenador, así como defender los derechos de los usuarios de software libre.»

La Free Software Foundation es la principal organización que patrocina el Sistema Operativo GNU. Apoye a GNU y la FSF mediante la compra de manuales y otros artículos, uniéndose a la FSF como miembro asociado o haciendo una donación, ya sea directamente a la FSF o mediante Flattr.