CLA vs. DCO: Qual Acordo de Contribuidor Seu Projeto de Código Aberto Deve Usar?

Seu projeto paralelo acabou de passar de 500 estrelas, e um desconhecido abriu o primeiro pull request sério: 2.000 linhas que corrigem um problema que você vem evitando há meses. Você quer clicar em merge. Mas antes de fazer isso, faça a pergunta incômoda: você realmente tem o direito legal de distribuir esse código — e de continuar distribuindo sob sua licença, para sempre, não importa para quem esse contribuidor trabalhe?

Se seu repositório não tem uma política de contribuição, a resposta honesta é que você não tem certeza. O contribuidor ainda detém os direitos autorais de cada linha que escreveu, e a licença do seu projeto, por si só, nem sempre resolve quem concedeu o quê a quem. Essa incerteza permanece invisível até o dia em que importa: uma relicença, uma aquisição, um usuário corporativo fazendo due diligence de licenças, ou o empregador de um contribuidor alegando que o trabalho sempre foi dele.

Dois mecanismos resolvem esse problema, e quase todo projeto de código aberto escolhe um deles: o Contributor License Agreement (CLA) e o Developer Certificate of Origin (DCO). Ambos existem para estabelecer que um contribuidor tem permissão para fazer a contribuição e que o projeto tem o direito de distribuí-la. Eles diferem enormemente em peso, fricção e no que permitem que você faça depois. Este guia explica como cada um funciona, quando escolher qual, e como configurar sua escolha em uma tarde.

Por Que Seu Projeto Precisa de Uma Política de Contribuição​

Os direitos autorais se aplicam automaticamente. No momento em que alguém escreve código, ele o possui — sem registro, sem aviso de copyright necessário. Quando essa pessoa o submete ao seu projeto, sua licença de código aberto cobre muita coisa, mas deixa lacunas que só uma política de contribuição fecha:

• A concessão de entrada. Sua licença de saída (MIT, Apache-2.0, GPL) diz aos usuários o que eles podem fazer com seu código. Uma política de contribuição deixa explícito que as contribuições recebidas chegam sob termos compatíveis, para que você possa distribuir o trabalho combinado sem rastrear a proveniência arquivo por arquivo manualmente.
• Reivindicações de empregadores. A maioria dos contratos de trabalho atribui a propriedade intelectual de projetos paralelos ao empregador, pelo menos para trabalho relacionado à função do empregado. Uma política que pede aos contribuidores que confirmem ter o direito de submeter coloca essa responsabilidade — e o registro documental — sobre o contribuidor.
• Opcionalidade de relicença. Se você algum dia quiser mudar licenças, adicionar uma edição comercial ou doar o projeto para uma fundação, você precisa de direitos de todos os contribuidores. Obter essa permissão retroativamente de dezenas de contribuidores passados fica entre o penoso e o impossível. Uma política escolhida no primeiro dia decide se essa porta permanece aberta.
• Proteção de patentes. Contribuições de código podem trazer consigo direitos de patente. Algumas políticas incluem uma concessão explícita de patente; outras não, o que importa mais do que a maioria dos mantenedores percebe.

Nada disso exige um escritório de advocacia à disposição. Exige escolher CLA ou DCO, documentá-lo em seu repositório e aplicá-lo automaticamente. Eis o que cada escolha implica.

O Que É um Contributor License Agreement (CLA)?​

Um Contributor License Agreement é um documento legal assinado entre o contribuidor e o projeto (ou a empresa ou fundação por trás dele). O contribuidor assina uma vez, e essa assinatura cobre todas as suas contribuições futuras.

Ao contrário das licenças de código aberto, os CLAs não são padronizados. Cada projeto escreve o seu, mas a maioria se encaixa em duas formas familiares:

CLAs individuais vs. corporativos​

• CLA Individual (ICLA): assinado por uma pessoa contribuindo em nome próprio. Normalmente concede ao projeto uma licença ampla de direitos autorais e, frequentemente, uma licença de patente, enquanto o contribuidor mantém seus próprios direitos autorais.
• CLA Corporativo (CCLA): assinado por uma empresa, autorizando seus empregados a contribuir. A empresa concede os mesmos direitos para o trabalho que suas pessoas submetem. Projetos que aceitam contribuições corporativas sem um CCLA estão confiando que o gestor de cada empregado sabe — e aprova — o que é exatamente o tipo de confiança que evapora durante a due diligence.

Concessão de licença vs. cessão de direitos autorais​

A maioria dos CLAs modernos são concessões de licença: o contribuidor mantém a propriedade e dá ao projeto uma licença perpétua, mundial e livre de royalties — frequentemente ampla o suficiente para permitir a relicença. O ICLA da Apache Software Foundation é o exemplo canônico.

Uma minoria de projetos usa cessão de direitos autorais, em que o contribuidor transfere a propriedade integralmente (a abordagem da Free Software Foundation). A cessão dá ao projeto liberdade máxima para fazer valer direitos e relicenciar, mas exige o máximo dos contribuidores e caiu em desuso em projetos liderados pela comunidade.

