💻 computer science

Detecting and Fixing Violations of Modification Terms in Open Source Licenses during Forking

Este artigo apresenta o LiVo, uma ferramenta projetada para detectar e corrigir automaticamente violações de termos de modificação em licenças de código aberto durante o processo de fork, abordando uma lacuna anteriormente inexplorada na mitigação de riscos jurídicos por meio da caracterização empírica de 47 licenças e validação bem-sucedida via pull requests mesclados.

Autores originais: Kaifeng Huang, Yingfeng Xia, Bihuan Chen, Zhuotong Zhou, Jin Guo, Xin Peng

Publicado 2026-06-23

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Kaifeng Huang, Yingfeng Xia, Bihuan Chen, Zhuotong Zhou, Jin Guo, Xin Peng

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine o mundo do software de código aberto como uma biblioteca enorme e movimentada, onde qualquer pessoa pode pegar livros emprestados, lê-los e até reescrever capítulos para criar suas próprias novas histórias. Isso é ótimo para a criatividade, mas há um detalhe: quase todos os livros nesta biblioteca vêm com um conjunto específico de regras (uma licença) escritas pelo autor original.

A maioria das pessoas conhece as grandes regras, como "Você deve dar o crédito" ou "Você deve compartilhar sua nova versão gratuitamente". Mas há uma regra sorrateira, frequentemente negligenciada, escondida em muitas dessas licenças chamada Termo de Modificação.

A Regra do "Registro de Alterações"

Pense no Termo de Modificação como uma regra estrita de um bibliotecário: "Se você pegar um livro da nossa biblioteca, mudar algumas páginas e criar uma nova versão, deve escrever um post-it explicando exatamente o que você mudou, quem mudou e quando."

Algumas licenças dizem que o post-it deve ir em cada página que você tocou. Outras dizem que você pode colocá-lo em um caderno de "Alterações" separado na frente do livro. Outras apenas dizem: "Certifique-se de que alguém saiba que você mudou isso."

O problema? A maioria dos desenvolvedores está tão ocupada escrevendo código que esquece de escrever esses post-its. Eles criam um "fork" (uma cópia do projeto que eles modificaram), mas falham em deixar um rastro do que fizeram. Isso é uma violação legal, como devolver um livro da biblioteca com páginas rasgadas, mas sem um bilhete explicando o porquê.

O Problema: A Violação "Silenciosa"

Os pesquisadores da Universidade de Fudan perceberam que, embora tenhamos ferramentas para verificar se você está usando o livro certo, não temos ferramentas para verificar se você esqueceu de escrever seu post-it. Eles perguntaram:

O que exatamente essas regras dizem?
Com que frequência as pessoas estão quebrando essas regras?
Podemos construir um robô para consertar isso?

A Solução: Conheça o "LiVo" (O Vigilante da Biblioteca)

Para resolver isso, a equipe construiu uma ferramenta chamada LiVo. Você pode pensar no LiVo como um bibliotecário super inteligente e automatizado que patrulha as bibliotecas "forkadas".

Veja como o LiVo funciona, passo a passo:

O Trabalho de Detetive (Encontrando as Mudanças): O LiVo olha para o livro original da biblioteca e para a nova versão modificada. Ele varre cada "commit" (uma alteração salva no código) para ver quais arquivos foram realmente tocados. Ele filtra as coisas chatas, como quando alguém apenas copiou uma página do original sem alterá-la.
A Busca (Procurando pelo Post-it): Uma vez que o LiVo sabe quais arquivos foram alterados, ele sai em busca do "post-it". Ele procura em dois lugares:
- Dentro dos próprios arquivos modificados.
- Em um arquivo de "Registro de Alterações" separado (como um CHANGELOG.md), que é comum em projetos de software.
O Confronto (Eles acertaram?): O LiVo compara a "mensagem de commit" (o que o desenvolvedor disse que fez ao salvar a alteração) com o "registro de alterações" (o post-it).
- Eles mencionaram a alteração?
- Incluíram a data?
- Incluíram o nome deles?
  Se a resposta for "Não" para qualquer um desses pontos, o LiVo sinaliza como uma violação.
O Conserto (O Piloto Automático): Se o LiVo encontrar um post-it faltando, ele não apenas grita; ele tenta consertar. Ele escreve automaticamente o post-it faltante com base na mensagem de commit original do desenvolvedor e sugere adicioná-lo ao projeto.

O Que Eles Descobriram (O Choque de Realidade)

A equipe testou o LiVo em 178 pares de projetos de software do mundo real (um projeto base e seu fork). Os resultados foram reveladores:

