Previous Up Next
Capítulo 16 El peligro de las patentes de software1

Posiblemente estéis familiarizados con mi trabajo sobre el software libre. Esta charla no trata sobre ese trabajo. Esta charla trata sobre una forma de abuso legal para hacer del desarrollo informático una actividad peligrosa. Esto es, más o menos, lo que pasa cuando una ley de patentes se aplica al campo del software.

No trata del hecho de patentar el software. Esta es una forma muy mala, una forma muy engañosa de describir la cuestión, porque el problema no está en patentar programas individuales. Si así fuera, no habría ninguna diferencia, sería algo básicamente inocuo. En vez de eso, esta charla trata sobre el hecho de patentar ideas. Toda patente protege alguna idea. Las patentes de software son patentes que protegen ideas que tienen que ver con el software, ideas que podrían usarse para desarrollar software. Eso es lo que las convierte en peligrosos obstáculos para cualquier desarrollo de software.

Quizá hayáis oído a la gente utilizar un término engañoso, «propiedad intelectual». Este término, como veréis, está sesgado: asume que, digas lo que digas, la forma de considerar el software está en relación a algún tipo de propiedad, cuando esta forma en realidad es una entre muchas otras alternativas. Este término, «propiedad intelectual», prejuzga la cuestión más básica en cualquiera de las áreas que consideréis. No contribuye a despejar y abrir la mente.

Existe un problema adicional con el término, que no tiene nada que ver con el desarrollo de la opinión que tenga cada uno; y es que impide la comprensión de los hechos. El término «propiedad intelectual» vale para todo, mezcla aspectos completamente dispares de la ley, como puedan ser el copyright y las patentes que son completamente distintos. Cada detalle es singular. También mezcla la cuestión de las marcas, que todavía genera más diferencia y otras cosas que se encuentran con menos frecuencia. Ninguna de ellas tiene nada en común con cualquiera de las otras. Históricamente sus orígenes están completamente separados; las leyes se diseñaron de forma independiente; cubrían diferentes actividades y aspectos de la vida. Las medidas políticas que crearon están completamente desconectadas, de modo que si intentáis pensar en ellas confundiéndolas, tendréis la garantía de llegar a conclusiones disparatadas. Literalmente no podéis tener una opinión sensata ni inteligente sobre la «propiedad intelectual». Por lo tanto, si queréis pensar con claridad, no mezcléis estas cuestiones. Pensad sobre el copyright y luego pensad sobre las patentes. Aprended acerca de la legislación de copyright y de forma separada aprended acerca de la legislación de patentes.

Por citar algunas de las diferencias más grandes entre el copyright y las patentes: Espero que os olvidéis del copyright en lo que queda de exposición, porque esta exposición trata sobre patentes y nunca se deben mezclar las patentes y el copyright, si se quiere comprender claramente estos dos asuntos.

Imaginad que pasaría si al estudiar química práctica —o cocina— confundierais el agua con el etanol.

Cuando escuchas a la gente describir el sistema de patentes, normalmente lo hacen desde el punto de vista de alguien que espera conseguir una patente —cómo sería para ti conseguir una patente, como sería andar por la calle con una patente en tu bolsillo, para poder sacarla cada dos por tres, mostrársela a alguien y decir «¡dame tu pasta!».

Hay un motivo para este prejuicio: la mayoría de la gente que habla del sistema de patentes ha apostado por él, y por lo tanto quiere seduciros. Hay otro motivo: el sistema de patentes se parece mucho a la lotería, sólo una fracción muy pequeña de las patentes reporta realmente algún beneficio a aquellos que las poseen. De hecho, The Economist comparó una vez este sistema con una «lotería que consume tiempo». Si has visto anuncios de lotería, siempre te incitan a pensar que vas a ganar. No te incitan a pensar que vas a perder, aunque perder es mucho más probable. Con la propaganda del sistema de patentes pasa lo mismo: siempre te incitan a pensar que vas a ganar.

Para compensar este prejuicio, voy a describir el sistema de patentes desde el punto de vista de sus víctimas —esto es, desde el punto de vista de alguien que quiere desarrollar software pero está obligado a un forcejeo con un sistema de patentes informáticas que puede llevarle a ser demandado.

Por lo tanto, ¿qué es lo primero que puedes hacer después de haber tenido una idea sobre el tipo de programa que quieres escribir?

Para tratar con el sistema de patentes, lo primero que podrías intentar es descubrir qué patentes pueden cubrir el programa que quieres escribir. Esto es, sin embargo, imposible.

La razón se encuentra en que algunas de las solicitudes de patentes en trámite son secretas. Pasado cierto tiempo, 18 meses, podrán publicarse. Sin embargo, 18 meses son tiempo de suficiente para que escribas el programa, e incluso para lanzarlo sin saber que existe una patente y que vas a ser demandado.

No es un asunto simplemente académico. En 1984 se escribió el programa Compress, un programa para la compresión de datos. En esa fecha, no había una patente para el algoritmo LZW de compresión que usaba. Más tarde, en 1985, los EE.UU. publicaron 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 habían hecho los programadores. No se había dado cuenta de que ya no se podían usar de forma segura las ideas que encontrabas en una revista.

Olvidemos ese problema. Las patentes en curso son publicadas por la oficina de patentes, de modo que puedes encontrar la lista completa y ver qué dictan exactamente.

Por supuesto, en realidad no podrías leer toda la lista, ya que hay demasiadas patentes. En EE.UU. hay cientos de miles de patentes de software. No hay forma de que puedas seguirles la pista de todo lo que contienen. Tendrías que intentar la búsqueda de las más importantes.

Algunos dicen que eso debería ser fácil en la moderna era del ordenador. Podrías buscar a partir de palabras clave, pero eso sólo funciona hasta cierto punto. Encontrarás algunas patentes en una determinada. Pero probablemente no encontrarás todas.

Por ejemplo, existe una patente de software —que quizá ya haya expirado— sobre el cálculo en orden natural para hojas de cálculo. Básicamente, esto quiere decir que cuando produces una celda dependiente de otra celda, todo se vuelve a calcular en función de aquello de lo que depende, de modo que después de una operación de cálculo todo queda actualizado. Las primeras hojas de cálculo hacían sus operaciones de arriba a abajo, luego si hacías que una celda dependiera de otra que estaba abajo, y repetías este paso, tenías que recalcular todo varias veces para que los nuevos valores se extendieran hacia arriba. (Tenías que disponer de elementos para que dependieran de las celdas superiores.)

Entonces alguien cayó en la cuenta, ¿por qué no realizo las operaciones de cálculo de modo que cada elemento se calcule en función del elemento del que depende? Este algoritmo se llama clasificación topológica. La primera referencia que encontré es de 1963. La patente cubría varias docenas de maneras de implementar la clasificación topológica.

