Open source e desenvolvimento assistido por IA: como lidar com as questões legais

No post anterior desta série, falamos sobre como a inteligência artificial está começando a mudar a forma como o software é desenvolvido. Neste novo post, vamos nos concentrar em algumas das principais questões legais (ou quase legais) que os próprios desenvolvedores de open source levantam em relação ao desenvolvimento assistido por IA.

Esta não é uma visão geral abrangente sobre todas as questões legais relacionadas à IA. Não estamos abordando, por exemplo, as preocupações dos clientes sobre conformidade com regulamentos de IA ou questões de responsabilidade relacionadas a contratos de produtos com tecnologia de IA. Em vez disso, estamos nos concentrando em questões que estão sendo ativamente debatidas nas comunidades open source. 

Nossas opiniões sobre essas questões refletem nosso compromisso com o uso responsável das tecnologias de IA e nossa filosofia de "abertura padrão". Acreditamos que abordagens colaborativas e transparentes são as melhores maneiras de abordar essas preocupações de maneira construtiva.

Atribuição e marcação 

A atribuição é uma norma legal e cultural fundamental no open source. As licenças geralmente exigem que você preserve os avisos de direitos autorais e de autoria e evite reivindicações enganosas de autoria. 

O desenvolvimento assistido por IA complica isso. Como os sistemas de IA não são considerados "autores" de acordo com a lei de direitos autorais, não há ninguém a quem dar o crédito pela autoria. No entanto, seria incoerente para um desenvolvedor apresentar resultados substanciais gerados por IA como seu próprio trabalho individual.

É por isso que um número crescente de projetos open source está adotando regras de divulgação para contribuições assistidas por IA, inspirando-se em normas de divulgação em outros campos, como a rotulagem de mídias sintéticas. "Marcar" as contribuições ajuda a preservar a clareza jurídica e a confiança da comunidade, além de facilitar a avaliação do código pelos revisores.

Apoiamos a marcação, mas não achamos que ela deva ser excessivamente prescritiva. Usos relativamente triviais da IA, como o preenchimento automático de um nome de variável ou a sugestão de uma docstring, não precisam ser divulgados. Para usos mais substanciais, a marcação pode ser tão simples quanto um comentário no código-fonte, uma observação em uma solicitação de mesclagem ou um trailer de commit, como Assisted-by: (outros candidatos usados por alguns projetos incluem Generated-by: e Co-authored by : ).  

Formalidades de licenciamento e direitos autorais

Por mais importante que a atribuição possa ser, o open source depende ainda mais de concessões de licença claras. Isso levanta uma questão prática: como os avisos de licença funcionam quando uma contribuição inclui material gerado por IA não protegido por direitos autorais?

Na maioria dos casos, onde os avisos de licença já existem em um repositório ou arquivo de origem individual, nada deve ser alterado. Devido à natureza altamente funcional do código, os arquivos-fonte já são geralmente uma mistura de material protegido por direitos autorais e não protegido por direitos autorais, e as concessões de licença open source se aplicam somente às partes protegidas por direitos autorais. Para contribuições substanciais geradas por IA, a divulgação por meio de marcação complementa os avisos de licença existentes, sendo a maneira certa de evitar enganos.

O caso mais difícil é quando um arquivo-fonte inteiro, ou até mesmo um repositório inteiro, é gerado pela IA. Neste caso, um aviso de direitos autorais e licença pode ser inadequado, a menos que a contribuição humana transforme o arquivo em um trabalho protegido por direitos autorais. Mas, dada a norma de que os repositórios open source devem ter um arquivo de LICENÇA global, é justo adicionar uma licença open source ultrapermissiva (por exemplo, a Unlicense) como a licença global de um repositório gerado por IA, embora tecnicamente tais licenças presumam que existam direitos autorais. À medida que as contribuições humanas são adicionadas, os mantenedores podem revisitar essa opção de licença inicial; devido à falta de colaboradores humanos anteriores, isso será mais fácil do que o cenário típico em que um projeto open source é relicenciado. Esperamos que as práticas evoluam com as mudanças na lei e com o aumento da experiência da comunidade com as ferramentas de IA.

As ferramentas de IA são "máquinas de plágio"? 

Alguns desenvolvedores open source são céticos, e às vezes até hostis, em relação ao desenvolvimento assistido por IA, acusando os modelos de IA de serem "máquinas de plágio" ou mecanismos de "lavagem de direitos autorais". 

Há duas versões dessa preocupação. A primeira é prática: uma ferramenta de IA pode inserir secretamente trechos de código proprietário (ou incompatível com a licença) em um projeto open source, potencialmente criando riscos legais para mantenedores e usuários. O segundo é mais amplo e filosófico: grandes modelos de linguagem, treinados em grandes quantidades de software open source, estão essencialmente se apropriando indevidamente do trabalho da comunidade, produzindo resultados que não cumprem as obrigações exigidas pelas licenças open source.

Acreditamos que essas preocupações devem ser levadas a sério. É verdade que grandes modelos de linguagem são capazes, em alguns casos, de emitir trechos não triviais de seus dados de treinamento. Se esse fosse um comportamento frequente ou inevitável, seria um bom motivo para evitar o uso dessas ferramentas. 

Mas as evidências sugerem o contrário. Quando o GitHub Copilot foi lançado, houve alegações amplamente divulgadas de que suas sugestões foram copiadas de projetos open source. Quando essas alegações eram fundamentadas, elas geralmente envolviam esforços deliberados para persuadir a ferramenta a reproduzir o código conhecido na íntegra, o que não é um uso comum. Desde então, não vimos evidências confiáveis de que as ferramentas de desenvolvimento de IA amplamente usadas replicam sistematicamente partes dos dados de treinamento que sejam substanciais o suficiente para levantar questões de direitos autorais.

