O Código Gerado por IA Tornou as Suas Garantias de Direitos de Autor Impossíveis de Assinar, e os Contratos Ainda Não Deram Por Isso
O Developer Certificate of Origin, o acordo de contribuidores da Apache e todas as garantias de propriedade intelectual que assentam sobre eles presumem que a autoria do código é cognoscível e demonstrável. O código gerado por IA invalidou esse pressuposto, e a divisão do open source em torno dele é apenas o sintoma visível.
Todos os patches aceites no kernel Linux, e nos milhares de projetos que copiaram o seu processo, incluem uma linha Signed-off-by. Essa linha certifica a primeira cláusula do Developer Certificate of Origin: «A contribuição foi criada, no todo ou em parte, por mim e tenho o direito de a submeter ao abrigo da licença open source indicada no ficheiro.» O acordo individual de licenciamento de contribuidores da Apache faz a mesma promessa por outras palavras: «Declara que cada uma das suas Contribuições é uma criação original sua.» Estas frases foram redigidas quando o único autor possível era uma pessoa, e todos os documentos que assentam sobre elas na cadeia comercial (questionários de aquisições, garantias de propriedade intelectual a clientes, os anexos de divulgação de uma operação de fusão e aquisição) herdam o mesmo pressuposto central: que o estatuto de direitos de autor de um código é algo que o seu autor consegue conhecer e o seu titular consegue provar. O código gerado por IA invalidou silenciosamente esse pressuposto. As cláusulas continuam a ser assinadas todos os dias. Lidas à letra, muitas delas já não podem ser assinadas com verdade por ninguém.
Porque é que os direitos de autor do código gerado por IA deixaram de ser verificáveis?
Siga o mecanismo. Os sistemas que geram código foram treinados sobre repositórios públicos sob todas as licenças e estatutos de direitos de autor imagináveis, e nada no seu resultado regista de onde deriva uma determinada sugestão; não existe um registo a consultar. O programador que aceitou a sugestão não consegue provar a licença do que recebeu, e o fornecedor da ferramenta que a produziu também não. Isto não é um problema de verificação que uma ferramenta melhor resolva no próximo ano: a informação nunca chegou a ser captada, logo não pode ser recuperada. Todas as cláusulas construídas sobre uma autoria demonstrável, desde a assinatura de um contribuidor até à garantia de propriedade intelectual num contrato de compra e venda de participações sociais, assentam agora num facto que já não é cognoscível.
As consequências comerciais chegam muito antes de qualquer tribunal. Os questionários de due diligence em processos de aquisições e compras perguntam agora diretamente pela proveniência do código. Clientes em setores regulados exigem declarações de que o código entregue está livre de contaminação de licenças. As condições de garantia e indemnização são calculadas com base no que pode ser demonstrado. Em todos os casos, os documentos foram redigidos para um mundo em que uma auditoria competente conseguia, pelo menos em princípio, seguir cada linha até a um autor e a uma licença. A auditoria ainda pode ser encomendada; já não pode responder à pergunta.
O open source já se dividiu perante o fosso de prova
A prova mais clara de como os engenheiros levam este problema a sério está na governação dos projetos open source. O conselho do Gentoo proibiu contribuições geradas por IA em 2024, citando os direitos de autor entre as razões. As diretrizes de commits do NetBSD presumem que o código gerado por IA está contaminado e bloqueiam-no sem aprovação da equipa central. O QEMU recusa-o pela razão exata com que este artigo começou: os contribuidores não conseguem certificar honestamente a sua origem ao abrigo da assinatura que cada patch exige. Repare na forma que qualquer política mais branda é obrigada a assumir. Uma regra que só admite código gerado por IA quando o contribuidor consegue verificar o seu estatuto de direitos de autor parece um compromisso, mas como essa verificação não existe, é uma proibição total disfarçada de autorização. Estes são projetos geridos pela comunidade cujo único ativo insubstituível é uma cadeia de titularidade defensável, e estão dispostos a prescindir de contribuições para a preservar.
A outra metade do ecossistema corre exatamente na direção oposta, com a folha de pagamentos a apoiá-la. Na teleconferência de resultados do terceiro trimestre de 2024 da Alphabet, Sundar Pichai disse aos analistas que «mais de um quarto de todo o código novo na Google é gerado por IA e depois revisto e aceite por engenheiros», uma afirmação amplamente noticiada na altura, e os maiores apoiantes empresariais da Linux Foundation vendem as ferramentas responsáveis por números como este. Nenhum dos dois campos, no entanto, consegue demonstrar o que o seu código realmente contém. Nenhum detetor de código escrito por máquina demonstrou a fiabilidade que uma auditoria de licenças exigiria, pelo que a aplicação das regras assenta na autodeclaração; o kernel Linux inclinou-se para a divulgação em vez da proibição, mas uma regra de divulgação só mede os contribuidores que optam por cumprir. Seja qual for a verdadeira percentagem de patches assistidos por IA, um sistema de honra pode reportar um mínimo, nunca uma medição. Os problemas de proveniência são também transitivos: um projeto rigoroso continua a importar dependências mantidas ao abrigo de políticas permissivas, e contribuidores empregados por empresas mantêm grandes áreas da infraestrutura que cada distribuição distribui. A política de IA de um projeto revela o seu apetite pelo risco. Não revela quase nada sobre o seu repositório.
Um SBOM consegue responder à pergunta que a sua garantia coloca?
A resposta reflexa é apontar para o software bill of materials. Não vai ajudar, e as próprias normas mostram-no na sua estrutura. Os campos definidos pelo SPDX e pelo CycloneDX descrevem componentes: nomes, versões, fornecedores, licenças declaradas, relações de dependência. Em nenhum dos dois formatos existe um campo que declare como o código de um componente chegou a existir, ou se foi uma pessoa a escrevê-lo. O SPDX 3.0 chegou a acrescentar um perfil de IA, mas este existe para descrever sistemas de IA entregues como produtos, não para registar a autoria de código-fonte comum. Um SBOM inventaria aquilo que corre; nunca foi concebido para provar de onde vem. Deixá-lo substituir uma garantia de proveniência é um erro de categoria, e quem faz due diligence já começou a reparar nisso.
O código gerado por IA é um risco de direitos de autor para a sua empresa?
A lei está por definir, e esperar que se defina não é uma estratégia, porque a exposição é contratual e reputacional muito antes de ser jurídica. A resposta útil é transformar a higiene de licenciamento de uma verificação pontual numa avaliação permanente, dependência a dependência. Conheça as políticas de IA dos projetos a montante de que a sua empresa realmente depende, e trate o silêncio como uma categoria de risco por si só. Faça rever a linguagem de garantia e indemnização à luz do que é hoje demonstrável e não do que costumava presumir-se; uma declaração de «criação original» sem reservas é uma promessa que os seus engenheiros não conseguem cumprir em seu nome. Tome a decisão sobre o apetite pelo risco de forma deliberada, ao nível em que a arquitetura é decidida: é exatamente o tipo de exposição que uma revisão séria de estratégia técnica deve identificar por defeito, e pertence à mesma conversa que a preparação para a IA antes de construir. Se as suas próprias equipas geram código com IA, aplica-se a mesma disciplina internamente, o que é mais um argumento para manter humanos no controlo do que a IA produz, em vez de tratar a ferramenta como autora.
Cada uma dessas políticas de projeto é, no fundo, uma escolha de apetite pelo risco, e a sua empresa enfrenta a mesma votação, uma dependência e uma assinatura de cada vez. As organizações que sairão bem desta fase não serão as que escolheram o campo «limpo». Serão as que repararam que não havia forma de verificar, e ajustaram o preço em conformidade.
Perguntas frequentes
O software consegue detetar se um código foi escrito por IA?
Não de forma fiável. Nenhum detetor de código gerado por máquina demonstrou a precisão que uma auditoria de licenças exigiria; os classificadores falham nos dois sentidos e edições triviais bastam para os enganar. É por isso que os projetos open source dependem da autodeclaração dos contribuidores em vez da deteção automática, e qualquer percentagem de IA divulgada deve ser lida como um mínimo, nunca como uma medição.
Os programadores ainda podem assinar o Developer Certificate of Origin se usarem ferramentas de IA?
Depende do projeto. As diretrizes do QEMU concluem que os contribuidores não conseguem certificar honestamente a origem de código gerado por IA e recusam esses patches, enquanto o kernel Linux tem privilegiado a divulgação identificada. Verifique a política de cada projeto antes de contribuir, porque uma assinatura é uma declaração jurídica sobre proveniência, não uma formalidade.
O que devemos perguntar aos fornecedores sobre a proveniência do código gerado por IA?
Pergunte pela sua política de desenvolvimento assistido por IA, como as contribuições de IA são identificadas e revistas, se as suas garantias de propriedade intelectual refletem o que é realmente demonstrável em vez do que costumava presumir-se, e quem assume a indemnização se a proveniência do código entregue for alguma vez contestada.
Relacionado
- Epic vs. Google: a cláusula do catálogo que entrega o fosso competitivo aos rivais
- Os preços da memória inverteram. Renegoceie o contrato de fornecimento antes da próxima renovação.
- Como a IA Deixa Chefes Ruins Ainda Piores: a Máquina de Bajulação na Sala da Diretoria
- Digital Business
Escrito por uma persona editorial de IA do sistema editorial proprietário da Abyshire e revisto pela nossa equipa.