¿Puede usar una licencia de código abierto menos restrictiva de la que tiene su dependencia?

Aug 17 2020

Sin perder la generalidad, suponga que tiene un proyecto Java de código abierto con Gradle como sistema de compilación y desea agregarle la licencia MIT. Considere los casos:

Caso 1. Desde el archivo build.gradle, usted declara una dependencia de JUnit5, que tiene la licencia de Eclipse Public License - v 2.0. Realiza algunas pruebas con él en una carpeta de prueba, y todo eso, junto con una carpeta src, se carga en GitHub. ¿Puede su proyecto obtener una licencia del MIT? Además, creará un paquete con su proyecto, pero las pruebas JUnit5 no se incluirán en él.

Caso 2. Desde el archivo build.gradle, usted declara una dependencia de las anotaciones java de JetBrains, que tiene la licencia Apache License 2.0. ¿Puede su proyecto obtener una licencia del MIT? Además, creará un paquete con su proyecto y querrá que los dependientes vean las anotaciones en su código, pero no le preocupa si pueden usar las anotaciones en su código.

TL; DR: Entiendo que si copia y pega los archivos de un proyecto, solo puede volver a licenciarlo con licencias compatibles, pero lo mismo ocurre si solo depende de ellos a través de los paquetes Maven / Gradle y su paquete de proyecto producido no los contendrá?

Respuestas

1 BartvanIngenSchenau Aug 18 2020 at 17:18

Cuando declara una dependencia en el paquete X, hay dos posibilidades

  1. El paquete X tiene una fuerte licencia copyleft, como la GPL o AGPL: estas licencias tienen el requisito de que la aplicación binaria final tenga la licencia GPL o AGPL, respectivamente. Como resultado, ponen una restricción a las licencias que puede elegir para su propio código.

    Cualquier compilación que distribuya que contenga el paquete X debe tener la misma licencia que el paquete X. Si no hay compilaciones sin el paquete X, entonces es mejor licenciar el código fuente también con esa misma licencia. Si también tiene compilaciones sin el paquete X, puede elegir una licencia compatible para su código fuente.

  2. El paquete X tiene cualquier otra licencia: estas licencias no extienden su alcance más allá de los archivos que tienen licencia explícita con esa licencia y, por lo tanto, no imponen ninguna restricción a las licencias que puede elegir para su propio código.

    En este caso, puede utilizar una licencia de código abierto menos restrictiva, una licencia de código abierto más restrictiva o incluso una licencia de código cerrado que sea compatible.

Ambos casos que menciona (JUnit5 y java-annotations) involucran licencias en la segunda categoría y, por lo tanto, no afectan las opciones de licencia que tiene para su propio código.