Ninguém fica refém: o que perguntar sobre código, infraestrutura e titularidade

Imagine que, amanhã de manhã, o fornecedor do seu sistema avise que vai encerrar as atividades. Quanto tempo a sua operação continua funcionando? Se a resposta honesta é "não sei", vale fazer o exercício completo antes que ele deixe de ser hipotético.

Ficar refém de um fornecedor raramente é resultado de má-fé. Quase sempre é resultado de perguntas que não foram feitas na assinatura. O servidor foi contratado no nome de quem desenvolveu porque era mais rápido. O código ficou no repositório do fornecedor porque ninguém pediu acesso. O contrato não tratou de titularidade porque parecia detalhe. Tudo funciona, até o dia em que a relação muda.

O que você está comprando, de verdade

Um sistema não é uma coisa só. É um conjunto de peças, e cada uma pode estar sob controle de pessoas diferentes:

• Código-fonte: as instruções que fazem o sistema funcionar.
• Infraestrutura: os servidores, o banco de dados, o armazenamento de arquivos.
• Domínio e e-mails: o endereço pelo qual o sistema é acessado.
• Contas de serviços externos: envio de e-mail, armazenamento, assinatura digital, mapas e o que mais o sistema usar.
• Dados: tudo o que a sua operação gravou ao longo dos anos.
• Conhecimento: a documentação que permite a outra pessoa entender e manter o sistema.

Ter "o sistema" só significa algo se você sabe quem controla cada uma dessas peças.

O que diz a lei, em linhas gerais

No Brasil, a Lei 9.609/98, conhecida como Lei do Software, trata da proteção dos programas de computador. O artigo 4º prevê que, salvo estipulação em contrário, os direitos sobre o programa desenvolvido durante a vigência de um contrato de prestação de serviços destinado a esse fim pertencem ao contratante. A mesma lei estabelece que o uso de programa de computador no país é objeto de contrato de licença.

O ponto que importa para o empresário está nas três primeiras palavras: "salvo estipulação em contrário". O contrato pode dispor de outra forma, e muitos dispõem. Por isso, a pergunta não é o que a lei diz em tese, mas o que o seu contrato diz de fato. Este artigo não é orientação jurídica: para avaliar um contrato específico, envolva um advogado de sua confiança.

E mesmo quando a titularidade está clara no papel, ela não garante acesso na prática. Ser dono de um código que está num repositório que você não consegue abrir, rodando num servidor que está no nome de outra pessoa, é uma propriedade difícil de exercer.

Checklist: doze perguntas para qualquer fornecedor

Use estas perguntas antes de assinar, ou agora mesmo, com o fornecedor que você já tem. Peça as respostas por escrito.

Infraestrutura

1. Em nome de quem estão contratados os servidores, o banco de dados e o armazenamento? Quem recebe a fatura?
2. Em nome de quem está registrado o domínio?
3. Minha empresa tem acesso de administrador a essas contas, ou só o fornecedor tem?
4. As contas de serviços externos usados pelo sistema estão no nome de quem?

Código e ambientes

1. Onde fica o código-fonte, e minha empresa tem acesso a ele hoje, não só "quando pedir"?
2. Esse acesso continua valendo se o contrato for encerrado, por qualquer motivo?
3. Existe documentação suficiente para outro desenvolvedor assumir o sistema?
4. O sistema usa algum componente do fornecedor que não é entregue junto, e sem o qual ele não roda?

Titularidade e licença

1. O contrato diz, de forma explícita, de quem são os direitos sobre o código desenvolvido para mim?
2. Se parte do sistema é um núcleo reutilizado pelo fornecedor em outros clientes, qual licença eu tenho sobre essa parte? Ela é perpétua ou depende de eu continuar pagando?

Saída

1. Em que formato recebo meus dados se quiser sair, e em quanto tempo?
2. Se o fornecedor encerrar as atividades amanhã, o que desliga?

Some as respostas que dependem de "o fornecedor faz por mim". Cada uma é um ponto em que a continuidade da sua operação está na mão de outra empresa. O ideal é que essa soma seja zero para as perguntas 1, 2, 3, 5, 6 e 12.

A pergunta que resume as outras onze: se o fornecedor sumir amanhã, o que desliga?

Como ler as respostas

Respostas vagas valem tanto quanto respostas negativas. "O código é seu, claro" sem acesso ao repositório é uma promessa, não uma garantia. "A gente entrega tudo se precisar" sem prazo e formato definidos no contrato é boa vontade, que pode não sobreviver a uma relação desgastada.

Também vale distinguir duas situações legítimas. Há fornecedores que constroem tudo do zero para cada cliente, e há os que usam um núcleo reutilizável configurado para cada um. A segunda opção costuma ser mais rápida e barata, e não há nada de errado nela, desde que a licença sobre esse núcleo esteja escrita e não desapareça quando o contrato terminar.

Independência é uma escolha de contrato

Ninguém assina contrato pensando no fim da relação, mas é justamente por isso que vale pensar nele no começo. Na Ezera, as respostas a essas perguntas são compromissos fixos: a infraestrutura fica no nome do cliente, código e ambientes ficam permanentemente acessíveis e, ao fim do período mínimo, a licença do que foi entregue é perpétua. A infraestrutura está no seu nome e o código sempre esteve acessível. Se a gente encerrar, nada desliga.