Gestión de proyectos de software libre (II). Decidiendo continuar.

proyectos software libreEn esta segunda entrega de la serie de posts sobre la gestión de software libre (traducción del texto original de Benjamin Mako Hill), decidimos seguir adelante con el proyecto y “Mako” nos explica cómo ponerle nombre y cómo licenciarlo.

Decidiendo continuar.

Una vez que has tanteado el terreno de forma satisfactoria y tienes una idea sobre qué tipo de software similar existe, todo desarrollador necesita decidir continuar con su propio proyecto. Es raro que un nuevo proyecto busque lograr un objetivo que no sea totalmente similar o no esté relacionado de ninguna manera al el objetivo de otro proyecto. Cualquiera que arranque un nuevo proyecto debe preguntarse: ¿Estará el nuevo proyecto duplicando trabajo hecho ya por otro proyecto? ¿Estará el nuevo proyecto compitiendo por desarrolladores de un proyecto existente? ¿Es posible conseguir el objetivo del nuevo proyecto añadiendo funcionalidad a un proyecto existente?.

Si la respuesta a alguna de estas preguntas es “si”, intenta contactar con el desarrollador del proyecto o proyectos existentes para saber si estaría dispuesto a colaborar contigo.

Para muchos desarrolladores este puede ser la parte más difícil de la gestión de un proyecto de software libre, pero se trata de una parte esencial. Es fácil que se te encienda la bombilla y te dejes llevar por el momento y el entusiasmo de un nuevo proyecto. A menudo hacerlo es dificilísimo, pero es importante que todo desarrollador de software libre recuerde que a menudo no arrancar un esfuerzo de nuevo desarrollo es más provechoso para la comunidad de software libre y es la manera más rápida de lograr los objetivos de tu propio proyecto así como los objetivos de proyectos similares.

Poniendo nombre a tu proyecto.

Aunque existen muchos proyectos que fracasan con nombres descriptivos y muchos otros que han tenido éxito sin, creo que es bueno pensar un poco a la hora de ponerle nombre a tu proyecto. Leslie Orchard trata esta cuestión en un Advogato article. Su artículo es pequeño y decididamente es bueno examinarlo lo antes posible.

La sinopsis es que Orchard recomienda que elijas un nombre que, después de escucharlo, muchos usuarios o desarrolladores:

  • Sepan lo que hace el proyecto.

  • Recuerden el nombre mañana.

Curiosamente, el proyecto de Orchard, “Iajitsu”, no cumple ninguna de las dos características. Probablemente no hay ninguna relación con que el desarrollo haya sido parado desde que este artículo fue escrito.

Sin embargo, tiene un punto interesante. Hay empresas cuya única función es poner nombre a componentes de software. Hacen cantidades ridículas de dinero haciéndolo y supuestamente lo vale. Aunque puedas pagar una empresa de esas, puedes también saber de su existencia y pensar un poco sobre el nombre que le estás dando a tu proyecto porque vale la pena.

Si realmente quieres un nombre pero no se ajusta al criterio de Orchard, puedes seguir adelante. Pienso que “gnubile” fue uno de los mejores nombres de proyectos de software libre que he conocido y sigo hablando de él mucho tiempo después de haber dejado de utilizar el programa. No obstante, si puedes ser flexible sobre este asunto, haz caso del consejo de Orchard. Podría ayudarte.

Licenciando tu Software.

En un (simple) nivel, la diferencia entre un componente de software libre y un componente de software propietario es la licencia. Una licencia te ayuda como desarrollador a proteger tus derechos legales para distribuir tu software bajo tus términos y ayuda a demostrar a aquellos que quieren ayudarte a ti o a tu proyecto que están invitados a unirse.

Eligiendo una licencia.

Cualquier debate sobre licencias generará seguramente al menos una pequeña “guerra”1 ya que existen fuertes opiniones sobre si algunas licencias de software libre son mejores que otras. De este debate surge también la cuestión de “Software de código abierto” y el debate sobre los términos “Software de código abierto” y “Software libre”. Sin embargo, como este HOWTO que escribo se refiere a la gestión de proyectos de software libre y no a la gestión de proyectos de software de código abierto, mis propias inclinaciones sobre este tema son evidentes.

Intentando buscar el punto medio diplomáticamente sin sacrificar mi propia filosofía, recomiendo escoger cualquier licencia que se ajuste a las pautas de la Debian Free Software. Originariamente recopilado por el proyecto Debian bajo Bruce Perens, las pautas forman la primera versión de la definición Open Source. Ejemplos de licencias libres creadas a partir de estas pautas son la GPL, la BSD, y la Artistic License. Así como ESR (Eric S. Raymond) menciona en su HOWTO [ESRHOWTO], no escribas tu propia licencia en cualquier caso. Las tres licencias que he mencionado tienen una larga tradición de interpretación. Indudablemente también hay software libre (y puede por consiguiente ser distribuido como parte de Debian y en otros lugares que permitan transferir software libre).

