Tempo de leitura: 11 min · Atualizado em 03/09/2026
Vazar o código-fonte de um sistema depois de prestar serviço como pessoa jurídica, mesmo sem contrato assinado, não fica sem consequência: existe dever de sigilo sobre o que foi produzido e visto durante o trabalho, e a empresa pode exigir que o uso pare, cobrar indenização e, dependendo do caso, buscar responsabilização criminal. A dificuldade real não é o direito em si — é reunir prova de que o vínculo e a autoria do código existiram.
Por que a falta de contrato não apaga o dever de sigilo
Quando alguém é chamado para desenvolver um sistema, mesmo informalmente e recebendo como pessoa jurídica, essa pessoa passa a ter acesso a regras de negócio, dados internos e à lógica de funcionamento da empresa. Esse acesso carrega, por natureza, uma expectativa de sigilo que não nasce de uma cláusula escrita — nasce da própria situação: ninguém contrata um desenvolvedor esperando que ele divulgue o sistema depois. A ausência de papel assinado não elimina essa expectativa, apenas desloca o problema: a discussão deixa de ser “existia dever de sigilo” e passa a ser “como provar que ele existia e foi descumprido”.
De quem é o código quando o contrato nunca saiu do papel
Quando uma empresa paga um prestador especificamente para construir um software para uso dela, a titularidade do resultado normalmente é de quem encomendou e pagou pelo trabalho — não de quem digitou o código. É a lógica de qualquer encomenda: quem paga por um produto feito sob medida é o dono do produto, ainda que o executor tenha autoria técnica sobre a forma como escreveu. Sem contrato, essa relação de encomenda precisa ser demonstrada por outros meios. É o oposto do que acontece quando um fornecedor de software se recusa a entregar o código-fonte: ali a empresa quer o código de volta; aqui ele já está fora, em posse de quem não deveria mais tê-lo.
A diferença entre esse caso e o do ex-funcionário com carteira assinada
Quando o vazamento parte de um ex-funcionário com carteira assinada, a empresa já tem, de largada, elementos automáticos: horário fixo, ferramentas fornecidas por ela, subordinação, recibos de salário — tudo isso já demonstra o vínculo e deixa claro que o que foi produzido durante o expediente pertence à empresa. É o cenário tratado em vazamento de código-fonte por ex-funcionário através da nuvem. Com um prestador PJ sem contrato, nada disso existe automaticamente, e cada um desses pontos precisa ser reconstruído com outras provas.
Ex-funcionário x PJ sem contrato: o que muda na prática
| Situação | Ex-funcionário (carteira assinada) | Prestador PJ sem contrato |
|---|---|---|
| Vínculo | Comprovado por registro, recibos e rotina de trabalho | Precisa ser reconstruído com e-mails, pagamentos e conversas |
| Dono do código | Presumido como da empresa, pelo próprio emprego | Precisa demonstrar que o serviço foi encomendado e pago |
| Maior dificuldade | Provar o prejuízo causado pelo vazamento | Provar que o vínculo e a encomenda existiram |
| Prova mais decisiva | Registros internos de acesso e horário | Comprovante de pagamento e histórico técnico do repositório |
Provas que substituem o contrato que não existe
Sem contrato, o caminho é montar um conjunto de indícios que, somados, contam a mesma história. Nenhuma prova isolada costuma bastar, mas o conjunto pode ser bem convincente. Vale reunir:
- E-mails ou mensagens combinando o escopo do serviço, o prazo e o valor;
- Comprovantes de pagamento — Pix, transferência, nota fiscal avulsa — feitos especificamente pelo trabalho de desenvolvimento;
- Prints de conversas em WhatsApp, Slack ou Teams tratando de entregas, ajustes e cobranças do projeto;
- Histórico do repositório de código (commits, datas, autoria de cada trecho) mostrando quem entregou o quê e quando;
- Testemunhas — sócios, outros funcionários, clientes — que confirmem que aquela pessoa foi contratada para aquele projeto específico;
- O próprio sistema em produção, com marcas técnicas que batem com o que foi encomendado.
O que conta como vazamento de código-fonte na prática
Vazamento não é só publicar o código em um lugar aberto. Também entra nessa conta levar o código para um projeto próprio concorrente, entregá-lo a um cliente ou parceiro do desenvolvedor, ameaçar divulgar o sistema caso não seja pago um valor extra, ou simplesmente manter cópias fora de controle depois que o serviço terminou. A lógica é parecida com a de outros casos de uso indevido de informação que deveria ficar interna, como o de um ex-funcionário que leva a lista de clientes para um concorrente: muda o tipo de ativo levado, mas o raciocínio é o mesmo — a informação obtida durante o trabalho não pertence a quem a levou.
Combinado verbal também gera dever de sigilo — e a prova técnica ajuda
Há um cenário parecido, mas diferente: o de um freelancer que usa estratégias da empresa para ajudar um concorrente sem nunca ter assinado um acordo de confidencialidade, detalhado em freelancer que usou estratégias da empresa sem contrato de confidencialidade. A diferença para o código-fonte é que estratégias costumam ser mais difíceis de flagrar tecnicamente, enquanto um código copiado deixa rastro: comentários idênticos, forma de nomear variáveis, estrutura de funções, até erros repetidos. Isso não resolve o problema de provar o vínculo, mas ajuda a provar que houve cópia — e que o sigilo, mesmo combinado de boca, foi quebrado.
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.
Caminhos jurídicos disponíveis
Reunidas as provas possíveis, existem três frentes, que podem ser usadas em conjunto: pedir com urgência que o uso do código pare e que as cópias fora de controle sejam apagadas, antes de qualquer decisão final; cobrar o prejuízo causado, incluindo o custo de reconstruir ou proteger o sistema e o que a empresa deixou de ganhar por causa do vazamento; e, dependendo de como o código foi obtido e usado, levar o caso à esfera criminal — por exemplo, em casos de acesso indevido a sistemas ou apropriação de informação sigilosa. O software, mesmo sem contrato, costuma receber o mesmo tipo de proteção que a Lei de Direitos Autorais dá a outras criações intelectuais, o que reforça que copiar e usar o código sem autorização é uma violação.
Quanto vale a causa e o que pode ser cobrado
O valor de uma disputa assim depende do prejuízo demonstrado, e não é automático. Entram na conta o custo de refazer ou substituir partes do sistema comprometido, o que a empresa deixou de ganhar por um concorrente passar a usar tecnologia equivalente sem ter investido para desenvolvê-la, e os gastos com a resposta ao incidente — auditoria, troca de credenciais, orientação jurídica. Dano à reputação só entra se houver como mostrar que o vazamento, de fato, prejudicou a imagem da empresa perante clientes ou parceiros.
Primeiros passos práticos ao descobrir o vazamento
A ordem das ações importa. Antes de confrontar o prestador, o ideal é:
- Reunir e guardar em local seguro todas as provas do vínculo e do vazamento, sem alterar nada;
- Fazer uma notificação formal exigindo que o uso do código pare e que qualquer cópia fora de controle seja apagada;
- Levantar, com números, o que já foi perdido ou está em risco de ser perdido;
- Buscar orientação jurídica para avaliar se cabe um pedido de urgência antes de qualquer outra medida;
- Revisar imediatamente senhas, acessos e permissões em repositórios e sistemas internos.
Como reduzir esse risco em contratações futuras
A forma mais simples de evitar passar por isso de novo é parar de contratar desenvolvimento sem nenhum registro por escrito — mesmo um contrato simples, de uma ou duas páginas, com uma cláusula de sigilo, já muda a facilidade de provar o combinado depois. Vale também limitar o acesso de cada prestador só ao que ele precisa, e revogar esse acesso assim que o serviço termina — cuidado que também aparece na situação do prestador de TI que mantém as senhas dos sistemas mesmo depois do fim do contrato, que segue gerando risco muito além do momento em que o serviço acabou.
Perguntas frequentes
Preciso ter contrato assinado para poder agir contra o desenvolvedor?
Não é obrigatório, mas sem contrato o trabalho de prova é bem maior. É preciso reunir outros elementos — pagamentos, mensagens, histórico do repositório — para mostrar que houve prestação de serviço e que o código pertence à empresa.
Como provar que o código pertence à minha empresa e não ao desenvolvedor?
Mostrando que o serviço foi encomendado e pago especificamente para aquele sistema. Comprovantes de pagamento vinculados ao projeto, mensagens combinando escopo e prazo, e o histórico técnico do repositório costumam ser as provas mais fortes.
O que fazer imediatamente ao descobrir que o código vazou?
Preservar as provas antes de qualquer confronto, notificar formalmente exigindo que o uso pare, e revisar por completo senhas e permissões de acesso aos sistemas e repositórios.
É possível pedir que a Justiça obrigue a retirada do código com urgência?
Sim, é possível pedir uma medida urgente para interromper o uso e forçar a exclusão de cópias, sem esperar o processo terminar, desde que o risco de dano contínuo esteja bem demonstrado.
Além de cobrar o prejuízo, cabe alguma medida criminal?
Pode caber, dependendo de como o código foi obtido e usado — por exemplo, em acesso indevido a sistemas ou apropriação de informação sigilosa. É avaliado caso a caso, junto com a via de indenização.
Conclusão: contrato ausente não é sinônimo de código desprotegido
A falta de contrato assinado muda a estratégia, não o direito. O que a empresa precisa fazer é trocar o papel que não existe por um conjunto de provas que, juntas, mostrem que houve prestação de serviço, que o código foi encomendado e pago, e que o sigilo era esperado desde o início daquela relação.
Quanto antes essas provas forem reunidas e a notificação formal for enviada, maior a chance de conter o uso indevido antes que o prejuízo cresça — seja ele a perda de vantagem competitiva, seja o custo de reconstruir a segurança do sistema comprometido.
Fontes oficiais consultadas
- Instituto Nacional da Propriedade Industrial (INPI) — proteção de programas de computador e propriedade industrial
- Presidência da República — Lei de proteção da propriedade intelectual de programa de computador (Lei do Software)
- Ministério da Justiça e Segurança Pública — orientações sobre crimes cibernéticos e acesso indevido a sistemas
Artigos relacionados
- Contrato de desenvolvimento de software não prevê propriedade intelectual do código fonte: de quem é a titularidade?
- Fornecedor de software recusa entregar o código-fonte após o fim do contrato: a empresa tem direito a receber?
- Vazamento de código-fonte e segredo industrial por ex-funcionário através da nuvem: como a empresa pode agir?
- Sistema SaaS contratado alterou os termos de uso e excluiu funcionalidades essenciais sem aviso prévio: é quebra de contrato?
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.
