Contrato de desenvolvimento de software: escopo, aceite, propriedade intelectual e riscos de entrega

Entenda o problema antes de contratar ou iniciar o projeto

O erro mais comum é tratar desenvolvimento de software como compra de produto pronto. Em um produto pronto, o cliente escolhe algo já existente e aceita as funcionalidades disponíveis. No desenvolvimento sob encomenda, o produto nasce de requisitos, reuniões, escolhas técnicas, validações e ajustes sucessivos. Se o contrato não organiza esse processo, cada parte pode criar uma expectativa diferente sobre o resultado final.

Para o contratante, o risco é pagar por um sistema que não atende à operação, depende excessivamente do fornecedor, não possui documentação suficiente ou não pode ser transferido a outra equipe com segurança. Para o desenvolvedor, o risco é assumir obrigações abertas, receber solicitações ilimitadas, entregar funcionalidades não previstas e enfrentar recusa de pagamento por critérios subjetivos.

Por isso, a discussão jurídica deve começar antes da assinatura. É importante definir se o projeto será fechado, com escopo rígido e preço determinado, ou se seguirá metodologia ágil, com ciclos de entrega, backlog, priorização e orçamento por etapa. Ambos os modelos podem funcionar, mas exigem contratos diferentes. O problema não é usar metodologia flexível. O problema é usar linguagem aberta sem definir governança, responsabilidades e limites.

Escopo é mais do que uma lista de funcionalidades

O escopo deve indicar objetivo do sistema, módulos, perfis de usuário, integrações, ambientes, requisitos de segurança, critérios mínimos de desempenho, telas relevantes, limitações técnicas e premissas de negócio. Também deve informar o que não está incluído, como hospedagem, suporte contínuo, criação de conteúdo, compra de licenças de terceiros, migração de dados antigos, treinamento presencial ou alterações solicitadas depois do aceite.

Quais direitos podem estar envolvidos

O contrato de software envolve, em primeiro lugar, obrigações contratuais. O Código Civil permite que as partes organizem obrigações, preço, prazo, responsabilidade, alocação de riscos e consequências do descumprimento, desde que respeitados os limites legais. A boa fé contratual exige cooperação, informação adequada e conduta coerente durante a execução.

Também há direitos de propriedade intelectual. A Lei 9.609 de 1998 estabelece que o programa de computador recebe proteção semelhante à conferida às obras literárias pela legislação autoral, observadas as regras próprias da Lei de Software. Ela também prevê que a proteção independe de registro. Isso significa que o simples pagamento pelo desenvolvimento não resolve, sozinho, todos os aspectos de titularidade, uso, cessão, licenciamento, exclusividade e reutilização de componentes.

A Lei 9.610 de 1998 reforça um ponto importante: negócios jurídicos sobre direitos autorais são interpretados restritivamente. Em termos práticos, se a empresa deseja adquirir direitos amplos sobre o código, documentação, telas, estrutura, banco de dados e componentes desenvolvidos especificamente para o projeto, essa transferência precisa estar clara. Se o fornecedor pretende manter bibliotecas próprias, ferramentas internas e conhecimento prévio, isso também deve ser separado no contrato.

Quando o software trata dados pessoais, a LGPD precisa ser considerada. O contrato deve identificar papéis, finalidades, medidas de segurança, responsabilidades por incidentes, regras de acesso, descarte, subcontratação e eventual atuação de operadores. Se o sistema funciona na internet, o Marco Civil da Internet também pode ser relevante para temas como registros de acesso, segurança, privacidade e responsabilidade conforme o modelo de aplicação.

Nem tudo que está no projeto pertence automaticamente ao cliente

É comum que o projeto use componentes de código aberto, frameworks, bibliotecas licenciadas, APIs de terceiros, serviços em nuvem e módulos reaproveitados pelo fornecedor. O contrato deve diferenciar o que é exclusivo do cliente, o que é licenciado, o que pertence ao fornecedor e o que depende de licença externa. Essa separação evita conflito sobre uso futuro, manutenção e comercialização do produto.

Documentos e provas que costumam fazer diferença

Em conflitos sobre software, a prova não se limita ao contrato assinado. Muitas discussões dependem de mensagens, atas de reunião, ordens de serviço, histórico de tarefas, repositório de código, registros de deploy, chamados de suporte, vídeos de demonstração, relatórios de teste e documentos de aceite. Por isso, a governança documental precisa ser planejada desde o início.