De acuerdo con la definición de software libre propuesta por Richard Stallman en “The Free Software Definition”, cualquier de estas licencias conservarán, a los usuarios libres de ejecutar, copiar, distribuir. Estudiar, cambiar y mejorar el software. Existen muchas otras licencias que también se ajustan a las pautas de Debian Free Software pero adheriéndose a una licencia más conocida proveerá la ventaja de ser reconocido y comprendido de forma inmediata. Mucha gente escriben tres o cuatro frases en una documento y asumen que han escrito una licencia de software libre—mi larga experiencia con el mailing de manifiestos legales de debian, por lo general no es el caso.

Tratando de hacer un análisis más profundo, estoy de acuerdo con la descripción que Karl Fogel hace sobre las licencias diferenciándolas en dos grupos: las que son GPL y las que no son GPL.

Personalmente, yo licencio todo mi software bajo GPL. Creada y protegida por la Free Software Foundation y el proyecto GNU, GPL es la licencia del kernel de Linux, GNOME, Emacs, y la gran mayoría de software GNU/linux. Es la elección obvia pero también creo que es buena. Cualquier fanático de BSD insistirá en recordarte sobre el aspecto viral de GPL que impide mezclar código GPL con código no GPL. Para mucha gente (yo incluido), es un beneficio, pero para otros, es un gran inconveniente.

Mucha gente escriben tres o cuatro frases en una documento y asumen que han escrito una licencia de software libre—mi larga experiencia con el mailing de manifiestos legales de debian, por lo general no es el caso. No te protegerá, no protegerá tu software, y hará las cosas muy difíciles a aquellos que quieran utilizar tu software pero presten mucha atención a los puntos sutiles legales de las licencias.

Si te apasiona una licencia “hecha en casa”, antes de utilizarla compruébala con la gente de OSI o con la mailing-list de debian-legal para protegerte de efectos laterales inesperados de tu licencia.

Las tres mayores licencias pueden encontrarse en los siguientes enlaces:

En cualquier caso, por favor lee cualquier licencia antes de liberar tu software bajo ella. Como programador principal, no puedes permitirte ninguna sorpresa respecto a la licencia.


Los mecanismos de licenciar.

El texto de GPL proporciona una buena descripción de los mecanismos de aplicación de una licencia a un componente de software. Mi lista rápida de comprobación al aplicar una licencia incluye:

  • Declárate a ti mismo o a la FSF como titular del copyright del trabajo. En algunos pocos casos, podrías querer definir como titular a una organización patrocinadora (si es suficientemente grande y potente). Haciendo esto es tan simple como poner el nombre en el espacio a tal efecto cuando modificas el aviso de copyright que se presenta a continuación. Al contrario de lo que se cree, no es necesario que sea una organización. El aviso es suficiente por sí solo para registrar el copyright de tu trabajo.

  • De ser posible, adjunta y distribuye una copia completa de la licencia con el código fuente y binario/s en un fichero separado.

  • Incluye un aviso de copyright al principio de cada fichero de código fuente de tu programa, además de incluir también la información de dónde se puede encontrar la licencia completa. GPL recomienda que cada fichero empiece con:

one line to give the program's name and an idea of what it does.
Copyright (C) yyyy  name of author

This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.

GPL también recomienda incluir información de cómo contactar contigo (el autor) via email o correo postal.

  • GPL sugiere que si tu programa se ejecuta en modo interactivo, deberías escribir el programa de modo que presente un aviso cada vez que se inicia el modo interactivo que incluya el mensaje como el siguiente que indique la información completa sobre la licencia del programa:

Gnomovision version 69, Copyright (C) year name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
type `show w'.  This is free software, and you are welcome
to redistribute it under certain conditions; type `show c' 
for details.
  • Por último, podría ser de ayuda incluir una “limitación de responsabilidad del copyright” para un empresario o escuela si trabajas como programador o si piensas que tu empresario o escuela podría iniciar más adelante polémica sobre la propiedad de tu código. No es que sea muy necesario pero hay muchos desarrolladores de software libre que han tenido problemas sobre este punto y desearon tener una.

Una última advertencia sobre licenciar.

Por favor, por favor, por favor, registra tu software bajo alguna licencia. Puede no parecer importante, y para tí podría no serlo, pero las licencias son importantes. Para que un componente de software se incluya en la distribución Debian GNU/Linux, debe estar licenciado y que su licencia se ajuste a las pautas de la Debian Free Software. Si tu software no está licenciado, no puede distribuirse como paquete en Debian hasta que lo re-liberes bajo una licencia libre. Por favor, evítate problemas a ti mismo y a los demás liberando la primera versión de tu software bajo una licencia y de forma clara.

1Del original: Flame war.

Acerca de Isildur Fuentes

Apasionado de las buenas historias y aikidoka de la tierra.

Publicado el junio 6, 2011 en Divulgación, Escritos y etiquetado en , , , . Guarda el enlace permanente. Comentarios desactivados en Gestión de proyectos de software libre (II). Decidiendo continuar..

Los comentarios están cerrados.

A %d blogueros les gusta esto: