Controversia en el Kernel de Linux: Disputa por la Autoría del Código Rust para DRM.

Publicado el 18 de abril de 2025, 10:07

En los últimos meses, la comunidad del kernel de Linux ha vivido una situación especialmente tensa y delicada en torno a la inclusión de Rust como lenguaje oficial dentro del núcleo. Aunque en su momento Linus Torvalds intentó calmar las aguas, las polémicas no han cesado. Y una de las más sonadas ha girado en torno a la autoría de un conjunto de parches escritos en Rust para el subsistema DRM (Direct Rendering Manager), centrados en el soporte de controladores gráficos.

¿Qué está pasando exactamente?

La disputa involucra a dos desarrolladores destacados: Lina Asahi, conocida por su trabajo en el controlador drm-asahi para GPUs Apple AGX, y Danilo Krummrich, mantenedor del controlador Nouveau para GPUs NVIDIA.

Todo comenzó cuando Danilo presentó una serie de parches para añadir soporte DRM en Rust al kernel de Linux. Lo que encendió la mecha fue que estos parches estaban basados, en gran medida, en el trabajo previo de Lina, pero en los commits, Danilo aparecía como autor principal de la mayoría de ellos. Aunque sí mencionaba a Lina como inspiración y colaboradora, ella no aparecía como autora principal en archivos donde, según su versión, había escrito la mayor parte del contenido.

El punto álgido: ¿quién escribió qué?

Uno de los ejemplos más discutidos es el archivo drm/drv.rs, con 321 líneas de código. Lina asegura haber escrito 280 líneas, mientras que el resto de los cambios eran simples comentarios o ajustes menores. Desde su perspectiva, el archivo no fue reescrito sustancialmente, por lo que ella debía figurar como autora principal.

En un mensaje dirigido a Danilo, Lina expresó lo siguiente:

“Me pregunto por qué asumiste la autoría principal de algunos parches. Por ejemplo, el parche n.º 3 lo tiene como autor principal y, sin embargo, cuando hago una comparación… De esas 41 líneas añadidas, la mayoría son comentarios y reelaboración del registro. Pensé que la etiqueta general del kernel es que se mantenga el autor original a menos que estés literalmente reescribiendo la mayor parte del archivo desde cero…”

Danilo, por su parte, respondió que había reestructurado el código, dividiéndolo en varios archivos y ajustando diversas secciones. Además, alegó que Lina le había dado permiso explícito para usar su código sin restricciones, aunque nunca se discutió formalmente cómo se gestionaría la autoría.

“Por ejemplo, el parche al que haces referencia a continuación (...) se ha dividido en tres diferentes parches, donde uno de ellos tiene prácticamente el mismo código, los otros dos fueron modificados.”

A pesar de mostrarse dispuesto a corregir las atribuciones si Lina especificaba en qué parches debía figurar como autora principal, ella consideró que esa solución era insuficiente. Desde su punto de vista, el permiso para usar el código no equivale a renunciar al reconocimiento de su trabajo.

Escalada del conflicto

Lo que pudo haber sido una conversación técnica se transformó en una disputa personal. Lina acusó a Danilo de minimizar deliberadamente su contribución e incluso de robarle el crédito por años de desarrollo. En respuesta, Danilo publicó un diff de 1462 líneas como prueba de sus aportes y volvió a reiterar su disposición para modificar la autoría donde correspondiera.

La situación tocó fondo cuando Lina, decepcionada, solicitó que se eliminara por completo su nombre de los commits y liberó el código bajo una licencia CC0 (dominio público). Una decisión radical que refleja su nivel de frustración.

Intervención de los mantenedores

Ante el aumento de tensión, intervino Dave Airlie, mantenedor del subsistema DRM en el kernel, quien zanjó el asunto afirmando que la autoría original de Lina debía mantenerse en cualquier parche que incluyera partes de su código. Además, pidió que se dejara de alimentar el drama públicamente.

Lina, sin embargo, revisó los cambios y concluyó que más del 50% del nuevo código provenía directamente de sus parches anteriores. Si se excluyen los comentarios, estimó que su contribución real alcanzaba el 75%. Solicitó ser reconocida como autora principal en los parches 3 al 7, si no se iba a eliminar su nombre por completo.

Pausa indefinida y un ambiente hostil

Este conflicto fue la gota que colmó el vaso. Lina anunció una pausa indefinida en su participación en el desarrollo del controlador Asahi, afirmando que ya no se sentía segura trabajando en ese entorno. Este anuncio se sumaba a la renuncia previa de Héctor Martín, líder del proyecto Asahi Linux, quien en febrero ya había abandonado el mantenimiento de la plataforma ARM/Apple en el kernel, denunciando un ambiente hostil hacia la integración de Rust en el núcleo.

¿Quién es realmente Lina Asahi?

En medio del conflicto, surgieron también teorías sobre la identidad de Lina Asahi. Algunos en la comunidad especulan que podría tratarse de un seudónimo o incluso de una identidad virtual creada por el propio Héctor Martín.

  • Lina no ha aparecido públicamente en eventos o transmisiones como una persona real.

  • Usa un avatar animado como representación.

  • En algunas transmisiones se han visto referencias a nombres de equipo y rutas de usuario como "raider", coincidentes con el entorno de Héctor, cuyo alias es marcan.

Aunque no hay pruebas concluyentes, las especulaciones han generado aún más ruido en torno a una situación ya de por sí cargada.

Este caso pone sobre la mesa temas sensibles pero fundamentales: la gestión de autoría en proyectos colaborativos, el reconocimiento al trabajo previo, y cómo manejar los conflictos dentro de una comunidad técnica. También deja claro que la integración de nuevos lenguajes como Rust, aunque prometedora, no está exenta de resistencias internas, malentendidos y disputas personales.

La comunidad del kernel de Linux tiene el reto de aprender de este conflicto, mejorar la comunicación y fortalecer las normas que rigen la colaboración para que todos los desarrolladores, sin importar su nivel de visibilidad o estilo de trabajo, se sientan valorados, respetados y protegidos.

 

Fuent: linuxOS

Añadir comentario

Comentarios

Todavía no hay comentarios