• proposta comercial com versão, data, preço e premissas do projeto
• contrato principal e anexos de escopo técnico
• documento de requisitos funcionais e requisitos não funcionais
• cronograma por etapas, marcos de pagamento e responsáveis por validação
• registro de solicitações de mudança e aprovação de orçamento adicional
• atas de reunião e decisões sobre prioridade de funcionalidades
• relatórios de teste, homologação e correção de erros
• termos de aceite parcial e aceite final
• comprovantes de entrega de código, credenciais, documentação e ambientes
• política de segurança, matriz de acesso e registro de tratamento de dados, quando aplicável

Esses documentos reduzem a dependência de lembranças e mensagens soltas. Se uma funcionalidade foi retirada do projeto para caber no orçamento, isso deve constar por escrito. Se a entrega depende de acesso fornecido pelo cliente, a falta desse acesso precisa ser registrada. Se uma mudança altera prazo ou preço, a aprovação deve ser documentada antes da execução.

Aceite precisa ter critério objetivo

O aceite é um dos pontos mais sensíveis. O contrato deve prever como o cliente testará cada entrega, qual prazo terá para apontar falhas, como serão classificadas falhas críticas e falhas menores, quando a entrega será considerada aprovada e quais efeitos decorrem do aceite. Sem esse procedimento, o projeto pode ficar em homologação indefinida, com pagamentos suspensos e equipe alocada sem previsibilidade.

Cláusulas essenciais em contrato de desenvolvimento de software

Embora cada projeto exija adaptação, algumas cláusulas aparecem com frequência em contratos bem estruturados. A primeira é a definição do objeto. Ela deve explicar se o fornecedor desenvolverá software novo, customizará plataforma existente, integrará sistemas, criará aplicativo, manterá código legado ou combinará várias atividades.

A segunda é o escopo. O escopo deve vir em anexo técnico, com linguagem compreensível para a equipe jurídica e para a equipe técnica. Ele deve conter funcionalidades, entregáveis, limitações, premissas e dependências. Quando o projeto for ágil, o contrato pode prever backlog inicial, ritos de priorização, sprints, critérios de aceite por ciclo e forma de aprovar mudanças.

A terceira é a propriedade intelectual. O contrato deve dizer se haverá cessão dos direitos patrimoniais sobre o que for desenvolvido, licença de uso, exclusividade, limitação territorial, limitação temporal, possibilidade de sublicença, autorização para alteração do código e uso posterior por outras empresas do mesmo grupo. Também deve preservar o que for pré existente do fornecedor ou de terceiros.

A quarta é a cláusula de confidencialidade. Projetos de software frequentemente expõem dados comerciais, fluxos internos, estratégia de produto, credenciais, documentos financeiros, bases de clientes e informações de segurança. O contrato deve definir informações protegidas, exceções, prazo de sigilo, cuidados mínimos e consequências do uso indevido.

A quinta é a responsabilidade por suporte, garantia e manutenção. Corrigir erro de entrega não é a mesma coisa que evoluir o produto. Suporte operacional também é diferente de desenvolvimento de novas funções. A falta dessa separação gera discussão sobre cobranças adicionais, prazo de resposta, disponibilidade da equipe e obrigação de corrigir problemas causados por alterações externas.

Erros comuns que geram conflitos

Um erro recorrente é contratar por preço fechado sem escopo suficientemente fechado. O cliente espera flexibilidade ampla, enquanto o fornecedor calcula esforço com base em premissas limitadas. Quando surgem novas necessidades, a relação se desgasta porque cada parte acredita que a outra está descumprindo o combinado.

Outro erro é não prever gestão de mudanças. Em tecnologia, mudanças são normais. O que precisa ser controlado é o impacto de cada mudança em prazo, custo, arquitetura, segurança e prioridade. Um formulário simples de solicitação e aprovação pode evitar meses de discussão.

Também é comum esquecer dependências externas. Integrações com bancos, plataformas de pagamento, sistemas públicos, redes sociais, marketplaces, provedores de autenticação e serviços de mensageria podem mudar regras, limitar acesso ou apresentar instabilidade. O contrato deve indicar quais riscos são do projeto e quais dependem de terceiros fora do controle do fornecedor.

Há ainda o erro de não tratar dados pessoais. Se o software coletará cadastro, localização, histórico de consumo, dados de saúde, dados de crianças, biometria ou informações financeiras, a avaliação jurídica deve ocorrer antes da construção. Privacidade não deve ser adicionada apenas no final, porque decisões de arquitetura podem afetar minimização, segurança, logs, consentimento, bases legais e retenção.

Entrega sem documentação cria dependência perigosa

Mesmo quando o sistema funciona, a falta de documentação técnica e operacional pode prender o cliente a um único fornecedor. O contrato deve indicar quais materiais serão entregues, como manual, instruções de instalação, descrição de ambientes, credenciais, documentação de API, mapa de banco de dados e orientações de manutenção.

