taler-merchant-demos

software-patents.html (69928B)

---

 <!--#set var="ENGLISH_PAGE" value="/philosophy/software-patents.en.html" -->
 
 <!--#include virtual="/server/header.es.html" -->
 <!-- Parent-Version: 1.96 -->
 <!-- This page is derived from /server/standards/boilerplate.html -->
 <!--#set var="TAGS" value="speeches" -->
 <!--#set var="DISABLE_TOP_ADDENDUM" value="yes" -->
 
 <!-- This file is automatically generated by GNUnited Nations! -->
 <title>Patentes de software - Proyecto GNU - Free Software Foundation</title>
 
 <!--#include virtual="/philosophy/po/software-patents.translist" -->
 <!--#include virtual="/server/banner.es.html" -->
 <!--#include virtual="/philosophy/ph-breadcrumb.es.html" -->
 <!--GNUN: OUT-OF-DATE NOTICE-->
 <!--#include virtual="/server/top-addendum.es.html" -->
 <div class="article reduced-width">
 <h2>Patentes de software: Un obstáculo para el desarrollo de software</h2>
 
 <address class="byline">por Richard Stallman</address>
 
 <div class="infobox">
 <p>Esta es la transcripción de una charla impartida por Richard Stallman el 25
 de marzo de 2002 en el <a href="https://www.cl.cam.ac.uk/">Laboratorio de
 Informática</a> de la Universidad de Cambridge, organizada por la <a
 href="https://www.fipr.org/"><cite>Foundation for Information Policy
 Research</cite></a>.</p>
 <p>Transcripción (<a
 href="https://www.cl.cam.ac.uk/~mgk25/stallman-patents.html">versión
 original</a>) y <a
 href="//audio-video.gnu.org/audio/#patent-cambridge-2002-03-25">grabación de
 audio</a> de Nicholas Hill. Edición HTML y enlaces de Markus Kuhn.</p>
 </div>
 <hr class="thin" />
 
 <p>
 Posiblemente estén familiarizados con mi trabajo en el <a
 href="/philosophy/free-sw.html">software libre</a>. Esta charla no trata
 sobre eso. Trata sobre una forma de <a
 href="https://web.archive.org/web/20150329103351/http://www.progfree.org/Patents/against-software-patents.html">abuso
 legal</a> que convierte el desarrollo de software en una actividad
 peligrosa. Trata acerca de lo que sucede cuando la ley de patentes se aplica
 al campo del software.
 </p>
 
 <p>
 Que se patente el software no es la cuestión. Esa es una manera engañosa de
 describir el asunto, pues el problema no es que se patenten programas
 individuales. Si así fuera, carecería de importancia, sería algo básicamente
 inocuo. Lo que sucede es que se patentan ideas. Toda patente cubre alguna
 idea. Las <a
 href="https://web.archive.org/web/20150329143651/http://progfree.org/Patents/patents.html">patentes
 de software</a> son patentes que cubren ideas que tienen que ver con el
 software, ideas que pueden usarse para desarrollar software. Es eso lo que
 las convierte en peligrosos obstáculos para el desarrollo de software.
 </p>
 
 <p>
 Probablemente hayan oído una expresión engañosa, «<a
 href="https://www.wipo.org/about-ip/en/">propiedad intelectual</a>». Como
 pueden ver, es una expresión sesgada. Da por sentado que, sea cual fuere la
 cosa de la que se está hablando, ha de considerarse como un tipo de
 propiedad, cuando en realidad esa es solo una entre muchas otras
 posibilidades. Con la expresión «propiedad intelectual» se prejuzga lo más
 básico en cualquier ámbito que se esté considerando. No contribuye a pensar
 de forma clara y con amplitud de miras.
 </p>
 
 <p>
 Existe otro problema que no tiene nada que ver con fomentar ningún punto de
 vista en particular, y es que constituye un obstáculo a la comprensión de
 los hechos. La expresión «propiedad intelectual» es un cajón de sastre en el
 que se incluyen campos legislativos completamente dispares, como por ejemplo
 la ley de copyright y la ley de patentes, que son totalmente
 distintas. Todos sus aspectos son diferentes. Mete también en el mismo saco
 las marcas, que difieren aún más, y varias otras cosas que aparecen con
 mayor o menor frecuencia. Ninguna de ellas tiene nada en común con las
 demás. Históricamente, sus orígenes no tienen ninguna relación.
 Esas leyes se diseñaron de manera independiente y cubrían diferentes
 actividades y aspectos de la vida, lo que dio lugar a medidas políticas sin
 ninguna relación entre sí. Si intentamos analizarlas metiéndolas todas en el
 mismo saco, seguramente llegaremos a conclusiones disparatadas. No se puede
 tener ninguna opinión sensata y lúcida en absoluto acerca de la «propiedad
 intelectual». Si queremos pensar con claridad, no las mezclemos. Analicemos
 el copyright y luego las patentes. Estudiemos la ley de copyright y
 estudiemos la ley de patentes por separado.
 </p>
 
 <p>
 Por citar algunas de las mayores diferencias entre el copyright y las
 patentes: el copyright cubre la expresión particular de una obra, no cubre
 ninguna idea; las patentes solo cubren ideas y el uso de ideas; el copyright
 se aplica automáticamente; las patentes son emitidas por una oficina de
 patentes, previa solicitud.
 </p>
 
 <p>
 Las patentes cuestan mucho dinero. Es mayor incluso el precio que hay que
 pagar a los abogados para que redacten la solicitud que lo que hay que
 abonar al presentarla. Normalmente la solicitud tarda algunos años en ser
 estudiada, aun cuando las oficinas de patentes las examinan de manera muy
 descuidada.
 </p>
 
 <p>
 El copyright dura muchísimo tiempo. En algunos casos puede durar hasta 150
 años. Las patentes, por el contrario, duran 20 años, lo cual no es tanto
 como para que sobrevivan a su titular, pero es demasiado para la escala
 temporal de un ámbito como el del software.
 </p>
 
 <p>
 Volvamos la vista veinte años atrás, cuando un PC era algo
 novedoso. Imaginemos que nos viéramos obligados a desarrollar software
 utilizando solo las ideas ya conocidas en 1982.
 </p>
 
 <p>
 El copyright cubre la copia. Si alguien escribe una novela que resulta ser
 idéntica, palabra por palabra, a <i>Lo que el viento se llevó</i> y puede
 demostrar que nunca antes había visto <i>Lo que el viento se llevó</i>, eso
 le serviría para defenderse ante cualquier acusación de infracción de
 copyright.
 </p>
 
 <p>
 Una patente es un monopolio absoluto sobre el uso de una idea. Aun cuando
 alguien pueda probar que concibió la idea por sí mismo, no serviría de nada
 si la idea ya ha sido patentada por otra persona.
 </p>
 
 <p>
 Espero que durante el resto de esta charla se olviden del copyright, ya que
 esta charla trata acerca de las patentes y nunca hay que meter en el mismo
 saco las patentes y el copyright. Se trata de que comprendan estas
 cuestiones legales. Imaginen cuál sería su comprensión de la química
 aplicada si no supieran distinguir entre el agua y el etanol.
 </p>
 
 <p>
 Cuando alguien nos habla del sistema de patentes, normalmente lo hace desde
 el punto de vista de quien espera obtener una patente. Nos cuenta lo que se
 consigue al obtener una patente, cómo sería si pudiéramos ir por la calle
 con una patente en el bolsillo y, de vez en cuando, apuntar a alguien con
 ella y decirle: «¡Deme su dinero!». Este sesgo tiene su razón de ser, y es
 que la mayoría de la gente que le hablará acerca de este sistema de patentes
 tiene intereses en él, y quiere que a usted le guste.
 </p>
 
 <p>
 Hay otra razón, y es que el sistema de patentes es como una lotería, pues
 solo una ínfima parte de las patentes reportan algún beneficio a quienes las
 poseen. De hecho, en cierta ocasión <cite><a
 href="https://www.economist.com/leaders/2011/08/20/patent-medicine">The
 Economist</a></cite> se refirió a él como «una lotería que requiere mucho
 tiempo». Si hemos visto anuncios de lotería, habremos observado que siempre
 nos invitan a pensar en lo que sucedería si ganáramos. No nos invitan a
 pensar en perder, aun cuando esto es mucho más probable. Lo mismo sucede con
 la publicidad del sistema de patentes. Siempre nos invitan a pensar en lo
 que sucederá si somos nosotros los que ganamos.
 </p>
 
 <p>
 Para compensar este punto de vista sesgado, voy a describir el sistema de
 patentes desde el punto de vista de sus víctimas. Es decir, desde el punto
 de vista de alguien que quiere desarrollar software pero está obligado a
 vérselas con un sistema de patentes de software que podría conducir a una
 demanda judicial.
 </p>
 
 <p>
 Veamos, ¿qué es lo primero que habría que hacer una vez que se tiene una
 idea del tipo de programa que se va a escribir? Lo primero que quizá se
 quiera hacer para lidiar con el sistema de patentes es descubrir qué
 patentes pueden cubrir el programa que se quiere escribir. Pero esto es
 imposible. La razón de ello es que algunas de las solicitudes de patente que
 están pendientes son secretas. Pueden publicarse después de cierto tiempo,
 por ejemplo 18 meses. Pero eso es tiempo suficiente para escribir el
 programa e incluso publicarlo, sin saber que va a haber una patente y que
 nos van a presentar una demanda.
 Esto no es una mera hipótesis. En 1984 se escribió el programa Compress, un
 programa para la compresión de datos. En aquel momento no había ninguna
 patente para el algoritmo de compresión LZW que utilizaba. Más tarde, en
 1985, EE.&nbsp;UU. emitió una patente sobre este algoritmo, y durante los
 años siguientes los que distribuían el programa Compress empezaron a recibir
 amenazas. No había forma de que el autor de Compress se hubiera dado cuenta
 de que podía ser demandado. Todo lo que hizo fue usar una idea que encontró
 en una revista, como siempre han hecho los programadores. No se dio cuenta
 de que ya no se podían usar sin peligro las ideas que se encontraban en una
 revista.
 </p>
 
 <p>
 Dejemos a un lado este problema... La oficina de patentes publica las
 patentes emitidas, de modo que se puede consultar toda su larga lista y ver
 exactamente lo que dicen. Pero, por supuesto, no sería posible leer la lista
 entera porque son demasiadas. En EE.&nbsp;UU. hay cientos de miles de
 patentes de software.
 </p>
 
 <p>
 No hay manera de examinarlas todas. Habría que tratar de encontrar las que
 sean relevantes. Hay quien dirá que eso debería ser sencillo en estos
 tiempos modernos en que disponemos de ordenadores. Se podría buscar por
 palabras clave, etc. Pero eso solo funciona hasta cierto punto. Así se
 encontrarán algunas patentes relevantes, pero no necesariamente
 todas. Había, por ejemplo, una patente de software, que quizá haya ya
 expirado, sobre el «cálculo del orden natural» en las hojas de cálculo.
 Esto significa básicamente que cuando se hace que ciertas celdas dependan de
 otras todo se vuelve a calcular en función de aquello de lo que depende, de
 modo que después de una operación de cálculo todo queda actualizado. Las
 primeras hojas de cálculo hacían sus operaciones de arriba a abajo, de
 manera que si se hacía que una celda dependiera de otra situada más abajo, y
 esto se repetía varias veces, había que recalcular todo varias veces para
 que los nuevos valores se extendieran hacia arriba. Había que disponer los
 elementos de manera que dependieran de las celdas superiores.
 Entonces alguien pensó que por qué no realizar las operaciones de cálculo de
 modo que cada elemento se calcule en función del elemento del que
 depende. Este algoritmo se conoce como clasificación topológica. La primera
 referencia a él que he podido encontrar es de 1963. La patente cubría varias
 docenas de maneras diferentes de implementar la clasificación topológica,
 pero no se podría haber encontrado esta patente buscando «hoja de
 cálculo». Tampoco buscando «orden natural» o «clasificación topológica». En
 ella no aparecían estos términos. Se describía como un método de compilar
 fórmulas en código objeto. La primera vez que lo vi pensé que no era esa la
 patente que buscaba.
 </p>
 
 <p>
 Supongamos que disponemos de una lista de patentes y queremos saber qué nos
 está prohibido. Al tratar de estudiar estas patentes descubriremos que es
 demasiado complicado entenderlas, ya que están escritas en un lenguaje legal
 muy enrevesado cuyo significado es difícil comprender. Lo que dicen las
 oficinas de patentes a menudo no significa lo que parece significar.
 </p>
 
 <p>
 En los años ochenta, el Gobierno australiano realizó un estudio del sistema
 de patentes. Concluyó que, aparte de la presión internacional, no había
 razones para disponer de un sistema de patentes. No ofrecía ningún beneficio
 para la sociedad, y recomendaba abolirlo de no ser por la presión
 internacional. Uno de los hechos que se señalaron fue que los ingenieros ni
 siquiera intentan leer las patentes para averiguar algo, ya que resulta
 demasiado complicado comprenderlas. Citaban a un ingeniero que decía: «No
 logro reconocer mis propias invenciones en las patentes».
 </p>
 
 <p>
 Esto no es una simple teoría. Hacia 1990, un programador llamado <a
 href="https://www.atarimagazines.com/startv2n3/hypercard.html">Paul
 Heckel</a> demandó a Apple alegando que Hypercard infringía dos de sus
 patentes. Cuando vio Hypercard por primera vez, no pensó que tuviera nada
 que ver con sus patentes, con sus «invenciones». No se parecían. Pero cuando
 su abogado le dijo que se podía interpretar que las patentes se aplicaban a
 una parte de Hypercard, decidió atacar a Apple.
 Cuando di una charla sobre esto en Stanford, él estaba entre el público y
 dijo, «Eso <a
 href="http://www.swiss.ai.mit.edu/6805/articles/int-prop/heckel-debunking.html">no
 es verdad</a>, ¡yo simplemente no entendía el alcance de mi protección!». Y
 yo le contesté, «Sí, eso es lo que yo estaba diciendo». De manera que habría
 que dedicar mucho tiempo a hablar con abogados para hacerse una idea de lo
 que esas patentes prohíben hacer.
 Al final dirán algo así: «Si haces esto, seguro que pierdes; si haces
 aquello, hay serias posibilidades de que pierdas, y si de verdad quieres
 estar a salvo, mantente al margen de esta área. Y, por cierto, el azar juega
 un importante papel en el resultado de cualquier proceso judicial».
 </p>
 
 <p>
 Ahora que conocemos el terreno que pisamos para hacer negocios(!), ¿qué
 haremos? Bien, hay tres formas de afrontar la cuestión, y todas son
 aplicables en ciertos casos.
 </p>
 
 <p>Son las siguientes:</p>
 
 <ol>
 <li>Evitar la patente</li>
 <li>Obtener la licencia de la patente</li>
 <li>Revocar la patente en los tribunales</li>
 </ol>
 
 <p>
 Describiré estas tres soluciones y lo que las hace viables o inviables.
 </p>
 
 <h3>1) Evitar la patente</h3>
 
 <p>
 Esto significa no utilizar la idea que está cubierta por la patente, lo cual
 puede ser fácil o difícil según la idea de que se trate. En algunos casos,
 lo que se patenta es una funcionalidad, de modo que la patente se evita no
 implementando esa funcionalidad. Entonces la cuestión es cuán importante es
 esa funcionalidad. En algunos casos, se puede prescindir de ella. Hace algún
 tiempo, los usuarios del procesador de textos XyWrite recibieron una
 actualización regresiva por correo. La actualización eliminaba una
 funcionalidad que permitía predefinir abreviaturas. Es decir, cuando se
 escribía una abreviatura seguida de un signo de puntuación, se reemplazaba
 inmediatamente por la secuencia de caracteres completa.
 De ese modo se podía asignar una abreviatura para alguna frase larga,
 escribir la abreviatura y entonces en el documento aparecía la frase
 entera. Ellos me escribieron sobre esto porque sabían que el editor <a
 href="/software/emacs/">Emacs</a> tiene una funcionalidad similar. De hecho,
 la tiene desde los años setenta. Fue interesante, porque me hizo ver que
 había tenido al menos una idea patentable en mi vida. ¡Supe que era
 patentable porque otra persona la patentó después! De hecho, habían probado
 los tres enfoques.
 Primero intentaron negociar con el titular de la patente, pero resultó que
 este no negociaba de buena fe. Luego se plantearon si podrían tener alguna
 oportunidad de invalidar la patente. Y finalmente decidieron eliminar esa
 funcionalidad del programa. Se puede vivir sin ella. Si el procesador de
 texto solo carece de esta funcionalidad, quizá la gente lo use igualmente,
 pero si se empiezan a eliminar varias funcionalidades, al final la gente
 pensará que el programa no es muy bueno y probablemente lo rechace. En este
 caso se trataba de una patente bastante limitada sobre una funcionalidad muy
 específica.
 </p>
 
 <p>
 Pero, ¿qué se puede hacer con relación a la <a
 href="https://patents.justia.com/patent/4873662">patente de British
 Telecom</a> sobre la navegación por hipervínculos mediante acceso
 telefónico? Hoy en día, la navegación por hipervínculos es absolutamente
 esencial en el uso corriente de los ordenadores. El acceso telefónico
 también es esencial. ¿Cómo arreglárselas sin esta funcionalidad que, por
 cierto, ni siquiera es una funcionalidad sino en realidad una combinación de
 dos funcionalidades yuxtapuestas de forma arbitraria? Es como tener una
 patente sobre un sofá y un televisor que estén en la misma habitación.
 </p>
 
 <p>
 A veces la idea patentada es tan amplia y básica que prácticamente abarca
 todo un campo. Por ejemplo, la idea de cifrado mediante clave pública, que
 fue patentada en EE.&nbsp;UU. La patente caducó en 1997. Hasta entonces,
 obstruyó enormemente el uso de ese tipo de cifrado en EE.&nbsp;UU. Un buen
 número de programas que la gente empezaba a desarrollar se vieron
 frustrados. Nunca llegaron a estar verdaderamente disponibles debido a las
 amenazas de los propietarios de las patentes.
 Posteriormente apareció un programa, <a href="http://www.pgpi.org/">PGP</a>,
 que inicialmente se publicó como software libre. Al parecer, los titulares
 de las patentes se proponían atacar, pero se dieron cuenta de que eso podría
 crearles muy mala imagen. De modo que impusieron restricciones, limitándolo
 solo a usos no comerciales, lo que significaba que no podría hacerse muy
 popular. De esta manera, limitaron fuertemente el uso del cifrado mediante
 clave pública durante una década o más. No había alternativas a esa
 patente. No se podía hacer nada más.
 </p>
 
 <p>
 A veces se patenta un algoritmo determinado. Por ejemplo, existe una patente
 sobre una versión optimizada de la transformada rápida de Fourier (<abbr
 title="Fast Fourier Transform">FFT</abbr>), que funciona el doble de
 rápido. Es posible evitarla utilizando en el programa la FFT ordinaria. Esa
 parte del programa tardará el doble de tiempo en ejecutarse. Quizás eso no
 tenga gran importancia, quizá represente una pequeña parte del tiempo de
 ejecución del programa, quizá ni siquiera se note que es el doble de
 lento. O quizás el programa no funcione en absoluto si le lleva el doble de
 tiempo hacer su tarea. Los efectos varían.
 </p>
 
 <p>
 En algunos casos se puede encontrar un algoritmo mejor. Esto podría ser
 bueno o no. Como no podíamos usar Compress, en el proyecto GNU empezamos a
 buscar algún algoritmo alternativo para la compresión de datos. Alguien nos
 escribió diciendo que tenía uno. Había escrito un programa y decidió
 ofrecérnoslo. Íbamos ya a publicarlo cuando por casualidad hojeé un ejemplar
 del New York Times en el que aparecía la columna semanal sobre patentes (no
 solía hojear el Times más que una vez cada varios meses). Así que le eché un
 vistazo, y decía que alguien había conseguido una patente por «inventar un
 nuevo método de compresión de datos».
 Pensé que habría que echarle un vistazo a esa patente. Conseguí una copia y
 resultó que cubría el programa que íbamos a publicar en tan solo una
 semana. Ese programa murió antes de nacer. Más adelante encontramos otro
 algoritmo que no estaba patentado. Este se convirtió en el programa <a
 href="/software/gzip/"> gzip</a>, que ahora es el estándar de facto para la
 compresión de datos. Como algoritmo para utilizar en un programa de
 compresión de datos estaba muy bien. Cualquiera  que quisiera comprimir
 datos podía utilizar gzip en lugar de compress. Pero el mismo algoritmo
 patentado de compresión LZW se utilizaba también en formatos de imagen tales
 como <a href="/philosophy/gif.html">GIF</a>.
 Y como en este caso lo que se quería hacer no era simplemente comprimir
 datos, sino elaborar una imagen que cualquiera pudiera visualizar con su
 software, resultaba extremadamente complicado cambiar a un algoritmo
 diferente. ¡Durante diez años no hemos podido hacerlo! Tan pronto como
 empezaron a llegar amenazas judiciales por usar archivos GIF, se comenzó a
 utilizar el algoritmo de gzip para definir <a
 href="https://www.w3.org/Graphics/PNG/">otro formato de imagen</a>. Cuando
 empezamos a pedir que se abandonara el uso de archivos GIF en favor de este
 otro formato, nos respondían: «No podemos cambiar, los navegadores no
 admiten todavía el nuevo formato». Y los desarrolladores de navegadores
 decían: «No tenemos ninguna prisa. Después de todo, nadie utiliza este nuevo
 formato».
 </p>
 
 <p>
 De hecho, la inercia en el uso del formato GIF era tan grande que no pudimos
 lograr que se cambiara. En la práctica, el uso del formato GIF por parte de
 la comunidad todavía sigue llevando a que los sitios web utilicen ese
 formato, con el resultado de que son vulnerables a las amenazas.
 </p>
 
 <p>
 En realidad la situación es todavía más grotesca. Hay de hecho dos patentes
 que cubren el algoritmo de compresión LZW. La oficina de patentes ni
 siquiera se dio cuenta de que estaban concediendo dos patentes sobre la
 misma cosa. No estaba al tanto, y hay un motivo para ello: hay que dedicar
 una buena cantidad de tiempo al estudio de estas dos patentes para darse
 cuenta de que en realidad cubren lo mismo.
 </p>
 
 <p>
 Si fueran patentes sobre procesos químicos, sería mucho más fácil. Se podría
 verificar qué sustancias se están empleando, qué se introduce, qué se
 obtiene y qué acciones físicas se llevan a cabo. Sea cual sea su
 descripción, se comprobaría en qué consisten esos procesos y se vería que
 son similares.
 </p>
 
 <p>
 Si algo es puramente matemático, existen muchas maneras muy diferentes de
 describirlo. Su similitud no se aprecia a simple vista. Hay que
 comprenderlas muy bien para apreciar que se refieren a lo mismo, y la
 oficina de patentes no tiene tiempo para hacerlo. Hace algunos años, la
 Oficina de Patentes de EE.&nbsp;UU. empleaba una media de 17 horas por
 patente. No es tiempo suficiente para examinarlas cuidadosamente, de modo
 que comenten errores como este, por supuesto. Ya les he hablado del programa
 que murió antes de nacer. También sobre ese algoritmo se habían emitido en
 EE.&nbsp;UU. dos patentes. Por lo que se ve, no es nada inusual.
 </p>
 
 <p>
 Evitar las patentes puede ser fácil, o imposible. Puede ser fácil, pero el
 programa puede acabar resultando inútil. Depende de la situación.
 </p>
 
 <p>
 Hay otra cuestión que debo mencionar. A veces una empresa o un consorcio
 puede hacer que un formato o protocolo sea el estándar de facto. En tal
 caso, si ese formato o protocolo se patenta es un auténtico desastre. Hay
 incluso estándares oficiales que están restringidos por patentes. El pasado
 mes de septiembre se produjo un gran revuelo político cuando el <a
 href="https://www.w3.org/TR/patent-practice"><cite>World Wide Web
 Consortium</cite></a> propuso que se empezaran a adoptar estándares
 cubiertos por patentes. La comunidad protestó y se retractaron.
 Se echaron atrás e insistieron en que cualquiera debería poder implementar
 libremente cualquier patente y en que los estándares tenían que ser libres
 para que cualquiera los implementara. Es una victoria interesante. Creo que
 ha sido la primera vez en que una organización de estándares ha tomado esta
 decisión. Es habitual que los organismos de normalización estén dispuestos a
 añadir a un estándar algo restringido por patentes, de modo que a la gente
 no se le permita implementarlo libremente. Tenemos que dirigirnos a otros
 organismos de normalización y reclamarles que cambien sus reglas.
 </p>
 
 <h3>2) Obtener la licencia de la patente</h3>
 
 <p>
 La segunda posibilidad consiste en conseguir una licencia para la patente,
 en lugar de evitarla. Esta no es necesariamente una opción. El titular de la
 patente no tiene por qué ofrecernos una licencia, no está obligado a
 hacerlo. Hace diez años, alguien cuyo pequeño negocio familiar consistía en
 la fabricación de máquinas tragamonedas para los casinos (que ya entonces
 usaban ordenadores) envió una carta a la Liga para la Libertad de
 Programación en la que solicitaba ayuda porque había recibido una amenaza de
 otra empresa que decía que ellos tenían la patente: «Usted no está
 autorizado a fabricar estas cosas. Cierre su negocio».
 </p>
 
 <p>
 Examiné esa patente. Cubría el montaje de una serie de ordenadores en red
 para jugar distintos juegos, de modo que cada ordenador disponía de más de
 un juego y permitía jugar a más de un juego a la vez.
 </p>
 
 <p>
 Ya ven que la oficina de patentes cree que es una idea brillante hacer
 cualquier cosa más de una vez. No se dan cuenta de que en informática esa es
 la forma más obvia de generalizar algo. Se ha hecho una vez y ahora se puede
 hacer cualquier número de veces, se puede escribir una subrutina. Creen que
 si alguien hace algo más de una vez, eso debe de significar que es un genio,
 que nadie puede llevarle la contraria y que tiene derecho a dar órdenes a
 todo el mundo. En cualquier caso, a esa persona no le ofrecieron la
 licencia. Tuvo que cerrar. Ni siquiera pudo afrontar el costo de acudir a
 los tribunales. Yo diría que esa patente concreta era una idea obvia. Es
 posible que un juez hubiera pensado lo mismo, pero nunca lo sabremos porque
 esa persona no se pudo permitir ir a juicio.
 </p>
 
 <p>
 No obstante, muchos titulares de patentes sí ofrecen licencias, pero a
 menudo piden mucho dinero por ellas. La compañía que concedía licencias para
 la patente sobre el recálculo en orden natural pedía un cinco por ciento de
 los ingresos brutos por cada hoja de cálculo vendida en EE.&nbsp;UU. Según
 me han dicho, ese era el precio reducido anterior al juicio. En caso de
 juicio, si el titular de la patente acaba ganando, exigirá más. Quizá uno
 pueda permitirse ese cinco por ciento por la licencia de una patente, pero
 ¿y si para desarrollar el programa hiciera falta la licencia de veinte
 patentes? Pues en ese caso todo el dinero que se consiga se lo llevarán las
 patentes. ¿Y si hay que obtener la licencia de ventiuna patentes?
 </p>
 
 <p>
 La gente del sector me decía que, en la práctica, dos o tres licencias de
 esas harían inviable cualquier negocio.
 </p>
 
 <p>
 Hay una situación en la que obtener una licencia por el uso de la patente es
 una muy buena solución. Es lo que les ocurre a las megacorporaciones
 multinacionales. Como estas empresas poseen muchas patentes e intercambian
 licencias entre ellas, se libran de la mayor parte del daño que provoca el
 sistema de patentes y disfrutan de todas sus ventajas. IBM publicó un <a
 href="https://web.archive.org/web/20150329104135/http://progfree.org/Links/prep.ai.mit.edu/ibm.think.article">artículo</a>
 en la revista <cite>Think</cite> (creo que era el número cinco de 1990)
 acerca de su cartera de patentes, donde se decía que IBM obtenía dos tipos
 de beneficios de sus 9.000 patentes estadounidenses (hoy en día el número
 debe de ser aún mayor). Estos eran, en primer lugar, los ingresos por
 regalías, y en segundo lugar, el acceso a las patentes de otros. Decían que
 el segundo beneficio era mucho mayor que el primero. De tal modo que el
 beneficio obtenido por IBM al permitírsele utilizar las ideas patentadas por
 otros multiplicaba por diez el beneficio directo que obtenía por ofrecer
 licencias. ¿Qué significa esto en realidad?
 </p>
 
 <p>
 ¿Cuál es el beneficio de IBM al tener acceso a las patentes de otros?
 Esencialmente es el beneficio de verse libre de los problemas que el sistema
 de patentes puede ocasionar. El sistema de patentes es como una lotería: con
 una patente determinada puede no ocurrir nada, suponer una gran cantidad de
 dinero para su titular o un desastre para todos los demás. Pero IBM es una
 empresa tan grande que le compensa. Pueden hacer una estimación general de
 las ventajas y desventajas del sistema de patentes.
 Para ellos, los problemas del sistema de patentes podrían haber sido diez
 veces mayores que las ventajas. Digo «podrían haber sido» porque mediante el
 intercambio de licencias IBM evita esos problemas. Los problemas son solo
 potenciales, en realidad no les afectan. Pero cuando evalúan los beneficios
 de evitarlos, su estimación es que de esa manera multiplican por diez el
 valor del dinero que obtienen por sus patentes.
 </p>
 
 <p>
 Este fenómeno del intercambio de licencias desmiente un mito muy común, el
 mito del «genio en la miseria», el mito de que las patentes «protegen» al
 «pequeño inventor». Estas son expresiones propagandísticas y no deberíamos
 emplearlas. Nos presentan la siguiente historia: imaginemos un brillante
 diseñador de lo que sea. Imaginemos que ha pasado años de privaciones en su
 ático diseñando algún nuevo y maravilloso prototipo y ahora quiere
 fabricarlo. ¿No es una vergüenza que las grandes empresas entren en
 competición con él, se queden con todo su negocio y él «se muera de hambre»?
 Debo señalar que aquellos que trabajan en sectores de alta tecnología
 normalmente no lo hacen por su cuenta, que las ideas no salen de la nada,
 sino que se apoyan en las ideas de otros, y que hoy por hoy esas personas
 tienen muchas oportunidades de conseguir un trabajo en caso de que lo
 necesiten. Así que este cuento, la posibilidad de que una idea brillante sea
 el fruto de esta brillante persona que trabaja sola, no es realista, al
 igual que la idea de que se encuentre en riesgo de pasar hambre. Pero sí es
 concebible que alguien tenga una idea que junto con otras cien o doscientas
 ideas pueda servir de base para la fabricación de algún tipo de producto, y
 que las grandes compañías puedan querer competir con esta persona.
 Veamos pues qué sucedería si esa persona intentara usar una patente para
 impedirlo. Él dirá: «Ah, no, IBM, no puedes competir conmigo. Tengo esta
 patente». E IBM responderá: «Veamos. Echemos un vistazo a tu
 producto. Mmmm. .. Yo tengo esta patente, y esta otra, y esta otra, y esta
 otra, y esta otra, y esta otra, que son infringidas por algunas partes de tu
 producto. Si crees que puedes luchar contra todas ellas en los tribunales,
 volveré y encontraré unas cuantas más. Así que, ¿por qué no intercambias
 licencias conmigo?». Y entonces el brillante pequeño inventor dirá: «Bueno,
 vale, intercambiemos licencias». Entonces podrá volver a su casa y fabricar
 ese maravilloso lo que sea, pero también IBM podrá hacerlo. IBM obtiene
 acceso a su patente y el derecho a competir con él, lo que significa que esa
 patente no lo «protegió» en absoluto. En realidad el sistema de patentes no
 sirve para eso.
 </p>
 
 <p>
 Las megacorporaciones se ven libres de la mayor parte del daño que ocasiona
 el sistema de patentes. Fundamentalmente disfrutan de sus ventajas, por eso
 quieren que existan patentes de software: son las únicas que se beneficiarán
 de ello. Pero si se es un pequeño inventor o se trabaja para una pequeña
 empresa, esa pequeña empresa no podrá hacerlo. Lo intentan, pero el problema
 es que no pueden conseguir una cantidad suficiente de patentes como para
 hacerlo. Toda patente apunta en una dirección determinada. De modo que si
 una pequeña empresa tiene patentes que apuntan aquí, ahí y allá, y alguien
 llega y le apunta con una patente diciendo: «Dame tu dinero», se ve
 indefensa..
 IBM puede hacerlo porque con esas 9.000 patentes apuntan a todas partes; no
 importa dónde estemos, probablemente haya una patente de IBM que apunte
 hacia nosotros. De modo que IBM casi siempre puede hacernos intercambiar
 licencias. Las empresas pequeñas rara vez pueden hacer que alguien
 intercambie licencias con ellas. Dicen que quieren las patentes con fines
 defensivos, pero no conseguirán las suficientes para poder defenderse.
 </p>
 
 <p>
 Hay casos en los que ni siquiera IBM puede hacer que alguien intercambie
 licencias con ella. Es lo que ocurre cuando hay una compañía cuyo único
 negocio es obtener patentes para sacarle dinero a la gente. La empresa que
 tenía la patente sobre el recálculo en orden natural era exactamente ese
 tipo de empresa. Su única actividad consistía en amenazar a la gente con
 demandas judiciales y sacarle dinero a quienes realmente estaban
 desarrollando algo.
 </p>
 
 <p>
 No hay patentes que cubran procedimientos legales. Supongo que los abogados
 comprenden lo penoso que sería tener que vérselas ellos mismos con el
 sistema de patentes. En consecuencia, no hay forma de obtener una patente
 para hacer que esa empresa intercambie licencias, lo que les permite ir por
 ahí exprimiendo a todo el mundo. Pero supongo que empresas como IBM calculan
 que eso es parte del precio que hay que pagar por hacer negocios, de manera
 que pueden vivir con ello.
 </p>
 
 <p>
 Así pues, esa es la opción de obtener la licencia de una patente, lo cual
 será posible o no, dependiendo de si uno puede permitírselo.
 </p>
 
 <h3>3) Revocar la patente en los tribunales</h3>
 
 <p>
 Supuestamente, para que algo se patente tiene que ser nuevo, útil y no
 obvio. Es el léxico usado en EE.&nbsp;UU. Creo que en otros países emplean
 términos diferentes que son prácticamente equivalentes. Por supuesto, cuando
 la oficina de patentes entra en juego, comienza por interpretar lo que es
 «nuevo» y «no obvio». «Nuevo» viene a significar «no lo tenemos en nuestros
 archivos» y «no obvio» suele significar «no obvio para alguien con un
 cociente intelectual de 50».
 </p>
 
 <p>
 Alguien que estudia la mayoría de las patentes de software emitidas en
 EE.&nbsp;UU. &mdash;o que al menos lo hacía, no sé si todavía puede con la
 cantidad que hay&mdash; decía que el 90% de ellas no pasaría el «test de
 Cristal City» [Cristal City es la zona de Washington donde se encuentra la
 oficina de patentes], con lo quería decir que si el personal de la oficina
 de patentes bajara al kiosco y adquiriera algunas revistas de informática,
 comprobaría que esas ideas ya se conocían.
 </p>
 
 <p>
 La oficina de patentes hace cosas tan obviamente estúpidas que ni siquiera
 es necesario estar al tanto de la tecnología más reciente para ver que son
 estúpidas. Esto no se limita al software. Una vez vi la famosa patente del
 ratón de Harvard, que se obtuvo mediante ingeniería genética inoculando un
 gen cancerígeno a una cepa de ratones. El gen cancerígeno ya era conocido y
 se inoculó empleando técnicas conocidas en una variedad de ratón ya
 conocida. La patente que obtuvieron cubría la inoculación de cualquier gen
 cancerígeno en cualquier tipo de mamífero empleando cualquier método. No
 hace falta saber nada de ingeniería genética para darse cuenta de que esto
 es ridículo.
 </p>
 
 <p>
 Me han dicho que estos excesos en las reivindicaciones son moneda corriente,
 y que la Oficina de Patentes de EE.&nbsp;UU. a veces invita a los
 solicitantes a ampliar aún más sus reivindicaciones. Básicamente, se trata
 de ampliar las reivindicaciones hasta que se sospeche que entran en colisión
 con alguna otra cosa que sin lugar a dudas es una técnica anterior. Este
 enfoque les permite calcular la tajada de espacio intelectual que pueden
 confiscar.
 </p>
 
 <p>
 Cuando los programadores echan un vistazo a las patentes de software, suelen
 decir: «¡Esto es ridículamente <a
 href="https://web.archive.org/web/20040604051644/http://people.qualcomm.com/karn/patents/patent-comments.html">
 obvio</a>!». Pero los burócratas de las patentes ponen todo tipo de
 pretextos para ignorar lo que piensan los programadores. Dicen: «¡Ah!, pero
 tienen que considerarlo teniendo en cuenta cuál era la situación hace diez o
 veinte años». Y descubrieron que repitiendo algo hasta la saciedad pueden
 hacer que uno acabe perdiendo el norte. Cualquier cosa puede parecer no
 obvia si se divide en partes cada vez más pequeñas y se analiza lo
 suficiente. Uno acaba perdiendo toda noción de obviedad, o al menos la
 capacidad de justificar cualquier criterio para discernir lo obvio de lo que
 no lo es. Luego, por supuesto, describen a todos los titulares de las
 patentes, sin excepción, como brillantes inventores. Por tanto, no podemos
 cuestionar su autoridad para decidir sobre lo que podemos o no podemos
 hacer.
 </p>
 
 <p>
 Si se va a juicio, los jueces tienden a ser un poco más estrictos acerca de
 lo que es obvio y lo que no lo es. El problema es que ir a juicio cuesta
 millones de dólares. Una vez oí hablar de un caso sobre patentes, recuerdo
 que la parte demandada era Qualcomm, y creo que el fallo fue finalmente de
 trece millones de dólares, cuya mayor parte se destinó a pagar a los
 abogados de ambas partes. Quedaron unos pocos millones de dólares para el
 demandante, ya que Qualcomm perdió.
 </p>
 
 <p>
 La validez de una patente depende en gran medida de circunstancias
 históricas. Las circunstancias son muchas, tales como qué es lo que se
 publicó exactamente y en qué fecha. Y de toda esa información, qué es lo que
 no se ha perdido y realmente se puede encontrar, como fechas concretas y
 cosas parecidas. Son muchas las circunstancias históricas que determinan si
 una patente es válida o no.
 
 De hecho, resulta extraño que la <a
 href="https://patents.justia.com/patent/4873662">patente de British Telecom
 sobre el seguimiento de hipervínculos mediante acceso telefónico</a> se
 solicitara, según creo, en 1975. Creo que fue en 1974 cuando por primera vez
 desarrollé el paquete info. Este paquete permite utilizar hipervínculos, y
 la gente usaba el teléfono para conectarse y acceder al sistema. Así que lo
 cierto es que yo produje con anterioridad una obra que utilizaba la técnica
 descrita en esa patente. De modo que esa es la segunda idea patentable que
 he tenido en mi vida, aunque creo que no tengo ninguna prueba de ello, no
 pensé que fuera lo suficientemente interesante como para publicarla. Después
 de todo, la idea de seguir un hipervínculo la tomé de la demo del editor de
 Englebart. Fue él quien tuvo una idea que merecía publicarse.
 A lo que había hecho lo llamé «hipertexto del pobre», dado que tenía que
 implementarlo en el contexto de TECO. No tenía tanta capacidad como el
 hipertexto de Englebart, pero al menos era útil para hojear documentación,
 que era todo lo que pretendía. Y en cuanto a que hubiera acceso telefónico
 al sistema, bueno, lo había, pero no se me ocurrió que lo uno tuviera
 ninguna relación particular con lo otro. No iba a publicar un artículo para
 decir: «¡Oh!, he implementado el hipertexto del pobre, y sabéis qué,
 ¡también hay acceso telefónico en el ordenador!». Sospecho que no hay manera
 de precisar en qué fecha implementé esto. Y ¿fue publicado en algún sentido?
 Bueno, invitamos a la gente a que entrara en ARPAnet y se registrara en
 nuestra máquina, de modo que pudieran buscar documentación utilizando info y
 ver cómo funcionaba todo. Si nos hubieran preguntado, habrían descubierto
 que teníamos acceso telefónico. Como pueden ver, una circunstancia histórica
 determina si una técnica es original o no.
 </p>
 
 <p>
 Claro que ahora hay una publicación de Englebart sobre el hipertexto, que se
 presentará en los tribunales. De todos modos, no creo que diga nada sobre
 disponer de acceso telefónico en el ordenador, de manera que no está claro
 si resultará suficiente. Así pues, esta es una opción, la posibilidad de
 acudir a los tribunales para revocar una patente.
 </p>
 
 <p>
 Debido a los gastos que supone, normalmente ni se plantea, aun cuando se
 puedan encontrar pruebas sólidas de la existencia de una técnica anterior
 que deberían bastar para revocar la patente. En consecuencia, una patente
 inválida, que teóricamente no debería existir (aunque en realidad existen
 muchas de ellas) es un arma peligrosa. Si alguien nos ataca con una patente
 inválida, puede causarnos serios problemas. Podemos tratar de disuadirlo
 mostrándole la técnica anterior. Quizá de ese modo se asuste, o puede que
 piense: «Estás fingiendo, sabemos que en realidad no puedes ir a juicio, no
 te lo puedes permitir, así que te demandaremos de todos modos».
 </p>
 
 <p>
 Estas tres son opciones que a veces se pueden utilizar, pero a menudo no es
 posible. De modo que hay que hacer frente a una patente tras otra. Cada vez
 que descubrimos que podemos utilizar una de esas opciones, enseguida aparece
 una nueva patente, y luego otra, y otra. Es como cruzar un campo de minas. A
 cada paso que se da, a cada decisión de diseño que se toma, es probable que
 no nos topemos con una patente, de modo que es posible dar unos cuantos
 pasos sin que se produzca una explosión. Pero la probabilidad de cruzar todo
 el campo de minas y llegar a desarrollar el programa que se quiere
 desarrollar sin toparse con ninguna patente es tanto menor cuanto mayor es
 el programa.
 </p>
 
 <p>
 La gente solía decirme: «Bueno, hay patentes en otras áreas, ¿por qué habría
 que excluir el software?». Observen qué suposición más grotesca hay ahí, la
 de que todos tenemos que someternos al sistema de patentes de alguna
 manera. Es como decir: «Algunos contraen cáncer, ¿por qué tú deberías verte
 libre de él?». Tal como yo lo veo, que una persona no contraiga cáncer es
 algo bueno. Pero tras esto hay una pregunta menos tendenciosa, una buena
 pregunta: ¿Es el área del software diferente de las demás? ¿Debería la
 política de patentes ser diferente en las diferentes áreas y, en tal caso,
 por qué?
 </p>
 
 <p>
 Permítanme... El efecto de las patentes no es el mismo en todas las áreas
 donde se aplican porque la relación de las patentes con los productos es
 diferente según el área de especialización.
 </p>
 
 <p>
 En uno de los extremos tenemos a las empresas farmacéuticas, donde se
 patenta una fórmula química, de modo que esa patente cubre un solo
 producto. Cualquier nuevo producto no estaría cubierto por la patente que ya
 existe. En caso de que el nuevo producto se patente, el titular de la
 patente será quien haya elaborado el nuevo producto.
 </p>
 
 <p>
 Eso se ajusta a la idea ingenua que tenemos del sistema de patentes, la idea
 de que si alguien diseña un producto nuevo, va a conseguir «la patente», la
 idea de que hay una patente por producto y que la patente cubre la idea de
 ese producto. En algunas áreas esto se aproxima a la verdad, en otras está
 muy lejos de ser cierto. En el área de la informática los paquetes de
 software suelen ser muy grandes. Utilizan muchas ideas diferentes en nuevas
 combinaciones. Si el programa es nuevo, y no simplemente copiado,
 probablemente utilice una combinación diferente de ideas, combinadas, por
 supuesto, con código nuevo, porque no es posible hacer que esas ideas
 funcionen mágicamente con solo pronunciar sus nombres. Hay que
 implementarlas todas.
 Hay que implementarlas todas en esa combinación. La consecuencia es que
 incluso cuando se escribe un programa se utiliza gran cantidad de ideas
 diferentes, cada una de las cuales puede estar patentada por alguien. Un par
 de ellas podría estar patentada como combinación por alguien. Puede haber
 varias maneras diferentes de describir una idea, que puede estar patentada
 por distinta gente. Así que posiblemente haya miles de cosas, miles de
 aspectos vulnerables en el programa, que podrían estar ya patentados por
 alguien. Por eso las patentes de software suelen obstaculizar el progreso
 del software, la tarea de desarrollar software.
 </p>
 
 <p>
 Si cada patente correspondiera a un solo producto, esas patentes no
 obstaculizarían el desarrollo de nuevos productos, porque al desarrollar un
 nuevo producto éste no podría estar ya patentado por otra persona. Pero
 cuando en un producto se combinan muchas ideas diferentes es muy probable
 que ese producto esté ya patentado por otra persona. De hecho, hay estudios
 económicos que demuestran que la imposición de un sistema de patentes en un
 campo en el que se da una innovación incremental puede ralentizar el
 progreso.
 Los defensores de las patentes de software dicen: «Bueno, sí, puede que haya
 problemas, pero más importante que cualquier problema es el hecho de que las
 patentes deben promover la innovación, y esto es tan importante que los
 problemas que causen son irrelevantes». Claro que esto no lo dicen en voz
 alta porque es ridículo, pero implícitamente quieren haceros creer que el
 sistema de patentes promueve el progreso y que eso compensa cualquier coste
 posible. En realidad no hay razones para creer que promueva el
 progreso. Ahora tenemos un modelo que demuestra claramente el modo en que
 las patentes pueden ralentizar el progreso. El caso en el que se aplica ese
 modelo, la innovación incremental, describe muy bien el área del software.
 </p>
 
 <p>
 ¿Por qué se encuentra el software en ese extremo del espectro? El motivo es
 que en el campo del software desarrollamos objetos matemáticos ideales. Se
 puede construir un complejo castillo y hacerlo descansar sobre una fina
 línea, y se mantendrá en pie, porque no pesa nada. En otras áreas la gente
 tiene que hacer frente a la obstinación de la materia, de los objetos
 físicos. La materia hace lo que tiene que hacer. Se puede tratar de
 construir un modelo, pero si el comportamiento real no se ajusta al modelo
 entonces tenemos un problema, porque el reto es construir objetos físicos
 que funcionen en la realidad.
 </p>
 
 <p>
 Si quiero poner una declaración <code>if</code> dentro de una declaración
 <code>while</code>, no tengo que preocuparme de que la declaración
 <code>if</code> pueda oscilar a una determinada frecuencia, friccionar con
 la declaración <code>while</code> y llegar a romperse. No tengo que
 preocuparme de que oscile a una frecuencia demasiado alta y genere una señal
 que modifique el valor de alguna otra variable. No tengo que preocuparme de
 cuánta corriente puede requerir la declaración <code>if</code> y si podrá
 disipar el calor dentro de la declaración <code>while</code>. O de si habrá
 una caída de tensión en la declaración <code>while</code> que impida que la
 declaración <code>if</code> funcione.
 No tengo que preocuparme de que si ejecuto el programa en un entorno de agua
 salada, el agua pueda introducirse entre las declaraciones <code>if</code> y
 <code>while</code> y provocar corrosión. Cuando hago referencia al valor de
 una variable, no tengo que preocuparme de que se exceda ningún límite si eso
 sucede veinte veces. Cuando hago referencia a la variable tampoco tengo que
 preocuparme de su capacitancia, ni de si habrá tiempo suficiente para que se
 cargue su valor. Cuando escribo el programa no tengo que preocuparme de cómo
 ensamblaré físicamente cada copia ni de si podré arreglármelas para insertar
 la declaración <code>if</code> dentro de la declaración
 <code>while</code>. No tengo que preocuparme de cómo acceder a la
 declaración <code>if</code>, en caso de que se rompa, para retirarla y
 sustituirla por una nueva.
 </p>
 
 <p>
 Hay muchos problemas de los que no tenemos que preocuparnos en el
 software. Eso lo hace esencialmente más sencillo. Es mucho más sencillo
 escribir un programa que diseñar un objeto físico que funcione. Esto puede
 parecer extraño, porque habrán oído hablar de lo difícil que es diseñar
 software, de los enormes problemas que supone y de cómo ingeniárselas para
 resolverlos. En realidad no están hablando de lo mismo que yo. Yo estoy
 comparando sistemas físicos y sistemas de software de la misma complejidad,
 con el mismo número de elementos. Estoy diciendo que un sistema de software
 es mucho más fácil de diseñar que un sistema físico. Pero la inteligencia de
 la gente que trabaja en estos terrenos diferentes es similar, de modo que
 ¿qué hacemos cuando nos encontramos en un terreno sencillo? ¡Lo hacemos
 avanzar! Llevamos nuestras capacidades al límite.
 Si los sistemas del mismo tamaño son sencillos, hagamos sistemas diez veces
 más grandes, ¡así será complicado! Y es lo que hacemos. Hacemos sistemas de
 software que son mucho mayores que los sistemas físicos con respecto al
 número de partes que los componen. Un sistema físico cuyo diseño contiene un
 millón de piezas diferentes es un megaproyecto. Un programa informático cuyo
 diseño contiene un millón de piezas puede tener unas 300.000 líneas, unas
 pocas personas pueden escribirlo en un par de años. No sería un programa
 gigantesco. GNU Emacs contiene ya varios millones de piezas, creo. Tiene un
 millón de líneas de código. Es un proyecto realizado prácticamente sin
 financiación, realizado en su mayor parte por gente en su tiempo libre.
 </p>
 
 <p>
 Hay otra gran ventaja. Si usted ha diseñado un producto físico, el siguiente
 paso será diseñar la fábrica para construirlo. Edificar esa fábrica puede
 costar millones o decenas de millones, mientras que para hacer copias del
 programa no hay más que escribir <kbd>copy</kbd>. La misma orden de copiar
 copiará cualquier programa. ¿Queremos copias en CD? De acuerdo, entonces
 grabamos un CD maestro y lo enviamos a una planta de CD. Utilizarán el mismo
 equipamiento para copiar cualquier contenido en un CD, no tenemos que
 levantar una fábrica para hacer este producto. Hay una tremenda
 simplificación y una tremenda reducción de costes en el diseño.
 
 La consecuencia, digamos para una compañía automovilística que se gastará 50
 millones de dólares en levantar una planta para fabricar un nuevo modelo, es
 que puede contratar a unos cuantos abogados para que se ocupen de las
 negociaciones relativas a las patentes. Podrían incluso afrontar un proceso
 judicial si quisieran. Diseñar un programa de la misma complejidad puede
 costar 50.000 o 100.00 dólares. En comparación, el coste de lidiar con el
 sistema de patentes es devastador. De hecho, concebir un programa de la
 misma complejidad que el diseño mecánico de un coche llevaría probablemente
 un mes de trabajo. ¿Cuántas partes tiene un coche (uno que no contenga
 ningún ordenador)?[<a href="#f1">1</a>] No son muchas. Esto no quiere decir
 que diseñar un buen coche sea sencillo, sino solo que no contiene muchas
 piezas diferentes.
 </p>
 
 <p>
 La programación es muy diferente de otros campos porque trabajamos con
 objetos matemáticos, cuyo diseño es muchísimo más sencillo, y debido a ello
 habitualmente hacemos sistemas que son muchísimo más grandes, y eso con tan
 solo un puñado de personas. El resultado es que entonces el sistema de
 patentes con el que nos encontramos, en lugar de ser del tipo «un producto,
 una patente», es un sistema en el que un producto comprende multitud de
 ideas que podrían estar ya patentadas.
 </p>
 
 <p>
 La mejor manera de explicarlo es comparándolo con una sinfonía. Una sinfonía
 es también larga y contiene muchas notas, y probablemente utiliza muchas
 ideas musicales. Imaginen que los Gobiernos europeos del siglo XVIII
 hubieran decidido que querían promover el progreso de la música sinfónica
 estableciendo una Oficina Europea de Patentes Musicales que concediera
 patentes para todo tipo de ideas musicales que pudieran expresarse en
 palabras. Imaginen ahora que se encuentran en 1800, ustedes son Beethoven y
 quieren componer una sinfonía. Descubrirían que conseguir que su sinfonía no
 infringiera ninguna patente sería más complicado que escribir una buena
 sinfonía.
 
 Si protestaran por ello, los titulares de las patentes dirían, «Ah,
 Beethoven, reniegas solo porque no tienes ideas propias. Lo único que
 pretendes es apropiarte de nuestras invenciones». Lo cierto es que Beethoven
 concibió multitud de ideas musicales nuevas, pero tenía que utilizar muchas
 ideas musicales ya existentes a fin de componer música reconocible, a fin de
 componer música que pudiera gustar a los oyentes, música que estos pudieran
 reconocer como tal. Nadie es tan brillante como para reinventar la música y
 componer algo que la gente quiera escuchar. <a
 href="https://en.wikipedia.org/wiki/Pierre_Boulez">Pierre Boulez</a> dijo
 que intentaría hacerlo, ¿pero quién escucha a Pierre Boulez?
 </p>
 
 <p>
 Nadie es tan brillante como para reinventar la informática desde cero. Si lo
 hiciera, lo que escribiera les resultaría a los usuarios tan extraño que no
 querrían utilizarlo. Si miran hoy un procesador de textos encontrarán, creo,
 cientos de funcionalidades diferentes. Si se desarrolla un nuevo procesador
 de textos de calidad e innovador, eso quiere decir que contendrá algunas
 ideas nuevas, pero ha de contener también cientos de viejas ideas. Si no se
 nos permite utilizarlas, no podremos hacer un procesador de textos
 innovador.
 </p>
 
 <p>
 Dado que la tarea de desarrollar software es tan grande, no necesitamos
 ningún plan artificial para incentivar ideas nuevas. Solo se necesita gente
 que escriba software, y ellos concebirán algunas ideas nuevas. Si queremos
 escribir un programa y hacer que sea bueno, tendremos algunas ideas y
 encontraremos la manera de utilizar algunas de ellas. Lo que solía suceder,
 puesto que yo trabajé en el campo del software antes de que hubiera patentes
 de software, es que la mayoría de los desarrolladores publicaban cualquier
 nueva idea que consideraran relevante, que pensaran que podía reportarles
 reconocimiento o consideración.
 
 No publicaban las ideas menores o insignificantes porque sería tonto
 hacerlo. Ahora se supone que el sistema de patentes estimula la divulgación
 de ideas. De hecho en los viejos tiempos nadie mantenía las ideas en
 secreto. Mantenían en secreto el código, es cierto. Al fin y al cabo, el
 código representaba el grueso del trabajo. Mantenían en secreto el código y
 publicaban las ideas, de manera que los empleados obtenían reconocimiento y
 se sentían bien. Tras la aparición de las patentes de software, seguían
 manteniendo el código en secreto y patentaban las ideas, así que lo cierto
 es que no se ha fomentado la divulgación de ninguna manera. Las mismas cosas
 que se mantenían en secreto antes se siguen manteniendo en secreto ahora,
 pero las ideas que solían publicarse y podíamos utilizar, ahora son
 probablemente patentadas y quedan fuera de alcance durante veinte años.
 </p>
 
 <p>
 ¿Qué puede hacer un país para cambiar esto? ¿Qué política deberíamos adoptar
 para resolver este problema? Hay dos maneras de abordar la cuestión. Una
 apunta al lugar donde se solicitan y emiten las patentes, la oficina de
 patentes. La otra se refiere al momento en que se solicitan las patentes, la
 cuestión de qué es lo que cubre una patente.
 </p>
 
 <p>
 Cambiar los criterios para emitir una patente, o simplemente adoptar un buen
 criterio para emitir patentes, puede funcionar en un país que aún no haya
 autorizado las patentes de software, por ejemplo en la mayor parte de
 Europa. Bastaría con consolidar las normas de la Oficina Europea de Patentes
 que dicen que el software no es patentable. Esta es una buena solución para
 Europa. Europa está ahora tomando en consideración una directiva sobre las
 patentes de software. La directiva, supongo, puede abarcar más cosas, pero
 una de sus implicaciones importantes es para las patentes de
 software. Simplemente modificando esto para decir que las ideas de software
 no pueden patentarse, la mayor parte de Europa se libraría del problema, con
 excepción de algunos países que han aceptado el problema por sí solos. Por
 desgracia, uno de ellos es el Reino Unido. Por desgracia para ustedes.
 </p>
 
 <p>
 Esta estrategia no sirve en EE.&nbsp;UU. La razón es que EE.&nbsp;UU. tiene
 ya gran cantidad de patentes de software y ningún cambio en los criterios
 para emitir patentes nos libraría de las ya existentes.[<a href="#f2">2</a>]
 En realidad estas patentes no están oficialmente identificadas como patentes
 de software. Yo hablo de patentes de software, pero ¿qué quiero decir en
 realidad? Me refiero a patentes que podrían aplicarse al software, patentes
 que podrían hacer que nos demandaran por escribir software.
 
 La oficina de patentes no distingue entre patentes de software y otro tipo
 de patentes. De manera que, de hecho, cabe la posibilidad de que cualquier
 patente podría hacer que nos demandaran por escribir software. Así que, en
 EE.&nbsp;UU., la solución consistiría en modificar la aplicabilidad, el
 alcance de las patentes, diciendo que una simple implementación de software
 que se ejecute en un ordenador genérico y que en sí misma no infrinja la
 patente no está cubierta por ninguna patente y no puede ser objeto de
 denuncia. Este es otro tipo de solución.
 </p>
 
 <p>
 El primer tipo de solución, la que se refiere al tipo de patentes que pueden
 ser válidas, es una buena solución para utilizar en Europa.
 </p>
 
 <p>
 Cuando en EE.&nbsp;UU. se empezaron a introducir las patentes de software,
 no hubo debate. De hecho, nadie lo advirtió. El mundo del software, en su
 mayor parte, ni siquiera se dio cuenta. En 1981 hubo una decisión del
 Tribunal Supremo relativa a una patente sobre un proceso de curado del
 caucho. La sentencia decía que el hecho de que el aparato incluyera un
 ordenador y un programa como parte del proceso para curar el caucho no lo
 inhabilitaba para ser patentado.
 Al año siguiente, un tribunal de apelación especializado en los casos de
 patentes invirtió los términos. Dijeron que el hecho de que algo contenga un
 ordenador y un programa lo hace patentable. Así es cómo EE.&nbsp;UU. comenzó
 a introducir patentes sobre procedimientos industriales. Esto se debe a que
 los procedimientos industriales se realizan en un ordenador, y eso los hacía
 patentables. El caso es que se tomó esa decisión, y creo que la patente
 sobre el cálculo en orden natural fue una de las primeras, o incluso puede
 que fuera la primera. En los años ochenta no lo sabíamos.
 </p>
 
 <p>
 Fue alrededor de los noventa cuando los programadores de
 EE.&nbsp;UU. empezaron a darse cuenta del peligro que representaban las
 patentes de software. De modo que yo conocía cómo funcionaba la informática
 antes y después, y no he visto ningún aumento del progreso a partir de
 1990. En EE.&nbsp;UU. no hubo debate, pero en Europa ha habido un amplio
 debate político. Hace unos años hubo presiones para enmendar el tratado de
 Munich que estableció la <a href="https://www.epo.org/">Oficina Europea de
 Patentes</a>. Hay una <a
 href="https://www.epo.org/law-practice/legal-texts/html/epc/1973/e/ar52.html">cláusula
 que dice que el software no es patentable</a>. La ofensiva pretendía
 enmendarla para que se permitieran las patentes de software. Pero la
 comunidad se dio cuenta de esto, y fueron los desarrolladores y usuarios de
 software libre quienes lideraron la oposición.
 </p>
 
 <p>
 Pero no somos los únicos amenazados por las patentes de software. Todos los
 desarrolladores de software están amenazados, e incluso los usuarios. Por
 ejemplo, cuando Paul Heckel vio que sus amenazas no intimidaban demasiado a
 Apple, amenazó con empezar a demandar a los clientes de Apple. Eso sí asustó
 a Apple. Calcularon que no podían permitirse que sus clientes fueran
 demandados de esa manera, aun cuando al final ganaran. De modo que también
 los usuarios pueden ser denunciados, bien como forma de atacar a un
 desarrollador, o simplemente como un medio para sacarles dinero o provocar
 confusión.
 </p>
 
 <p>
 Todos los desarrolladores y usuarios de software son vulnerables, pero fue
 la comunidad del software libre europea la que tomó el liderazgo para
 organizar la oposición. De hecho, los países que gobiernan la Oficina
 Europea de Patentes han votado ya dos veces en contra de enmendar el
 tratado. Luego intervino la UE, y cada Dirección General adoptó una posición
 diferente.
 </p>
 
 <p> La Dirección que se ocupa de promover el software es contraria a las
 patentes de software, pero ellos no se encargaban de este asunto. Quien está
 al cargo es la Dirección General del Mercado Interno, cuyo líder es
 favorable a las patentes de software. Ignoraron por completo la opinión
 pública y propusieron una directiva que permitía las patentes de
 software.[<a href="#f3">3</a>] El Gobierno francés ya ha dicho que se opone
 a esa directiva. En varios otros países europeos ya se está trabajando para
 oponerse a las patentes de software, y es vital que aquí se empiece a hacer
 lo mismo.  </p>
 
 <p>
 Según Hartmut Pilch, que es uno de los líderes de la lucha europea contra
 las patentes de software, la que hace más fuerza es la <a
 href="https://www.gov.uk/topic/intellectual-property/patents">Oficina de
 Patentes del Reino Unido</a>. La Oficina de Patentes del Reino Unido tiene
 una predisposición favorable a las patentes de software. Llevó a cabo una
 encuesta pública y la mayoría de las respuestas fueron contrarias a las
 patentes de software. Luego redactaron un informe diciendo que la gente
 parecía estar conforme con ellas, ignorando por completo las
 respuestas. Resulta que la comunidad del software libre pidió que se
 enviaran las respuestas a la Oficina de Patentes, y también a ellos, para
 así publicarlas. De modo que las publicaron, y la mayoría eran contrarias. A
 la vista del informe de la Oficina de Patentes del Reino Unido nadie habría
 pensado que era así.
 </p>
 
 <p>
 Ellos (la Oficina de Patentes y Marcas Comerciales del Reino Unido) utilizan
 un concepto que llaman «efecto técnico». Es un concepto que se puede estirar
 enormemente. Se supone que hay que pensar que significa que la idea de un
 programa solo es patentable si está estrechamente relacionada con
 actividades físicas concretas. Si la interpretación es esa, el problema
 estaría prácticamente resuelto. Si las únicas ideas de software que pudieran
 patentarse fueran las que realmente están relacionadas con una técnica
 particular, con un resultado físico concreto que podría haberse patentado
 sin utilizar un programa, eso estaría bien. El problema es que se puede
 ampliar esa condición. Se puede describir como un resultado físico el
 resultado que se obtiene ejecutando algún programa. ¿En qué se diferencia
 este resultado físico de cualquier otro? En que es el resultado de esa
 computación. La consecuencia es que la Oficina de Patentes del Reino Unido
 está planteando una propuesta que parece conducir a la resolución del
 problema y que en realidad da carta blanca para patentar casi todo.
 </p>
 
 <p>
 En el mismo ministerio hay personas que se ocupan también del copyright, que
 en realidad no tiene nada que ver con las patentes de software, solo que las
 personas al cargo son las mismas. La cuestión es cómo se interprete la
 reciente directiva de la UE sobre el copyright, una horrible ley como la <a
 href="https://www.eff.org/issues/dmca">Ley de Copyright del Milenio Digital
 de EE.&nbsp;UU.</a>. Pero cada país dispone de cierto margen en cuanto a la
 modalidad de implementación. El Reino Unido está proponiendo la forma más
 draconiana posible de implementar esta directiva. Si se implementara de
 manera apropiada se podría reducir en gran medida el daño que produce, pero
 el Reino Unido quiere maximizar el efecto tiránico de la directiva. Parece
 que hay cierto organismo, el <a
 href="https://webarchive.nationalarchives.gov.uk/ukgwa/20070603164510/http://www.dti.gov.uk/">Departamento
 de Comercio e Industria</a>, al que hay que poner freno. Es necesario poner
 límites a sus actividades e impedirle crear nuevas formas de poder.
 </p>
 
 <p>
 Las patentes de software enredan a todos los desarrolladores de software y a
 todos los usuarios de ordenadores en una nueva forma de burocracia. Si las
 empresas que utilizan ordenadores se dieran cuenta de la cantidad de
 problemas que esto puede ocasionarles se pondrían en pie de guerra y estoy
 seguro de que podrían detenerlo. A las empresas no les gustan las trabas
 burocráticas.
 </p>
 
 <p>
 Claro que a veces cumple una función importante. Hay algunos terrenos en los
 que desearíamos que el Gobierno del Reino Unido hiciera una labor más
 cuidadosa imponiendo trámites burocráticos a ciertas empresas, como cuando
 se trata de trasladar animales de un lugar a otro.[<a href="#f4">4</a>] Pero
 en ciertos casos, cuando no sirve más que para crear monopolios artificiales
 que permiten que alguien interfiera en el desarrollo del software y exprima
 a los desarrolladores y usuarios, entonces hemos de rechazarla.
 </p>
 
 <p>
 Debemos hacer que los directivos de las empresas sean conscientes de lo que
 las patentes de software les pueden hacer. Anímelos a apoyar la <a
 href="https://www.ffii.org/">lucha contra las patentes de software en
 Europa</a>.
 </p>
 
 <p>
 La batalla no ha terminado. Aún se puede ganar.
 </p>
 <div class="column-limit"></div>
 
 <h3 class="footnote">Notas</h3>
 <ol>
   <li id="f1">Una transmisión automática consta de entre 300 y 400 partes únicas, y por lo
 general la transmisión es el componente más complicado de un
 automóvil. Diseñar una transmisión puede llevar de seis meses a un año, y
 luego puede llevar aún más tiempo construirla y hacerla funcionar. Sin
 embargo, un programa con entre 500 y 600 partes funcionales tendría entre
 200 y 300 líneas de código, y a un buen programador le llevaría entre un día
 y una semana escribirlo, probarlo y depurarlo.</li>
   
   <li id="f2">Digo «patentes de software», pero ¿qué quiero decir en realidad? La oficina
 de patentes de EE.&nbsp;UU. no divide oficialmente las patentes en patentes
 de software y las demás. De modo que, de hecho, cualquier patente, si puede
 aplicarse a algún software, podría servir para demandar a quien escribe
 software. Las patentes de software son patentes que podrían aplicarse al
 software, patentes que podrían servir para demandar a quien escribe
 software.</li>
 
   <li id="f3">El 6 de julio de 2005, el Parlamento europeo rechazó la directiva de
 patentes de software con 648 votos negativos de 680. No obstante, no debemos
 dejar que este asunto caiga en el olvido, ya que quienes presionaron en
 favor de las patentes están tratando de resucitar la directiva recientemente
 rechazada. También hemos de asegurarnos de que la Oficina Europea de
 Patentes y las oficinas nacionales de los diferentes países de la UE dejen
 de conceder patentes para el software que está incluido en otro tipo de
 invenciones.</li>
 
   <li id="f4">Para evitar que se extienda la fiebre aftosa.</li>
 </ol>
 
 <hr class="no-display" />
 <div class="edu-note c"><p id="fsfs">Este ensayo está publicado en el libro <a
 href="https://shop.fsf.org/product/free-software-free-society/"><cite>Software
 libre para una sociedad libre: Selección de ensayos de Richard
 M. Stallman</cite></a>.</p></div>
 </div>
 
 <div class="translators-notes">
 
 <!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
  </div>
 </div>
 
 <!-- for id="content", starts in the include above -->
 <!--#include virtual="/server/footer.es.html" -->
 <div id="footer" role="contentinfo">
 <div class="unprintable">
 
 <p>Envíe sus consultas acerca de la FSF y GNU a <a
 href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. Existen también <a
 href="/contact/">otros medios para contactar</a> con la FSF. <br /> Para
 avisar de enlaces rotos y proponer otras correcciones o sugerencias,
 diríjase a <a
 href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>.</p>
 
 <p>
 <!-- TRANSLATORS: Ignore the original text in this paragraph,
         replace it with the translation of these two:
 
         We work hard and do our best to provide accurate, good quality
         translations.  However, we are not exempt from imperfection.
         Please send your comments and general suggestions in this regard
         to <a href="mailto:web-translators@gnu.org">
 
         &lt;web-translators@gnu.org&gt;</a>.</p>
 
         <p>For information on coordinating and contributing translations of
         our web pages, see <a
         href="/server/standards/README.translations.html">Translations
         README</a>. -->
 El equipo de traductores al español se esfuerza por ofrecer traducciones
 fieles al original y de buena calidad, pero no estamos libres de cometer
 errores.<br /> Envíe sus comentarios y sugerencias sobre las traducciones a
 <a
 href="mailto:web-translators@gnu.org">&lt;web-translators@gnu.org&gt;</a>.
 </p><p>Consulte la <a href="/server/standards/README.translations.html">Guía
 para las traducciones</a> para obtener información sobre la coordinación y
 el envío de traducciones de las páginas de este sitio web.</p>
 </div>
 
 <!-- Regarding copyright, in general, standalone pages (as opposed to
      files generated as part of manuals) on the GNU web server should
      be under CC BY-ND 4.0.  Please do NOT change or remove this
      without talking with the webmasters or licensing team first.
      Please make sure the copyright date is consistent with the
      document.  For web pages, it is ok to list just the latest year the
      document was modified, or published.
      
      If you wish to list earlier years, that is ok too.
      Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
      years, as long as each year in the range is in fact a copyrightable
      year, i.e., a year in which the document was published (including
      being publicly visible on the web or in a revision control system).
      
      There is more detail about copyright years in the GNU Maintainers
      Information document, www.gnu.org/prep/maintain. -->
 <p>Copyright &copy; 2002, 2006, 2021 Richard Stallman.</p>
 
 <p>Esta página está bajo licencia <a rel="license"
 href="http://creativecommons.org/licenses/by-nd/4.0/deed.es_ES">Creative
 Commons Reconocimiento-SinObraDerivada 4.0 Internacional</a>.</p>
 
 <!--#include virtual="/server/bottom-notes.es.html" -->
 <div class="translators-credits">
 
 <!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
 <strong>Traducido originalmente por la editorial Traficantes de Sueños,
 2004.</strong> Revisión: Equipo de traductores al español de GNU, 2020.</div>
 
 <p class="unprintable"><!-- timestamp start -->
 Última actualización:
 
 $Date: 2022/04/16 12:08:24 $
 
 <!-- timestamp end -->
 </p>
 </div>
 </div>
 <!-- for class="inner", starts in the banner include -->
 </body>
 </html>