O equívoco subjacente a grande parte da narrativa da "máquina de plágio" é que os modelos de IA generativa são um tipo de compactação com perdas de seus dados de treinamento. Na realidade, o comportamento normal dos modelos é gerar novos textos com base nos padrões estatísticos que aprenderam. O fato de que eles são treinados em código open source não significa que sua saída seja uma reprodução desse código. 

Dito isso, a possibilidade de replicação ocasional não pode ser ignorada. Os desenvolvedores que usam ferramentas de IA devem ficar atentos a esse risco e tratar as informações geradas pela IA como algo a ser revisado com o mesmo cuidado que qualquer outra contribuição. Quando as ferramentas de desenvolvimento de IA oferecem funcionalidades para detectar ou sinalizar sugestões longas que correspondam ao código open source existente, essas funcionalidades devem ser habilitadas. Combinadas a práticas de divulgação e supervisão humana, essas etapas são uma maneira prática de reduzir a preocupação com a replicação sem tratar todo o uso de IA como inerentemente corrompido. 

Contribuições assistidas por IA e o DCO

Os projetos que usam o Developer Certificate of Origin (DCO) têm gerado preocupações específicas sobre as contribuições assistidas por IA. O DCO, que há muito tempo consideramos uma boa prática no desenvolvimento open source, exige que os colaboradores confirmem ter o direito de enviar seu trabalho conforme a licença do projeto. Alguns desenvolvedores argumentam que, como os resultados das ferramentas de IA podem incluir material desconhecido ou não divulgado, ninguém pode legitimamente fazer a aprovação do DCO para código assistido por IA. Essa visão levou alguns projetos que usam DCO a proibir completamente as contribuições por IA. 

Entendemos essa preocupação, mas o DCO nunca foi interpretado como exigindo que cada linha de uma contribuição seja a expressão criativa pessoal do colaborador ou de outro desenvolvedor humano. Muitas contribuições contêm material rotineiro e não protegido por direitos autorais, e os desenvolvedores ainda as assinam. O verdadeiro objetivo do DCO é a responsabilidade. O colaborador acredita ter o direito de usar a contribuição em um trabalho que é regido (como seus elementos protegidos por direitos autorais) por uma licença open source específica. Os mantenedores de projetos têm a expectativa razoável de que o colaborador fez a devida diligência para fazer a certificação. Com a divulgação, a atenção humana e a supervisão, auxiliadas sempre que possível por ferramentas que verificam a similaridade do código, as contribuições assistidas por IA podem ser totalmente compatíveis com o espírito do DCO.

Nada disso quer dizer que os projetos devam permitir contribuições assistidas por IA. Cada projeto tem o direito de fazer suas próprias regras e definir seu próprio nível de conforto e, se um projeto decidir proibir as contribuições assistidas por IA por enquanto, essa decisão deve ser respeitada. Os projetos que optarem por esse caminho devem reconhecer que as preocupações que estão expressando não são novas ou exclusivas da IA. Durante anos, os usuários comerciais de open source, avessos ao risco, se preocuparam com o código "lavado": contribuições que ocultavam material protegido por direitos autorais em termos não revelados e problemáticos. Com o tempo, esses temores se mostraram infundados. Não é impossível que uma contribuição assistida por IA contenha material protegido por direitos autorais não divulgado, mas a experiência sugere que é um evento de risco gerenciável e não é categoricamente diferente dos desafios que o open source enfrentou e superou no passado. 

Em outras palavras, o DCO pode continuar sendo o que sempre foi: uma ferramenta prática e eficaz para manter a confiança e a clareza jurídica no desenvolvimento open source, mesmo na era da IA.

Estabelecendo a confiança

Subjacente a grande parte da discussão sobre a IA no desenvolvimento de software, seja ela legal, técnica ou ética, está a questão da confiança. A confiança é uma preocupação humana fundamental e essencial para qualquer projeto open source bem-sucedido. A introdução da IA no desenvolvimento open source gera novos problemas de confiança em várias dimensões: a confiança de que os colaboradores estão usando a IA de maneira responsável, de que aqueles que fazem isso não são estigmatizados e de que as empresas que criam e incentivam o uso da IA estão fazendo isso de maneiras que servem ao bem público. Reconhecer que essas empresas, incluindo a Red Hat, têm interesse comercial no sucesso da IA também é parte essencial da transparência sobre seu papel nessa transformação tecnológica.

O desafio de criar confiança na tecnologia não é novo. A palestra seminal de Ken Thompson em 1984, "Reflexões sobre a confiança ", continua sendo uma referência para entender como o julgamento humano e a integridade institucional sustentam o software em si. A IA traz esses conceitos de volta à tona. A confiança ainda precisa ser conquistada por meio de ações consistentes e visíveis. A Red Hat valoriza a confiança que construímos com as comunidades upstream e acreditamos que nosso modelo de desenvolvimento open source, baseado em transparência, colaboração e responsabilidade, continua sendo a melhor maneira de mantê-la à medida que navegamos juntos no futuro da IA e do open source.

De olho no futuro

Os problemas que discutimos aqui (marcação, avisos de licença, preocupações com a replicação de dados de treinamento e o DCO) são os tipos de questões legais que os desenvolvedores open source mais enfrentam atualmente. Com a divulgação do uso da IA, a supervisão humana e o respeito pelas regras do projeto, o desenvolvimento assistido por IA pode ser reconciliado com os fundamentos legais e os valores culturais do open source. Agradecemos a colaboração em projetos upstream nessas e em outras abordagens que equilibrem esses interesses. Cada projeto deve ser livre para fazer suas próprias escolhas. As comunidades open source serão mais fortes se elas mesmas resolverem esses problemas, em vez de ficarem de fora.