Desenvolvedor Não Entregou o Código-Fonte: O Que Fazer?

Quando o desenvolvedor não entregou o código-fonte, a primeira providência é verificar o que foi efetivamente contratado. O pagamento pelo desenvolvimento não significa, em todas as situações, que o contratante receberá automaticamente o código, a titularidade integral do software ou liberdade irrestrita para modificá-lo.

A resposta depende do contrato, da proposta comercial, do modelo de desenvolvimento, da origem dos componentes utilizados e das regras sobre propriedade intelectual. Também é necessário distinguir a entrega do código-fonte da licença de uso, da cessão de direitos e do acesso ao repositório do projeto.

A falta de entrega do código-fonte é sempre descumprimento contratual?

Não. A ausência de entrega somente representará descumprimento quando o desenvolvedor tiver assumido essa obrigação ou quando ela puder ser juridicamente identificada a partir da natureza da contratação, dos documentos e das circunstâncias do projeto.

Em um software disponibilizado como serviço, por exemplo, o cliente normalmente recebe acesso às funcionalidades, sem adquirir o código-fonte. Em uma licença de programa padronizado, o titular também pode autorizar apenas o uso da solução, preservando para si a tecnologia e o direito de realizar alterações.

A situação pode ser diferente quando uma empresa contrata o desenvolvimento personalizado de um sistema e os documentos preveem a entrega do repositório, da documentação técnica ou dos arquivos necessários à manutenção. Nesse caso, a recusa injustificada pode caracterizar inadimplemento, conforme o conteúdo da obrigação assumida.

Por isso, antes de notificar o desenvolvedor ou adotar uma medida judicial, é necessário identificar se a entrega estava incluída no objeto do contrato e quais materiais deveriam acompanhá-la.

Entrega do código-fonte, titularidade e licença são conceitos diferentes

A posse de uma cópia do código-fonte não é sinônimo de titularidade sobre o software. Da mesma forma, ser titular dos direitos patrimoniais não significa necessariamente possuir todas as credenciais, versões, dependências e documentos técnicos necessários para colocar o sistema em funcionamento.

A Lei nº 9.609/1998, conhecida como Lei do Software, protege juridicamente os programas de computador. Seu artigo 4º estabelece regras sobre a titularidade dos direitos relativos ao programa desenvolvido durante contrato de trabalho, prestação de serviços ou vínculo semelhante, ressalvada a possibilidade de estipulação contratual em sentido diferente.

A aplicação dessa regra exige atenção ao objeto da contratação. Deve-se verificar se o desenvolvimento era expressamente previsto, se decorria da natureza das atividades contratadas e se foram utilizados recursos, tecnologias ou componentes preexistentes do fornecedor.

É comum que um projeto reúna elementos com titulares diferentes. O contratante pode possuir direitos sobre módulos personalizados, enquanto o desenvolvedor conserva direitos sobre bibliotecas, estruturas genéricas, ferramentas próprias ou componentes criados antes da contratação. Também podem existir elementos de terceiros e softwares de código aberto sujeitos a licenças específicas.

Assim, a análise deve separar pelo menos quatro situações:

• licença para utilizar o software;
• entrega de uma cópia do código-fonte;
• acesso e controle do repositório de desenvolvimento;
• cessão total ou parcial dos direitos patrimoniais sobre o programa.

Essas situações podem coexistir, mas uma não decorre automaticamente da outra.

O que deve ser verificado no contrato de desenvolvimento?

A análise deve começar pelo contrato principal, mas não deve se limitar a ele. Propostas, mensagens, anexos técnicos, ordens de serviço, apresentações comerciais e registros de reuniões podem ajudar a identificar o escopo prometido.

É importante verificar se os documentos tratam de:

• entrega do código-fonte ao final de cada etapa ou somente após a quitação;
• titularidade dos módulos personalizados;
• uso de componentes anteriores do desenvolvedor;
• criação e administração do repositório;
• documentação da arquitetura e das integrações;
• credenciais de hospedagem, banco de dados, domínio e serviços externos;
• critérios de teste, homologação e aceite;
• possibilidade de manutenção por outros profissionais;
• consequências do encerramento antecipado do contrato.

