Distribuidora de autopeças, 35 pessoas. O painel sob medida já está desenhado — pedido, estoque por filial, comissão do mês, tudo num lugar só. O escopo agrada, o preço o dono topa. E aí, na véspera de assinar, vem a pergunta que trava tudo: se eu pagar por esse sistema, de quem é o código? E se a empresa que construiu sumir daqui a dois anos?
É uma boa pergunta, e ela quase sempre chega no fim — quando o projeto já está pronto pra começar. A gente prefere responder antes.
Um aviso antes de seguir: o que vem abaixo é pra você conversar com quem entende de contrato, não parecer jurídico. Cada dispositivo citado está linkado no texto oficial. A decisão sobre o seu caso é do seu advogado, não deste artigo.
São duas perguntas, não uma
Quem está prestes a mandar fazer um sistema sob medida costuma juntar dois medos numa frase só. Vale separar, porque a resposta de cada um vem de um lugar diferente.
A primeira é de propriedade: de quem é o código quando fica pronto. Essa tem resposta na lei.
A segunda é de continuidade: o que acontece com a sua operação se o fornecedor fechar as portas, subir o preço ou simplesmente parar de atender. Essa não se resolve na lei — se resolve no contrato e na forma como o sistema é entregue.
Confundir as duas é o que deixa o medo grande. Uma parece jurídica, a outra parece técnica, e no fim as duas viram um "sei lá, melhor não mexer". Separadas, cada uma tem um caminho claro. Vamos uma de cada vez.
De quem é o código do sistema, segundo a lei
No Brasil, software é tratado como obra — protegido pela Lei do Software (Lei nº 9.609/1998) e pela Lei de Direito Autoral. E a Lei do Software tem um artigo que responde direto à sua pergunta.
O artigo 4º diz, na letra: "Salvo estipulação em contrário, pertencerão exclusivamente ao (...) contratante de serviços (...) os direitos relativos ao programa de computador, desenvolvido e elaborado durante a vigência de contrato". Traduzindo: quando você contrata alguém expressamente pra desenvolver um sistema pra você, por padrão os direitos são seus.
Parece que resolve. Mas repare nas três primeiras palavras: "salvo estipulação em contrário". Elas são a parte mais importante da frase. A lei entrega o código pra você enquanto o contrato ficar calado sobre isso. Se o contrato disser o contrário — que o código fica com quem desenvolveu, que você recebe só uma licença de uso —, aí vale o que o contrato diz, não a regra da lei.
Ou seja: a lei começa do seu lado, e é fácil abrir mão disso sem perceber, assinando um documento que inverte a regra. A lição não é "relaxa, o código é meu por lei". É: está escrito, com todas as letras, que a titularidade e o código-fonte são seus e serão entregues? Se não está, você está contando com a boa vontade, não com o papel.
Registrar o sistema no INPI não é o que você pensa
Aqui aparece um mal-entendido comum. Muita gente ouve "registra no INPI" e imagina que isso põe o código guardado num cofre neutro, de onde daria pra sacar o sistema se o fornecedor sumisse. Não é isso que o registro faz.
O registro de programa de computador no INPI protege a autoria — serve pra provar quem criou aquele software e desde quando. Mas ele não guarda o seu código. O sistema do INPI trabalha com um resumo digital, um "hash": uma espécie de impressão digital do arquivo, que comprova o conteúdo sem revelar nem armazenar o código em si.
E tem um detalhe que quase ninguém sabe: a guarda do código-fonte, diz o próprio INPI, é responsabilidade do titular do direito — não do instituto. Quem gera esse resumo, guarda o arquivo com o código e mantém tudo íntegro é o dono do registro. O INPI fica só com a impressão digital.
Então registro de autoria e ter o código na mão são coisas diferentes. "Registrei no INPI" responde "quem criou". Não responde "e se o fornecedor sumir, eu consigo pegar o sistema e continuar com outro time?". Essa segunda pergunta é a de continuidade — e ela se resolve em outro lugar.
Continuidade: e se o fornecedor do sistema sumir
Essa é a pergunta que mais tira o sono, e faz sentido. Contratar sob medida é diferente de assinar um sistema de prateleira: você está mandando construir algo que a sua operação vai passar a depender no dia a dia.
A boa notícia é que continuidade não é sorte — é um conjunto de coisas concretas que dá pra exigir desde o começo. Na minha experiência de quem já entregou sistema e também já viu projeto ficar órfão de fornecedor, o que separa um caso do outro não é o tamanho da empresa que construiu. É se o cliente ficou com as chaves na mão.
"Ficar com as chaves" quer dizer, na prática, três coisas:
- O código-fonte na sua mão, atualizado, num repositório — o lugar onde o código fica versionado, tipo um Drive de programador — que está no nome da sua empresa, não no do fornecedor.
- A infraestrutura no seu nome: o servidor onde o sistema roda, o banco de dados, o domínio. Se essas contas estão no seu CNPJ, ninguém desliga o seu sistema por você.
- Documentação de como o sistema é montado, pra que outro time consiga entender e continuar sem começar do zero.
Com essas três coisas, a resposta pra "e se o fornecedor sumir" deixa de ser "perdi tudo" e vira "contrato outro time pra continuar de onde parou". Você não fica preso a um fornecedor, porque não é ele que segura a chave.
Repare que nada disso é promessa de que ninguém nunca vai sumir. É outra coisa: se sumir, você continua de pé. A diferença é entre depender da existência do fornecedor e depender só do que já está na sua mão.
O que exigir no contrato antes de mandar fazer o sistema
Checklist pra levar pra mesa antes de assinar. É binário: ou está escrito, ou é um risco que você anotou.
- Está escrito que a titularidade do código e a entrega do código-fonte são suas? Sem isso, o "salvo estipulação em contrário" do artigo 4º não trabalha a seu favor.
- O código-fonte é entregue de forma contínua, num repositório no nome da sua empresa — ou só "lá no fim", um dia, se você lembrar de cobrar?
- As contas de infraestrutura (servidor, banco de dados, domínio) ficam no seu nome, com você tendo acesso de dono?
- Existe uma documentação mínima que permita outro time assumir o sistema?
- No encerramento do contrato, como é a saída: o que você leva, em quanto tempo, e como isso é comprovado?
- Você pode contratar outro fornecedor pra mexer no sistema depois, sem depender de autorização de quem construiu?
Se o fornecedor travar em três ou mais dessas perguntas, o problema não é preço. É que ele está vendendo dependência junto com o sistema.
Antes de assinar
Voltando pra distribuidora do começo: "de quem é o código" não devia ser a última pergunta antes de assinar. Devia ser uma das primeiras — porque a resposta muda o que você exige no contrato, em vez de virar uma descoberta ruim depois.
A lei já começa do seu lado, mas só enquanto o contrato não disser o contrário. O INPI protege a autoria e não guarda o seu código. E continuidade se constrói com o código, a infraestrutura e a documentação na sua mão desde o primeiro dia.
Este texto te deu vocabulário pra cobrar isso, não um veredito jurídico. As cláusulas do seu caso quem valida é o seu advogado.
Aqui, a gente entrega o sistema com o código-fonte versionado num repositório no seu nome e a infraestrutura no seu CNPJ — de propósito, pra que a saída seja sempre sua. Não porque a gente pretende sumir; porque um sistema do qual a sua operação vai depender não pode ficar na mão de um fornecedor só — nem da gente.
Me conta como a sua operação funciona hoje: o que roda em planilha, o que já tem sistema, onde trava. Numa conversa de 30 minutos dá pra mapear o que valeria a pena construir sob medida — e como fazer isso ficando com as chaves na mão desde o começo. Falar no WhatsApp
Este artigo é informativo e não substitui orientação jurídica. Decisão sobre o seu caso passa por um advogado.
Fontes consultadas
- Brasil, Lei nº 9.609, de 19 de fevereiro de 1998 (Lei do Software) — Presidência da República/Planalto. Art. 4º. Consultado em 23/07/2026.
- INPI, Guia completo de Programa de Computador — Instituto Nacional da Propriedade Industrial. Registro por hash e custódia do código-fonte pelo titular. Consultado em 23/07/2026.
