1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
|
<!--#set var="ENGLISH_PAGE" value="/philosophy/limit-patent-effect.en.html" -->
<!--#include virtual="/server/header.es.html" -->
<!-- Parent-Version: 1.79 -->
<!-- This file is automatically generated by GNUnited Nations! -->
<title>Cómo proteger el software frente a las patentes - Proyecto GNU - Free
Software Foundation</title>
<!--#include virtual="/philosophy/po/limit-patent-effect.translist" -->
<!--#include virtual="/server/banner.es.html" -->
<h2>Cómo proteger el software frente a las patentes</h2>
<p>por <a href="http://www.stallman.org/"><strong>Richard Stallman</strong></a></p>
<p><em>Una versión de este artículo se publicó inicialmente en <a
href="http://www.wired.com/opinion/2012/11/richard-stallman-software-patents/"><cite>Wired</cite></a>
en noviembre de 2012.</em></p>
<p>Las patentes son una amenaza para todo desarrollador de software, y las
guerras de patentes que durante tanto tiempo hemos temido ya han
estallado. Los desarrolladores y los usuarios de software, que en nuestra
sociedad constituyen la mayoría, necesitan que el software esté libre de
patentes.</p>
<p>A las patentes que nos amenazan, a menudo se las llama «patentes de
software», pero este término es engañoso, pues tales patentes no se refieren
a programas concretos, sino que cada patente describe alguna idea práctica y
dice que a cualquiera que aplique esa idea se lo puede demandar. Por eso
resulta más claro llamarlas «patentes de ideas computacionales».</p>
<p>El sistema de patentes estadounidense no califica las patentes de manera que
se pueda decir que esta es una «patente de software» y aquella no lo es. Son
los desarrolladores de software los que distinguen entre las patentes que
suponen una amenaza para ellos (las que cubren ideas que pueden
implementarse en software) y las demás. Por ejemplo, si la idea patentada es
el diseño de una estructura física o una reacción química, ningún programa
puede implementar esa idea, por lo que esa patente no representa ninguna
amenaza para el área del software. Pero si la idea patentada es un cómputo,
los desarrolladores y usuarios de software están en el punto de mira de esa
patente.</p>
<p>Esto no quiere decir que las patentes de ideas computacionales prohíben solo
software. Esas ideas también pueden implementarse en hardware, y así ha sido
en muchos casos. La patente normalmente cubre las implementaciones de la
idea en hardware <em>y</em> en software.</p>
<h3>El problema particular del software</h3>
<p>Las patentes sobre las ideas computacionales ocasionan un problema
particular en el área del software, donde es fácil implementar miles de
ideas a la vez en un programa. Si el diez por ciento están patentadas, el
programa queda bajo la amenaza de cientos de patentes.</p>
<p>Cuando Dan Ravicher, de la <cite>Public Patent Foundation</cite>, estudió en
2004 un programa grande (Linux, que es el núcleo del sistema operativo <a
href="/gnu/gnu-linux-faq.html">GNU/Linux</a>), encontró 283 patentes
estadounidenses que parecían cubrir ideas computacionales implementadas en
el código fuente de ese programa. Ese mismo año, una revista estimó que
Linux representaba el 0,25% de todo el sistema GNU/Linux. Multiplicando 300
por 400, el orden de magnitud del resultado indica que el sistema en su
conjunto se encontraba <em>amenazado por alrededor de cien mil
patentes</em>.</p>
<p>Si se eliminara la mitad de esas patentes por «mala calidad» (es decir, por
errores del sistema de patentes), eso no cambiaría mucho las cosas. Sean
cien mil o cincuenta mil, el desastre es el mismo. Por eso es un error
reducir nuestra crítica del sistema de patentes a los «<cite>trolls</cite>»
de patentes o a las patentes de «mala calidad». Apple, que no es un «troll»
según la definición común del término, en
la actualidad es la empresa más agresiva cuando se sirve de sus patentes
para atacar. No sé si las patentes de Apple son de «buena calidad», pero
cuanto mejor sea su «calidad», más peligrosas serán.</p>
<p>Hemos de resolver todo el problema, no solo una parte.</p>
<p>Para corregir este problema por la vía legislativa generalmente se sugiere
cambiar los criterios para la concesión de patentes. Por ejemplo, prohibir
la emisión de patentes sobre prácticas computacionales y sistemas para
aplicarlas. Este planteamiento tiene dos inconvenientes.</p>
<p>En primer lugar, los abogados especialistas en patentes reformulan
hábilmente las patentes para que encajen en cualquiera de las normas que
pudieran resultar pertinentes, y transforman en un requisito meramente
formal todo intento de limitar la patente de manera sustancial. Por ejemplo,
muchas patentes estadounidenses sobre ideas computacionales describen un
sistema que incluye una unidad de procesamiento aritmético, un secuenciador
de instrucciones, una memoria y unos controles para llevar a cabo un cálculo
concreto. Esta es una manera peculiar de describir un ordenador que ejecuta
un programa para realizar alguna operación. Se formuló de esta manera para
hacer que la solicitud de la patente satisficiera los criterios que durante
algún tiempo se creyó que mantenía el sistema de patentes estadounidense.</p>
<p>En segundo lugar, en EE. UU. existen ya miles de patentes sobre ideas
computacionales, y cambiar los criterios para evitar que se sigan emitiendo
no nos libraría de las ya existentes. Tendríamos que esperar casi veinte
años para que, con la expiración de dichas patentes, se solucionara el
problema. Podríamos imaginar que se legislara la abolición de las patentes
en vigor, pero eso probablemente sea inconstitucional. (El Tribunal Supremo
ha insistido perversamente en que el Congreso puede ampliar los privilegios
privados a costa de los derechos colectivos, pero que no puede hacerse en el
sentido contrario.)</p>
<h3>Otra forma de abordar el problema: limitar el efecto, no la patentabilidad</h3>
<p>Lo que yo sugiero es cambiar el <em>efecto</em> de las patentes. Debemos
legislar para que el desarrollo, la distribución y la ejecución de un
programa no constituyan infracción de patentes. Esta solución tiene varias
ventajas:</p>
<ul>
<li>No exige que se clasifiquen las patentes o solicitudes de patentes como
«software» o «no software».</li>
<li>Proporciona a desarrolladores y usuarios protección frente a las patentes
sobre ideas computacionales actuales y futuras.</li>
<li>Los abogados especialistas en patentes no pueden evitar el efecto que se
pretende redactando las solicitudes de manera diferente.</li>
</ul>
<p>Esta solución no invalida por completo las patentes sobre ideas
computacionales existentes, pues seguirían siendo aplicables a las
implementaciones que utilicen hardware con un propósito específico. Hace
unos años se aprobó en EE. UU. una ley que protegía a los cirujanos
frente a pleitos sobre patentes, de modo que incluso si un procedimiento
quirúrgico está patentado, los cirujanos están a salvo.</p>
<p>Los desarrolladores y usuarios de software necesitan protección frente a las
patentes. Esta es la única solución legislativa que proporcionaría
protección completa para todos. Entonces podríamos volver a competir y
cooperar sin miedo a que nadie echara por tierra nuestro trabajo.</p>
<p><em>Véase también: <a href="/philosophy/patent-reform-is-not-enough.html">La
reforma de las patentes no es suficiente</a></em></p>
<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">
<div class="unprintable">
<p>Envíe sus consultas acerca de la FSF y GNU a <a
href="mailto:gnu@gnu.org"><gnu@gnu.org></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"><webmasters@gnu.org></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">
<web-translators@gnu.org></a>.</p>
<p>For information on coordinating and submitting 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"><web-translators@gnu.org></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 © 2012, 2013, 2015, 2016 Free Software Foundation, Inc.</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>Traducción: Javier Fdez. Retenaga, 2020.</strong> Revisión: Equipo
de traductores al español de GNU.</div>
<p class="unprintable"><!-- timestamp start -->
Última actualización:
$Date: 2020/06/02 09:00:53 $
<!-- timestamp end -->
</p>
</div>
</div>
</body>
</html>
|
