Se o desenvolvedor saiu e levou o código, empresários e gestores precisam agir rápido para preservar evidências, manter a continuidade do negócio e reduzir risco de perda do ativo digital. Nas próximas horas e dias, o foco é provar autoria, escopo do contrato e acesso indevido, para viabilizar negociação ou medidas judiciais.
Índice
ToggleQuando o desenvolvedor sai e “leva o código”, o que isso significa na prática
Na rotina de empresas, “levar o código” raramente é só apagar um repositório. Costuma envolver bloqueio de acessos, retenção de senhas, exclusão de backups, cópia do repositório para uso próprio ou entrega incompleta do que foi pago.
O ponto de negócios é simples. Sem o código-fonte e sem credenciais, a empresa perde previsibilidade de prazo, aumenta custo de troca de fornecedor e pode ficar refém para corrigir falhas. Isso afeta faturamento, compliance e até o caixa.
O que decide o caminho é a prova. Você precisa demonstrar o que foi contratado, o que foi entregue, quem criou o quê e quais acessos foram bloqueados ou removidos.
Direitos típicos da empresa: propriedade intelectual, posse dos arquivos e continuidade operacional
Nem todo software desenvolvido para uma empresa é automaticamente “da empresa” em todos os sentidos. O cenário muda conforme a relação (empregado, PJ terceirizada, agência, freelancer) e conforme o contrato.
O Instituto Nacional da Propriedade Industrial (INPI) trata o registro de programa de computador como meio de fortalecer a prova de autoria e data. Ele não “cria” o direito do zero, mas ajuda a reduzir discussão sobre anterioridade.
Programa de computador é a expressão de um conjunto organizado de instruções, em linguagem natural ou codificada, contida em suporte físico ou digital, para uso em máquinas. Segundo o Congresso Nacional, a Lei nº 9.609/1998, art. 2º, determina que o software é protegido pelo regime de direitos autorais. Para empresas, isso reforça que código-fonte, versões e módulos têm tutela jurídica e podem embasar pedido de cessação de uso indevido e indenização. Ignorar essa base costuma dificultar acordos e aumenta o custo de litígio, porque a discussão vira “palavra contra palavra”.
As 7 provas que mais ajudam quando há disputa por código e acessos
Prova boa é a que reconstrói fatos com baixa margem de interpretação. A recomendação é consolidar evidências antes de discutir por WhatsApp, porque conversas posteriores podem ser contestadas como “negociação”.
1) Contrato, proposta comercial e anexos técnicos (escopo)
Procure cláusulas sobre entrega de código-fonte, transferência de direitos, cronograma, aceite e sigilo. Se o contrato não tiver, vale a proposta enviada e aceita, inclusive por e-mail. O detalhe de escopo pesa.
2) Notas fiscais, comprovantes e histórico do faturamento do projeto
Pagamentos amarram a narrativa. Eles ajudam a provar a existência da contratação, o período de execução e o valor discutido. Em conflitos, isso delimita o “tamanho” do ativo e do prejuízo.
3) Histórico do repositório (Git), commits e permissões
Exportar o log de commits, tags, branches e permissões é objetivo e verificável. Se houver GitHub, GitLab ou Bitbucket, registre capturas com data e exporte relatórios. Faça isso antes de perder o acesso.
4) Evidências de acesso: senhas, tokens, painel de hospedagem e e-mails de reset
Centralize tudo que prova quem controlava a infraestrutura. Painel de DNS, provedor de nuvem, FTP, banco de dados, console de deploy e contas de e-mail corporativo entram aqui. Uma frase curta: sem infra, não há operação.
5) Backups e snapshots (antes e depois do rompimento)
Tenha pelo menos um backup externo, fora do fornecedor. Compare datas e tamanhos. A diferença entre “o código sumiu” e “o código foi substituído” muda a estratégia técnica e jurídica.
6) Ata notarial para capturar telas e estados do sistema
A ata notarial é uma forma forte de documentar o que aparece em tela e em páginas acessíveis. Ela não resolve tudo, mas costuma reduzir discussão sobre adulteração. Serve para painéis, mensagens, erros e bloqueios de acesso.
7) Mensagens, e-mails e tickets que provem negativa de entrega ou condicionamento
Guarde a conversa que mostra o pedido de entrega do código e a recusa, ou a tentativa de cobrar “resgate”. Evite provocações. Escreva pedido objetivo, com prazo e checklist do que precisa.
Abaixo, um quadro rápido do que cada evidência costuma demonstrar.
| Evidência | O que costuma provar | Erro comum |
|---|---|---|
| Contrato + anexos | Escopo, entregáveis, regras de cessão/licença | Assinar sem anexos técnicos e sem aceite formal |
| Logs do Git e permissões | Autoria por contribuição, histórico e controle de acesso | Não exportar antes de perder a conta |
| Backups e snapshots | Estado do sistema em data certa | Backup ficar só com o fornecedor |
| Ata notarial | Registro imparcial do que se vê em tela | Deixar para fazer depois, quando a tela mudou |
O que fazer nas primeiras 48 horas: contenção, continuidade e prova
O maior erro é discutir “quem tem razão” antes de travar o dano. A primeira orientação é técnica: preserve acessos, faça rotação de chaves, altere senhas e gere backup fora do fornecedor.
A segunda orientação é jurídica: formalize a notificação com pedido de entrega e prazo. Use checklist, cite ambientes (produção, homologação), repositórios e credenciais. Fica mais difícil alegar “não entendi o que pediram”.
Recomendamos também congelar mudanças em produção por alguns dias. Isso vale quando há risco de sabotagem. Não vale quando a empresa depende de deploy diário para vender e não há sinal de ataque.
Quando vira ilícito indenizável: o critério que separa “briga contratual” de dano
Nem todo atraso na entrega vira indenização automática. O ponto de corte costuma estar no comportamento: retenção deliberada, interrupção do serviço sem justificativa, acesso indevido e prejuízo demonstrável.
O Código Civil dá o eixo de responsabilidade. Segundo o Congresso Nacional, o Código Civil (Lei nº 10.406/2002), art. 186, define ato ilícito como violação de direito com dano, ainda que moral. O mesmo diploma, no art. 927, impõe o dever de reparar.
Recomendamos documentar o impacto financeiro. Anote pedidos cancelados, SLA quebrado, custo de recontratação e horas internas perdidas. Isso vale quando você quer acordo com números. Não vale se a prioridade é só retomar operação, sem discutir indenização agora.
Exceções e casos-limite que pegam empresas de surpresa
Alguns conflitos nascem de lacunas previsíveis no contrato. Eles aparecem em auditorias de governança de TI e em disputas entre sócios.
- Uso de componentes de terceiros: o fornecedor pode alegar que não pode “entregar tudo” por licenças. Você precisa do inventário de dependências e licenças.
- Ambiente em nome do desenvolvedor: domínio, nuvem e e-mail cadastrados no CPF do prestador viram ponto único de falha. A titularidade do contrato com o provedor importa.
- Coautoria ou múltiplas equipes: parte do código pode ser de outro fornecedor. O log de commits e os contratos anteriores são decisivos.
- Funcionário que desenvolveu internamente: a discussão muda para regras trabalhistas e políticas internas, com risco de prova fraca se não houver controle de acesso e registro de atividades.
Como reduzir o risco na próxima contratação (sem burocratizar a operação)
Governança de tecnologia não é só “jurídico”. Ela protege caixa e valuation. Um contrato bom já nasce com fluxo de entrega e de aceite.
- Repositório em organização da empresa, com permissões por perfil e MFA.
- Cláusula de entrega contínua: código, documentação mínima e credenciais operacionais.
- Plano de saída: prazo de transição, handover e checklist de ambientes.
- Backups automáticos em conta controlada pela empresa.
- Inventário de dependências e licenças, atualizado a cada release.
Para empresas em crescimento, o custo de montar isso é menor do que um mês de retrabalho. A previsibilidade melhora e a troca de fornecedor vira decisão, não emergência.
Perguntas Frequentes
Se eu paguei pelo sistema, o desenvolvedor é obrigado a entregar o código-fonte?
Não existe uma regra única para todo caso. A resposta depende do contrato e do que foi definido como entregável, mas pagamento, escopo e logs do repositório ajudam a sustentar a exigência e a renegociação.
Posso “tirar do ar” o acesso do desenvolvedor imediatamente?
Sim, quando há risco operacional ou de segurança. Faça isso com registro interno, rotação de senhas e backup, para evitar alegação de que você impediu a entrega ou adulterou evidências.
Ata notarial realmente ajuda em disputa de código?
Sim. Ela ajuda a fixar um estado observável (telas, bloqueios, mensagens e páginas) em uma data, o que reduz discussão sobre alterações posteriores.
Quanto tempo eu tenho para buscar meus direitos na Justiça?
O prazo varia conforme o tipo de pretensão e o enquadramento jurídico do caso. Um advogado precisa classificar o pedido (contratual, indenizatório, autoral) para definir a prescrição aplicável e evitar perda de prazo.
Registrar o software no INPI resolve o problema de autoria?
Não resolve sozinho, mas fortalece a prova de anterioridade e autoria. O Instituto Nacional da Propriedade Industrial (INPI) é útil como camada de evidência, somada a contrato, commits e backups.
Revisado pela equipe técnica de ADVOGADOS GUERRA, Especialistas em escritório de advocacia empresarial especializado em direito tributário, trabalhista e societário em Fortaleza.
Se o seu negócio ficou refém porque o fornecedor reteve o código ou os acessos, uma estratégia bem documentada reduz prejuízos e acelera a retomada. Fale com a ADVOGADOS GUERRA agora mesmo.
Fale com um especialista para recuperar seu código
