La empresa Canonical publica la versión 5.20 de LXD, ahora distribuida bajo la licencia AGPLv3 y con la obligación de un Acuerdo de Licencia del Colaborador para aquellos que contribuyen al proyecto.
¿Qué es LXD?
LXD, que significa "Lex-Daemon," es un hipervisor basado en contenedores desarrollado por Canonical, la empresa detrás del popular sistema operativo Ubuntu. Aunque comparte similitudes con las tecnologías de contenedores como Docker, LXD se diferencia al proporcionar una capa de virtualización más cercana a las máquinas virtuales tradicionales. Esto se logra mediante la utilización de tecnologías de kernel como LXC (Linux Containers) para garantizar la separación eficiente de recursos.
Características Clave de LXD
-
Virtualización Ligera: A diferencia de las máquinas virtuales convencionales, LXD utiliza contenedores que comparten el mismo kernel del sistema operativo anfitrión. Esto mejora la eficiencia de los recursos y facilita un rendimiento más rápido y ágil.
-
Gestión de Recursos: LXD proporciona herramientas avanzadas para la gestión de recursos, permitiendo a los administradores asignar de manera precisa CPU, memoria y almacenamiento a cada contenedor. Esto garantiza un uso eficiente de los recursos del sistema.
-
Interfaz de Usuario Gráfica y Línea de Comandos: LXD ofrece una interfaz de usuario gráfica llamada LXDUI, que simplifica la administración de contenedores. Además, se puede gestionar a través de la línea de comandos, lo que facilita la automatización y la integración en flujos de trabajo existentes.
-
Snapshots y Migración: LXD permite la creación de instantáneas (snapshots) de contenedores, facilitando la copia de seguridad y la restauración rápida en caso de fallos. Además, es posible migrar contenedores entre hosts LXD, lo que brinda flexibilidad en la administración de la infraestructura.
El Debate sobre la Licencia y Cambios Recientes
Recientemente, Canonical ha realizado cambios en la licencia de LXD, trasladándola a la AGPLv3 y requiriendo la aceptación de un Acuerdo de Licencia del Colaborador (CLA) para contribuciones. Estos cambios han generado cierta controversia y han llevado a la creación de forks, como el caso de Incus liderado por Stéphane Graber, uno de los primeros responsables de LXD.
Canonical y el lanzamiento de la versión LXD 5.20
La empresa Canonical ha revelado el lanzamiento de LXD 5.20, la última iteración de su sistema de gestión de virtualización y contenedores, una herramienta crucial para LXC y la primera que ve la luz bajo la administración directa de la desarrolladora de Ubuntu. Este traslado ha generado controversia y resistencia en la comunidad, especialmente entre los mantenedores de Linux Containers, quienes objetaron la restricción impuesta por Canonical, que parecía limitar la participación a empleados de la compañía.
Puede leer también | Canonical lanza nuevas actualizaciones de seguridad del kernel de Ubuntu Linux
A pesar de que la colaboración aún es posible, está sujeta a las nuevas condiciones establecidas por Canonical, incluida la aceptación del Acuerdo de Licencia de Contribuidor (CLA), una medida que ha sido recibida con descontento. La renuncia de Stéphane Graber, un desarrollador veterano de Ubuntu y uno de los primeros responsables de LXD, fue una de las respuestas notables a este cambio. Aunque Graber continúa trabajando para Canonical como desarrollador de Ubuntu Core, dejó el mantenimiento de LXD para liderar el desarrollo de un fork llamado Incus.
Puede leer también | Canonical : lanzó actualizaciones de seguridad del kernel de Ubuntu para corregir trece vulnerabilidades
Incus lanzó su primera versión en octubre, ofreciendo mejoras y cambios significativos en comparación con LXD 5.18, según lo expresado por Graber. Estos cambios incluyen la eliminación de características no utilizadas o problemáticas de LXD, que eran difíciles de implementar debido a las restricciones de compatibilidad con versiones anteriores.
Anuncio del Lanzamiento LXD 5.20
El lanzamiento de LXD 5.20, aunque presenta avances técnicos, se ve empañado por su cambio más destacado: la modificación de la licencia del proyecto, que ahora se distribuirá bajo la licencia AGPLv3. Este cambio ha sido percibido como un punto focal de las tensiones y desacuerdos en la comunidad de colaboradores:
"Canonical ha optado por modificar las contribuciones por defecto al proyecto LXD a la licencia AGPLv3, alineándolas con nuestra licencia estándar para el código en el servidor. Todas las contribuciones de Canonical han sido recalificadas y ahora están bajo la licencia AGPLv3, mientras que las contribuciones de la comunidad continúan bajo la Apache 2.0. Seguimos las directrices del Software Freedom Law Center en este asunto. En adelante, cualquier contribución a LXD se realizará automáticamente bajo la licencia AGPLv3. El autor de un cambio seguirá siendo el titular de los derechos de autor de su código, sin cesión de derechos de autor.
Es esencial destacar que este cambio no impide que nuestros usuarios utilicen, modifiquen o proporcionen soluciones de software basadas en LXD, siempre y cuando compartan el código fuente si realizan modificaciones y lo hagan accesible para otros. Las condiciones de la licencia están diseñadas para fomentar la contribución al proyecto y a la comunidad por parte de aquellos que buscan modificar el software".
Sin importar la licencia, los colaboradores pasados y futuros de LXD mantendrán la autoría de sus contribuciones, sin ceder sus derechos de autor, como es común en la mayoría de las licencias de código abierto. Desde la perspectiva del modelo de código abierto, la AGPLv3 parece más adecuada que la Apache 2.0 para fomentar el aprovechamiento completo de la colaboración, más allá de la colaboración en sí misma.
Puede leer también | Canonical : ahora certifica servidores Gigabyte para Ubuntu Linux
Sin embargo, no todos están satisfechos con este cambio. Una vez más, Stéphane Graber señala posibles problemas, especialmente derivados de la combinación de licencias que, aunque inicialmente compatibles entre sí, pueden presentar limitaciones en ciertas direcciones. Además, la obligatoriedad de aceptar el Acuerdo de Licencia de Contribuidor (CLA) también genera preocupaciones. Aunque Graber expone sus inquietudes desde la perspectiva de Incus, es evidente que podrían surgir diversas situaciones problemáticas.