Sin embargo, no conseguirías encontrar esta patente con la búsqueda «hojas de cálculo». No la conseguirías encontrar con la búsqueda «orden natural» ni con la búsqueda «modelo topológico». No incluía ninguno de esos términos. De hecho, estaba descrita como un método para «recopilar fórmulas en código máquina». Cuando la vi por primera vez, pensé que era una patente equivocada.

Supongamos que tienes una lista de patentes y quieres ver qué es lo que no se te permite. Cuando intentas estudiar estas patentes, descubres que son muy difíciles de entender, dado que están escritas en un retorcido lenguaje legal cuyo significado es muy difícil de comprender. Lo que dicen las oficinas de patentes a menudo no significa lo que parece que dicen.

En un estudio del gobierno australiano sobre el sistema de patentes en la década de 1980, se concluía que, aparte de la presión internacional, no había motivos para tener un sistema de patentes —ya que no producía nada bueno para el público— y recomendaba su abolición a pesar de la presión internacional. Una de las cosas que citaban era que los ingenieros no intentan leer las patentes para aprender, porque resulta muy difícil entenderlas. Citaban a un ingeniero que decía: «No puedo reconocer mis propios inventos en las patentes».

No se trata de un asunto meramente teórico. 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 patentes, con sus «invenciones». No se parecía. 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. Dijo, «eso no es verdad, ¡simplemente yo no entendía el alcance de mi protección!». Yo contesté, «sí, eso es lo que yo estaba diciendo».

Así que, en realidad, tendrías que dedicar mucho tiempo a hablar con abogados para hacerte una idea de lo que estas patentes te prohíben hacer. Al final dirán algo como esto: «Si haces algo aquí, seguro que pierdes; si haces algo aquí —Stallman gesticula, señalando una amplia área— hay una posibilidad considerable de que pierdas, y si de verdad quieres estar a salvo, quédate fuera de esta área —vuelve a gesticular, señalando una área todavía más amplia—. Y, por cierto, hay una considerable posibilidad de que como resultado se de curso a una demanda».

Ahora que hemos definido un escenario previsible para hacer negocios, ¿qué vas a hacer? Bien, hay tres posibilidades que podrías probar, cualquiera de las cuales es aplicable en algunos casos. Permitidme que describa estas tres posibilidades y qué las hace viables o inviables.

16.1 Evitar la patente

«Evitar la patente» —lo que significa no utilizar la idea que cubre la patente. Esto puede ser fácil o difícil, dependiendo de qué idea se trate.

En algunos casos, se patenta una prestación. De este modo, la patente se evita no implementando esa prestación. Por lo tanto sólo cuenta lo importante que sea esa prestación. En algunos casos, puedes prescindir de ella. Hace algún tiempo, los usuarios del procesador de textos XyWrite vieron rebajadas sus aspiraciones. Esa degradación eliminó una prestación que te permitía predefinir abreviaturas. Es decir, cuando escribías una abreviatura seguida de un signo de puntuación, se reemplazaba inmediatamente con alguna prolongación de la abreviatura. Así, podías definir la abreviatura para alguna frase larga, escribirla y entonces la frase aparecía en tu documento. [Los desarrolladores] me escribieron acerca de esto, porque sabían que el editor de Emacs tenía una prestación similar. De hecho, la tenía desde la década de 1970. Este asunto era interesante porque demostraba que había tenido por lo menos una idea patentable en mi vida. ¡Sé que era patentable porque otro la patentó después!

En realidad tomaron en cuenta las tres posibilidades. Primero intentaron negociar con el dueño de la patente y resultó que no negociaba de buena fe. Después pensaron si podrían tener alguna oportunidad de invalidar la patente. Lo que decidieron fue eliminar esa prestación del programa.

Puedes prescindir de ella. Si el procesador de texto sólo carece de esta prestación, quizá la gente todavía lo use. Pero según empiecen a caer varias prestaciones, finalmente te encontrarás con un programa sobre él que la gente piensa que no es muy bueno y tenderá a rechazarlo.

En este caso se trata de una patente bastante limitada sobre una prestación muy específica. Pero, ¿qué se puede hacer en relación a la patente de la British Telecom sobre navegación por hipervínculos por medio del acceso telefónico? Hoy en día, la navegación por hipervínculos es absolutamente esencial para la mayor parte de los usos de los ordenadores. El acceso telefónico también es esencial. ¿Cómo te las arreglas sin esta prestación? La cual, por cierto, ni siquiera es una prestación —realmente es la combinación de dos prestaciones yuxtapuestas de forma arbitraria. Es como tener una patente sobre un sofá y un televisor que están en la misma habitación.

A veces la idea patentada será tan amplia y básica que prácticamente abarca todo un campo; por ejemplo, la idea de clave de uso público, que fue patentada en los EE.UU. La patente caducó en 1997. Hasta entonces, coartó en gran medida el uso de la clave de uso público en EE.UU. Gran cantidad de programas que la gente empezó a desarrollar fueron aplastados —nunca estuvieron de verdad disponibles porque los dueños de las patentes les amenazaban. Posteriormente, se consiguió publicar un programa, el PGP, que inicialmente se lanzó como software libre. Al parecer, cuando los dueños de las patentes estaban a punto de atacar, se dieron cuenta de que eso podría hacerles muy mala publicidad. Así que impusieron restricciones, haciendo que sólo fuera para uso no comercial, lo que significaba que no podría hacerse muy popular. De este modo limitaron el uso de la clave de uso público por una década o más. No había otras vías alternativas a esa patente. No había nada que pudieras hacer y fuera comparable a la clave de uso público.

A veces se patenta un determinado algoritmo. Por ejemplo, existe una patente sobre una versión mejorada de Fast Fourier Transform (FFT). Funciona dos veces más rápido, más o menos. Puedes evitarlo usando un FFT normal en tu programa. Esta parte del programa tarda el doble. Quizás eso no importe, quizás represente una pequeña parte del tiempo de carga del programa. Quizás si es dos veces más lento, ni siquiera te des cuenta. O quizás tu programa no funcione en absoluto dado que le llevará el doble de tiempo hacer su trabajo. Los efectos difieren.

En algunos casos, puedes encontrar un algoritmo mejor. Esto podría ser bueno o no. Como en el proyecto GNU no podíamos usar Compress, empezamos a buscar un algoritmo alternativo para la compresión de datos. Alguien nos escribió diciendo que tenía uno; había escrito un programa y quería ofrecérnoslo. Íbamos a sacarlo. Por casualidad, coincidió que leí un ejemplar del New York Times. (No leía un ejemplar del Times más que una vez cada pocos meses.) Así que le eché un vistazo y decía que alguien había recibido una patente por «inventar un nuevo método de compresión de datos». Supuse que sería mejor revisar esa patente. Conseguí una copia y resultó que cubría el programa que íbamos a lanzar en una semana. Ese programa murió antes de nacer.

