Usar diferentes licencias para diferentes ramas del mismo repositorio
Tengo un repositorio de Git con un proyecto de tamaño mediano en GitHub. Dado que hay algunos componentes que dependen de las bibliotecas GPL, el repositorio actualmente también tiene licencia GPL. Sin embargo, la biblioteca con licencia GPL solo la utilizan algunos componentes (que se pueden aislar), y el resto del proyecto se puede utilizar perfectamente sin esos componentes. Por lo tanto, quiero licenciar todo lo que no dependa de ninguna biblioteca GPL bajo la licencia MIT. ¿Cuáles son las mejores prácticas para lograrlo?
Mi idea es tener dos ramas diferentes: una rama contiene el código completo y tiene licencia GPL. La otra rama elimina toda la funcionalidad que depende del código GPL y tiene licencia del MIT. ¿Es factible y / o común tener diferentes licencias para diferentes ramas del mismo repositorio? Si no es así, ¿cuáles serían mejores alternativas?
¿Podría ser un problema que, técnicamente, el historial completo de esa nueva rama no GPL alguna vez incluyó código GPL? ¿O está bien siempre que se elimine todo el código GPL de esa rama antes de agregar el nuevo archivo de licencia MIT en la rama?
Tenga en cuenta que esta pregunta es algo similar, pero tengo la sensación de que la mía está más preocupada por la implementación técnica . Es decir, ¿puedo simplemente poner dos archivos de LICENCIA diferentes en el directorio raíz del repositorio, dependiendo de la rama en la que nos encontremos actualmente?
Respuestas
Las ramas de Git no funcionan muy bien para mantener diferentes "ediciones" del mismo proyecto, porque no hay una buena manera de compartir los cambios entre las ramas sin fusionarlos por completo. Entonces, simplemente por razones técnicas, le recomiendo que no use ramas con licencias diferentes. Estas ramas tampoco son muy visibles para los usuarios.
En su lugar, mantenga todo el código en una rama principal, pero mantenga el código con licencia diferente en carpetas diferentes y deje muy claro qué código está bajo qué licencia.
La GPL no requiere que ningún código posterior esté bajo la GPL. Requiere que todas las obras derivadas (en su conjunto) estén bajo la misma licencia GPL. Pero esto puede satisfacerse cuando cualquier componente que haya escrito usted mismo se encuentra bajo una licencia compatible con GPL, como el MIT. Para evitar dudas, también puede otorgar una licencia doble a esos componentes como "MIT o GPL". Esto sería importante para las licencias que no son compatibles, por ejemplo, "Apache-2.0 o GPL-2.0-only".
Por lo tanto, la mejor práctica sería separar las partes cubiertas por la GPL de las partes que ha escrito completamente por usted mismo y usar la LICENCIA de nivel superior para describir qué partes están disponibles bajo qué licencia. Si desea hacer esto con extrema precisión, incluso podría adoptar el copyrightformato de archivo legible por máquina de Debian que asocia patrones globales con licencias. Se podría almacenar el texto de la licencia completa, ya sea dentro del mismo archivo de licencia, o tal vez como archivos separados gusta LICENSE.GPL.txt, LICENSE.MIT.txto en sus respectivos directorios.
Dado que actualmente está ofreciendo todo el código bajo GPL, mover el MIT para algunas partes requeriría volver a obtener la licencia . Esto es trivial si usted es el único contribuyente, porque usted, como único propietario de los derechos de autor, puede emitir licencias como desee. Pero si hay otros contribuyentes, tendrá que obtener su consentimiento para la renovación de la licencia o eliminar sus contribuciones (lo que puede ser extremadamente complicado porque generalmente requiere reescribir el componente comenzando con el último estado antes de la contribución cubierta por la GPL). No creo que importe que el historial de Git muestre esos mismos archivos cubiertos por la GPL incluso después de la renovación de la licencia. La licencia anterior sigue siendo válida para esas versiones anteriores, la nueva licencia sigue siendo válida para esas nuevas versiones.