45

En la empresa que trabajo, si para resolver un problema un miembro del equipo de desarrollo propone utilizar una librería Open Source, los productores del proyecto siempre preguntan qué licencia de software viene con la librería.

No somos abogados, pero entiendo que no todas las distintas licencias, se pueden combinar porque existen ciertos requisitos que cada una exige cumplir.

Dicho esto, quiero saber, ¿Cuáles serían las consideraciones a tener en cuenta antes de incluir una librería Open Source en un software que creé por mi cuenta?

rnrneverdies
  • 16,491
  • 3
  • 49
  • 79
  • 1
    No es necesario saber nada de las licencias de software para ser programador. – Flimzy Dec 03 '15 at 13:57
  • 2
    Para hacer la pregunta más especifica se podria decir: ¿cuales licencias open-source de las más conocidas permiten redistribuir el software en questión como parte de en una aplicación comercial de código cerrado?. – yms Dec 03 '15 at 14:40
  • @rnrneverdies: Exactamente. Yo, con un cargo, pienso X, y tu con otro, piensa Y. – Flimzy Dec 03 '15 at 15:55

4 Answers4

28

Dicho esto, quiero saber, ¿Cuáles serían las consideraciones a tener en cuenta antes de incluir una librería Open Source en un software que creé por mi cuenta?

La consideración más importante que deberías tener en cuenta de forma general es la forma de distribución de tu aplicación, o sea, cómo será utilizado por los usuarios. Según como sea la distribución es que las licencias te pueden poner algún impedimento.

Si tu aplicación es un servicio (SaaS)

En ese caso la única licencia que conozco que puede limitarte es la licencia AGPL ya que te obliga a hacer toda la aplicación AGPL y publicar el código fuente en algún lado. El resto de las licencias pueden ser utilizadas, sin restricción (más allá de que estaría bueno linkearlas como forma de agradecimiento). La única excepción es el código JavaScript, que se envía al cliente y se ejecuta en su computadora, el cual debe ser tratado como en la sección siguiente.

Si tu aplicación es instalable

En este caso hay que distinguir dos tipos de dependencias distintas, aquellas que se pueden instalar separadamente y aquellas que se compilan dentro de tu aplicación.

En el caso de las dependencias que se instalan separadamente, la mayoría de las licencias no te afectan, ya que no se mezcla con tu aplicación lo que se hace es dejar el instalador separado (así funciona por ejemplo GitHub para Windows, que al instalarlo instala por detrás git con licencia GPL).

En el último caso, en que tu aplicación utiliza las librerías internamente, es que las licencias, se pueden volver complicadas, en este caso las licencias "abiertas (BSD, MIT, etc.)" no constituyen problema alguno, excepto la obligación de dejar una mención de su uso y de la licencia (ejemplo).

Por último, las licencias "libres" (o copyleft), te obligan a darle acceso al usuario al código fuente de las mismas. En el caso de la licencia LGPL solo es necesario darle acceso al código de la misma librería (con las modificaciones que le hayas realizado), no de todo tu código. El caso de la GPL es más extremo ya que te pide que distribuyas toda tu aplicación bajo esa licencia (cuestión que en algunos casos es imposible ya que algunas, son incompatibles).

Aclaración

En general las licencias te obligan a distribuir la fuente del código con la persona a la que le das la aplicación, no a hacerlo público. Por lo tanto, si la aplicación se vende a una empresa específica para su uso interno, lo que te exige la licencia es que les entregues a la empresa la fuente, no que publiques todo en internet.

eloyesp
  • 1,082
  • 6
  • 20
  • 3
    Creo que un símil muy acertado es decir, que GPL o AGPL es una licencia "viral", es decir todo lo que toquen tiene que ser liberado en condiciones similares. En cambio LGPL, MIT, etc... no obligan a que el resto del código se libere con la misma licencia. Al menos a mi me ayudo mucho a entender este lío de las licencias... :) – Taber Dec 10 '15 at 14:33
  • @Taber: las licencias propietarias también son virales, obligan a no liberar todo lo que toquen, y en muchos casos, obligan a hacer "publicidad" en documentación y en la interfaz de usuario (p.ej: en _Acerca de_ ...) – ninjalj Dec 10 '15 at 18:43
  • @Taber: es sólo que no estoy nada de acuerdo con usar la palabra "viral", una palabra con connotaciones negativas, para las licencias copyleft, cuando otras licencias tienen mayores restricciones y no se usa una palabra negativa para referirse a ellas. Me parece una manipulación del lenguaje. – ninjalj Dec 15 '15 at 20:19
  • 1
    @Taber hay software abierto (o sea con licencias "open source") que es propietario (por ejemplo el rpm de newrelic). Abierto y propietario no son opuestos. – eloyesp Dec 16 '15 at 18:32
  • @yms sobre este punto, la diferencia es que mediante el linkeo dinámico uno usa la librería, mientras que mediante el linkeo estático la extiende (o sea la modifica) y por lo tanto ese nuevo código queda como parte del otro. – eloyesp Nov 23 '16 at 18:59
