Google ha dejado de publicar etiquetas Git para parte del código fuente de Android

Artículo original ↗ Discusión en Hacker News ↗

Google ha dejado de publicar algunas fuentes de Android y del kernel de Pixel mediante etiquetas Git públicas y ahora exige que los desarrolladores soliciten tarballs a través de un Google Form, que luego se entregan mediante Google Drive tras retrasos de días o semanas. Los comentaristas debaten si esto satisface la letra de GPLv2 mientras socava claramente su espíritu, argumentando que retener código fuente puntual y nativo de Git dificulta que proyectos descendentes como las ROM personalizadas sigan los cambios y publiquen actualizaciones de seguridad. Muchos ven la medida como parte de una tendencia más amplia de Android hacia un modelo menos abierto y más estrictamente controlado, junto con próximas restricciones a la carga lateral y a los ecosistemas de terceros.

Qué cambió en la distribución de código fuente de Google

  • Google dejó de publicar ciertas etiquetas Git relacionadas con Android (especialmente para código específico de Pixel) en AOSP.
  • Para los controladores del kernel de Pixel y otros componentes GPL/LGPL, el código fuente ahora se proporciona mediante archivos tar en Google Drive, accesibles solo después de enviar un Google Form.
  • Antes, las etiquetas se publicaban regularmente y los tarballs (cuando se usaban) solían estar disponibles en cuestión de horas; ahora las respuestas a menudo tardan semanas.
  • Los nuevos tarballs son monolíticos, con historial aplastado y metadatos extra del repositorio, en lugar de la estructura original de muchos repositorios Git.

Cumplimiento de GPL vs. “cumplimiento malicioso”

  • Un lado sostiene que Google está en clara violación de GPLv2:
    • Retrasos de semanas no constituyen un “tiempo razonable” dadas las capacidades de Google.
    • El código fuente no está en la “forma preferida para hacer modificaciones” porque el sistema de compilación de Android espera múltiples repositorios Git y ejecuta comandos de Git; el formato solo en tarball provoca errores.
  • Otros argumentan que probablemente cumple técnicamente:
    • GPLv2 permite el código fuente bajo pedido e incluso en medios físicos, sin un límite temporal explícito.
    • Históricamente, se han aceptado instantáneas sin todo el historial del VCS.
    • Google Drive + un proceso manual se ve como hostil, pero aún dentro de la letra de la licencia.
  • Hay desacuerdo sobre si el “medio habitualmente usado para el intercambio de software” podría excluir Google Drive o imponer expectativas de tiempo.

Impacto en proyectos descendentes y el ecosistema

  • Los proyectos de sistemas operativos personalizados dirigidos a dispositivos Pixel informan daños concretos: las fuentes del kernel retrasadas bloquean el soporte oportuno para versiones estables y beta.
  • Los Pixel se comercializaron como dispositivos de referencia de AOSP con largos periodos de soporte; algunos sostienen que dejar de publicar lanzamientos específicos de Pixel para AOSP socava esos compromisos.
  • La fricción hace que los Pixel sean más difíciles, no más fáciles, para ROMs de terceros, empujándolos hacia otros fabricantes (por ejemplo, Motorola).

Motivos percibidos y preocupaciones más amplias

  • Los motivos especulados incluyen:
    • Aumentar el control sobre el ecosistema Android y las ROM de terceros.
    • Ralentizar el análisis de parches de seguridad y vulnerabilidades.
    • Alinear con movimientos más amplios como endurecer la carga lateral y la verificación de desarrolladores.
  • Muchos ven el cambio como parte de una tendencia: Android alejándose de lo “abierto” hacia un modelo más cerrado, parecido al de iOS, aunque el AOSP central siga siendo de código abierto.