Não há direito de relicenciar este projeto

• Mark Pilgrim, autor original do chardet, apontou uma violação da licença LGPL no projeto e exigiu a reversão da recente mudança para a licença MIT na versão 7.0.0
• Ele afirmou que, mesmo que os mantenedores aleguem uma “reescrita completa”, trata-se de um derivado escrito com exposição direta ao código original, portanto deve continuar sob LGPL
• Vários desenvolvedores discutiram se uma reescrita assistida por IA realmente constitui uma “implementação clean room” e se o LLM foi treinado com o código original
• Alguns mencionaram a compatibilidade de API e a possibilidade de fair use, mas a maioria demonstrou preocupação com a possibilidade de violação de direitos autorais e a incerteza jurídica do código gerado por IA
• A discussão vem sendo vista como um precedente importante em torno da responsabilidade autoral do código gerado por IA, dos procedimentos para mudança de licença em projetos open source e dos limites da autoridade de mantenedores

---

O questionamento de Mark Pilgrim

• Mark Pilgrim declarou ser o autor original do chardet e afirmou que o projeto vinha sendo distribuído sob a licença LGPL
  • Ele apontou que a alegação do mantenedor de que teria o “direito de relicenciar” na versão 7.0.0 está errada
  • Enfatizou que código sob LGPL, mesmo quando modificado, deve ser publicado sob a mesma licença, e que a alegação de “reescrita completa” não tem base legal
  • Também afirmou que a “adição de um gerador de código” não concede novos direitos
• Pilgrim exigiu que o projeto fosse restaurado à licença LGPL original

Reação inicial da comunidade

• Um usuário perguntou se existia um fork de uma versão anterior à reescrita assistida por IA, e outro forneceu um link para a versão 6.0.0
• Alguns concordaram que “legalmente Mark está certo”, reconhecendo a possível violação da LGPL
• Outros comentaram, de forma mais prática, que uma “reescrita via IA é um trade-off inevitável”

Debate jurídico: API, direitos autorais e fair use

• Um usuário citou o caso Google LLC v. Oracle America, Inc. para afirmar que APIs também estão sujeitas à proteção autoral
  • Explicou que uma reescrita motivada por compatibilidade de API pode ser ilegal se não atender aos requisitos de fair use
• Em resposta, outro usuário rebateu dizendo que, no caso do Google, o uso foi considerado fair use
• A discussão então se expandiu para a legalidade de reescritas compatíveis com API e o status autoral de código gerado por IA

Geração de código por IA e a controvérsia sobre implementação clean room

• Alguns apontaram que, se houver a possibilidade de a IA ter sido treinada com o código original, então uma implementação clean room não se sustenta
  • A questão de saber se o LLM aprendeu com o código do chardet pode se tornar o ponto central da análise jurídica
• Outros argumentaram que “talvez fosse possível” se a IA tivesse gerado o código com base apenas em entradas e saídas
  • Em resposta, surgiu a objeção de que, nesse caso, “a própria licença perderia o sentido”
• A falta de clareza sobre a responsabilidade autoral do código de IA e a dificuldade de verificar conformidade com licenças emergiram como temas centrais

Compatibilidade de licenças e debate sobre GPL

• Alguns afirmaram que a licença MIT não é compatível com a GPL, mas outro usuário citou a documentação oficial da FSF para explicar que a MIT (Expat) é compatível com a GPL
• Ainda assim, houve amplo consenso de que relicenciar código LGPL como MIT continua sendo uma violação
• Outro usuário observou que “não dá para abandonar o acordo e, ao mesmo tempo, manter a reputação e o repositório construídos sobre código LGPL”

Dados de treinamento de IA e questão de confiança

• Vários usuários levantaram a dúvida: “é possível acreditar que o Claude não foi treinado com código LGPL?”
  • A falta de rastreabilidade dos dados de treinamento dos modelos de IA foi citada como risco jurídico
• Alguns defenderam que, se código de IA embute risco de plágio, o melhor seria evitar seu uso por completo
  • Com citação de pesquisa, foi mencionada uma estatística segundo a qual 2% a 5% do código de IA pode ser cópia de código existente

Identidade do projeto e limites da autoridade do mantenedor

• Alguns argumentaram que, “se todo o código de contribuidores anteriores foi removido”, então a nova versão poderia ser independente
  • Porém, houve a contestação de que continuar usando o mesmo nome e a mesma reputação seria inadequado
• Também apareceu a opinião de que “direitos autorais protegem a expressão, não o nome”
• Houve ainda quem dissesse que, se o mantenedor realmente removeu todo o código anterior, talvez não houvesse violação legal — mas nenhuma prova clara foi apresentada

Visão geral da comunidade

