Contrato de desenvolvimento de software: cláusulas essenciais que protegem o contratante

Contratos de software sob encomenda movimentam cifras expressivas no mercado de tecnologia, mas costumam silenciar sobre as cláusulas que mais importam. A falta de previsão expressa de cessão de direitos autorais pode manter a titularidade do código com quem o desenvolveu, ainda que o contratante tenha pago o valor integral. A esse risco somam-se lacunas sobre manutenção pós-entrega, prazos de correção de falhas críticas, penalidades por atraso e proteção de dados sigilosos.

Titularidade do código-fonte e a propriedade do que se paga

O ponto mais sensível em uma encomenda de software é definir a quem pertence o resultado. Muitos contratantes assumem que, ao pagar pelo desenvolvimento, tornam-se automaticamente donos do programa. Essa premissa nem sempre se confirma no plano jurídico.

A Lei de Software (Lei 9.609 de 1998) e a Lei de Direitos Autorais (Lei 9.610 de 1998) tratam o programa de computador como obra intelectual protegida. A consequência prática é direta: sem cláusula expressa de cessão, a empresa que contratou pode ficar apenas com uma licença de uso, enquanto a titularidade dos direitos patrimoniais permanece com o desenvolvedor.

Essa distinção entre licenciar e ceder define o futuro do negócio. Quem detém uma licença usa o programa nos limites do que foi autorizado. Quem detém a titularidade pode modificar, revender, sublicenciar e impedir terceiros de explorar o mesmo código.

Cessão de direitos autorais: por que a cláusula precisa ser expressa e detalhada

A cessão de direitos patrimoniais sobre o software exige previsão escrita e específica. Uma redação genérica, do tipo “o contratante terá todos os direitos sobre o produto”, abre espaço para interpretações divergentes e disputas posteriores.

Um contrato bem construído descreve o objeto da cessão com precisão: código-fonte, código-objeto, documentação técnica, bibliotecas próprias desenvolvidas para o projeto e eventuais artefatos auxiliares. Também esclarece se a cessão é total ou parcial, se vale para todo o território nacional e estrangeiro e por qual prazo.

Outro cuidado relevante diz respeito a componentes de terceiros. Boa parte das aplicações modernas incorpora bibliotecas de código aberto, módulos licenciados e serviços externos. O contrato precisa distinguir o que de fato é cedido daquilo que apenas integra a solução sob licença de terceiros, evitando que o contratante acredite ter recebido direitos que o próprio desenvolvedor não poderia transferir.

Convém ainda prever a entrega formal do código-fonte e de credenciais de acesso a repositórios. Sem isso, o contratante pode ter a titularidade no papel, mas depender tecnicamente do desenvolvedor para qualquer evolução do produto.

A Lei de Software (Lei 9.609 de 1998) e a Lei de Direitos Autorais (Lei 9.610 de 1998) tratam o programa de computador como obra intelectual protegida.

Escopo de manutenção e SLA de bugs críticos: o que medir e exigir

Entregue o software, começa a vida real do produto. É nesse momento que a ausência de cláusulas de manutenção cobra seu preço. Falhas aparecem, ambientes mudam, integrações quebram, e o contrato precisa dizer quem responde por isso e em quanto tempo.

O primeiro elemento é a separação entre garantia e manutenção evolutiva. A garantia cobre defeitos do que foi contratado, dentro de um período definido, sem custo adicional. A manutenção evolutiva trata de novas funcionalidades e melhorias, normalmente remuneradas à parte. Misturar os dois conceitos gera atritos e cobranças inesperadas.

O segundo elemento é o acordo de nível de serviço, conhecido pela sigla SLA. Ele estabelece prazos objetivos de resposta e de solução conforme a gravidade do problema. Uma falha que derruba o sistema inteiro não pode ter o mesmo prazo de um ajuste estético.

Uma classificação útil distingue severidades. Falhas críticas paralisam a operação e exigem atendimento imediato. Falhas graves comprometem funções importantes, mas admitem contorno temporário. Falhas leves afetam pontos secundários. Para cada nível, o contrato fixa tempo máximo de resposta e de correção, além das consequências do descumprimento.

Sem essa graduação, o contratante fica refém da boa vontade do fornecedor. Com ela, passa a contar com parâmetros mensuráveis e exigíveis, capazes de sustentar eventual cobrança de penalidades ou rescisão por inadimplemento.

Prazos, penalidades por atraso e confidencialidade de dados

Atrasos na entrega são frequentes em projetos de tecnologia, e o contrato precisa antecipar como tratá-los. A previsão de multa por descumprimento de prazo cumpre dupla função: compensa o contratante pelo prejuízo e desestimula a postergação indefinida do cronograma.

A redação eficiente vincula a penalidade a marcos verificáveis, e não a uma data única e distante. Entregas parciais, homologações intermediárias e aceites por etapa permitem identificar o atraso cedo e acionar a cláusula sem esperar o colapso de todo o projeto.

A confidencialidade merece capítulo próprio. No desenvolvimento sob encomenda, o fornecedor costuma acessar informações estratégicas, bases de dados, regras de negócio e, muitas vezes, dados pessoais de clientes do contratante. A circulação desse conteúdo exige proteção contratual robusta.

A Lei Geral de Proteção de Dados (Lei 13.709 de 2018) reforça essa preocupação. Quando o software trata dados pessoais, o contrato deve definir papéis, responsabilidades e medidas de segurança, além de obrigações de notificação em caso de incidente. A omissão expõe o contratante a sanções administrativas e a pedidos de reparação por titulares de dados.

Cláusulas de confidencialidade bem desenhadas sobrevivem ao término do contrato. Elas estabelecem prazo de vigência da obrigação, hipóteses de exceção, destinação ou destruição das informações após o encerramento e penalidades específicas para a quebra de sigilo, independentemente das perdas e danos cabíveis.

Checklist prático de revisão contratual antes de assinar

Antes de firmar um contrato de software sob encomenda, vale percorrer um roteiro objetivo de verificação. O exame antecipado evita que pontos decisivos fiquem em aberto e reduz o risco de litígio.

• Cessão de direitos autorais prevista de forma expressa, com descrição do objeto, abrangência territorial e prazo.
• Entrega formal do código-fonte, da documentação e das credenciais de repositórios e ambientes.
• Distinção clara entre componentes próprios cedidos e bibliotecas de terceiros sob licença externa.
• Separação entre período de garantia e manutenção evolutiva remunerada.
• Acordo de nível de serviço com severidades graduadas e prazos objetivos de resposta e solução.
• Penalidades por atraso vinculadas a marcos verificáveis, e não a uma data final isolada.
• Cláusula de confidencialidade com vigência pós-contratual e destinação das informações.
• Tratamento de dados pessoais alinhado à legislação de proteção de dados, com papéis definidos.
• Hipóteses de rescisão, consequências e regras de transição para outro fornecedor.

Esse roteiro não substitui a análise individual de cada caso, mas funciona como filtro inicial. Contratos que falham em vários desses itens tendem a transferir risco e poder para o desenvolvedor, em detrimento de quem investe no produto.

A revisão jurídica especializada, feita antes da assinatura, costuma custar uma fração do que se gasta para resolver um conflito depois. Quando o software se torna ativo central da operação, cada cláusula negligenciada vira um ponto de vulnerabilidade.

As informações deste artigo são de caráter informativo e não substituem consulta jurídica individualizada.