Contrato de Desenvolvimento Encerrado Antes da Entrega: De Quem Fica o Código Já Produzido?

Quando um contrato de desenvolvimento termina antes da entrega final, uma das principais dúvidas é saber quem pode utilizar, receber ou continuar o código já produzido. A resposta sobre o código-fonte em contrato encerrado depende das cláusulas negociadas, da finalidade do projeto, das etapas concluídas, dos pagamentos realizados e da origem dos componentes utilizados.

A empresa contratante não se torna necessariamente titular de todo material existente apenas porque financiou parte do projeto. Da mesma forma, o desenvolvedor não pode presumir que poderá reter ou reutilizar livremente tudo o que foi criado. É necessário separar titularidade, posse dos arquivos, licença de uso, obrigação de entrega e remuneração pelo trabalho executado.

De quem fica o código produzido antes do encerramento?

Não existe uma resposta única aplicável a todos os projetos. O primeiro documento a ser analisado é o contrato de desenvolvimento de software, especialmente as cláusulas sobre propriedade intelectual, cessão de direitos, licenciamento, entregas parciais, pagamentos e efeitos da rescisão.

A Lei nº 9.609/1998, conhecida como Lei do Software, estabelece que, salvo estipulação em contrário, os direitos relativos ao programa desenvolvido durante contrato de prestação de serviços podem pertencer ao contratante quando o desenvolvimento estiver previsto na contratação ou decorrer da própria natureza dos encargos assumidos.

Essa regra, entretanto, deve ser aplicada às circunstâncias concretas. É necessário identificar se o objeto contratado era efetivamente a criação daquele software, se o código discutido foi produzido no âmbito do projeto e se existem cláusulas que reservam determinados componentes ao desenvolvedor.

Além disso, ser titular dos direitos patrimoniais não significa necessariamente possuir todos os arquivos, acessos e conhecimentos técnicos necessários para continuar o projeto. A obrigação de entregar repositórios, documentação, credenciais e ambientes precisa ser examinada separadamente.

Titularidade, acesso e licença são questões diferentes

Em contratos de tecnologia, diferentes situações jurídicas costumam ser tratadas como se fossem a mesma coisa. A titularidade corresponde à possibilidade de explorar economicamente o software nos limites legais e contratuais. O acesso ao código representa a disponibilidade material dos arquivos. Já a licença autoriza determinados usos sem necessariamente transferir a titularidade.

Uma empresa pode, por exemplo, receber licença para utilizar um sistema sem adquirir sua propriedade intelectual. Também pode ser titular do código personalizado desenvolvido para o projeto, mas não das bibliotecas, estruturas ou ferramentas preexistentes utilizadas pelo fornecedor.

O contrato deve indicar se existe cessão definitiva, licença exclusiva, licença não exclusiva ou simples autorização limitada. Também deve esclarecer quando os direitos são transferidos: na assinatura, em cada pagamento, após a aprovação de um marco ou somente depois da quitação integral.

Quando essas disposições são vagas, torna-se necessário interpretar o contrato em conjunto com propostas, mensagens, documentos técnicos, comprovantes de pagamento e comportamento mantido pelas partes durante o desenvolvimento.

O pagamento parcial transfere a propriedade do código?

O pagamento de parcelas não transfere automaticamente todos os direitos sobre o software em qualquer situação. O efeito jurídico depende da estrutura contratual. Existem projetos remunerados por horas trabalhadas, por etapas, por funcionalidades aprovadas ou por um preço global condicionado à conclusão.

Se o contrato vincular a transferência de direitos à quitação total, o encerramento antecipado pode produzir uma discussão diferente daquela existente quando cada etapa paga corresponde a uma entrega autônoma. Também é possível que as partes tenham previsto cessão progressiva, pela qual os direitos sobre cada módulo sejam transferidos após sua aprovação e pagamento.

A Lei nº 9.610/1998, que disciplina os direitos autorais, determina que negócios envolvendo esses direitos sejam interpretados restritivamente. A legislação também prevê que a cessão total ou parcial seja realizada por escrito e identifique seu objeto e as condições de exercício quanto a tempo, lugar e preço.

