Investigacion+sobre+el+movimiento+del+software+libre

Investigación sobre el Movimiento del Software Libre

Pablo Luis Zorzoli [email protected] 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  0.4  2003 

Se Eliminaron gifs. Se Modificaron pequeños errores de tipeo.  Se agregaron varios links de referencia. Disponible en tar.gz 

Versión  16 de Abril de  0.2  2003 

Primera publicación 

FUENTE: http://www.z­labs.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           Consideraciones Finales 

6. Eric Steven Raymond 

         La Catedral y el Bazar           Netscape y el Bazar           Los Documentos Halloween           Consideraciones Finales 

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

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

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 PDP­7. 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 PDP­7 a las  modernas PDP­11/20, PDP­11/45 y PDP­11/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 PDP­11/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 CD­Roms 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

Networking  Release /2

386BSD

FreeBSD

1994

1995

4.4 BSD  Lite

FreeBSD

...

2002

NetBSD

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.   8 DARPA:    :   Agencia de proyectos avanzado de investigación de defensa.   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  PDP­10 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/initial­announcement.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/initial­announcement.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/byte­interview.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/no­word­attachments.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 e­mails” (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.

Consideraciones Finales 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 1983­84).  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) Ver Licencia Completa 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).

Detalles Importantes  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 Ver Licencia Completa en http://www.opensource.org/licenses/bsd­license.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.

Detalles Importantes  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 Ver Licencia Completa 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 ad­honorem 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) Ver Licencia Completa en http://www.opensource.org/licenses/mit­license.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

Licencia

Puede mezclarse  con software no  libre

Modificaciones  pueden tornarse  privadas y no  retornarse a los  demás

Puede  relicenciarse por  cualquiera

Contiene  privilegios  especiales para el  titular de los  derechos de autor  sobre los cambios

GPL LGPL

X

BSD

X

X

NPL

X

X

MPL

X

X

MIT

X

X

X

Dominio  Público

X

X

X

X

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 MIT­Consorcio X y la licencia  Artística (http://www.opensource.org/licenses/artistic­license.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.

VOVIDA Software License.

Licencia de bases de datos de  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.

Consideraciones Finales 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/cathedral­bazaar/

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/magic­cauldron/): 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. 

Consideraciones Finales 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 (5613­D­00) pasó a archivo y fue  presentado uno nuevo en la Cámara de Diputados del Congreso Nacional (904­ D­029). Este se basa en el anterior, e incorpora las mejoras que fue recibiendo  durante dos años.

Proyecto de Ley 904­D­02 Autores: Marcelo Dragan

Omar Enrique Becerra

Rosana Andrea Bertone

Diputado nacional Tierra del Fuego Partido Acción por la  República

Diputado nacional  Tierra del Fuego Partido Justicialista

Diputada nacional  Tierra del Fuego Partido Justicialista

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 904­D­02 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 CD­ROM, 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.

Consideraciones Finales 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 Half­Life. 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.  Consideraciones Finales 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  02111­1307  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 front­matter 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 Back­Cover Texts, in the notice that says that the Document is  released under this License.  A "Transparent" copy of the Document means a machine­readable 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 standard­conforming 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 machine­generated 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 Back­Cover 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 machine­readable Transparent copy along  with each Opaque copy, or state in or with each Opaque copy a publicly­ accessible computer­network location containing a complete Transparent copy  of the Document, free of added material, which the general network­using public  has access to download anonymously at no charge using public­standard  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 front­matter 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 parties­­for 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 Front­Cover Text, and a  passage of up to 25 words as a Back­Cover Text, to the end of the list of Cover  Texts in the Modified Version. Only one passage of Front­Cover Text and one of  Back­Cover 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 self­contained 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   e­mails” Página 33 Fecha: 25/03/2002