A cena é mais comum do que deveria. Uma empresa investe R$ 80 mil em um sistema sob medida. Três anos depois, decide trocar de fornecedor — por preço, por atendimento, por qualquer motivo legítimo. É aí que descobre: não tem acesso ao código-fonte, o servidor está contratado no CNPJ da antiga empresa de tecnologia e até o domínio do sistema está registrado em nome de terceiros.
A pergunta “de quem é o código?” parece assunto de advogado até o dia em que ela decide o futuro da sua operação. Neste artigo, vamos explicar o que a lei brasileira diz sobre propriedade intelectual de software, qual a diferença entre ter o direito e ter o acesso, e o que exigir em contrato antes de assinar qualquer projeto.
O que a lei brasileira diz sobre software sob encomenda
No Brasil, o software é protegido pela Lei nº 9.609/1998, conhecida como Lei do Software. O artigo 4º estabelece que, salvo estipulação em contrário, os direitos pertencem ao empregador ou ao contratante de serviços quando o programa é desenvolvido durante um vínculo expressamente destinado a essa atividade, quando o desenvolvimento integra as atribuições contratadas ou quando decorre da própria natureza desses encargos. Em projetos sob encomenda, portanto, o contrato e a descrição do serviço são decisivos para definir a titularidade com segurança.
Só que essa regra vem com uma cláusula que muda tudo: “salvo estipulação em contrário”. Se o contrato disser outra coisa — ou se não existir contrato escrito definindo o assunto —, abre-se uma zona cinzenta que costuma ser resolvida da pior forma possível: no desgaste, na negociação sob pressão ou na Justiça. Vale o registro de sempre: este artigo não substitui aconselhamento jurídico. Antes de assinar, leve o contrato a um advogado de confiança. O que fazemos aqui é mostrar, do lado da tecnologia, onde moram os riscos.
Funcionário, freelancer ou empresa: o vínculo muda alguma coisa?
Um detalhe que gera dúvida: a mesma lei trata do software criado por funcionários. Quando o programa é desenvolvido por um empregado contratado para essa finalidade, os direitos pertencem ao empregador — também aqui, salvo acordo em contrário. O cuidado extra vale para os arranjos informais, muito comuns no mercado: o freelancer contratado por mensagem de WhatsApp, o “conhecido que programa”, o sócio técnico que deixou a sociedade levando o repositório junto. Quanto mais informal o vínculo, mais frágil fica a posição da empresa em uma eventual disputa.
Isso não significa que trabalhar com profissionais independentes seja um risco em si — muitos são excelentes. Significa que a formalização importa mais, e não menos: um contrato simples de prestação de serviços, com cláusula de cessão de direitos e entrega do código, resolve em uma página o que anos de discussão não resolvem depois.
Ter o direito não é a mesma coisa que ter o acesso
Este é o ponto que mais surpreende empresários. Juridicamente, o código pode ser seu. Na prática, ele mora em um repositório que você nunca viu, roda em um servidor cuja senha você não tem e depende de serviços contratados em contas que não são suas. É propriedade sem posse — e, no dia a dia, é a posse que mantém o sistema no ar.
Ter posse do seu sistema significa, no mínimo: acesso ao repositório onde o código é versionado, credenciais do servidor e do banco de dados guardadas pela sua empresa, contas dos serviços essenciais (domínio, e-mail transacional, gateway de pagamento) registradas no seu CNPJ e uma documentação mínima que permita a outra equipe assumir o projeto. Se qualquer um desses itens existe apenas nas mãos do fornecedor, existe um ponto único de falha entre a sua operação e ele.
Cessão, licença de uso e a caixa-preta
Nem todo modelo de contratação transfere o código — e não há nada de errado nisso, desde que esteja claro. No desenvolvimento sob medida clássico, o esperado é a cessão: o sistema foi feito para você, com o seu investimento, e o código é entregue como parte do projeto. No licenciamento de produto, como um SaaS ou um sistema de prateleira, você paga pelo direito de uso: o código é do fornecedor, e sempre será — é o modelo de negócio dele.
Existem ainda os modelos híbridos, em que o fornecedor mantém um núcleo próprio e desenvolve customizações para cada cliente. Nesse caso, é fundamental saber o que é seu e o que é dele — e o que acontece com as suas customizações se a relação terminar. O problema real não é o modelo escolhido. É descobrir em qual deles você está só na hora da rescisão.
Um exemplo prático ajuda a enxergar a diferença. Se a sua empresa usa um CRM de mercado por assinatura, o código nunca será seu — e tudo bem: você paga pouco justamente porque o custo do produto é diluído entre milhares de clientes. Agora, se você pagou o desenvolvimento integral de um sistema que só a sua empresa usa, a lógica se inverte: o investimento foi seu, o risco foi seu, e é razoável que o ativo também seja. As confusões acontecem no meio do caminho — quando um fornecedor cobra como projeto sob medida e entrega como licença de uso.
O que exigir em contrato antes de assinar
Alguns pontos deveriam constar em qualquer contrato de desenvolvimento sob encomenda, e a resistência do fornecedor em incluí-los já é, por si só, uma informação valiosa.
O primeiro é a cláusula de titularidade: preto no branco, a quem pertence o código desenvolvido no projeto. O segundo é a entrega contínua do código versionado, com a sua empresa tendo acesso ao repositório durante o projeto — não apenas um arquivo entregue no final. O terceiro é a infraestrutura no seu nome: servidor, domínio e serviços contratados no CNPJ da sua empresa, ainda que administrados pelo fornecedor.
Complete com uma exigência de documentação mínima (como o sistema é instalado, atualizado e configurado) e uma cláusula de transição: em caso de encerramento do contrato, o fornecedor se compromete a apoiar a passagem de bastão por um período definido. Nenhum desses pontos é hostil. Fornecedores sérios trabalham assim por padrão — e costumam receber bem clientes que perguntam sobre isso, porque é sinal de projeto maduro.
Checklist: o que sua empresa deveria ter em mãos hoje
Se você já tem um sistema em operação, vale um teste rápido. Sua empresa tem acesso ao repositório do código? As credenciais de servidor e banco de dados estão guardadas em um cofre de senhas da empresa? O domínio e os serviços essenciais estão no CNPJ certo? Existe documentação que permitiria a outra equipe assumir o sistema em algumas semanas?
Se você respondeu “não” — ou “não sei” — a duas ou mais dessas perguntas, sua empresa tem um risco de continuidade real, mesmo que a relação com o fornecedor atual seja ótima. Empresas mudam de dono, sócios brigam, prioridades se invertem. O momento de organizar esses acessos é agora, quando a relação está bem, e não durante uma rescisão.
E se o fornecedor sumir — ou segurar o sistema?
Quando o pior acontece, existem caminhos, e a ordem importa. O primeiro é sempre a negociação de transição: propor um encerramento formal, com entrega de código, acessos e um período de suporte, remunerado se necessário. Custa menos que qualquer alternativa. O segundo é o resgate técnico: uma nova equipe avalia o que a empresa efetivamente possui e reconstrói o acesso ao que for possível — às vezes recuperando o sistema, às vezes concluindo que refazer é mais barato que resgatar.
O caminho jurídico existe e, dependendo do contrato e da conduta do fornecedor, pode ser cabível. Mas ele é lento e caro, e enquanto corre, a operação segue dependente. Por isso a conclusão prática deste artigo é quase óbvia: prevenção, aqui, custa uma fração do remédio. Cada cláusula bem escrita e cada acesso guardado hoje é uma crise que não vai acontecer.
Um adendo para quem já está nessa situação: resista à tentação de resolver no grito. Bloquear pagamentos, trocar senhas que ainda estão compartilhadas ou expor o fornecedor publicamente costuma acelerar exatamente o cenário que você quer evitar — o sistema fora do ar e a relação sem volta. Enquanto a dependência existir, a negociação é o caminho mais barato, por mais injusto que isso pareça no momento.
Transparência é critério de escolha, não detalhe
A forma como uma empresa de tecnologia trata a propriedade do código diz muito sobre como ela enxerga o cliente: como parceiro ou como refém. Na Sulivam, projetos sob encomenda são entregues com código versionado, documentação e infraestrutura organizada em nome do cliente — porque acreditamos que o cliente fica pelos resultados, não pela dependência.
Se a sua empresa vai contratar um sistema, leve as perguntas deste artigo para a conversa. E se você já tem um sistema e não sabe responder ao checklist acima, fale com a gente: um diagnóstico de continuidade é rápido e pode poupar um problema grande no futuro.
