Escrow de código: depósito sem teste pode guardar uma cópia inútil
Escrow de código é a custódia de código-fonte e materiais relacionados por terceiro, com liberação ao beneficiário quando ocorrer gatilho contratual. O mecanismo reduz risco de descontinuidade apenas se o depósito estiver atualizado, completo, verificável e acompanhado dos direitos necessários para uso.
O contrato prevê escrow, mas ninguém verifica o depósito por anos. Quando o fornecedor encerra atividades, a cópia não corresponde à produção e depende de credenciais que nunca foram depositadas.
Por Giovanny Maciel, Sócio-fundador
Escrow de código-fonte é um mecanismo de continuidade: uma cópia do material necessário à manutenção do software fica sob custódia de terceiro e pode ser liberada quando ocorrer um gatilho previamente definido. O valor do arranjo, porém, depende menos da existência do depósito e mais de o que foi depositado, se aquilo funciona e em quais condições poderá ser acessado.
Depósito sem verificação pode guardar um arquivo inútil
Código antigo, sem dependências, documentação ou instruções de build pode cumprir formalmente a obrigação de “entregar uma cópia” e falhar quando a empresa realmente precisa assumir a operação. Por isso, o pacote deve refletir o objetivo: compilar, restaurar, auditar, migrar ou manter.
Em sistemas críticos, a verificação pode conferir versão, integridade, scripts, dependências e capacidade de reprodução em ambiente controlado. O nível de teste deve acompanhar o custo e a criticidade da dependência.
O gatilho precisa ser objetivo o suficiente para funcionar sob crise
Falência, encerramento do serviço, descumprimento grave de suporte ou indisponibilidade prolongada podem aparecer como eventos de liberação, mas cada expressão precisa de critério e prova. “Quando o cliente se sentir inseguro”, por exemplo, cria disputa justamente no momento em que o mecanismo deveria reduzir incerteza.
O Código Civil fornece a base contratual para o desenho das obrigações, e a Lei de Software continua relevante para os direitos sobre o programa. Receber o código por escrow não transfere automaticamente titularidade. A licença de uso após a liberação precisa estar prevista.
Custodiante precisa ter papel e segurança definidos
O terceiro que guarda o material não deveria ser mero endereço de entrega. Contrato de custódia deve tratar confidencialidade, controles de acesso, integridade, responsabilidade por perda e procedimento de verificação. Também é útil prever o que acontece se o próprio custodiante encerrar atividades ou sofrer incidente.
Em produtos com segredos de negócio, a liberação deve entregar ao beneficiário somente o material e os direitos previstos, sem transformar a custódia em acesso permanente durante a vigência normal.
A liberação também deve prever transição de conhecimento. Mesmo um pacote tecnicamente completo pode exigir período de cooperação, documentação adicional ou contato com profissionais autorizados para reduzir o tempo entre o gatilho e a retomada da operação.
Atualização é parte da custódia
Produto muda toda semana; depósito anual pode estar muitos meses atrás da versão crítica. Defina frequência, evento que exige atualização e evidência de que o custodiante recebeu o pacote correto. Se o software depende de serviços externos, documente também o que não pode ser depositado e qual alternativa existe.
Antes de contratar escrow, avalie se acesso controlado ao código-fonte ou uma arquitetura de saída de SaaS resolve o risco de forma mais direta. Escrow é ferramenta específica, não sinônimo de continuidade.
Perguntas frequentes
Escrow transfere a propriedade do software ao cliente?
Não. Custódia e liberação do código não substituem as regras de titularidade e licença. O contrato deve definir quais direitos surgem após o gatilho.
Basta depositar o repositório uma vez?
Em produto atualizado continuamente, não. Frequência de atualização e verificação precisam acompanhar a criticidade e a velocidade de mudança.
Todo SaaS precisa de escrow de código?
Não. Exportação de dados, redundância, transição contratual ou outros mecanismos podem ser mais adequados dependendo do risco e da arquitetura.