Investigación 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