O que um CLA custa a você e aos seus contribuidores​

O trade-off é a fricção. Um contribuidor de primeira vez precisa sair do pull request, ler um documento legal, assiná-lo (geralmente eletronicamente) e esperar que a verificação de status fique verde antes que um mantenedor revise seu código. As ferramentas tornaram isso quase indolor — bots como o CLA Assistant comentam no pull request com um link de assinatura e registram a assinatura automaticamente — mas ainda é um portão entre "eu corrigi seu bug" e "você pode fazer merge da minha correção". Alguns contribuidores casuais desistem diante dele.

Em troca, o projeto obtém um registro assinado e auditável: esta pessoa, nesta data, concedeu estes direitos. Para projetos com apoio corporativo, projetos com licença dupla e qualquer coisa que possa um dia ser adquirida, esse registro documental vale dinheiro de verdade.

O Que É o Developer Certificate of Origin (DCO)?​

O Developer Certificate of Origin foi introduzido pela Linux Foundation em 2004 para o kernel do Linux, justamente para evitar o peso de um CLA. Não é um contrato que um contribuidor assina e arquiva. É uma certificação curta — cinco parágrafos, versão 1.1 — que o contribuidor afirma a cada commit adicionando uma linha Signed-off-by à mensagem do commit:

Fix off-by-one error in retry backoff calculation
 
The retry delay doubled one extra time because the loop counter
started at 1 instead of 0.
 
Signed-off-by: Alex Rivera <[email protected]>

Adicionar a linha é uma flag: git commit -s a anexa automaticamente usando sua identidade Git configurada. Ao assinar, o contribuidor certifica que:

1. Ele criou a contribuição (no todo ou em parte) e tem o direito de submetê-la sob a licença de código aberto do projeto, ou
2. Sua contribuição é baseada em trabalho anterior já sob uma licença de código aberto apropriada que permite essa submissão, ou
3. Ele recebeu a contribuição de outra pessoa que certificou um dos itens acima, e ele não a modificou, e
4. Ele entende que a contribuição e seu registro — incluindo sua assinatura — são públicos e mantidos indefinidamente.

Esse é todo o mecanismo. Sem documento separado, sem vinculação de conta, sem onboarding por projeto. A aplicação é uma verificação de status: o app DCO ou uma verificação equivalente verifica se cada commit no pull request carrega uma assinatura válida, e os mantenedores fazem merge apenas quando está verde.

As limitações deliberadas do DCO​

Observe o que o DCO não faz. Ele não concede nenhuma licença além do que a licença de saída do projeto já transmite — ele conta com a contribuição chegando sob os termos de licença do projeto. Não contém concessão de patente. E, como nada é assinado e arquivado por contribuidor, não há registro central de quem concordou com o quê; o próprio histórico do Git é o registro.

Os defensores consideram isso uma característica: a baixa barreira do DCO é o ponto. O kernel do Linux, o GitLab (que mudou de um CLA em 2017) e o Chef (que mudou em 2016) todos concluíram que a atestação por commit lhes dá a proveniência de que precisam sem taxar cada contribuidor. O Comitê Técnico do OpenStack resolveu em 2025 substituir seu CLA pelo DCO para todas as contribuições. A tendência da indústria é inconfundível — mas uma tendência não é um veredito para o seu projeto, como explicam as próximas seções.

CLA vs. DCO Lado a Lado​

Quando um CLA É a Escolha Certa​

Escolha o CLA quando o futuro do projeto pode depender de direitos que o DCO não captura:

• Você planeja licença dupla ou relicença. Se uma edição comercial, uma mudança de licença ou uma transição de copyleft para licenciamento permissivo é sequer remotamente plausível, um CLA com uma concessão ampla de volta é a única forma leve de manter essa opção aberta. Reconstruir o consentimento anos depois é o cenário de pesadelo.
• Uma empresa sustenta o projeto. Patrocinadores corporativos, adquirentes e clientes empresariais fazendo due diligence de PI querem um registro de assinaturas, não arqueologia. Google, projetos Apache e Canonical usam CLAs exatamente por esse motivo.
• Patentes importam no seu domínio. Codecs, protocolos sem fio, arquiteturas de modelos de ML — em áreas densas em patentes, a concessão explícita de patente do CLA faz um trabalho real que o DCO silenciosamente pula.
• Uma fundação exige. Algumas fundações exigem seu CLA como condição de hospedagem ou graduação. Verifique antes de presumir que o DCO é suficiente.

Se você seguir esse caminho, mantenha o próprio CLA padrão e entediante: comece pelo Apache ICLA ou por um modelo Harmony em vez de redigir do zero, publique as versões individual e corporativa, e configure um bot de assinatura no primeiro dia para que a fricção seja um clique, não uma ida e volta de PDF.

Quando o DCO Vence​

Escolha o DCO quando as contribuições são a força vital e a fricção é o inimigo:

