Quem é dono do código: licença, cessão e escrow em contratos de software

Programas de computador são protegidos pela legislação de direitos autorais: a Lei 9.610/98 lista expressamente o programa de computador entre as obras intelectuais protegidas, e a titularidade inicial pertence a quem criou. Isso vale tanto para a pessoa que programa por conta própria quanto para a empresa desenvolvedora.

Dessa regra nasce o mal-entendido mais comum do setor: a empresa paga pelo desenvolvimento, recebe o sistema funcionando e assume que o código é seu. Não é o que a lei diz. Sem cláusula de cessão escrita, o que o pagamento compra é a licença de uso que o contrato descrever, e a titularidade continua com quem desenvolveu.

A consequência prática aparece em três momentos: quando a empresa quer contratar outra equipe para evoluir o sistema, quando tenta vender o produto com o software embutido e quando o fornecedor encerra as atividades. Em todos eles, quem tem cessão negocia; quem tem apenas licença renegocia.

A licença é a autorização para usar o software dentro de limites: prazo ou perpetuidade, território, número de usuários, instalações permitidas e finalidade. O art. 29 da Lei 9.610/98 exige autorização prévia e específica do titular para a utilização da obra, e é esse instrumento que formaliza a permissão entre as partes.

As cláusulas que decidem o valor da licença são as que dizem o que o cliente pode fazer além de usar: pode alterar o código, pode contratar terceiro para dar manutenção, pode integrar o sistema com seus produtos e com serviços de terceiros, pode usar o software para atender a filiais e empresas do grupo. Cada resposta omissa é um limite interpretado pelo titular.

Na relação SaaS, a licença costuma estar embutida nos termos de uso da plataforma, e o cliente raramente lê os limites com atenção ao ciclo de vida: o que acontece com os dados, com as configurações e com o direito de uso se a relação terminar é questão de licença e de contrato de serviços ao mesmo tempo.

Em software desenvolvido sob encomenda, a cláusula de cessão deve dizer o quê, o quanto e com quais exceções a titularidade passa ao cliente. O art. 50 da Lei 9.610/98 determina que a cessão total ou parcial dos direitos patrimoniais do autor se faça sempre por escrito e presuma-se onerosa. O contrato omisso não gera cessão ampla: o que não foi escrito segue com o titular.

A negociação madura separa o código em camadas: o específico do negócio do cliente, que pode ser cedido integralmente, e os componentes genéricos que o fornecedor reaproveita entre projetos, sobre os quais se negocia licença retroativa ou perpétua ao cliente. O contrato omisso devolve essa decisão a quem detém a titularidade.

Vale incluir garantia de originalidade e declaração de componentes de terceiros. O código entregue quase nunca nasce isolado: bibliotecas de código aberto, kits de desenvolvimento e serviços externos trazem licenças próprias que sobrevivem à cessão. Saber o que está embutido, com inventário de dependências, é parte da entrega e não uma gentileza do fornecedor.

O escrow é o arranjo em que o fornecedor deposita o código-fonte em custódia com um terceiro, e o cliente ganha direito de acessá-lo somente quando hipóteses contratadas se verificarem. As mais comuns: encerramento das atividades do fornecedor, abandono do produto, rescisão do contrato por culpa do fornecedor e falha grave não sanada em prazo acordado.

O desenho do escrow é feito em três pontos: quais hipóteses liberam o acesso; o que exatamente é depositado, incluindo código compilável, documentação e credenciais necessárias; e como o cliente verifica periodicamente que o material depositado corresponde à versão em produção. Escrow sem verificação periódica protege o papel, não a operação.

O instrumento combina bem com licenças: ao liberar o acesso, o contrato deve conceder de imediato a licença necessária para o cliente manter, corrigir e evoluir o software com a equipe que escolher. Sem essa licença associada, o acesso ao código de nada adianta juridicamente.

A titularidade do código é item recorrente em due diligence de investimento e de aquisição. Quem examina a empresa procura: cessão escrita de todo o código relevante, licenças de terceiros regularmente obtidas, inventário de código aberto e ausência de dependência de código que a empresa não possa demonstrar ter direito de usar. Lacuna em qualquer um desses pontos vira desconto no preço ou condição para fechar.

Na troca de fornecedor, a mesma falta aparece em versão operacional: a empresa precisa migrar o sistema e descobre que a licença não permite que a nova equipe toque no código, ou que o conhecimento necessário saiu junto com o contrato anterior. O remédio é contratual: escrow, documentação obrigatória e licença de manutenção por terceiro já previstos desde a assinatura.

Em ambos os cenários, o padrão é o mesmo: o direito sobre o código vale o que o papel mostra. A conversa sobre titularidade é barata na assinatura e cara quando o negócio já depende da resposta.

O escrow falha por detalhe operacional, não por conceito. A primeira cláusula define o material depositado: código-fonte compilável, documentação de build e implantação, credenciais necessárias e inventário de dependências. Depósito parcial é o cenário mais comum de inutilidade: o código chega sem as instruções que o transformam em sistema funcionando.

A segunda cláusula é a verificação periódica: o agente de custódia confirma, em intervalos definidos, que o material depositado compila e corresponde à versão em produção, com relatório disponível ao cliente. A terceira é a licença associada: liberado o acesso, o contrato concede de imediato ao cliente a licença necessária para manter, corrigir e evoluir o software com a equipe que escolher.

O conjunto completo muda a posição do cliente na due diligence antes de investimento: escrow com depósito verificado e licença associada é continuidade demonstrável, e não promessa. Para o fornecedor, o mesmo conjunto é argumento comercial, porque transfere ao cliente a confiança que o discurso de vendas não sustenta sozinho.

Os três instrumentos respondem a perguntas diferentes sobre o mesmo código, e confundi-los é a origem da maioria das disputas. A licença responde o que o cliente pode usar; a cessão responde o que o cliente passa a ter; o escrow responde quando ele terá acesso ao que não tem. O quadro abaixo resume as diferenças que decidem a negociação.

A leitura prática do quadro: nenhuma linha substitui outra. O cliente que licencia sem escrow depende da sobrevivência do fornecedor; o que cede sem inventário de dependências herda licenças de terceiros; o que deposita em escrow sem verificação periódica tem proteção no papel. Os três combinados, com escopo escrito, cobrem uso, domínio e continuidade. Para o contrato completo de software, vale revisar a trilha de software, SaaS e licenciamento antes de fechar o texto final.