Más tarde encontramos otro algoritmo que no estaba patentado. Éste llegó a ser el programa gzip, que ahora es de hecho el estándar para la compresión de datos. Como algoritmo para usar en un programa de compresión de datos, estaba bien. Cualquiera que quisiera hacer compresión de datos podría usar gzip en lugar de Compress.

La misma patente de compresión basada en el algoritmo de LZW también fue usada en formatos de imagen como GIF. Pero en este caso, dado que el trabajo que la gente quería hacer no era simplemente comprimir datos sino construir una imagen que pudieran activar con su software, resultó muy difícil comenzar a usar un algoritmo diferente. ¡No hemos sido capaces de hacerlo en diez años! Sí, la gente usaba el algoritmo de gzip para definir otro formato de imagen una vez que empezaron a ser amenazados con demandas por usar archivos de GIF. Cuando empezamos a decirle a la gente que dejara de usar archivos de GIF, que se cambiara, la gente decía «no podemos cambiarnos, los navegadores todavía no admiten el nuevo formato». Los desarrolladores de navegadores decían «esto no nos agobia, después de todo, nadie está usando este nuevo formato de archivo».

En efecto, existía mucha inercia en la sociedad en el uso del formato GIF, no fuimos capaces de que la gente se cambiara. En esencia, el uso que hace la comunidad del formato GIF todavía apremia a los sitios web a usar el formato GIF, con el resultado de que son vulnerables a estas amenazas.

De hecho, la situación es todavía más extraña. En realidad hay dos patentes que cubren el algoritmo de compresión de LZW. La oficina de patentes ni siquiera podía decir que estaban publicando dos patentes sobre la misma cosa; no podían seguir el rastro. Hay un motivo para esto: hace falta dedicación al estudio de estas dos patentes para darte cuenta de que realmente protegen la misma cosa.

Si fueran patentes sobre procesos químicos, sería mucho más fácil. Podrías comprobar qué sustancias se están usando, qué entradas y salidas hay, que acciones físicas se están tomando. Sin importar cómo estuvieran descritas, comprobarías qué son y comprobarías que son parecidas. Si algo es puramente matemático, existen muchas maneras muy diferentes de describirlo. A primera vista no parecen similares. Tienes que comprenderlos de verdad para comprobar que realmente están hablando de la misma cosa. La oficina de patentes no tiene tiempo. Hace unos pocos años, la oficina de patentes de los EE.UU. estaba empleando una media de 17 horas por patente. Esto no es mucho tiempo para pensar en ellas con cuidado, así que por supuesto comenten errores como éste. De hecho, os he hablado de un programa que murió antes de nacer. Ese algoritmo también disponía de dos patentes en los EE.UU.; por lo que parece, no es algo tan raro.

Evitar las patentes puede ser fácil, o puede ser imposible. Podría ser fácil y hacer inútil vuestro programa —según la situación.

Aquí llegamos a otro punto que se debería mencionar. A veces una empresa o consorcio puede hacer que un formato o un protocolo sea de facto el estándar. Por lo tanto, si se patenta ese formato o protocolo es un auténtico desastre. Incluso, existen estándares oficiales que están restringidos por patentes. Se produjo un gran alboroto político en septiembre de 2001 cuando el W3C (Consorcio de la World Wide Web) propuso que se empezaran a adoptar estándares protegidos por patentes. La comunidad protestó, y tuvieron que desdecirse. Volvieron a insistir en que cualquier patente debería ser implementada libremente por cualquiera y en que los estándares tenían que ser libres para que cualquiera los implementara. Es una victoria interesante. Pienso que esta fue la primera vez que una organización de estándares ha tomado esta decisión. Es normal que las organizaciones de estándares deseen añadir algo restringido por las patentes a un estándar para que a la gente no se le permita implementarlo libremente. Tenemos que acudir a otras organizaciones de estándares y reclamarles que cambien sus reglas.

16.2 Obtener la licencia de la patente

La segunda posibilidad consiste en conseguir una licencia para la patente en lugar de evitar la patente. Esta no es necesariamente una opción. El dueño de la patente no tiene por qué ofrecerte la licencia, no es obligatorio. Hace diez años, la Liga para la Libertad de Programación recibió una carta pidiendo ayuda para alguien cuyo pequeño negocio estaba fabricando máquinas tragaperras para los casinos, que ya entonces usaban ordenadores. Este alguien recibió una amenaza de otra empresa que decía: «Tenemos una patente. No se os permite hacer esto. ¡Cerrad!».

Le eché un vistazo a esa patente. Cubría la tenencia de una serie de ordenadores en red para instalar juegos, de modo que cada ordenador proveía más de un juego y te permitía jugar a más de un juego a la vez.

Os parecerá que la oficina de patentes de verdad piensa que es algo brillante hacer cualquier cosa más de una vez. No se dan cuenta de que en la ciencia informática esta es la forma más obvia de generalizar algo. Lo hiciste una vez, luego ahora lo puedes hacer varias veces, puedes crear una subrutina. Piensan que si haces algo más de una vez, de algún modo significa que eres brillante, que posiblemente nadie pueda discutir contigo y que tienes derecho a mandar.

De todos modos, a esta persona no le ofrecieron la licencia. Tuvo que cerrar. Ni siquiera podía permitirse ir a juicio. Yo diría que esa patente en concreto era una idea obvia. Es posible que un juez hubiera estado de acuerdo, pero nunca lo sabremos porque esta persona no se podía permitirse ir a juicio.

Sin embargo, muchos dueños de patentes ofrecen licencias. Aunque a menudo cobran mucho dinero por ello. La compañía que daba licencias para la patente del cálculo en orden natural pedía un cinco por ciento de los ingresos brutos por cada hoja de cálculo vendida en los EE.UU. Me han dicho que ese era el precio barato, anterior a la demanda —si de verdad te demandaban y ganaban, te exigían más.

Quizás puedas permitirte ese cinco por ciento por la licencia de esa patente, pero ¿y si necesitas la licencia de veinte patentes para desarrollar el programa? La gente del sector me dijo que, prácticamente, dos o tres licencias como esa harían inviable cualquier negocio.

Existe una situación en la que obtener una licencia por el uso de la patente es una solución muy buena. Es lo que ocurre si eres una megacorporación multinacional. Puesto que estas empresas poseen muchas patentes y se intercambian las licencias entre ellas, se libran de gran parte del daño que el sistema de patentes provoca y sólo perciben las cosas buenas.

