Google mató los tags de Git de Android: el código ahora se pide por formulario y GrapheneOS dice que viola la GPL

Google decidió que publicar el código fuente ya no se hace con Git: ahora se pide por formulario y te lo mandan por Google Drive. Literal.

El equipo de GrapheneOS, el sistema operativo enfocado en privacidad para Pixel, destapó el cambio en una publicación que explotó en Hacker News con casi 300 puntos y 128 comentarios en horas.

La acusación es grave: Google estaría violando la GPLv2, la licencia que obliga a quien distribuye software basado en Linux a entregar el código fuente a quien lo pida.

¿Qué cambió exactamente?

Antes, si querías el kernel de Pixel o los drivers de usuario, ibas a AOSP y ahí estaban los tags de Git: versiones etiquetadas, historial completo, descargables con un simple git fetch.

Eso murió. Según GrapheneOS, Google ya no empuja los tags de Git para el código del kernel de Pixel ni los drivers a AOSP.

Ahora tenés que llenar un formulario de Google y esperar a que un humano te pase un link de Google Drive con el código.

El proceso es lento y opaco, denuncia GrapheneOS, y empeora con el tiempo.

La trampa legal de Google

A simple vista parece un capricho. Pero hay un detalle de ingeniería legal que lo hace brillante: un tarball en Drive no es la "forma preferida del trabajo para hacer modificaciones", como exige la GPLv2.

Sin tags, sin historial de commits y sin estructura de repositorio, el código entregado es técnicamente "fuente", pero es casi inútil para mantener un proyecto real encima.

Para desarrolladores de custom ROMs como GrapheneOS o LineageOS, es como recibir los planos de un edificio... sin las medidas ni los nombres de las habitaciones.

En Hacker News el debate es feroz: hay quien dice que es "malicious compliance" (cumplimiento malicioso, legal pero en mala fe), y quien sostiene que Google está dentro de la letra de la licencia.

No es solo Pixel: AOSP entero se cierra

El formulario de Google revela otra capa: "podríamos cobrarte una tarifa para cubrir el costo" de entregarte tu propio código.

Y la cosa va más lejos: AOSP ahora publica sus releases grandes solo dos veces al año (Q2 y Q4). Nada de lanzamientos mensuales como antes.

Google dice que es por su "modelo de desarrollo trunk stable". Los críticos lo resumen distinto: menos código público, más control, menos competencia.

Para el ecosistema de custom ROMs —que nació y vive de la apertura de Android— esto es un golpe directo.

La ironía de todo esto

Android existe gracias a Linux, y Linux existe gracias a la GPL. La misma licencia que Google usó para construir su imperio móvil hoy le estorba.

Si esto escala, el siguiente paso podría ser una demanda o una disputa ante la Free Software Foundation. El precedente de la GPL es largo y Google lo sabe.

Mientras tanto, el mensaje a los desarrolladores es claro: el "open source" de Google tiene límites, y los estás viendo en tiempo real.

En Latinoamérica, donde las custom ROMs alargan la vida de millones de teléfonos económicos, esta pelea nos toca de cerca.

Conclusión

Google no quebró la ley (todavía). Pero encontró una forma de hacer que el código abierto duela: cumplir al pie de la letra lo mínimo y hacer el resto cuesta arriba.

La pregunta de fondo: si el dueño del ecosistema más grande de open source móvil trata así a la GPL, ¿qué podemos esperar del resto?

Comparte esto con alguien que todavía cree que el Android de Google es código abierto de verdad.

¿Crees que la GPLv2 cubre este caso o Google encontró el hueco definitivo? Déjalo en los comentarios.