24

La distinción más importante es si una licencia es copyleft (familia GPL) o permisiva (MIT, BSD, Apache y otras). Las primeras obligan, bajo algunas condiciones, a relicenciar el código de los productos que usen software licenciado con ellas, con el objetivo de preservar en todo momento las libertades del usuario. Las licencias permisivas son más laxas, permiten ser incluidas en productos cerrados bajo algunas condiciones y en general son más sencillas. Los enlaces que ha pasado Christopher contienen mucha información al respecto.

Una web muy interesante es TLDRLegal

https://tldrlegal.com/

En ella explican muchas licencias de software libre o abierto para que sean fáciles de entender, y en el futuro permitirá compararlas.

Es importante remarcar que ausencia de licencia no es software libre. Ausencia de licencia significa que no se otorga ningún derecho, porque según los tratados internacionales (convenio de Berna) el "copyright" es irrenunciable. Por eso existen licencias de software, que desarrollan los conceptos de autoría, atribución y permisos en un lenguaje apropiado y compatible con las leyes de los distintos países. GitHub creó una web con el objetivo de ayudar a los desarrolladores a escoger una licencia para su proyecto y contiene información interesante sobre el tema.

astrojuanlu
  • 1,004
  • 13
  • 31
13

Este tema es amplio (véase https://es.wikipedia.org/wiki/Licencia_de_software y https://es.wikipedia.org/wiki/Anexo:Comparaci%C3%B3n_de_licencias_de_software_libre).

Hay que estudiar las licencias (o pedir a los abogados de su empresa que lo hagan). No se puede evitar esto.

Aquí se compara el uso de la licencia "Lesser GPL" y la licencia GPL ordinaria (dos de las licencias libres comunes) con respeto a las librerías:

[U]sar la licencia "Lesser GPL" permite el uso de la biblioteca en programas privativos; el uso de la GPL ordinaria para una biblioteca la hace disponible únicamente para programas libres. (http://www.gnu.org/licenses/why-not-lgpl.html).

(Por favor, también véase las respuestas buenisimas de astrojuanlu y yms).

Comunidad
  • 1
Christopher Bottoms
  • 835
  • 6
  • 17
13

No soy abogado, así que el uso de la información a continuación es a riesgo propio:

Hay varias licencias para proyectos Open Source que permiten re-distribución de binarios en aplicaciones comerciales de código cerrado. Nótese que la clave del asunto es "re-distribución", si usas un proyecto open source internamente en tu empresa, sin redistribuirlo, no hay (generalmente) de qué preocuparse.

Entonces, las licencias permisivas más conocidas son:

Nota 1: LGPL hace diferenciación entre uso de los fuentes directamente, linkeo estático y linkeo dinámico. Si usas una libreria LGPL con linkeo estático o en código fuente, tu código queda afectado por la licencia LGPL (debes distribuir los fuentes). Tengo entendido que hay excepciones para ficheros de interfaz, como los .h en C y C++

Nota 2: Cada una de estas licencias puede o no imponer restricciones en cuanto a las modificaciones que se le hagan al código, aquí estoy asumiendo que se utilizarán sin modificar.

Las licencias no permisivas más conocidas son:

  • GNU GPL

  • GNU AGPL Esta es la más estricta que conozco, contiene una cláusula que obliga a la publicación de tu código fuente incluso en el caso de utilización del proyecto open source en sitios web o servicios web, aunque no ocurra una "redistribución" como tal de binarios.

En ocasiones las licencias GPL y AGPL se combinan con una licencia comercial alternativa para el caso de utilización en proyectos comerciales de código cerrado.
Ejemplos de proyectos que usan esta estrategia de doble licencia AGPL-Commercial son Ghostscript, iText, QT y MongoDB (me pregunto si el que le puso el nombre a este proyecto habla Español).

Un detalle importante es que un proyecto Open Source publicado con una licencia permisiva podría tener una dependencia publicada con una licencia no permisiva, utilizada en forma de biblioteca externa. En tales situaciones la licencia no permisiva es la que prevalece.

Otro punto interesante es la definición de "distribución" de fuentes. GPL por ejemplo no dice que tienes que poner tus fuentes en Internet accesibles para cualquiera, la idea es que cada persona que reciba un binario de tu aplicación o sistema, debe poder recibir los fuentes si así lo deseara, podría ser incluso enviado por correo postal en un DVD, mediando incluso un pago "razonable" por el esfuerzo de quemar el disco y enviarlo.

yms
  • 579
  • 4
  • 16