• Vários usuários afirmaram respeitar as contribuições tanto de Mark Pilgrim quanto de Dan Blanchard, e destacaram a necessidade de reconhecer a complexidade dos temas IA, direitos autorais e governança open source
• A discussão se ampliou para tópicos como a responsabilidade jurídica pelo código gerado por IA, a legitimidade de mudanças de licença em projetos e os limites da autoridade de mantenedores de open source
• Alguns chegaram a propor: “vamos fazer um fork da v7.0.0 e restaurá-la para LGPL”

Resumo dos pontos centrais

• Legalidade da mudança de LGPL → MIT: opinião majoritária de que isso não é possível sem o consentimento do autor original
• Status autoral da reescrita por IA: pode ser considerada derivada dependendo da exposição aos dados de treinamento
• Se houve implementação clean room: seria necessário provar que a IA não consultou o código original
• Uso do nome e da reputação do projeto: redistribuir com o mesmo nome gera controvérsia jurídica e ética
• Confiabilidade do código de IA: preocupações com risco de plágio e estabilidade da cadeia de suprimentos

Este caso vem sendo tratado como um exemplo representativo do debate sobre direitos autorais de código gerado por IA e conformidade com licenças open source, podendo influenciar no futuro a estrutura de responsabilidade jurídica de ferramentas de desenvolvimento com IA.

[GN⁺]

Comentários no Hacker News

• Acho que Pilgrim está entendendo errado o conceito de copyright (clean room)
  A alegação de “reescrita completa” não é o ponto importante. Legalmente, uma implementação independente é possível.
  Clean room é apenas um mecanismo processual para simplificar litígios; não é uma exigência legal que a pessoa nunca tenha sido exposta ao código original.
  Na prática, o Linux também conhecia a estrutura interna do Unix, mas foi implementado de forma independente

  • Independentemente da interpretação jurídica, preocupa a ideia de que, se a IA puder reescrever automaticamente código GPL e contornar a licença, isso significaria perder uma arma da comunidade open source
  • Também está errada a afirmação de que um teste de similaridade estrutural pode determinar se algo é obra derivada. E também é incorreto concluir que é obra derivada só porque usaram Claude. O critério jurídico real continua sendo uma área pouco clara
  • É preciso pensar em três casos.
    1. Se o código for parecido, é preciso provar a reimplementação em clean room
    2. Se for completamente diferente, tanto faz se houve clean room ou não
    3. Na maioria dos casos, há mistura de partes semelhantes e não semelhantes, então é preciso analisar cada parte separadamente. Se qualquer trecho tiver sido copiado, esse trecho precisa ser reescrito
  • A funcionalidade do chardet (detecção de codificação Unicode) é essencialmente fixa. Portanto, é natural que uma nova implementação passe nos mesmos testes.
    A baixa similaridade no JPlag parece ser uma evidência convincente de que não houve plágio
  • Surpreende pensar que código reescrito gerado por IA seria protegido por copyright

• A afirmação de que “se você conhece a base de código, qualquer reescrita também viola copyright” não é totalmente válida
  Conhecimento interno é questão de patente, não de copyright.
  Porém, se alguém deixa o código original ao lado e só troca as frases, isso é infração.
  Se a IA olhar o código original e gerar algo parecido, isso provavelmente será tratado na prática como cópia paralela.
  Mas, se for escrito totalmente do zero sem ver o original, isso é possível. Ainda assim, como é difícil se defender juridicamente, do ponto de vista empresarial isso deve ser tratado como um risco

  • É preciso deixar clara a diferença entre patente e copyright.
    Patente pode ser infringida independentemente de invenção independente, mas em copyright o essencial é a independência criativa.
    Ainda assim, se você produzir o mesmo resultado de uma obra que já viu antes, será difícil convencer um júri
    No fim, se houver similaridade, é bem provável que se conclua pela infração com base no critério de preponderância das evidências
  • Se você ler The Godfather, de Mario Puzo, e escrever um romance com a mesma estrutura, isso será considerado obra derivada.
    Por outro lado, se você nunca conheceu a obra original, será reconhecido como criação independente
  • Se existe um arquivo Claude.md, é bem provável que o novo mantenedor tenha usado o Claude como gerador de código, e esse modelo provavelmente foi treinado com o código original do chardet
  • Surge a pergunta: “quanto precisa mudar para ser reconhecido como código novo?”
  • Reescrita é parecida com tradução. Tradução também viola copyright.
    A ideia em si não é protegida, mas a expressão é.
    Se o LLM viu o código original durante o treinamento, isso cai numa zona cinzenta jurídica