Por isso, comprovantes de pagamento são relevantes, mas devem ser avaliados com o contrato, os critérios de aceite e o que foi efetivamente produzido. O pagamento pode demonstrar a remuneração de uma etapa sem, isoladamente, resolver toda a controvérsia sobre titularidade e entrega.

O código incompleto precisa ser entregue?

A obrigação de entregar código incompleto depende do que foi contratado. Alguns instrumentos determinam que todo material produzido até a data do encerramento seja disponibilizado ao contratante. Outros condicionam a entrega ao pagamento dos valores correspondentes ou preveem apenas a disponibilização de marcos formalmente aprovados.

Também é necessário verificar se o material parcial possui utilidade técnica. Um conjunto de arquivos ainda não testado pode conter erros, dependências não documentadas ou funcionalidades sem condições de uso. A entrega, nesses casos, não deve ser apresentada como se correspondesse a um produto finalizado.

Um termo de encerramento pode registrar o estado do projeto e relacionar:

• funcionalidades concluídas e pendentes;
• versões e ramificações existentes no repositório;
• documentação técnica disponível;
• dependências externas e bibliotecas utilizadas;
• erros conhecidos e testes ainda não executados;
• credenciais, chaves e ambientes que serão transferidos;
• valores pagos, pendentes ou discutidos;
• direitos cedidos e limitações de uso.

Esse registro reduz o risco de o contratante presumir que recebeu um sistema pronto ou de o desenvolvedor ser responsabilizado por intervenções realizadas posteriormente por terceiros.

Código preexistente, bibliotecas e componentes de terceiros

Nem todo conteúdo presente no projeto foi necessariamente criado para o contratante. O desenvolvedor pode ter utilizado estruturas próprias, módulos genéricos, ferramentas internas, componentes de terceiros e bibliotecas de código aberto.

Esses elementos devem ser separados do código desenvolvido especificamente para o projeto. A transferência de direitos sobre a parte personalizada não significa, por si só, a cessão definitiva de ferramentas anteriores pertencentes ao fornecedor.

Bibliotecas de código aberto também possuem licenças próprias. Algumas permitem uso, alteração e distribuição com poucas restrições; outras impõem condições relacionadas à disponibilização do código, atribuição de autoria ou manutenção da mesma licença em obras derivadas. O encerramento do contrato não elimina essas obrigações.

Antes de entregar ou continuar o projeto com outro fornecedor, é recomendável produzir um inventário dos componentes utilizados. Essa análise ajuda a identificar o que pertence ao contratante, o que permanece com o desenvolvedor e o que pode ser utilizado apenas dentro das condições estabelecidas por terceiros.

Como o motivo do encerramento interfere na entrega?

O encerramento pode decorrer de acordo entre as partes, denúncia unilateral permitida pelo contrato, atraso, falta de pagamento, descumprimento técnico ou impossibilidade de continuidade. Cada hipótese pode produzir efeitos diferentes.

O Código Civil prevê que os contratantes devem observar a probidade e a boa-fé durante a celebração e a execução do contrato. A legislação também disciplina o distrato, a resilição unilateral e a resolução decorrente de inadimplemento.

Se o desenvolvimento foi encerrado por falta de pagamento, pode existir controvérsia sobre a exigibilidade da entrega e a possibilidade de suspensão das obrigações. Nos contratos bilaterais, o Código Civil estabelece que uma parte, antes de cumprir sua obrigação, não pode exigir o cumprimento da obrigação correspondente pela outra. A aplicação dessa regra depende da ordem das prestações, dos pagamentos realizados e das cláusulas do instrumento.

Se o término ocorreu por falha do desenvolvedor, o contratante pode discutir o cumprimento da entrega, a resolução do contrato e eventuais prejuízos demonstráveis. Nenhuma dessas consequências deve ser presumida sem a análise das obrigações, das notificações e das provas do descumprimento.

Quais documentos ajudam a definir de quem fica o código?

A apuração não deve ficar limitada ao contrato principal. Projetos de software costumam sofrer mudanças durante a execução, e parte das condições pode estar registrada em documentos complementares.

Devem ser preservados, conforme o caso:

