Canonical ha anunciado el lanzamiento de LXD 5.20, nueva versión del sistema de gestión de virtualización y contenedores, herramienta estándar de referencia para LXC, y la primera que ve la luz en su nueva casa, y es que estamos hablando de un proyecto que está al cargo de de la misma desarrolladora de Ubuntu, por supuesto, no sin polémica y movimientos encontrados.
Así, tras saberse que Linux Containers trasladaba la propiedad de LXD a Canonical comenzó la oposición comunitaria por parte, entre otros, de los mantenedores del mismo, que veían cómo Canonical cerraba las puertas a todo aquel que no fuese empleado de la compañía. La posibilidad de colaboración seguía -y sigue- ahí, pero pasando siempre por el aro de Canonical, algo con lo que no todo el mundo estaba de acuerdo.
O lo que es lo mismo, todo aquel que lo desee puede seguir colaborando con el desarrollo de LXD, pero aceptando las nuevas condiciones impuestas por Canonical, entre otras, la aceptación del Acuerdo de Licencia de Contribuidor (CLA) que tan poco suele gustar, algo de lo que ya se advirtió y que, en efecto, ha terminado sucediendo.
Las consecuencias no se hicieron esperar y una de las más destacadas fue la renuncia de Stéphane Graber, veterano desarrollador de Ubuntu y uno de los primeros responsables de LXD. De hecho, es cuando menos curiosa la posición de Graber, pues sigue trabajando para Canonical como desarrollador de Ubuntu Core, pero se apeó del mantenimiento de LXD tras el reciente cambio de marco… para encabezar el desarrollo de un fork.
«Seguiré siendo un usuario activo de LXD y probablemente seguiré reportando y solucionando problemas ocasionalmente. Sin embargo, no tengo la intención de firmar nunca el CLA de Canonical, por lo que si eso se convierte en una barrera para la contribución al proyecto, tendré que dejar de contribuir», señalaba Graber al darse el anuncio de un fork de LXD respaldado por Linux Containers. Sin duda, estas cosas solo pasan en el mundo del código abierto.
Ese fork, llamado Incus, lanzó su primera versión el pasado octubre y, según comentaba el propio Stéphane Graber, «es aproximadamente equivalente a LXD 5.18, pero con una serie de cambios importantes», incluyendo «muchas funciones no utilizadas o problemáticas de LXD. La mayoría de esos cambios son cosas que nos hubiera gustado hacer en LXD pero no pudimos debido a que teníamos fuertes garantías de compatibilidad con versiones anteriores».
Envuelto en semejante clima aparece LXD 5.20, un lanzamiento cuyas novedades técnicas están siendo eclipsadas por otras que apuntan hacia donde lo hacían las suspicacias de los colaboradores revueltos, que no solo. El cambio más destacado según recoge el anuncio oficial es el relicenciamiento del proyecto, cuyo código se distribuirá ahora bajo la licencia AGPLv3. Así lo explican:
«Canonical ha decidido cambiar las contribuciones predeterminadas al proyecto LXD a AGPLv3 para que estén alineadas con nuestra licencia estándar para código del lado del servidor. Todas las contribuciones de Canonical han sido relicenciadas y etsán ya bajo la AGPLv3. Las contribuciones de la comunidad se mantienen bajo la Apache 2.0. Seguimos la guía del Software Freedom Law Center en relación con esto. En el futuro, cualquier contribución a LXD se realizará bajo AGPLv3 de forma predeterminada. El autor de un cambio seguirá siendo el titular de los derechos de autor de su código, pero sin cesión de derechos de autor.
Es importante tener en cuenta que este cambio no impide que nuestros usuarios utilicen, modifiquen o proporcionen soluciones de software basadas en LXD, siempre que compartan el código fuente si lo modifican y lo pongan a disposición de otros. Las condiciones de la licencia están diseñadas para alentar a quienes buscan modificar el software a contribuir al proyecto y a la comunidad.»
En resumen, idependientemente de la licencia, los colaboradores pasados y futuros de LXD conservarán la autoría de sus contribuciones, pero sin cesión de derechos de autor. Lo normal en casi cualquier licencia de código abierto. En cuanto a las licencias, desde el punto de vista del modelo del código abierto la AGPLv3 está más indicada que la Apache 2.0 para fomentar el aprovechamiento de toda colaboración, que no la colaboración en sí.
Pero no todo el mundo está contento con el cambio. Una vez más, Stéphane Graber advierte de problemas, derivados en este caso de la mezcla de licencias, compatibles entre sí a priori, pero no en todas direcciones, así como de la obligatoriedad de aceptar el CLA. Y aunque expone sus temores desde la perspectiva de Incus, lo cierto es que podrían darse situaciones de todo tipo.
