Software libre para una sociedad libre - 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.