• contrato, anexos, aditivos e propostas comerciais;
• escopo, cronogramas e critérios de aceite;
• comprovantes de pagamento e notas fiscais;
• mensagens, atas de reunião e solicitações de alteração;
• histórico do repositório e registros de autoria dos arquivos;
• relatórios de horas e entregas realizadas;
• documentação técnica e listas de dependências;
• notificações sobre atraso, falhas ou encerramento;
• registros de acesso aos servidores e ambientes.

O histórico do repositório pode ajudar a demonstrar quando determinada parte foi criada, quem participou das alterações e qual era o estágio do projeto no momento do encerramento. Esse histórico, entretanto, deve ser interpretado com os demais documentos, pois a autoria técnica de um arquivo não resolve, isoladamente, a titularidade patrimonial.

Como encerrar o contrato e organizar a transição?

Quando ainda existe possibilidade de diálogo, as partes podem formalizar um distrato ou termo de encerramento. O documento deve evitar expressões genéricas que apenas declarem o término da relação sem resolver o destino dos ativos tecnológicos.

É recomendável definir quais arquivos serão entregues, em qual formato, até qual data e mediante quais condições. Também podem ser tratados o pagamento proporcional, a revogação de acessos, a exclusão ou devolução de dados, a continuidade da confidencialidade e a eventual colaboração durante a transição.

A transferência técnica pode incluir repositórios, documentação de arquitetura, instruções de implantação, banco de dados, chaves de integração e histórico de versões. Senhas pessoais não devem ser simplesmente compartilhadas; quando possível, devem ser criados acessos institucionais ou realizados procedimentos de substituição das credenciais.

Se houver desacordo, notificações formais podem delimitar o que cada parte exige, quais obrigações considera pendentes e quais materiais devem ser preservados. Dependendo dos fatos, pode ser avaliada medida destinada à entrega, preservação ou proteção do código, sem que isso represente garantia de resultado.

Dúvidas frequentes sobre código-fonte em contrato encerrado

Quem pagou pelo desenvolvimento fica automaticamente com o código?

Não necessariamente. O pagamento é relevante, mas a titularidade depende da finalidade da contratação, das cláusulas sobre propriedade intelectual, das etapas pagas e das regras da Lei do Software. Também é preciso distinguir o código personalizado dos componentes preexistentes ou pertencentes a terceiros.

O desenvolvedor pode apagar o código depois da rescisão?

A eliminação do material durante uma controvérsia pode comprometer provas e dificultar a apuração das obrigações. A possibilidade de exclusão depende do contrato, da titularidade, das regras de guarda e das circunstâncias do encerramento. Recomenda-se preservar o conteúdo até que o destino dos arquivos esteja definido.

A empresa pode contratar outro desenvolvedor para terminar o sistema?

Pode ser possível, desde que possua acesso legítimo ao código e autorização para utilizá-lo, modificá-lo e permitir a atuação do novo fornecedor. Devem ser verificadas eventuais limitações contratuais, componentes de terceiros, licenças e obrigações de confidencialidade.

O código precisa estar registrado para ser protegido?

A proteção conferida pela Lei do Software independe de registro. O registro pode servir como elemento documental, mas não substitui o contrato, o histórico do repositório e os demais registros relacionados à criação e à titularidade.

É possível reter o código por falta de pagamento?

A resposta depende da sequência das obrigações, das parcelas vencidas, das cláusulas contratuais e do motivo do encerramento. A retenção não deve ser adotada automaticamente sem verificar se parte do código já foi paga ou se havia obrigação anterior de entrega.

Conclusão

A definição sobre de quem fica o código-fonte em contrato encerrado exige a análise conjunta da Lei do Software, das regras de direitos autorais, do contrato e do modo como o projeto foi executado.

Titularidade, acesso aos arquivos, licença de uso e obrigação de entrega são questões diferentes. Também devem ser separados o código personalizado, os componentes preexistentes do desenvolvedor e as bibliotecas submetidas a licenças de terceiros.

Quando o desenvolvimento termina antes da entrega final, a preservação do repositório, dos documentos técnicos, dos pagamentos e das comunicações ajuda a esclarecer o estágio do projeto. Conforme o caso, pode ser avaliada a formalização de um termo de encerramento, a negociação da entrega parcial ou outra medida adequada aos fatos e às provas disponíveis.