Os dados e o código são seus? O que verificar no contrato

Três perguntas decidem se você contratou um fornecedor ou adquiriu uma dependência: o código desenvolvido é seu?, você consegue exportar seus dados hoje, sozinho? e as contas de infraestrutura estão no CNPJ da sua empresa? Se alguma resposta for negativa ou incerta, encerrar a relação vai custar muito mais do que o valor mensal do contrato. Este texto lista o que verificar. Não é aconselhamento jurídico, as cláusulas devem ser redigidas e revisadas por advogado.

Propriedade do código

No Brasil, programa de computador é protegido pela Lei 9.609/98, com aplicação subsidiária da lei de direitos autorais. O artigo 4º prevê que, salvo estipulação em contrário, os direitos pertencem ao empregador ou contratante quando o desenvolvimento decorre de contrato expressamente destinado a isso.

Duas palavras carregam o risco: "salvo estipulação em contrário" e "expressamente destinado". Se o contrato for genérico de "prestação de serviços de TI", ou tiver uma cláusula discreta reservando os direitos ao fornecedor, a situação muda. Por isso a recomendação prática é não depender da regra supletiva e escrever a cessão de forma explícita.

O que a cláusula precisa deixar claro:

• Cessão total, definitiva e irrevogável dos direitos patrimoniais sobre o que foi desenvolvido para você
• Abrangência: código-fonte, scripts de banco, arquivos de infraestrutura, documentação e artefatos de design
• Ausência de restrição de uso, modificação e sublicenciamento, inclusive por outro fornecedor
• Momento da transferência, o ideal é na entrega e no pagamento de cada etapa, não só no fim

Um ponto legítimo e comum: o fornecedor pode manter componentes genéricos reutilizáveis (bibliotecas internas, esqueletos de projeto). Isso é razoável, desde que esteja listado no contrato e venha com licença perpétua, irrevogável e livre de royalties para você usar e modificar. O que não pode acontecer é a peça central do sistema ficar sob licença que o fornecedor pode revogar.

Bibliotecas de terceiros e licenças abertas

Todo sistema usa código de terceiros. A maior parte tem licença permissiva (MIT, Apache, BSD) e não gera obrigação relevante. Algumas licenças, porém, impõem condições quando o software é distribuído.

Peça ao fornecedor a lista de dependências com as respectivas licenças. Ferramentas geram isso automaticamente. É documento de cinco minutos para quem desenvolve e evita surpresa quando um cliente corporativo ou um investidor pedir.

Os dados

Aqui a posição é mais confortável: os dados operacionais e os dados pessoais tratados são da sua empresa, e sob a LGPD você figura como controlador, com o fornecedor atuando como operador. Mas a titularidade não garante o acesso técnico.

O que precisa estar no contrato:

• Direito de exportar a qualquer momento, sem custo adicional, em formato aberto e documentado (SQL, CSV, JSON), não em formato proprietário nem só em PDF
• Exportação incluindo anexos e arquivos, não apenas as tabelas
• Dicionário de dados ou documentação do modelo, para que a base seja utilizável por outro fornecedor
• Prazo de entrega definido em caso de encerramento, tipicamente de 15 a 30 dias
• Obrigação de eliminação pelo fornecedor após a devolução, com declaração escrita
• Cláusulas de proteção de dados, definindo papéis, finalidades e dever de notificar incidente

Um detalhe que costuma escapar: o contrato deve dizer que a exportação continua disponível mesmo em caso de inadimplência em discussão. Reter dado como forma de pressão comercial é um cenário que ninguém quer testar.

Acessos e infraestrutura

É onde a dependência se instala sem ninguém perceber. Faça o inventário e confira em nome de quem está cada item:

O modelo saudável: as contas são suas, e você concede acesso ao fornecedor. Assim, encerrar a relação é revogar credenciais, não migrar infraestrutura.

Sobre a conta da loja de aplicativos: se o app está publicado sob a conta de desenvolvedor do fornecedor, você não controla nem atualização nem retirada. Transferir depois é possível, mas burocrático e demorado.

Documentação e continuidade

Código sem documentação também é uma forma de dependência. Peça no contrato:

• README com instruções para rodar o projeto do zero em uma máquina limpa
• Documentação das integrações e das regras de negócio não óbvias
• Diagrama do modelo de dados
• Procedimento de publicação e de reversão
• Inventário de serviços de terceiros com custo mensal de cada um

Um teste simples e revelador: peça o repositório e entregue a outro desenvolvedor com a pergunta "você conseguiria rodar isso localmente e entender em uma semana?". A resposta mede o seu risco real.

O teste de portabilidade

Não espere o fim do contrato. Uma vez por ano, faça três pedidos:

1. Cópia completa do repositório, incluindo histórico
2. Dump do banco em formato aberto, com os arquivos anexos
3. Lista de todos os acessos administrativos, confirmando que estão no seu nome

Fornecedor com relação saudável entrega isso em dias, sem desconforto, é o cliente exercendo um direito previsto. Demora, cobrança extra ou resistência são a informação que você foi buscar. É a mesma prática que aplicamos na Retti Tech: o cliente mantém as contas em seu próprio nome desde o primeiro dia do projeto.

Cláusulas para levar ao advogado

• Cessão total e irrevogável dos direitos patrimoniais sobre o desenvolvido
• Lista dos componentes reutilizáveis do fornecedor, com licença perpétua e irrevogável
• Direito de exportação de dados a qualquer tempo, sem custo, em formato aberto
• Prazo e formato de devolução no encerramento, com eliminação posterior comprovada
• Titularidade das contas de infraestrutura no CNPJ do contratante
• Entrega de documentação técnica como condição de aceite de cada etapa
• Cláusulas de proteção de dados e de notificação de incidente
• Confidencialidade recíproca

Nenhum fornecedor sério se incomoda com esses itens. Resistência a qualquer um deles é, por si só, uma resposta útil.