IBM publicó un artículo en la revista Think —creo que era el número cinco de 1990— sobre el catálogo de patentes de IBM, en éste se exponía que IBM percibía dos tipos de beneficios en concepto de sus 9.000 patentes en EE.UU. —creo que el número es mayor hoy en día. Estos eran, en primer lugar, los ingresos por royalties, y en segundo lugar, «el acceso a las patentes de otros». Decían que el segundo beneficio era de mayor magnitud. De tal forma que el beneficio que IBM percibía por tener permiso de usar las ideas patentadas por otros era diez veces el beneficio directo que IBM percibía por ofrecer licencias.

¿Qué significa esto realmente? ¿Qué beneficio percibe IBM de su «acceso a las patentes de otros»? Esencialmente es el beneficio de estar exento de los problemas que el sistema de patentes puede causarle. El sistema de patentes es como la lotería: lo que ocurre con una patente determinada puede no ser nada, puede ser un golpe de suerte para algún dueño de una patente o un desastre para todos los demás. Pero IBM es una empresa demasiado grande, le compensa. Ellos pueden estimar el promedio de ventajas y desventajas del sistema de patentes. Para ellos, los problemas del sistema de patentes podrían haber sido diez veces mayores que las ventajas.

Digo «podrían haber sido» porque a través del intercambio de patentes se evitan experimentar esos problemas. Esos problemas sólo son potenciales, en realidad no les afectan. Pero cuando miden los beneficios de evitarlos, lo estiman en diez veces el valor del dinero que ingresan por sus patentes.

Este fenómeno del intercambio de licencias desmiente un mito común, el mito del «genio famélico», el mito de que las patentes «protegen» al «pequeño inventor». (Son términos propagandísticos. No deberíais usarlos.)

La historia es como sigue: imagina que existe un «brillante» diseñador de lo que sea. Imagina que se ha pasado «años de privaciones en el desván» diseñando un nuevo y maravilloso prototipo y ahora quiere fabricarlo. ¿No es una vergüenza que las grandes empresas vayan a competir con él, que se queden con todo el negocio y él «pase hambre»?

Debo precisar que normalmente aquellos que trabajan en el sector de las tecnologías de vanguardia no trabaja por su cuenta, que las ideas no salen de la nada —están basadas en las ideas de otros— y que, hoy por hoy, esta gente tiene muy buenas oportunidades de conseguir un trabajo si lo necesita. Así que este cuento —la idea de que una idea brillante venga una persona que trabaja sola— no es realista, al igual que la idea de que se encuentre en riesgo de pasar hambre.

Pero sí se puede concebir que alguien tenga una idea y que esta idea junto con otras 100 o 200 ideas pueda ser la base para la fabricación de algún tipo de producto, y que las grandes compañías podrían querer competir con esta persona. Así que veamos qué pasa si esa persona intenta usar una patente para impedírselo. Él dice: «Ah, no, IBM, no puedes competir conmigo. Tengo esta patente». IBM dice: «Veamos. Echemos un vistazo a tu producto. Hmmm. Tengo esta patente, y esta otra, y esta otra y esta otra y esta otra y esta otra, que han sido violadas por algunas partes de tu producto. Si crees que puedes luchar contra todas ellas en un juicio, volveré y encontraré unas cuantas más. Así que, ¿por qué no intercambias tus licencias con las mías?». Y entonces el brillante pequeño inventor dice, «bueno, vale, las intercambio». Entonces puede volver y fabricar este maravilloso lo-que-sea, pero también puede hacerlo IBM. IBM obtiene «acceso» a su patente y el derecho a competir con él, lo que quiere decir que esta patente no le «protegió» en absoluto. El sistema de patentes no hace eso, en realidad.

Las megacorporaciones evitan, en su mayoría, el daño del sistema de patentes; principalmente ven la cara buena. Por eso quieren tener patentes de software: son las únicas que se beneficiarán de ello. Pero si eres un pequeño inventor o trabajas para una pequeña empresa, la pequeña empresa no será capaz de hacer esto. Lo intentan. El problema es que las pequeñas empresas no pueden conseguir suficientes patentes para hacer que todo el mundo intercambie sus licencias con ellas.

Cualquier patente apunta a una cierta dirección. De modo que si una pequeña empresa tiene patentes que apuntan allí, y allí, y allí, y alguien por allí [Stallman señala a otro sitio] les señala un patente y dice dame tu dinero, la empresa pequeña está desamparada. IBM puede hacerlo, porque con 9.000 patentes apuntan a todas partes, no importa dónde estés, probablemente haya una patente de IBM que te señale. Así que IBM casi siempre puede hacerte intercambiar la licencia. Las empresas pequeñas ocasionalmente pueden hacer que alguien les intercambie las suyas. Dirán que quieren las patentes para fines defensivos, pero no conseguirán las suficientes para defenderse a sí mismas.

Hay casos en que ni siquiera IBM puede hacer que alguien le intercambie sus licencias. Esto ocurre cuando hay una compañía cuyo único negocio es tomar una patente y exprimirle a la gente dinero. La empresa que tenía la patente del orden natural de cálculo era exactamente este tipo de empresa. Su único negocio era amenazar a la gente con una demanda e ingresar dinero de gente que estaba creando algo de verdad.

No hay patentes sobre los procedimientos legales. Supongo que los abogados comprenden qué lata sería tener que tratar ellos mismos con el sistema de patentes. El resultado es que no hay forma de obtener una patente para hacer que tal compañía intercambie sus licencias contigo. Así que van por ahí exprimiendo a todo el mundo. Pero supongo que empresas como IBM se imaginan que es parte del precio de hacer negocios, así que pueden vivir con ello.

Así que esta es la opción de obtener una licencia de patente, que puede ser posible o no, según seas capaz de permitírtelo o no —lo cual nos conduce a la tercera posibilidad.

16.3 Revocar la patente en un juicio

Supuestamente, para que algo sea patentado, tiene que ser nuevo, útil y no obvio. (Es el léxico usado en EE.UU., creo que otros países tienen otro bastante similar.) Por supuesto, cuando la oficina de patentes entra en juego, comienza por interpretar «nuevo» y «no obvio». «Nuevo» viene a significar «no lo tenemos en nuestros archivos» y «no obvio» tiende a significar «no obvio para alguien con un coeficiente intelectual de 50».

Un estudioso de la mayoría de las patentes de software publicadas en EE.UU. —o que al menos lo era, no sé si todavía puede con todas ellas— dijo que el 90 por ciento no habría pasado el «test de Cristal City»,2lo que quería decir que si el personal de la oficina de patentes bajara al kiosko y adquiriera algunas revistas de informática, comprobaría que esas ideas ya son conocidas.

