Quem fica com o código que eu paguei

Pagar pelo desenvolvimento não transfere automaticamente todos os direitos sobre o código. Quem fica com o quê é definido pelo contrato, não pela nota fiscal. Sem uma cláusula expressa de cessão, é perfeitamente possível pagar por um sistema inteiro e terminar com o direito de usá-lo, enquanto o fornecedor segue como titular do código. Isso raramente é má-fé. É o resultado padrão de um contrato que simplesmente não tratou do assunto.

Por que pagar não basta

Software é obra protegida por direito autoral no Brasil, com legislação própria. Direito autoral nasce ligado a quem cria, e a transferência dos direitos patrimoniais para outra pessoa ou empresa precisa ser prevista por escrito. Contrato de trabalho e contrato de prestação de serviço não recebem o mesmo tratamento, e é justamente aí que muita empresa se surpreende: contratar um estúdio ou um freelancer é diferente de ter um funcionário registrado escrevendo o mesmo código.

O detalhe cruel é o momento em que o problema aparece. Enquanto a relação está boa, ninguém pergunta de quem é o código. A pergunta surge quando a empresa quer trocar de fornecedor, quando vai vender participação, quando um investidor pede due diligence ou quando o fornecedor encerra as atividades. Nessas horas, um contrato genérico de "prestação de serviços de desenvolvimento" não responde nada.

As quatro cláusulas que precisam existir

1. Cessão dos direitos patrimoniais. Precisa ser expressa, total e definitiva, sem limite de prazo nem de território, incluindo o direito de modificar, adaptar, sublicenciar e contratar terceiros para dar continuidade. Cessão "para uso interno" ou "para os fins deste projeto" é uma cessão amarrada.

2. Escopo do que está sendo cedido. Código não é só o arquivo da aplicação. Liste: código-fonte, scripts e migrações de banco, arquivos de infraestrutura, configurações, documentação, diagramas, arquivos editáveis de design e, em projetos com IA, os prompts e configurações de modelo.

3. Ressalva do que não é cedido. Nenhum sistema é escrito do zero. Bibliotecas abertas, componentes comerciais e frameworks internos do fornecedor não pertencem a você e não deveriam ser prometidos como se pertencessem. O contrato deve nomear esses itens e dizer sob qual licença você pode usá-los.

4. Entrega efetiva. Onde, quando e em que formato. Cessão sem entrega é papel: você é dono de um código que não tem em mãos.

Vale ainda definir o momento da cessão. É comum condicionar a transferência à quitação integral, o que é razoável para os dois lados, mas precisa estar escrito.

Código de terceiros e bibliotecas abertas

Todo sistema moderno é montado sobre componentes de terceiros. Os tipos mais comuns:

• Bibliotecas abertas permissivas (MIT, Apache, BSD): uso comercial livre, geralmente com a obrigação de manter o aviso de licença.
• Bibliotecas com copyleft (GPL, AGPL): dependendo de como são usadas, podem gerar obrigações sobre o código derivado.
• Componentes comerciais: licença paga por servidor, por assento ou por aplicação, muitas vezes intransferível.
• Serviços acessados por API: não é código, é contrato de uso, e o custo continua depois da entrega.

Peça um inventário de dependências com as respectivas licenças. Ferramentas de análise geram essa lista automaticamente, então o pedido não é abusivo. Se algum item preocupar, leve o inventário a um advogado especializado em propriedade intelectual antes de assinar.

Item por item: quem deve ficar com ele e como garantir

Repositório e contas no CNPJ desde o primeiro dia

A melhor cláusula é aquela que você nunca precisa executar. Se a estrutura já nasce no nome da empresa, não existe transferência a fazer no fim.

Antes da primeira linha de código:

• Crie a organização no serviço de repositório com um e-mail corporativo e convide o fornecedor como colaborador.
• Registre o domínio em conta da empresa.
• Abra as contas de nuvem, hospedagem, banco e serviços de terceiros no CNPJ, com o cartão da empresa.
• Configure acesso administrativo para pelo menos duas pessoas internas.

Isso não custa nada e elimina o cenário mais comum de dor de cabeça: descobrir que o sistema inteiro vive numa conta pessoal de alguém que não trabalha mais com você. Na Retti Tech, essa configuração é feita antes do início do projeto justamente porque discutir posse depois é caro para os dois lados.

Como fazer a transferência quando o projeto termina

Seja no encerramento planejado ou na saída de um fornecedor, a sequência é a mesma:

1. Inventário de acessos. Liste todo sistema, conta e serviço envolvido, com quem tem acesso a cada um.
2. Transferência de titularidade. Domínio, nuvem, repositório e contas de serviço passam para o CNPJ da empresa.
3. Rotação de segredos. Troque senhas, chaves de API e certificados. Remova acessos antigos.
4. Congelamento da versão. Marque a versão entregue no repositório e guarde uma cópia offline.
5. Teste de subida do zero. Alguém de fora tenta instalar e rodar o sistema numa máquina limpa, seguindo apenas a documentação.
6. Acompanhamento. Um período de 30 a 60 dias com o fornecedor disponível para dúvidas, previsto em contrato.

O passo 5 é o que separa posse formal de autonomia real. Se ninguém consegue subir o sistema sem o fornecedor original, você tem o código e continua dependente.

O que perguntar antes de assinar

• O contrato tem cláusula expressa de cessão de direitos patrimoniais?
• A lista de entregáveis inclui documentação, banco e infraestrutura, ou só o código?
• Quais componentes de terceiros serão usados e sob quais licenças?
• O repositório e as contas ficarão no nome da minha empresa desde o início?
• Existe algum framework proprietário do fornecedor? Sob qual licença ele fica comigo?
• O que acontece com os acessos e com o suporte se a relação terminar antes do previsto?

Este texto é orientação prática, não parecer jurídico. A forma da cessão, o momento da transferência e as ressalvas variam conforme o caso. Leve o contrato a um advogado antes de assinar: o custo dessa revisão é irrelevante perto do custo de descobrir o problema quando já não dá para negociar.