É um Erro Comum: Cerca de 51% dos projetos modificados estavam quebrando essas regras. Eles haviam alterado o código, mas esqueceram de escrever as notas exigidas.
A Escala: Eles encontraram mais de 51.000 instâncias específicas onde os desenvolvedores esqueceram de documentar suas alterações.
O Código-Fonte é o Culpado: A maioria das notas ausentes era para alterações feitas no próprio "código-fonte" (as instruções que executam o programa), em vez de documentação ou scripts.

Funcionou?

O LiVo não é apenas uma teoria; eles o colocaram à prova no mundo real.

Eles enviaram 91 "Pull Requests" (sugestões oficiais para corrigir o código) para os proprietários dos projetos.
18 desenvolvedores responderam positivamente, dizendo: "Ah, você tem razão! Nós esquecemos disso."
8 desses consertos foram de fato integrados ao código principal, o que significa que o risco legal foi oficialmente resolvido.

A Conclusão

Este artigo é o primeiro a dizer: "Ei, precisamos parar de ignorar a regra sobre escrever notas quando alteramos o código de código aberto." Eles mapearam exatamente como essas regras se parecem em 47 licenças diferentes e construíram uma ferramenta, o LiVo, que atua como um bibliotecário prestativo, encontrando os post-its faltantes e escrevendo-os para você.

Não se trata de impedir as pessoas de alterar o código; trata-se de garantir que a "trilha de papel" exista para que todos saibam quem mudou o quê, mantendo a biblioteca legal segura e organizada.

Resumo Técnico: Detecção e Correção de Violações de Termos de Modificação em Licenças de Código Aberto durante o Forking

Definição do Problema
O desenvolvimento de software de código aberto (OSS) depende fortemente do forking, onde desenvolvedores copiam um repositório base para criar uma nova versão modificada de forma independente. Embora isso fomente a inovação, introduz riscos jurídicos significativos quando os desenvolvedores falham em cumprir as obrigações da licença. Pesquisas existentes focaram na identificação de licenças, detecção de incompatibilidades entre dependências e busca por inconsistências no licenciamento de arquivos. No entanto, uma lacuna crítica permanece em relação aos Termos de Modificação (MTs). Os MTs são cláusulas específicas em licenças de OSS que ditam as condições sob as quais os usuários podem modificar o trabalho original e as obrigações que devem cumprir ao fazê-lo. Um exemplo proeminente é o requisito em licenças como a Apache-2.0 de incluir "avisos proeminentes" declarando que os arquivos foram alterados. Tanto quanto os autores sabem, nenhum trabalho anterior caracterizou sistematicamente esses termos ou forneceu mecanismos automatizados para detectar e corrigir violações de MTs durante o processo de forking.

Metodologia
Os autores propõem uma abordagem de duas fases: um estudo empírico para caracterizar os MTs, seguido pelo desenvolvimento de uma ferramenta automatizada chamada LiVo.

1. Caracterização Empírica de Termos de Modificação
Os autores conduziram um estudo empírico em 107 licenças aprovadas pela Open Source Initiative (OSI). Eles identificaram 47 licenças que declaram explicitamente MTs exigindo formas específicas de "aviso" para descrever modificações. Para modelar essas obrigações, os autores analisaram as licenças através de três dimensões:

Escopo de Modificação ( $S_g$ ): Os tipos de arquivos sujeitos a obrigações de modificação (ex: código-fonte, documentação, arquivos de configuração, scripts). Eles os categorizaram em oito grupos, observando que quase metade das licenças (44,7%) se aplica a qualquer tipo de arquivo.
Conteúdo do Aviso ( $C_g$ ): As informações exigidas no aviso. Isso foi categorizado em quatro elementos: Data, Autor, Declaração Breve (declarando que os arquivos foram alterados) e Declaração Informativa (detalhando como/por que). As licenças foram agrupadas em seis categorias com base nesses requisitos.
Localização do Aviso ( $L_g$ ): Onde o aviso deve ser colocado. Isso foi categorizado em dois elementos: um documento separado (ex: CHANGELOG) ou cada arquivo modificado. As licenças foram agrupadas em quatro categorias.

Com base nessas dimensões, as 47 licenças foram modeladas como 2-tuplas $\langle lic, O \rangle$ , onde $O$ é uma 3-tupla $\langle S_g, C_g, L_g \rangle$ representando a obrigação específica.

2. A Abordagem LiVo
O LiVo é uma ferramenta automatizada projetada para detectar e corrigir violações de MT durante o forking. Ele recebe um repositório base e um repositório fork como entrada e opera em três etapas:

