Google parou de publicar tags Git para parte do código-fonte do Android

Artigo original ↗ Discussão no Hacker News ↗

O Google parou de publicar certas fontes do Android e do kernel do Pixel por meio de tags Git públicas e agora exige que os desenvolvedores solicitem tarballs por um Google Form, que são então entregues via Google Drive após atrasos de dias ou semanas. Comentadores debatem se isso cumpre a letra da GPLv2 enquanto claramente mina seu espírito, argumentando que reter código-fonte oportuno e nativo de git torna mais difícil para projetos downstream, como ROMs customizadas, acompanhar mudanças e lançar atualizações de segurança. Muitos veem a medida como parte de uma tendência mais ampla de o Android se tornar menos aberto e mais rigidamente controlado, junto com futuras restrições ao sideloading e aos ecossistemas de terceiros.

O que mudou na distribuição de código-fonte do Google

  • O Google deixou de publicar certas tags Git relacionadas ao Android (especialmente para código específico de Pixel) no AOSP.
  • Para drivers de kernel do Pixel e outros componentes GPL/LGPL, o código-fonte agora é fornecido via tarballs no Google Drive, obtidos apenas após o envio de um Google Form.
  • Antes, as tags eram enviadas regularmente e os tarballs (quando usados) costumavam ser disponibilizados em poucas horas; agora, as respostas frequentemente levam semanas.
  • Os novos tarballs são monolíticos, com histórico compactado e metadados extras do repositório, em vez da estrutura original de muitos repositórios Git.

Conformidade com a GPL vs. “conformidade maliciosa”

  • Um lado argumenta que o Google está em clara violação da GPLv2:
    • Atrasos de várias semanas não são um “prazo razoável” dada a capacidade do Google.
    • O código-fonte não está na “forma preferida para fazer modificações” porque o sistema de build do Android espera vários repositórios Git e executa comandos Git; a forma apenas em tarball causa erros.
  • Outros argumentam que provavelmente há conformidade técnica:
    • A GPLv2 permite código-fonte sob solicitação e até mídia física, sem limite de tempo explícito.
    • Historicamente, snapshots sem o histórico completo de VCS têm sido aceitos.
    • Google Drive + um processo manual é visto como hostil, mas ainda dentro da letra da licença.
  • Há divergência sobre se o “meio comumente usado para intercâmbio de software” poderia excluir o Google Drive ou impor expectativas de tempo.

Impacto em projetos downstream e no ecossistema

  • Projetos de sistemas operacionais customizados voltados para Pixels relatam dano concreto: atrasos no código-fonte do kernel bloqueiam suporte oportuno para versões estáveis e beta.
  • Os Pixels foram divulgados como dispositivos de referência do AOSP com longas janelas de suporte; alguns argumentam que abandonar lançamentos específicos para Pixel enfraquece esses compromissos.
  • A fricção torna os Pixels mais difíceis, e não mais fáceis, para ROMs de terceiros, empurrando-os para outros fabricantes (por exemplo, Motorola).

Motivos percebidos e preocupações mais amplas

  • Os motivos especulados incluem:
    • Aumentar o controle sobre o ecossistema Android e ROMs de terceiros.
    • Atrasar a análise de patches de segurança e vulnerabilidades.
    • Alinhar-se a movimentos mais amplos, como endurecer o sideloading e a verificação de desenvolvedores.
  • Muitos veem a mudança como parte de uma tendência: o Android se afastando do “aberto” em direção a um modelo mais fechado, semelhante ao iOS, mesmo que o AOSP principal continue sendo de código aberto.