Contrato de desenvolvimento de software não prevê propriedade intelectual do código fonte: de quem é a titularidade?

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 trata de um jeito específico os contratos de encomenda: quando o desenvolvimento do sistema é o próprio objeto do contrato firmado com a empresa, e não existe cláusula em sentido contrário, os direitos sobre aquele código tendem a ficar com quem encomendou e pagou 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:

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.

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?

Ajuda bastante e é o argumento mais forte do contratante, mas não é automático. Pagamento integral reforça a posição de quem contratou, principalmente em desenvolvimento sob encomenda, mas convive com fatores como o uso de bibliotecas próprias do desenvolvedor.

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.

Conclusão: 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ã.

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.

Sobre o autor

Siga @phelipecardosoadv no Instagram →

Phelipe Pereira Cardoso é advogado desde 2009 e fundador do PHC Phelipe Cardoso Advogados. Atua principalmente em Direito Civil, Empresarial e do Consumidor, com experiência em responsabilidade civil, indenizações, contratos, conflitos patrimoniais e demandas envolvendo empresas e instituições financeiras.

Ao longo de sua trajetória, concedeu entrevistas e contribuiu com análises jurídicas para veículos como TV Globo, TV Record e Rádio Itatiaia, abordando temas de interesse público e questões relevantes das relações civis e de consumo. À frente do PHC, coordena a estratégia jurídica do escritório e combina experiência prática, linguagem clara e tecnologia aplicada ao Direito para conduzir casos de forma técnica, personalizada e orientada à solução.

Precisa de orientação sobre o seu caso?

Fale com o escritório  ·  Conheça o PHC Advogados  ·  Ver outros artigos

Este conteúdo tem caráter informativo e não substitui a análise individual do seu caso por um advogado.