Tempo de leitura: 11 min · Atualizado em 06/09/2026
Quando o contrato de desenvolvimento de software não fala em propriedade intelectual, a regra mais aplicada é que quem contratou e pagou pelo sistema tende a ter o direito de usá-lo livremente. Mas isso não quer dizer, automaticamente, que a empresa contratante virou dona do código-fonte. A resposta certa depende de como o serviço foi combinado e do que entrou na construção do sistema.
É uma situação mais comum do que parece. A empresa fecha com um desenvolvedor ou uma fábrica de software, o sistema entra em produção, e ninguém escreveu quem fica com o código depois de pronto. Enquanto tudo funciona, ninguém sente falta dessa cláusula — o assunto costuma só aparecer quando algo já deu errado, como quando um sistema é entregue cheio de falhas, quando a relação azeda ou quando o próprio desenvolvedor reaproveita partes do código em outro projeto.
O silêncio do contrato não é o mesmo que “não tem dono”
A ausência de cláusula sobre propriedade intelectual não joga o código num vazio jurídico. Existe uma lógica padrão aplicada quando o contrato não resolveu o ponto, olhando o que as partes realmente combinaram: o que foi pago, como o objeto do contrato foi descrito e qual era a intenção de cada lado ao fechar o negócio. O silêncio é preenchido, só que nem sempre do jeito que o contratante presume.
A regra padrão: quem encomendou e pagou tende a ficar com o direito de uso
Quando uma empresa contrata e paga integralmente por um sistema feito sob medida para ela, a tendência é que o contratante tenha direito de usar esse sistema livremente, sem depender de autorização futura do desenvolvedor. Faz sentido: a empresa bancou o trabalho e o software foi pensado para resolver o problema dela. Negar esse uso depois de pago esvaziaria o próprio propósito do contrato.
Só que essa regra prática de “quem paga, usa” resolve o problema do dia a dia, não a pergunta mais precisa: o direito de uso é o mesmo que ser titular do código?
Ter direito de usar não é o mesmo que ser dono do código
Aqui mora a confusão mais frequente. Em regra, quem escreve um programa nasce como titular dos direitos sobre aquele código. A Lei do Software (art. 4º da Lei nº 9.609/1998) trata de um jeito específico os contratos de encomenda: salvo estipulação em contrário, quando o desenvolvimento daquele programa específico é o próprio objeto do contrato ou vínculo firmado com a empresa, os direitos patrimoniais sobre o código tendem a ficar com o contratante. O critério legal é a natureza da contratação — ter sido uma encomenda específica para a criação daquele programa —, não o simples fato de ter pago pelo serviço.
Para o caso comum de “contratei uma empresa de tecnologia especificamente para desenvolver este sistema para mim”, já existe uma resposta padrão favorável ao contratante, mesmo com o contrato calado. O problema é tratar essa regra como absoluta: ela vale para o que foi produzido especificamente naquele contrato, não para tudo que compõe o sistema entregue.
O que muda quando o desenvolvedor usa bibliotecas próprias
Poucos sistemas são escritos do zero. A maioria usa módulos e trechos que o desenvolvedor já tinha antes daquele contrato, ou reaproveita em vários clientes — um sistema de login, um painel administrativo genérico. Essa parte reaproveitável, em geral, não vira propriedade do cliente só por estar dentro do sistema entregue. Na prática, o resultado costuma se dividir em camadas:
| Parte do sistema | De quem tende a ser |
|---|---|
| Código escrito especificamente para aquele contrato | Do contratante, se o contrato não disser o contrário |
| Bibliotecas e módulos próprios do desenvolvedor, anteriores ao contrato | Do desenvolvedor, mesmo integrados ao sistema |
| Componentes de terceiros usados sob licença (frameworks e pacotes abertos) | Do titular original da licença |
| Documentação, layout de telas e dados cadastrados pela empresa | Normalmente da empresa |
Um contrato silencioso raramente separa essas camadas, e é aí que nasce boa parte das discussões: a empresa acha que “comprou tudo”, o desenvolvedor entende que só cedeu aquele sistema específico, mantendo para si a base reaproveitável — a mesma base que ele precisa proteger de um eventual vazamento de código-fonte por um ex-funcionário, já que ali também mora um segredo de negócio próprio.
Seu caso envolve uma situação semelhante?
Cada caso possui particularidades e deve ser analisado individualmente. Para informações sobre análise jurídica do seu caso, entre em contato com o escritório.
Sistema sob encomenda é diferente de licenciar um software pronto
A regra de que “quem paga tende a ter direito de uso pleno” pressupõe que o serviço foi mesmo desenvolvimento sob encomenda — um sistema pensado para aquela empresa, com escopo combinado especificamente para o projeto. É diferente de contratar o uso de um software que o fornecedor já mantinha pronto, apenas configurado para o cliente, em formato de assinatura.
Nesse segundo cenário, a empresa não contratou a criação de um código só dela, mas a licença de uso de um produto de prateleira. Dificilmente ela vai sustentar que é dona do código-fonte da plataforma — o que ela tem é o direito de continuar usando o serviço enquanto pagar por ele. Confundir os dois modelos é uma causa comum de expectativa frustrada quando o contrato termina.
Como pesa a forma como o contrato foi redigido
Diante de um contrato omisso, o que decide não é só a regra padrão em abstrato, mas indícios que revelam a real intenção das partes: como o objeto foi descrito, se havia exclusividade na prestação do serviço, se o pagamento cobria desenvolvimento específico ou apenas uso, e como as partes se comportaram depois — por exemplo, se o desenvolvedor seguiu vendendo sistema parecido a concorrentes sem que o cliente reclamasse.
Por isso vale revisar com cuidado o texto do contrato antes de assinar, mesmo numa relação de confiança. Cláusula ausente não é neutra: só transfere a decisão para depois, quando as partes já não estão mais alinhadas.
Isso é diferente de discutir a entrega física do código
Vale separar duas perguntas que se misturam. Uma é saber de quem é o direito sobre o código quando o contrato nada disse — o tema deste artigo. Outra é o que fazer quando já se sabe que o direito é da empresa, mas o fornecedor simplesmente se recusa a entregar o código-fonte depois de encerrado o contrato. Nesse segundo caso, a discussão não é mais sobre titularidade, e sim sobre obter na prática o que já é seu por direito — problema parecido com o de empresas cujo prestador de TI terceirizado mantém as senhas dos sistemas mesmo após o fim do contrato.
Como evitar esse problema em contratos futuros
A prevenção é simples de descrever e barata de aplicar, comparada ao custo de discutir isso depois que a relação já azedou. Um contrato de desenvolvimento bem escrito deixa claro, desde o início:
- o que exatamente é transferido — todo o código, só o direito de uso, ou uma licença por prazo determinado;
- o que continua sendo do desenvolvedor, como bibliotecas próprias e código reaproveitável;
- se há componentes de terceiros envolvidos e sob qual licença;
- o que acontece com o código se o contrato terminar antes do prazo previsto.
Essa cláusula não interessa só à empresa contratante. Um desenvolvedor que não deixa claro o que é seu corre o risco de, num contrato mal redigido, transferir sem perceber uma base que usa com vários outros clientes — algo que fica ainda mais confuso quando uma empresa terceirizada abandona o projeto no meio do desenvolvimento e ninguém sabe ao certo o que já pertence a quem.
Perguntas frequentes
Se o contrato só diz que a empresa “recebe o sistema pronto”, isso já garante a titularidade do código?
Não necessariamente. Essa frase costuma ser lida como entrega de um produto funcionando, não como cessão explícita de todos os direitos sobre o código-fonte.
O fato de a empresa ter pago o valor total do projeto já resolve a questão?
Não, isoladamente. O pagamento é esperado em qualquer contrato de prestação de serviço e não é, por si só, o critério legal de titularidade. O que decide é a natureza da contratação: se o desenvolvimento daquele programa específico foi o objeto da encomenda, o art. 4º da Lei do Software favorece o contratante mesmo com o contrato omisso — mas isso convive com fatores como o uso de bibliotecas próprias do desenvolvedor, que não deixam de ser dele só porque o projeto foi pago integralmente.
Um funcionário da própria empresa desenvolveu o sistema: a regra é a mesma?
Quando quem escreve o código é funcionário contratado justamente para desenvolver software, a titularidade tende a ficar com o empregador de forma ainda mais clara do que com um fornecedor externo, porque isso fazia parte das funções da própria relação de trabalho.
Freelancer que atua sem contrato escrito também segue essa lógica?
Sim, o raciocínio é o mesmo, mas a ausência de contrato formal deixa a discussão mais dependente de provas indiretas — mensagens, comprovantes de pagamento, escopo combinado por e-mail.
Dá para incluir essa cláusula num contrato que já está em andamento?
Sim, por meio de um aditivo assinado pelas duas partes, esclarecendo a titularidade a partir daquele momento. É mais simples fazer isso enquanto a relação ainda está de boa-fé do que depois de um rompimento.
E quando o sistema mistura código sob encomenda com um produto de prateleira do próprio fornecedor?
Esse é o cenário mais complexo, porque exige separar tecnicamente as duas partes. Costuma valer a pena um laudo técnico simples apontando o que foi construído especificamente para aquele cliente e o que já existia antes.
Cláusula clara evita discussão sobre o óbvio depois
Quando o contrato não fala em propriedade intelectual, a tendência é que quem contratou e pagou por um sistema sob encomenda tenha direito de usá-lo livremente, mas isso não é regra absoluta nem cobre tudo que compõe o sistema — bibliotecas próprias do desenvolvedor e componentes de terceiros seguem lógicas próprias. Quanto mais claro o objeto do contrato, mais fácil sustentar essa titularidade se um dia for preciso.
O mais barato continua sendo resolver isso por escrito antes de qualquer atrito: definir o que é transferido, o que permanece com o desenvolvedor e o que acontece se o contrato terminar antes do previsto. Uma cláusula de meia página hoje evita meses de discussão amanhã.
Fontes oficiais consultadas
- Planalto — Lei do Software (Lei nº 9.609/1998), sobre a proteção da propriedade intelectual de programas de computador
- Planalto — Lei de Direitos Autorais (Lei nº 9.610/1998), aplicada subsidiariamente aos programas de computador
- INPI — Registro de programas de computador e orientações sobre titularidade
Artigos relacionados
- Vazamento de código-fonte de software por ex-desenvolvedor contratado como PJ sem contrato formal: quais as vias legais?
- Fornecedor de software recusa entregar o código-fonte após o fim do contrato: a empresa tem direito a receber?
- Empresa de tecnologia terceirizada abandonou o projeto no meio do desenvolvimento: como reaver os valores pagos e o código já produzido?
- Vazamento de código-fonte e segredo industrial por ex-funcionário através da nuvem: como a empresa pode agir?
Veja também nosso conteúdo completo sobre direito digital.
Seu caso envolve uma situação semelhante?
Cada caso possui particularidades e deve ser analisado individualmente. Para informações sobre análise jurídica do seu caso, entre em contato com o escritório.