Também deve ser verificado se o contratante cumpriu as próprias obrigações, como pagamento das etapas vencidas, fornecimento de informações, aprovação de protótipos e disponibilização de acessos necessários. Nos contratos bilaterais, o artigo 476 do Código Civil prevê que uma parte não pode exigir o cumprimento da outra antes de cumprir sua própria obrigação.

Uma cobrança pendente não autoriza, em qualquer circunstância, a retenção definitiva de materiais pertencentes ao contratante. Contudo, o inadimplemento do cliente pode influenciar a exigibilidade da entrega, especialmente quando o contrato relaciona expressamente a liberação do código ao pagamento de determinada etapa.

Quais provas devem ser preservadas?

Quando o desenvolvedor não entregou o código-fonte, a preservação das provas deve ocorrer antes que contas sejam desativadas, mensagens sejam apagadas ou acessos deixem de funcionar. O objetivo é demonstrar o que foi contratado, quanto foi pago, quais entregas foram realizadas e quais materiais continuam sob controle do fornecedor.

Podem ser relevantes:

• contrato, aditivos, proposta e anexos técnicos;
• comprovantes de pagamento e notas fiscais;
• mensagens e e-mails sobre a entrega do código;
• cronogramas, relatórios e apresentações do projeto;
• protótipos, telas, versões de teste e arquivos recebidos;
• registros de acesso ao repositório e histórico de alterações;
• credenciais de hospedagem, domínio, banco de dados e serviços em nuvem;
• comunicações de recusa, condicionamento ou interrupção do projeto.

Uma avaliação técnica independente pode ajudar a identificar o que foi efetivamente entregue. Nem sempre um conjunto de arquivos corresponde a um código completo e utilizável. Podem faltar dependências, instruções de compilação, variáveis de ambiente, esquemas do banco de dados, chaves, documentação ou versões atualizadas.

Quando houver risco de perda da prova, pode ser avaliada a produção antecipada prevista no artigo 381 do Código de Processo Civil. A necessidade dessa medida depende da urgência, da relevância das informações e da possibilidade concreta de desaparecimento ou alteração dos registros.

Notificação extrajudicial e tentativa de solução

Depois de organizar os documentos, pode ser adequada uma notificação extrajudicial. A comunicação deve individualizar a obrigação discutida, indicar os materiais pendentes e estabelecer prazo compatível para resposta ou regularização.

Em vez de solicitar genericamente “todo o sistema”, a notificação pode especificar, conforme o contrato:

• repositório e histórico das versões;
• arquivos do código-fonte e scripts de implantação;
• documentação da arquitetura e das APIs;
• estrutura e cópia do banco de dados;
• credenciais administradas em nome do projeto;
• lista de bibliotecas, dependências e licenças utilizadas;
• instruções necessárias para instalação e continuidade.

A notificação também pode propor uma entrega assistida, com conferência técnica, alteração de senhas e registro dos itens transferidos. Em alguns casos, a divergência decorre da falta de definição sobre o formato da entrega ou sobre componentes que o desenvolvedor entende serem de sua propriedade.

Uma solução negociada pode incluir entrega parcial, licença sobre componentes preexistentes, depósito do código em ambiente neutro, quitação de etapa incontroversa ou apoio temporário para migração. A composição deve registrar os direitos de cada parte e evitar que a continuidade do sistema dependa de promessas informais.

Quais medidas judiciais podem ser avaliadas?

Quando a solução extrajudicial não for suficiente, a medida judicial dependerá do direito demonstrado e do objetivo do contratante. Pode ser discutido o cumprimento da obrigação, a entrega de materiais, a exibição de documentos, a resolução do contrato ou a reparação de prejuízos comprovados.

