Si usas Linux Mint y alguna vez has abierto GNOME Calendar para gestionar tus citas, es posible que estés utilizando una aplicación que sus propios creadores no reconocen como suya. Esa es, resumida en una frase, la raíz del conflicto que ha estallado públicamente entre uno de los desarrolladores principales de GNOME Calendar y el equipo de mantenimiento de paquetes de Linux Mint. La disputa no va de código roto ni de un fallo puntual: va de nombres, de identidad y de quién carga con el trabajo de atender a usuarios frustrados. Y toca un nervio que lleva años tensándose en el ecosistema del software libre.
Qué ha modificado Linux Mint en la aplicación de calendario
El punto de partida es una decisión técnica que Mint tomó de forma deliberada. Mientras el proyecto original de GNOME avanzaba hacia GTK4 y libadwaita, la biblioteca de widgets moderna del entorno, Linux Mint forzó un retroceso hacia GTK3 para mantener la compatibilidad con sus propios escritorios y temas visuales. No es un descuido ni un retraso en la actualización: es una regresión activa.
Para completar esa integración, Mint hizo que la aplicación utilizara libAdapta, una bifurcación propia de libadwaita. El problema es que libAdapta está anclada a versiones bastante antiguas: se basa en la 1.5, mientras el proyecto original ya circula por la 1.9. Traducido a tiempo real, hablamos de una brecha de entre dos y cuatro años de obsolescencia acumulada. Y esa distancia tiene consecuencias medibles: cientos de errores antiguos que GNOME ya había parcheado hace años volvieron a aparecer en los equipos de los usuarios de Mint.
Aquí está el detalle que convierte un problema técnico en un conflicto abierto. La versión modificada conserva intacto el nombre oficial de GNOME Calendar y mantiene los enlaces de contacto originales en su ventana de información. Cuando algo falla, el usuario hace lo lógico: busca en la aplicación a quién reportar el fallo, encuentra los canales de GNOME y escribe allí. El resultado es un equipo de voluntarios dedicando su tiempo a clasificar y cerrar quejas sobre problemas que no provocaron o que resolvieron hace años.
Seis meses de silencio y una petición ignorada
Buscando una salida razonable, el equipo de GNOME Calendar abrió un reporte formal en la plataforma de Linux Mint. La petición era modesta y concreta: eliminar las referencias al proyecto principal, retirar los enlaces de soporte y cambiar el nombre y el icono de la aplicación modificada. Nada de exigir que Mint revirtiera sus cambios técnicos ni de cuestionar su derecho a empaquetar el software como quisiera. Solo desvincular la identidad.
Esa petición estuvo seis meses sin respuesta. Cuando el responsable del paquete de Mint finalmente contestó, desvió el foco comparando su situación con la de Ubuntu LTS y Debian, argumentando que esas distribuciones también ofrecen versiones antiguas del calendario. El desarrollador de GNOME señaló de inmediato el fallo del razonamiento: el conflicto no está en la antigüedad del código, sino en distribuir una versión estructuralmente alterada que usurpa la identidad del proyecto original. Los paquetes sin modificar de Debian o Ubuntu no generan ese problema, por muy desactualizados que estén.
La tensión llegó a su punto máximo cuando Linux Mint rechazó categóricamente la solicitud de cambio de marca. En su lugar, el mantenedor sugirió que fueran los propios desarrolladores de GNOME quienes programaran sistemas de advertencia dentro de la aplicación para avisar a los usuarios sobre versiones obsoletas. Es decir, una propuesta que trasladaba todavía más trabajo no remunerado al equipo original para resolver un problema que no había creado.
Dónde termina la licencia libre y empieza la marca registrada
Mint cerró el caso de forma unilateral apoyándose en un argumento que suena impecable sobre el papel: las licencias de software libre permiten este tipo de redistribución y modificación sin restricciones. Y es cierto. Nadie discute que Mint tenga derecho legal a coger el código, modificarlo y distribuirlo.
Pero para los desarrolladores de GNOME esa respuesta confunde deliberadamente dos cosas distintas. La libertad del código y la identidad del proyecto son cuestiones separadas: una licencia libre te permite reutilizar el software, no necesariamente presentarlo al público bajo el nombre y la marca del proyecto original después de haberlo alterado en profundidad. Es una distinción que existe en el ecosistema desde hace tiempo, y que otros proyectos han resuelto precisamente con cambios de nombre en las versiones derivadas.
El desequilibrio de fuerzas es evidente. Escudarse en el argumento de que el proyecto eligió la licencia equivocada resulta cómodo frente a desarrolladores independientes que no disponen de recursos legales para iniciar un litigio por uso indebido de marca. La defensa funciona no porque sea sólida, sino porque la otra parte no puede permitirse ponerla a prueba.
El coste humano detrás de las distribuciones derivadas
Lo que hace que este caso trascienda el conflicto puntual es lo que revela sobre la sostenibilidad del modelo. El agotamiento de los desarrolladores voluntarios no llega de golpe: se acumula reporte a reporte, en horas dedicadas a explicar por enésima vez que ese fallo no existe en la versión oficial, que ese comportamiento se corrigió en 2023, que no, que no pueden ayudar porque ni siquiera es su compilación la que está fallando.
Al distribuir una versión modificada y sin soporte real bajo el nombre explícito de GNOME Calendar, Mint está desplazando una carga de mantenimiento hacia gente que no la pidió, mientras el usuario final se queda con una experiencia degradada y la impresión de que el proyecto original es el responsable. La reputación se erosiona en una dirección y el trabajo se acumula en otra.
Hay algo incómodo en todo esto que va más allá de GNOME y Mint. El software libre construyó su fuerza sobre la libertad de modificar y redistribuir sin pedir permiso, y esa libertad sigue siendo su mayor virtud. Pero el mismo mecanismo que permite a cualquiera adaptar una herramienta a sus necesidades permite también que el coste de esa adaptación aterrice en el buzón de quien no tomó la decisión. Puede que la pregunta que este caso deja abierta no sea cuánto puedes modificar el trabajo ajeno, sino cuánto puedes seguir llamándolo por su nombre después de hacerlo.
Fuente: Desde linux
Añadir comentario
Comentarios