Olá a todos!
Venho cá hoje falar de algo que acho que merece muito mais atenção do que está a receber nos círculos técnicos portugueses. O The Register publicou em 26 de março de 2026, que o GitHub vai começar a usar os dados de interação dos seus utilizadores para treinar os seus modelos de IA — e não está a pedir autorização. Está a assumir consentimento por defeito, com a possibilidade de opt-out enterrada algures nas definições.Se usam o GitHub Copilot — na versão Free, Pro, ou Pro+ — e não fizerem nada, a partir de 24 de abril o vosso código, os vossos comentários, as vossas interações com o assistente, tudo isso passa a ser ingrediente no próximo modelo de IA da Microsoft.
Mas isto não é só uma notícia sobre o Copilot. É sobre algo muito maior, e vou tentar explicar porquê.
O que está realmente a acontecer
A mudança de política é cirúrgica na sua redação, mas explosiva nas suas implicações. Segundo o The Register, o GitHub vai passar a recolher, para treino de IA, inputs e outputs das interações com o Copilot, snippets de código mostrados ao modelo, o contexto à volta do cursor, comentários e documentação que escreveram, nomes de ficheiros e estrutura de repositórios, interações com features do Copilot como chats, e feedback que deram ao modelo.A parte que me fez levantar as sobrancelha feito o Spock foi esta: os repositórios privados também estão em cima da mesa. A FAQ oficial do GitHub é explícita: se um utilizador do Copilot tiver as definições configuradas para permitir treino com os seus dados, snippets de repositórios privados podem ser recolhidos e usados para treino de modelos enquanto o utilizador está a trabalhar ativamente nesses repositórios.
Façam uma pausa e deixem essa frase sink in.
Um repositório “privado” no GitHub sempre significou, em teoria, que só vocês, as pessoas com quem explicitamente partilharam acesso, e certos membros da organização, tinham acesso. Agora significa isso com um asterisco. E esse asterisco diz “exceto o GitHub, que pode usar o conteúdo para treinar IA se não tiverem feito opt-out.”O Mario Rodriguez, Chief Product Officer do GitHub, até faz o discurso motivacional habitual, prometendo que a participação vai ajudar os modelos a compreender melhor os workflows de desenvolvimento, a fazer sugestões mais precisas e seguras, e a melhorar a capacidade de encontrar bugs antes que cheguem à produção. Muito bonito. O problema é que ninguém vos pediu isso. Simplesmente assumiram que queriam contribuir para o produto deles.
O problema da privacidade — e não é só o código
Quando falamos de código em repositórios privados, tendemos a pensar em propriedade intelectual de empresas. E sim, esse é um problema enorme, sobre o qual vou falar a seguir. Mas há outra dimensão que raramente é mencionada: a privacidade pessoal e organizacional.Pensem no que costuma estar num repositório de desenvolvimento ativo. Variáveis de ambiente comentadas onde alguém se esqueceu de as remover. Strings de conexão a bases de dados em ficheiros de configuração de desenvolvimento. Nomes de clientes ou parceiros em comentários que explicam o contexto de um bug. Arquitetura interna de sistemas que uma empresa prefere não publicitar. Estratégias de produto em ficheiros README de repositórios internos.Agora pensem que isso tudo pode passar a fazer parte do contexto que alimenta um modelo de linguagem da Microsoft. Não para ser publicado diretamente — o GitHub não é assim tão ingénuo — mas para ser usado no treino de um modelo que depois vai ser usado por milhares de outros developers. Informação que pensávamos estar num cofre passa a ser um tijolo numa parede que não controlamos.E há mais.
Os “comentários e documentação” que o GitHub quer recolher incluem a forma como a vossa equipa pensa sobre os problemas, as decisões arquiteturais que tomaram e as razões delas, os trade-offs que consideraram. Isso não é só código — é conhecimento. É o tipo de contexto que define como uma organização resolve problemas, e que levou anos a acumular.Do ponto de vista do Regulamento Geral de Proteção de Dados, a situação europeia é particularmente interessante — e não no bom sentido. O GitHub reconhece implicitamente isto quando nota que o modelo de opt-out que está a aplicar segue “práticas estabelecidas da indústria” americanas, por oposição às normas europeias onde o opt-in é normalmente exigido. Ou seja, sabem que esta abordagem não passaria em GDPR se aplicada com rigor. A questão é quem vai fazer cumprir, quando, e com que consequências práticas.
O problema da propriedade intelectual — que é ainda mais complicado do que parece
A questão da propriedade intelectual de código é um labirinto legal que a indústria tecnológica tem sistematicamente evitado olhar de frente, e esta mudança de política do GitHub acelera um confronto que vai acabar por acontecer.
Quando uma empresa desenvolve software proprietário e usa o GitHub como repositório privado, parte do pressuposto de que esse código é confidencial. As equipas jurídicas de muitas empresas vão ter de examinar com atenção se esta mudança de política constitui uma violação dos acordos de confidencialidade internos, dos contratos com clientes que proíbem partilha de informação proprietária, das obrigações fiduciárias em relação a acionistas, e das regulamentações setoriais em industrias como financeiras, saúde, e defesa.Mas o problema vai mais fundo. O código open source tem licenças. Licenças como GPL, AGPL, e outras copyleft têm requisitos específicos sobre como o código pode ser usado e redistribuído. Quando esse código é usado para treinar um modelo de IA, o que acontece? O modelo é um “trabalho derivado”? Os outputs do modelo são cobertos pelas licenças do código que lhe serviu de treino? Ninguém tem uma resposta definitiva para isto ainda, e os tribunais vão ter de a construir ao longo dos próximos anos.O The Register nota, aliás, que o Codex da OpenAI — que alimenta o GitHub Copilot — foi “fine-tuned em código publicamente disponível no GitHub.” Ou seja, o cavalo já saiu da estrebaria há muito tempo, para usar a metáfora do artigo. Mas isso não significa que devemos simplesmente aceitar que o próximo passo seja o código privado.
Há também uma dimensão competitiva que raramente é discutida abertamente. O GitHub pertence à Microsoft. A Microsoft compete com muitas das empresas cujo código está alojado no GitHub. Quando uma startup de software decide usar o GitHub para os seus repositórios privados, implicitamente confia em que a Microsoft não vai usar o seu código para beneficiar um competidor. Esta mudança de política não viola diretamente essa confiança — o GitHub não vai dar o vosso código à Azure — mas cria um precedente e uma infraestrutura que tornam esse tipo de uso mais plausível no futuro.
O opt-out que não resolve o problema
O GitHub oferece opt-out. Para o fazer, devem ir a /settings/copilot/features e desativar “Allow GitHub to use my data for AI model training” sob o cabeçalho Privacy.
Vão fazer isso agora? Ótimo. Mas isto não resolve o problema estrutural, e vou explicar porquê.
Primeiro, o opt-out tem de ser feito utilizador a utilizador. Numa organização com cinquenta developers, isso significa cinquenta pessoas que têm de saber que esta mudança está a acontecer, perceber as implicações, e tomar uma ação ativa. Na prática, a maioria das organizações vai ter uma mistura de pessoas que fizeram opt-out e pessoas que não fizeram — o que significa que o código do repositório privado pode estar a ser recolhido através das sessões de Copilot de qualquer developer que não agiu.
Segundo, os utilizadores Copilot Business e Copilot Enterprise estão isentos por força dos termos contratuais das suas subscrições pagas. Estudantes e professores também. Mas os utilizadores Free, Pro, e Pro+ — que são a maioria dos developers individuais e de pequenas equipas — estão sujeitos a esta política por defeito.
Terceiro, e mais importante: hoje é o opt-out de treino de modelos. O que é amanhã? A lógica de “opt-out disponível, portanto está tudo bem” estabelece um precedente. Cada nova forma de recolha de dados pode usar o mesmo argumento — a opção de não participar existe, em algum menu, algures. Esta é uma das razões pelas quais o GDPR existe: porque o opt-out per se não é proteção suficiente quando a assimetria de poder entre o utilizador e a plataforma é tão grande.
A questão mais profunda: de quem é o código open source?
Aqui é onde as coisas ficam genuinamente interessantes, porque esta situação levanta uma questão que o movimento open source tem estado a evitar.
O GitHub tornou-se, ao longo dos últimos quinze anos, a infraestrutura central do software open source mundial. Projetos que começaram em servidores independentes, em sourceforge, em repositórios pessoais, foram gradualmente migrando para o GitHub porque era conveniente, tinha ferramentas boas, e tinha onde a comunidade estava. E essa centralização trouxe benefícios reais — facilidade de contribuição, visibilidade, integração com CI/CD.
Mas também criou uma dependência preocupante. O código open source que vive no GitHub está sujeito às políticas de uma empresa privada que pertence à Microsoft e que tem os seus próprios interesses comerciais. Quando o GitHub decide que vai usar esse código para treinar IA, os projetos open source que lá estão alojados não têm mecanismos de defesa efetivos, para além de migrar.
E migrar é difícil. É onde os utilizadores estão. É onde os workflows estão. É onde os sistemas de CI/CD estão configurados. A fricção de mover um projeto ativo para outra plataforma é real, e o GitHub sabe isso.
Mas talvez seja precisamente esse o momento de falar seriamente de alternativas.
A alternativa que devia existir: instâncias próprias e self-hosted
Há uma conversa que a comunidade técnica tem tido em voz baixa há anos e que este momento deveria tornar mais alta: a do alojamento próprio de infraestrutura de desenvolvimento.
O Gitea é um servidor Git self-hosted, escrito em Go, extremamente leve, com uma interface web completa, suporte a issues, pull requests, CI/CD básico, e compatível com o ecossistema de ferramentas que já usam. Instala num VPS de dez euros por mês. Consome menos de 100MB de RAM em idle. É open source, sem licenças comerciais, sem tracking, sem políticas de uso de dados que possam mudar de um dia para o outro.
O Forgejo é um fork do Gitea, gerido pela comunidade precisamente porque alguns developers queriam garantir que o projeto nunca fosse adquirido ou sujeito a pressões comerciais. É funcionalmente equivalente ao Gitea mas com uma governança mais aberta.
O GitLab tem uma versão Community Edition que se pode instalar on-premises com funcionalidades muito mais avançadas — pipelines de CI/CD completos, gestão de issues sofisticada, wikis integradas, container registry, e muito mais. É mais pesado em recursos mas é a escolha natural para equipas que precisam de um ambiente de desenvolvimento completo sem dependências externas.
A beleza de qualquer uma destas opções é que o código fica literalmente nos vossos servidores. Não há política de privacidade de terceiros que se aplique. Não há empresa que possa decidir unilateralmente que vai usar os vossos dados para treinar IA. O modelo de treino da Microsoft não tem acesso ao que está na vossa instância de Gitea, porque a vossa instância de Gitea está numa máquina que vocês controlam.
E aqui está o ponto que me parece crucial para o open source especificamente: uma instância self-hosted mas com acesso público não é menos “open” do que um repositório no GitHub. Um projeto alojado em git.vossaorganizacao.pt pode ser completamente público — qualquer pessoa pode clonar, fork, contribuir, abrir issues. A diferença é que os dados de interação ficam nos vossos servidores, não nos da Microsoft.
Isto é importante porque resolve um equívoco que ouço às vezes: “mas o GitHub é necessário para a visibilidade do projeto.” Não é. O GitHub é conveniente para a visibilidade, mas não é necessário. Projetos como o kernel Linux, o FreeBSD, o Debian, e muitos outros têm infraestrutura própria e continuam a ter contribuidores ativos de todo o mundo. O que é necessário é que o repositório seja acessível pela internet, e isso consegue-se com qualquer instância self-hosted com um domínio e uma porta aberta.
Como começar — sem entrar em pânico
Se estão a considerar a migração, aqui está uma abordagem razoável.
Para projectos pessoais e pequenas equipas, o Gitea ou o Forgejo são a escolha óbvia. Um VPS de 1-2 CPUs e 1-2GB de RAM é mais do suficiente para uma equipa de dezena de pessoas. Há imagens Docker oficiais que tornam o deployment numa questão de minutos. A migração de repositórios GitHub é suportada nativamente — o Gitea tem um importador que replica repositórios, issues, pull requests, e comentários.
Para organizações maiores, o GitLab Community Edition é provavelmente a escolha certa. Requer mais recursos — recomendam 4 CPUs e 4GB de RAM para começar — mas oferece um ecossistema completo que reduz a necessidade de ferramentas externas. Se já têm infraestrutura Kubernetes, há um chart Helm oficial.
Não precisam de migrar tudo de uma vez. Uma estratégia razoável é começar a colocar projetos novos em self-hosted, manter os projetos públicos existentes no GitHub para visibilidade enquanto adicionam um mirror self-hosted, e migrar gradualmente os projetos privados com mais sensibilidade.
E sim — o GitHub pode continuar a ser usado como mirror público de projetos open source, sem ser o repositório autoritativo. Isso dá-vos o melhor dos dois mundos: visibilidade na maior plataforma do mundo, mas controlo total sobre os dados de desenvolvimento no vosso servidor.
Uma palavra sobre o GDPR e Portugal especificamente
Para os leitores portugueses e europeus em geral: esta mudança de política tem implicações específicas para organizações sujeitas ao GDPR.
Se a vossa organização usa o GitHub com Copilot e tem repositórios privados com dados que possam indiretamente identificar pessoas — e a maioria dos repositórios de desenvolvimento empresarial tem — existe uma questão legítima sobre se esta recolha de dados para treino de IA é compatível com as obrigações GDPR da vossa organização. Não sou advogado, e isto não é aconselhamento jurídico, mas recomendo fortemente que levantem esta questão com o vosso DPO se tiverem um, ou que consultem alguém especializado se não tiverem.
A CNPD, a Comissão Nacional de Proteção de Dados, tem estado razoavelmente ativa na supervisão de questões de transferência de dados para os EUA. Este tipo de recolha de dados para treino de IA por uma empresa americana é exatamente o género de situação que o GDPR foi desenhado para regular.
Fechando o ciclo
O GitHub vai fazer o que as empresas fazem: otimizar para os seus interesses. A Microsoft pagou 7,5 mil milhões de dólares pelo GitHub em 2018, e precisa de justificar esse investimento. A IA generativa é onde o dinheiro está a ser gasto, e os dados de código são um dos ativos mais valiosos para treinar modelos de programação. A lógica de negócio é impecável.
O que é menos impecável é assumir que os utilizadores consentiram simplesmente por não terem lido as notas de versão de uma mudança de política. O modelo de opt-out em vez de opt-in é uma escolha deliberada — e as 59 reações negativas contra 3 positivas na discussão da comunidade GitHub dizem tudo o que é necessário dizer sobre como os utilizadores se sentem em relação a isso.
A resposta sensata não é entrar em pânico, mas é definitivamente questionar o pressuposto de que centralizar toda a infraestrutura de desenvolvimento num único serviço controlado por uma corporation americana é uma boa ideia a longo prazo.
O open source nasceu precisamente da ideia de que o software deve pertencer à comunidade, que a infraestrutura deve ser controlável, e que a dependência de entidades comerciais cria vulnerabilidades. Está na altura de aplicar esses princípios à infraestrutura onde o próprio open source vive.
Um Gitea no vosso servidor. Um Forgejo na vossa VPS. Um GitLab numa máquina da empresa. São opções que existem, funcionam muito bem, e colocam o controlo onde deve estar — nas vossas mãos.
O código que escrevem é vosso, dado por vossa vontade á comunidade. A infraestrutura que o aloja devia ser também.
Um abraço, Nuno
P.S.: Para os que querem fazer o opt-out imediato no GitHub enquanto avaliam alternativas — vão a github.com/settings/copilot/features e desativem “Allow GitHub to use my data for AI model training” na secção Privacy. Demora trinta segundos, e vale a pena fazer hoje.
P.P.S.: Se estiverem a considerar self-hosting e quiserem ajuda a configurar uma instância de Gitea ou GitLab, deixem um comentário. É exatamente o tipo de how-to que gosto de escrever.
TLDR: O link para opt-out é este.