• O ponto central é se houve violação da LGPL.
  Se o novo código foi baseado no original, ele é considerado obra derivada e deve manter a LGPL.
  Mesmo alegando “reescrita completa”, se houve exposição ao código original, isso pode configurar violação de licença

  • Ter sido exposto não torna algo automaticamente uma obra derivada.
    Clean room é apenas um procedimento de defesa em litígio, e o ônus da prova é do autor da ação.
    Linux e ferramentas GNU também conheciam o Unix, mas eram legais
  • Se o Claude foi treinado com o código original, essa interpretação leva à conclusão interessante de que a IA só poderia gerar derivados sob LGPL
  • Copyright é o ponto principal. Se o novo código for derivado do original, deve seguir a LGPL; se não for, o novo detentor do copyright pode definir livremente a licença
  • Se só mantiverem o mesmo nome e aumentarem a versão, isso pode acabar parecendo, na prática, o mesmo projeto

• Vi um caso interessante durante consultoria.
  Um engenheiro de uma empresa SaaS usou Claude Code para fazer engenharia reversa do próprio app e criar, em uma semana, um backend compatível com a API.
  Perguntaram: “como nos protegemos se um concorrente fizer isso?”

  • Isso é simplesmente avanço tecnológico.
    Se o código em si é o centro do negócio, ele já está em risco.
    Em vez de se preocupar com concorrência, o importante é fazer um produto melhor
  • Como no caso do StrongDM Factory, já está se tornando real copiar serviços externos para uso em testes.
    Já vivemos numa era em que dizer “vamos reimplementar Slack ou Drive” não soa irrealista
  • Se a IA reimplementou o backend vendo apenas o frontend, isso é legal.
    A API é uma interface pública, então não é protegida
  • Patente não pode ser registrada retroativamente, e copyright não protege ideias.
    Como nos casos de engenharia reversa do BIOS da IBM e do DOS, implementação independente é legal

• O mantenedor é um trustee, não o proprietário.
  Ele não deve mudar arbitrariamente a licença definida pelo autor original.
  Se o código foi feito inteiramente do zero, então deveria iniciar um projeto com outro nome.
  Dizer algo como “congelem a versão existente” vai contra o espírito da comunidade

• Já em um comentário de 2021 foi mencionado que “chardet é baseado em LGPL, então não pode ser relicenciado”.
  Se reescreveram mesmo sabendo disso, foi uma decisão imprudente e uma falta de respeito com o autor original

  • Por outro lado, também há a opinião de que foi a escolha certa para maximizar a utilidade do projeto

• Se a IA escreveu o código depois de ver o original, isso não é uma implementação clean room.
  E se houvesse duas equipes de IA, uma criando a especificação e a outra implementando? Isso seria aceitável?
  Segue o precedente da era IBM, mas, se o modelo já foi treinado no original, ainda há problema

  • Se o chardet estiver nos dados de treinamento, então clean room é impossível em qualquer estrutura
  • Se for extraída uma especificação e outro modelo escrever o código a partir dela, em teoria um clean room seria possível.
    Mas seria preciso verificar se a especificação não contém elementos expressivos
  • Se o original estiver nos dados de treinamento, a possibilidade de infração continua alta
  • Também houve a alegação de que a estrutura da API faz parte do copyright, mas isso foi corrigido
  • O caso IBM/Compaq só é parecido na superfície.
    Quando o original está incluído nos dados de treinamento, a comparação em si perde o sentido

• Como na piada “se eu copiar e colar da Wikipédia e trocar só algumas palavras, tudo bem?”,
  no fim das contas não dá para evitar de propósito.
  Vivemos uma época em que é difícil confiar, a ponto de ser preciso fixar versões de dependências

  • Engenheiros muitas vezes entendem a lei como se fosse uma regra técnica.
    Mas o direito valoriza uma avaliação do conjunto.
    Os tribunais julgam com base na “preponderância das evidências”, e simplesmente trocar palavras não transforma uma obra em outra.
    Se o original foi essencial, é bem provável que se conclua que se trata de obra derivada.
    Se o original estiver nos dados de treinamento, prevê-se que um processo por violação de copyright será inevitável

• Por outro lado, é curioso ver Mark Pilgrim aparecer de novo
  A página dele na Wikipédia menciona o episódio em que ele “desapareceu” da internet.
  Os livros dele sobre Python ainda valem a recomendação

  • Em breve a conta do GitHub “a2mark” talvez até apareça na Wikipédia

• Há também surpresa com a ideia de que “se a IA foi treinada com código GPL, então todo código de IA não estaria contaminado por GPL (taint)?”

  • Há projetos como ReactOS que exigem clean room completo, mas isso é apenas uma proteção jurídica, não uma exigência obrigatória
  • Para provar a “contaminação”, seria preciso demonstrar de fato a derivação.
    O procedimento de clean room nos EUA é apenas uma estratégia para encurtar litígios
  • Como o sistema de copyright foi originalmente um instrumento de proteção do capital, alguns acham improvável que isso seja aplicado de forma tão rígida na prática
  • Já havia gente alertando sobre esse problema desde o início da onda dos LLMs