La oficina de patentes hace cosas que son tan obviamente estúpidas, que ni siquiera tendrías que conocer el estado de la técnica para saber que son estúpidas. Esto no se limita al software. Una vez vi el famoso ratón patentado de Harvard, que fue obtenido después de que Harvard practicara ingeniería genética con un ratón introduciéndole un gen cancerígeno. El gen cancerígeno ya era conocido y fue insertado usando técnicas conocidas en una variedad ya conocida de ratón. La patente que obtuvieron cubría la introducción de cualquier gen cancerígeno dentro de cualquier tipo de mamífero mediante cualquier método. No tienes que saber nada sobre ingeniería genética para darte cuenta de que esto es ridículo. Me han dicho que esta «sobrepretensión» es una práctica normal, y que la oficina de patentes de los EE.UU. a veces invita a los solicitantes a hacer sus pretensiones todavía más amplias. Esencialmente, uno tiende a hacer tan amplias las pretensiones hasta que cree que está en contradicción con algo que no es ambiguo y está bien documentado. Observad cuanta tierra podéis conseguir en el espacio mental.

Cuando los programadores echan un vistazo a muchas patentes de software dicen: «¡Esto es ridículamente obvio!». Los burócratas de las patentes tienen todo tipo de excusas para justificar su ignorancia sobre lo que piensan los programadores. Dicen: «¡Ah!, pero tienes que considerarlo en términos de cómo eran las cosas hace diez o veinte años». En ese momento descubrieron que si repiten algo hasta la saciedad pueden hacerte perder toda perspectiva. Todo puede parecer no obvio si lo descompones y lo analizas suficientemente. Uno simplemente pierde toda criterio de obviedad o por lo menos pierde la habilidad de justificar cualquier categoría sobre lo obvio o no. Luego, por supuesto, describen a los dueños de las patentes como brillantes inventores, sin excepción, por eso no podemos cuestionar su derecho a tener poder sobre lo que hacemos.

Si vas a juicio, los jueces tienden a ser un poco más estrictos sobre qué es obvio y qué no. El problema es que 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 finalmente fue de 13 millones, de los cuales la mayoría se destinó a pagar a los abogados de las dos partes. Quedaron unos pocos millones de dólares para el demandante —porque Qualcomm perdió.

En gran medida, la validez de una patente dependerá de las incidencias en el historial. Muchas incidencias en el historial como, exactamente qué fue publicado y cuándo, y cuáles de esos elementos se pueden encontrar, cuáles no se perdieron, fechas concretas y así... determinan si una patente es válida o no.

En realidad, resulta extraño que la patente de British Telecom «seguimiento de hipervínculos por medio de acceso telefónico» fuera solicitada en 1975. Creo que fue en 1974 cuando creé el paquete Info por primera vez. El paquete Info te permite utilizar hipervínculos y la gente usaba el teléfono para conectarse y acceder al sistema. Así que de hecho, yo produje una prueba que invalidaba esta patente. Es la segunda idea patentable que sé que he producido en mi vida.

Pero no creo que tenga ninguna prueba de ello. No pensé que esto fuera lo suficientemente interesante como para publicarlo. Después de todo, la idea de seguir un hipervínculo la tomé de la demo de Englebart para su editor. Él fue quien tuvo una idea que era interesante de publicación. Lo que yo había hecho lo llamé «el hipertexto del pobre» dado que tenía que implementarlo en el contexto de TECO. No tenía tanta capacidad como su hipertexto, pero al menos era útil para buscar 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 nada que ver con lo otro. No iba a publicar un artículo que dijera: «¡Oh, he implementado el hipertexto del pobre y ¿sabéis qué? ¡También hay líneas telefónicas en el ordenador!».

Sospecho que no hay manera de precisar en qué fecha implementé esto. ¿Fue publicado de algún modo? Bueno, invitamos a la gente a que entrara a través de ARPANET, y se registrara en nuestra máquina —de modo que hubieran podido buscar documentación a través de Info y echar un vistazo al asunto. Si nos lo hubieran preguntado, se habrían encontrado con que teníamos acceso telefónico. Como podéis ver, las incidencias en el historial determinan si tienes una técnica original.

Ahora, por supuesto, hay una publicación hecha por Englebart sobre el hipertexto, que ellos, lo acusados, van a mostrar. De todos modos, no creo que diga nada sobre tener líneas telefónicas en el ordenador así que no está claro si bastará.

La posibilidad de ir a juicio para revocar una patente es una opción. Debido a los gastos normalmente ni se plantea, aunque puedas encontrar una prueba sólida que sea suficiente para revocar la patente. Como resultado, una patente nula, una patente que nominalmente no debería haber existido —pero en realidad muchas de estas patentes sí existen— es un arma peligrosa. Si alguien te ataca con una patente nula, verdaderamente te puede causar muchos problemas. Puedes ir de farol enseñándoles tus pruebas. Depende de si se pueden asustar de este modo o no. Podrían pensar: «Bueno, vas de farol, nos imaginamos que realmente no puedes ir a juicio: no te lo puedes permitir, así que de todos modos te demandaremos».

Todas estas opciones son cuestiones con las que a veces te puedes apañar, pero con las que a menudo no puedes. Así que tendrás que enfrentarte a patente, tras patente, tras patente. Cada vez que seas capaz de encontrar alguna de estas tres posibilidades, te encuentras con que existe otra patente, luego otra y luego otra. Se convierte en algo parecido a cruzar un campo de minas. Cada paso que das, cada decisión de diseño posiblemente no pise una patente, así que puedes dar unos pocos pasos y posiblemente no habrá una explosión. Pero las posibilidades de que te abras paso a través del campo de minas y crees el programa que quieres desarrollar sin pisar nunca una patente disminuyen más y más según el programa se hace más grande.

Bueno, la gente solía decirme, «bien, hay patentes en otros campos, ¿por qué el software debería estar eximido de ellas?» Observad qué suposición más grotesca tenemos aquí: de algún modo todos debemos sufrir por el sistema de patentes. Es como decir: «Alguna gente desarrolla cáncer ¿por qué tú deberías estar exento?» Tal y como yo lo veo, que una persona no desarrolle cáncer es algo bueno.

Pero detrás de eso hay una pregunta menos sesgada, una buena pregunta, que es: ¿es el software diferente de los demás campos? ¿Debería la política de patentes ser diferente en campos diferentes? ¿En ese caso, por qué?

Permitidme que conteste a esa pregunta: las patentes se relacionan con diferentes campos de forma diferente porque, en campos diferentes, las patentes se relacionan con los productos de forma diferente.

De un extremo tenemos a las empresas farmacéuticas, donde una fórmula dada podría patentarse de modo que esa patente cubra un solo producto. Una sustancia nueva no estaría protegida por la patente que ya existe. De existir una patente para este nuevo producto, sería el dueño de la patente quien desarrollaría el nuevo producto.

Eso encaja con la idea ingenua que tenemos del sistema de patentes, que si estas diseñando un producto nuevo, vas a conseguir «la patente». La idea es que hay una patente por producto que cubre la idea del producto. En algunos campos esto está cerca de ser verdad; en otros campos esto está lejos de ser verdad.

