Contrato de desenvolvimento de software: como formalizar

Projeto de software que dá errado raramente quebra no código: quebra no combinado. O cliente esperava funcionalidades que não estavam no escopo, o fornecedor entrega e descobre que o cliente se considera dono até das ferramentas usadas no projeto, o prazo escorrega e ninguém sabe quem absorve o custo. O contrato de desenvolvimento de software existe para resolver essas conversas antes que elas custem o projeto, e tem um detalhe que muita empresa ignora: a propriedade do código tem regra legal própria, que decide a disputa quando o contrato silencia.

Neste artigo, você vai entender o que a Lei do Software define, como o modelo de contratação muda o contrato, as cláusulas essenciais e como formalizar tudo digitalmente.

O que diz a Lei do Software

A Lei 9.609/1998, a Lei do Software, protege o programa de computador pelo regime de direitos autorais e traz a regra que mais importa no desenvolvimento sob encomenda: salvo estipulação em contrário, o software desenvolvido sob contrato de prestação de serviços pertence ao contratante, não a quem escreveu o código. É o inverso da regra geral das obras criativas, em que a encomenda não transfere nada automaticamente.

Isso não dispensa a cláusula de propriedade intelectual, pelo contrário. A regra legal cobre o programa encomendado, mas não resolve sozinha o destino das ferramentas próprias do fornecedor, dos componentes reaproveitados de outros projetos nem das bibliotecas de terceiros embutidas na entrega. Quem deixa tudo no implícito descobre o problema na pior hora: na venda da empresa, na auditoria do investidor ou na troca de fornecedor.

Escopo fechado ou ágil: o modelo muda o contrato

Antes das cláusulas, as partes precisam escolher o modelo de contratação, porque ele define como escopo, preço e risco se distribuem:

• Escopo fechado (preço fixo): requisitos detalhados viram anexo do contrato, com cronograma e valor definidos. O risco de estimar mal é do fornecedor; o risco de especificar mal é do cliente. Mudanças de escopo exigem aditivo formal.
• Alocação ou tempo e materiais (modelo ágil): o contrato formaliza a capacidade (equipe, horas, sprints) e a governança (backlog, priorização, aceite por entrega), e o escopo evolui dentro dela. O risco de direção é do cliente, e o contrato precisa dizer como se mede e aprova o que foi feito.

Nenhum é melhor em abstrato. O erro clássico é assinar um contrato de preço fixo e tocar o projeto como ágil: o papel diz uma coisa, a prática outra, e qualquer disputa vira interpretação.

As cláusulas que o contrato precisa prever

1. Escopo e requisitos: o que será desenvolvido, com anexo técnico ou a governança de backlog, conforme o modelo.
2. Entregas e cronograma: marcos, sprints ou fases, com critérios objetivos de conclusão.
3. Propriedade intelectual: de quem é o código novo, o que o fornecedor retém e qual licença cobre o que ele reutiliza.
4. Componentes de terceiros e open source: autorização de uso, responsabilidade pelas licenças e vedação a componentes que contaminem o código do cliente.
5. Confidencialidade e dados: sigilo sobre o negócio do cliente e, se o projeto trata dados pessoais, as obrigações de LGPD entre as partes.
6. Aceite e homologação: prazo e critérios para o cliente testar e aprovar cada entrega, e o efeito do silêncio.
7. Garantia e correção de erros: por quanto tempo o fornecedor corrige defeitos sem custo, e o que é defeito versus nova funcionalidade.
8. Preço e pagamento: valores atrelados a marcos ou medições, com regras de reajuste em contratos longos.
9. Rescisão e transição: como o contrato termina, com entrega de código, documentação, credenciais e período de transição assistida.

Propriedade intelectual: de quem é o código

A cláusula de propriedade intelectual merece atenção de desenho, não só de redação. O padrão saudável separa três camadas. O código novo, escrito para o projeto, fica com o cliente, na linha da regra legal. O código preexistente do fornecedor, frameworks próprios, bibliotecas internas, aceleradores, permanece do fornecedor, com licença de uso perpétua para o cliente na medida do que foi embutido na entrega. E os componentes open source entram mapeados, porque cada licença tem suas condições, e um componente mal escolhido pode impor obrigações ao produto inteiro.

Para quem contrata, a lição é exigir o mapa do que está dentro da entrega. Para quem desenvolve, é proteger o próprio ferramental antes de assinar, o mesmo cuidado que detalhamos na cessão de direitos autorais, onde o software é justamente a exceção legal.

Como formalizar o contrato online

O desenvolvimento de software é uma relação documental em camadas, e todas elas se beneficiam do fluxo digital. A conversa começa com o NDA ainda na fase de proposta; o contrato principal segue no modelo do contrato de prestação de serviços com os anexos técnicos; cada mudança de escopo vira aditivo formal, não um acordo de reunião; e os termos de aceite de cada entrega fecham o ciclo com data provada.

Assinado eletronicamente, esse conjunto ganha o que projetos de software mais precisam em disputa: trilha de auditoria com datas, autenticação de quem aprovou cada entrega e o dossiê completo do projeto, do NDA ao aceite final, arquivado num lugar só. Testemunhas no mesmo envelope reforçam o contrato principal, e o cliente e o fornecedor de cidades diferentes assinam no mesmo dia, não na mesma semana de malote.

Conclusão

O contrato de desenvolvimento de software bem-feito resolve as três disputas clássicas antes de elas existirem: o que será entregue (escopo e aceite), de quem é o resultado (propriedade intelectual em camadas, com a regra da Lei 9.609 como pano de fundo) e o que acontece quando algo muda (aditivos e rescisão com transição). Formalizado digitalmente, do NDA ao aceite de cada entrega, o projeto ganha governança documental na mesma velocidade das sprints.

Quer formalizar contratos de software, NDAs e aditivos no fluxo digital? Conheça os planos da LetsSign ou fale com a nossa equipe.

Perguntas frequentes

De quem é o software desenvolvido sob encomenda?

Pela Lei 9.609/1998, salvo estipulação em contrário, o programa desenvolvido sob contrato de prestação de serviços pertence ao contratante. A cláusula de propriedade intelectual continua necessária para tratar do código preexistente do fornecedor e dos componentes de terceiros.

Qual a diferença entre contrato de escopo fechado e ágil?

No escopo fechado, requisitos, prazo e preço são definidos antes, e mudanças exigem aditivo. No modelo ágil (tempo e materiais), o contrato formaliza equipe, cadência e governança de priorização, e o escopo evolui dentro dessa capacidade, com aceite por entrega.

O que a cláusula de open source precisa dizer?

Que componentes de terceiros só entram na entrega mapeados e com licenças compatíveis com o uso pretendido, definindo quem responde por violações. Licenças open source têm condições diferentes entre si, e um componente inadequado pode impor obrigações ao produto inteiro.

O contrato de desenvolvimento de software pode ser assinado online?

Pode, com validade plena: contrato, NDA, aditivos de escopo e termos de aceite assinados eletronicamente, com autenticação, testemunhas no mesmo envelope e trilha de auditoria provando a data de cada aprovação, exatamente o que projetos longos precisam numa disputa.