• Projetos comunitários com muitos contribuidores casuais. Correções de documentação, ajustes de erros de digitação, pequenos patches de bugs — as contribuições mais propensas a desistir diante de um portão de assinatura são também as que um DCO lida com elegância.
• Licença permissiva, sem planos de relicença. Se o projeto permanecerá MIT ou Apache-2.0 para sempre e não há edição comercial no roteiro, os direitos extras do CLA compram pouco.
• Mantenedores solo e equipes pequenas. O DCO não precisa de infraestrutura de assinatura, de entidade legal para manter acordos, nem de processo para assinar formulários corporativos. É governança que você pode administrar a partir de um arquivo CONTRIBUTING.md e uma verificação de status.
• Postura de máxima compatibilidade. Alguns contribuidores — particularmente aqueles empregados por grandes empresas com políticas rígidas de PI — podem assinar um DCO, mas não podem assinar um CLA externo sem revisão jurídica. O DCO mantém essa porta aberta.

Seja qual for sua escolha, documente a decisão. Um CONTRIBUTING.md que declara a política, mostra o fluxo exato de assinatura, e vincula o texto completo elimina a fonte mais comum de confusão: contribuidores adivinhando requisitos a partir de uma verificação de status que falhou.

5 Erros Que Minam Qualquer Uma das Escolhas​

1. Dizer ambos. A falha mais comum no mundo real é um CONTRIBUTING.md que exige assinaturas DCO em um parágrafo e assinaturas de CLA em outro — geralmente após uma migração pela metade. Os contribuidores seguem uma instrução, a outra verificação falha, e os mantenedores fazem merge de qualquer forma, o que anula o propósito de ambas. Escolha um mecanismo, aplique-o, e apague todo vestígio do outro.

2. Nenhuma aplicação automatizada. Uma política declarada apenas em prosa é uma sugestão. Vincule a verificação ao seu fluxo de pull request como uma verificação de status obrigatória — o app DCO para assinaturas, o CLA Assistant ou EasyCLA para assinaturas de documentos — para que uma contribuição sem acordo não possa ser mesclada por acidente ou fadiga do mantenedor.

3. Ignorar contribuidores corporativos. Se empresas usam e corrigem seu projeto, empregados submeterão código em horário de trabalho. Sob uma política de CLA, isso significa obter o CCLA assinado cedo, enquanto a relação está aquecida. Sob uma política de DCO, significa garantir que o requisito de assinatura seja visível o suficiente para que a primeira contribuição de ninguém se torne um incidente de PI.

4. Presumir que contratos de trabalho permitem contribuir. O outro lado da mesma moeda: se você contribui para outros projetos, verifique seu próprio contrato de trabalho primeiro. Muitos atribuem a PI de projetos paralelos relacionados ao trabalho ao empregador por padrão. A certificação do DCO ("tenho o direito de submeter isto") só é verdadeira se essa papelada disser isso.

5. Nenhuma política para código assistido por IA. Contribuições geradas por máquina levantam questões de proveniência que nem o texto do DCO da era de 2004 nem a maioria dos modelos de CLA previram. Decida sua postura — permitido com revisão, divulgado ou proibido — e declare-a no CONTRIBUTING.md junto com sua política de CLA/DCO, antes que seu primeiro pull request gerado por IA chegue, em vez de depois.

Não Esqueça o Lado Financeiro do Seu Projeto​

Eis a parte que os mantenedores adiam até a temporada de impostos: no momento em que seu projeto ganha seu primeiro dólar — pagamentos do GitHub Sponsors, doações do Open Collective, um trabalho de consultoria que chegou por causa do seu README — ele tem finanças, e finanças precisam de livros.

A mesma disciplina que torna a proveniência das contribuições auditável torna o dinheiro do projeto gerenciável. Rastreie a receita de patrocínio separadamente do seu salário para que você saiba o que é renda tributável de trabalho autônomo. Registre as despesas do projeto — renovações de domínio, minutos de CI, a tarde que um advogado passou revisando seu CLA — em contas próprias para que as deduções não evaporem nas faturas do cartão pessoal. Se o projeto crescer para uma LLC ou se juntar a um host fiscal, registros históricos limpos tornam a transição entediante em vez de forense.

A contabilidade em texto puro se encaixa excepcionalmente bem nesse fluxo de trabalho: seu livro-razão vive no controle de versão ao lado do seu código, cada lançamento tem um histórico, e nada se esconde em um formato proprietário. Nossa documentação mostra como colocar um primeiro livro-razão em funcionamento em minutos.

Mantenha as Contas do Seu Projeto Tão Limpas Quanto Seu Histórico Git​

Escolher entre um CLA e um DCO leva uma tarde; desembaraçar a proveniência ou as finanças do projeto anos depois leva semanas. Tome a decisão de contribuição agora, automatize sua aplicação, e dê ao dinheiro do projeto o mesmo cuidado que você dá aos seus commits. O Beancount.io oferece contabilidade em texto puro que lhe dá transparência e controle completos sobre seus dados financeiros — sem caixas-pretas, sem aprisionamento de fornecedor. Comece gratuitamente e veja por que desenvolvedores e profissionais de finanças estão mudando para a contabilidade em texto puro.