Artículos cortos…
Esta página contiene artículos cortos que
he escrito en un momento u otro. Como autor, no quiero gastar
tiempo
tratando de que alguien los publique. Ese sería el trabajo que
deberían realizar las agencias de publicación, si
no estuvieran en nómina
de los monopolios del copyright.
Por lo tanto, la publicación o distribución de mis artículos es
libre bajo los términos de la versión 2 o posterior
de la Licencia General de uso Público de GNU
(GPL).
Debe tenerse en cuenta que estos artículos no son
en forma alguna traducciones de los que he escrito en
francés a menudo sobre temas completamente
distintos.
Indice de materias
(bueno, de acuerdo, en esta ocasión sólo
hay un artículo)
Sobre los artículos de Eric S.
Raymond's (escrito el
23-mayo-1998).
Notas sobre "La catedral y el bazar" y otros escritos
de Eric S.
Raymond…
Lo que sigue son unas pequeñas anotaciones
sobre defectos que se han deslizado en los, por lo demás
excelentes y justamente bien conocidos, artículos
de Eric
S. Raymond . Se las envié a
él en primer lugar, pero decidió, y estaba en su
pleno derecho, no tenerlas en cuenta. Dado que creo que esto hace
que sus artículos difundan unos cuantos conceptos
notablemente incorrectos como parásitos de las importantes
ideas que en ellos se exponen, me creo obligado a publicarlas
aquí; quizá logre al menos de esta forma que ESR
incluya los enlaces correspondientes a ellas en su página
(escrito entre el 23 y 25 de mayo de 1998).
Eric S. Raymond, un respetado "hacker" (en el
sentido
del término), se ha hecho famoso como "predicador del
software
abierto", desde que escribió su influyente artículo
"La
catedral y el bazar", que cuenta ya con algunas
secuelas (por el momento sólo "Colonizando
la Noosfera").
Leí "La
catedral y el bazar", poco después de que
se publicara, antes de que se hiciera tan famoso como lo es en
este momento, y se modificara por razones de mercado al
sustituir la expresión "software
libre" por "software abierto". Es un gran
artículo, no pretendo negarlo; de hecho, no puedo sino
estar fervientemente de acuerdo con la mayor parte de lo que en
él se dice, pues contiene por cierto hallazgos importantes
sobre la dinámica del desarrollo del
software. Hallazgos que son, como creo que
Jonathan Eunice hace notar si bien de forma poco
apropiada, casi totalmente (aunque no por completo)
independientes de toda consideración sobre si el software
es libre o apropiable. I como teorizador sobre el software
libre, mis observaciones tratarán sobre la no tan
escasa diferencia entre ese "casi totalmente" y aquel "no por
completo".
Mi primera observación (poco importante) se refiere a
la siguiente sugerencia que aparece al final del artículo
de la catedral:
Quizá al final la cultura del
software abierto triunfe no porque la colaboración sea
moralmente
"buena" y la posesión avara del software "mala"
(suponiendo que creas esto último, algo que ni yo ni
Linus hacemos), sino simplemente porque el mundo comercial no
puede ganar una carrera de
armamentos frente a comunidades de software abierto capaces de
movilizar cantidades de tiempo de personal
cualificado algunos órdenes de magnitud superiores a la
hora de resolver un problema.
Si bien estoy de acuerdo con la última parte de
la frase, no lo estoy con la primera. ¿Qué mejor
argumento moral que el software libre esté
intrínsecamente mejor dotado para producir a largo plazo
software fiable y de buena calidad?. Desde
luego, no es un argumento metafísico; pero no hay
razón para basar la moral en
dogmas de este tipo; al contrario, la ética
resulta más adecuada si las consideraciones a manejar
provienen de la vida real.
En un correo privado, Eric me explicó que, si
bien estaba de acuerdo con mi observación, no
modificaría su artículo pues temía confundir
a los lectores con nociones sobre si los aspectos éticos
eran consideraciones a-priori o a-posteriori, que están
fuera del contexto del artículo y requerirían una
explicación demasiado larga para resultar inteligibles.
Bueno, tal consideración no es al menos ajena a su
conclusión, por lo que, si deseaba ajustarse de forma tan
precisa al contexto, también hubiera podido eliminar
directamente la conclusión. Y, cuando menos, una nota al
pie con un enlace a alguna otra página de otro tipo
hubiera podido contribuir a poner las cosas en claro para todo el
mundo. También hubiera podido buscar una
formulación más precisa o neutral, sin mayor
explicación. Por miedo a "confundir" a los lectores con
una "excesiva" precisión, Eric contribuye a un aumento de
la confusión ya existente sobre asuntos éticos de
importancia.
En la secuela al artículo de la catedral y el
bazar, "Colonizando
la Noosfera", otro artículo muy
interesante, Eric introduce una confusión más
esencial que está en el origen de todas las
contradicciones aparentes que el artículo intenta
despejar, en concreto,
pensar que los programas son de
alguna forma apropiables.
Si debiera ubicarme en uno de los modelos de
ideologías de hacker descritos por Eric, probablemente me
situaría en el tipo integrista anticomercial. Pero creo
que su división de los tipos de hacker es parcial, en
parte como consecuencia de un intento consciente de provocar
mediante el humor, y en parte como resultado de la
propagación de malentendidos habituales. En primer lugar
"anti comercial" es simplemente un concepto
incorrecto: los hackers del tipo
de la FSF no están en absoluto en contra de hacer negocio;
apoyan ardientemente la idea de que los servicios de
software deben ser remunerados, y que debe haber un mercado libre
para tales servicios; con lo que no están de acuerdo es
con la idea de que el software pueda ser poseído y los
malos hábitos asociados a las licencias
comerciales.
Finalmente, "integrista" es un término obviamente parcial;
yo más bien diría que alguna gente tiene más
o menos tendencia a realizar compromisos si se presenta la
oportunidad de apropiarse ellos mismos de un software dado, y de
promover o dificultar tales compromisos en los otros, dos
aspectos por lo demás independientes. El extremismo y el
fanatismo no son atributos exclusivos de los puritanos del
software libre que rechazan cualquier compromiso, sino que pueden
encontrarse entre gente de cualquier opinión: no
están unidos a una opinión particular, sino al
hecho de que las opiniones se mantengan de forma dogmática
o no.
En cuanto al pragmatismo,
no es ciertamente un atributo que deba ser otorgado a nadie en
virtud de su disposición a aceptar compromisos. Aceptar
compromisos degradantes a largo plazo se llama "realpolitik", y
ha demostrado ser una estrategia
inútil frente a enemigos descaradamente inmorales (vease
la historia del
facismo o el comunismo),
mientras que el rigor se ha manifestado a menudo como una
actitud
ganadora (por ejemplo, frente a la segregación en
Sudáfrica). No estoy sugiriendo en absoluto que no deba
realizarse jamás compromiso alguno, sino que deben tenerse
en cuenta sus implicaciones a largo plazo como una parte
más de los costes generados al aceptarlo, y no debe caerse
en la ceguera de considerar tan sólo sus beneficios a
corto plazo. El artículo de la catedral, manteniendo la
observación anterior, es la mejor demostración de
que el modelo de
desarrollo de software libre del GNU constituye de hecho la
aproximación más pragmática posible (otra
confirmación de que GNU es el modelo más adecuado
es la constante división observable en los proyectos regidos
por licencias del tipo BSD, tales como las variantes de BSD
Unix o el
proyecto
X).
El punto fundamental en que Eric se equivoca consiste en
que, por miedo a asustar a unos accionistas poco educados, parece
avergonzarse de la idea de que el software no es apropiable y
trata desesperadamente de evitarla hasta el punto de no
mencionarla como el axioma central de las teorías
sobre software libre de la mayor parte de la gente (en aquellos
casos en que la tienen, por supuesto).
Esta idea surge de forma natural a partir de las mismas
fuentes de
liberalismo
clásico y antropología que Eric invoca como
inspiración de su artículo: la propiedad se
justifica sobre recursos
físicos escasos como la única forma de controlar de
manera fiable uno de tales recursos sin introducir luchas
permanentes entre la gente; pero el software, al ser un tipo
particular de ideas, no tiene similitud alguna con los recursos:
un número arbitrario de personas puede tener una idea sin
privar a nadie de tenerla a la vez, y es la prohibición de
actuar de acuerdo con una idea dada (con una copia mental
particular de la misma) la que introduce los conflictos y
la falta de libertad.
Esta justificación de que las ideas, la información, y el software no son
apropiables apoya la aparición de un mercado en los
servicios comerciales que tratan con ideas, información o
software en tanto en cuanto tales servicios implican la
utilización de recursos físicos. Tales servicios
incluyen la búsqueda (no el hallazgo) de nueva
información, la caza de errores, la mejora y puesta al
día de la información existente, el soporte
técnico, los cursos de formación que ayudan a
manipular la información entregada, la entrega de harware
físico o de medios de
soporte de tal información, la garantía de
disponibilidad, relevancia, y/o precisión de la
información, asegurar frente a los riesgos
relacionados con su uso, etc. No puedo sino incluir una
referencia a mi propia página WEB
(en francés) sobre software libre, y mi "Manifiesto de la
información libre" (que se ha traducido parcialmente al
inglés)
para aquellos a los que interese una discusión más
profunda de tales temas.
Con tales conceptos en mente se desvanecen todas las
dificultades con que topa Eric en su artículo sobre la
colonización.
En primer lugar, las divergencias entre las actitudes
frente al software libre no son contradicciones, sino meras
diferencias; cada cual tiene su actitud particular, que no
necesariamente contradice la de ningún otro; del mismo
modo en que cada programador escribe programas (es de suponer)
diferentes a los de cualquier otro sin contradecirlos. Cuando se
considera que el desarrollo y el uso del software libre requiere
recursos
humanos escasos en cuanto a tiempo de desarrolladores y
usuarios, se puede caer en la tentación de considerar cada
diferencia como una contradicción potencial. Sin embargo,
esto no hace las diferencias relativas al software libre
más contradictorias entre sí de lo que lo son las
que aparecen con el software propietario; de hecho, mucho menos:
el software libre no puede sino hacer aparecer las
incompatibilidades esenciales entre programas que intentan captar
los mismos recursos (de computación, humanos); mientras que el
software propietario introduce también oposiciones entre
monopolios que intentan excluirse mutuamente con barreras
artificiales consistentes en costes de utilización y
desarrollo y la asuencia de las fuentes del programa.
En segundo lugar, Eric ve una contradicción entre
la teórica proclama de libertad en las licencias del
software libre, que permite que todo el mundo pueda modificar
cualquier cosa, y la práctica gragaria por la cual los
hackers siguen
reglas estrictas de conducta al
compartir el código.
Pero no constituye mayor contradicción que el hecho de que
en aquellos países en los que existe libertad de
asociación los individuos no crean docenas de asociaciones
con ellos como únicos miembros. La libertad es un asunto
de derechos civiles.
¡El derecho a hacer algo dentro de unos límites
dados no significa que todas las cosas que puedan realizarse
dentro de ellos se lleve a la práctica!. Lo cual quiere
decir que la gente ya tiene bastantes dificultades al tratar con
las limitaciones naturales del mundo físico y social, y no
desea sufrir la molestia adicional de artificiosas reglas humanas
más allá de lo que definen los límites
mutuos de libertad.
Los tabús que Eric señala pueden por tanto
explicarse en función de
las limitaciones humanas que afectan a las actividades
relacionadas con la programación, de las que en su mayor parte
ya hemos hablado: mientras los programas no son apropiables y
nunca lo serán, el desarrollo de los programas, al igual
que el trabajo
relacionado con el software, como su nombre indica, implica un
gasto de recursos, y aquellos hackers que vean sobrevivir a sus
trabajos serán los que optimicen la utilización de
recursos escasos.
La programación implica en primer lugar conocimiento y
comprensión de los fines y medios de los programas, que
pueden a su vez subdividirse en fines externos (observables por
usuarios no programadores) e internos (perceptibles por
programadores que mantienen, mejoran o simplemente modifican el
programa). Tal conocimiento y comprensión no son por
supuesto apropiables, y la libertad es el régimen bajo el
cual serán maximizables. Pero adquirir y coordinar
el
conocimiento requiere el uso de canales de comunicación y el acuerdo sobre los
protocolos a
usar; y los canales de comunicación fiables de alta
velocidad
son un recurso escaso.
La parte de costes de tecnología hardware está
disminuyendo con rapidez, como pone de manifiesto la
aparición de Internet, que ya ha jugado
de hecho un papel importante en la difusión de la
información que ha hecho posible la cultura del software
libre; este coste hardware de la
comunicación ha sido siempre una preocupación
crucial antes o fuera de Internet; e incluso en ella, la parte
WWW, a pesar de sus limitaciones, ha jugado un papel importante
en la dramática reducción del coste
tecnológico relacionado con la creación de centros
de difusión identificables con fiabilidad. Por supuesto,
la predominancia de los costes tecnológicos en la
difusión de información útil fuera de
Internet ha ayudado a ocultar el coste de la apropiación
de dicha información más allá del ocasionado
por su difusión, de modo que los monopolios de la
información se establecieron sin que el público se
preocupara o incluso se diera cuenta de tal hecho, y sin que se
considerara su (temible) impacto sobre el avance
tecnológico.
Pero con Internet, el coste de distribuir software se ha
aproximado a cero, y el coste predominante en la difusión
es el factor humano. Ya que los humanos disponen de un tiempo
limitado para leer y escribir información; necesitan
referencias que los guíen en el océano de la
información disponible; necesitan referencias sobre su
distribución, sobre las que puedan descargar su
preocupación de encontrar información fiable;
necesitan centros de contacto para intercambiarla, en los que
puedan confiar para obtener información útil, y
tomar en consideración las posibles respuestas. Una densa
red de tales
puntos de contacto, en la que los programadores puedan
intercambiar sus contribuciones, es lo que se denomina un
proyecto de programación. Un proyecto tiene una
existencia bastante física, lo que se
opone a los meros objetos de programación que son
ante todo información inmaterial. Un proyecto dado puede
lanzar (con mayor o menor regularidad) objetos, pero no debe
identificarse con ellos; tales objetos lanzados pueden olvidarse,
compartirse por millones de unidades, o reutilizarse de manera
divergente por diferentes proyectos aislados en el tiempo y el
espacio del proyecto original que los produjo.
Los objetos de software no son jamás asimilables
con la propiedad, independientemente de lo que uno lo intente.
Las ideas no pueden poseerese. La propiedad de algo es natural
cuando, y sólo entonces, algo tiene la propiedad
intrínseca de la mutua exclusión. Que es el caso de
los objetos físicos y los servicios, pero no de las
ideas. Por otra parte, los proyectos de software son tan
apropiables como cualquier bien físico; tienen una
identidad en
el mundo físico, independientemente de las partes de la
noosfera que ya hayan sido exploradas o que se pretendan explorar
más adelante; consumen recursos físicos (el trabajo
de los hackers).
El aspecto principal no percibido por Eric en su
artículo sobre la colonización es por tanto que la
combinación de interés y
fama que yace en un proyecto, lo que hace que la gente invierta
su tiempo de programación, lo que él llama su
promesa, constituye el bien escaso que interesa a los que
desarrollan software libre.
Como ejemplo de que los proyectos de software libre
generan recursos y valor por
sí mismos, sin necesidad de recurrir al uso artificial de
la apropiación del software, podemos echar un vistazo
a RedHat
software, que sólo escribe software libre
(todas las versiones de redhat, que son software, son libres) y
sin embargo vende un número de copias suficiente de su
Official RedHat CD como para
prosperar, ya que incluyen el interés, el empuje y la fama
que constituye la esencia del proyecto RedHat, identificado en su
marca
comercial.
De hecho, si en el artículo de Eric sustituimos
cualquier referencia a la propiedad de programas por referencias
a la propiedad de proyectos (el mismo Eric usa en ocasiones esta
expresión más adecuada), el resultado es casi
totalmente correcto. En consecuencia, no puede decirse que los
programadores colonicen la noosfera, la esfera de los programas,
ya que es falso; los programas son algo inmaterial y no es
posible mediante esfuerzo colonizador alguno u otra actividad
cualquiera traspasar una "mágica" frontera
y crear una propiedad en la noosfera. En su lugar los
programadores colonizan una "imagen de la
noosfera", la esfera de los proyectos de programación, que
constituyen exploraciones físicas de la noosfera
inmaterial (lo que da a la publicación de las
"páginas principales" de un proyecto un valor de
ocupación del territorio más que
metafórico). Lo siento por la autoestima de
Eric al haber encontrado otro eslogan de dos palabras de lo
más aparente: "colonizando la noosfera". Pero la
corrección de las ideas es más importante que los
eslógans de impacto, y estoy seguro de que es
también capaz de encontrar un buen eslogan que refleje las
ideas correctas en lugar de las erróneas.
Tras corregir esta confusión, todo lo
demás en el artículo de Eric resulta una
consecuencia inmediata de las consideraciones anteriores, y las
dificultades desaparecen. La gente puede poseer y de hecho posee
proyectos que son más o menos prometedores; y la
dinámica de su posesión es esa cosa fluida que Eric
describe con precisión, pues la teoría
de la colonización se aplica perfectamente a los proyectos
en el campo del software.
Un proyecto no se bifurca de forma arbitraria ya que la
división implica una división de su capital, de su
"promesa", en varias partes, lo que significa un menor retorno a
la inversión en programación a menos
que existan otras causas (tales como el reagrupamiento de otros
proyectos distintos, o la desaparición de un desacuerdo
interno importante) que hagan que uno de los proyectos
resultantes aumente su atractivo por encima del que tenía
el proyecto original. Aunque puedan limitarse los perjuicios
ocasionados por una bifurcación del proyecto a base de
compartir código entre las partes resultantes, existen
costes proporcionales al grado de divergencia de los proyectos
(lo que justifica la ruptura), por lo cual lo anterior es tan
sólo un atenuante .
El simple hecho de que los proyectos puedan bifurcarse
prueba que no pertenecen a la noosfera, ya que la
bifurcación resulta un concepto escasamente aplicable a
ideas platónicas inmutables. Los dos (o más)
proyectos resultantes de una bifurcación parten de los
mismos programas en la misma posición de la noosfera, lo
que resulta incompatible con la posesión de los programas
que una vez más requiere la idea de exclusión
mutua; pero que es sin mebargo compatible con la idea de
possión de proyectos que exploran la noosfera, si bien con
recursos diferentes y una historia pasada y/o futura asimismo
distinta.
Respecto a lo que Eric considera el segundo
"tabú" del software libre, la oposición a realizar
modificaciones fuera de la coordinación reconocida en un proyecto,
puede considerarse un simple corolario del anterior, pues todo
aquel que realiza modificaciones de este tipo actúa como
lo haría dentro de su propia bifurcación del
proyecto, aunque unos pocos parches no oficiales puedan ser
incorporados (eventualmente) a las fuentes del proyecto
oficial.
Podemos por tanto cuestionar que el software libre
implique una economía basada en el
regalo. Para empezar, la misma noción de "regalo" es
confusa cuando se aplica al software tal como hace Eric en su
artículo, por cuanto el software no es poseíble,
pero resulta completamente significativa si la aplicamos a los
proyectos y al tiempo de programación. Por tanto, podemos
ver que de hecho mucho del software libre que se escribe y
distribuye actualmente se realiza durante el "abundante tiempo
libre" de los hackers que de esta forma regalan un tiempo de
programación precioso sin recibir a cambio una
compensación monetaria. Es decir que sí, que puede
ser cierto que el el software libre actual sea
principalmente una cultura basada en la donación. Pero en
ese caso el acaparamiento del software, al desplazar los ingresos desde
los desarrolladores a los monopolizadores, del trabajo
legítimo a la rapiña, distorsiona completamente el
mundo del software: el capital se orienta hacia privilegios
económicos artificiales y se emplea en imponer o utilizar
leyes
injustas, en lugar de invertirse en actividades útiles.
Como resultado, los programadores capaces que se dedican al
software libre no obtienen un reconocimiento de tipo
económico, y el desarrollo de la mayor parte del software
libre (o abierto) debe realizarse de forma gratuita, lo que
explica porqué los hackers que se mueven en el mundo del
software libre se ven forzados, quiéranlo o no, a
la donación de sus obras: la razón no es otra que
los mecanismos de apropiación los excluyen casi totalmente
de la economía predominante en el mundo del software. La
gente que participa en el desarrollo de software libre puede en
cierta medida involucrarse en una "cultura del regalo", algo que
no se opone a una cultura de la competición; pero las
reglas del juego han sido
cambiadas y la competición se desarrolla entre recursos
disponibles pero escasos, no entre recursos que son o bien
inalcanzables o abundantes. En caso de que la ley se corrigiera
y dejara de apoyar la apropiación del software al
reconocer la artificialidad de la "posesión" en la
noosfera, creo que el desarrollo del software así liberado
llevaría a un floreciente mercado libre de los servicios
relacionados con el software que tendría poco que ver,
para bien o para mal, con una economía del
regalo.
El fenómeno con el que cabe comparar de forma
adecuada el desarrollo del software libre es la investigación científica
teórica. De hecho, ambos proceden del mismo
fenómeno general: la creación sistemática de
nueva información. Y comparten un mismo origen
histórico, ya que el mundo del software libre nació
en universidades conectadas a través de Internet y fue
creado por estudiantes y profesores en ciencias de la
computación, matemáticas, física, química, y
demás. En tales campos, la gente explora un espacio
compuesto por objetos de información puros, que no pueden
ser poseidos, aunque se pelee por la fama y por atraer el
interés de otras personas a un campo de trabajo
particular, de forma que los problemas que
nos afectan puedan ser resueltos o puedan captarse fondos
adicionales. Todo lo que digamos sobre la cultura del software
libre es aplicable asimismo a la ciencia
teórica y viceversa.
La comparación resulta perfecta en lo que
concierne a la evaluación
por iguales: ésta es la única forma aceptada de
juzgar la calidad tanto en ciencia como
en el software. De hecho, llegaría hasta extender la
afirmación anterior a cualquier intercambio de
información: es el juicio entre iguales el que asegura la
mejor calidad de cualquier información, ya sea
científica, técnica, financiera, o relacionada con
cualquier aspecto de la vida, incluyendo los asuntos más
comunes del día a día. Es éste mecanismo el
que establece los precios en un
mercado libre, en función de la información
disponible. Y es por esto por lo cual la libertad de
información resulta esencial para mantener el equilibrio en
una economía de mercado, y por lo que la revisión
entre iguales debería extenderse a todos los campos del
conocimiento, para lo que sería necesaria la
abolición de los privilegios actuales relacionados con la
información, ya sean secretos, patentes, acuerdos de
no difusión, o derechos de propiedad
intelectual y de copia. Sin embargo, en aras de la brevedad,
me centraré tan sólo en este artículo en el
tema del software.
La noción de que el reconocimiento de la
autoría debe ser respetado, de que se conserve la pista de
cómo se creó la información, que constituye
el tercer "tabú" del software libre percibido por Eric,
está también presente en Ciencia. En primer lugar,
tal seguimiento resulta sumamente útil cuando se investiga
en campos que analizan procesos
históricos, o se exploran temas relacionados entre
sí. Y, de manera más prosaica, es necesario para
asegurar un reconocimiento adecuado a los autores, de modo que
sean ellos los que logren la fama o la vergüenza asociada a
su trabajo, y se dediquen inversiones
adicionales a proyectos que lo merezcan (que los proyectos que
tienen reconocida una "promesa" dada se beneficien de recursos
adicionales proporcionales a su mérito). Aquellos que
borran tales huellas, que no les costaría nada mantener,
causan a otros las molestias derivadas de la
privación de una información útil, o les
obligan a gastar recursos valiosos en su reconstrucción, a
la vez que minan el proceso de la
evaluación entre iguales. Tal actitud puede por tanto
asimilarse al vandalismo gratuito o al robo cuando se realiza por
interés; y es por lo que la costumbre lo desaprueba con
firmeza y por lo que quizá debería ser incluso
punible por ley.
No tengo más objeciones importantes al resto de
los artículos de Eric S. Raymond. Terminaré
diciendo que todas las confusiones y parcialidades que aparecen
en sus artículos son típicos de su elección
de la "política real" como principio de
actuación en su activismo en pro del software libre. Un
ejemplo de esta elección es haber cambiado con efectos
retroactivos en sus artículos y conferencias el
término "software libre" por "software abierto". No
discrepo de la noción de ser eficaz promoviendo el
software libre. Pero me opongo a acciones que
pueden resultar atajos válidos a corto plazo y causar
perjuicios a la larga, ya que en estos casos, en la
búsqueda de un éxito
puntual, se opta por apoyar fenómenos esencialmente
erróneos en lugar de combatirlos.
Las leyes actuales han creado la noción
artificial de "propiedad intelectual", y han hecho uso de ella
como único modo de defender la necesaria validación
de la información en un sistema de
revisión por iguales. Estas leyes han corrompido
completamente las instituciones
económicas, ya que muchas corporaciones dependen de un
modo crucial del monopolio de
la información, también en el origen de grandes
fortunas, más que de ser pagadas a cambio de la
prestación de servicios reales. No deben realizarse
compromisos con estas leyes, y debe lucharse contra su
justificación, habitualmente errónea. Este es el
principio fundamental de la filosofía del software libre.
Lo menos que Eric podría hacer es evitar tales
justificaciones, en lugar de apoyarlas. Es difícil luchar
contra prejuicios que sirven para justificar enormes intereses
financieros, por supuesto. Hace falta ser muy estricto
precisamente porque la tearea es muy dura.
Faré . François-René
Rideau