Introducción al Software Libre Plan Evaluación Continuada N° 3 Jorge Alberto Arocha Muñoz
1. De las siguientes licencias, decir: Cuáles son copyleft "fuerte", cuáles copyleft "débil" en un par de líneas explicando la razón de la respuesta a) CDDL Copyleft débil, ya que en el numeral 3.5 autoriza a distribuir el software con o sin modificaciones en forma de ejecutables sin obligar a publicar el código fuente, con la misma licencia o con la que el usuario lo desee. b) Sleepycat or Berkeley Database License Copyleft fuerte, es un licencia de tres clausulas y la consabida renuncia a la garantía, en ella se especifica que además de distribuir el software con la misma licencia el que lo reciba debe hacerlo también en el mismo sentido, además debe estar disponible la forma de obtener el código fuente de la base de datos y del software que la usa. c) eCos 2.0 Copyleft débil, porque esta licencia es una modificación de la GPL que hace que termine comportándose como la LGPL, lo cual permite que software que se enlaza al software origina sea licenciado bajo cualquier licencia posteriormente. d) Affero GPL Copyleft fuerte, en líneas generales es una licencia GPL con una modificación para el software que puede ser usado sobre la red de datos como un servicio, en este caso como la persona no está redistribuyendo el software, pues el usuario no recibe el software como tal y la licencia, el usuario que recibe el servicio prácticamente estaría ante un software propietario pues la persona que brinda el servicio no está obligada a cumplir las cuatro libertades del software libre, con esta clausula se garantiza que el usuario del software tenga disponible el código fuente y además que este tipo de uso sea con la misma licencia. e) Eclipse Public License Copyleft débil, en el tercer ítem de la licencia estable que quien recibe el software puede redistribuirlo en forma de código objeto siempre y cuando se cumplan ciertas condiciones, entre las cuales se encuentra colocar a disposición el código fuente, esta clausula, en mi interpretación, permite que se puedan cambiar completamente los términos de la licencia original. 2. Explicar por qué puede ser conveniente licenciar la documentación de un programa GPL bajo la GPL, en lugar de usar la GFDL. Aunque son dos licencias que en esencia buscan lo mismo están diseñadas para ser aplicadas sobre distintos tipos de trabajos, los cuales cada uno tiene sus particularidades, el
Introducción al Software Libre Plan Evaluación Continuada N° 3 Jorge Alberto Arocha Muñoz
problema radica en la obligación de conservar una serie de textos inmodificables (en la licencia son llamadas "Secciones Invariantes") establecida en la GFDL lo que plantea una restricción a la libertad como se podría entender desde la óptica de la GPL, pero mas allá del sentido filosófico está la parte practica en el sentido en que estas secciones además de no poderse modificar tampoco se pueden eliminar, es así como no se puede en determinado momento tomar un programa licenciado bajo GPL cuya documentación este en GFDL, incluir parte de la documentación o manuales como ayuda del software y luego licenciar todo GPL, a menos que se conserven estas secciones invariantes o se cuente con que el autor nos relicencie su documentación. Por esta razón hay quienes consideran que realmente la GFDL no es una licencia libre, en especial Debian durante un tiempo no incluía la documentación licenciada bajo esta licencia dentro de su repositorio main, aunque en la actualidad desde el 16 de marzo de 2006 acepta este tipo de documentación siempre y cuando no tenga "Secciones Invariantes". Tiempo: ¿Cuánto tiempo te ha llevado responder a esta parte? 3 Horas Parte B: 3. Describir cuatro características particulares de la Ingeniería del Software Libre que la distingan de la Ingeniería del Software habitual y que apoyen a los modelos de negocio señalados por Hecker y/o Fuggetta. a) Levantamiento de Información y requerimiento de usuarios: Aunque este aspecto la ingeniería de software libre es mas bien informal, pues no existen documentos ni diseños elaborados, y en general corresponde a las apreciaciones de esa primera persona que tiene la necesidad (o grupo como un solo ente) que inicia el desarrollo, este es complementado con las listas de usuarios o mecanismos que esa comunidad proponga para plantear nuevos requerimientos. Modelos Apoyados: Clasificación Hecker: Sell it, free it. Los requerimientos planteados por usuarios en las versiones libres permiten enriquecer el software y de esta forma mejorar el producto que inicialmente se licencia como propietario. Clasificación Fuggetta: Desarrollo y distribución de paquetes de código abierto 'puros', desarrollados para plataformas de código abierto y propietarias, y que hacen una línea de producto más atractiva. b) Desarrollo distribuido: La colaboración de mas de un desarrollador, independientemente de las motivaciones que tenga, con el desarrollo de un producto de software libre permite tener productos finales a menor coste que un software propietario, evitando inconvenientes de administración de
Introducción al Software Libre Plan Evaluación Continuada N° 3 Jorge Alberto Arocha Muñoz
personal, etc. Se puede ver como un doble beneficio, para el producto: como se comentó anteriormente la disminución de costos y contar con mano de obra para el desarrollo y para la empresa o persona: el conocimiento que le da participar en el desarrollo la habilita para brindar servicios, realizar otros desarrollos, implementar y plantear nuevas funcionalidades, etc. Modelos Apoyados: Todos los modelos propuestos por Hecker y Fuggetta se pueden apoyar en esta característica, porque si la empresa cuenta con desarrolladores que participen en un software que sea libre y la empresa lo tiene como base de negocio, se benefician de tener personas que participen en el desarrollo de ese proyecto para obtener mayor conocimiento y pericia del producto, de otra forma si es la empresa la que desarrolla y lidera el proceso de desarrollo de un producto le conviene tener desarrolladores a bajo costo. c) Documentación y traducciones: El proceso de documentación, manuales e internacionalización dentro del software libre se hace por lo general con voluntarios también que participan dentro del proyecto, de manera similar al caso anterior, esta característica apoya los modelos de negocio en dos formas posibles: el conocimiento y pericia que se adquiere durante el proceso para después utilizarlo en provecho del negocio o la facilidad de disponer de personas voluntarias que realicen este trabajo y lo compartan con nosotros, de esta manera se cuenta con una cantidad de personas trabajando sin necesidad de contar con muchos recursos económicos. Modelos Apoyados: Con el mismo razonamiento que el literal anterior se puede afirmar que esta característica apoya todos los modelos de negocio planteados por Hecker y Fuggetta. d) Usuarios, tester y solución de errores: El software libre facilita la detección de errores, al mismo tiempo que disminuye lo gastos y tiempos de corrección de los mismos, como se menciona en La Catedral y el Bazar, "Con un buen estímulo, los usuarios diagnosticarán problemas, sugerirán correcciones y ayudarán a mejorar los programas mucho más rápido de lo que uno lo haría sin ayuda." Modelos Apoyados: Clasificación Hecker: Support seller y Sell it, free it. Estos dos modelos son los que se dedican realmente al desarrollo de software y como tal son los que se apoyan en esta característica. Clasificación Fuggetta: Esta característica apoya los modelos de Fuggetta que se basan en el desarrollo o distribución de software libre, es decir los modelos 1, 2 y 4, sin embargo esta
Introducción al Software Libre Plan Evaluación Continuada N° 3 Jorge Alberto Arocha Muñoz
característica podría apoyar los modelos planteados en los numerales 3 y 5 pero no en la misma cantidad que en los otros pues al ser software propietario o un desarrollo a medida, así sea libre, no tienen la misma facilidad de llegar a una gran cantidad de usuarios que el software libre. 4. Ingeniería del software libre. Escoged un proyecto de software libre y analizad hasta qué punto sigue las pautas marcadas en la "Catedral y el Bazar". Nombre: Geographic Resources Analysis Support System - GRASS Descripción: Es un Sistema de Información Geográfica, usado para el manejo de información geoespacial y tratamiento de imágenes, en la actualidad es uno de los mas avanzados y maduros de Software libre. Inicialmente fué desarrollado por el Cuerpo de Ingenieros del ejercito de Estados Unidos (USA-CERL) como una herramienta de soporte dentro de su trabajo en administrar los terrenos del ejercito y la planeación ambiental, como tuvo gran aceptación dentro de varios organismos gubernamentales, académicos y privados el software fue licenciado como de dominio público. Hasta el año 1995 con la versión 4.1 fué desarrollado por el USA-CERL, posteriormente su desarrollo fue continuado en la Universidad de Baylor, posteriormente liderado por Markus Neteler del Instituto Trentino de Cultura (ITC), en 1999 se cambia su licencia a GPL y en la actualidad el proyecto es liderado por un comité directivo (1). Url: http://grass.itc.it/ Número de Desarrolladores: Desde 1982 en que comenzó su desarrollo se han involucrado gran cantidad de personas y diferentes agencias gubernamentales, privadas, educativas, etc. sin embargo después de 26 años lasa personas que han intervenido en su de desarrollo se encuentran listadas en (2), en la actualidad según su página web oficial(3) cuenta con 17 desarrolladores, mas sin embargo el sitio de ohloh (4), Ohloh es un sitio web que provee conjuntos de servicios Web y plataforma para comunidades virtuales que tiene por objeto el mapear el paisaje del desarrollo código abierto, muestra que tiene 61 desarrolladores (5). Herramientas: a) Lenguajes:
Introducción al Software Libre Plan Evaluación Continuada N° 3 Jorge Alberto Arocha Muñoz
C HTML C++ Python Tcl shell script Perl CSS b) Otras herramientas Autoconf Make TeX/LaTeX c) Como algo importante en este tipo de proyectos para coordinar el desarrollo está el control de versiones se usa SVN. d) También usa Trac y Wiki. d) No se tiene referencia de ningún IDE o editor de textos en especial. Discusión: * "Todos los trabajos buenos en software comienzan tratando de paliar un problema personal del que los programa." Respecto a este punto no interpreto literalmente "problema personal", se entiende que ese personal hace referencia a una persona o entidad (empresa, universidad, agencia gubernamental, etc.), en ese orden de ideas esete software surge de la necesidad específica del Cuerpo de Ingenieros del Ejercito de Estados Unidos (USA-CERL) de un programa que soportara la administración de tierras y la planeación ambiental. En este orden de ideas se considera que si lo cumple. * "Tratar a tus usuarios como colaboradores es el camino menos complicado para mejorar con rapidez y depurar eficazmente un programa." En la misma página web del software se anima a los usuarios a colaborar activamente en el proyecto, ea con sugerencias, pruebas, documentación o desarrollo. Cuenta con Trac para el seguimiento de errores y un sistema de listas de correo (6) para dar dinámica a esta característica de desarrollo del software libre. * "Lánzalo pronto. Lánzalo a menudo. Y escucha a tus usuarios."
Introducción al Software Libre Plan Evaluación Continuada N° 3 Jorge Alberto Arocha Muñoz
No siempre ha sido así, teniendo especial cuidado que en un principio el desarrollo correspondió a un proceso clásico de software dentro de una agencia gubernamental, aunque desde 1992 comienza su desarrollo conforme a una comunidad de software libre pocas nuevas versiones se hicieron hasta 1999, yendo desde la 4.1 a la 4.3, en lo últimos años si se ha correspondido con esta máxima, teniendo tres ramas el proyecto: estable, no estable y nuevo desarrollo. En la página web de GRASS (7) se puede observar la celeridad con que han sido liberados los releases. * "Dada una base lo suficientemente amplia de probadores y colaboradores, casi todos los problemas se identificarán con rapidez y su solución será obvia para alguien." Evidentemente basta con repasar el trac del proyecto para notarlo. Tiempo: ¿Cuánto tiempo te ha tomado responder a la parte B? 3 Horas
(1) http://grass.osgeo.org/wiki/GRASS_Project_Steering_Commitee (2) http://grass.itc.it/devel/grasscredits.html http://trac.osgeo.org/grass/browser/grass/trunk/AUTHORS (3) http://grass.itc.it/community/team.php (4) http://www.ohloh.net (5) http://www.ohloh.net/p/grass_gis/contributors (6) http://grass.itc.it/community/support.php (7) http://grass.itc.it/devel/grasshist.html