Brave GNU World

Hola a todos, estoy contento de presentar el cuarto número del Brave GNU World. Empezaré la columna de este mes recogiendo algunas reacciones que he recibido después del primer número.

 ¿Software GNU comercial?

 Después de mi artículo sobre el renombrado de la LGPL recibí varios correos protestando sobre mi preferencia de la GPL sobre la LGPL. Como ejemplo, citemos un mensaje de Marcel Ruff (nota: el autor tradujo esta cita al inglés para que sea entendido; la cita original se puede encontrar en la versión en alemán): "Creo que todo el Software Libre debería ser publicado bajo la LGPL, porque esto es de la mayor importancia en mezclas de software Libre y comercial." Este argumento parece lógico pero se basa en una asunción errónea, dejadme elaborarlo.

 ¿Cuál es exactamente la diferencia entre la LGPL y la GPL? La GNU General Public License garantiza a cada usuario el derecho a usar, modificar y copiar el software de la forma que desee. Para proteger este derecho el código licenciado bajo la GPL nunca podrá ser utilizado en programas propietarios. Este no es el caso con la LGPL. Aun cuando la licencia del software no puede ser cambiada nunca, permite explícitamente el uso en todos los programas (incluso los propietarios). La propietariedad significa que una persona o firma exige ser la única autoridad independientemente de quién pueda poseer o usar una cierta parte del software. Pero hemos estado hablando de software comercial que es software con el cual las personas o entidades ganan dinero. Esto plantea la cuestión fundamental de si el software comercial necesita ser propietario. El Proyecto GNU lleva diciendo mucho tiempo que este no es el caso y el éxito de GNU/Linux lo ha probado.

 Existen un montón de razones para publicar el software como Software Libre y el intento de explicar esto a los gestores a mantenido a un montón de gente ocupada durante años; el más sobresaliente ejemplo de estos intentos es el movimiento de "Fuente Libre" (Open Source).

 Pero esto no es sobre las ventajas del Software Libre, es sobre la cuestión de si se debe preferir la GPL o la LGPL. Para algún software es muchos más sensato de manera incuestionable el ser publicado bajo la LGPL; sin embargo, esto debe ser decidido en base a cada caso. En general el Proyecto GNU piensa que la GPL se debe preferir. Una de las razones es dar al Software Libre comercial un ventaja extra en la competencia. Esta ventaja extra combinada con las ventajas del Software Libre puede ser todo los que una pequeña firma necesita para tener éxito.

 Esta es la teoría por este mes, mi siguiente tema será ciertamente de interés para los productores de software comercial porque elegir la organización correcta puede ser crucial. Incluso en proyectos con sólo un desarrollador una buena estructura puede ahorrar muchas horas de trabajo, para proyectos distribuidos con múltiples desarrolladores puede ser casi como salvar la vida. Por esta razón me gustaría presentar a

 Aegis

 Aegis [4] de Peter Miller es un proyecto corriendo en casi todas las plataformas UNIX y, dado que está basado en el Autoconf de GNU, la instalación es fácil y rápida. De forma similar a otros proyectos Aegis tiene un archivo central, llamado repositorio. El repositorio contiene todas las versiones del proyecto desde que comenzó, así uno puede fácilmente volver a versiones más antiguas o desarrollar simultáneamente dos ramas diferentes del mismo proyecto.

 El repositorio no se cambia nunca directamente. Los desarrolladores crean árboles de código fuente locales para trabajar sobre ellos. Los cambios hechos en el código fuente se ponen en "Conjuntos de cambio" donde todos los cambios durante un ciclo de trabajo son recogidos. Aegis esta construido sobre el mantenimiento de la versión actual ejecutable y tan libre de bugs como sea posible, por ello cada Conjunto de Cambio incorpora al menos un test. Estos tests se convierten en parte del repositorio cuando el Conjunto de Cambio es implementado en el repositorio, esto hace posible asegurar que el nuevo código no rompe ninguna rutina antigua ejecutando tests "históricos". Mediante seguir la pista también de las dependencias de los ficheros fuente en el repositorio Aegis puede sugerir programas test que sean coherentes  con el nuevo Conjunto de Cambio. Sólo si los tests incluidos y una operación build tienen éxito se acepta un Conjunto de Cambio. Para ser finalmente parte del repositorio necesita ser revisado y terminado una vez.

 Esto puede parecer un poco complicado pero tiene ciertas ventajas. Con otros sistemas a veces se convierte en un problema importante el hecho de que se bloquee un fichero tan pronto como un desarrollador anuncia que pudiera estar pensando en cambiar algo del fichero. Esto crea un cuello de botella con ficheros populares que está siendo evitado por los Conjuntos de Cambio. Aegis también pone parte del trabajo de control de calidad dentro del proceso de desarrollo sin retardarlo de forma noticiable. Por ejemplo, la terminación de los cambios puede ser hecha por cada desarrollador, un grupo central de desarrolladores, un comité externo o el responsable del proyecto; lo que se adecue mejor a las necesidades del proyecto. En cada caso se tiene a alguien que autorizó los cambios. Este sistema también asegura que el proceso de desarrollo produce directamente versiones probadas y ejecutables. Esto puede ser extremadamente valioso para las firmas porque están capacitadas para dar un versión actual a sus clientes en cualquier momento dado.

 Lo que personalmente me gusta mucho  es el hecho de que las versiones locales no necesitan ser aisladas del repositorio. Aegis soporta actualizaciones "push and pull", así un cambio en el repositorio puede ser transferido a los directorios de trabajo automáticamente.

 Sin entrar demasiado en detalles dejadme mencionar sólo que Aegis soporta múltiples repositorios distribuidos, permite que los Conjuntos de Cambio sean transportados por correo electrónico o HTTP y ha sido escrito teniendo en cuenta aspectos de seguridad.

 Pero ahora me gustaría hablar sobre dos proyectos que deberán ser de interés para el usuario "normal" también. El mantenedor del GNU Enscript, Markku Rossi, me pidió que escribiera un poco acerca del estado y planes de su proyecto.

 GNU Enscript

 GNU Enscript es un programa que convierte ASCII a PostScript, ANSI (secuencias de escape de terminal), HTML, Overstrike (secuencias de escape de nroff como en las páginas del manual) o RTF.

 A pesar de que su código está siendo reescrito actualmente, GNU Enscript soporta realce sensible al lenguaje desde la versión 1.5.1. Esto es de alguna forma parecido a los modos "font lock" de Emacs. El tipo de fichero es reconocido y ciertas partes del texto (por ejemplo, los comentarios en una programa en C) son realzados de la forma que defina el usuario. Un ejemplo de como usarlo sería publicar código fuente en la web sólo con pasarlo por enscript una vez. Si estás echando de menos estilo en tu instalación, la página de GNU Enscript de Markku Rossi [5] es probablemente el lugar a ir; Enscript soporta actualmente 42 lenguajes y tipos de ficheros diferentes.

 El nuevo motor de realzado es más rápido y fácil de configurar que el anterior, porque define las reglas de realzado, los estilos y los lenguajes de salida en capas separadas que se pueden cambiar sin afectar unas a las otras. Si estás interesado en echar un vistazo, la versión beta [6] utiliza ya este nuevo motor.

 En este contexto me gustaría presentar otro proyecto interesante.

 Ted

 Ted [7] es un procesador simple de "rich text" de Mark de Does. Permite al usuario simplemente escribir en un  mensaje electrónico o carta en estilo wysiwyg. Dado que el RTF se utiliza como formato nativo del fichero, el intercambio de documentos con Microsoft Word o Wordpad no es un problema. Ted también se puede usar como visualizador de RTF para Netscape. El objetivo del proyecto es conseguir una aplicación fácil de usar para la máxima portabilidad con la "Esfera Windows".

 A pesar de que el autor ahora preferiría GTK+, Ted está basado en Motif; conseguir que las relaciones entre la pantalla y la impresora sean correctas e implementar otros alfabetos además del Latin1 es lo más importante en este momento. La ayuda en estas tareas es bienvenida.

 Me gustaría finalizar este número con otra de mis ideas. Construyendo una pagina web últimamente no fui capaz de encontrar ningún icono "Nosotros ejecutamos GNU" para páginas web. Pensando me he dado cuenta que nunca he visto tal ícono. Por favor, siéntete libre de enviar ideas de diseño así como preguntas, comentarios e ideas sobre la columna vía correo electrónico [1].
 