O artigo 475 do Código Civil permite que a parte prejudicada pelo inadimplemento peça a resolução do contrato ou prefira exigir seu cumprimento, sem afastar a análise de eventuais perdas e danos. O artigo 389 disciplina consequências do descumprimento obrigacional, enquanto o artigo 422 exige que os contratantes observem a probidade e a boa-fé durante a execução do negócio.

Se o contrato estabelecer a entrega do código, poderá ser avaliado pedido de tutela específica da obrigação. O artigo 497 do Código de Processo Civil prevê que, nas obrigações de fazer ou não fazer, o juiz poderá conceder tutela específica ou determinar providências que assegurem resultado prático equivalente.

Em situações urgentes, o artigo 300 do mesmo Código admite tutela de urgência quando existirem elementos que indiquem a probabilidade do direito e perigo de dano ou risco ao resultado útil do processo. Dependendo do caso, pode ser solicitado o depósito do código, a preservação do repositório, a manutenção temporária do sistema ou a entrega de credenciais essenciais.

A concessão dessas medidas não é automática. É necessário apresentar documentos capazes de demonstrar a obrigação e explicar concretamente o risco de paralisação, exclusão de arquivos, perda de dados ou comprometimento da atividade empresarial.

Se houver dúvida sobre os materiais existentes, os artigos 396 a 400 do Código de Processo Civil também disciplinam a exibição judicial de documento ou coisa. A pertinência do procedimento depende da identificação do objeto procurado e da demonstração de que ele está sob controle da outra parte.

O artigo 11 da Lei do Software obriga toda entrega de código?

Não. O artigo 11 da Lei nº 9.609/1998 possui aplicação específica aos contratos de transferência de tecnologia de programa de computador levados a registro perante o Instituto Nacional da Propriedade Industrial. Nessa hipótese, a lei exige documentação completa, incluindo código-fonte comentado e informações técnicas necessárias à absorção da tecnologia.

Essa disposição não cria uma obrigação geral e automática de entregar código-fonte em toda contratação de software. Projetos de desenvolvimento, licenciamento, manutenção, plataforma SaaS e transferência de tecnologia possuem estruturas jurídicas diferentes.

A existência do direito à entrega deve ser apurada a partir do tipo de negócio, da legislação aplicável e dos documentos firmados. Utilizar isoladamente o artigo 11 para qualquer contrato de desenvolvimento pode conduzir a uma conclusão incompatível com o alcance da norma.

Dados, credenciais e continuidade do sistema

Mesmo quando houver controvérsia sobre a titularidade do código, outros ativos podem pertencer claramente ao contratante. É o caso de domínio registrado em seu nome, banco de dados com informações de sua operação, contas de serviços contratadas diretamente e conteúdos fornecidos para o projeto.

Por isso, a discussão não deve ficar limitada aos arquivos de programação. É necessário mapear quem controla hospedagem, banco de dados, contas de nuvem, certificados, integrações, lojas de aplicativos, ferramentas de análise e chaves de acesso.

Quando o sistema trata dados pessoais, a transferência ou recuperação dessas informações também deve observar a Lei Geral de Proteção de Dados Pessoais. A disputa contratual não elimina os deveres relacionados à segurança, confidencialidade, finalidade e controle de acesso.

A entrega do código sem instruções de implantação ou sem acesso aos ambientes pode ser insuficiente para assegurar a continuidade. Uma avaliação técnica pode indicar quais materiais são necessários para que outro profissional compreenda, execute e mantenha o projeto.

Como prevenir a retenção do código-fonte?

A prevenção começa antes do desenvolvimento. O contrato deve indicar quem será titular de cada componente, o que será entregue, quando ocorrerão as entregas e quais materiais deverão acompanhar o código.

Uma prática possível é manter o repositório em conta administrada pelo contratante, concedendo ao desenvolvedor as permissões necessárias. Outra alternativa é exigir cópias periódicas, documentação atualizada ou depósito condicionado do código, conhecido como escrow, com hipóteses objetivas de liberação.