Caminhos possíveis para reduzir riscos

Antes de assinar, as partes devem transformar expectativas em documentos. A empresa contratante precisa explicar problema de negócio, prioridade e orçamento. O fornecedor precisa indicar premissas, limitações, tecnologias usadas, dependências e riscos conhecidos. O contrato deve amarrar essas informações em linguagem clara.

1. definir objeto, escopo e entregáveis com anexos técnicos versionados
2. separar desenvolvimento, suporte, manutenção corretiva e evolução futura
3. criar procedimento de aceite com prazo de homologação e critérios objetivos
4. regular propriedade intelectual, licenças de terceiros e componentes pré existentes
5. prever gestão de mudanças, orçamento adicional e reprogramação de prazo
6. documentar obrigações de segurança, confidencialidade e proteção de dados
7. definir forma de rescisão, transição, entrega de documentação e continuidade do serviço

Em projetos relevantes, também é recomendável prever comitê de acompanhamento, responsáveis nomeados, periodicidade de reuniões, registro de decisões e mecanismo de resolução de impasses. A tecnologia muda durante o projeto, mas a governança contratual precisa dar previsibilidade para mudanças legítimas.

Quando procurar orientação jurídica

A orientação jurídica é recomendável antes da assinatura, principalmente quando o software será essencial para a operação, quando envolver dados pessoais, quando houver investimento significativo ou quando o cliente pretende explorar comercialmente a plataforma depois da entrega. Nesses casos, a revisão contratual deve ocorrer junto com a análise técnica do projeto.

Também é importante buscar apoio quando o contrato já foi assinado e surgiram divergências sobre prazo, escopo, qualidade, pagamento, aceite ou titularidade do código. A análise dos documentos pode indicar se há inadimplemento, necessidade de notificação, renegociação, produção de prova, rescisão organizada ou medida judicial em situação específica.

Para fornecedores de tecnologia, a prevenção também é relevante. Um contrato bem escrito reduz pedidos ilimitados, organiza cobrança por mudança de escopo, protege componentes próprios e melhora a prova de entrega. Para contratantes, ele ajuda a evitar dependência excessiva, ausência de documentação e disputa sobre propriedade intelectual.

Perguntas frequentes

Quem fica dono do software desenvolvido sob encomenda?

Depende do contrato. O pagamento pelo desenvolvimento não elimina a necessidade de cláusula clara sobre cessão, licença, exclusividade, componentes pré existentes e materiais de terceiros. A interpretação de negócios sobre direitos autorais tende a ser restritiva.

O registro do software é obrigatório para proteção?

A Lei 9.609 de 1998 prevê que a proteção dos direitos relativos a programa de computador independe de registro. Ainda assim, o registro pode ter utilidade probatória em algumas situações, a depender da estratégia e dos documentos disponíveis.

O que deve constar no aceite da entrega?

O aceite deve indicar entrega avaliada, versão, critérios de teste, prazo de homologação, falhas identificadas, correções pendentes e consequência da aprovação. Também pode prever aceite parcial por etapa, especialmente em projetos longos.

Manutenção está incluída no desenvolvimento?

Não necessariamente. O contrato deve separar correção de erros da entrega, suporte operacional, manutenção preventiva, atualização de segurança e evolução com novas funcionalidades. Cada modalidade pode ter prazo e preço próprios.

O contrato precisa tratar LGPD?

Sim, quando o software envolve tratamento de dados pessoais. O contrato deve abordar finalidade, segurança, acesso, responsabilidades, subcontratação, incidentes, descarte e documentos que comprovem conformidade.

Como o escritório pode ajudar

O contrato de desenvolvimento de software exige leitura jurídica e compreensão prática do projeto. A análise deve conectar escopo, cronograma, aceite, propriedade intelectual, dados pessoais, segurança, confidencialidade, suporte e rescisão. Quando esses pontos são tratados antes da execução, as partes reduzem riscos de conflito e ganham previsibilidade.

O escritório pode auxiliar empresas, desenvolvedores, startups e prestadores de tecnologia na elaboração, revisão e negociação de contratos digitais, com foco em documentação clara, proteção de ativos e organização das responsabilidades de cada parte.

Se você enfrenta uma situação semelhante, o Cardoso Advogados Associados pode analisar os documentos, esclarecer os riscos e indicar os caminhos jurídicos possíveis com segurança e responsabilidade.

Você também pode falar com a equipe pela página de contato para avaliação dos documentos e orientação sobre os próximos passos.