Info

[1] Envía ideas, comentarios y preguntas a Brave GNU World <column@gnu.org> [2] Página del proyecto GNU http://www.gnu.org/ [3] Página del Brave GNU World  de Georg http://www.gnu.org/brave-gnu-world/ [4] Página de Aegis http://www.canb.auug.org.au/~millerp/aegis/ [5] Página de GNU Enscript por Markku Rossi http://www.iki.fi/mtr/genscript/ [6] Versión Beta de GNU Enscript ftp://alpha.gnu.org/gnu/enscript-1.6.2.tar.gz [7] Página de Ted http://www.nllgg.nl/Ted/

Volver a Página de GNU.

Por favor envía las preguntas y peticiones de información acerca de FSF y GNU gnu@gnu.org. También hay otras formas de contactar con la FSF.

Por favor envía los comentarios sobre la columna Brave GNU World a column@gnu.org, envía los comentarios sobre estas páginas web a webmasters@www.gnu.org, envía otras preguntas a gnu@gnu.org.

Copyright (C) 1999 Georg C. F. Greve, versión en Alemán publicada en Linux-Magazin

Se concede Permiso para realizar y distribuir copias literales de esta transcripción siempre  que aparezcan el copyright y esta nota de permiso.

Actualizado:13 mayo 1999 greve