Introducción al software libre y/o de código abierto

0
14399

Introducción al software libre y/o de código abierto,

y sus licencias

Creación: 09-03-2007

Índice
de contenidos

1.Introducción

Hace poco que en Autentia (http://www.autentia.com) hemos publicado una herramienta para la gestión de autónomos o PIMES, especialmente orientadas a servicios (proyectos, horadedicadas a cada proyecto, planificación semanal, interacciones con los clientes, …). La podéis encontrar en:

A la hora de publicar la aplicación nos encontramos con el dilema de la elección de la licencia ¿una licencia libre? ¿una licencia privada?, … (por cierto, al final nos decantamos por la licencia libre GPL)

En general cuando queramos publicar una aplicación (comercial o no), nos encontramos con numerosas dudas de este tipo.

Este tutorial en ningún caso debe tomarse como referencia ya que mucho de lo que aquí se expone son opiniones e interpretaciones personales, siendo este tema de las licencias muy amplio y muy delicado (ya que implica temas legales). Sería interesante que cada uno consultara con expertos legales para ver que licencia cubre mejor sus necesidades.

Este tutorial tan sólo pretende ser una introducción al software libre (free software) y/o de código abierto (open source), y a algunas de las licencias más habituales en este tipo de desarrollos, de forma que el lector empiece a conocer este mundillo.

2. Entorno

El tutorial está escrito usando el siguiente entorno:

  • Hardware: Portátil Ahtec Signal 259M MXM (Sonoma 2.1 GHz, 2048 MB RAM, 100 GB HD).
  • Sistema Operativo: GNU / Linux, Debian Sid (unstable), Kernel 2.6.18, KDE 3.5

3. ¿Que es el software libre y/o de código abierto?

A partir de ahora los denominaremos free software y open source, respectivamente (aunque estos términos son anglicismos, los vamos a utilizar ya que es como comúnmente se conocen y como podemos encontrar más referencias).

Dentro del free software y/o open source podemos encontrar dos grandes organizaciones:

  • FSF: Free Software Fundation http://www.fsf.org/ (persigue los fines morales más que la excelencia técnica)
  • OSI: Open Source Initiative http://www.opensource.org/ (persigue más la excelencia técnica, y la compartición del código es un medio para conseguirlo)

Cada una de estas organizaciones da su correspondiente definición sobre cada uno de los términos.

3.1. Free Software

La definición oficial: http://www.gnu.org/philosophy/free-sw.html

Lo primero que debemos entender es la interpretación de “free”: este se refiere a
“libre”, y no a “gratuito”. En nuestro idioma tenemos menos problemas para diferenciar el concepto porque podemos usar palabras claramente diferentes, pero en el habla inglesa, el uso de “free” a causado muchas confusiones.

En concreto “free” se refiere a cuatro tipo de libertades:

  1. Libertad para ejecutar el programa.
  2. Libertad para estudiar como funciona la aplicación y adaptarla a las necesidades de cada uno. El acceso al código fuente es una precondición para esto (sino a ver quien es el listo que hace la modificación ;).
  3. Libertad para redistribuir copias.
  4. Libertad para mejorar el programa y distribuir esas modificaciones al público (es decir, la segunda libertad me permite modificar el programa, y esta libertad me permite publicar esos cambios). Aquí también es una precondición el acceso al código fuente.

Un programa se considera libre si sus usuarios tienen estas libertades, independientemente de si han pagado por el programa o de si ellos van a cobrar por hacer la redistribución.
Además sus usuarios no tienten que pagar ni preguntar para poder hacer uso de estas libertades.

Un usuario podría modificar un programa y usar esa modificación internamente sin tener que avisar a nadie de la existencia de esa modificación. Y si decide publicar los cambios, no tendría que avisar a nadie ni hacerlo en ningún sitio, o de ninguna manera en concreto.

3.2. Open Source

La definición oficial de la OSI (la OSD Open Source Definition): http://www.opensource.org/docs/definition.php

Para que un programa se considere open source, su distribución debe cumplir los siguientes términos:

  1. Libre distribución: la licencia no puede restringir sobre la distribución gratuita o comercial del programa. Podríamos cobrar por la distribución sin pagar derechos de autor o cualquier otro honorario.
  2. Código fuente: El código debe estar disponible, se puede distribuir junto al binario, o indicar donde y como se puede conseguir (por ejemplo indicando donde se puede descargar). Que esté disponible también significa que sea posible su fácil entendimiento y modificación, es decir, no está permitido proporcionar código ofuscado.
  3. Trabajos derivados: La licencia debe permitir modificaciones y trabajos derivados. Y debe permitir distribuir estos cambios bajo los mismos términos de la licencia original (nótese que “debe permitir” pero no obligar, es decir la distribución de los cambios podría hacerse bajo otros términos).
  4. Integridad de los autores del código fuente: La licencia puede requerir algún mecanismo por el que la distribución de los cambios siga garantizando la identificación del trabajo original y sus autores (por ejemplo que la distribución se haga en base a parches que se aplican sobre el original, o que se de un nombre o versión diferente, …). Con esto se pretende mantener la autoría y reputación de los autores originales.
  5. No puede haber discriminación contra ninguna persona o grupo. Todo el mundo puede usar o distribuir el software.
  6. No se puede discriminar el uso en un campo determinado: Con esto se pretende evitar posibles “trampas” en las licencias para evitar el uso del open source en aplicaciones comerciales. La idea del open source es intentar que se extienda lo más posible, incluso en el software comercial.
  7. Distribución de la licencia: Con esto se pretende evitar que la licencia tenga alguna claúsula de no divulgación. Es decir, en cuanto alguien recibe una distribución del programa puede ejercer todos los derechos asociados a este, y por lo tanto puede, a su vez, seguir distribuyéndolo.
  8. La licencia no debe ser específica de un producto: Con esto se pretende que si el programa open source se saca de una distribución concreta, el programa debe seguir teniendo los mismos derechos. Todas las partes del programa deben tener los mismos derechos que aquellos aplicados a la distribución, completa, original.
  9. La licencia no debe restringir otros softwares distribuidos con el software licenciado: es decir, la distribución completa puede tener software open source y software no open source. La licencia open source no debe obligar a que todo software que se distribuya conjuntamente sea también open source. (estaría relacionado con el punto 3 sobre los trabajos derivados).
  10. La licencia debe ser tecnológicamente neutral: Con esto se pretende evitar aquellas licencias que necesitan alguna operación por parte del usuario para aceptar la licencia (por ejemplo hacer click con el ratón sobre un diálogo de aceptación), ya que esto puede ir en contra de algunos medios de distribución (FTP, CD-ROM, …). En definitiva, la distribución del software siempre debe permitir otros medios que no tienen porque ser Web, y tener en cuenta que el software podría ejecutarse en un entorno que no soporte diálogos popup.

3.3. Resumen

Se puede ver que ambas definiciones (ambas organizaciones) persiguen aproximadamente los mismos objetivos. La idea es construir software que este disponible para toda la comunidad, siendo la piedra angular de ambas definiciones el acceso al código fuente para su estudio, modificación, e incluso su posterior distribución.
Además las licencias que se encuentran bajo estas definiciones también pretenden proteger la propiedad intelectual de los autores (por esto no debemos confundir software libre con software público).

Con esto se pretende conseguir software de más calidad, y una más rápida evolución del mismo, ya que toda la comunidad puede aportar sus ideas o correcciones.

Otra idea importante detrás de estas definiciones es la globalización de la información y el conocimiento, haciendo que este llegue a cualquiera, sin restricciones.

En numerosas ocasiones se emplea el término free software u open source indistintamente, pero no debemos olvidar que las dos definiciones no son exactamente iguales. De hecho se podría decir que la definición de open source es más restrictiva, ya que pone más condiciones para que una licencia se pueda considerar de este tipo. Por esto podemos encontrar que licencias aprobadas por la FSF son incompatibles con licencias aprobadas por la OSI.

Para ver un listado de categorías de software libre y no libre podemos visitar el siguiente enlace (muy recomendable):

http://www.fsf.org/licensing/essays/categories.html

A continuación presentamos un gráfico elaborado por René Mérou donde se resumen bastante bien las características y bondades del software libre:

 

 

En cualquier caso no debemos olvidar que el softwere libre no impide su distribución comercial, siempre y cuando se mantengan las libertades y principios de las definiciones.

4. Algunas licencias de free software y open source

Existen numerosas licencias dentro de estas definiciones.
Sólo dentro de las licencias aceptadas por la OSI podemos encontrar más de 40 (http://www.opensource.org/licenses/).
Todas expresan más o menos lo mismo, ya que todas están enmarcadas en una de las dos definiciones que hemos visto anteriormente, pero cada una tiene sus particularidades. Es aquí donde se hace importante la lectura detenida de cada una de ellas, y si fuera necesario, la intervención de un experto en temas legales.

A continuación vamos a comentar algunas de estas licencias (las que ha día de hoy son las más utilizadas o relevantes).

4.1. General Public License (GPL)

http://www.gnu.org/philosophy/free-sw.html

Estaría dentro de la categoría de free software. Es la principal licencia de la FSF, y a día de hoy, la más extendida.

Se encuentra en su versión 2 (de junio de 1991), aunque la versión 3 está a punto de ver la luz (esperamos que sea este año).

Su principal característica es la incorporación del concepto de Copyleft. El Copyleft es un método general para hacer libre a un programa, y obligar a que toda modificación o extensión de este programa sea también libre. Es decir, la intención del Copyleft es mantener las libertades del free software, incluso en las modificaciones o trabajos derivados. Por esto se dice que este tipo de licencias son virales, ya que el Copyleft se va extendiendo por cada modificación o trabajo derivado.

Aunque queda fuera de las 4 libertades del free software, esta licencia también se preocupa de conservar y proteger la autoría de la obra. Así en su sección 2.a nos dice que si modificamos algún fichero, debemos añadirle una nota que indique claramente que el fichero ha sido cambiado, y la fecha del cambio.

4.2. Lesser/Library General Public License LGPL

Esta licencia también pertenece a la FSF, y es básicamente igual a la GPL. La principal diferencia es que incorpora un Copyleft “débil”. Esto es, que modificaciones o trabajos derivados tienen que seguir bajo los mismos términos de la LGPL, pero el software bajo la licencia LGPL puede ser usado sin que el que lo usa este obligado a licenciarse bajos los términos de la LGPL.

Es decir, productos comerciales (en general productos bajo cualquier tipo de licencia) podrán enlazarse con software LGPL si sólo lo usan y no lo modifican de ninguna manera (el producto tendrá su propia licencia, pero el software LGPL se mantiene libre).

Esta licencia está pensada especialmente para aplicarla a librerías, con la intención de que el uso de estas librerías se extienda lo más posible (por ejemplo para intentar que se conviertan en un estándar de facto).

Usar la licencia GPL para una librería puede limitar mucho el número de aplicaciones que la usen, por esto tenemos que pensar muy bien la licencia que aplicamos a una librería: GPL garantiza mejor el mantenimiento de las libertades, pero LGPL garantiza una mayor divulgación de nuestra librería.
Tendremos que ver en cada caso que es lo que más nos interesa (la FSF recomienda el uso de la GPL, ya que su principal objetivo es la divulgación de los principios morales del free software).

4.3. Apache Software License

http://www.opensource.org/licenses/apache2.0.php

Licencia reconocida por la OSI. Su versión actual es la 2.0 (del 2004) que es bastante más extensa que las anteriores.

Es una licencia muy extendida dentro del mundo Java (debido a que es la principal licencia de “The Apache Software Fundation” http://www.apache.org), aunque puede aplicarse a cualquier software en cualquier lenguaje.

Cosas que podríamos destacar en esta licencia es como protege las marcas registradas, de forma que trabajos derivados no pueden usarlas. Por ejemplo si cogemos una librería de Apache y la modificamos, no podemos ir diciendo que esa librería modificada es de Apache, y de esta manera intentar aprovecharnos del nombre de marca o su prestigio. Por el contrario nos vemos obligados a mantener un fichero “NOTICE” donde se quede bien claro el origen del trabajo (es decir debe quedar claro que nuestro software usa librerías de Apache, o que el origen de la modificación era Apache).

Otro punto es el tratamiento de las patentes. Apache, como la mayoría de los defensores del open-source, está en contra de las patentes, ya que estas pueden minar el desarrollo y la evolución del open-source. Por ejemplo alguien malintencionado podría hacer una aportación a un software open-source, donde esa aportación llevara algún tipo de
patente; podría dejar que ese open-source se distribuyera por la comunidad, y después podría realizar varias demandas por la violación de esa patente. La versión 2.0 de la licencia de Apache intenta protegerse contra este tipo de cosas.

También sería interesante comentar la compatibilidad de esta licencia con la GPL. En este punto hay un debate abierto y Apache está en conversaciones con la FSF para ponerse de acuerdo. La cuestión es que la FSF no considera que sean compatibles ya que la licencia de Apache es más restrictiva que la GPL (por ejemplo en el tema de las patentes), sin embargo “The Apache Software Fundation” si considera que son compatibles. Esperamos que con la proxima versión de la licencia GPL estos temas queden aclarados. Podéis encontrar más información en los siguientes enlaces:

http://www.apache.org/foundation/licence-FAQ.html#GPL

http://www.apache.org/licenses/GPL-compatibility.html

4.4. Mozilla Public License (MPL)

http://www.opensource.org/licenses/mozilla1.1.php

Licencia reconocida por al OSI. Su versión actual es la 1.1.

En http://www.mozilla.org/MPL/ podéis encontrar información muy interesante,
sobre todo una versión comentada de la licencia que nos puede venir muy bien para entender mejor la licencia.

En esta licencia se diferencia entre código fuente y ejecutable teniendo diferentes restricciones y requisitos.

En esta licencia también se tiene en cuenta el tema de las patentes.

5. Conclusiones

Como hemos visto, hay multitud de licencias, y cada una tiene sus particularidades. La única recomendación que os puedo dar es que pongáis sobre la mesa los objetivos que pretendéis conseguir con vuestro software, y una vez tengáis esto claro, elegir la licencia que mejor se adapte.

Incluso, si lo creéis oportuno para alcanzar vuestros objetivos, elegir una licencia propietaria. Pero no olvidéis que free software u open source no significa gratis. Podéis seguir cobrando por la distribución, y lo que es más importante por los servicios relacionados con vuestro software (documentación, formación, instalación, soporte, adaptaciones particulares, …).

Por ejemplo, en nuestro caso, con TNTConcept (http://tntconcept.sourceforge.net/,
http://sourceforge.net/projects/tntconcept) hemos elegido la licencia GPL porque creemos sinceramente en los principios de compartición y globalización de la información, promovidos por el free software (de hecho ya llevamos mucho tiempo compartiendo con vosotros nuestros conocimientos en forma de tutoriales). Además con la licencia GPL, aunque no es perfecta (ninguna lo es), pretendemos garantizar que posibles mejoras o adaptaciones de nuestra aplicación sigan disponibles para la comunidad.

También comentaros que en este tutorial hemos estado hablando de licencias de software libre u open-source, pero existen otros tipos de licencias, por ejemplo para proteger nuestros escritos (documentación, libros, artículos, …). De hecho este mismo tutorial esta “protegido” por una de estas licencias, cuya referencia podéis encontrar más abajo.

6. Sobre el autor

Alejandro Pérez García, Ingeniero en Informática (especialidad de Ingeniería del Software)

Socio fundador de Autentia (Formación, Consultoría, Desarrollo de sistemas transaccionales)

mailto:alejandropg@autentia.com

Autentia Real Business Solutions S.L. – “Soporte a Desarrollo”

http://www.autentia.com

 

 

Alejandro es socio fundador de Autentia y nuestro experto en Java EE, Linux y optimización de aplicaciones empresariales. Ingeniero en Informática y Certified ScrumMaster. Seguir @alejandropgarci Si te gusta lo que ves, puedes contratarle para darte ayuda con soporte experto, impartir cursos presenciales en tu empresa o para que realicemos tus proyectos como factoría (Madrid). Puedes encontrarme en Autentia: Ofrecemos servicios de soporte a desarrollo, factoría y formación.

DEJA UNA RESPUESTA

Por favor ingrese su comentario!

He leído y acepto la política de privacidad

Por favor ingrese su nombre aquí

Información básica acerca de la protección de datos

  • Responsable:
  • Finalidad:
  • Legitimación:
  • Destinatarios:
  • Derechos:
  • Más información: Puedes ampliar información acerca de la protección de datos en el siguiente enlace:política de privacidad