Licenciar software libre es un acto bastante difícil, a mi particularmente me gusta emplear la licencia LGPL 2.1 pero hay quien me ha sugerido emplear otras como Apache o BSD, ¿es para evitar problemas, para emplear el código ajeno como propio o para evitar aportar a la comunidad cambios y mejoras?
En este artículo me gustaría centrarme en LGPL 2.1 ya que es la licencia que mejor conozco y he empleado durante muchos años en el desarrollo de librerías de código en Erlang y Elixir que tengo en mis repositorios de github personal y de Altenwald.
El principal miedo de las personas que quieren usar librerías como ephp o myproto es si deben modificar sus licencias para ser también LGPL 2.1 o también si pueden emplear en código propietario esas librerías. Todos saben la historia de Richard Stallman y su cruzada por hacer el mundo del desarrollo de software un mundo abierto donde todo el código sea visible. Pero precisamente LGPL 2.1 fue desaconsejada por la FSF al ser la más permisiva en compatibilidad con código cerrado en comparación con otras como GPL o AGPL.
En resumen puedo decir que no necesitas hacer tu código LGPL si solo emplearás la librería sin modificaciones y como agregado. Realmente solo vulneras la LGPL 2.1 si modificas o empleas ficheros (algunos o todos) dentro del código de tu librería. Esto quiere decir que si mi librería ephp (por ejemplo), está en tu fichero rebar.config como dependencia y no modificas nada, tu código puede tener otra licencia o ser propietario. Sin embargo, si hiciste un fork privado y modificaste la librería para agregarla a un software que estás distribuyendo, entonces sí la estás incumpliendo.
¿Qué es LGPL 2.1 y por qué importa?
Tal y como el artículo de porqué no debes usar LGPL indica el uso de LGPL fue diseñada para competir con otras librerías de código cerrado o propietario al mismo nivel. Es decir, permite la inclusión de la librería dentro de código cerrado distribuible sin problemas. Muchas veces esto no se percibe así y se confunde LGPL con GPL y la exigencia de mantener todo el código donde se usa la librería también abierto. No es el caso.
Según los puntos de la licencia, tus obligaciones son:
- Incluir la información de autor, licencia y código de la librería incluida. Esto quiere decir que si creas una aplicación que incluye una librería LGPL y el software es distribuido, debes incluir en algún sitio información sobre el uso de esta librería, que su licencia es LGPL y un enlace a dónde está el código fuente de la librería. Si usas el original, el enlace al sitio original está bien.
- Puedes cobrar el software sin problemas incluso si solo vendes la librería con o sin modificaciones y siempre que respetes el punto anterior.
- Los cambios deben ser reportados. En mi caso uso github para todo mi código libre. Si alguien hace un fork y realiza cambios, realizar un pull request (solicitud de mezcla) es suficiente para cumplir con todo el segundo punto de la LGPL. En esa petición de cambio se agregan los cambios introducidos y se mantiene enlace al código original.
- El fork realizado NO puede cambiar de licencia. Esta es la única parte rígida en el acuerdo. Si realizas una modificación, incluso si la modificación deriva en un trabajo aún mayor, cambiando el nombre y evolucionando la librería enormemente, esta debe seguir siendo LGPL.
En el punto 5 la licencia deja clara que si tu trabajo está diseñado para trabajar con la librería pero incluso no la incluye. Tu trabajo es completamente independiente.
En el punto 6 habla también el caso de que se incluya y como decíamos en los puntos anteriores. Si todos se cumplen, no hay problema. En este punto además se hace hincapié de proporcionar al usuario sin coste adicional de toda la información de la librería empleada además de utilizar algún método que permita modificarla o emplear modificaciones de esa librería por parte del usuario. En este punto, si usas lenguaje C, es el equivalente a emplear gtk para tu aplicación y solicitar al usuario que instale en su distribución de GNU/Linux los binarios de GTK de paquetería.
En caso de emplear un mecanismo para bajar de un sitio público la librería y permitir al usuario emplearla el caso es el mismo que el del punto 5. Tu software puede ser cerrado y privado. Solo debes dar a conocer al usuario la necesidad de esa librería, de dónde se descargará y que acepte su licencia. Sobretodo por motivos de descargo de responsabilidad.
Pero... tú sigues siendo el autor
El punto 14 de la licencia lo dice claro: escriba al autor para pedir permiso. Como autor puedes conceder un cambio de licencia específicamente para alguien. Por ejemplo, hubo una versión de myproto que licencié con Erlang Public License para que Flussonic pudiese incluir y modificar la librería evolucionándola hasta llegar a sqlapi. Como conozco al autor le concedí esa licencia y derivó en un trabajo bajo licencia MIT pero puedes leer en su fichero LEGAL toda la historia.
Libre de Garantías
Esta parte es la más importante. El autor original queda siempre libre de posibles daños realizados por el uso de la librería. A diferencia de código cerrado y privativo que es vendido y debe dar ciertas garantías como estipula el mercado, el software libre por lo general no tiene ligadas estas garantías y son aceptadas como tales por los usuarios al emplear el software.
Por ello es importante dar a conocer la LGPL cuando está incluida o usada dentro de un software. Para dar a entender al usuario que el uso de ese software en tanto lo que respecta a la actividad llevada a cabo por el software libre no tiene cubierta ninguna garantía.
Conclusiones
En definitiva, como autor puedes decir si aplicas o no la licencia a tu software, puedes hacer doble licenciamento del mismo software bajo contrato y en realidad, puedes hacer lo que quieras. La existencia de una licencia es un medio de protección para quien toma el software de obtenerlo bajo las condiciones por defecto especificadas en esa licencia y no preocuparse de posibles incidencias legales mientras cumpla la licencia, pero si conoces al autor y te permite hacer lo que quieres, no deberías tener mayores problemas. Al final todo gira en torno al entendimiento entre quien realiza una librería y quien quiere emplearla dentro de un código específico.
Espero haber arrojado un poco de luz sobre este tema tan controvertido de las licencias de software y, aunque solo he hablado de esta licencia, si estáis interesados en conocer aún más sobre esta licencia u otras no olvidéis dejarme un comentario.
