browse.php

<!--#set var="ENGLISH_PAGE" value="/philosophy/software-patents.en.html" -->

<!--#include virtual="/server/header.es.html" -->
<!-- Parent-Version: 1.98 -->
<!-- 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>
<style type="text/css" media="print,screen"><!--
ul.big-list li { margin-top: 1em; }
ol.compact li { margin-top: .5em; }
i.aside { color: #505050; }
-->
</style>

<!--#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://web.archive.org/web/20221028103335/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/rms-speech-cambridgeuni-england2002.ogg">grabación
de audio</a> de Nicholas Hill. Edición HTML y enlaces de Markus Kuhn y
administradores del sitio de GNU.</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>


<div class="toc">
<h3 class="no-display">Índice general</h3>
<ul>
  <li><a href="#copyright-vs-patent">Diferencias entre copyright y patentes</a></li>
  <li><a href="#patent-system">El sistema de patentes</a></li>
  <li><a href="#dealing-with-patents">Cómo puede un desarrollador afrontar las
patentes</a>
    <ul>
      <li><a href="#patent-avoiding">Evitar la patente</a></li>
      <li><a href="#patent-licensing">Obtener la licencia de la patente</a></li>
      <li><a href="#patent-overturning">Revocar la patente en los tribunales</a></li>
    </ul>
  </li>
  <li><a href="#software-specificity">Características del área de la
programación</a></li>
  <li><a href="#software-patent-policies">Cómo abordar el problema de las patentes
de software en las políticas públicas</a></li>
  <li><a href="#footnotes">Notas</a></li>
</ul>
</div>


<h3 id="copyright-vs-patent">Diferencias entre copyright y patentes</h3>

<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 porque da por sentado que, sea cual
fuere la cosa de la que se está hablando, ha de considerarse como un tipo de
propiedad, cuando en realidad esa es solo una entre muchas otras
posibilidades. Con la expresión «propiedad intelectual» se prejuzga la
cuestión más básica en cualquier ámbito que se esté considerando. No
contribuye a pensar de forma clara y con amplitud de miras.
</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. Cubren diferentes
actividades y aspectos de la vida, lo que dio lugar a medidas políticas sin
ninguna relación entre sí. Si intentamos analizarlas metiéndolas todas en el
mismo saco, seguramente llegaremos a conclusiones disparatadas. No se puede
tener ninguna opinión sensata y lúcida en absoluto acerca de la «propiedad
intelectual». Si queremos pensar con claridad, no las mezclemos. Analicemos
el copyright y luego las patentes. Estudiemos la ley de copyright y
estudiemos la ley de patentes por separado.
</p>

<p>
Por citar algunas de las mayores diferencias entre el copyright y las
patentes:
</p>

<ul class="big-list">
<li>
<p>
El copyright cubre la expresión particular de una obra, no las ideas. Es un
error legal considerar que el copyright cubre las ideas. Las patentes, en
cambio,  cubren <em>únicamente </em> ideas y el uso de las ideas.
</p>
</li>

<li>
<p>
El copyright se aplica automáticamente, mientras las patentes las otorga la
oficina de patentes en respuesta a una solicitud. Cuesta mucho dinero, y
pagar a los abogados para que redacten la solicitud cuesta aún más que lo
que hay que abonar al presentarla. Normalmente la solicitud tarda algunos
años en ser estudiada, aun cuando las oficinas de patentes las examinan de
manera muy descuidada.
</p>
</li>

<li>
<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 dueño, 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>
</li>

<li>
<p>
El copyright cubre la copia. Si alguien escribe una novela que resulta ser
idéntica, palabra por palabra, a <cite>Lo que el viento se llevó</cite> y
puede demostrar que nunca antes había visto <cite>Lo que el viento se
llevó</cite>, eso le serviría para defenderse ante cualquier acusación de
infracción de copyright.
</p>
<p>
Una patente, por otro lado, es un monopolio absoluto sobre el uso de una
idea. Aun cuando alguien pueda probar que concibió la idea por sí mismo, no
serviría de nada si la idea ya ha sido patentada por otra persona.
</p>
</li>
</ul>

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


<h3 id="patent-system">El sistema de patentes</h3>

<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
podría conseguir con una patente, cómo sería si pudiéramos ir por la calle
con una patente en el bolsillo y, de vez en cuando, apuntar a alguien con
ella y decirle: «¡Dame su dinero!». Este sesgo tiene su razón de ser, y es
que la mayoría de la gente que le hablará acerca de este sistema de patentes
tiene intereses en él, y quiere que a usted le guste.
</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 entonces, ¿qué es lo primero que habría que hacer una vez que se
tiene una idea del tipo de programa que se va a escribir? Lo primero que
quizá se quiera hacer para lidiar con el sistema de patentes es descubrir
qué patentes pueden cubrir el programa que se quiere escribir. Pero esto es
imposible, porque algunas de las solicitudes de patente que están pendientes
son secretas. Pueden publicarse después de cierto tiempo, por ejemplo 18
meses. Pero eso es tiempo suficiente para escribir el programa e incluso
publicarlo, sin saber que va a haber una patente y que nos van a presentar
una demanda.
Esto no es una mera hipótesis. En 1984 se escribió el programa Compress, un
programa para la compresión de datos. En aquel momento no había ninguna
patente para el algoritmo de compresión LZW que utilizaba. Más tarde, en
1985, EE.&nbsp;UU. emitió una <a
href="https://patents.justia.com/patent/4558302">patente</a> sobre este
algoritmo, y durante los años siguientes los que distribuían el programa
Compress empezaron a recibir amenazas. No había forma de que el autor de
Compress se hubiera dado cuenta de que podía ser demandado. Todo lo que hizo
fue usar una idea que encontró en una revista, como siempre han hecho los
programadores. No se había dado cuenta de que ya no se podían usar sin
peligro las ideas que se encontraban en una revista.
</p>

<p>
Pero dejemos a un lado ese problema... La oficina de patentes publica las
patentes emitidas, de modo que se puede consultar toda su larga lista y ver
exactamente lo que dicen. Pero, por supuesto, no sería posible leer la lista
entera porque son demasiadas. En EE.&nbsp;UU. hay cientos de miles de
patentes de software.
</p>

<p>
Por ejemplo, había una patente de software, que quizá haya ya expirado,
sobre el «recálculo en orden natural» en las hojas de cálculo. Esto
significa básicamente que cuando se hace que ciertas celdas dependan de
otras todo se vuelve a calcular en función de aquello de lo que depende, de
modo que después de una operación de recálculo todo queda actualizado. Las
primeras hojas de cálculo hacían el recálculo de arriba hacia abajo, de
manera que si se hacía que una celda dependiera de otra situada más abajo, y
esto se repetía varias veces, había que recalcular todo varias veces para
que los nuevos valores se extendieran hacia arriba. Había que disponer los
elementos de manera que dependieran de las celdas superiores.
Entonces alguien pensó: «¿Por qué no realizar las operaciones de recálculo
de modo que cada elemento se recalcule en función del elemento del que
depende?  Haciéndolo en el orden correcto, todos se actualizarán». Este
algoritmo se conoce como clasificación topológica. La primera referencia a
él que he podido encontrar es de 1963. La patente cubría varias docenas de
maneras diferentes de implementar la clasificación topológica, pero no se
podría haber encontrado esta patente buscando «hoja de cálculo», porque no
se mencionaba esa expresión. Tampoco buscando «orden natural» o
«clasificación topológica» porque en la patente no aparecían estos
términos. De hecho, se describía como un «método de compilar fórmulas en
código objeto». Creo que la primera vez que la vi pensé que no era esa la
patente que buscaba.
</p>

<p>
Supongamos que disponemos de una lista de patentes y queremos saber qué nos
está prohibido. Al tratar de estudiar estas patentes descubrimos que es
demasiado complicado entenderlas, ya que están escritas en un lenguaje legal
muy enrevesado cuyo significado es difícil comprender. De hecho, lo que
dicen las oficinas de patentes a menudo no significa lo que parece
significar.                                       
</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 el idioma de las
patentes».&rdquo; <i class="aside">[risas]</i>
</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 <a
href="https://patents.justia.com/patent/4486857">patentes</a>. Cuando vio
Hypercard por primera vez, no pensó que tuviera nada que ver con sus
«invenciones». No se parecían similares. Pero cuando su abogado le dijo que
se podía interpretar que las patentes se aplicaban a una parte de Hypercard,
decidió atacar a Apple.
Cuando di una charla sobre esto en Stanford, él estaba entre el público y
dijo: «Eso <a
href="https://groups.csail.mit.edu/mac/classes/6.805/articles/int-prop/heckel-debunking.html">no
es verdad</a>, ¡yo simplemente no entendía el alcance de mi protección!». <i
class="aside">[risas]</i>&nbsp; Y yo le contesté: «Sí, eso es lo que yo
estaba diciendo». <i class="aside">[risas]</i>
</p>

<p>
De modo tal que, de hecho ,pasaremos mucho tiempo hablando con los abogados
para descifrar qué es lo que estas patentes nos prohíben hacer. Al final
dirán algo así: «Si haces esto, seguro que pierdes; si haces aquello, hay
serias posibilidades de que pierdas, y si de verdad quieres estar a salvo,
mantente al margen de esta área. Y, por cierto, el azar juega un importante
papel en el resultado de cualquier proceso judicial». <i
class="aside">[risas por lo bajo]</i>
</p>


<h3 id="dealing-with-patents">Cómo puede un desarrollador afrontar las patentes</h3>

<p>
Ahora que conocemos el terreno que pisamos para hacer negocios, <i
class="aside">[risas por lo bajo]</i> ¿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 class="compact">
  <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>

<dl>
<dt id="patent-avoiding">1. Evitar la patente</dt>
<dd>
<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.
</p>

<p>
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. <i class="aside">[risas]</i>&nbsp;  Descubrí que
era patentable porque ¡otra persona la patentó después! De hecho, habían
probado los tres enfoques.
Primero intentaron negociar con el dueño de la patente, pero resultó que
este no negociaba de buena fe. Luego se plantearon si podrían tener alguna
oportunidad de invalidar la patente. Finalmente decidieron eliminar esa
funcionalidad del programa. Se puede vivir sin ella. Si el procesador de
texto solo carece de esta funcionalidad, quizá la gente lo use igualmente,
pero si se empiezan a eliminar varias funcionalidades, al final la gente
pensará que el programa no es muy bueno y probablemente lo rechace. 
</p>

<p>
En ese caso se trataba de una patente bastante limitada sobre una
funcionalidad muy específica. Pero, ¿qué se puede hacer con relación a la <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. <i
class="aside">[risas]</i>
</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
y nunca llegaron a estar verdaderamente disponibles debido a las amenazas de
los propietarios de las patentes.
Posteriormente un programa escapó: <a
href="https://web.archive.org/web/20170315023711/http://www.pgpi.org/">PGP</a>,
que inicialmente se publicó como software libre. Al parecer, los dueños de
las patentes se proponían atacar, pero se dieron cuenta de que eso podría
crearles muy mala imagen. De modo que impusieron restricciones, limitándolo
solo a usos no comerciales, lo que significaba que no podría hacerse muy
popular. De esta manera, limitaron fuertemente el uso del cifrado mediante
clave pública durante una década o más. No había manera de evitar esa
patente. No se podía hacer nada más.
</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 aproximadamente el
doble de rápido. Es posible evitarla utilizando en el programa la FFT
ordinaria. Esa parte del programa tardará el doble de tiempo en
ejecutarse. Quizás eso no tenga gran importancia, quizá represente una
pequeña parte del tiempo de ejecución del programa, quizá ni siquiera se
note que es el doble de lento. O quizás el programa no funcione en absoluto
si le lleva el doble de tiempo hacer su tarea. Los efectos varían.
</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 <cite>New York Times</cite> 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. Quien quisiera comprimir datos podía
utilizar Gzip en lugar de Compress. Pero el mismo algoritmo patentado de
compresión LZW se utilizaba también en formatos de imagen tales como <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. De hecho, ¡durante diez años no pudimos hacerlo! Tan pronto como
empezaron a llegar amenazas judiciales por usar archivos GIF, se comenzó a
utilizar el algoritmo de Gzip para definir <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».&rdquo; <i class="aside">[risas]</i>
</p>

<p>
De hecho, la inercia en el uso del formato GIF era tan grande que no pudimos
lograr que la gente cambiara. En la práctica, el uso del formato GIF por
parte de la comunidad todavía sigue llevando a que los sitios web utilicen
ese formato, con el resultado de que son vulnerables a las amenazas.
</p>

<p>
En realidad la situación es todavía más grotesca, porque de hecho hay dos
patentes que cubren el algoritmo de compresión LZW. La oficina de patentes
ni siquiera se dio cuenta de que estaban concediendo dos patentes sobre la
misma cosa. No estaba al tanto, y hay un motivo para ello: hay que dedicar
una buena cantidad de tiempo al estudio de estas dos patentes para darse
cuenta de que en realidad cubren lo mismo.
</p>

<p>
Si fueran patentes sobre procesos químicos, sería mucho más fácil, porque se
podría verificar qué sustancias se están empleando, qué se introduce, qué se
obtiene, y qué acciones físicas se llevan a cabo. Sea cual sea su
descripción, se comprobaría en qué consisten esos procesos y se vería que
son similares.
</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; pues bien, 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 un estándar de facto. En tal
caso, si ese formato o protocolo se patenta, es un auténtico desastre. Hay
incluso estándares oficiales que están restringidos por patentes. El pasado
mes de septiembre se produjo un gran revuelo político cuando el <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 y volvieron a insistir en que cualquiera debería poder
implementar libremente cualquier patente, y en que cualquiera debería tener
la libertad de implementar los estándares. Es una victoria interesante. Creo
que ha sido la primera vez en que una organización de estándares ha tomado
esta decisión. Es habitual que los organismos de normalización estén
dispuestos a añadir a un estándar algo restringido por patentes, de modo que
a la gente no se le permita implementarlo libremente. Tenemos que dirigirnos
a otros organismos de normalización y reclamarles que cambien sus reglas.
</p>
</dd>

<dt id="patent-licensing">2. Obtener la licencia de la patente</dt>
<dd>
<p>
La segunda posibilidad consiste en conseguir una licencia para la patente,
en lugar de evitarla. Esta no es necesariamente una opción. El dueño de la
patente no tiene por qué ofrecernos una licencia, no está obligado a
hacerlo. Hace diez años, alguien cuyo pequeño negocio familiar consistía en
la fabricación de máquinas tragamonedas para los casinos (que ya entonces
usaban ordenadores) envió una carta a la Liga para la Libertad de
Programación en la que solicitaba ayuda porque había recibido una amenaza de
otra empresa que le decía:  «Nosotros tenemos las patentes. Usted no está
autorizado a fabricar estas cosas. Cierre su negocio».
</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. <i class="aside">[risas]</i>&nbsp; No se dan
cuenta de que en informática esa es la forma más obvia de generalizar
algo. Se ha hecho una vez y ahora se puede hacer cualquier número de veces,
se puede escribir una subrutina. Creen que si alguien hace algo dos veces en
vez de una sola vez, ha inventado algo. Eso debe de significar que se trata
de un genio, que nadie puede llevarle la contraria y que tiene derecho a dar
órdenes y restringir a todo el mundo. En cualquier caso, a esa persona no le
ofrecieron la licencia, tuvo que cerrar. Ni siquiera pudo afrontar el costo
de acudir a los tribunales. Yo diría que esa patente concreta era una idea
obvia. Es posible que un juez hubiera pensado lo mismo, pero nunca lo
sabremos porque esa persona no se pudo permitir ir a juicio.
</p>

<p>
No obstante, muchos dueños de patentes sí ofrecen licencias, pero a menudo
piden mucho dinero por ellas. La compañía que concedía licencias para la
patente sobre el recálculo en orden natural pedía un cinco por ciento de los
ingresos brutos por cada hoja de cálculo vendida en EE.&nbsp;UU. Según me
han dicho, ese era el precio reducido anterior al juicio. En caso de juicio,
si el dueño de la patente acababa ganando, exigiría más. Quizá uno pueda
permitirse ese cinco por ciento por la licencia de una patente, pero ¿y si
para desarrollar el programa hiciera falta la licencia de veinte patentes?
Pues en ese caso todo el dinero que se consiga se lo llevarán ellos. ¿Y si
hubiera que obtener la licencia de veintiuna patentes?
</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 una patente
es una muy buena solución. Es lo que les ocurre a las megacorporaciones
multinacionales. Como estas empresas poseen muchas patentes e intercambian
licencias entre ellas, se libran de la mayor parte del daño que provoca el
sistema de patentes y disfrutan de todas sus ventajas. IBM publicó un <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 (creo que hoy en día el
número es mayor). Estos eran, en primer lugar, los ingresos por regalías, y
en segundo lugar, el acceso a las patentes de otros. Decían que el segundo
beneficio era un orden de magnitud  mayor que el primero. De tal modo que el
beneficio obtenido por IBM al permitírsele utilizar las ideas patentadas por
otros multiplicaba por diez el beneficio directo que obtenía por ofrecer
licencias.
</p>

<p>
¿Qué significa esto en realidad? ¿Cuál es el beneficio de IBM al tener
acceso a las patentes de otros? Esencialmente es el beneficio de verse libre
de los problemas que el sistema de patentes puede ocasionar. El sistema de
patentes es como una lotería. Con una patente determinada puede no ocurrir
nada, o puede suponer un grande beneficio para su dueño y un desastre para
todos los demás. Pero IBM es una empresa tan grande que le compensa. Pueden
hacer una estimación general de las ventajas y desventajas del sistema de
patentes.
Para ellos, los problemas podrían haber sido diez veces mayores que las
ventajas. Digo «podrían haber sido» porque mediante el intercambio de
licencias IBM evita esos problemas. Los problemas son solo potenciales, en
realidad no les afectan. Pero cuando evalúan los beneficios de evitarlos, su
estimación es que de esa manera multiplican por diez el valor del dinero que
obtienen por sus patentes.
</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 cualquier cosa. Imaginemos que ha pasado años de privaciones en
su ático diseñando algún nuevo y maravilloso prototipo y ahora quiere
fabricarlo. ¿No es una vergüenza que las grandes empresas entren en
competición con él, se queden con todo su negocio y él «se muera de hambre»?
Debo señalar que aquellos que trabajan en sectores de alta tecnología
normalmente no lo hacen por su cuenta, que las ideas no salen de la nada,
sino que se apoyan en las ideas de otros, y que hoy por hoy esas personas
tienen muchas oportunidades de conseguir un trabajo en caso de que lo
necesiten. Así que este cuento, la posibilidad de que una idea brillante sea
el fruto de esta brillante persona que trabaja sola, no es realista, al
igual que la idea de que se encuentre en riesgo de pasar hambre. Pero sí es
concebible que alguien tenga una idea que junto con otras cien o doscientas
ideas pueda servir de base para la fabricación de algún tipo de producto, y
que las grandes compañías puedan querer competir con esa persona.
Veamos pues qué sucedería si esa persona intentara usar una patente para
impedirlo. Dirá: «Ah, no, IBM, no puedes competir conmigo. Tengo esta
patente». E IBM responderá: «Veamos. Echemos un vistazo a tu
producto. Mmm. .. Yo tengo esta patente, y esta otra, y esta otra, y esta
otra, y esta otra, y esta otra, que son infringidas por algunas partes de tu
producto. Si crees que puedes luchar contra todas ellas en los tribunales,
encontraré unas cuantas más. Así que, ¿por qué no intercambias licencias
conmigo?». Y entonces el brillante pequeño inventor <i
class="aside">[risas]</i> 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, es por
eso quieren que existan patentes de software, son las únicas que se
beneficiarán con ellas. Pero si se es realmente un pequeño inventor o se
trabaja para una pequeña empresa, esa pequeña empresa no podrá hacerlo. Lo
intentan, pero el problema es que no pueden obtener una cantidad suficiente
de patentes como para hacerlo. Toda patente apunta en una dirección
determinada. De modo que si una pequeña empresa tiene patentes que apuntan
aquí, ahí y allí <i class="aside">[señalando hacia la izquierda]</i>, y
alguien llega desde allá <i class="aside">[señalando hacia la derecha]</i> y
le apunta con una patente diciendo: «Dame tu dinero», se ve indefensa porque
posee patentes que apuntan allí o cerca de allí <i class="aside">[señalando
hacia la izquierda]</i>, pero no allá <i class="aside">[señalando hacia la
derecha]</i>.
 
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. <i
class="aside">[risas]</i>&nbsp;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, <a
href="https://www.nytimes.com/1990/01/14/business/a-white-knight-draws-cries-of-patent-blackmail.html">
Refac</a>, 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>
</dd>

<dt id="patent-overturning">3. Revocar la patente en los tribunales</dt>
<dd>
<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. Claro que cuando la
oficina de patentes entra en juego y comienza a interpretar lo que es nuevo
y no obvio,  «nuevo» viene a significar «no lo tenemos en nuestros archivos»
y «no obvio» suele significar «no obvio para alguien con un cociente
intelectual de 50».
</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 fuera 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 dueños de las patentes,
sin excepción, como brillantes inventores. Por tanto, no podemos cuestionar
su autoridad para decidir sobre lo que podemos o no podemos hacer.
</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.
</p>

<p>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.
Lo llamé «hipertexto del pobre», dado que tenía que implementarlo en el
contexto de TECO. No tenía tanta capacidad como el hipertexto de Englebart,
pero al menos era útil para hojear documentación, que era todo lo que
pretendía. Y en cuanto a que hubiera acceso telefónico al sistema, bueno, lo
había, pero no se me ocurrió que lo uno tuviera alguna relación particular
con lo otro. No iba a publicar un artículo para decir: «¡Oh!, he
implementado el hipertexto del pobre, y sabéis qué, ¡también hay acceso
telefónico en el ordenador!». <i class="aside">[risas]</i>&nbsp; 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.
</p>

<p>
Así pues, esta es una opción, la posibilidad de acudir a los tribunales para
revocar una patente. Pero debido a los gastos que supone, normalmente ni se
plantea, aun cuando se puedan encontrar pruebas sólidas de la existencia de
una técnica anterior que deberían bastar para revocar la patente. En
consecuencia, una patente inválida, que teóricamente no debería existir
(aunque en realidad existen muchísimas de ellas) es un arma peligrosa. Si
alguien nos ataca con una patente inválida, puede causarnos serios
problemas. Podemos tratar de disuadirlo mostrándole que la técnica ya
existía. Quizá de ese modo se asuste, o puede que piense: «Estás fingiendo,
sabemos que en realidad no puedes ir a juicio, no te lo puedes permitir, así
que te demandaremos de todos modos».
</p>
</dd>
</dl>

<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 estas opciones, enseguida
aparece una nueva patente, y luego otra, y otra. Es como cruzar un campo de
minas. A cada paso que se da, a cada decisión de diseño que se toma, es
probable que no nos topemos con una patente, de modo que es posible dar unos
cuantos pasos sin que se produzca una explosión. Pero la probabilidad de
cruzar todo el campo de minas y llegar a desarrollar el programa que se
quiere desarrollar sin toparse con ninguna patente es tanto menor cuanto
mayor es el programa.
</p>


<h3 id="software-specificity">Características del área de la programación</h3>

<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í, 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?». <i>[risas]</i> 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 dueño 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
<em>ese</em> producto. En algunas áreas esto se aproxima a la verdad, en
otras está muy lejos de ser cierto. El software se encuentra en el extremo
opuesto. Esto se debe a que en el área de la informática los paquetes de
software suelen ser muy grandes, utilizan muchas ideas diferentes en nuevas
combinaciones. Si el programa es nuevo, y no simplemente copiado,
probablemente utilice una combinación diferente de ideas, combinadas, por
supuesto, con código nuevo, porque no es posible hacer que esas ideas
funcionen mágicamente con solo pronunciar sus nombres. Hay que
implementarlas todas.
Hay que implementarlas todas en esa combinación. La consecuencia es que
incluso cuando se escribe un programa se utiliza gran cantidad de ideas
diferentes, cada una de las cuales puede estar patentada por alguien. Un par
de ellas podría estar patentada como combinación por alguien. Puede haber
varias maneras diferentes de describir una idea, que puede estar patentada
por distintas personas. Así que posiblemente haya miles de cosas, miles de
aspectos vulnerables en el programa, que podrían estar ya patentados por
alguien. Por eso las patentes de software suelen obstaculizar el progreso
del software, la tarea de desarrollar software.
</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 hacernos creer que el
sistema de patentes promueve el progreso y que eso compensa cualquier coste
posible. En realidad no hay razones para creer que promueva el
progreso. Ahora tenemos un modelo que demuestra claramente el modo en que
las patentes <em>pueden</em> 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. <i
class="aside">[risas]</i>&nbsp; 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 demasiadas veces. Cuando hago referencia a la variable tampoco tengo
que preocuparme de su capacitancia, ni de si habrá tiempo suficiente para
que se cargue su valor. Cuando escribo el programa no tengo que preocuparme
de cómo ensamblaré físicamente cada copia ni de si podré arreglármelas para
insertar la declaración <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.<i class="aside">[risas]</i>
</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! <i class="aside">[risas]</i>&nbsp;Y es lo
que hacemos. Hacemos sistemas de software que son mucho mayores que los
sistemas físicos con respecto al número de partes que los componen. Un
sistema físico cuyo diseño contiene un millón de piezas diferentes es un
megaproyecto. Un programa informático cuyo diseño contiene un millón de
piezas puede tener unas 300.000 líneas, unas pocas personas pueden
escribirlo en un par de años. No sería un programa gigantesco. GNU Emacs
contiene ya varios millones de piezas, creo, porque tiene un millón de
líneas de código. Fue un proyecto realizado prácticamente sin financiación,
realizado en su mayor parte por gente en su tiempo libre.
</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 <code>copy</code>. La misma orden
<code>copy</code> 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 <em>hacer</em> este
producto. Hay una tremenda simplificación y una tremenda reducción de costes
en el diseño.
La consecuencia, digamos para una compañía automovilística que se gastará 50
millones de dólares en levantar una planta para fabricar un nuevo modelo, es
que puede contratar a unos cuantos abogados para que se ocupen de las
negociaciones relativas a las patentes. Podrían incluso afrontar un proceso
judicial si quisieran. Diseñar un programa de la misma complejidad puede
costar 50.000 o 100.000 dólares. En comparación, el coste de lidiar con el
sistema de patentes es devastador. Concebir un programa de la misma
complejidad que el diseño mecánico de un coche llevaría probablemente un mes
de trabajo. ¿Cuántas partes tiene un coche... uno que no contenga ningún
ordenador?[<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. El diseño es muchísimo más sencillo, y debido a ello
habitualmente hacemos sistemas que son muchísimo más grandes, y eso con tan
solo un puñado de personas. Entonces el resultado es que el sistema de
patentes, en lugar de ser del tipo «un producto, una patente», es un sistema
en el que un producto comprende multitud de ideas que podrían estar ya
patentadas.
</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 lograr que su sinfonía no
infringiera ninguna patente sería más complicado que escribir una buena
sinfonía.
Si protestaran por ello, los dueños de las patentes dirían, «Ah, Beethoven,
reniegas solo porque no tienes ideas propias. Lo único que pretendes es
apropiarte de nuestras invenciones». Lo cierto es que Beethoven concibió
multitud de ideas musicales nuevas, pero tuvo que utilizar muchas ideas
musicales ya existentes a fin de componer música reconocible, a fin de
componer música que pudiera gustar a los oyentes, música que estos pudieran
reconocer como tal. Nadie es tan brillante como para reinventar la música y
componer algo que la gente quiera escuchar. <a
href="https://en.wikipedia.org/wiki/Pierre_Boulez">Pierre Boulez</a> dijo
que intentaría hacerlo, ¿pero quién escucha a Pierre Boulez? <i
class="aside">[risas]</i>
</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 creo que
encontrarán cientos de funcionalidades diferentes. Si se desarrolla un nuevo
procesador de textos de calidad e innovador, eso quiere decir que contendrá
algunas ideas nuevas, pero ha de contener también cientos de viejas
ideas. Si no se nos permite utilizarlas, no podremos hacer un procesador de
textos innovador.
</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, queremos que sea bueno. Tendremos algunas ideas y
encontraremos la manera de utilizar algunas de ellas. Lo que solía suceder,
puesto que yo trabajé en el campo del software antes de que hubiera patentes
de software, es que la mayoría de los desarrolladores publicaban cualquier
nueva idea que consideraran relevante, que pensaran que podía reportarles
reconocimiento o consideración.
No publicaban las ideas menores o insignificantes porque sería tonto
hacerlo. Ahora se supone que el sistema de patentes estimula la divulgación
de ideas. De hecho en los viejos tiempos nadie mantenía las ideas en
secreto. Mantenían en secreto el código, es cierto. Al fin y al cabo, el
código representaba el grueso del trabajo. Generalmente mantenían en secreto
el código y publicaban las ideas. De manera que los empleados obtenían
reconocimiento y se sentían bien, porque se sabe, se les permitía publicar
artículos. Tras la aparición de las patentes de software, seguían
manteniendo el código en secreto y patentaban las ideas, así que lo cierto
es que no se ha fomentado la divulgación de ninguna manera. Las mismas cosas
que se mantenían en secreto antes se siguen manteniendo en secreto ahora,
pero las ideas que solían publicarse y podíamos utilizar, ahora son
probablemente patentadas y quedan fuera de alcance durante veinte años.
</p>


<h3 id="software-patent-policies">Cómo abordar el problema de las patentes de software en las políticas
públicas</h3>

<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. En realidad estas
patentes no están oficialmente identificadas como patentes de software. Yo
hablo de patentes de software, pero ¿qué quiero decir en realidad? Me
refiero a patentes que podrían aplicarse al software, patentes que podrían
hacer que nos demandaran por escribir software.

La oficina de patentes no distingue entre patentes de software y otro tipo
de patentes. De manera que, de hecho, cabe la posibilidad de que cualquier
patente podría hacer que nos demandaran por escribir software si se pudiera
aplicar al mismo. Así que, en EE.&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 ejecuta en un ordenador genérico y
que en sí misma no infringe la patente no está cubierta por ninguna patente
y no puede ser objeto de denuncia. Este es el otro tipo de solución.
</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 político. De hecho, nadie lo advirtió. El mundo del software,
en su mayor parte, ni siquiera se dio cuenta. En 1981 hubo una decisión del
Tribunal Supremo relativa a una patente sobre un proceso de curado del
caucho. La sentencia decía que el hecho de que el aparato incluyera un
ordenador y un programa como parte del proceso para curar el caucho no lo
inhabilitaba para ser patentado.
Al año siguiente, un tribunal de apelación especializado en los casos de
patentes invirtió los términos. Dijeron que el hecho de que contenga un
ordenador y un programa lo hace patentable. Cualquier cosa contenga un
ordenador y un programa es patentable. Así es cómo EE.&nbsp;UU. comenzó a
introducir patentes sobre procedimientos industriales, porque los
procedimientos industriales se realizan en un ordenador, y eso los hacía
patentables. Fue así que se tomó esa decisión, y creo que la patente sobre
el cálculo en orden natural fue una de las primeras, o incluso puede que
fuera la primera.
</p>

<p>
Pero durante los años ochenta no sabíamos prácticamente nada de esto. 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 si al final ganaran. De modo que también los
usuarios pueden ser denunciados, bien como forma de atacar a un
desarrollador, o simplemente como un medio para sacarles dinero o provocar
confusión.
</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="#f2">2</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/government/collections/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, <i class="aside">[risas]</i> 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.  El resultado que se obtiene ejecutando algún
programa se puede describir como un resultado físico. ¿En qué se diferencia
este resultado físico de cualquier otro? En que es el resultado de esa
computación. La consecuencia es que la Oficina de Patentes del Reino Unido
está planteando una propuesta que parece conducir a la resolución del
problema y que en realidad da carta blanca para patentar casi todo.
</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>, <i class="aside">[risas]</i> al que hay que
poner freno. <i class="aside">[risas]</i>&nbsp;Es necesario poner límites a
sus actividades e impedirle crear nuevas formas de poder.
</p>

<p>
Las patentes de software atrapan a todos los desarrolladores de software y a
todos los usuarios de ordenadores en una nueva forma de burocracia. Si las
empresas que utilizan ordenadores se dieran cuenta de la cantidad de
problemas que esto puede ocasionarles se pondrían en pie de guerra y estoy
seguro de que podrían ponerle fin. A las empresas no les gustan las trabas
burocráticas.
</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="#f3">3</a>] Pero
en ciertos casos, cuando no sirve más que para crear monopolios artificiales
para que alguien interfiera en el desarrollo del software y exprima a los
desarrolladores y usuarios, entonces hemos de rechazarla.
</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. <i
class="aside">[aplausos]</i>
</p>

<div class="column-limit"></div>

<h3 id="footnotes" 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">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="f3">Para evitar que se extienda la fiebre aftosa.</li>
</ol>

<hr class="no-display" />
<div class="edu-note c"><p id="fsfs">Esta charla está publicada 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, 2023, 2024 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: 2024/01/01 05:25:36 $

<!-- timestamp end -->
</p>
</div>
</div>
<!-- for class="inner", starts in the banner include -->
</body>
</html>
savannah-hackers-public@gnu.org	ViewVC Help
Powered by ViewVC 1.1.26