El campo del software está en el último extremo: un programa puede ser objeto de muchas patentes. Esto pasa porque los paquetes de software son normalmente muy grandes. Usan muchas ideas diferentes en combinación. Si el programa es nuevo y no es una simple copia, entonces probablemente está usando una combinación diferente de ideas. Por supuesto, incorporadas en un código escrito de nuevo, porque no puedes nombrar mágicamente estas ideas y hacerlas funcionar. Tienes que implementar todas. Tienes que implementar todas ellas en esa combinación.

El resultado es que incluso cuando escribes un programa, estás usando una enorme cantidad de ideas diferentes, cada una de las cuales puede estar patentada por alguien. Un par de ellas podría estar patentada por alguien en una combinación. Podría haber varias maneras distintas de describir una idea, que podrían estar patentadas por gente distinta. Así que posiblemente hay miles de cosas, miles de puntos vulnerables en tu programa, que podrían estar ya patentadas por cualquier otro.

Por eso las patentes de software tienden a obstruir el progreso del software —el trabajo de creación de software. Si fuera el caso de «un producto, una patente» entonces estas patentes no obstruirían la creación de productos porque al crear un nuevo producto, no habría manera de que estuviera patentado por nadie más. Pero cuando un producto se corresponde con muchas ideas diferentes combinadas, parece probable que tu nuevo producto —tanto en parte como en su totalidad— pueda estar patentado ya por otro.

En realidad, hay investigaciones económicas que demuestran cómo la imposición de un sistema de patentes, en un campo en el que existe una creciente innovación, puede ralentizar el progreso. Los defensores de las patentes de software dicen: «Bueno, sí, a lo mejor hay 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 da igual los problemas que causen». Por supuesto, esto no lo dicen en voz alta porque sería ridículo, pero implícitamente quieren haceros creer que el sistema de patentes promueve siempre el progreso y que eso compensa todo coste posible. Pero en realidad no hay razones para creer que promueva el progreso. Ahora tenemos un modelo que demuestra exactamente cómo las patentes pueden ralentizar el progreso. El caso donde ese modelo aplicado describe muy bien el software es el de la creciente innovación.

¿Por qué se encuentra el software en ese extremo del espectro? El motivo es que en software creamos objetos matemáticos ideales. Puedes construir un castillo enrevesado que descanse sobre una línea fina y se mantendrá en pie porque no pesa nada. En otros campos, la gente se tiene que manejar con la obstinación de la materia —la de los objetos físicos. La materia hace lo que tiene que hacer. Puedes intentar modelarla, pero si el comportamiento real no se ajusta a tu modelo entonces peor para ti, porque el desafío es hacer objetos físicos que verdaderamente funcionen.

Si quiero poner una orden condicional en una orden «mientras», no me tengo que preocupar sin la condicional oscilará a tal frecuencia y se frotará contra el «mientras» hasta que finalmente ambas se rompan. No me tengo que preocupar de si oscilará a una determinada alta frecuencia y provocará una señal en el valor de otra variable. No me tengo que preocupar de cuánta corriente atraerá esa condicional, ni de si disipará el calor dentro del «mientras», o de si habrá una caída en el voltaje a través del «mientras» que hará que la orden condicional no funcione. No me tengo que preocupar de que si pongo este programa en un entorno de agua salada, el agua salada se podría introducir entre la condicional y la orden «mientras» y provocar corrosión. [Risas del público.]

No me tengo que preocupar, cuando me refiero al valor de una variable, de si estoy excediendo su aforo refiriéndome a ella 20 veces. No me tengo que preocupar de cuánta capacidad tiene, ni de si habrá suficiente tiempo para que cobre valor.

No me tengo que preocupar, cuando escribo el programa, de cómo voy a juntar físicamente cada copia ni de si puedo arreglármelas para llegar a poner la condicional dentro del «mientras». No me tengo que preocupar de cómo voy a acceder a ella, en caso de que la orden condicional se rompa, para retirarla y cambiarla por una nueva. Hay muchos problemas de los que no nos tenemos que preocupar en el software; eso hace mucho más fácil escribir un programa que diseñar un objeto físico que tenga que funcionar.

Esto puede parecer extraño, porque habréis oído a gente hablando sobre lo difícil que es diseñar software, sobre el enorme problema que supone y reflexionando sobre cómo van a resolverlo. Realmente no están hablando de lo mismo que yo. Yo estoy comparando sistemas físicos y sistemas de software de la misma complejidad, con la misma cantidad de elementos. Estoy diciendo que un sistema de software es mucho más fácil de diseñar que un sistema físico. Pero el talento de la gente en estos campos diferentes es el mismo, de modo que ¿qué hacemos cuando nos encontramos con un campo fácil? ¡Lo hacemos avanzar! Llevamos nuestras habilidades al límite. Si los sistemas del mismo tamaño son fáciles, hagamos sistemas diez veces más grandes —¡resultará entonces más difícil! Eso es lo que hacemos: producimos sistemas de software que son mucho más grandes que los sistemas físicos en cuanto a su número de elementos.

Un sistema físico cuyo diseño incluye un millón de partes diferentes es un megaproyecto. Un programa informático cuyo diseño incluye un millón de partes quizá tenga 300.000 líneas; unas pocas personas escriben eso en un par de años. No es un programa especialmente gigantesco. GNU EMACS tiene ahora varios millones de partes en su diseño, creo. Tiene un millón de líneas de código. Este es un proyecto esencialmente hecho sin financiación de ningún tipo, realizado en su mayoría por gente en su tiempo libre.

Hay otra gran salvedad. Si has diseñado un producto físico, lo próximo que debes hacer es diseñar la fábrica para producirlo. Construir esta fábrica podría costar millones o decenas de millones, mientras que para hacer copias de un programa sólo tienes que pulsar «copiar». El mismo comando copiará cualquier programa. Si quieres copias en un CD, perfecto, grabas un CD master y lo envías a una planta de CDs. Ellos usarán el mismo equipo que copia cualquier contenido en un CD. No hace falta construir una fábrica especializada para producir cada producto concreto. Se da una tremenda simplificación y reducción del coste del diseño.

Una compañía automovilística, que se gasta 50 millones para construir una fábrica para hacer un nuevo modelo de coche, puede contratar a unos abogados para vérselas con las negociaciones de la licencia de patentes. Incluso pueden vérselas con una demanda si quisieran. Diseñar un programa de la misma complejidad podría costar 50.000 o 100.000 dólares. En comparación, el coste de tratar con el sistema de patentes es demoledor —en realidad diseñar un programa de la misma complejidad que el diseño mecánico de un coche representa probablemente un mes de trabajo. Cuántas partes tiene un coche..., quiero decir, en caso de que el coche no tenga ordenador.3 Esto no quiere decir que diseñar uno bueno sea fácil, sólo que no incluye tantos elementos diferentes.

