Investigacion Sobre El Movimiento Del Software Libre

Investigación sobre el
Movimiento del Software Libre
Pablo Luis Zorzoli
pablozorzoli@yahoo.com.ar
Versión 0.4
Copyright © 2002, 2003 Pablo Luis Zorzoli
Copyright:
Permission is granted to copy, distribute and/or
modify this document under the terms of the GNU
FREE DOCUMENTATION LICENSE, version 1.1
Historia del Documento
Versión 24 de Mayo de Se Eliminaron gifs. Se Modificaron pequeños errores de tipeo.

0.4 2003 Se agregaron varios links de referencia. Disponible en tar.gz
Versión 16 de Abril de
Primera publicación
0.2 2003
FUENTE: http://www.zlabs.com.ar/docs/tif/indice.html
Indice
0. Aclaraciones
1. Introducción
2. UNIX
Historia del Sistema Operativo Unix
Unix de Berkley
El Juicio
3. Richard Stallman y su Proyecto GNU
El Anuncio Inicial
El Manifiesto GNU
Consideraciones Preliminares
El Avance del Proyecto
Polémicas y Enfrentamientos
Consideraciones Finales
4. Licencias
Dominio Público
GNU GPL
GNU LGPL
Licencia BSD
NPL & MPL
Licencia del MIT
Resumen
5. Iniciativa Código Fuente Abierto
Introducción
Definición de Código Fuente Abierto
Diferencias entre Código Fuente Abierto y Software Libre
Licencias Aceptadas
6. Eric Steven Raymond
La Catedral y el Bazar
Netscape y el Bazar
Los Documentos Halloween
7. Software Libre en la Argentina
El Software Libre en el Estado
Marco Legal
Migración de los sistemas de la DPV de Tucumán a GNU/Linux
Proyecto UTUTO
8. Proyectos de Software Libre
W.I.N.E.
Fundación Apache
SAMBA
OpenOffice
9. Software Libre en la UADE
Caso 1: Usuarios de Software en General
Caso 2: Enseñanza de Informática
Caso 3: Estudiantes de Informática
10. Conclusión Final
ANEXOS
Anexo I: Ejemplos de Mensajes de Respuesta
Anexo II: Proyecto de Ley de Software Libre
Anexo III: GNU Free Documentation License
Referencias
0. Aclaraciones Preliminares
He decidido proteger este Trabajo de Investigación Final, bajo la licencia GNU
Free Documentation License1. La principal motivación para esta decisión ha
sido justamente todo lo aprendido al estudiar los logros que se obtienen si se
da libertad a la gente.
Mi intención es que, luego de cumplir con los requisitos académicos, este
trabajo pueda estar a disposición de quién lo desee. Esta licencia permite que
cualquier persona tome este escrito y lo redistribuya o lo modifique libremente.
De esta forma, nuevas versiones mejoradas del trabajo pueden obtenerse.
A su vez, es de mi interés dejar en claro la acepción de algunos términos que
se emplearán a lo largo de la publicación.
En primer lugar, el término hacker. En la actualidad, mucha gente asocia este
término con el de delincuente informático. En este documento, se utiliza esta
palabra para identificar a las personas que son especialistas programadores o
que tienen mucho interés y conocimientos en lo que respecta a la informática.
Pero que bajo ningún concepto utilizan sus habilidades para efectuar daños a
terceros.
El otro término que es empleado en varias ocasiones y puede prestarse a
confusión es el de portar. Con esta palabra, se intenta describir el proceso de
reescribir o recompilar una aplicación para que pueda utilizarse en una
arquitectura de computadora diferente a la original para la que fue escrita.
Una última aclaración en cuanto a las convenciones utilizadas en este trabajo,
se refiere a la manera adoptada para nombrar al sistema operativo GNU/Linux.
El autor opina que es la forma más conveniente de nombrar al sistema
completo. En los casos particulares en que se haga referencia únicamente al
núcleo del mismo se usará el término Linux.
1. Introducción.
Objetivos y Alcances
El presente trabajo apunta a presentar un análisis de las características
específicas del movimiento del Software Libre. Es de gran importancia para un
profesional de la informática conocer a nivel amplio el funcionamiento de este
modelo que surgió principalmente en los ámbitos académicos, pero que gracias
a Internet, ha logrado proliferar a través del mundo.
A esta altura de las circunstancias, la mayoría de la gente ha oído hablar de
'GNU/Linux'. La verdad es que gracias a la popularidad y publicidad obtenida
por el sistema del pingüino, mucha gente se ha acercado al mundo que se
encuentra del otro lado del estándar de facto creado por Microsoft.
GNU/Linux es solo la punta del iceberg. Debajo de él, se encuentran miles de
proyectos. Cada uno de los cuales tienen diferentes líderes, objetivos y
filosofías. Este trabajo se introducirá en las entrañas de este movimiento.
Para comenzar, nos remontaremos a los finales de la década del sesenta
cuando el software era libre para todos. Se estudiará cómo fue desapareciendo
la camaradería entre desarrolladores y fueron surgiendo las grandes
corporaciones que comenzaron a utilizar las licencias y contratos de no difusión
para dejar de compartir el código fuente de sus programas.
Se analizará en profundidad uno de los casos más emblemáticos de todos los
tiempos: el sistema operativo Unix. La etapa de colaboración entre Berkley y
AT&T y los conflictos posteriores. Se nombrarán todas las bifurcaciones que
surgieron a partir de este sistema operativo.
Al llegar a la década del ochenta, se expondrá el nacimiento del proyecto GNU.
Richard Stallman comienza a desarrollar un conjunto de herramientas, e intenta
crear un sistema operativo totalmente libre2. Nace la Free Software Foundation
(Fundación para el Software Libre). Se expondrá la filosofía de este carismático
líder.
También serán objeto de estudio las distintas licencias que surgieron para
proteger el Software Libre. Se comentarán las ventajas y desventajas de cada
una. Se detallará en qué situaciones es conveniente usar cada licencia.
Dentro del desarrollo, se dedicará una sección entera a presentar el modelo
alternativo al software libre, conocido como Open Source. Se establecerán las
similitudes y diferencias frente al software libre.
Se expondrán los aportes de Eric Raymond y se estudiará uno de sus escritos
más famosos y comentados: “La catedral y el bazar”.
Se estudiarán casos particulares de proyectos. Apache, Samba, Openoffice y
WINE. Se analizarán sus estructuras de desarrollo, de decisión. Reportes y
corrección de errores. Desarrollo y depuración distribuidos.
A su vez, se analizará la posición que ocupa actualmente el software libre en
nuestro país y se presentarán distintos casos de proyectos de software libre.
También se incluirá en el análisis de la coyuntura local, al proyecto de ley de
software libre.
Para finalizar este trabajo, mi idea ha sido elaborar distintas propuestas para
implementar en el ámbito de la Universidad. Las mismas apuntan a aprovechar
las ventajas de este modelo y a su vez enriquecer la calidad académica de los
cursos.
El desarrollo de este trabajo me ha permitido investigar e introducirme en un
mundo más que interesante en donde prima la camaradería y el deseo de
compartir el conocimiento para fomentar el desarrollo futuro, basándose en los
logros anteriores.
Básicamente, este mundo se asemeja a lo expresado por Sir Isaac Newton: “Si
he visto más lejos, es porque me apoyé sobre los hombros de gigantes”. Todos
los participantes de este movimiento directa o indirectamente llevan a cabo lo
dicho por este genio y son los que permiten que cada vez más gente se
acerque a este universo donde el conocimiento es una herramienta y no un
arma de dominación.
2Libre: Este es un término muy conflictivo, por la duplicidad del significado en inglés de Free .
A lo largo de este trabajo se desarrollará con mayor detalle la acepción correcta que tiene en
este tema.
2. UNIX
Historia del sistema operativo UNIX
Para poder comprender el éxito actual del software libre, lo primero que se
debe hacer es repasar la historia. Sin dudas, uno de los hitos clave es el
nacimiento del Sistema Operativo Unix.
Creado en 1969 en los laboratorios Bell de AT&T por Ken Thompson, UNIX
nació como un experimento de la empresa para ayudar a controlar la nueva
generación de redes telefónicas, que estaban convirtiéndose en computadoras
especializadas.
Bell ya había participado junto con el M.I.T. y General Electric en el desarrollo
del sistema MULTICS3. Thompson y sus colegas admiraban las capacidades de
MULTICS, pero consideraban que era demasiado complicado, por lo que se
dieron a la tarea de demostrar que era posible construir un sistema operativo
que ofreciera un ambiente de trabajo cómodo y que fuera mucho más sencillo.
La primera versión de UNIX, llamada UNICS4 se ejecutaba en una
computadora DEC PDP7. Este primer UNIX estaba escrito en un lenguaje
llamado B.
El trabajo de Thompson impresionó a sus colegas de los laboratorios Bell de tal
forma que pronto se le unió Dennis Ritchie y más tarde todo el departamento.
Lo primero que hicieron fue portar el UNIX de la obsoleta PDP7 a las
modernas PDP11/20, PDP11/45 y PDP11/70.
Ritchie, diseñó un sucesor de B, llamado C y escribió un compilador con el
objeto de ofrecer un lenguaje que pudiera usarse para escribir una versión
portable del sistema. En 1973 Ritchie y Thompson rescribieron UNIX en C.
En noviembre del '73 Ritchie y Thompson presentaron el primer artículo sobre
UNIX, en el simposio sobre los principios de los sistemas operativos en la
Universidad de Purdue. Este artículo estimuló a muchas universidades a pedir
a los laboratorios Bell una copia de UNIX.
Puesto que la compañía dueña de los laboratorios Bell, AT&T, era entonces un
monopolio regulado y no podía entrar al negocio de la computación, no tuvo
objeción en otorgar licencias de uso de UNIX a las universidades a un bajo
costo. Algo muy importante es que AT&T también distribuyó el código fuente de
UNIX, fomentando así el desarrollo adicional y las innovaciones.
Se organizaban reuniones científicas en torno de UNIX, con distinguidos
conferencistas que indicaban el descubrimiento de ciertos errores y la forma de
arreglarlos. Como resultado de esta actividad, las nuevas ideas y mejoras al
sistema se difundieron con rapidez. La versión que se convirtió en el primer
estándar del mundo académico fue la Versión 6.
UNIX de Berkley
Uno de los asistentes al simposio de noviembre del '73 fue el profesor Fabry de
la Universidad de California, Berkley. El profesor quedó inmediatamente
interesado en obtener una copia para experimentar en los laboratorios de
Berkley.
En enero del '74 se instaló Unix en una computadora PDP11/455. Los primeros
problemas que surgieron con el sistema fueron corregidos de manera remota
por el mismísimo Ken Thompson. Este fue el comienzo de la relación de
cooperación entre Berkley y los laboratorios Bell.
En los comienzos de 1977, Bill Joy organizó la `Berkley Software Distribution'
(BSD). Esta primera distribución incluía el sistema Pascal y un editor de textos
llamado 'ED'. Para mediados del '78 salió la segunda versión(2BSD). La misma
incluía grandes mejoras al Pascal, fruto de la colaboración de la comunidad
usuaria del mismo. También contaba con un nuevo editor de textos, el ahora
famoso 'vi'.
La última versión de UNIX, de los laboratorios Bell fue 32/V6. De ahí en más el
desarrollo de UNIX pasó a USL7. Este grupo lanzó primero el System III y luego
el System V, pero los objetivos perseguidos eran netamente comerciales. Al
comercializarse UNIX, el personal de los laboratorios Bell no pudo continuar
encargándose de manejar las investigaciones que estaban llevando a cabo en
las distintas universidades.
De esta manera y dado que la comunidad investigadora seguía modificando el
sistema UNIX, se hacía notoria la necesidad de producir nuevas versiones a
partir de lo investigado. Fue así que Berkley tomó el rol antes ostentado por los
laboratorios Bell, dado que fue uno de los primeros participantes en la
evolución del UNIX y por su vasta experiencia en la creación de herramientas
basadas en UNIX.
Mientras tanto en la DARPA8, se estaba buscando una manera de
homogeneizar las comunicaciones entre las computadoras que formaban la red
de centros de investigaciones. Decidieron que la mejor solución sería unificar a
nivel de sistema operativo. Luego de varias discusiones, UNIX fue seleccionado
por su probada portabilidad.
A fines de 1979, Berkley ofreció a la DARPA la creación de una versión
mejorada de la 3BSD para la comunidad DARPA. Gracias a la buena
reputación obtenida por la distribución 3BSD, Berkley obtuvo en abril del '80 un
contrato con DARPA por 18 meses. Dada la magnitud del proyecto se creó una
organización, la CSRG9. Con el Apoyo de la DARPA, la CSRG comenzó a
crecer y las versiones de BSD comenzaron a sumar adeptos.
La distribución 4BSD vio la luz en octubre de 1980. Para junio del '81 se lanzó
la 4.1BSD. La agencia DARPA estaba satisfecha con los resultados, por lo que
renovó el contrato con Berkley por dos años más.
En agosto de 1983 se lanzó la 4.3BSD que tuvo mayor popularidad que el
System V de AT&T(y la USL). La principal razón era que el System V no poseía
las herramientas para redes, ni el nuevo sistema de archivos diseñado por
Berkley (FFS10). Cuando éstos cambios se incorporaron al System V (gracias a
la disponibilidad del código fuente de Berkley), el System V recuperó el terreno
perdido. En esa época BSD se encontraba a la vanguardia de los sistemas tipo
UNIX.
Hasta la versión 4.3BSD, todos los usuarios debían obtener primero una
licencia para el código fuente de AT&T. Esto se debía a que los sistemas BSD
nunca fueron lanzados por Berkley en su forma binaria/ejecutable. Las
distribuciones siempre contenían el código fuente completo de cada parte del
sistema. La historia de los sistemas UNIX y del sistema BSD en particular
mostró el poder de que los usuarios dispongan del código fuente. En vez de
utilizar el sistema de forma pasiva, los usuarios trabajan activamente
corrigiendo errores, mejorando el desempeño, la funcionalidad y eventualmente
incorporando nuevas características.
Los incrementos constante en los costos de las licencias para el código fuente
de AT&T se transformaron en prohibitivos. Los interesados en crear
aplicaciones para trabajo en redes basándose en el protocolo TCP creado por
Berkley, reclamaron a la universidad que los lanzara por separado del sistema
operativo completo y que se empleara una licencia que no requiriera pagar los
derechos de AT&T.
El código originado por Berkley para redes y las aplicaciones de soporte fueron
lanzadas en junio de 1989 bajo el nombre de `Networking Release 1`. Este fue
el primer código libremente distribuido lanzado por Berkley.
Los términos de la licencia eran liberales11. Cualquiera podía distribuir el código
(modificado o no) ya sea de forma binaria o fuente sin pagar regalías a Berkley.
Los únicos requerimientos eran que los avisos de copyright del código fuente
debían dejarse intactos. Además si algún producto incorporaba el código fuente
de Berkley el mismo debía indicar en la documentación que el producto
contiene código de la Universidad de Berkley y sus contribuyentes.
En junio de 1991, el grupo lanzó el 'Networking Release 2'. Esta versión incluía
casi por completo una versión operativa de UNIX. La tarea de desarrollo del
Networking Release 2 se llevó a cabo en 18 meses y participaron más de 400
personas. Keith Bostic fue quien se encargó de coordinar a la gente para
producir código fuente nuevo que pudiera reemplazar los fragmentos
pertenecientes a AT&T. Bostic le entregaba a los voluntarios la descripción
publicada de la aplicación o la parte de la documentación de la biblioteca y les
pedía que lo implementaran nuevamente sin utilizar el código de AT&T. Esta fue
la forma dentro del marco de la ley con la que se dio vida a este proyecto.
Como fue expresado anteriormente, Networking Release 2 era casi una versión
completa de UNIX. Lo que faltaba para transformarlo en un sistema
completamente funcional eran seis archivos. Networking Release 2 fue lanzado
sin estos seis archivos pero seis meses más tarde (enero del '92) ya estaban
listos.
Este hueco fue tapado por Bill Jolitz, quien lanzó un sistema booteable para la
arquitectura 386 al cual bautizó '386BSD'. La distribución de este sistema fue a
través de Internet. Unos meses después del lanzamiento, Jolitz no pudo
continuar encargándose del proyecto. Entonces algunos usuarios crearon el
grupo NetBSD para agrupar los esfuerzos colectivos, mantener y mejorar el
sistema. El grupo NetBSD eligió enfocar sus objetivos al soporte de la mayor
cantidad de plataformas posibles. Otro objetivo de importancia dentro del
proyecto es enfatizar el diseño correcto y la generación de código fuente bien
escrito. Un ejemplo es la implementación de una infraestructura de bus
independiente de la arquitectura de la máquina. Esto posibilita que un único
controlador de dispositivo, se pueda compartir en diferentes tipos de bus (PCI,
ISA, etc.) y también en diferentes plataformas. Esto contrasta con el enfoque
tradicional de escribir y mantener diferentes versiones del controlador. NetBSD
provee lanzamientos formales para 21 plataformas distintas.
El grupo FreeBSD se formó unos meses después que el grupo NetBSD. Su
objetivo era soportar principalmente la arquitectura de la PC. Además
apuntaban a atrapar un grupo de usuarios con menor o nulos conocimientos
técnicos. Crearon sistemas de instalación elaborados y comenzaron a vender el
sistema en CDRoms de bajo costo. FreeBSD posee el mayor número de
usuarios de todos los sistemas derivados del Networking Release 2.
La otra bifurcación dentro de las distribuciones se produjo en 1995 cuando
Theo de Raadt (uno de los 8 socios fundadores de NetBSD) fue echado12 del
grupo. Las metas de esta distribución son enfatizar la corrección, seguridad,
estandarización y portabilidad. En definitiva, quieren convertirse en el sistema
operativo más seguro del mercado.
El Juicio
Además de los grupos organizados para distribuir libremente sistemas creados
a partir del Networking Release 2, se creó la compañía BSDI (Inc) para
desarrollar y distribuir una versión del código fuente mantenida comercialmente.
De la misma manera que los otros grupos, lo primero que hicieron fue
desarrollar los 6 archivos faltantes a la distribución 386BSD. BSDI comenzó a
vender su producto (que incluía código fuente y binarios), en enero de 1992.
Esto provocó una reacción por parte de USL, lo que derivó en una demanda
judicial contra BSDI y la Universidad de California, alegando que sus productos
contenían código fuente propiedad de la USL.
La justicia decretó que mientras perduraban las acciones judiciales ninguna
distribución basada en Networking Release 2 podía ser comercializada.
La causa se prolongó en el tiempo y recién llegó a su fin en enero de 1994. El
resultado fue que 3 archivos debían quitarse de la distribución Networking
Release 2 (que contenía aproximadamente 18000 archivos), y algunos cambios
menores debían efectuarse a otros archivos. La universidad accedió a agregar
copyrights de la USL a 70 archivos, aunque los mismos continuaron
distribuyéndose libremente.
Con la finalización del juicio, se lanzó la 4.4BSD Lite en junio de 1994. Los
arreglos del juicio estipularon que USL no demandaría a ninguna organización
que use 4.4 BSD Lite como base para su sistema. De esta manera, todos los
grupos que realizaban distribuciones basadas en el código BSD (NetBSD,
FreeBSD, BSDI), tuvieron que empezar nuevamente a partir del código base
del 4.4 BSD Lite y luego migrar todos los cambios y mejoras propios a este
nuevo código base.
Línea de Tiempo
1991 1992 1993 1994 1995 ... 2002
Networking
386BSD FreeBSD
Release /2
NetBSD
4.4 BSD
FreeBSD
Lite
NetBSD
OpenBSD
3 MULTICS:
(Multiplexed Information & Computing Service). Servicio de información y cómputo
con Multiplexión. Fue un sistema de tiempo compartido, grande y de alta capacidad, que incluía
varias ideas novedosas en el campo del diseño de sistemas operativos. El proyecto fracasó en
parte por ser demasiado ambicioso para su época.
4 UNICS:
Sistema de Información y cómputo con Uniplexión. El nombre implica un juego de
palabras con eunucos, para indicar que era un MULTICS castrado. Más adelante se lo cambió
por UNIX.
5 DEC PDP
: Digital Equipment Corporation. Los modelos 11/45 y 11/70 dominaron el mundo de
las minicomputadoras durante gran parte de la década del '70.
6 32/V
: Versión de UNIX para la arquitectura VAX.
7 USL
: Laboratorios del Sistema UNIX. Subsidiaria de AT&T.
: Agencia de proyectos avanzado de investigación de defensa.
8 DARPA:

9 CSRG
: Grupo de investigación en sistemas de computación de Berkley.
10 FFS
: Sistema de archivos rápido de Berkley.
11En este momento nace la Licencia BSD. La misma será analizada en la sección 4.
12Lo que realmente sucedió fue que le quitaron los permisos para escribir en el árbol de código
de los desarrolladores.
3. Richard Stallman y su Proyecto GNU
Introducción
Sin dudas Richard Mathew Stallman es la persona más importante dentro del
movimiento del software libre. De hecho, fue él quien acuñó la concepción
actual del término ' Software Libre' (ver http://www.fsf.org/philosophy/free
sw.es.html).
Nacido en el año 1953 en Nueva York, tuvo su primer contacto con una
computadora (IBM 7094) a la edad de 12. A los 18 años, ingresó en el
laboratorio de inteligencia artificial del MIT. En esa época el software se
compartía sin ningún problema. Stallman se formó dentro de una comunidad
que compartía todo. Al comenzar la década del 80 se produjeron algunos
hechos que desencadenaron la reacción de dicha persona.
En primer lugar, la compañía Symbolics contrató a casi todos los hackers del
laboratorio de IA, y la despoblada comunidad dejó de ser capaz de mantenerse
a sí misma. A esto se le sumó el hecho que, el laboratorio adquirió una nueva
PDP10 y sus administradores decidieron utilizar el sistema no libre de tiempo
compartido de Digital en vez del ITS13 que había sido diseñado en el MIT y que
era libre.
De esta forma, Stallman se vio obligado a tomar una decisión:
'Al desaparecer mi comunidad, se hizo imposible continuar como antes. En
lugar de ello, me enfrenté a una elección moral severa.
La elección fácil era unirme al mundo del software propietario,
firmar los acuerdos de no revelar, y prometer que no iría en ayuda
de mi amigo hacker. Podría haber hecho dinero de esta manera, y
tal vez me hubiera divertido escribiendo código. Pero sabía que al
final de mi carrera, al mirar atrás los años construyendo paredes
para dividir a la gente, sentiría que usé mi vida para empeorar el
mundo...
Otra elección, fácil pero dolorosa, era abandonar el campo de la computación.
De esta manera no se usarían mis habilidades para dividir a la gente, pero aún
así se desperdiciarían...
Así que busqué la manera en la cual un programador podía hacer algo bien.
Me pregunté: ¿ habrá algún programa o programas que yo pueda escribir, de
tal manera de otra vez hacer posible una comunidad? La respuesta era clara: lo
primero que necesitaba era un sistema operativo... El nombre GNU se eligió
siguiendo una tradición hacker, como acrónimo recursivo para GNU's Not Unix.'
A partir de ese momento, Stallman no se detuvo jamás. Comenzó a darle vida
a su idea y para hacerse conocer redactaba ensayos expresando sus ideales.
El primero de esos documentos, se lo conoce como el anuncio inicial y será
analizado en forma detallada.
EL ANUNCIO INICIAL
Ver el Documento Completo en
http://www.fsf.org/gnu/initialannouncement.es.html
Este documento fechado el 27 de septiembre de 1983 fue enviado a dos grupos
de noticias con el asunto: "Nueva implementación de UNIX". En este breve
correo electrónico Stallman comienza a explicar su proyecto:
'Voy a escribir un sistema... compatible con UNIX llamado GNU... y lo distribuiré
libre"14 A su vez explica las similitudes y diferencias de su GNU con UNIX:
"GNU tendrá la capacidad de correr programas UNIX, pero no será idéntico a
UNIX. Haremos todas las mejoras que son convenientes, basados en nuestra
experiencia con otros sistemas operativos'
Luego hace una presentación de su persona y pasa a explicar las razones por
las que escribirá GNU.
'Considero que la regla de oro exige que si yo quiero un
programa debo compartirlo con otras personas que
también lo quieren. No puedo, conscientemente, firmar un
acuerdo de confidencialidad o un acuerdo de licencia de
software.
Para que yo pueda continuar utilizando las computadoras
sin violar mis principios, he decidido reunir suficiente
software libre de manera que podré continuar sin
necesidad de utilizar algún software que no sea libre'.
Estos párrafos definen claramente la postura filosófica de Richard Stallman.
Son los primeros pasos de su lucha contra el modelo de software propietario.
Stallman menciona a los acuerdos de confidencialidad. Esta es la forma en que
usualmente se distribuían los programas en la década del 80. Al usuario se le
entregaba el sistema (raras veces el código fuente), y tenía que firmar un
acuerdo de confidencialidad. En el mismo se comprometía a no divulgar el
código fuente, ni copiar ni modificar ni redistribuir el sistema. Stallman sufrió en
carne propia las consecuencias de los acuerdos de confidencialidad con una
impresora XEROX15.
El documento continúa pidiendo donaciones de dinero, equipos y mano de
obra.
`Los programadores pueden contribuir escribiendo una copia compatible de
alguna utilidad UNIX y dándomela. Para la mayoría de proyectos, tal trabajo
distribuido sería muy difícil de coordinar; las partes escritas
independientemente no trabajarían juntas. Pero para la tarea particular de
reemplazar UNIX , este problema está ausente... Si cada contribución trabaja
con el resto de UNIX , probablemente trabajará con el resto de GNU'
Lo que intenta explicar Stallman es la forma en que pretende encarar el
proceso de reemplazo de UNIX. Propone que el voluntario tome una aplicación
de UNIX y la reescriba. Luego debe reemplazar la aplicación original por la
nueva. Si funciona correctamente, esto quiere decir que el trabajo está
finalizado.
Cabe destacar que en aquel entonces no existía la GNU GPL. Este es el motivo
por el cual Stallman reclama que quien cree una aplicación, se la done. De esta
forma, se aseguraba de registrarla a nombre de la FSF a la espera de crear
una licencia acorde con sus principios.
El documento finaliza con una expresión de deseo por parte de su autor:
'Si obtengo donaciones de dinero, puedo contratar algunas personas por
tiempo completo o a tiempo parcial. El salario no será alto, pero estoy
buscando personas para quienes el ayudar a la humanidad sea tan importante
como el dinero. Veo esto como una manera de permitirles a las personas
consagradas dedicar completamente sus energías trabajando en GNU
ahorrándoles la necesidad de ganarse la vida de otra manera'.
Stallman califica a su emprendimiento como una ayuda a la humanidad y
demuestra su intención de contratar personal. Poco tiempo después esa idea
se hizo realidad al fundar la Fundación para el Software Libre (F.S.F.).
Unos meses después de que este anuncio fuera realizado, ya en el año 1984,
Stallman publica una nueva versión de su editor de textos EMACS (GNU
EMACS) como software libre. El GNU EMACS comenzó a distribuirse de dos
formas:
1. A través de un servidor FTP anónimo del cual se podía descargar en forma
gratuita.
2. Comprando una copia por u$s 150. De esta manera, inició un negocio de
distribución de software libre.
El GNU EMACS fue lanzado bajo una licencia llamada GNU EMACS License.
La misma fue la antecesora de la GNU GPL. Como gran diferencia puede
indicarse que la licencia del GNU EMACS requería que los cambios efectuados
al código fuente se entregasen al autor (en este caso a Stallman) .
A medida que el interés por el uso de GNU EMACS crecía, otras personas se
involucraron en el proyecto GNU. Entonces nació la Fundación para el Software
Libre (FSF). Esta organización de caridad libre de impuestos fue ideada para
fomentar el desarrollo de software libre.
El Manifiesto GNU
Ver el Documento Completo en
http://www.fsf.org/gnu/initialannouncement.es.html
Este documento se basa en el anuncio inicial que Stallman publicó en 1983. El
mismo ahonda en temas de índole técnica y filosófica. Sin dudas este
manifiesto deja sentadas las bases sobre las que más adelante se edificó el
movimiento de software libre.
Resulta importante analizar el contenido del mismo para destacar cuales eran
las intenciones iniciales del creador del proyecto GNU. Se pueden encontrar
varias aristas interesantes y controversiales que ayudan a comprender a una
persona tan carismática como Richard Stallman.
El manifiesto comienza explicando el motivo del nacimiento del proyecto GNU.
Su creador comenta que ya cuenta con voluntarios ayudándolo e invita a otros
programadores a sumarse. Luego se encarga de describir las aplicaciones que
ya poseen. Entre ellas se destacan:
1. Editor de textos GNU EMACS (creado por él mismo).
2. Un shell casi terminado. (hoy conocido como BASH)
3. Un nuevo compilador portable de C que se ha compilado a sí mismo y será
liberado este año. (se refiere al gcc y al año 1985).
4. Existe un núcleo inicial pero requiere de muchas características más para
emular UNIX.
5. Usaremos el sistema gratuito y portable de ventanas XWindow.
De toda esta enumeración de aplicaciones, la que le trajo más dolores de
cabeza a Stallman en particular y a su proyecto en general fue el núcleo o
kernel del sistema operativo. En aquel entonces indicaba que ya poseía un
núcleo pero que faltaba mucho para que pudiera ser funcional. La verdad es
que cinco años después (en 1990) el sistema GNU estaba casi completo y el
único componente faltante era el núcleo. El núcleo HURD nunca ha llegado a
ser completamente funcional. Este hueco fue en donde calzó el proyecto
empezado por Linus Torvalds.
Stallman continúa el manifiesto expresando que GNU está siendo escrito
inicialmente para máquinas de la serie 68000 de Motorola. Menciona que si
alguien dona algún equipo al proyecto, seguramente GNU se ejecutará en
ellos. Con esto busca captar donaciones de máquinas con distintas
arquitecturas prometiendo que GNU se portará a esos sistemas.
Luego prosigue esgrimiendo las razones por las cuales escribirá GNU.
Nuevamente reitera lo expresado en el anuncio inicial, y agrega que ha
renunciado a su trabajo en el laboratorio de IA para que el MIT no posea
ninguna excusa legal que le prohíba distribuir GNU libremente.
Este fue un gesto bastante elocuente por parte de Stallman, para demostrar
que su iniciativa era seria. Igualmente a pesar de no ser más empleado del
MIT, las autoridades le permitieron continuar utilizando su oficina para este
proyecto particular.
El manifiesto continúa con dos puntos muy importantes. El primero es
netamente técnico. Indica que GNU, será compatible con UNIX dado que es un
buen sistema portable pero además porque es el más utilizado16. De esta
manera al ser compatible, las utilidades UNIX podrían ejecutarse en GNU. Y el
otro motivo importante es que no sería difícil el cambio al nuevo sistema
operativo para los usuarios de UNIX.
El segundo punto importante es cuando Stallman explica como estará
disponible GNU:
'GNU no es de dominio público. Todos tendrán permiso para modificar y
redistribuir GNU, pero a ningún distribuidor se le permitirá restringir su
redistribución posterior. Esto es decir, modificaciones propietarias no estarán
permitidas'.
Con estas palabras queda definida la intención de Stallman de proteger su
software con una licencia que asegure que los programas sean libres y que
continúen siéndolo. Años después creó la licencia GPL, dándole un marco legal
a estas premisas filosóficas.
Más adelante Stallman escribe sobre los beneficios que le brindará GNU a los
usuarios de computadoras.
'Los códigos completos del sistema estarán disponibles para todos. Como
resultado, un usuario que necesita cambios en el sistema será siempre libre
para hacerlos por sí mismo, o de contratar a cualquier programador o empresa
disponible para hacerlos por él. Los usuarios no estarán ya a merced de un
programador o una empresa que sea dueña de los códigos fuente' .
Este aspecto remarcado por Stallman es muy importante ya que está
explicando las oportunidades de negocio dentro del mundo de software libre. A
lo que apunta es a dejar en claro que no se opone a que los programadores
cobren dinero por su trabajo o que las empresas participen del negocio. Lo que
intenta repudiar es que no se respete la libertad, o se intente coartar los
derechos de los demás.
Como última sección del manifiesto, Stallman se encarga de autorresponder un
conjunto de preguntas sobre diversos ítems de su proyecto. Es una especie de
conclusión final donde continúa recalcando cuales (en su opinión) son las
razones por las que el usuario de computación en particular y la humanidad en
general se beneficiarán con el software libre.
Consideraciones Preliminares
Luego de analizar estos dos primeros documentos redactados por el padre del
proyecto GNU y la FSF, se pueden sacar diversas conclusiones.
Una de ellas, y por cierto la más evidente de todas es que se está frente a un
purista, que muchas veces se parece más a un extremista. Ya desde sus
primeros escritos pueden rescatarse sus ideales de libertad que lo impulsaron a
abandonar su trabajo y dedicarse a la tarea 'sagrada' de liberar a la humanidad
del software propietario.
A pesar de todo, hay muchas cosas que no quedan claras o se prestan a la
confusión en estos documentos. Pero hay que reconocer la habilidad que
demuestra Stallman a través de su prosa, de capturar al lector y hacerlo pensar
como él quiere.
Cabe recalcar que Stallman es un ciudadano estadounidense. Esto no es un
dato menor, ya que su prédica ha sido muchas veces tildada de comunista.
Además para la fecha en que comenzó su proyecto (año '84), la guerra fría aún
no había finalizado, por lo que las críticas fueron más feroces. Stallman nunca
le prestó mucha importancia a estos comentarios, pero siempre aclaró que sus
intenciones se alejan mucho de las de un régimen comunista, dado que en
éstos se coartan las libertades de la gente y lo que él busca es la libertad a
cualquier precio.
Está claro que frente a una personalidad tan influyente se encuentren fieles
seguidores y fervientes detractores.
El avance del Proyecto
Stallman comenzó a sumar adeptos a su proyecto GNU. La mayoría de ellos
provenían de los claustros universitarios y eran expertos programadores. La
Free Software Foundation, era la entidad madre que se encargaba de
administrar el trabajo de los voluntarios. Los ingresos por ventas del GNU
EMACS ayudaban a mantener la fundación.
En una entrevista con la revista '
Byte
' en junio de 1986

(http://www.fsf.org/gnu/byteinterview.html), Stallman respondía sobre su
manera de ganarse la vida:
'De la consultoría. Cuando hago consultoría, me reservo el derecho a publicar
lo que escribí para el trabajo. También podría ganarme la vida vendiendo
copias de software libre que escribí. Mucha gente me envió 150 dólares por el
GNU EMACS, pero actualmente ese dinero va a la FSF que fundé. La
fundación no me paga un sueldo porque surgiría un conflicto de intereses. En
cambio contrata a otras personas para que trabajen en GNU. Mientras pueda
continuar ganándome la vida como consultor, creo que es la mejor manera'.
Sin dudas, Stallman gozaba de buena fama como programador, lo que le
permitía cobrar hasta 260 dólares por hora de consultoría. Pero esta tarea le
quitaba tiempo y no le permitía dedicarse cien por ciento a su proyecto.
Esta situación cambió radicalmente, cuando en 1990 fue galardonado con una
beca de investigación de 240.000 dólares, por la fundación MacArthur. Estas
becas conocidas como 'genius grants', se entregan anualmente a personas de
gran talento y creatividad. En el caso puntual de Stallman se le entregó por sus
méritos en el campo de desarrollo de software, en especial por el software libre
y por su fundación (la FSF). Esto le permitió a Stallman dedicarse por completo
a su proyecto.
Uno de los hitos clave dentro del desarrollo del proyecto GNU, es la creación de
la licencia GPL. Fue un gran éxito para Stallman y su gente lograr darle un
marco legal, al movimiento que estaban forjando.
Aunque las implicancias de esta licencia serán analizadas en la sección
siguiente, es importante ubicarla dentro del contexto del avance del proyecto y
como impactó sobre el mismo.
Antes de la GPL, había un vacío legal ya que la FSF no tenía un instrumento
jurídico que le permitiese proteger de la manera que ellos deseaban al software
de su propiedad. A partir de esta licencia (año '89) surge el concepto de
'copyleft'. La idea de Stallman y por ende la FSF era que el software puede
considerarse libre si cumple con las siguientes cuatro libertades:
 Libertad 0 : Libertad de ejecutar el programa para cualquier finalidad.
 Libertad 1 : Libertad de estudiar como funciona el programa y adaptarlo a
las propias necesidades.
 Libertad 2 : Libertad de distribuir copias para ayudar a un tercero.
 Libertad 3 : Libertad de mejorar el programa y publicar las propias mejoras,
para que se beneficie de ellas toda la comunidad.
La libertad 0 la entregan todos los programas en general. Por eso es que
realmente las libertades 1, 2 y 3 son las que distinguen al software libre del
resto.
La libertad 1 es la que implica ayudarse a uno mismo modificando el software
para que satisfaga las necesidades propias. Esto puede ser reparando algún
error, agregándole funcionalidad o portándolo a otra arquitectura de
computadora.
De esta libertad surge la oportunidad del negocio. Es obvio que no todos los
usuarios de software son programadores que pueden reparar o modificar los
programas. Entonces el usuario puede contratar a un programador o una
empresa para que modifique el software por él.
La libertad 2 es la que apunta a la distribución de copias de software. Stallman
dice 'En la actualidad nos hacen creer que ayudar a un amigo es moralmente
equivalente a atacar un barco. Te llaman pirata'.
La libertad 3 apunta a la posibilidad de armar comunidades de desarrollo de
software libre. La idea es trabajar juntos para avanzar el conocimiento humano.
Es la libertad de modificar el software y que haya gente que coincida con esa
modificación.
Para cumplirse las libertades 1 y 3 se debe tener acceso al código fuente. Pero
no es lo único que importa. El software libre no es solo disponer del código
fuente. Es toda una filosofía de desarrollo en la que lo más importante es la
libertad. Muchos de los que intentan despreciar a este movimiento lo simplifican
hablando de código fuente abierto y copias gratuitas.
La caída de la FSF comienza a sentirse por el año '92 cuando se produce una
división en el desarrollo del GNU EMACS (XEMACS). En 1996 XEMACS ya es
más popular que el EMACS. A su vez, el desarrollo del núcleo GNU Hurd
prácticamente muere, eclipsado por las fallas propias y el boom de Linux.
En el año '97, se produce la división en el desarrollo de gcc (nace egcs). Junto
con esto, comienza a desaparecer la idea de que la FSF es el centro del
universo del software libre. En el mismo año Eric Raymond publica su texto “La
catedral y el bazar”, dando nacimiento al movimiento “Open Source”. A la larga
este término se vuelve más conocido y utilizado que el de software libre.
Para el año 2000 el proyecto GNU se convierte en una organización puramente
política, prácticamente sin ninguna actividad de desarrollo importante.
En la actualidad Stallman es un reconocido conferencista que recorre el mundo
'evangelizando' con su prédica de libertad a cualquier precio.
'No programo más. Trabajar en la parte gerencial y política del movimiento es
todo lo que puedo hacer. Programar es más divertido, pero la única forma de
hacerlo sería dejando de lado las otras responsabilidades.
Es el liderazgo del movimiento lo que hago. A veces debo manejar a la gente
que se encuentra en proyectos nuevos, a veces hago el reclutamiento, y en
oportunidades negociaciones con otros proyectos, o persuado a la gente para
que cambie sus licencias'.
Polémicas y Enfrentamientos
Las opiniones tan duras contra todo aquello que no sea software libre, han
llevado a Stallman a encarar fervientes enfrentamientos contra muchas
organizaciones y personas.
Entre los casos más famosos, se encuentra el boicot iniciado contra la empresa
`Amazon.com` (http://www.fsf.org/philosophy/amazon.html). El mismo se debe
al uso agresivo de las patentes contra su competidor directo 'Barnes & Noble' .
Lo que realmente quería Stallman era que el software no cuadre dentro de la
ley de patentes de Estados Unidos.
Sucede que al patentar algoritmos o técnicas de programación, se impide que
puedan ser utilizadas por los desarrolladores de software de manera libre. La
forma de poder emplearlas sería pagando a los titulares de la patente. Esta
práctica se transforma en prohibitiva para los desarrolladores de software libre,
quienes muchas veces son voluntarios.
En marzo de 2002, amazon.com y Barnes & Noble llegaron a un acuerdo. Pero
como los términos del mismo no fueron dados a conocer, desde el proyecto
GNU y la FSF siguen incitando al boicot contra amazon.com.
Otro de sus fuertes enfrentamientos fue contra KDE. La contienda contra el
entorno de escritorio comenzó en el año '97 cuando nació el proyecto. El
problema era que KDE incluía las bibliotecas17 QT de la empresa Trolltech, que
no estaban lanzadas bajo la licencia GPL. De esta forma, al no ser considerado
software completamente libre, Stallman y la mayoría de los puristas se oponían
a la inclusión de KDE en las distribuciones de GNU/Linux. Este hecho
desencadenó el lanzamiento por parte de Red Hat del proyecto GNOME, como
alternativa totalmente libre frente a KDE.
La disputa culminó en el año 2000, cuando la empresa Trolltech lanzó sus
bibliotecas bajo la licencia LGPL18. Aunque es una licencia más leve que la
GPL, Stallman y su gente no pudieron continuar con el enfrentamiento ya que
la LGPL es una licencia creada por la FSF especialmente para bibliotecas.
Hoy en día KDE y GNOME se incluyen en la mayoría de las distribuciones de
GNU/Linux y compiten cabeza a cabeza por el dominio de los escritorios.
La última iniciativa de Stallman fue en enero de 2002 al publicar un escrito
criticando a los correos electrónicos con archivos adjuntos en formato de
Microsoft Word (http://www.gnu.org/philosophy/nowordattachments.es.html).
Especialmente se refirió a ellos como 'molestos' y que impiden que la gente se
pase al software libre. A lo que apunta con su escrito es que si alguien recibe
un archivo adjunto en formato de Word (.doc), que pida al remitente que
reconsidere su manera de hacer las cosas.
'La mayoría de los usuarios de computadoras utiliza Microsoft Word. Eso es
desafortunado para ellos, ya que no pueden estudiarlo, cambiarlo y
redistribuirlo. Y como Microsoft modifica el formato con cada nueva versión, sus
usuarios están encerrados en un sistema que los insta a comprar cada
actualización, ya sea que necesiten un cambio o no'.
A modo de ejemplo, Stallman incluye dos mensajes o respuestas enlatadas19
para que el usuario pueda enviarlas rápidamente cada vez que sea necesario.
También explica que hay muchos que al recibir un archivo de Word tratan de
abrirlo de alguna manera para leer el contenido y expresa:
'Arreglártelas para leer el archivo es un síntoma de una enfermedad crónica.
Para curar la enfermedad, debemos convencer a las personas de que no
envíen o publiquen documentos en formato de Word'.
Esta iniciativa tuvo bastantes repercusiones en el mundo informático. En
nuestro país, salió publicada una nota en el matutino Clarín bajo el título “Los
pesados y a veces peligrosos archivos adjuntos de los emails” (Lunes 25 de
marzo de 2002 pág 33). En ella se hace mención al escrito publicado por el
gurú del software libre.
Sin dudas es muy importante la llegada al diario de mayor tirada del país de las
ideas de Stallman. Esto le permite conseguir despertar el interés en aquellos
que ni siquiera conocen las bases de su movimiento.
La realidad indica que lo expresado por Stallman en este documento es cierto.
Mucha gente y organismos publican información o exigen recibirla en
formato de Word.
Obligan a la gente a utilizar Word para leer el documento20.
Los archivos de Word pueden transportar algún virus y también
información privada sobre su autor.
La máxima aspiración de Stallman es que la premisa de “no envíe formato de
Word” consiga el estatus de netiquette. El tiempo dirá si pudo lograrlo o no.
Pero sin dudas que el esfuerzo vale la pena.
Esta sección ha recorrido la vasta trayectoria de una persona más que
influyente dentro de la historia del software. Lamentablemente, no todo el
mundo está al tanto de los logros que se han alcanzado gracias al aporte de
Stallman. Quizá su carácter fuerte y personalidad conflictiva, le han impedido
lograr una mayor fama o reconocimiento.
Pueden resultar chocantes en muchas oportunidades las opiniones de
Stallman. A su vez, esa actitud confrontativa y de aislamiento son las que
desencadenaron la división que se ha producido en los últimos años entre el
Open Source y el Software Libre.
Aún así, a Richard Stallman hay que reconocerle varios logros. Obviamente, el
más importante es el de la creación del proyecto GNU ya que es el que engloba
al total de sus aportes. Le sigue en importancia, la creación de la licencia GNU
GPL. Aunque recibió el consejo de importantes juristas para su elaboración, la
idea de la misma fue suya. Y puede reconocerse fácilmente la influencia de sus
creencias en el texto de la misma.
También resultan destacables sus logros en el campo del desarrollo de
software. Las herramientas que desarrolló, permitieron que un gran número de
personas se sumen al proyecto y contribuyan a su crecimiento:
GNU C Compiler (GCC) EL compilador portable que fue diseñado
para soportar diversas arquitecturas y múltiples lenguajes. Actualmente
son 30 las arquitecturas diferentes y 7 los lenguajes soportados .
GNU Debugger (GDB) Un debugger flexible y poderoso que
continúa siendo utilizado.
GNU Emacs editor de textos extensible. Esta característica le ha
permitido transformarse en navegador web, cliente de correo y muchas
cosas más. Stallman recibió la distinción “Grace Hopper Award” de la
Association for Computing Machinery en 1991 por esta herramienta.
Por todo lo expuesto, valga el reconocimiento para este ser humano que ha
realizado un aporte de gran valor al mundo de la informática. Richard Stallman
contribuyó al desarrollo de una plataforma donde el conocimiento se comparte
y lo único que se pide a cambio de ello es que no se corte esa cadena para
que los nuevos conocimientos estén al alcance de los demás.
13ITS: Sistema de Tiempo compartido Incompatible. Sistema operativo desarrollado por los
hackers del MIT especialmente para la DEC PDP 7. Estaba implementado en lenguaje de
máquina y ensamblador, lo que al cambiar el modelo hubiera implicado la necesidad de
reescribirlo.
14 En aquellos tiempos no se había planteado aún la controversia con el término libre. El
problema es que en la lengua inglesa el término "free" se usa tanto para libre como para gratis.
15 Impresora Xerox
: Xerox le entregó al laboratorio de IA una impresora muy veloz, la cual
bastante a menudo tenía problemas. Cuando Stallman y sus compañeros hackers intentaron
modificar el controlador de la misma, se encontraron con que Xerox se negó a entregarles el
código fuente con lo que no pudieron solucionar los problemas que tenía la fotocopiadora
devenida en impresora láser.
16El sistema UNIX era el más utilizado en aquel entonces (Años 198384).
17 Bibliotecas
: Mucha bibliografía hace referencia a Librerías. Es un error ya que la forma
correcta de traducir el término Library al castellano es biblioteca.
18 LGPL
: Lesser General Public License. Esta licencia será analizada en profundidad en la
sección especialmente dedicada a las licencias de software.
19Las mismas se encuentran en el Anexo I.
20Hoy en día existen herramientas como OpenOffice y AbiWord que pueden leer los formatos
de MS Office y obtener el texto. Aunque no funcionan siempre perfectamente, son de gran
utilidad.
4. Licencias
Introducción
Con el marco legal actual la licencia bajo la que se distribuye un programa
delimita exactamente los derechos que tienen sobre él sus usuarios. Por
ejemplo, en la mayoría de los programas propietarios la licencia priva al usuario
de los derechos de copia, modificación, préstamo, alquiler, uso en varias
máquinas, etc. De hecho, las licencias suelen especificar que la propietaria del
programa es la empresa creadora del mismo, la cual simplemente vende
derechos restringidos para el uso del programa.
En el mundo del software libre, la licencia bajo la que se distribuye un programa
también es de gran importancia. Normalmente, las condiciones de las licencias
de software libre son el resultado de un compromiso entre varios objetivos
hasta cierto punto contrapuestos. Entre ellos, pueden citarse los siguientes:
Garantizar algunas libertades básicas (de redistribución, de
modificación, de uso) a los usuarios.
Asegurar algunas condiciones impuestas por los autores (cita de su
nombre en trabajos derivados, etc.).
Procurar que los trabajos derivados sean también software libre.
Los autores pueden elegir proteger su software con distintas licencias según el
grado con que quieran cumplir cada uno de estos objetivos, y los detalles que
quieran asegurar. De hecho, el autor de un programa suele elegir con mucho
cuidado la licencia bajo la que lo distribuye. Por otro lado, los usuarios y
especialmente quienes redistribuyen o modifiquen el software, deben estudiar
con cuidado la licencia del mismo.
En realidad, casi todo el software libre usa alguna de las licencias más
habituales (GPL, LGPL, estilo BSD, estilo Netscape). El objetivo de esta
sección es analizar las licencias bajo las que se distribuye habitualmente el
software libre.
Dominio Público
Muchas veces se comete el error conceptual de suponer que el software libre
es de dominio público. Esto sucede simplemente porque la idea de software
libre o Código Fuente Abierto es confusa para mucha gente.
Tanto el software libre como el de Código Fuente Abierto21 poseen los derechos
de autor reservados, y están protegidos por una licencia. Solo que éstas
licencias dan a la gente más derechos de los que están acostumbrados a tener.
Un programa de dominio público es aquel al cual el autor ha renunciado sus
derechos. No puede decirse que vengan con una licencia; el programa no tiene
propietario y existe la posibilidad de usarse como se desee. Cualquiera puede
relicenciar un programa de dominio público, o remover el nombre del autor y
tratarlo como un trabajo propio.
Este es el concepto de dominio público. Como se verá a continuación dista
bastante de lo expresado por las licencias que se aplican al software libre.
GNU GPL
Versión 2 (Junio 1991)
Ver Licencia Completa
en http://www.gnu.org/copyleft/gpl.html
La controvertida Licencia Pública General GNU será analizada en primer lugar.
Sin dudas junto con la licencia estilo BSD, son las más conocidas en el mundo
del software libre. Como todo lo que proviene de la FSF y por añadidura de
Richard Stallman, esta licencia no escapa del centro de la polémica.
Algunos se refieren a la GNU GPL como de naturaleza viral. Defienden esta
postura indicando que la misma infecta a los programas con el virus de la
libertad. Esto es porque un programa que está protegido por la GPL no puede
transformarse en software propietario. Esta principal falencia que remarcan los
que la critican, es la virtud más importante que defienden los que están a su
favor. El concepto que hay detrás de esta licencia es el de copyleft.
Copyleft deriva de un juego de palabras que representan lo contrario de
copyright. De hecho, el copyleft incluye la registración de los derechos de autor.
Este concepto fue acuñado en la FSF y se encuentra enmarcado por la GNU
GPL. El proceso consiste en reservar los derechos sobre un programa y luego
añadirle los términos de distribución (por ejemplo la GPL). Estos términos son
el instrumento legal que le dan a todo el mundo los derechos de utilizar,
modificar y redistribuir el código fuente del programa o cualquier programa
derivado del mismo. Todo esto es posible si los términos de distribución no son
cambiados.
En el primer párrafo de la licencia, queda bien clara la intención de la misma,
que es heredada directamente de los ideales pregonados por Stallman.
'Las licencias para la mayoría de los programas se crean para quitarte tu
libertad. En cambio, la GNU GPL pretende garantizar tu libertad de compartir y
modificar software libre ; Asegurar que el software sea libre para todos los que
lo usan'.
Esta licencia se aplica a cualquier programa u otro trabajo que contenga un
aviso del titular del derecho de autor que puede distribuirse bajo los términos
de la Licencia Pública General GNU.
Actos Permitidos
Distribuir copias de software libre.
Modificar software libre y redistribuirlo.
Cobrar por el acto de transferir una copia.
Ofrecer garantía a cambio de un canon.
No publicar las modificaciones mientras se usen en forma privada.
Esto incluye a las empresas mientras mantengan los cambios dentro de
su ámbito.
Actos NO Permitidos
Imponer nuevas restricciones a la licencia.
Copiar, modificar, sublicenciar o distribuir el programa de una manera
distinta de la expresamente utilizada por la licencia.
Detalles Importantes
No se ofrece garantía sobre el funcionamiento correcto del software
cubierto por la licencia.
Si se modifica el software y se lo redistribuye, se debe expresar que
es una modificación del original para no afectar la reputación del creador.
Con el término programa, la misma se refiere a cualquier programa o
trabajo basado en el programa. Esto quiere decir el programa o una
porción del mismo; ya sea una copia fiel o con modificaciones y/o
traducciones. ( la licencia considera al acto de traducir un programa
como una modificación).
El mero agregado de otro trabajo no basado en el programa en un
medio de almacenamiento para su distribución, no implica que el otro
trabajo deba ser lanzado bajo la GPL.
Para un ejecutable, el código fuente completo significa el código
fuente de todos los módulos que contiene, más los archivos con la
configuración de la interfase y los scripts22 utilizados para controlar la
compilación e instalación. No se debe incluir el código fuente del sistema
operativo donde el programa se ejecuta.
Al no firmarse la licencia, nadie está obligado a aceptarla. Pero nada
más que la misma le da permiso al usuario de modificar o distribuir un
programa o sus trabajos derivados. Estas acciones están prohibidas por
la ley de derechos de autor si no se acepta la licencia. De esta forma,
quien modifique o distribuya un programa protegido por esta licencia,
está indicando su aceptación de la misma.
Si como consecuencia de una resolución judicial, al autor se le
imponen condiciones que contradicen las de la licencia, las mismas no lo
excusan de las condiciones de la GPL. Si no puede distribuirlo de una
manera que satisfaga ambas obligaciones, entonces no debe distribuir el
programa.
La distribución del código fuente del programa debe ser a través de un
medio físico, no es suficiente con publicarlo en un servidor FTP.
Las traducciones de la GPL son consideradas versiones no oficiales.
En términos legales, la versión original en inglés es la que especifica los
términos de distribución. La razón por la que la FSF no las aprueba
como oficialmente válidas es porque si poseen un error, los resultados
podrían ser desastrosos para la comunidad de software libre. Mientras
no sean oficiales, no pueden causar daños y ayudan a que más gente
entienda la GPL.
La GPL permite que los usuarios publiquen sus versiones
modificadas. Este es un aspecto crucial ya que los usuarios deben ser
libres de cooperar. Es absolutamente esencial permitir a los usuarios
ayudarse mutuamente y compartir las reparaciones y mejoras
efectuadas al software.
Hubo quienes propusieron alternativas a la GPL que requerían que las
versiones modificadas pasen por el autor original. Mientras que el autor se
mantenga al día con las necesidades de los usuarios, esto funciona. Pero si el
autor no atiende las necesidades de la comunidad usuaria, este esquema se
derrumba.
A primera vista, puede parecer que la GPL no permite la convivencia con un
intento comercial relacionado con el software libre. El modelo tradicional de
ganar dinero a través de la venta de copias solamente no es posible. Pero la
GPL puede ser extraordinariamente efectiva para establecer una plataforma
que desaliente la creación de nuevas plataformas competitivas. Se establece
un único campo donde todas compiten en el mismo nivel y donde ser el primero
tiene muchos beneficios.
Un ejemplo de esto es la empresa Cygnus Solutions. Cygnus generó durante
muchos años cambios al compilador gcc23, entre ellos portarlo a nuevos tipos
de arquitecturas de hardware. La gran mayoría de sus trabajos cumplen con la
GPL, y luego se incluían a la distribución de gcc. Cygnus cobra por el esfuerzo
involucrado en la portación y mantenimiento a sus clientes, pero no por el
código fuente.
Si una empresa intenta competir a la par de Cygnus, se verá forzada a
redistribuir su trabajo. De esta forma se beneficia en primer lugar Cygnus ya
que la competencia no puede diferenciarse por la plataforma tecnológica. El
cliente elige por el nivel de servicio. Por otro lado también se beneficia toda la
comunidad de software libre que recibe las mejoras al compilador tan utilizado.
GNU LGPL
Versión 2.1 (Febrero 1999)
en http://www.gnu.org/licenses/lgpl.html
En un principio esta licencia era llamada Library GPL y llegó hasta la versión 2.
Luego se le cambió el nombre (pero mantuvo las siglas) por Lesser GPL. Su
primer versión (aquí comentada) es la 2.1.
Esta licencia se aplica a unos paquetes de software especiales llamados
bibliotecas24. En la licencia se aclara que cualquiera puede usarla, pero sugiere
que se utilice la GPL y que solo se recurra a la LGPL en casos estratégicos.
En el preámbulo indica que la mayoría del software GNU, incluyendo algunas
bibliotecas (como Readline), están cubiertas por la GPL. La LGPL se ha creado
para permitir que se enlacen estas bibliotecas con programas no libres.
Cuando un programa se enlaza con una biblioteca, ya sea estáticamente o
mediante una biblioteca compartida (dinámica), la combinación de ambos se
considera, legalmente hablando, un trabajo combinado, derivado de la
biblioteca original. La GPL permite ese enlace solo si ambos cumplen con su
criterio de libertad.
Por su parte la LGPL posee un criterio de libertad más laxo, de ahí su nombre:
Lesser. A su vez, provee menos ventajas para los desarrolladores de software
libre, sobre programas no libres de la competencia. Pero como se dijo
anteriormente, es posible que esta licencia represente en algunas ocasiones
una ventaja estratégica.
Por ejemplo, en el caso de que hubiera una necesidad de inculcar el uso
masivo de cierta biblioteca y convertirla en un estándar de facto. Para lograr
este propósito los programadores no libres deberían poder usar la biblioteca.
Con la GPL esto no sería posible.
La LGPL se usa generalmente cuando una biblioteca libre hace la misma tarea
que otras no libres. En este caso, no hay mucho que se gane si la biblioteca
está cubierta por la GPL. La biblioteca del lenguaje C (glibc) que proveen
distintos sistemas GNU/Linux es un ejemplo de software protegido por la LGPL.
Sino, GNU/Linux solo podría ser utilizado por desarrolladores de software
libre.
Hay que prestar atención a la diferencia entre un trabajo basado en una
biblioteca y un trabajo que usa la biblioteca. El primero contiene código
derivado de la biblioteca, mientras que el otro debe enlazarse con la biblioteca
para ejecutarse. Un trabajo basado en la biblioteca encuadra en el derecho de
autor ya que es un trabajo que contiene la biblioteca o una porción de ella
(copia fiel o con modificaciones y/o traducido a otro idioma).
Permite copiar y/o distribuir copias de la biblioteca.
Se puede modificar la biblioteca o una porción de ella y formar un
trabajo basado en la misma si:
El trabajo modificado es una biblioteca de software.
Los archivos modificados indican en que fecha se
modificaron.
El trabajo se licencia bajo LGPL.
Una funcionalidad en la biblioteca modificada hace
referencia a una función o tabla de datos que es provista
por un programa que usa esta facilidad, la misma debe
mantenerse operativa aunque el programa no lo provea
alguna vez.
Una biblioteca licenciada bajo LGPL puede convertirse a GPL en
cualquier momento. Cuando esto sucede, no hay posibilidad de volver
atrás.
Un programa que no contenga ninguna porción de la biblioteca, pero
que ha sido diseñado para trabajar con la biblioteca al ser enlazado o
compilado con ella, se lo considera un trabajo que usa la biblioteca. Este
trabajo no es derivado de la misma por lo que escapa a los alcances de
la licencia. El programa binario/ejecutable queda cubierto por la LGPL,
pero el código fuente del programa original no se ve afectado y conserva
su licencia.
Estos aspectos son los que diferencian a la LGPL de la GPL. A su vez el resto
de los detalles descriptos para la GPL se aplican también a la LGPL.
LICENCIA ESTILO BSD
en http://www.opensource.org/licenses/bsdlicense.php
Dentro del mundo del software libre, las licencias estilo BSD han sido muy
importantes y muy utilizadas. Su origen se remonta a las raíces del movimiento.
Esta licencia fue la primera que se ideó para distribuir software libre de las
entregas BSD25. Estas entregas fueron la forma en que el CSRG distribuía su
trabajo alrededor del sistema operativo UNIX. La primera vez que se utilizó esta
licencia fue en la distribución Networking Release 1. En la actualidad, se sigue
utilizando como licencia para varios proyectos. Entre los más importantes se
encuentran:
Los sistemas operativos: FreeBSD, NetBSD y OpenBSD.
El servidor web Apache.
El sistema de bases de datos PostgreSQL.
La principal diferencia de las licencias estilo BSD y las de la familia de
la GPL es que los cambios efectuados pueden publicarse en forma
binaria/ejecutable sin distribuir el código fuente.
No se entrega ninguna garantía sobre el correcto funcionamiento del
software.
Redistribuciones del código fuente deben mantener los avisos de
derecho de autor, la lista de condiciones y la negación de garantía.
La cláusula de la discordia.
La misma figuraba en las antiguas versiones de la licencia. Expresaba que
cualquier material publicitario que mencione características o el uso del
software debía mostrar la siguiente leyenda:
“This product includes software developed by the University of California,
Berkley and its contributors ”26
El problema que surgió con esta cláusula es que mucha gente reemplazaba en
la licencia Universidad de California por sus nombres o el de sus instituciones.
El resultado es que el programa tenía varios mensajes distintos que mostrar. Al
momento de juntar muchos de estos programas en un sistema operativo, la
cantidad de nombres a mencionar se convertía en un serio problema.
En los últimos años, muchos proyectos que utilizan esta licencia fueron
removiendo la cláusula, hasta que por último la Universidad de California
aceptó que era necesario quitarla de la licencia original. Hoy en día,
prácticamente no se usa más esta cláusula.
Desde una perspectiva de negocio, esta es la mejor licencia para involucrarse
en un proyecto existente, ya que no hay restricciones en cuanto al futuro o su
redistribución. Cualquiera puede mezclar y unir este software con su software
propietario y lanzar lo que quiera. Esta es una de las razones por la que se
seleccionó esta licencia en el proyecto Apache.
Este tipo de licencia es ideal para promover el uso de código como cuerpo de
referencia. Puede ser la implementación de un protocolo o un servicio común.
En Apache se la seleccionó para mantener HTTP como un protocolo estándar y
multipartito. Este grado de apertura trae aparejado riesgos. No hay ningún
incentivo para que las compañías que modifican el código lo devuelvan al resto
de la gente.
El hecho que la licencia BSD original deja hacer prácticamente cualquier cosa
es porque el software que en principio cubría esta licencia (producido por el
CSRG) estaba financiado por el gobierno de los Estados Unidos. Dado que el
software había sido pagado por los impuestos, se permitía a la gente hacer con
él lo que quisiera.
Puede argumentarse que esta licencia asegura “verdadero”software libre, en el
sentido que el usuario tiene libertad ilimitada con respecto al software, y que
puede decidir incluso redistribuirlo como no libre. Otras opiniones están
orientadas a destacar que este tipo de licencia no contribuye al desarrollo de
más software libre.
NPL & MPL
Versión 1.1
en http://www.opensource.org/licenses/mozilla1.1.php
La Netscape Public License fue desarrollada por Netscape cuando lanzó como
Código Fuente Abierto a su producto Netscape Navigator. Actualmente esta
versión del navegador se la conoce como Mozilla.
Varios hackers famosos dentro del movimiento de Código Fuente Abierto, entre
ellos Linus Torvalds, Bruce Perens y Eric Raymond colaboraron como
consultores adhonorem durante el desarrollo de la licencia. Aunque intentaron
persuadir a Netscape para que utilizase la GPL, su esfuerzo fue en vano.
Terminaron lanzándolo bajo la NPL que cumple con la Definición de Código
Fuente Abierto27.
Fue la primer licencia nueva luego de muchos años, que se encargaba de
algunos puntos que no fueron tenidos en cuenta por las licencias BSD y GNU.
En el espectro de las licencias de software libre se la puede considerar
adyacente a la licencia estilo BSD.
Antes de lanzar su código fuente al público, Netscape liberó una versión beta
de su licencia, el 5 de marzo de 1998, en un grupo de noticias especialmente
creado para opinar sobre la misma (netscape.public.mozilla.license). Esto
despertó gran entusiasmo y derivó en propuestas varias para modificar algunos
términos de la NPL.
La sección de la licencia que fue más criticada es la que le confiere a Netscape
privilegios especiales como es la posibilidad de relicenciar modificaciones
hechas por cualquiera al código. También pueden tomar estas modificaciones,
mejorarlas y negarse a contribuirlas al proyecto.
Esta previsión fue creada porque Netscape tenía contratos con las compañías
que proveían módulos que estaban incluidos en el navegador (en total 75
módulos). Este aspecto de la licencia hizo suponer que la misma no sería
aceptada finalmente por la comunidad de Código Fuente Abierto.
La gente de Netscape tuvo en cuenta el feedback recibido y para solucionar
este problema se creó la Mozilla Public License. Ambas licencias son idénticas,
salvo que la NPL mantiene las cláusulas que protegen los derechos de
Netscape.
El código fuente de Netscape Navigator fue liberado originalmente bajo la NPL
y todas la modificaciones deben lanzarse bajo la misma licencia. Pero si se
desarrollan nuevos módulos de código, pueden lanzarse bajo la licencia MPL o
alguna compatible (obviamente la GPL no lo es).
Detalles Importantes de la MPL
Los cambios deben volver al proyecto.
Cualquier individuo o compañía que contribuye al código del proyecto
debe renunciar a cualquier derecho de patentamiento sobre el código
fuente.
Licencia del MIT Sistema X Window
Versión 11 Entrega 6 (X11R6 Año 1996)
en http://www.opensource.org/licenses/mitlicense.php
Esta licencia otorga permiso, libre de cargo a cualquier persona que obtenga
una copia de este software, de trabajar con el mismo sin restricciones a los
derechos de uso, copia, modificación, publicación, distribución, sublicenciar y la
venta de copias.
Todo esto es posible si se cumple con la condición de incluir una nota con el
programa donde se desliga al Consorcio X de cualquier problema que pueda
surgir con el uso del software.
La licencia no permite que se use el nombre del Consorcio X para realizar
publicidad alguna sin expresa autorización del mismo.
Resumen sobre las licencias estudiadas
Contiene
Modificaciones
privilegios
Puede mezclarse pueden tornarse Puede
especiales para el
Licencia con software no privadas y no relicenciarse por
titular de los
libre retornarse a los cualquiera
derechos de autor
demás
sobre los cambios
GPL
LGPL X
BSD X X
NPL X X X
MPL X X
MIT X X X
Dominio
X X X
Público
21La Iniciativa código fuente abierto será analizada en la sección 5.
22 Script: Programa que por lo general es interpretado, con lo que se distribuye en modo
fuente, no binario.
23Cygnus, luego se abrió del desarrollo del gcc y comenzó a distribuir su propio compilador
llamado egcs. Ambos proyectos se unieron en la versión 2.95 de Abril de 1999. Se renombró,
egcs como gcc y Cygnus quedó a la cabeza del mantenimiento.
24 Biblioteca:
Agrupamiento o colección de funciones de software y/o datos preparados para ser
enlazados convenientemente con programas para formar ejecutables.
25 Entregas BSD
: Este tema se explicó con detalle en la sección 1.
26Este producto incluye software desarrollado por la Universidad de California, Berkley y sus
contribuyentes.
27 Definición de Código Abierto:
Tema ampliado en la sección dedicada al Open Source.
5. Iniciativa Código Fuente Abierto
Introducción
La etiqueta “Open Source” surgió de una reunión estratégica mantenida el día 3
de febrero de 1998 en Palo Alto, California. Entre los presentes estaban:
 Eric Raymond (ver sección 6).
 Bruce Perens (líder del grupo Debian).
 John “Maddog”Hall (de la organización
Linux International).
 Sam Ockman (grupo de usuarios de
Linux de Sillicon Valley).
Esta reunión tenía como intención reaccionar frente al plan de Netscape de
liberar el código fuente de su navegador 'Netscape Navigator'.
Se dieron cuenta que era la oportunidad de dejar de lado la actitud
confrontativa que se había asociado con el software libre en el pasado y
trataron de vender su idea desde un punto de vista más pragmático y orientado
al mundo de los negocios.
La definición de lo que era Open Source o Código Fuente Abierto procedía del
proyecto Debian. Uno de los líderes de ese grupo, Bruce Perens, redactó lo que
se conoce como “Debian Free Software Guidelines”
(http://www.debian.org/social_contract.html) 28. La definición de lo que era
aceptable como no, era suficientemente amplia como para incluir la GPL, las
licencias estilo BSD, y algunas otras como la del MITConsorcio X y la licencia
Artística (http://www.opensource.org/licenses/artisticlicense.php) 29. Estos
lineamientos fueron refinados con el aporte de los voluntarios del grupo Debian.
Cuando se decidió utilizarla como Definición de Código Fuente Abierto, lo único
que hubo que hacer fue quitar las referencias específicas a Debian.
La idea básica detrás de Código Fuente Abierto es simple: cuando un
programador puede leer, redistribuir y modificar el código fuente de un
programa, el mismo evoluciona. La gente (voluntarios) lo mejora, lo adapta y
corrige los errores. Esto puede suceder a una velocidad mucho mayor a la del
desarrollo del software comercial convencional. Este proceso evolutivo produce
mejor software que el modelo tradicional.
En realidad, todas estas ideas que conforman las ventajas del modelo Open
Source provienen de un escrito publicado por Eric Raymond en el año 1997. El
mismo, titulado “La catedral y el Bazar”, será analizado más adelante. Pero
desde ya es importante recalcar la influencia de éste sobre el nacimiento del
modelo Open Source.
Definición de Código Fuente Abierto
versión 1.9
A continuación se detalla el contenido de la Definición de Código Fuente
Abierto. Es necesario para poder luego efectuar una comparación frente al
movimiento liderado por Richard Stallman.
Introducción.
Código Fuente Abierto no significa el mero acceso al código fuente. Los
términos para la distribución del software de Código Fuente Abierto tienen que
cumplir con el siguiente criterio:
1. Redistribución Libre:
La licencia no deberá impedir la venta o el ofrecimiento del software
como un componente de una distribución de software que contenga
programas de muchas fuentes distintas a ninguna parte. La licencia no
deberá requerir el pago de los derechos de autor u otra tasa por dicha
venta.
Esta cláusula apunta a que la licencia debe permitir que el software se incluya
en distribuciones (por ejemplo, una distribución de GNU/Linux, o los
compilados que aparecen en las revistas). A su vez tampoco se debe exigir por
parte del autor un pago por incluir el paquete en una distribución.
2. Código Fuente:
El programa tiene que incluir el código fuente y tiene que permitir la
distribución tanto en código fuente, como en forma compilada. Si alguna
forma del producto no es distribuida con el código fuente, tiene que
haber un medio bien publicado de obtener el código fuente por no más
que un costo razonable de reproducción preferentemente, una descarga
a través de Internet sin cargo. El código fuente tiene que ser la forma
preferida en la cual un programador modificaría el programa. El código
fuente deliberadamente ofuscado no está permitido. Las formas
intermedias tales como la salida de un prepocesador o un intérprete no
están permitidas.
Como idea es muy interesante, pero en la práctica es difícil de llevar a cabo. Es
muy subjetivo el término código fuente ofuscado. Lo que sí queda claro es que
las salidas intermedias no son aceptadas, por ejemplo un bytecode de Java.
Tendrían que entregarse los archivos *.java y no los *.class.
3. Trabajos Derivados:
La licencia tiene que permitir modificaciones y trabajos derivados, y tiene
que permitir que ellos sean distribuidos bajo los términos de la licencia
de software original.
Esta fue la forma que encontraron para unificar las posturas que antes eran
opuestas entre la licencia GPL y la estilo BSD. Esto permite una aceptación de
muchas más licencias por sobre el criterio GNU que prácticamente acepta la
GPL y nada más.
4. Integridad del Código Fuente del autor:
La licencia puede impedir que el código fuente sea distribuido en forma
modificada solamente si la licencia permite la distribución de archivos
parches con el código fuente con el objetivo de modificar el programa en
tiempo de construcción. La licencia tiene que permitir explícitamente la
distribución del software construido a partir del código fuente modificado.
La licencia puede requerir que los trabajos derivados tengan un nombre
distinto o un número de versión distinto del software original.
Apunta a que los usuarios sepan quién es el responsable del software que
usan, no por una cuestión de garantía ya que ninguno de estos programas la
traen, sino porque la reputación del autor original puede verse afectada por
acciones de otros individuos.
5. No a la discriminación de personas o grupos:
La licencia no tiene que discriminar a ninguna persona o grupos de
personas.
6. No a la discriminación de campos laborales:
La licencia no tiene que restringir a nadie que haga uso del programa en
un campo laboral específico. Por ejemplo, no puede impedir que el
programa sea usado en un negocio, o que sea usado para una
investigación científica.
La principal idea detrás de esta cláusula es permitir que la gente de todos los
ámbitos utilice software de Código Fuente Abierto. Con esta idea se establece
una clara diferencia con el software llamado shareware, que en general prohíbe
el uso del mismo para fines comerciales.
7. Distribución de la licencia:
Los derechos adjuntos al programa tienen que aplicarse a todos
aquellos que reciben el programa sin la necesidad de ejecutar una
licencia adicional para estas partes.
Apunta a que no se intente cortar la distribución del software al agregar otra
licencia como podría ser un acuerdo de no divulgación.
8. La licencia no tiene que ser específica de un producto.:
Los derechos adjuntos al programa no tienen que depender de que el
mismo forme parte de una distribución particular de software. Si el
programa es extraído de esa distribución y es usado o distribuido de
acuerdo a los términos de la licencia del programa, todas las partes a las
que el programa sea redistribuido deben tener los mismos derechos que
son garantizados en conjunto con la distribución original del software.
Esta cláusula intenta evitar posibles trampas que se pueden incluir en otras
licencias para anular la licencia original.
9. La licencia no tiene que restringir a otro software:
La licencia no tiene que colocar restricciones en otro programa que es
distribuido con el software licenciado. Por ejemplo, la licencia no tiene
que insistir en que todos los otros programas distribuidos en el mismo
medio tengan que ser software de Código Fuente Abierto.
Se complementa con la cláusula 1, ya que en aquella se busca que la licencia
permita que el programa pueda ofrecerse en distribuciones de software y esta
apunta a que la licencia no debe imponer restricciones sobre los demás
paquetes de la distribución.
El primer gran objetivo por el cual nació la Iniciativa Código Fuente Abierto se
cumplió con la publicación de esta Definición. El segundo paso tenía como
intención registrar como marca el término “Open Source”. Pero como el mismo
es descriptivo, no fue aceptado como marca registrada. Entonces para poder
indicar el software que cumple con la Definición de Código Fuente Abierto, se
registró la etiqueta “OSI Certified” (Certificado por la OSI). Esta certificación se
aplica al software que se distribuye bajo una licencia que cumple con la
Definición de Código Fuente Abierto.
En el sitio web de la Iniciativa Código Fuente Abierto se mantiene una lista con
las licencias que han sido aprobadas por el comité de la OSI y la comunidad en
general. En la actualidad (junio 2002) esta lista enumera 32 licencias. Entre
ellas están las más conocidas como la GNU GPL, la BSD, MPL y otras no tan
utilizadas.
La intención detrás de esto, es que cualquiera que distribuye su software bajo
algunas de estas licencias, puede decir que su programa es “Software de
Código Fuente Abierto certificado por la OSI”.
Diferencias entre Código Fuente Abierto y Software Libre
No se puede decir que sean dos movimientos opuestos entre sí. Lo que queda
claro, es que ambos persiguen objetivos diferentes (pero no contrapuestos).
Por un lado está la Free Software Foundation y su defensa de la libertad a
cualquier precio. Por el otro, tenemos a la incipiente Iniciativa Código Fuente
Abierto que ha ganado muchos adeptos en sus cortos cuatro años de vida.
Desde la OSI, expresan que ellos se desprendieron del software libre porque
consideraban que esa postura tan radical (pseudo comunista) asustaba a los
hombres de negocios. Su intención no es solo que los programadores lancen
proyectos certificados por la OSI, sino que grandes compañías se sumen a la
iniciativa. En realidad, siempre han tratado de enfriar un poco el enfrentamiento
con el software libre. De hecho, siempre aclaran que muchos de sus principios
son heredados de los preceptos de Stallman. También suelen referirse a su
movimiento como más orientado al marketing y a generar una imagen en la
gente sobre las características técnicas de los productos de Código Fuente
Abierto; más que recalcar los principios filosóficos que persiguen.
A lo largo de estos últimos cuatro años, Stallman desde su posición de “Sumo
Pontífice” del movimiento de Software Libre; ha ido cambiando su veredicto
acerca de la Iniciativa Código Fuente Abierto. En un principio criticó duramente
al Open Source y lo descalificó en reiteradas ocasiones. Con el correr de los
años y dado que el movimiento Open Source comenzó a ganar fama y
reconocimiento destronando al software libre, Stallman tomó otra postura frente
al mismo.
Sin dudas que nunca fue de su agrado por el hecho que hasta ese momento su
Fundación para el Software Libre era la organización más importante y sus
ideales eran los únicos que valían como contrapartida al modelo de software
propietario. Al aparecer este movimiento que se enfrentaba al software
propietario de una manera distinta a la propuesta por él, no le gustó para nada
y comenzó a criticarlo. La forma de hacerlo era indicando las debilidades del
mismo en cuanto a los principios y valores perseguidos.
'La enseñanza acerca de la libertad a los nuevos usuarios se hizo más difícil en
1998, cuando parte de la comunidad decidió dejar de usar el término software
libre y usar “Open Source Software” en su lugar. Algunos de los que
favorecieron este término tenían como objetivo evitar la confusión de free con
gratis; una meta válida. Otros, sin embargo, apuntaban a apartar el espíritu de
principios que ha motivado el movimiento por el software libre y el proyecto
GNU, para resultar así más atractivos a los ejecutivos y usuarios comerciales,
muchos de los cuales sostienen una ideología que pone las ganancias por
encima de la libertad, de la comunidad y los principios'.
Esto fue expresado por Richard Stallman en el libro Open Sources en el año
1999. Es una de las primeras declaraciones públicas opinando sobre el otro
movimiento. Aquí puede entenderse claramente su intención de diferenciar los
movimientos por cuestiones principalmente filosóficas. Casi simultáneamente,
hizo una declaración al sitio de información “Linux Today” (17/8/99) donde
remarcaba otro aspecto que los diferencia:
'La distinción es que la filosofía de Código Fuente Abierto se basa en hacer
software confiable y poderoso. Enfatizan los valores prácticos. No están
equivocados, pero eso no es todo. Yo creo que la libertad es más importante
que los atributos de confiabilidad de un software. Si tengo que elegir entre un
programa muy poderoso y mi libertad, me quedo con mi libertad'.
Como es posible deducir, Stallman basa todos sus conceptos en la libertad y
por eso traza una separación con el otro movimiento; ya que no prioriza la
libertad. Con el correr de los años, la postura de Stallman fue perdiendo
adeptos y el movimiento de Código Fuente Abierto quedó como la opción más
fuerte y reconocida frente al software propietario. Esto fue advertido por
Stallman y hasta llegó a declarar que lo estaban “borrando de la historia”. Lo
cierto es que el tono de sus críticas bajó un poco y declaró lo siguiente:
'Nuestra relación con el Open Source es la siguiente: estamos en desacuerdo
en los principios básicos, pero coincidimos bastante en las recomendaciones
prácticas. Entonces podemos hacer trabajos en conjunto en muchos proyectos.
No los vemos como un enemigo, ya que nuestro enemigo es el software
propietario. Reconocemos que han contribuido a nuestra comunidad'.
Licencias aceptadas
Para continuar con la comparación entre Código Fuente Abierto y Software
Libre, se pueden establecer las diferencias entre ambos a la hora de aceptar
licencias.
En la fundación para el Software Libre se califica a una licencia según los
siguientes criterios:
 Si califica como licencia de Software Libre. (O sea que cumple con las
Libertades 0, 1, 2 y 3 ).
 Si es una licencia de Copyleft.
 Si es compatible con la GNU GPL.
 Si causa algún problema práctico en particular.
De esta calificación surgen tres tipos de licencias:
 Licencias de Software libre compatibles con la GNU GPL.
 Licencias de Software libre incompatibles con la GNU GPL.
 Licencias No libres de software.
En la Iniciativa Código Fuente Abierto se utiliza la Certificación OSI para
denotar que el software es Open Source. Para acceder a esta certificación la
licencia bajo la que se distribuye el mismo debe cumplir con la Definición de
Código Fuente Abierto.
Licencias aceptadas por ambos
 GNU General Public License.
 GNU Lesser General Public License.
 Licencia BSD.
 Licencia del MIT.
 Licencia Zlib.
 Licencia W3C.
 Mozilla Public License. *
 QT Public License. *
 IBM Public License. *
 Phyton Software License. *
 Apache Software License. *
 Sun Industry Standards Source License. *
 Zope Public License. *
* Estas licencias son aceptadas por la Free Software Foundation como de
software libre pero no son compatibles con la GNU GPL, por lo que no pueden
unirse a un programa protegido por la GNU GPL para obtener un trabajo
derivado. Si se hace eso, el trabajo debe lanzarse bajo la GNU GPL.
Licencias aceptadas particularmente
Open Source Iniciative Free Software Foundation
MITRE Collaborative Virtual Workspace
Licencia Guile.
License.
RICOH Source Code Public License. Cryptix General License.
Licencia de bases de datos de
VOVIDA Software License.
Berkley.
INTEL Open Source License. Licencia de Netscape Javascript.
JABBER Open Source License.
NOKIA Open Source License.
Sleepycat License.
NETHACK General Public License.
Common Public License.
XNET License.
Eiffel Forum License.
MotoSoto License.
Open Group Test Suite License.
NCSA Open Source License.
Open Source Iniciative Free Software Foundation
Artistic License. *
Apple Public License. *
Sun Public License. *
* Estas licencias son consideradas por la Free Software Foundation como Licencias No Libres
de software.
Sin dudas es muy importante la aparición del movimiento de Código Fuente
Abierto. Aportó nuevas ideas y un enfoque distinto al dilema entre el software
libre y el software propietario. Permitió acercar estos dos extremos hacia un
modelo híbrido en el cual ambos participantes dan lo mejor de cada uno.
Por el lado del software libre, tenemos la robustez que logran los programas al
poder ser inspeccionados y probados por los usuarios. Además la posibilidad
de contar con el código fuente permite efectuar modificaciones u optimizar las
soluciones actuales. Del lado del software propietario, las empresas pueden
aportar su capital para financiar los proyectos, más el 'know how' obtenido a lo
largo de años.
Todo esto unido da forma a la idea de Open Source. Esta concepción es muy
interesante y quizá termine prevaleciendo en el futuro.
En cuanto al software libre, tiene muchos aspectos importantísimos, sin los
cuales el Open Source no existiría. Como idea es mucho más pura. El
problema que trae aparejado esto es que el movimiento de Software Libre se
aísla del resto, solo porque no comparten sus ideales de libertad.
Aunque a Stallman no le guste, el modelo Open Source es una evolución del
Software Libre y debería reconocerlo como tal. Lo que nunca hay que olvidar
es que el movimiento Open Source tiene la fuerza que tiene en gran parte
gracias a todo lo desarrollado por la Free Software Foundation con anterioridad.
28Lineamientos de Debian sobre Software Libre.
29Licencia del lenguaje de programación PERL
6. Eric Steven Raymond.
Introducción
Eric Raymond, es una especie de filósofo del mundo del Software Libre.
Aunque no solo es famoso por sus escritos, ya que varios paquetes de software
de su autoría forman parte de las distribuciones de GNU/Linux.
Entre sus aportes se puede destacar:
 Emacs VC (Version Control) Un Front End para
CVS, o sea control de versiones.
 Fetchmail: una solución para la obtención de
correo para máquinas UNIX, especialmente
para aquellos con conexión intermitente al
servidor de correo (PPP, SLIP). Recupera los
mensajes usando alguna variante de POP o de
IMAP.
 Participó del desarrollo de las bibliotecas
ncurses .
Se precia de ser uno de los primeros voluntarios en sumarse al proyecto GNU
de Stallman (a mediados de la década del 80). Y aunque luego fue uno de los
creadores del movimiento Open Source, asegura que continúan siendo amigos
con Stallman.
A los efectos de estudiar el movimiento del software libre, es esencial tener en
cuenta los escritos publicados por Raymond. Consiguió resumir de forma
magistral el fenómeno y crear un mito en su artículo "La catedral y el bazar".
Trató de destacar las diferencias entre varios campos del mundo de código
fuente abierto. Se dio cuenta de que los que lideraban proyectos de código libre
tenían distintas formas de compartir y quería explicar cuál de todas es la que
mejor funciona.
La Catedral y el Bazar
Ver Documento Completo
en http://www.catb.org/~esr/writings/homesteading/cathedralbazaar/
Este famoso escrito fue presentado por Raymond en mayo de 1997, en un
congreso sobre GNU/Linux en Bavaria. En el mismo se encarga de analizar el
modelo de desarrollo creado y utilizado por Linus Torvalds para su proyecto
Linux30. El hacker dice que este modelo cambió su forma de pensar. Mucha
gente dentro del mundo del software cree que hay un cierto nivel de
complejidad a partir del cual es recomendable un desarrollo centralizado. Linus
Torvalds demostró que estaban equivocados al desarrollar una pieza de
software tan crítica como es el núcleo de un sistema operativo, de una manera
abierta y completamente descentralizada.
Para explicar este fenómeno emplea una metáfora bien descriptiva. Sugiere
que el mundo del Software Libre es como un bazar con muchos comerciantes
diferentes que ofrecen sus mercancías. El desarrollo empresarial, por el
contrario, esta estructurado como los sindicatos religiosos que construyeron las
catedrales medievales.
Los bazares ofrecen mucha competencia, pero sin orden alguno. Las
catedrales estaban sometidas a la dirección de jerarquías sacerdotales, que
aprovechaban la riqueza de la ciudad para construir el proyecto de un solo
arquitecto.
Las diferencias entre ambos son evidentes. El equipo de la catedral puede
producir una obra de arte si el arquitecto tiene talento, los encargados de la
financiación tienen éxito y la dirección consigue que todo el mundo se
concentre en su trabajo. El bazar, por otra parte, consiste en muchos
mercaderes pequeños que tratan de competir unos con otros. Los mejores se
quedan con los mejores clientes, y los otros pronto acaban sin trabajo.
Aunque parezca que la comparación apunta a separar el desarrollo
comercial/cerrado del mundo Open Source, Raymond señala que la FSF es
como la catedral del Software Libre. Obviamente con esto no quiere decir que
la FSF sea lo mismo que Microsoft, pero sí que su modelo de desarrollo es por
lo general centralizado.
A lo largo del escrito, Raymond redacta su experiencia personal durante el
desarrollo de fetchmail. Expresa de manera clara y explicativa, cómo fue que se
decidió a aplicar un modelo similar al utilizado en el proyecto Linux para llevar
adelante su propio desafío. A medida que avanza en detalles va definiendo
algunos axiomas que son interesantes de discutir.
Toda buena pieza de software empieza por una motivación personal de
un programador31.
Esta regla es bastante controversial. Sin dudas, muchos de los proyectos
surgen de la necesidad de una persona o de un grupo de personas, pero no
siempre es así. De hecho, si fuera de esta manera sería imposible poder contar
con un sistema operativo completo de la talla de GNU/Linux. Se necesitan
muchísimas herramientas, las cuales fueron en su gran mayoría desarrolladas
por voluntarios de la FSF. Entonces, hay muchas aplicaciones que fueron
escritas por el simple hecho de una necesidad. Para citar un ejemplo simple: la
utilidad tar. Tar se encarga de armar un solo archivo a partir de dos o más. No
se puede suponer que sea el interés de nadie, programar dicha utilidad. Pero
para poseer un sistema tipo UNIX completo se debe contar con una aplicación
de este tipo.
Como este ejemplo hay cientos, ya que los sistemas tipo UNIX se caracterizan
por la cantidad de aplicaciones que poseen. Entonces, aunque puede ser
verdad que en muchos casos los proyectos nacen de motivaciones particulares,
no es correcto definirlo como un axioma.
Cuando pierdes el interés en un programa, tu última obligación es
entregarle el mando a un sucesor competente.
Esta sí es una máxima dentro del mundo de los proyectos Open Source. Es
muy importante que el líder esté completamente dedicado al proyecto y que
demuestre que los esfuerzos de los voluntarios son tenidos en cuenta. En el
caso que al líder deje de interesarle el proyecto, ya sea porque alcanzó una
madurez razonable o porque realmente no puede dedicarle todo el tiempo
necesario, el mismo debe delegar esta responsabilidad en alguna otra persona
del proyecto. Esto es necesario para que el proyecto no entre en un pozo.
Además, siempre debe evitarse que por culpa de un líder que no cumple con
sus responsabilidades, el proyecto sufra una bifurcación32. Siempre se busca
evitar las bifurcaciones porque implican dos grupos distintos haciendo la misma
tarea.
Tratar a los usuarios como codesarrolladores es la mejor ruta para una
rápida mejora del código y un debugging efectivo.
Esta es una de las lecciones aprendidas por Raymond del modelo de Linus,
que aplicó a su propio proyecto de fetchmail. Esto se basa en una fortaleza de
la tradición UNIX, que Linux también heredó, y es que muchos de sus usuarios
son hackers. Dado que el código fuente está disponible, pueden ser hackers
efectivos. Esto puede ser muy útil para reducir los tiempos de debugging. Si se
los incentiva, los usuarios diagnostican problemas, sugieren correcciones, y
ayudan a mejorar el código de una manera mucho más rápida que si el creador
lo hiciera solo.
Este axioma se complementa con el siguiente, que apunta al mismo concepto y
que Raymond lo definió como la ley de Linus.
Ley de Linus: Dado el suficiente número de globos oculares, todos los
errores son triviales.
Todo proyecto de Software Libre, tiene como plataforma a Internet. Esto permite
que los voluntarios que conforman los grupos sean de diferentes partes del
mundo. Las comunidades virtuales que se forman en torno a un proyecto, no
podrían existir sin Internet como medio de comunicación.
La red no solo brinda el espacio de comunicación entre desarrolladores, sino
que también es un excelente medio de publicidad. Hay sitios que se dedican a
auspiciar estos proyectos (SourceForge, Freshmeat, etc.). A través de ellos, los
proyectos pueden darse a conocer al mundo. De esta forma comienzan a
captar usuarios que son posibles codesarrolladores. Dada la masividad de
Internet, es muy grande la posibilidad de que un proyecto que persigue
objetivos interesantes; logre captar la atención de muchos hackers alrededor
del mundo.
A medida que el proyecto comienza a lograr fama y suma adeptos, más y más
gente comienza a interesarse en él. A partir de ahí comenzarán a aparecer
distintos tipos de usuarios. Por un lado aquellos que simplemente utilizan el
software porque les es de utilidad, y solo necesitan que el mismo cumpla con
sus funciones. A su vez, serán quienes al utilizarlo de manera frecuente
comiencen a encontrar errores. Si están bien entrenados, los reportarán. Otros,
comenzarán a manipular el código fuente del software con lo que, aportarán
sus opiniones y corregirán los bugs detectados. Todo esto puede suceder a una
velocidad asombrosa.
La ley de Linus declara que al crecer la cantidad de gente que utilice el
software y que lo inspeccione, cualquier problema que aparezca va a resultar
trivial. Dado el gran número de voluntarios, las actividades se solapan y no son
realizadas por la misma persona. Por eso, seguramente no será el mismo
usuario que detecte un bug, que el que lo solucione.
Todo esto nos lleva a obtener como conclusión, que para los proyectos de este
tipo los usuarios son el recurso más importante con que se cuenta. El usuario,
no es meramente aquel que paga una determinada cantidad de dinero por la
licencia de uso de un programa. Sino que sus opiniones y aportes son muy
importantes y ayudan al progreso del proyecto. Sin dudas que esta es la mayor
diferencia que se puede encontrar a la hora de comparar el modelo de
desarrollo tipo Bazar, frente al modelo de la Catedral donde todo es muy
cerrado.
Publicar pronto y frecuentemente, delegar todo lo que puedas, estar
abierto hasta el punto de la promiscuidad.
Esta es una parte crítica del modelo de desarrollo de Linux. Muchos
desarrolladores creían que no era una práctica para proyectos grandes, porque
las versiones tempranas están llenas de errores y no se quiere agotar la
paciencia de los usuarios.
La creencia de los modelos tipo catedral, es que al usuario deben llegarle la
menor cantidad posible de errores. Para lograr eso, las versiones están
separadas por largos lapsos de tiempo. Raymond dice lo siguiente:
'Según la idea de programación del constructor de catedrales, los errores y
problemas de desarrollo son fenómenos taimados, insidiosos, profundos.
Cuesta meses de escrutinio por parte de unos cuantos, muy dedicados,
desentrañarlos por completo. De ahí los largos intervalos entre versiones, y la
inevitable decepción cuando las entregas esperadas desde hace largo tiempo
no son perfectas.
Por el contrario, según la visión del bazar, uno asume que los fallos son,
habitualmente, fenómenos superficiales, o al menos que se pueden minimizar
rápidamente, cuando se exponen a miles de ansiosos codesarrolladores que
machacan incesantemente cada nueva versión. Por lo tanto, uno saca más
versiones para poder realizar más correcciones y, como efecto colateral
benéfico, tiene menos que perder si se cuela algún problema ocasional'.
Esto no implica que solamente se deban publicar versiones a menudo para
satisfacer a los ansiosos Hackers. En general, lo que se realiza es una división
del proyecto en dos ramas, la estable y la de desarrollo. Por un lado, los
usuarios comunes pueden descargarse la última versión estable del programa,
la cual les asegura un funcionamiento aceptable. La otra rama, es la que
cuenta con las últimas modificaciones y sobre la que se efectúan las pruebas
para incorporar nuevas funcionalidades al software. Este método permite que
los dos tipos de usurarios puedan satisfacer sus necesidades.
Netscape y el Bazar
El 22 de enero de 1998, aproximadamente siete meses después de la primera
edición de este escrito, Netscape Communications Inc, anunció sus planes de
publicar el código fuente de su browser Netscape Navigator.
El vicepresidente ejecutivo de la firma le comunicó a Raymond: 'En
representación de todos en la empresa, queremos agradecerte por ayudarnos a
llegar a este punto. Tus pensamientos y tus escritos fueron la inspiración
fundamental de esta decisión'.
Los resultados no fueron tan buenos como esperaban, pero Netscape pudo
frenar la expansión monopólica de Microsoft y su Internet Explorer. Surgieron
varios inconvenientes durante los primeros meses de vida del proyecto Mozilla.
Tampoco puede indicarse que haya sido un fracaso. El problema principal es
que Netscape no se atuvo a los principios básicos del modelo bazar. Por
ejemplo, se tardó mucho tiempo en lanzar una versión que pudiera ejecutarse
sin problemas. Parte de este inconveniente tuvo que ver con asuntos legales
por el uso de las bibliotecas no libres motif. También se registraron dificultades
en el seno de la conducción del proyecto, lo que desembocó en renuncias y
pérdida de confianza por parte del público testigo de todo esto.
Hoy en día, el navegador Mozilla forma parte de la mayoría de las
distribuciones de GNU/Linux. Ha alcanzado un nivel, más que satisfactorio de
performance, pero no logró llegar al punto de ser un asesino de categoría33.
Los Documentos Halloween
Ver Los Documentos Completos
en http://www.opensource.org/halloween/
El día 30 de Octubre de 1998, llegó a las manos de Eric Raymond un
memorandum confidencial que parecía proceder de Microsoft. En él se
analizaba el modelo Open Source y se estudiaban las implicancias del mismo
en comparación con el modelo de negocios de la empresa de Bill Gates.
Raymond, ni lerdo ni perezoso, publicó el reporte titulándolo "Halloween
Document" (en alusión a la fecha en que conoció la existencia del mismo). Este
hecho recibió una fuerte cobertura de los medios, especialmente en Estados
Unidos y Europa. Microsoft, se vio obligada a reconocer la autenticidad del
mismo. Unos días después apareció un segundo documento "Halloween
Document II", que hacía referencia específicamente al sistema operativo
GNU/Linux.
Los documentos Halloween fueron como dinamita. Se convirtieron en el
testimonio de las fortalezas del modelo Open Source, visto desde la compañía
que más perdió por el éxito de GNU/Linux. A su vez, sirvieron para confirmar
muchas de las sospechas sobre las tácticas que emplearía Microsoft para
detenerlos. Desde la empresa intentaron restarle importancia al hecho, y
calificaron al informe como un estudio de ingeniería, que no reflejaba las
políticas de Microsoft.
A continuación se detallarán los puntos más importantes de estos documentos,
que sirven para entender como intentará una de las empresas más importantes
de desarrollo comercial / cerrado, derrotar al incipiente Open Source.
En el comienzo, describe las principales características del Open Source. El
autor declara que los proyectos de este tipo, han alcanzado calidad comercial.
Como primer alarma indica que muchos casos de estudio que se han
presentado en Internet, dan evidencia al resto de la gente (potenciales clientes
de Microsoft) que los proyectos Open Source han logrado grandes resultados.
A lo largo del memorandum, el autor se encarga de destacar las
personalidades más influyentes:
 Richard Stallman, por ser el creador de la concepción moderna de
Software libre y por su proyecto GNU.
 Linus Torvalds, por ser el creador de Linux. Se lo identifica como un líder
carismático.
 Eric Raymond. Es el más citado dentro de todo el documento. Se analizan
sus escritos para describir el pensamiento y la forma de actuar de los
hackers que integran el movimiento.
Como uno de los hechos más particulares e importantes, se destaca que la
motivación principal de la mayoría de los proyectos no es monetaria. Indica que
por lo general no hay una empresa detrás de los mismos, por lo que Microsoft
debería apuntar al proceso en sí mismo y no a una empresa determinada.
Se puede concluir que es acertado el enfoque propuesto por el autor. A pesar
de que hay varias empresas detrás del movimiento (las más conocidas son las
que se encargan de armar las distribuciones del sistema GNU/Linux como
SuSE o Red Hat), estas no son la principal amenaza contra Microsoft. Lo más
importante es ver si está en condiciones el modelo que defiende
(cerrado/comercial) de competir frente al abierto y libre del Open Source. Esta
es la razón por la cual es acertado indicar que el proceso es el que atenta
contra los objetivos de Microsoft y no alguna empresa en particular.
También se reconoce la fuerte penetración que ha tenido el modelo en el
ámbito universitario / académico. Se detalla que es un campo muy importante
ya que se producen muchas investigaciones y desarrollos nuevos que se
implementan antes en GNU/Linux, que en la plataforma Microsoft.
Como punto más importante y preocupante, el autor plantea que GNU/Linux
puede ganar la batalla solo si los servicios y protocolos siguen siendo
commodities. Es una afirmación bastante fuerte, que da muestras claras de lo
que ha sido la historia de los desarrollos de Microsoft: cerrado y oculto. Al
sugerir que los protocolos deben dejar de ser un commodity, el autor está
expresando que la mejor manera de ganar es creando protocolos propietarios y
no compatibles con los demás, que no permitan la libertad de elección a los
usuarios. Aunque desde Microsoft se planteó que este escrito no representaba
sus políticas, da bastante escalofrío suponer que la empresa tiene en sus
horizontes, por ejemplo, lanzar su propio protocolo tcp/ip o su propia versión del
HTTP.
Estos documentos34 son muy importantes y permitieron dar a conocer la
opinión de uno de los exponentes principales del modelo que se contrapone al
del Software Libre. A su vez, Raymond escribió en estos últimos años varios
ensayos más en los que continuó analizando el mundo del Software Libre y del
Open Source.
Entre ellos se destacan:
 Homesteading the noosphere
(http://www.geocities.com/jagem/noosfera.html): Aquí se encarga de
analizar a la cultura de los hackers. Presenta a la misma como una
cultura de regalos donde cada uno de los individuos regalan sus
productos para lucirse frente a los demás. También dice que la mayoría
de los hackers hacen su trabajo en busca de una satisfacción del ego.
También estudia cómo se desempeñan los grupos que se forman en
torno a los proyectos y analiza los líderes que surgen de los mismos.
 The Magic Cauldron
(http://www.catb.org/~esr/writings/homesteading/magiccauldron/): En
este ensayo analiza al modelo desde un perspectiva económica y de
negocios. Presenta su opinión sobre en qué caso es más conveniente
lanzar un proyecto Open Source y cuándo conviene utilizar el modelo
convencional.
 The Revenge of the Hackers
(http://www.oreilly.com/catalog/opensources/book/raymond2.html) y
A Brief Story of Hackerdom
(http://www.oreilly.com/catalog/opensources/book/raymond.html): Estos
dos escritos forman parte del libro Open Sources Voices of the Open
Source Revolution. Aquí, Raymond habla nuevamente sobre la cultura
hacker y el modelo Open Source.
Un análisis más detallado de estos escritos escapan al alcance de este trabajo.
Se los nombra simplemente para dar una idea clara de la cantidad de ensayos
y escritos que ha publicado Raymond, de ahí que se lo considere como el
filósofo del Software Libre.
No hay duda alguna que Raymond es otra de las personalidades influyentes
dentro del software libre. Varias razones son las que justifican esta afirmación.
Sus aportes contribuyeron a fortalecer varios ámbitos del movimiento. Por un
lado, su temprana participación en el proyecto GNU y principalmente en el
desarrollo de GNU EMACS. Otro de sus valiosos aportes fue la aplicación
Fetchmail, que es muy respetada y utilizada. Por el otro lado, sus escritos han
sido muy importantes a la hora de explicar el fenómeno del software libre y
permitieron dar a conocer por parte de un integrante de la comunidad hacker
cuáles eran los objetivos perseguidos por ellos.
Por último, para continuar enumerando sus aportes, puede marcarse su
posición destacada en el grupo que lidera el movimiento Open Source. Es de
importancia remarcar que su postura, no ha sido tan radical y confrontativa,
como la de Stallman. Actitudes como la suya, fueron las que contribuyeron a
que hoy en día se conozca más al Open Source que al software libre.
Todas estas razones permiten determinar que se está frente a otra de las
personalidades que han dedicado gran parte de su vida, al esfuerzo de lograr
que este modelo prevalezca frente al cerrado y propietario.
30Aquí se refiere solamente al kernel, que es el proyecto de Torvalds.
31El término utilizado era scratching a developer's itch, refiriéndose a que el programdor se
rasca lo que le pica. Una metáfora para justificar que el programador ataca solo sus
motivaciones personales.
32En la jerga se lo denomina fork. Fork es una de las llamadas al sistema en Unix. La misma
sirve para crear procesos hijos, para lo cual el proceso padre se duplica y de ese proceso
duplicado nace el hijo. Es una metáfora para describir las divisiones que pueden producirse en
un proyecto que terminan dando origen a dos proyectos (el actual, más el nuevo).
33 Asesino de categoría
: Así se denomina a las aplicaciones que han capturado un nicho
específico. Sería muy difícil para otra aplicación capturar la atención del público. Se dice que
GNU/Linux es un asesino de categoria en cuanto a los Sistemas Operativos de código fuente
abierto.
34Los documentos originales pueden encontrarse en la página de la Iniciativa Open Source:
www.opensource.org.
7. Software Libre en Argentina.
Introducción
El objetivo de esta sección es analizar la situación actual del Software Libre en
la Argentina. En primer instancia, se estudiará el caso del Estado nacional. Se
intentará identificar las desventajas de utilizar software propietario en el ámbito
público y luego se detallará la forma en que el software libre puede subsanar
esos inconvenientes.
A su vez, se presentarán iniciativas que provienen de distintos ámbitos pero
que tienen como fin común promover el uso generalizado de herramientas
libres.
El Software Libre en el Estado
Situación en el estado nacional:
 Actualmente el estado nacional no posee el grado de control necesario
de la información digitalizada que procesa.
 El estado no tiene completo control sobre la legalidad del software que
utiliza.
Es de conocimiento de público que al asumir el gobierno de Fernando de la
Rua, se declaró que numerosos organismos utilizaban software de manera
ilegal, sin pagar los correspondientes derechos de uso. Esta situación
implicaba que el mismo Estado estaba no solo tolerando sino incitando a la
comisión de un ilícito, como es el emplear software sin licencia.
Desde ya, no es el objetivo de este trabajo criticar a un gobierno, ni entrar en
discusiones políticas. Pero se puede destacar que las instituciones del ámbito
público, deben poseer una conducta ética irreprochable, que constituya un
ejemplo para los ciudadanos. Sino se transforma en imposible exigirle al
ciudadano el cumplimiento de la ley, el pago de sus impuestos, si es el mismo
estado quien vulnera la norma legal.
Problemas derivados del uso de software propietario
Cuando el ciudadano brinda información al Estado, lo hace bajo la suposición
que será resguardada su privacidad, o sea que:
 dichos datos se mantendrán adecuadamente custodiados,
 los mismos no podrán ser alterados por ninguna persona,
 solo podrán ser tratados por los funcionarios competentes y
 no podrán ser transferidos fuera de la órbita del Estado35.
El Estado nacional debe poseer un completo y acabado control de sus
acciones y por lo tanto es completamente inaceptable que emplee sistemas de
los cuales no conozca hasta sus mínimos detalles.
Los formatos empleados para codificar los datos que se mantienen en soporte
digital, son otro punto a tener en cuenta. En caso que el estado no pueda
disponer de los parámetros con los cuales han sido desarrollados dichos
formatos, queda obligado a depender de una aplicación cerrada para
acceder a sus propios datos. Al emplear formatos cerrados, la información
volcada por el Estado solo puede ser decodificada correctamente por el
diseñador del formato, sea éste una empresa o persona de cualquier origen o
dimensión.
Otro asunto de gran importancia es el software de seguridad. El mismo es
como un seguro de caja fuerte: aunque se sepa como funciona es necesario
conocer la clave o la combinación que su dueño fijó para abrirla. La seguridad
depende de la protección de esa combinación, no del mecanismo en sí
(siempre que el mecanismo sea lo suficientemente bueno). Sin la posibilidad de
inspeccionarlo, es imposible saber si el programa cumple meramente con su
función, o si además incluye vulnerabilidades intencionales o accidentales que
permitan a terceros acceder indebidamente a los datos.
Hay programas libres para usar los mecanismos de seguridad más fuertes
conocidos. El hecho de que sean libres les da una garantía de calidad extra, ya
que su publicidad permite que cualquiera pueda detectar y reparar fallos o
riesgos a la seguridad que contenga.
Uno de los ejemplos más puntuales de la dependencia tecnológica puede verse
en la misma legislación argentina. Desde hace un tiempo, la AFIP exige a los
contribuyentes la presentación de diversas declaraciones en formato digital. La
idea, por cierto, es razonable, pero la manera en que la AFIP la implementó es
tal que exige que la presentación sea exclusivamente a través de la ejecución
de programas específicos provistos por esa organización. Estos programas, es
cierto, son gratuitos, pero entre sus requerimientos de ejecución se incluyen,
como sistemas operativos, exclusivamente“Windows 95, 98 o Superior”. Es
decir que el Estado está exigiendo a los ciudadanos que compren un
determinado producto de un determinado proveedor al solo fin de poder cumplir
sus obligaciones impositivas.
Beneficios para el Estado con el uso de software libre
Muchas veces se pone adelante de todas las ventajas el ahorro monetario.
Este ahorro puede ser realmente importante, pero puede ser mermado a corto
plazo por los costos de realizar la transición de los sistemas. Existen otras
ventajas que son inmediatas y más importantes, al punto de ser cruciales para
la adopción de estas políticas por el estado:
 Independencia Tecnológica : Mediante el uso de software libre, el
Estado deja de tener sus sistemas controlados por una entidad externa
(con frecuencia empresas extranjeras). De esta forma rompe la
dependencia tecnológica que lo tiene actualmente atado y obtiene las
libertades que el software libre otorga.
 Control de la Información : Esto se desprende directamente de las
libertades que brinda el Software Libre. Al tener la libertad de
inspeccionar el mecanismo de funcionamiento del software y la manera
en que almacena los datos, sumado a la posibilidad de modificar ( o
contratar a alguien que modifique) estos aspectos, queda en manos del
Estado la llave de acceso a la información y no en manos de terceros
ajenos.
 Seguridad : Este es uno de los puntos claves para el estado. Mucha
información que el Estado maneja puede ser peligrosa en manos
incorrectas. Es por esto que es crítico que el Estado pueda fiscalizar que
su software no tenga puertas de entradas traseras (backdoors),
voluntarias o accidentales, y que pueda cerrarlas en caso de
encontrarlas; tal inspección solo es posible con el software libre.
Debe tenerse en cuenta que una política de este tipo no discrimina en contra
de productos o proveedores específicos, sino contra ciertas prácticas nocivas
que involucran el control de la información del usuario por parte del proveedor.
Es fundamental que el estado no se someta a estas presiones.
Otro punto a favor es que la industria local se verá ampliamente beneficiada,
dado que las licencias libres le otorgan al gobierno el derecho a contratar
profesionales locales para modificar y adaptar sus sistemas. De esta forma, se
fomenta la industria tecnológica local, la economía y el empleo.
Hay que destacar que la migración sería costosa en primer instancia. Esto se
debe a que involucra costos en relevamientos, toma de decisiones para
implementar los nuevos sistemas, mano de obra para implementar el cambio,
conversión de datos, reentrenamiento del personal. Todo esto sin tener en
cuenta el natural rechazo al cambio, que no tiene un impacto monetario pero
que puede hacer fracasar cualquier proyecto de implementación.
Los costos relacionados con el software propietario son, en gran medida, por
licencias de uso por cada terminal, más la necesidad de actualizar el hardware
dados los requerimientos de procesamiento más potente en cada nueva versión
de las aplicaciones. A su vez, en muchos casos la actualización de los
programas es forzada, ya que no se mantiene una compatibilidad con
versiones anteriores con lo que el software se transforma en obsoleto.
Según un estudio realizado36, aproximadamente el 70% del empleo que se le
da a una computadora en la órbita estatal demanda los denominados
programas de escritorio, de los cuales en la mayor parte de los casos se utiliza
exclusivamente el procesador de textos. Este porcentaje trepa casi al 90% en la
órbita del poder judicial, es decir que una parte sustancial puede ser
reemplazada en forma casi masiva e inmediata, pero en esta fase parte del
ahorro debería invertirse en capacitación.
Marco Legal
Ha pasado tiempo desde que se comenzó a hablar de la necesidad de utilizar
software libre en el estado. Obviamente Argentina no es el único país donde se
está impulsando el uso de herramientas de software libre para los sistemas del
Estado. Hay varios casos de proyectos en Europa (Francia, España, Italia) y
también en América (Méjico y Brasil).
En nuestro país, el día 10 de septiembre de 2000 se presentó un Proyecto de
ley sobre Software Libre en la Cámara de Diputados Nacional. La iniciativa
correspondió al Ingeniero Marcelo Dragan.
Este proyecto de ley recibió una difusión aceptable y mucha gente se mostró a
su favor. Dragan y su gente se encargaron de presentarse en distintos
congresos y reuniones del mundo informático para lograr adhesiones a su
iniciativa. Por ejemplo, la misma fue sometida para su discusión ante los
participantes del Congreso Argentino de Ciencias de la Informática y
Computación que se desarrolló en Ushuaia en el año 2000. El texto inicial
causó sorpresa y recibió una fuerte adhesión de parte de prestigiosos
educadores de universidades públicas y privadas.
También hubo una presentación en COMDEX Argentina 2001, por parte del
Diputado Nacional Martín Borrelli. En la misma se debatió sobre las
implicancias del proyecto y ayudó a que mayor cantidad de gente conociera la
iniciativa.
El 27 de marzo de 2002 proyecto de Dragan (5613D00) pasó a archivo y fue
presentado uno nuevo en la Cámara de Diputados del Congreso Nacional (904
D029). Este se basa en el anterior, e incorpora las mejoras que fue recibiendo
durante dos años.
Proyecto de Ley 904D02
Autores:
Marcelo Dragan Omar Enrique Becerra Rosana Andrea Bertone

Diputado nacional Diputado nacional Diputada nacional
Tierra del Fuego Tierra del Fuego Tierra del Fuego
Partido Acción por la Partido Justicialista Partido Justicialista
República
Aspectos Importantes
 Define claramente el concepto de software libre.
 Exige que dentro de todos los ámbitos y Poderes del Estado se utilicen
programas libres.
 Si no existe una solución que utilice software libre, existen dos
alternativas.
 De no existir una herramienta que cumpla con los requerimientos y en
consecuencia se deba desarrollar un programa nuevo, el mismo debe
obligatoriamente ser libre.
 En el caso que solamente exista una herramienta no libre que cumpla
con los requerimientos y a su vez existan exigencias de tiempo
verificables para la solución, el organismo que lo demande podrá
gestionar un permiso temporario para su utilización.
 Las entidades educativas pueden pedir permisos especiales para utilizar
software no libre siempre y cuando sea para su investigación.
 Se establece que el Poder Ejecutivo deberá reglamentar en un plazo de
180 días las condiciones, tiempos y formas en que se efectuará la
transición. Esto significa de qué manera se transitará del estado actual a
uno que cumpla con las condiciones estipuladas en la ley
Actualmente el proyecto de Dragan se encuentra en la Cámara de Diputados
de la Nación.
El 10 de mayo de 2002, el senador de la Provincia de Buenos Aires por la UCR
Alberto J. L. Conde, presentó un Proyecto de Declaración en el cual indicaba
que: “ vería con agrado que el Congreso de la Nación proceda a dar
tratamiento en forma urgente y su aprobación al proyecto de Ley 904D02 con
inicio en la Cámara de Diputados referido al uso de Política de utilización de
Software Libre por el Estado Nacional”.
Esta presentación fue aprobada por unanimidad por la Cámara de Senadores
de la provincia de Buenos Aires el día 6 de junio de 2002. El texto37 del mismo
posee una pequeña modificación del original para adaptarlo al contexto
provincial. El mismo día, el proyecto fue aprobado por unanimidad en la
Cámara de Senadores de la Provincia de Buenos Aires. De esta forma el
mismo se transformó en proyecto de ley. El 18 de junio, el mismo tomó estado
parlamentario y será tratado en orden secuencial por las siguientes comisiones:
1. Comisión de Educación, Cultura, Deportes, Ciencia y Técnica
2. Comisión de Legislación General
Todos estos intentos son más que destacables, pero todavía se está lejos de
alcanzar resultados tangibles. Es de esperarse que los legisladores reciban
presiones de todo tipo de los gigantes de la industria propietaria. Todo proyecto
tiene un año de lapso dentro del cual debe procederse a su tratamiento.
Transcurrido el mismo, el proyecto pierde su estado parlamentario. Esta es la
forma en que el primer proyecto del diputado Dragan fue “cajoneado”.
Lamentablemente, este tema no está instalado en la opinión pública y pasará
mucho tiempo hasta que suceda. Pero de todos modos es importante que se
vayan formando grupos que intenten revertir la situación actual de dependencia
tecnológica total que acosa al Estado.
Otras Iniciativas.
Migración de los sistemas de la Dirección Provincial de Vialidad de
Tucumán a GNU/Linux
En agosto de 2001, la Dirección Provincial de Vialidad de Tucumán realizó una
licitación para migrar todos sus sistemas a GNU/Linux. La empresa que salió
adjudicada fue Tucumán Linux.
Este proyecto de llevó a cabo por varios motivos, los cuales valen la pena
destacar porque ilustran claramente los problemas típicos en ambientes en los
cuales se utiliza software propietario.
 La situación actual del país, en donde priman las soluciones de bajo
costo y la reutilización del hardware. No solo para reducir el gasto de
licencias, sino también para tratar de reducir el tiempo y costo de
mantenimiento.
 El problema de la legalidad del software instalado. Además, en muchas
oportunidades, se hace común que las estaciones de trabajo Windows
sean atacadas por virus. Éstos producen pérdidas de tiempo, dinero y
datos.
La migración total de las 42 estaciones de trabajo, duró dos semanas con los
cursos de capacitación para los usuarios (10 días hábiles). El curso para el
centro de cómputo se extendió un poco más, dado que este personal no tenía
ningún conocimiento en relación a GNU/Linux. Con la capacitación dictada al
personal del centro de cómputos de la DPV, quedaron totalmente aptos para
utilizar y configurar GNU/Linux, y de esta forma no depender de la empresa
para el mantenimiento de su parque informático.
El costo total del proyecto de migración fue de 6.500 PESOS. Si bien en la DPV
contaban con licencias de software, el costo para actualizarlas y mantenerlas
en el tiempo es bastante mayor.
Durante el año de este proyecto (2001), si una empresa o institución del estado
quería licenciar 40 PCs con Windows, Software de oficina y Antivirus no estaba
gastando menos de 35.000 a 40.000 dólares, sólo en licencias. En la coyuntura
actual que se presenta luego de la devaluación del Peso frente al Dólar, se
tornan aún más prohibitivos los precios de las licencias de software propietario.
Aunque no sea la ventaja más importante, es de gran valor comparar las
erogaciones necesarias para mantener un parque informático bajo software
libre y compararlo con uno bajo software propietario. No hay duda alguna que
la diferencia es grande y que va a continuar creciendo.
Algunos detalles técnicos sobre la Migración
1. Al principio se realizó un análisis comparativo de las distribuciones
existentes. Se presentó un informe a la DPV, en el que se consignó un
estudio de las distribuciones existentes, aconsejando una en particular,
acorde con el parque informático, y considerando a futuro la
conformación de redes o subredes, con servidores trabajando en
cualquier plataforma de sistema operativo (GNU/Linux, Windows, otros).
Finalmente se seleccionó SuSE Linux 7.2. por su adaptabilidad a
cualquier entorno, y por su gran cantidad de aplicaciones.
2. Se instaló Samba y el cliente komba2, para integrar las PCs GNU/Linux
con el resto de las PCs en la red.
3. Un aspecto muy interesante es que la gente de Tucumán Linux adaptó el
kernel (recompilándolo) para cada modelo de estación de trabajo
distinto. De esta forma, cada estación de trabajo tiene un kernel refinado
para su microprocesador y chipset.
4. En cuanto a desarrollos extras, se encargaron de modificar en ciertos
puntos el arranque y apagado de Linux, para hacerlo más entendible al
usuario final.
Estos últimos puntos se presentan como grandes diferencias que a su vez son
ventajas a favor del software libre, en este caso el sistema operativo
GNU/Linux.
Este tipo de iniciativas, demuestran que es posible la migración. Uno de los
puntos más importantes a tener en cuenta, es la forma de capacitar a los
usuarios. Este no es un detalle menor y deber ser tenido en cuenta a la hora de
proyectar el cambio. En el caso que los futuros usuarios no puedan vislumbrar
ventajas en su trabajo cotidiano, pueden oponerse al cambio y afectar los
resultados del proyecto.
Por lo expresado anteriormente, es muy importante que junto con un plan
técnico de migración acorde a las necesidades de la organización se tenga
muy en cuenta el factor de los recursos humanos. Estos serán en definitiva los
que operen los nuevos sistemas y por ende deben estar convencidos de que
las ventajas que les reportará el cambio.
Proyecto UTUTO
Esta es otra iniciativa que se ha dado en el ámbito de software libre a nivel
nacional. UTUTO nació como solución a un inconveniente que se le presentó a
Diego Saravia. Este ingeniero industrial dicta una maestría sobre Energías
Renovables en la Universidad Nacional de Salta. Para la misma utiliza algunos
programas que corren bajo GNU/Linux, como Sceptre, que sirve para simular
sistemas eléctricos e instalaciones solares. Saravia necesitaba darle a los
estudiantes la posibilidad de ejecutar Sceptre en sus casas. La opción de
enseñarles a instalar GNU/Linux no era viable y escapaba a los objetivos del
curso. De esta necesidad surgió UTUTO, la primera distribución de GNU/Linux
de Argentina.
Lo más interesante y original fue la creación de un CD que funcionara sin
necesidad de instalación. Dice Saravia: 'La idea es preparar un sistema que
ejecute GNU/Linux sin hacer demasiadas preguntas. Ninguna en principio. Que
no modifique el disco duro en una forma difícil de revertir. Que pueda iniciarse
desde el CDROM, una disquetera o incluso desde el modo DOS del Windows.
Que ofrezca una interfaz gráfica agradable y con programas útiles a
disposición. Un Disco Compacto que muestre su contenido (incluso sus
páginas web) desde Windows.'
La primera versión, muy primitiva y con muchos errores logró su cometido y
alcanzó una fama importante dentro del ámbito académico. Todo lo creado por
la gente del proyecto UTUTO (scripts de arranque, utilidades para detectar
hardware, etc.) están protegidos por la licencia GNU GPL. Pero a su vez, la
distribución incluía software no libre como Netscape y StarOffice.
Apuntando a las cuestiones técnicas de la distribución, se puede destacar que
está basada en Debian 2.1 y SuSE 6.4, con agregados Tiny Login, Busy Box y
LiveCD Project.
Algo muy importante de este proyecto es que es un excelente esfuerzo en sí
mismo, como también un punto de referencia para la elaboración de
distribuciones más elaboradas, con scripts de configuración, instalación, etc.
Este es uno de los usos más interesantes que se le pueden encontrar a
UTUTO.
Actualmente desde el sitio de UTUTO (www.ututo.org) están anunciando que
pronto saldrá a la luz el próximo UTUTO. El mismo se llamará UTUTO libre,
pues solo usara software libre. La distribución no será más un híbrido de SuSE
y Debian sino que dependerá directamente del código fuente de cada paquete.
Por ahora UTUTO no tiene scripts para realizar una instalación en la PC, pero
sus desarrolladores prometen que en un futuro cercano, se incorporarán.
Incluso, se podrá instalar en una partición preexistente del Windows
(UMSDOS). Cuando se ejecuta el UTUTO desde el CDROM, las particiones
que ya estaban creadas en el sistema, no se modifican en gran medida. Se
crea un directorio para el Ututo (ututo.20), y otro para StarOffice (ututo.so52).
Estos directorios se crean en la partición ext2 o FAT con más espacio libre, y si
no hay discos, el resto de UTUTO se carga en RAM.
En resumen, la distribución es ideal para:
 Los que quieren probar GNU/Linux, pero no desean reparticionar su
disco duro, ni pueden destinar varios cientos de Mb para una prueba.
 Los usuarios de GNU/Linux que quieran mostrar, dar charlas, clases,
etc. Especialmente en lugares donde no hay máquinas con GNU/Linux
preinstalado.
 Los que deseen hacer una distribución propia. UTUTO puede verse
como un conjunto de rutinas para preparar distribuciones, más que como
una distribución.
 Como ejemplo puntual, puedo destacar el uso que le dieron a UTUTO
varios compañeros míos estudiantes de informática. Al cursar la materia
Arquitectura de Sistemas Computarizados, recibimos un curso
introductorio a GNU/Linux. Varios alumnos optaron por utilizar UTUTO
para hacer las prácticas y de esa forma, evitaron alterar las
configuraciones de sus máquinas y pudieron cumplir con los objetivos
del curso.
Sería también interesante que el proyecto pueda seguir sumando logros y
encontrar nuevos colaboradores. De esta forma, este emprendimiento tan
ambicioso seguirá mejorando este producto de gran valor como UTUTO.
Todas las iniciativas presentadas a lo largo de esta sección son más que
destacables. Es de esperarse que por la coyuntura económica actual del país,
se generen más casos en los que el software libre sea la única opción posible.
Los precios de la tecnología se han multiplicado varias veces como
consecuencia de la devaluación, pero como contrapartida de eso se abre la
posibilidad para la Argentina de exportar software. Sería muy provechoso que
desde los sectores políticos se fomente este mercado y se lo impulse para que
crezca.
El sector político tiene en sus manos también, la posibilidad de tomar una
decisión importantísima. De sancionarse el proyecto de ley, Argentina se
convertiría en el primer país en contar con una ley nacional que instrumente el
uso de software libre en el estado. Aunque la posibilidad de aprobación
parezca remota es muy importante para comenzar a formar el pensamiento
crítico en el común de la gente que no ve como una amenaza el hecho que el
estado no tenga el control absoluto sobre sus sistemas.
Lamentablemente y como sucede en estos casos donde los intereses
económicos son tan importantes es de suponerse que las grandes empresas
desarrolladoras y proveedoras de software para el estado continúen haciendo
lobby para evitar el tratamiento del proyecto.
35Este principio está consagrado en la ley de Habeas Data(Nº 25.036 / Nov '98). Ningún
ciudadano puede imaginar que sus datos personales puedan terminar en la base de datos de
alguna empresa de marketing.
36Los datos son provenientes de un estudio realizado por los diputados que se encuentran
trabajando en el proyecto de ley de Software Libre. Estos números dan una clara impresión que
en muchos organismos del estado las computadoras son utilizadas simplemente como una
máquina de escribir más poderosa.
37Una copia completa del mismo se encuentra en forma de anexo al trabajo.
8. Proyectos de Software Libre.
W.I.N.E.
(Wine Is Not an Emulator)
El proyecto WINE (http://www.winehq.org/) es bastante antiguo, ya que nació
en 1993. En aquel entonces el objetivo del mismo era lograr ejecutar programas
de Windows 3.1 en GNU/Linux.Bob Amstadt fue quien inició el proyecto, pero
poco tiempo después se lo pasó a su principal ayudante, Alexandre Julliard
quien continúa siendo el líder de WINE.
Como su nombre lo indica, WINE no es un emulador. La idea detrás de este
proyecto es la de clonar la Win32 API ( y la Win16)38. Para entender de una
manera más clara el funcionamiento de este software hay que imaginarlo como
una capa de compatibilidad con Windows. WINE provee lo siguiente:
 Un conjunto de herramientas de desarrollo para portar códigos fuente de
aplicaciones Windows a Unix.
 Un cargador de programas, el cual permite que muchas aplicaciones
para Windows 3.x/9X/ME/NT/2000/XP se ejecuten sin modificarse en
varios UNIX para plataforma Intel como GNU/Linux, FreeBSD y Solaris.
WINE no requiere que se encuentre instalado Microsoft Windows, dado que es
una implementación alternativa que no utiliza código fuente de Microsoft.
Puede llegar a utilizar alguna dll (biblioteca dinámica) en el caso que se
encuentre instalado Windows. El código fuente de WINE se encuentra
licenciado bajo la LGPL por lo que se lo considera Software Libre.
A mediados del año 2002 el proyecto cuenta con más de un millón de líneas de
código fuente escrito en lenguaje C. A su vez cuenta con un grupo de 300
personas que han participado o participan del desarrollo de esta pieza de
software.
Dada la complejidad del objetivo perseguido y a su vez que la meta se
encuentra en constante movimiento (cada nueva versión de Windows implica
nuevos desarrollos), el proyecto aún no llegó a liberar la versión 1.0. Los
detalles que faltan ajustar para poder llegar a la bendita 1.0 son:
 Crear un sistema de instalación simple e intuitivo para los usuarios
comunes.
 Lograr soportar a las aplicaciones que fueron creadas específicamente
para Windows XP (por ejemplo .NET).
WINE ha sido una pieza clave para el desarrollo de Lindows, una distribución
de GNU/Linux que prometía ejecutar cualquier pieza de software diseñada para
Windows. Por problemas de índole legal aún no pudo llegar a comercializarse
esta distribución.
En el sitio web del proyecto se puede participar de un sistema de votación para
elegir qué aplicación se desea que pueda ejecutarse en WINE. El software más
votado es el Macromedia Dreamweaver, luego lo siguen entre otros algunos
juegos como el HalfLife. También tiene votos el Adobe Photoshop y el
Microsoft Word. En el caso del procesador de textos de Microsoft, ya se ha
podido ejecutar bajo WINE, pero su performance aún deja mucho que desear.
También hay otro sistema, el cual se utiliza para calificar el funcionamiento de
las aplicaciones bajo WINE. Se establece una separación entre las que se
ejecutan y se instalan sobre UNIX de las que se ejecutan desde una partición
de Windows. De esta forma se permite que los usuarios califiquen qué nivel de
funcionalidad obtuvieron del software al ejecutarlo bajo WINE. La escala va de
0 a 5 y en la misma página indican cómo debe evaluar el usuario a la aplicación
para evitar distintos puntos de vista a la hora de establecer la puntuación.
FUNDACION APACHE
El proyecto más conocido de esta fundación es el servidor HTTP Apache
(http://www.apache.org/). Pero en realidad son varios los proyectos Open
Source que se encuentran apadrinados por esta fundación. Estos son:
 El servidor HTTP Apache.
El nombre apache tiene un origen un poco discutido, algunos dicen que
viene de "a patchy server" debido a numerosos parches del principio,
otros dicen de una manera más seria que los investigadores de este
proyecto tomaron el nombre en memoria de los Apaches por su gran
adaptabilidad al terreno.
Este servidor es el más utilizado en internet. Respeta el protocolo HTTP
(1.1) normalizado por el W3C (WWW Consortium)
Esta es la encuesta que se publica en el sitio netcraft.com. Claramente se
observa el predominio de Apache sobre los demás servidores. En segunda
ubicación se encuentra Microsoft con su IIS, pero no alcanza el 35% del
mercado contra el 60% de HTTP Apache.
 Jakarta: El proyecto Jakarta es el que se encarga de crear y mantener
todas las soluciones open Source creadas para la plataforma Java. Los
productos del proyecto se dividen en tres categorías generales.
 Bibliotecas, herramientas y APIs: Por ejemplo Taglibs que es una
colección de tags JSP para implementar aplicaciones Web.
 Motores: Por ejemplo Lucene que es un motor de búsqueda de textos
totalmente implementado en Java.
 Aplicaciones del lado del Servidor: Por ejemplo Tomcat que permite
implementar las tecnologías de Servlets y JSP.
 Perl: Integra el lenguaje de programación Perl al servidor web. Permite
ejecución de scripts CGI y también lo concerniente al manejo de
sesiones y autenticación de usuarios. El intérprete se encuentra
embebido al servidor.
 TCL: Apache Tcl intenta integrar el lenguaje de Scripting TCL con el
servidor Web. A su vez el proyecto se divide en tres.
 mod_dtcl: permite usar Tcl como un lenguaje de scripting embebido en
el HTML y también ejecutar scripts de Tcl
 neowebscript: también permite embeber el Tcl en HTML, pero utiliza
intérpretes seguros y archivos db.
 mod_tcl: Permite escribir módulos completos de Apache en Tcl. El
intérprete se encuentra dentro del servidor lo que genera mejores
tiempos de arranque.
 XML: Se encarga de agrupar todos los desarrollos que vinculen XML
con Apache. Entre los subproyectos más importantes se encuentran:
 Xerces: Parser XML en Java y C++.
 Xalan: Preprocesador de hojas de estilo XSLT, en Java y C++.
 FOP: Objetos para formatear XSLT, en Java.
La fundación Apache se creó para brindar soporte organizacional, legal y
financiero a todos los proyectos anteriormente mencionados. La misma, no
persigue fines de lucro y se encarga de ser la “cara visible” de todos los
proyectos. Esto permite que las donaciones se hagan a nombre de una entidad
legal y no a un proyecto o a un líder de proyecto.
La estructura de la fundación puede denominarse una “meritocracia”. Esto
implica que para poder ascender posiciones, el individuo debe tener probados
pergaminos en uno o más de los proyectos. Los distintos integrantes de la
estructura son:
 Usuarios : Son muy útiles para el proyecto, dado que emplean el
software desarrollado por la fundación. En muchos casos son quienes
reportan errores encontrados y quienes contribuyen ideas sobre mejoras
posibles. Algunos usuarios participan en las listas de correo ayudando a
solucionar problemas que afectan a sus pares.
 Desarrolladores : son aquellos que contribuyen con código fuente o
documentación a la lista de correo.
 Committers : son desarrolladores que contribuyen de manera frecuente
al proyecto. Por esa razón tienen permiso de escritura sobre los
repositorios de código fuente del proyecto. Son los encargados de tomar
las decisiones diarias sobre los cambios que se efectuarán al software.
 Comité de Gerenciamiento del proyecto : es un grupo de committers
que toman la dirección a largo plazo del proyecto. Este comité lo elige el
directorio de la fundación.
 Directorio : Es el que se encarga de la administración de los asuntos de
negocios de la organización. Las decisiones de índole técnica quedan
delegadas en los distintos comités de gerenciamiento de proyectos.
SAMBA
Samba (http://www.samba.org/) es un conjunto de aplicaciones UNIX que
entienden el protocolo SMB (Server Message Block). Muchos sistemas
operativos, entre ellos Windows y OS/2, usan SMB para operaciones de red
cliente/servidor. Mediante el soporte de este protocolo, Samba permite a los
servidores UNIX entrar en acción, comunicando con el mismo protocolo de red
que los Windows. De esta manera, una máquina UNIX con Samba puede
enmascararse como servidor en una red Microsoft y ofrecer los siguientes
servicios.
 Compartir uno o más sistemas de archivos.
 Compartir impresoras, instaladas tanto en el servidor como en los
clientes.
 Autenticar clientes logueandose contra un dominio Windows.
 Proporcionar un servidor con resolución de nombre WINS.
El creador de Samba fue Andrew Tridgell quien continúa liderando el equipo de
desarrollo de Samba. En un comienzo Tridgell creó un programa servidor de
archivos para LAN que soportaba el protocolo DEC de la empresa Digital
Pathworks. Tiempo después este protocolo se convirtió en SMB, y ahí nació
realmente el proyecto. En un principio simplemente era conocido como servidor
SMB, pero luego no pudo mantener ese nombre y su creador tuvo que
cambiarlo. Para ello utilizó el comando grep.
grep i `sm*m.*b' /usr/dict/words
y la respuesta fue:
salmonberry samba sawtimber scramble
De esta manera nació el nombre de Samba. El paquete completo se distribuye
bajo la GNU GPL. Aunque parezca extraño, Microsoft también ha contribuido
materialmente poniendo a disposición de la gente de Samba la definición de
SMB y del Common Internet File System (CIFS). El protocolo CIFS es el nuevo
nombre de las futuras versiones de SMB que serán usadas por Windows.
¿Cuándo es recomendable usar Samba?
 Para acceder a archivos NT desde un servidor Unix.
 Para compartir impresoras entre clientes Windows y Unix.
 Para reemplazar un servidor NT, OS/2 o Netware.
Este proyecto goza de una fama importante, en gran medida por la utilidad que
reviste. Es más que interesante su implementación en ambientes LAN que
cuentan con equipos que corren distintos sistemas operativos. Los servicios
que brinda son los justos y necesarios para este tipo de configuraciones
( autenticación de usuarios, compartir archivos e impresoras). Con todas estas
características, Samba se transforma en una herramienta más que útil y por
sobre todas las cosas es libre; dándole aun más ventajas al usuario final.
OPENOFFICE
El proyecto OpenOffice (http://www.openoffice.org/) es la apuesta por parte de
Sun Microsystems para destronar a Microsoft Office de los escritorios. La
historia se remonta a julio de 1999 cuando Sun adquirió de la empresa alemana
Star Division la suite Star Office. En junio de 2000 se lanzó Star Office 5.2.
Para octubre de 2000 se publicaron los fuentes dando origen al proyecto
OpenOffice.
Rápidamente, se convirtió en uno de los proyectos más grandes del mundo de
software libre. Actualmente se estima que alcanza a los 7,5 millones de líneas
de código fuente en C++. OpenOffice cuenta con:
 un procesador de textos (Writer).
 una planilla de cálculos (Calc).
 un software de presentaciones (Impress).
 Un software para dibujo (Draw).
Una de las características más importantes es que el software es
multiplataforma. Corre en Solaris, GNU/Linux, Windows. A su vez se
encuentran en etapas de desarrollo las versiones para FreeBSD, MacOS X e
Irix. Entre sus funcionalidades principales se encuentra la posibilidad de abrir y
guardar documentos en formato Microsoft Office (97/2000/XP) y cuenta con
soporte para 27 idiomas.
Los archivos nativos de OpenOffice respetan el formato de intercambio de
datos de XML y sus especificaciones se encuentran disponibles al público en
general. La suite se encuentra licenciada bajo una modalidad dual que emplea
la LGPL y la licencia de Sun SISSL (Sun Industry Standards Source License).
Las implicancias de la LGPL ya fueron descriptas en la sección 4. Sobre la
SISSL, se puede destacar que obliga a mantener compatibilidad entre las
versiones. En el caso de no respetar la compatibilidad, se deberá publicar una
implementación de referencia para dar a conocer los detalles de la
modificación.
Como desventajas frente a la suite de Microsoft se puede resaltar que requiere
de mayor potencia de hardware para funcionar correctamente. Si se ejecutan
ambos en un mismo equipo, puede observarse claramente que los programas
de Sun tardan algunos segundos más en iniciarse. También durante la
operación, se nota que los programas de Microsoft responden con mayor
velocidad.
Este trabajo ha sido redactado utilizando las versiones de OpenOffice beta
0.639 y la flamante 1.0 lanzada en abril de 2002.
38Win API: Application Programming Interface de Windows. Es una gran cantidad de
características que facilitan la creación de software bajo Windows. Si un programador debe
crear un nuevo menú, no tiene que escribir todas las instrucciones nuevamente ya que en la
Win API se encuentra una rutina que hace esa tarea. La Win16 API es para Windows 3.X y la
Win32 API es para Windows 95 y superiores (32 bits).
9. Software Libre en la UADE
Introducción
A lo largo de esta sección se presentarán distintas alternativas para aprovechar
las ventajas que surgen del uso del software libre en el ámbito educativo. El
objetivo principal, es mostrar en qué puede beneficiarse una institución
educativa como la UADE de optar por este tipo de software.
Para un análisis más detallado, es conveniente separar en tres ramas de
estudio el caso puntual de la Universidad:
1. Usuarios de software en general : esta categoría corresponde a aquellos
que son usuarios de los equipos y las aplicaciones en general en toda la
Universidad.
2. Enseñanza de herramientas informáticas . Se refiere a las materias cuyos
objetivos son explicar el uso de determinadas aplicaciones informáticas.
3. Estudiantes de Sistemas . Incluye únicamente a los alumnos de la
carrera Informática.
En el caso de la UADE la inmensa mayoría de las computadoras utilizan
software propietario, y en particular alguna versión de MS Windows y MS
Office. Sin embargo, la elección de estos programas raramente es una decisión
meditada, ni suele estar basada en un análisis de las opciones disponibles.
Caso 1. Usuarios de software en general.
Este primer caso, hace referencia en su mayor parte al tipo de software
utilizado por la Universidad en sus computadoras. Las formas en la que se
beneficiaría la misma al emplear software libre en vez de software propietario
son numerosas y en gran parte se desprenden de lo expuesto a lo largo del
trabajo.
De los tres casos planteados, este es el que costaría más llevar a cabo. No
sólo monetariamente, ya que también habría que portar sistemas (o
desarrollarlos nuevamente) y capacitar usuarios, tareas que implican bastante
tiempo. Y por sobre todas las cosas, es necesaria una decisión política muy
importante.
No hay dudas de la gran ventaja que representaría a la Universidad tener el
control total de sus sistemas, pero también hay que tener en cuenta que se
corren muchos riesgos al abocarse a una tarea tan importante.
Caso 2. Enseñanza de herramientas informática.
Este punto es de importancia más que alta ya que tiene el objetivo replantear el
enfoque de las materias de informática que se imparten en la mayoría de las
carreras.
Hoy en día, a nadie se le ocurre pensar que un profesional pueda desconocer
el uso de la informática como herramienta productiva. En mayor o menor
medida, el mercado laboral requiere que los profesionales tengan
conocimientos de computación y que estén en condiciones de utilizar las
aplicaciones de uso habitual. Entre ellas se encuentran las suites de oficina
(planilla de cálculo, procesador de textos, software de presentaciones), manejo
de Internet y correo electrónico.
La educación relacionada con la informática es hoy día un monocultivo de
algunas marcas de software propietario. Sin realizar en muchos casos ningún
estudio previo, se elige como plataforma para la formación la que se percibe
como la más habitual.
Muchas veces no se tiene en cuenta si esta es la mejor opción posible. O peor
aún, se suele confundir la introducción a la informática con un curso de
introducción a cierto sistema operativo o los conocimientos sobre ofimática con
el conocimiento de una cierta marca de programa ofimático. En general, mucha
gente supone que saber de informática es lo mismo que saber manejar ciertas
herramientas propietarias, y fundamentalmente MS Windows y MS Office.
Por lo general, al justificar la elección de este tipo de educación se indica lo
siguiente:
 Es mejor enseñar el uso de la plataforma dominante en el mercado,
porque así lo enseñado será más útil al alumno.
 Los propios alumnos piden que se les enseñe el uso de ciertos
programas, y piensan que si se usan otros, los conocimientos les van a
ser de menos utilidad.
 No hay muchas alternativas, y en cualquier caso, no las hay con ventajas
claras sobre el uso de la plataforma dominante.
Estas razones no son válidas. Por otro lado, no es el objetivo de este planteo
rechazar la enseñanza basada en herramientas propietarias. El punto de esta
afirmación es que al alumno se le debe mostrar que hay alternativas, y que no
solamente existen Windows y Office. Porque en el caso que algún día cambie
el dominador del mercado esa persona va a sentirse excluida y no capacitada.
Sería de mayor utilidad enseñarle cómo funciona un procesador de texto en
general, y no únicamente los detalles del uso de MS Word ( ni de ningún otro
procesador de texto) en particular. Naturalmente habrá que hacer unas
prácticas, y en ellas lo ideal sería utilizar más de una herramienta. Trazando
una comparación con el concepto de aprendizaje de escritura, no se enseña a
usar una marca única de lapiceras, sino que se enseña a escribir y luego la
persona elige. De la misma forma, en la enseñanza de informática deberían
utilizarse las herramientas de la forma lo más genérica posible.
A su vez, la utilización de software libre brinda otras ventajas extra al docente:
1. Puede adaptarse a las necesidades de un curso dado. Puede, por
ejemplo, modificarse la aplicación determinada para ofrecer a los
alumnos una versión simplificada.
2. El alumno puede reproducir todo el entorno de prácticas, con total
exactitud, en cualquier otra computadora. En particular, en la
computadora de su casa, donde podrá practicar sin ningún problema de
licencias, y sin costos extra para el alumno. Además, el docente podría
entregar a sus alumnos un CD que incluya todas las herramientas
utilizadas.
Caso 3. Estudiantes de Sistemas.
Esta es la rama que más beneficios obtiene del uso de software libre. La
posibilidad de acceder al código fuente de herramientas reales de calidad
comercial enriquecen la enseñanza.
Materias del tipo de lenguajes de programación y sistemas operativos son las
que rápidamente pueden aprovechar los recursos libres que se encuentran
disponibles. Es posible enseñar con el ejemplo. Se encuentra a disposición de
los docentes compiladores y sistemas operativos completamente libres para ser
aprovechados.
Por ejemplo, armar un laboratorio con 30 máquinas para materias de
programación que incluyan la suite de Microsoft Visual Studio para enseñar C,
C++, Visual Basic y SQL Server para bases de datos implica altísimos costos
de licencias por cada computadora. En cambio, un laboratorio para enseñar los
mismos lenguajes (excepto Visual Basic) tendría costo nulo bajo una solución
de software libre. Aplicaciones como gcc, g++, gdb, PostgreSQL corriendo
sobre GNU/Linux son totalmente gratuitas y cumplen la misma función que la
solución propietaria. A la evidente ventaja económica, se agrega la ventaja
educativa extra de poder inspeccionar estos programas. De esta forma, los
alumnos pueden ver cómo funcionan los compiladores y sistemas operativos
'por dentro', cosa imposible con herramientas propietarias.
Una idea interesante para los laboratorios de software libre sería incorporar
como administradores a estudiantes de la carrera. De esta forma, los alumnos
pueden obtener y aplicar todos los conocimientos obtenidos. Ellos trabajarían
como administradores y complementarían lo aprendido en sus cursos. En
consecuencia, los estudiantes serían los encargados de mantener los sistemas
funcionando y también de encontrar, adaptar y construir nuevo software. A
aquellos que opten por este modelo de prácticas, podría entregársele un
certificado extra al graduarse.
Son más que numerosas y variadas las ventajas que representaría implementar
soluciones basadas en software libre en el ámbito de la Universidad. La
intención de esta sección ha sido enumerarlas para que puedan ser
consideradas y ponderadas frente al modelo actual.
Luego de estudiar en profundidad este modelo, el que escribe considera que la
Universidad se vería fuertemente beneficiada de optar por este tipo de
software.
En el caso de optar por una migración, la Universidad podría recurrir a sus
propios estudiantes para que aporten ideas y que colaboren en el proceso.
Sería una actividad de gran valor agregado para el estudiante poder participar
de un emprendimiento tan importante y a su vez complementaría los
conocimientos teóricos incorporados en las diversas materias.
Conclusiones
El principal objetivo de este trabajo, ha sido presentar una alternativa. Bajo
ningún concepto se quiere suponer que es la única solución posible. La
intención ha sido repasar la historia e ideales que forjaron este movimiento.
La primer opinión que se desprende del análisis efectuado es que, como en los
demás ámbitos de la vida, ninguna posición extrema es beneficiosa. Los
ideales filosóficos pregonados por Stallman, son los que lo incentivaron a crear
un movimiento de desarrollo de software que se asemeja en gran medida, a un
partido político. Nadie puede discutir que los logros obtenidos son más que
importantes, pero a su vez esa idea de autoexcluirse del resto del mundo es la
que ha llevado a su movimiento a perderse en confrontaciones poco
productivas y que solo sirven para el desgaste.
En una clara muestra de darwinismo digital, nació la idea de Open Source. El
concepto de software libre logró adaptarse y evolucionar para poder competir a
la par del modelo propietario. Es de esperarse que esta concepción continúe
creciendo, inversamente proporcional a la merma en la cantidad de adhesiones
al extremismo de Stallman.
Aún así, se está lejos de alcanzar un estado de las cosas dónde el Open
Source sea la alternativa más ajustada frente a los requerimientos de
informatización. De hecho, este software no ha alcanzado el grado de madurez
suficiente que le permita desplazar de los escritorios al software empaquetado,
fácil de instalar y utilizar. ¿ Qué diferencia presenta el código fuente para el
usuario normal que sólo quiere leer sus mensajes de correo electrónico? Los
que no sepan leer el código fuente no contribuirán demasiado al proyecto, y
ciertamente no van a darle mucho valor al hecho de conseguirlo.
Tampoco puede desconocerse la gran base de usuarios de Windows en los
escritorios (aproximadamente el 90%). Sin dudas, este es el mayor logro de la
empresa de Bill Gates, que ha llevado la computadora a millones de hogares.
Además, es común que la gente que ha elegido un producto o arquitectura de
computadora, le sean fieles siempre. Todo esto juega en favor de Microsoft y es
a su vez una barrera de entrada muy fuerte que el software libre deberá
superar si desea conquistar los escritorios de la gente común.
A los directivos de las empresas, que son los que mantienen las máquinas de
los escritorios de la gente, no le gustan los cambios. Los cambios significan
reeducación, significan instalar un nuevo software en toda la organización y
suponen trabajo extra. Requisar una oficina sale muy caro. El costo de comprar
nuevas computadoras y software suele ser más reducido que el costo de
reeducación. Aunque el mundo del software libre es mucho más barato, el
cambio no es fácil.
Pero, así como se reconoce que el software propietario es la solución que más
se ajusta a las necesidades del usuario hogareño típico y que supera a lo
ofrecido por el software libre, hay que destacar que en otros ámbitos el
software libre es el que va a la cabeza. El mercado de los servidores Web es
uno de los ejemplos más claros. Apache y GNU/Linux literalmente gobiernan
Internet, en gran parte por su precio (nulo) y las prestaciones ofrecidas.
La posibilidad de inspeccionar y modificar el código fuente brinda un abanico
de ventajas que deberían ser aprovechados en distintos campos. La formación
en ciencias de la computación, es el ámbito en el cual nació este movimiento y
la que más se beneficia por la libertad de inspeccionar las entrañas de las
aplicaciones. El software propietario y cerrado se transforma en un mundo
estático y lento, que solo permite obtener resultados pero no saber cómo llegó
a ellos.
El mayor desafío para el movimiento de software libre, se presenta en el campo
del mundo de los negocios. No son tantos los ejemplos de empresas que se
dediquen únicamente al software libre y que hallan logrado tener éxito. Quizá el
ejemplo más interesante es el de Cygnus Solutions, que a base de esfuerzos y
de una visión del negocio excelente se transformó en la encargada de
mantener el compilador gcc desplazando nada menos que a la Free Software
Foundation.
Son también destacables los emprendimientos conocidos como distribuciones
de GNU/Linux. Entre las más reconocidas se encuentran SuSE y Red Hat. Las
mismas mantienen sus estructuras cobrando por el soporte y a través de la
venta de manuales y cdroms con las últimas versiones de los programas.
Queda claro que el principal nicho a atacar es el de los servicios de valor
agregado. La posibilidad de modificar y redistribuir las herramientas, permite
que se personalicen las soluciones para las necesidades puntuales de cada
empresa. Esto brinda una ventaja más que interesante.
Hay muchos proyectos hoy en día que continúan existiendo gracias al aporte de
voluntarios y donaciones. En muchos casos estos grupos se encuentran
apadrinados por alguna universidad o centro de investigación que permite
mantener las estructuras funcionando.
Es por eso que aún queda mucho por recorrer y el movimiento debería poder
demostrar que es capaz de mantenerse por sí solo. Hasta el mismísimo
Stallman sufrió por varios años este asunto. Aunque renunció a su puesto en el
laboratorio de inteligencia artificial del MIT, las autoridades le permitieron
continuar viviendo en el campus y utilizar los equipos. Las donaciones y becas
que recibió a lo largo de su carrera le permitieron dedicarse por completo a su
proyecto.
Esto no apunta a indicar que esté mal recibir donativos, sino remarcar que el
movimiento (en muchos casos) no es capaz de generar ingresos para soportar
los gastos mínimos de estructura.
Otro de los puntos de estudio es el que se refiere al ingreso de las grandes
empresas a este movimiento. Sun Microsystems e IBM son las que han dado
los primeros pasos. Aunque en muchos casos generó suspicacias, estas
iniciativas son interesantes. Significan que desde el punto de vista de empresas
netamente comerciales, las ventajas del software libre han llevado a un
replanteo de sus propios modelos de negocios.
El tiempo dirá si esto ayuda al movimiento o si solamente contribuye a que
continúen las divisiones entre los que apoyan a la apertura de la comunidad y
los que quieren mantenerla como está.
A lo largo de este estudio logré conocer un mundo que presenta una alternativa
viable a la solución que en muchos casos se indica como única. Por suerte, los
usuarios de software en general contamos con la posibilidad de elegir en base
a nuestras necesidades y la opción existe. Esta opción se encuentra
acompañada de ideales que propugna: debate abierto, amplia circulación, el
fácil acceso y la completa revelación. El software libre crea riqueza, no dinero y
la riqueza es mucho mejor que el dinero. El software libre da poder a las
personas.
ANEXO I
Ejemplos de Mensajes de Respuesta
EJEMPLO 1
Usted envió el archivo adjunto en formato Microsoft Word, un formato
propietario y secreto, por lo que yo no puedo leerlo. Si Usted me envía el texto
puro, HTML o PDF, entonces yo podré leerlo.
Enviar a la gente documentos en formato Word tiene efectos perniciosos,
porque esta práctica los insta a utilizar software de Microsoft. En efecto, Usted
se convierte en un sostén del monopolio de Microsoft. Este problema específico
es un gran obstáculo a la adopción más amplia de GNU/Linux. ¿Podría, por
favor, reconsiderar el uso del formato Word en la comunicación con otras
personas?
EJEMPLO 2
Usted ha enviado el archivo adjunto en formato Microsoft Word, un formato
propietario y secreto, por lo que me resulta difícil de leer. Si Usted me envía
texto puro, HTML o PDF, entonces podré leerlo.
Distribuir documentos en formato Word es malo para Usted y para otros. Usted
no puede asegurarse de que se verán igual si alguien utiliza otra versión de
Word; hasta puede resultar imposible abrirlos.
Recibir archivos adjuntos en Word es malo para Usted porque pueden acarrear
virus (ver http://www.symantec.com/avcenter/venc/data/acro.html). Enviar
archivos adjuntos en Word es malo para Usted porque un documento de Word
normalmente contiene información oculta acerca del autor, permitiendo que
sean espiadas las actividades del autor (acaso las de Usted). Texto que Usted
creyó haber borrado puede permanecer embarazosamente presente. Ver
http://www.microsystems.com/Shares_Well.htm para más información.
Pero sobre todo, enviar documentos de Word a las personas las insta a utilizar
software de Microsoft y ayuda a negarles cualquier otra opción. En efecto,
Usted se convierte en un sostén del monopolio Microsoft. Esta presión es un
gran obstáculo contra la adopción más amplia de software libre. ¿Podría, por
favor, reconsiderar el uso del formato Word en la comunicación con otras
personas?
Convertir el archivo a HTML es simple. Abra el documento, haga clic en
Archivo, después en Guardar como, y, en la opción Guardar como tipo, en la
parte inferior de la ventana, elija Documento HTML o Página Web. Después
elija Guardar. Entonces Usted puede adjuntar el nuevo documento HTML en
vez de su documento Word. Note que Word cambia de manera inconsistente
(los nombres de los ítems en sus menús pueden ser ligeramente diferentes, por
favor intente con ellos).
Convertir a texto puro es casi lo mismo (en vez de Documento HTML, elija Sólo
texto o Documento de texto en la opción Guardar como tipo).
ANEXO II
PROYECTO DE LEY
El Senado y la Cámara de Diputados de la Provincia de Buenos Aires
sancionan con fuerza de:
L E Y
TITULO PRIMERO: DE LAS DEFINICIONES
Artículo 1º. A los efectos del cumplimiento de la presente ley,
entiéndese por:
a) Programa o "software" a cualquier secuencia de instrucciones usada por un
dispositivo de procesamiento digital de datos para llevar a cabo una tarea
específica o resolver un problema determinado.
b) Usuario a aquella persona física o jurídica que emplea el software.
c) Código fuente o de origen, o programa fuente o de origen, al conjunto completo
de instrucciones y archivos digitales originales creados y/o modificados por
quien los programara, más todos los archivos digitales de soporte, como tablas
de datos, imágenes, especificaciones, documentación, y todo otro elemento
que sea necesario para producir el programa ejecutable a partir de ellos.
Como excepción, podrán excluirse de este conjunto aquellas herramientas y
programas que sean habitualmente distribuidos como software libre por otros
medios como, entre otros, compiladores, sistemas operativos y librerías.
d) Programa (software) libre a aquél cuyo empleo garantice al usuario, sin costo
adicional, las siguientes facultades:
d.1) ejecución irrestricta del programa para cualquier propósito
d.2) acceso irrestricto al código fuente o de origen respectivo
d.3) inspección exhaustiva de los mecanismos de funcionamiento del programa
d.4) uso de los mecanismos internos y de cualquier porción arbitraria del
programa para adaptarlo a las necesidades del usuario.
d.5) confección y distribución pública de copias del programa.
d.6) modificación del programa y distribución libre, tanto de las alteraciones
como del nuevo programa resultante, bajo las mismas condiciones del
programa original.
Además, el costo de obtención de una copia del código fuente del programa por
parte del usuario no podrá ser significativamente mayor al costo habitual de
mercado en concepto de materiales, mano de obra y logística necesarias para
la confección de dicha copia.
e) Programa "no libre" o "propietario" a aquél que no reúna todos los requisitos
expresados en el artículo 1º inciso d) precedente.
f) Formato abierto a cualquier modo de codificación de información digital que
satisfaga las siguientes condiciones
f.1) la documentación técnica completa está disponible públicamente
f.2) el código fuente de al menos una implementación de referencia completa
está disponible públicamente.
f.3) no existen restricciones para la confección de programas que almacenen,
transmitan, reciban o accedan a datos codificados de este modo.
TITULO SEGUNDO: DEL ÁMBITO DE APLICACIÓN
Artículo 2º. Los Poderes Ejecutivo, Legislativo y Judicial, los
Organismos Descentralizados y las Empresas donde el Estado
Provincial posea mayoría accionaria, emplearán en sus sistemas y
equipamientos de informática exclusivamente programas (software)
libres.
Artículo 3º. La Autoridad de Aplicación de esta ley será el Poder
Ejecutivo o en quien este delegue esa responsabilidad con la
facultad de actuar sobre todos los niveles de la administración
pública provincial.
TITULO TERCERO: DE LAS EXCEPCIONES
Artículo 4º. En caso de no existir una solución que utilice software
libre y permita satisfacer una necesidad determinada, los organismos
estatales mencionados en el artículo 2º podrán adoptar las
siguientes alternativas, con el orden de prioridades sucesivo:
a) En caso de inexistencia o indisponibilidad de software no libre que permita dar
solución a la necesidad planteada, y que como consecuencia de ello se
determinara la necesidad de su desarrollo, la solución técnica resultante deberá
ser, en todos los casos, software libre, en los términos definidos en el artículo
primero de esta ley.
b) Si mediaran exigencias de tiempo verificables para la solución del problema
técnico, y se encontraran disponibles en el mercado programas (software) no
libres o propietarios, el organismo que lo demande podrá gestionar ante la
Autoridad de Aplicación un permiso temporario de utilización de software no
libre. La selección del producto deberá ser realizada de acuerdo al siguiente
orden de preferencia:
b.1) programas que cumplen con todos los criterios enumerados en
el Artículo 1º Inciso d, excepto por la de distribución del programa
modificado.
b.2) programas para los que existe un proyecto libre avanzado para
su reemplazo compatible.
b.3) otros programas.
Sólo en el caso b.1), el permiso de uso del programa no libre podrá
ser definitivo. En el caso b.2) el permiso caducará automáticamente
en el momento en que el producto libre pase a estar disponible con
la funcionalidad necesaria para satisfacer la necesidad concreta. En
el caso restante el permiso caducará periódicamente con un plazo
de validez no mayor a los dos años, y deberá ser renovado luego de
constatar que aún no existe una solución libre al problema.
El permiso temporario sólo será otorgado si el organismo estatal
solicitante garantiza el almacenamiento de los datos en formatos
abiertos.
Artículo 5º. Las entidades educativas y toda otra entidad dependiente del
Estado Provincial podrán, además, gestionar un permiso de empleo de
software no libre para su uso en investigación, siempre que el objeto de
investigación esté directamente asociado al uso del programa en cuestión.
TITULO CUARTO: DE LA PUBLICIDAD DE LAS EXCEPCIONES
Artículo 6º. Las excepciones emanadas de la Autoridad de Aplicación deberán
ser fundamentadas y publicadas en los medios que determine la
reglamentación. La fundamentación deberá enumerar los requisitos funcionales
concretos que el programa debe satisfacer.
Artículo 7º. Si cualquiera de los organismos comprendidos en el artículo
segundo fuera autorizado para adquirir o utilizar programas o software "no libre"
para almacenar o procesar datos cuya reserva sea necesario preservar, fueren
confidenciales, críticos o vitales para el desempeño del Estado, la Autoridad de
Aplicación deberá publicar, en los medios que determine la reglamentación,
además, un informe donde se expliquen los riesgos asociados con el uso de
software de dichas características para esa aplicación en particular.
TITULO QUINTO: DE LAS RESPONSABILIDADES
Artículo 8º. La máxima autoridad administrativa, junto con la máxima
autoridad técnica informática de cada organismo del Estado comprendido en
los alcances del artículo segundo precedente, serán solidariamente
responsables por el cumplimiento de esta ley.
TITILO SEXTO: DE LOS PLAZOS DE TRANSICIÓN
Artículo 9º. El Poder Ejecutivo reglamentará en un plazo de ciento ochenta
días las condiciones, tiempos y formas en que se efectuará la transición de el
estado actual a uno que satisfaga las condiciones de la presente ley y
orientará, en tal sentido, las licitaciones y contrataciones futuras de programas
de computación (software) realizadas a cualquier título.
Artículo 10. Se invita a los Gobiernos Municipales a adherir a esta iniciativa.
Artículo 11. Deróguese o modifíquese toda norma que se oponga a la
presente.
Artículo 12. Comuníquese al Poder Ejecutivo.
ANEXO III
GNU Free Documentation License
Version 1.1, March 2000
Copyright (C) 2000 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 021111307 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
0. PREAMBLE
The purpose of this License is to make a manual, textbook, or other written
document "free" in the sense of freedom: to assure everyone the effective
freedom to copy and redistribute it, with or without modifying it, either
commercially or noncommercially. Secondarily, this License preserves for the
author and publisher a way to get credit for their work, while not being
considered responsible for modifications made by others.
This License is a kind of "copyleft", which means that derivative works of the
document must themselves be free in the same sense. It complements the
GNU General Public License, which is a copyleft license designed for free
software.
We have designed this License in order to use it for manuals for free software,
because free software needs free documentation: a free program should come
with manuals providing the same freedoms that the software does. But this
License is not limited to software manuals; it can be used for any textual work,
regardless of subject matter or whether it is published as a printed book. We
recommend this License principally for works whose purpose is instruction or
reference.
1. APPLICABILITY AND DEFINITIONS
This License applies to any manual or other work that contains a notice placed
by the copyright holder saying it can be distributed under the terms of this
License. The "Document", below, refers to any such manual or work. Any
member of the public is a licensee, and is addressed as "you".
A "Modified Version" of the Document means any work containing the
Document or a portion of it, either copied verbatim, or with modifications and/or
translated into another language.
A "Secondary Section" is a named appendix or a frontmatter section of the
Document that deals exclusively with the relationship of the publishers or
authors of the Document to the Document's overall subject (or to related
matters) and contains nothing that could fall directly within that overall subject.
(For example, if the Document is in part a textbook of mathematics, a
Secondary Section may not explain any mathematics.) The relationship could
be a matter of historical connection with the subject or with related matters, or of
legal, commercial, philosophical, ethical or political position regarding them.
The "Invariant Sections" are certain Secondary Sections whose titles are
designated, as being those of Invariant Sections, in the notice that says that the
Document is released under this License.
The "Cover Texts" are certain short passages of text that are listed, as Front
Cover Texts or BackCover Texts, in the notice that says that the Document is
released under this License.
A "Transparent" copy of the Document means a machinereadable copy,
represented in a format whose specification is available to the general public,
whose contents can be viewed and edited directly and straightforwardly with
generic text editors or (for images composed of pixels) generic paint programs
or (for drawings) some widely available drawing editor, and that is suitable for
input to text formatters or for automatic translation to a variety of formats
suitable for input to text formatters. A copy made in an otherwise Transparent
file format whose markup has been designed to thwart or discourage
subsequent modification by readers is not Transparent. A copy that is not
"Transparent" is called "Opaque".
Examples of suitable formats for Transparent copies include plain ASCII without
markup, Texinfo input format, LaTeX input format, SGML or XML using a
publicly available DTD, and standardconforming simple HTML designed for
human modification. Opaque formats include PostScript, PDF, proprietary
formats that can be read and edited only by proprietary word processors, SGML
or XML for which the DTD and/or processing tools are not generally available,
and the machinegenerated HTML produced by some word processors for
output purposes only.
The "Title Page" means, for a printed book, the title page itself, plus such
following pages as are needed to hold, legibly, the material this License requires
to appear in the title page. For works in formats which do not have any title page
as such, "Title Page" means the text near the most prominent appearance of the
work's title, preceding the beginning of the body of the text.
2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either commercially
or noncommercially, provided that this License, the copyright notices, and the
license notice saying this License applies to the Document are reproduced in all
copies, and that you add no other conditions whatsoever to those of this
License. You may not use technical measures to obstruct or control the reading
or further copying of the copies you make or distribute. However, you may
accept compensation in exchange for copies. If you distribute a large enough
number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and you
may publicly display copies.
3. COPYING IN QUANTITY
If you publish printed copies of the Document numbering more than 100, and
the Document's license notice requires Cover Texts, you must enclose the
copies in covers that carry, clearly and legibly, all these Cover Texts: Front
Cover Texts on the front cover, and BackCover Texts on the back cover. Both
covers must also clearly and legibly identify you as the publisher of these
copies. The front cover must present the full title with all words of the title
equally prominent and visible. You may add other material on the covers in
addition. Copying with changes limited to the covers, as long as they preserve
the title of the Document and satisfy these conditions, can be treated as
verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit legibly, you should
put the first ones listed (as many as fit reasonably) on the actual cover, and
continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more
than 100, you must either include a machinereadable Transparent copy along
with each Opaque copy, or state in or with each Opaque copy a publicly
accessible computernetwork location containing a complete Transparent copy
of the Document, free of added material, which the general networkusing public
has access to download anonymously at no charge using publicstandard
network protocols. If you use the latter option, you must take reasonably prudent
steps, when you begin distribution of Opaque copies in quantity, to ensure that
this Transparent copy will remain thus accessible at the stated location until at
least one year after the last time you distribute an Opaque copy (directly or
through your agents or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the Document
well before redistributing any large number of copies, to give them a chance to
provide you with an updated version of the Document.
4. MODIFICATIONS
You may copy and distribute a Modified Version of the Document under the
conditions of sections 2 and 3 above, provided that you release the Modified
Version under precisely this License, with the Modified Version filling the role of
the Document, thus licensing distribution and modification of the Modified
Version to whoever possesses a copy of it. In addition, you must do these things
in the Modified Version:
A. Use in the Title Page (and on the covers, if any) a title distinct from
that of the Document, and from those of previous versions (which should,
if there were any, be listed in the History section of the Document). You
may use the same title as a previous version if the original publisher of
that version gives permission.
B. List on the Title Page, as authors, one or more persons or entities
responsible for authorship of the modifications in the Modified Version,
together with at least five of the principal authors of the Document (all of
its principal authors, if it has less than five).
C. State on the Title page the name of the publisher of the Modified
Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications adjacent to
the other copyright notices.
F. Include, immediately after the copyright notices, a license notice giving
the public permission to use the Modified Version under the terms of this
License, in the form shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections and
required Cover Texts given in the Document's license notice.
H. Include an unaltered copy of this License.
I. Preserve the section entitled "History", and its title, and add to it an
item stating at least the title, year, new authors, and publisher of the
Modified Version as given on the Title Page. If there is no section entitled
"History" in the Document, create one stating the title, year, authors, and
publisher of the Document as given on its Title Page, then add an item
describing the Modified Version as stated in the previous sentence.
J. Preserve the network location, if any, given in the Document for public
access to a Transparent copy of the Document, and likewise the network
locations given in the Document for previous versions it was based on.
These may be placed in the "History" section. You may omit a network
location for a work that was published at least four years before the
Document itself, or if the original publisher of the version it refers to gives
permission.
K. In any section entitled "Acknowledgements" or "Dedications", preserve
the section's title, and preserve in the section all the substance and tone
of each of the contributor acknowledgements and/or dedications given
therein.
L. Preserve all the Invariant Sections of the Document, unaltered in their
text and in their titles. Section numbers or the equivalent are not
considered part of the section titles.
M. Delete any section entitled "Endorsements". Such a section may not
be included in the Modified Version.
N. Do not retitle any existing section as "Endorsements" or to conflict in
title with any Invariant Section.
If the Modified Version includes new frontmatter sections or appendices that
qualify as Secondary Sections and contain no material copied from the
Document, you may at your option designate some or all of these sections as
invariant. To do this, add their titles to the list of Invariant Sections in the
Modified Version's license notice. These titles must be distinct from any other
section titles.
You may add a section entitled "Endorsements", provided it contains nothing but
endorsements of your Modified Version by various partiesfor example,
statements of peer review or that the text has been approved by an organization
as the authoritative definition of a standard.
You may add a passage of up to five words as a FrontCover Text, and a
passage of up to 25 words as a BackCover Text, to the end of the list of Cover
Texts in the Modified Version. Only one passage of FrontCover Text and one of
BackCover Text may be added by (or through arrangements made by) any one
entity. If the Document already includes a cover text for the same cover,
previously added by you or by arrangement made by the same entity you are
acting on behalf of, you may not add another; but you may replace the old one,
on explicit permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License give
permission to use their names for publicity for or to assert or imply endorsement
of any Modified Version.
5. COMBINING DOCUMENTS
You may combine the Document with other documents released under this
License, under the terms defined in section 4 above for modified versions,
provided that you include in the combination all of the Invariant Sections of all of
the original documents, unmodified, and list them all as Invariant Sections of
your combined work in its license notice.
The combined work need only contain one copy of this License, and multiple
identical Invariant Sections may be replaced with a single copy. If there are
multiple Invariant Sections with the same name but different contents, make the
title of each such section unique by adding at the end of it, in parentheses, the
name of the original author or publisher of that section if known, or else a
unique number. Make the same adjustment to the section titles in the list of
Invariant Sections in the license notice of the combined work.
In the combination, you must combine any sections entitled "History" in the
various original documents, forming one section entitled "History"; likewise
combine any sections entitled "Acknowledgements", and any sections entitled
"Dedications". You must delete all sections entitled "Endorsements."
6. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents
released under this License, and replace the individual copies of this License in
the various documents with a single copy that is included in the collection,
provided that you follow the rules of this License for verbatim copying of each of
the documents in all other respects.
You may extract a single document from such a collection, and distribute it
individually under this License, provided you insert a copy of this License into
the extracted document, and follow this License in all other respects regarding
verbatim copying of that document.
7. AGGREGATION WITH INDEPENDENT WORKS
A compilation of the Document or its derivatives with other separate and
independent documents or works, in or on a volume of a storage or distribution
medium, does not as a whole count as a Modified Version of the Document,
provided no compilation copyright is claimed for the compilation. Such a
compilation is called an "aggregate", and this License does not apply to the
other selfcontained works thus compiled with the Document, on account of
their being thus compiled, if they are not themselves derivative works of the
Document.
If the Cover Text requirement of section 3 is applicable to these copies of the
Document, then if the Document is less than one quarter of the entire
aggregate, the Document's Cover Texts may be placed on covers that surround
only the Document within the aggregate. Otherwise they must appear on covers
around the whole aggregate.
8. TRANSLATION
Translation is considered a kind of modification, so you may distribute
translations of the Document under the terms of section 4. Replacing Invariant
Sections with translations requires special permission from their copyright
holders, but you may include translations of some or all Invariant Sections in
addition to the original versions of these Invariant Sections. You may include a
translation of this License provided that you also include the original English
version of this License. In case of a disagreement between the translation and
the original English version of this License, the original English version will
prevail.
9. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as
expressly provided for under this License. Any other attempt to copy, modify,
sublicense or distribute the Document is void, and will automatically terminate
your rights under this License. However, parties who have received copies, or
rights, from you under this License will not have their licenses terminated so
long as such parties remain in full compliance.
10. FUTURE REVISIONS OF THIS LICENSE
The Free Software Foundation may publish new, revised versions of the GNU
Free Documentation License from time to time. Such new versions will be
similar in spirit to the present version, but may differ in detail to address new
problems or concerns. See http://www.gnu.org/copyleft/
Each version of the License is given a distinguishing version number. If the
Document specifies that a particular numbered version of this License "or any
later version" applies to it, you have the option of following the terms and
conditions either of that specified version or of any later version that has been
published (not as a draft) by the Free Software Foundation. If the Document
does not specify a version number of this License, you may choose any version
ever published (not as a draft) by the Free Software Foundation.
Referencias Bibliográficas
H. M. Dietel
Sistemas Operativos 2da Edición
Adisson Wesley Iberoamericana
Paul Adams, Bruce Larson
Unix Para impacientes
Adisson Wesley Iberoamericana.
Andrew Tanenbaum
Sistemas Operativos Modernos
Primera edición, 1993.
Prentice Hall.
Brian Kernighan, Dennis Ritchie
El Lenguaje de Programación C
Segunda edición, 1991.
Prentice Hall.
Sam Williams
Free as in Freedom. Richard Stallman's crusade for free software.
Primera edición, Marzo 2002
O'Reilly & Associates.
Peter Wayner
La ofensiva del software libre.
Primera edición, 2001.
Ediciones Granica.
Brian Behlendorf, Scott Bradner, Jim Hamerly, Kirk McKusick, Tim
O'Reilly, Tom Paquin, Bruce Perens, Eric Steven Raymond, Richard
Mathew Stallman, Michael Tiemann, Linus Torvalds, Paul Vixie, Larry Wall,
Bob Young, Chris DiBona, Sam Ockman, Mark Stone.
Open Sources: Voices from the Open Source Revolution.
Primera edición, Enero 1999
O'Reilly & Associates.
Otras Fuentes:
Transcripción de la conferencia de Richard Stallman “ El Copyright en la
era de los computadores”
Lugar: Universidad de Budeos, Francia
Fecha: 07/07/2000
Transcripción de la charla de Richard Stallman “ Software Libre: Libertad
y Cooperación”
Lugar: Universidad de Nueva York, Estados Unidos
Fecha: 29/05/2001
Revista: Users Linux “Presentamos a UTUTO”
Año 1 Número 3
Páginas 20 a 22
Diario Clarín “Los pesados y a veces peligrosos archivos adjuntos de los
emails”
Página 33
Fecha: 25/03/2002

Investigacion Sobre El Movimiento Del Software Libre

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Investigacion Sobre El Movimiento Del Software Libre

Uploaded by

Copyright:

Available Formats

Investigación sobre el

Versión 24 de Mayo de Se Eliminaron gifs. Se Modificaron pequeños errores de tipeo.

1991 1992 1993 1994 1995 ... 2002

Marcelo Dragan Omar Enrique Becerra Rosana Andrea Bertone

You might also like