De quem é o código que você mandou desenvolver
Quem fica com o código, o banco e os acessos quando a empresa contrata um sistema, e o que precisa estar em contrato para não ficar refém.
Resposta rápida
No Brasil, software é protegido como obra intelectual, e quando a empresa contrata o desenvolvimento os direitos patrimoniais normalmente pertencem a quem contratou — mas isso precisa estar escrito. Sem cláusula expressa de cessão, e sem a entrega efetiva de repositório, banco e acessos de infraestrutura, a empresa acaba refém do fornecedor na prática, mesmo tendo razão no papel. Propriedade sem acesso não serve para nada.
Neste artigo
A empresa pagou pelo sistema. Usa todo dia. Quando decide trocar de fornecedor, descobre três coisas ao mesmo tempo: o código está no repositório pessoal do desenvolvedor, a hospedagem está no cartão dele, e o domínio foi registrado no nome dele.
O sistema é da empresa. O acesso não é. E na prática é o acesso que manda.
O que a lei diz, em resumo
No Brasil, programa de computador é protegido como obra intelectual, por lei própria. Quando o desenvolvimento é contratado por uma empresa, os direitos patrimoniais — o direito de usar, modificar e explorar — normalmente ficam com quem contratou.
Mas “normalmente” é uma palavra perigosa em contrato. A regra depende de como o vínculo foi estabelecido e do que ficou escrito. Discutir isso depois, com o sistema em produção, é a pior hora possível.
A solução custa nada: cláusula expressa de cessão de direitos patrimoniais, no contrato, antes de começar.
Propriedade no papel não basta
É aqui que a maioria dos casos trava. Você pode ter toda a razão jurídica e ainda assim não conseguir mexer no seu sistema.
O que precisa ser entregue, de fato:
Repositório com histórico. Não é um arquivo .zip com o código. É o repositório, com o histórico de alterações, numa conta da sua empresa. O histórico importa: é como alguém entende por que uma decisão foi tomada.
Banco de dados. Estrutura e dados, em formato que outra pessoa consiga restaurar.
Acessos de infraestrutura em nome da empresa. Hospedagem, domínio, serviços externos, chaves de API. Tudo contratado com e-mail corporativo e cartão da empresa — nunca no nome pessoal de quem desenvolve.
Documentação mínima. Como subir o ambiente do zero. Não precisa ser manual extenso; precisa ser suficiente para outro desenvolvedor assumir sem adivinhar.
Esse último item é o que separa um sistema que pode trocar de mãos de um que depende de uma pessoa específica. O risco disso está em sinais de que é hora de refatorar o sistema legado.
Os pontos que geram discussão
Reuso de componentes. É normal o fornecedor ter base própria e reutilizá-la. Legítimo. O que não deve acontecer é a regra específica do seu negócio virar produto vendido ao seu concorrente. Vale uma linha separando as duas coisas.
Bibliotecas de terceiros. Todo sistema moderno usa código aberto, e isso é bom. Cada biblioteca tem licença própria, e algumas impõem obrigações quando o software é distribuído. Peça a lista de dependências e licenças. Para uso interno raramente é problema — mas é informação que você deve ter.
Trabalho feito antes do contrato. Se o fornecedor já tinha parte pronta, defina o que está sendo cedido e o que está sendo licenciado para uso.
O que colocar no contrato
Quatro itens resolvem a maior parte dos problemas:
- Cessão expressa dos direitos patrimoniais sobre o que for desenvolvido, após o pagamento.
- Lista do que é entregue: repositório, banco, acessos, documentação — com prazo.
- Infraestrutura em nome da contratante, desde o primeiro dia.
- Condições de saída: o que acontece se a relação terminar, com que antecedência e o que é entregue.
O item 4 é o mais ignorado e o mais útil. Ele transforma uma separação potencialmente traumática em um procedimento previsto.
O checklist completo de contratação está em checklist para contratar um desenvolvedor PJ.
Um teste rápido
Responda, sobre o seu sistema atual:
Se o seu fornecedor parasse de responder amanhã, você conseguiria contratar outra pessoa para mexer no sistema esta semana?
Se a resposta for não, o problema não é jurídico — é operacional, e ele existe hoje, não no futuro. Em geral se resolve sem conflito: é pedir os acessos e transferir as contas, o que fornecedor sério faz sem resistência.
Se quiser uma leitura dessa situação no seu caso, me chame.
Perguntas frequentes
Se eu paguei, o código não é automaticamente meu?
Não assuma. A regra geral favorece quem contratou o desenvolvimento, mas contrato mal escrito, ausência de cláusula e uso de bibliotecas de terceiros criam zonas cinzentas. Exigir cláusula expressa de cessão de direitos patrimoniais custa nada e elimina a discussão.
O que eu preciso receber além do código?
Repositório com histórico, banco de dados com estrutura e dados, acessos de infraestrutura em nome da sua empresa (hospedagem, domínio, serviços externos) e documentação mínima para outra pessoa subir o ambiente. Código sem acesso ao servidor não roda.
O fornecedor pode reutilizar partes do meu sistema em outro cliente?
Depende do que o contrato disser. É comum e legítimo que ele reutilize componentes genéricos que já tinha. O que não deve acontecer é a regra de negócio específica da sua empresa virar produto para o concorrente. Esse ponto merece uma linha própria no contrato.
E se o sistema usa bibliotecas de código aberto?
Usar biblioteca aberta é normal e desejável, mas cada uma tem licença própria e algumas impõem obrigações a quem distribui o software. Peça a lista de dependências e as licenças. Para sistema de uso interno isso raramente é problema, mas é informação que você deve ter.
Quem escreve
Thainan Prado
Desenvolvedor full stack sênior com mais de 8 anos de experiência, responsável por sistemas em produção para empresas como OXXO, Ambev e Shell Select. Desenvolve sistemas sob medida, automações e integrações para PMEs e empresas médias de todo o Brasil.