El resultado es que el software es realmente distinto de otros campos, porque cuando estamos trabajando con herramientas matemáticas, diseñar algo es mucho, mucho más fácil. El resultado es que producimos con regularidad sistemas que son mucho, mucho más grandes y lo hacemos con sólo unas pocas personas. El resultado es que en lugar de acercarnos a tener un producto y una patente, estamos en un sistema donde un producto implica muchas, muchas ideas que podrían estar ya patentadas.

El mejor modo de explicar esto por analogía es con las sinfonías. Una sinfonía también es larga y incluye muchas notas, y probablemente usa muchas ideas musicales. Imaginad 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 ofreciera patentes para cualquier tipo de ideas musicales que pudieras exponer con palabras.

Imaginad entonces que estamos cerca de 1800, que sois Beethoven y queréis escribir una sinfonía. Os encontraréis con que disponer vuestra sinfonía de modo que no infrinja ninguna patente es más difícil que escribir una buena sinfonía.

Cuando os quejáis de esto, los dueños de las patentes os dicen «Venga, Beethoven, ya nos estás jodiendo porque no tienes ideas propias. Lo único que quieres es robar nuestras invenciones». Beethoven, como de hecho sucedía, tenía muchas ideas musicales nuevas —pero tenía que usar muchas ideas musicales ya existentes para hacer música reconocible, para hacer música que pudiera gustar a los oyentes, que estos pudieran reconocer como música. Nadie es tan brillante como para reinventar una música completamente distinta y hacer algo que a la gente le guste escuchar. Pierre Boulez dijo intentar hacerlo, pero ¿quién escucha a Pierre Boulez?

Nadie es tan brillante como para reinventar toda la ciencia informática, de forma completamente nueva. Si lo hiciera, produciría algo que los usuarios encontrarían tan extraño que no querrían usarlo. Si hoy echas un vistazo a un procesador de texto, te encontrarás, creo, con cientos de características diferentes. Si desarrollas un procesador de texto nuevo, bueno e innovador, eso significa que incluye algunas ideas nuevas, pero debe incluir cientos de viejas ideas. Si no te está permitido usarlas, no puedes hacer un procesador de textos innovador. Como el trabajo de creación de software es tan grande, el resultado es que no necesitamos ningún plan artificial para incentivar nuevas ideas. Simplemente deja que la gente escriba software y ya tendrán nuevas ideas. Si quieres escribir un programa y quieres hacerlo bien, te vendrán a la cabeza algunas ideas y encontrarás alguna forma de usar algunas de ellas.

Lo que solía pasar —porque yo estaba en el campo del software antes de que existieran patentes de software— era que la mayoría de los creadores publicaban cualquier idea que pensaran que fuera digna de atención y por la que pensaran recibir algún reconocimiento o respeto. Las ideas que fueran demasiado pequeñas o no lo suficientemente notables no las publicaban porque podrían ser una tontería. Ahora se supone que el sistema de patentes apoya el descubrimiento de ideas. En realidad, en los viejos tiempos, nadie guardaba las ideas en secreto. Guardaban el código en secreto, es verdad. El código, después de todo representaba el grueso del trabajo. Guardaban el código en secreto y publicaban las ideas, de modo que los empleados adquirieran algo de reconocimiento y se sintieran bien.

Después de las patentes de software, todavía guardan el código en secreto y además patentan las ideas, así que en realidad, no se ha apoyado el descubrimiento en ningún sentido significativo. Las mismas cosas se guardan en secreto hoy al igual que se guardaban en secreto ayer, pero las ideas que se solían publicar para que las pudiéramos usar, es muy probable que ahora sean patentadas y estén fuera de nuestro alcance durante 20 años.

¿Qué puede hacer un país para cambiar esto? ¿En qué dirección deberíamos modificar las políticas al respecto para solucionar este problema?

Hay dos puntos donde se puede atacar. Uno es el punto desde donde se lanzan las patentes, la oficina de patentes. El segundo es donde se aplican las patentes. Aquí se trata de qué es lo que protege la patente.

Una forma es mantener un buen criterio para publicar patentes. Esto puede funcionar en un territorio que no ha autorizado antes las patentes informáticas, por ejemplo, en la mayor parte de Europa. Simplemente reforzar claramente las reglas de la Oficina Europea de Patentes que dictan que el software no es patentable ya es una buena solución para Europa. Ahora Europa está teniendo en cuenta una directiva sobre patentes de software. (Supongo que la directiva será más amplia, pero una de sus implicaciones importantes son las patentes de software.) Simplemente con modificar esta directiva para dictar que las ideas de software no pueden ser patentadas, el problema se mantendrá alejado de Europa, al menos en su mayor parte, excepto en algunos países que podrían haber asumido el problema por su cuenta, siendo por desgracia el Reino Unido uno de ellos —por desgracia para vosotros.

Esa posibilidad no existe en EE.UU. La razón es que EE.UU. ya tienen una gran cantidad de patentes de software y cualquier cambio en el criterio para publicar patentes no se deshará de las que ya existen.4 Así, en los EE.UU., la solución tendrá que pasar por cambiar la aplicabilidad, el alcance, de las patentes. Dictar que una implementación pura de software, instalada sobre hardware de uso general que no infringe en sí mismo la patente, no está protegida por ninguna patente y no puede ser objeto de demanda por ello. Este es otro tipo de solución.

El primer tipo de solución, la solución que interviene sobre qué tipos de patentes pueden ser válidos, es una buena solución para Europa.

Cuando en EE.UU. se empezaron a conceder patentes de software, no hubo debate político. En realidad, nadie se enteró. El ámbito del software, en su mayor parte, ni siquiera se enteró. Existía una decisión del Tribunal Supremo en 1981 que reflexionaba sobre la patente de un procedimiento para curar el síndrome del nevus azul. El fallo fue que el hecho de que el aparato incluyera un ordenador y un programa como parte del procedimiento para curar el síndrome no lo hacía impatentable. Al año siguiente, la sala de apelaciones que considera todos los casos de patentes invirtió los términos: dictó que el hecho de que hubiera un ordenador y un programa en todo esto lo hacía patentable. El hecho de que cualquier cosa tenga un ordenador y un programa la hace patentable. Por eso los EE.UU. empezaron a tener patentes sobre procesos de negocio: porque los procesos de negocio se gestionaban con un ordenador y eso los hacía patentables.

De este modo, se dictó este fallo y creo que la patente sobre el cálculo en orden natural fue una de las primeras o quizá incluso haya sido la primera.

Durante la década de 1980 no sabíamos nada de esto. Fue hacia 1990 cuando los programadores en los EE.UU. empezaron a ser conscientes de que se enfrentaban a un peligro con las patentes de software. Vi cómo trabajaba el sector antes y cómo trabajaba después. No vi ningún aceleramiento especial del progreso después de 1990.