Etapa 1: Detecção de Modificação Obrigatória
- Mapeamento de Arquivos: O LiVo estabelece mapeamentos entre os arquivos nos repositórios base e fork para identificar o reuso. Ele lida com cenários onde arquivos são renomeados, movidos ou copiados (usando ferramentas como JGit e Saga).
- Detecção de Licença: Ele utiliza o Ninka para detectar a licença de cada arquivo no repositório base.
- Arquivos e Commits Obrigatórios: Ele identifica "arquivos obrigatórios" (aqueles que caem dentro do escopo de modificação da licença detectada) e "commits obrigatórios" no repositório fork que modificam esses arquivos. Ele filtra commits selecionados (picked) do repositório base (que já estão em conformidade) e commits revertidos.
Etapa 2: Extração de Aviso
- O LiVo localiza potenciais arquivos de aviso no repositório fork (ex: CHANGELOG, RELEASE.txt).
- Ele extrai "logs de mudanças" desses arquivos. A lógica de extração lida com texto semiestruturado, identificando blocos de mudanças associados a intervalos de datas específicos e autores.
- Cada log de mudança extraído é modelado como uma tupla $\langle msg, d_s, d_e, a \rangle$ (mensagem, data de início, data de fim, autor).
Etapa 3: Detecção e Correção de Violações
- Correspondência: Para cada commit obrigatório, o LiVo tenta corresponder com um log de mudança no conjunto extraído.
- Verificação de Similaridade: Ele utiliza TF-IDF para medir a similaridade semântica entre a mensagem do commit e a mensagem do log de mudança. Se a similaridade exceder um limite (definido empiricamente como 0,3), o requisito de conteúdo é considerado atendido.
- Verificação de Atributos: Ele verifica se a data do commit cai dentro do intervalo de datas do log de mudança e se o autor do commit corresponde ao autor do log de mudança.
- Classificação: Os commits são classificados como:
  - OB (Totalmente Obligado): Todos os requisitos atendidos.
  - VN (Violado - Falta de Aviso): Nenhum log de mudança correspondente encontrado.
  - VD (Violado - Falta de Data): Incompatibilidade de intervalo de datas.
  - VA (Violado - Falta de Autor): Incompatibilidade de autor.
- Correção: Para violações, o LiVo gera uma correção criando ou atualizando uma entrada no log de mudanças com a mensagem, data e autor corretos, e escrevendo-os no arquivo de aviso apropriado.

Principais Resultados
Os autores avaliaram o LiVo usando 178 pares de repositórios base e fork (selecionados de projetos do GitHub com alto número de estrelas).

Prevalência: 21,9% dos repositórios fork analisados exigiam MTs em suas licenças.
Gravidade da Violação: 51,1% dos repositórios fork violavam os MTs. Mais criticamente, 95,3% dos commits obrigatórios (commits que modificam arquivos protegidos) foram encontrados violando os MTs. A violação mais comum foi a falta de aviso (VN), seguida pela falta de data (VD).
Precisão: O LiVo alcançou uma precisão macro de 0,82 e um recall macro de 0,80 na detecção e classificação de violações. A principal fonte de erro foi a falta de consciência semântica do TF-IDF ao combinar mensagens curtas de commit com logs de mudança.
Eficiência: A ferramenta levou em média 229,8 segundos por par de repositórios, com a etapa de detecção de modificação representando ~92% do tempo de execução.
Impacto no Mundo Real: Os autores enviaram 91 pull requests para os repositórios violados. 18 receberam respostas positivas e 8 foram mesclados (merged) nas ramificações principais. Alguns desenvolvedores inicialmente resistiram, alegando que o próprio histórico de commits constituía o aviso ou alegando que eram os autores originais, mas a ferramenta identificou e propôs correções com sucesso para a maioria dos casos.

Significância e Alegações
O artigo afirma ser o primeiro trabalho a:

Caracterizar empiricamente os termos de modificação em um grande conjunto de licenças de código aberto.
Propor uma abordagem automatizada (LiVo) para detectar e corrigir violações desses termos específicos durante o forking.

Os autores enfatizam que, embora a identificação de licenças e a detecção de incompatibilidade sejam campos maduros, a obrigação específica de fornecer um "aviso" para modificações foi negligenciada. Ao abordar isso, o LiVo ajuda a mitigar riscos jurídicos, como processos judiciais e perdas financeiras associadas à não conformidade. O artigo conclui que as violações de MT são severas em cenários do mundo real e que a detecção e correção automatizadas são viáveis e eficazes, embora melhorias na correspondência semântica (ex: usando aprendizado profundo) sejam necessárias para reduzir ainda mais falsos positivos e negativos.