En EE.UU. no hubo debate político pero en Europa, ha habido un gran debate político. Hace varios años hubo presiones para enmendar el tratado de Múnich que establecía la Oficina Europea de Patentes. Tenía una cláusula que dictaba que el software no es patentable. La presión fue para enmendarlo y para que se pudiera empezar a permitir las patentes de software. Sin embargo, la comunidad se enteró. Fueron realmente los desarrolladores y los usuarios de software libre quienes llevaron la iniciativa. Pero no somos los únicos amenazados por las patentes de software. Todos los desarrolladores de software están amenazados por las patentes de software, y incluso los usuarios de software están amenazados por las patentes de software.

Por ejemplo, Paul Heckel —cuando Apple no estaba muy asustada por sus amenazas— amenazó con empezar a demandar a los clientes de Apple. Apple encontró esto mucho más temible. Se imaginaron que no podrían permitirse que sus clientes fueran demandados de este modo, aunque finalmente ganaran. Así que los usuarios también pueden ser demandados, bien como forma de atacar al creador, bien como simple forma de exprimirles dinero por su cuenta o bien como forma de causar el caos. Todos los desarrolladores y usuarios de software son vulnerables.

Sin embargo, fue la comunidad del software libre en Europa la que llevó la iniciativa para organizar la oposición. De hecho, dos tercera partes de los países que están ahora en la Oficina Europea de Patentes votó en contra de enmendar ese tratado. En ese momento, la UE intervino, los directores estaban divididos acerca de este cuestión. Al parecer, el encargado de la promoción del software está en contra de las patentes de software, pero no estaba a cargo de este asunto. Es la dirección del Mercado Único la que tiene esta competencia y está dirigida por alguien que está a favor de las patentes del software. Básicamente no hicieron caso de la opinión pública que se les había expresado. Han propuesto una directiva para permitir las patentes de software.

El gobierno francés ya ha dicho que está en contra. La gente está informando a otros gobiernos europeos para que se opongan a las patentes del software y es vital que se empiece a hacer esto aquí, en Inglaterra. Según Harmut Pilch, que es uno de los líderes en la lucha europea contra las patentes de software, el mayor impulso para éstas viene de la oficina británica de patentes. La oficina de patentes del Reino Unido está simplemente inclinada a favor de las patentes de software. Hizo una encuesta pública y la mayoría de las respuestas se oponían a las patentes de software. Entonces escribieron un informe diciendo que la gente parecía satisfecha con ellas, pasando por alto completamente las respuestas. La comunidad del software libre dijo «por favor, enviadnos las respuestas también a nosotros». Así que publicaron esas respuestas, que generalmente estaban en contra. Nunca se hubiera supuesto eso a partir el informe que publicó la oficina de patentes del Reino Unido.

Usan un término que ellos llaman «efecto técnico». Este es un término que puede estirarse enormemente. Supuestamente tienes que pensar que significa que una idea sobre un programa sólo sería patentable si está relacionada con actos físicos específicos. Si esa es la interpretación, esto en su mayor parte resolvería el problema. Si las únicas ideas de software que pudieran patentarse fueran aquellas que de verdad estuvieran relacionadas con un resultado técnico o físico particular, que hubieras patentado si no hubieras usado el programa, eso estaría bien. El problema es que puedes estirar ese término. Puedes describir el resultado que obtienes por utilizar cualquier programa como un resultado físico. ¿Cómo se diferencia este resultado físico de cualquier otro? Bueno, se diferencia como resultado de este cómputo. El resultado es que la oficina de patentes del Reino Unido propone algo que parece llevar a que resuelva el problema en su mayor parte, pero en realidad da carta blanca para patentar casi cualquier cosa.

El personal del mismo ministerio también está implicada en asuntos referidos al copyright, que realmente no tienen nada que ver con las patentes del software excepto en que están siendo manejadas por la misma gente. (A lo mejor se han visto llevados por el término «propiedad intelectual» para confundir las dos cuestiones.) Se trata de interpretar la reciente directiva de copyright de la UE, una ley horrible como la Digital Millenium Copyright Act en los EE.UU., pero con algo de flexibilidad para que los países decidan cómo se implementa. Reino Unido propone la manera más draconiana posible de implementar esta directiva. Se podría reducir mucho el daño implementándola apropiadamente. Reino Unido quiere maximizar el efecto tiránico de esta directiva. Parece que hay cierto grupo —¿el Departamento de Comercio e Industria?— que debe ser frenado. Es necesario revisar sus actividades y detener la gestación de nuevas formas de poder.

Las patentes de software subordinan a todo desarrollador de software y a todo usuario a una nueva forma de burocracia. Si los negocios que usan ordenadores se dieran cuenta de cuántos problemas les puede causar esto, se levantarían en armas, y estoy seguro de que podrían detenerlo. A los negocios no les gusta estar subordinados a la burocracia. Hay algunas áreas en las que nos gustaría que el gobierno del Reino Unido hiciera un trabajo más cuidadoso al subordinar ciertos negocios a la burocracia, como en todo lo que se refiere al desplazamiento de animales. Pero en los casos en los que no sirve a otro propósito que a crear monopolios artificiales, de modo que alguien pueda interferir en la creación de software —exprimiendo dinero de los desarrolladores y los usuarios—, deberíamos rechazarlo. Tenemos que hacer conscientes a las empresas de lo que las patentes de software les pueden hacer, y conseguir su apoyo para luchar contra las patentes de software en Europa.

La batalla no ha terminado. Todavía puede ser ganada.

1
Esta charla fue pronunciada en la Universidad de Cambridge, Londres, el 25 de marzo de 2002.
2
Cristal City es la zona de Washington donde se encuentra la oficina de patentes. [N. del E.]
3
Hay aproximadamente 300-400 elementos distintos en una transmisión automática y una transmisión es generalmente el componente más complicado de un coche. Diseñar una transmisión puede llevar de seis meses a un año, e incluso entonces puede llevar más tiempo tenerla a punto y en funcionamiento. De todos modos, un programa con 500 o 800 elementos útiles tendría entre 200 y 300 líneas de código, y probablemente a un buen programador le llevaría de un día a una semana escribirlo, probarlo y depurarlo.
4
Digo «patentes de software», pero ¿a qué me estoy refiriendo? La oficina de patentes de los EE.UU. no divide oficialmente las patentes entre patentes de software y otras patentes. Así que, de hecho, se puede concebir que cualquier patente pueda servir para demandarte si se puede aplicar a algún software. Las patentes de software son patentes que potencialmente se podrían aplicar al software, patentes que en potencia pueden servir para demandarte por escribir software.
Previous Up Next