Contrato de desenvolvimento de software: empreitada, cessão de direitos e modelo

Um projeto de software raramente dá errado por causa do código. Dá errado porque ninguém escreveu o que significa "pronto" nem de quem será o resultado. O cliente acha que comprou um programa, o desenvolvedor acha que vendeu horas de trabalho, e a fatura final cai no meio dos dois mal-entendidos.

O contrato de desenvolvimento de software resolve esses pontos antes de existir o primeiro commit: o que será construído, como se verifica que está pronto, quanto custa e a quem pertencem os direitos. No Brasil, ele costuma se enquadrar na empreitada do Código Civil: o empreiteiro pode contribuir para a obra só com seu trabalho ou também com os materiais (art. 610), e o dono é obrigado a receber a obra concluída de acordo com o ajuste (art. 615). O contrato existe sem forma especial, mas dois assuntos pedem papel: provar o que foi prometido e ceder os direitos autorais, porque a Lei 9.610/98 só admite a transmissão total e definitiva dos direitos por estipulação contratual escrita (art. 49, II).

Este guia se concentra nas duas armadilhas que os modelos traduzidos do inglês costumam errar: a titularidade do código, que no Brasil tem uma regra própria na Lei do Software, e o aceite do trabalho, de que a lei trata pouco. Passa também pelos tipos de contrato, oito cláusulas que não convém deixar em branco, um modelo, o preenchimento e a assinatura online. Para a diferença entre contrato e acordo, veja nosso artigo sobre contrato e acordo; para o método geral, como fazer um contrato.

O contrato de desenvolvimento de software é o acordo entre um cliente e um desenvolvedor (autônomo, software house ou consultoria) para construir um programa: um aplicativo web ou mobile, uma integração, uma ferramenta interna. Na prática aparece também como contrato de desenvolvimento de sistema, de aplicativo ou de site e, quando o prestador é uma empresa especializada, como contrato de software house. Ele fixa o escopo, as entregas, o preço, o cronograma, os direitos sobre o código, a confidencialidade e a forma de sair do acordo.

Não é uma proposta comercial, nem uma especificação, nem uma conversa de WhatsApp que confirma o pedido. Uma proposta aceita pode bastar para formar o contrato, mas raramente diz quem é o titular do código, como se verifica a entrega ou o que acontece se o projeto parar no meio. É esse silêncio que o contrato preenche. Se houver litígio, é o documento que o juiz vai ler.

O que o contrato cobre

Um contrato sério trata, no mínimo, de:

• Escopo e entregas: o que será construído, com detalhe suficiente para um terceiro dizer se foi entregue
• Preço e marcos: preço total, cronograma de pagamentos e o fato que dispara cada pagamento
• Cessão de direitos: de quem é o código depois de escrito, e sobre o quê exatamente
• A confidencialidade, isto é, o que cada parte precisa manter reservado
• Aceite: como o cliente verifica que o software atende ao pedido
• A garantia: o que o desenvolvedor corrige e por quanto tempo
• Rescisão e responsabilidade: como sair, o que se paga pelo trabalho feito e até onde cada um responde

Muita gente confunde esse contrato com o documento de requisitos. Há sobreposição, mas não são a mesma coisa: o documento de requisitos descreve o produto, o contrato descreve a relação e remete a ele como anexo.

Sempre que alguém paga você para construir um software, ou que você paga alguém para fazer isso. Seja um freelancer por duas semanas ou uma software house por doze meses de produto: muda a escala, não a necessidade de deixar por escrito.

Você precisa de contrato quando:

• terceiriza o desenvolvimento, sobretudo para uma equipe remota ou de outro país, onde a lei aplicável deixa de ser óbvia
• o software é sob medida: quanto mais específico, mais pesa a pergunta "de quem é?"
• o projeto avança por fases e cada pagamento depende de um aceite por escrito
• dados pessoais passam pelo projeto, o que pede regras de tratamento: a LGPD diz que o operador deve tratar os dados segundo as instruções do controlador (art. 39)
• o desenvolvedor reaproveita código que já tinha ou bibliotecas de código aberto
• o desenvolvedor é autônomo ou uma empresa pequena: sem estipulação escrita, a cessão dura no máximo cinco anos e só vale no país onde o contrato foi firmado (art. 49 da Lei 9.610/98)

Dá para dispensar o contrato? Quase nunca. Até uma tarefa de três dias merece uma página que diga o quê, quanto, quando e de quem é o resultado. Leva uma hora. Um mal-entendido num projeto "simples" custa muito mais.

Não existe um contrato único para todos os projetos, e quem diz o contrário está vendendo alguma coisa. A estrutura precisa acompanhar a forma como o projeto é precificado e delimitado; se não, cria incentivos que jogam contra um bom resultado.

Preço fechado

O desenvolvedor se compromete com um escopo e um preço total, e você sabe quanto vai pagar. Tudo depende de o escopo estar bem descrito: se for vago, cada parte descobre no caminho que não entendia a mesma coisa. O Código Civil traz regras úteis para esse formato. Sem estipulação em contrário, o empreiteiro que executa a obra segundo plano aceito não pode exigir acréscimo de preço, mesmo que o projeto seja alterado, a não ser que a mudança decorra de instruções escritas do dono da obra (art. 619). E o dono pode suspender a obra mesmo depois de iniciada, desde que pague as despesas e os lucros dos serviços já feitos, mais uma indenização razoável (art. 623). Vale fixar esses valores no contrato em vez de deixar para o juiz.

Horas

Você paga o tempo trabalhado por um valor combinado, e a relação se aproxima da prestação de serviço regida pelo art. 593 do Código Civil. É a escolha lógica quando o produto se descobre no caminho. O reverso é não haver teto natural: um orçamento máximo e uma revisão mensal reduzem o risco.

Equipe dedicada

Para um produto que vive anos, a equipe dedicada define as regras de uma relação contínua em vez de uma entrega única. Os contratos das empresas de TI costumam passar por esse modelo com parceiros de terceirização. Atenção: um desenvolvedor autônomo integrado à sua equipe, com seu horário e sob suas ordens, pode ter o vínculo reconhecido como emprego, como explica nosso artigo sobre prestador independente e empregado.

Projetos ágeis

O desenvolvimento ágil combina mal com preço fechado sobre um escopo que muda a cada sprint. A saída é cobrar por sprint ou por lote, cobrar por horas com teto, ou manter o escopo variável com possibilidade de sair ao fim de cada sprint. O aceite passa a valer para cada incremento, e o contrato precisa dizer isso.

Contrato-mãe e SOW

Para uma relação longa, separa-se o contrato-mãe (direitos, confidencialidade, responsabilidade, lei aplicável) dos SOW, ou ordens de serviço, que fixam as entregas, os prazos e o preço de cada projeto.

Nem todas as cláusulas pesam igual. Estas são as oito em que um contrato se ganha ou se perde, porque uma redação vaga gera litígios de verdade.

1. Escopo e entregas

Descreva o que será construído com detalhe suficiente para alguém alheio ao projeto dizer se foi entregue: funções, restrições técnicas, serviços de terceiros, níveis de desempenho. Nomeie também o que fica de fora. "Fazer um site" não é escopo. "Um aplicativo Next.js responsivo com as funções do Anexo A e nota Lighthouse mobile de pelo menos 90" é. A imprecisão é a primeira fonte de litígios em software: cada parte está convencida de que foi clara.

2. Preço, marcos e prazo de pagamento

Liste cada pagamento: valor, fato gerador e meio de pagamento. Amarre os marcos a entregas aceitas, não a datas do calendário. A multa por atraso tem limite: a cláusula penal não pode exceder o valor da obrigação principal (art. 412 do Código Civil), e o juiz a reduz se for manifestamente excessiva (art. 413). Sobre prazos e encargos, veja nosso artigo sobre prazo de pagamento.

3. Cessão de direitos de propriedade intelectual

É a cláusula que quase todo mundo lê por alto, e a que decide quem pode usar, alterar e vender o software. De quem é o código sob medida? E as peças que o desenvolvedor já tinha? E o código aberto? A Lei 9.609/98 e a Lei 9.610/98 trazem regras de titularidade e de forma, detalhadas na seção sobre direitos autorais mais abaixo.

4. Confidencialidade

Combine uma confidencialidade recíproca: o desenvolvedor não revela seus dados nem sua lógica de negócio, e você não revela as ferramentas e os métodos dele. Fixe por quanto tempo a obrigação sobrevive ao fim do contrato. Para um acordo autônomo, leia o guia de NDA para empresas de software e como criar um NDA sólido.

5. Aceite

Defina como o cliente verifica cada entrega: prazo de verificação (de cinco a dez dias úteis é comum), formato dos comentários, critérios de sucesso e o que acontece se o cliente não responder. O Código Civil obriga o dono a receber a obra concluída de acordo com o ajuste, mas permite rejeitá-la se o empreiteiro se afastou das instruções ou das regras técnicas (art. 615), ou recebê-la com abatimento no preço (art. 616). Para obras medidas por partes, presume-se verificado o que foi medido se, em trinta dias, o dono não denunciar vícios (art. 614, § 2º). A regra não foi escrita para software, então não conte com ela: escreva o prazo no contrato.

6. Garantia

O desenvolvedor garante que o software funciona conforme o Anexo A, que o código é original (ou devidamente licenciado) e que a entrega não viola direitos de terceiros. Um período de correção de erros após o aceite (de trinta a noventa dias, na prática) protege contra defeitos que aparecem em produção. Esclareça que a garantia não cobre o que o cliente alterou por conta própria. O prazo de cinco anos do art. 618 vale para edifícios e construções consideráveis, não para software: para software vale o que o contrato fixar.

7. Rescisão

Cada parte deve poder sair mediante aviso prévio (trinta dias é comum). Defina o destino do trabalho em andamento e o cálculo do saldo. Separe a rescisão por inadimplemento, com notificação prévia, da resilição por conveniência, que se paga, como no art. 623 do Código Civil.

8. Lei aplicável e foro

Nomeie a lei que rege o contrato e o foro competente. Entre um cliente no Brasil e um desenvolvedor em outro país, essa cláusula decide qual juiz vai resolver o litígio. Não deixe em branco só porque parece "formal": é uma das mais úteis assim que uma das partes está fora do seu país.

Use este modelo como base. Substitua todos os campos entre colchetes pelas suas condições. Ele foi escrito para a lei brasileira: a cláusula de cessão (a terceira) segue a Lei 9.609/98 e a Lei 9.610/98. É, junto com a garantia e a limitação de responsabilidade, a parte que um advogado de tecnologia deve revisar. Um modelo é um ponto de partida, não consultoria jurídica.

CONTRATO DE DESENVOLVIMENTO DE SOFTWARE

Data do contrato: [data]

CONTRATANTE: [razão social, CNPJ, endereço]
representada por [nome, cargo] ("a Contratante")

CONTRATADA: [razão social ou nome do autônomo, CNPJ ou CPF, endereço]
representada por [nome, cargo] ("a Contratada")

CLÁUSULA 1. OBJETO E ESCOPO

1.1 A Contratada projeta, desenvolve e entrega à Contratante o software
descrito na especificação do Anexo A ("o Software"), conforme os requisitos,
restrições e critérios de aceite que ali constam.

1.2 Todo trabalho não descrito no Anexo A está fora do escopo e só pode ser
executado depois da assinatura de uma ordem de alteração (cláusula 10).

1.3 O Software é entregue por marcos, conforme o cronograma do Anexo B.

CLÁUSULA 2. PREÇO E PAGAMENTO

2.1 O preço é de R$ [valor] ("o Preço"), pago por marcos conforme o Anexo B.
[Preço fechado, ou horas com teto de R$ [valor]]

2.2 As faturas são pagas em [30] dias da data de emissão.

2.3 O atraso gera multa de [2]% e juros de mora de [taxa]% ao mês sobre o
valor em atraso (a multa respeita o limite do art. 412 do Código Civil).

2.4 A Contratada pode suspender os trabalhos se uma fatura permanecer
impaga [30] dias após o vencimento e após notificação por escrito.

CLÁUSULA 3. PROPRIEDADE INTELECTUAL

3.1 Cessão. Paga integralmente o Preço, a Contratada cede à Contratante, por
escrito, em caráter exclusivo e definitivo, os direitos patrimoniais de autor
sobre os desenvolvimentos específicos criados para ela ("os Desenvolvimentos"),
código-fonte, código-objeto e documentação, nas seguintes modalidades de
utilização, todas existentes na data deste contrato:
a) reprodução, total ou parcial, por qualquer meio e sob qualquer forma;
b) adaptação, tradução e demais modificações, e reprodução do resultado;
c) distribuição, inclusive locação, e comunicação ao público, inclusive a
   disponibilização como serviço online.
Território: todo o mundo. Prazo: todo o prazo de proteção legal dos direitos.
Finalidade: qualquer uso da Contratante, inclusive exploração comercial perante
terceiros [ou: apenas as necessidades internas da Contratante].

3.2 Remuneração. A cessão é feita em troca do Preço, que remunera os direitos
cedidos e é a única compensação pelo trabalho (art. 4º, § 1º, da Lei 9.609/98).

3.3 Direitos morais. Ressalvados a paternidade e o direito de opor-se a
alterações que prejudiquem sua honra ou reputação (art. 2º, § 1º, da Lei
9.609/98), a Contratada não se opõe a que a Contratante crie ou autorize
versões novas e derivações do Software.

3.4 Elementos preexistentes. A Contratada mantém a titularidade das
ferramentas e componentes anteriores ao projeto ou independentes dele, listados
no Anexo A ("os Elementos Preexistentes"), e concede à Contratante licença não
exclusiva, mundial, perpétua e gratuita para usá-los como integrados ao
Software.

3.5 Código aberto. Os componentes de código aberto do Software constam do
Anexo A com suas licenças. A Contratada garante que o uso é compatível com a
exploração prevista na cláusula 3.1.

3.6 Cadeia de titularidade. A Contratada garante ser titular dos direitos
necessários, inclusive os de seus empregados e os de seus subcontratados, que
os cederam a ela por escrito, e que os Desenvolvimentos não violam direitos de
terceiros.

3.7 Registro. As partes podem registrar o programa (registro facultativo, art.
3º da Lei 9.609/98) e averbar a cessão.

CLÁUSULA 4. CONFIDENCIALIDADE

4.1 Cada parte mantém em sigilo as informações não públicas que a outra lhe
comunicar por força deste contrato, por [2/3/5] anos após o seu término.

4.2 Excluem-se as informações públicas sem culpa de quem as recebe, as já
conhecidas por ela e as que a lei ou ordem judicial determinem revelar.

CLÁUSULA 5. DADOS PESSOAIS

Se a Contratada tratar dados pessoais em nome da Contratante, atuará como
operadora, seguirá as instruções da controladora (art. 39 da LGPD) e as partes
assinarão, antes de qualquer tratamento, o aditivo do Anexo C.

CLÁUSULA 6. ACEITE

6.1 A cada entrega de marco, a Contratante tem [10] dias úteis para verificar o
entregável pelos critérios do Anexo A e aceitá-lo ou notificar por escrito os
erros.

6.2 A Contratada corrige os erros bloqueantes em [10] dias úteis, sem custo; os
erros menores ficam como ressalvas e não impedem o aceite.

6.3 Se a Contratante não responder no prazo, a Contratada a lembra por escrito.
Se continuar sem resposta em [5] dias úteis, o marco se considera aceito.

6.4 O aceite segue os critérios objetivos do Anexo A. Cada marco se encerra
com um termo de aceite assinado pelas duas partes.

CLÁUSULA 7. GARANTIA

Por [90] dias após o aceite final, a Contratada corrige sem custo os erros de
conformidade com o Anexo A, salvo se decorrerem de alteração do Software ou do
seu ambiente feita pela Contratante ou por terceiros.

CLÁUSULA 8. RESPONSABILIDADE

8.1 A responsabilidade de cada parte limita-se ao Preço pago nos [12] meses
anteriores ao fato, sem indenização por danos indiretos.

8.2 Esses limites não se aplicam a dolo.

CLÁUSULA 9. VIGÊNCIA E RESCISÃO

9.1 O contrato vigora até o aceite final e o pagamento do saldo.

9.2 Inadimplemento: após notificação sem efeito por [15] dias, a parte
prejudicada pode rescindir o contrato.

9.3 Conveniência: a Contratante pode resilir com [30] dias de aviso, pagando os
marcos aceitos, o trabalho em andamento e [valor ou percentual] pelos lucros
que a Contratada deixaria de ter (art. 623 do Código Civil).

9.4 Ao fim do contrato, a Contratada entrega o código, a documentação e os
acessos necessários.

CLÁUSULA 10. ORDENS DE ALTERAÇÃO

Toda alteração de escopo consta de uma ordem de alteração assinada pelas duas
partes antes de ser executada. A ordem indica o acréscimo, o efeito no
cronograma e o preço. Só [cargos autorizados] podem assiná-la (art. 619 do
Código Civil).

CLÁUSULA 11. LEI APLICÁVEL E FORO

O contrato é regido pela lei brasileira. Fica eleito o foro de [cidade/UF] para
dirimir os litígios dele decorrentes.

CLÁUSULA 12. INTEGRALIDADE

O contrato, seus anexos e as ordens de alteração formam o acordo integral das
partes.

ASSINATURAS

[Cidade], [data]. As partes reconhecem a validade da assinatura eletrônica que
escolheram (art. 10, § 2º, da MP 2.200-2/2001).

A Contratante: [nome, cargo, assinatura]
A Contratada: [nome, cargo, assinatura]

---
ANEXO A. ESPECIFICAÇÃO
[Funções, restrições técnicas, critérios de aceite de cada entregável,
elementos preexistentes, componentes de código aberto e licenças]

ANEXO B. MARCOS E PAGAMENTOS

| Marco | Entregável | Data | Pagamento |
|-------|------------|------|-----------|
| M1: início | [descrição] | [data] | [valor] |
| M2: [fase] | [descrição] | [data] | [valor] |
| M3: entrega final | [descrição] | [data] | [valor] |

ANEXO C. ADITIVO DE TRATAMENTO DE DADOS PESSOAIS (se aplicável)

Se você cuida dos contratos de vários fornecedores de TI, guardar todas as vias assinadas no mesmo lugar, com o histórico de versões, evita a troca de arquivos Word renomeados "final_v3_DEFINITIVO".

A maioria dos modelos cobre o básico. Estas são as cláusulas que somem dos contratos feitos às pressas e as que mais importam no dia em que algo dá errado.

Critérios de aceite mensuráveis

A cláusula 6 do modelo diz quando e como o cliente verifica. O que muitos contratos omitem são os critérios em si. Sem limites mensuráveis, o aceite vira negociação: o cliente sempre pode julgar que o software "não está bom o bastante". Escreva critérios objetivos no Anexo A antes de começar o desenvolvimento.

Depósito do código-fonte e reversibilidade

Se o seu negócio depende de um software sob medida e o desenvolvedor desaparece, você precisa do código. Um depósito (escrow) entrega o código a um terceiro, que o libera ao cliente se o desenvolvedor encerrar as atividades ou descumprir gravemente o contrato. No mínimo, inclua uma cláusula de reversibilidade: entrega do código, da documentação e dos acessos ao fim do contrato, sem custos ocultos. Pouca gente pede isso antes de precisar, e a maioria dos desenvolvedores aceita quando o pedido vem cedo.

Responsabilidade depois da entrega

A cláusula 8 limita a responsabilidade, mas muitos modelos calam sobre a duração. Até quando o desenvolvedor responde? Se uma falha causar perda de dados dezoito meses depois, quem paga? Fixe o período de garantia e a responsabilidade posterior. O Código Civil ajuda a quem negocia limites: nos contratos civis e empresariais, a alocação de riscos definida pelas partes deve ser respeitada (art. 421-A, II). Mesmo assim, um limite desproporcional pode ser discutido, e a cláusula penal está sujeita aos arts. 412 e 413.

Ordens de alteração

A cláusula 10 exige uma ordem assinada para qualquer mudança de escopo. O que muitos omitem é quem tem poder para assinar. Se um gerente de projeto do cliente pede uma função por mensagem e o desenvolvedor a constrói, ela é devida? Só se o procedimento foi seguido. Nomeie cargos, não pessoas, com autoridade para autorizar mudanças. O Código Civil ajuda a entender o risco: sem instruções escritas do dono, o empreiteiro não pode exigir acréscimo de preço, mas, se o dono acompanhava a obra de perto e nunca protestou, deve pagar os acréscimos (art. 619 e parágrafo único).

Código aberto e dados pessoais

Uma biblioteca com licença GPL, por exemplo, pode obrigar a publicar o código do seu produto que a integra. Exija a lista de componentes de código aberto e de suas licenças, e a confirmação de que são compatíveis com o uso previsto. O mesmo vale para os dados: se o desenvolvedor trata dados pessoais, ele atua como operador e segue as instruções do controlador (art. 39 da LGPD), e convém firmar um aditivo de tratamento de dados antes do primeiro acesso a uma base real.

A propriedade intelectual é a cláusula que o cliente folheia e onde os erros saem mais caros. No Brasil, duas leis se somam: a Lei 9.609/98, do software, e a Lei 9.610/98, dos direitos autorais, à qual a primeira remete.

A regra do software: o art. 4º da Lei 9.609/98

O regime de proteção do programa de computador é o das obras literárias, observada a lei do software (art. 2º). Sobre a titularidade, o art. 4º diz que, salvo estipulação em contrário, os direitos pertencem exclusivamente ao empregador, ao contratante de serviços ou ao órgão público quando o programa é desenvolvido na vigência de contrato expressamente destinado à pesquisa e desenvolvimento, ou em que a atividade do contratado seja prevista ou decorra da natureza dos encargos. A compensação, ressalvado ajuste em contrário, limita-se à remuneração convencionada (§ 1º). E o programa gerado sem relação com o contrato e sem recursos do contratante pertence ao contratado (§ 2º). Parece favorável ao cliente, mas depende de "expressamente destinado" e de "salvo estipulação em contrário": se o seu contrato é genérico, o enquadramento pode ser discutido. Por isso a cessão escrita continua sendo a forma segura.

O que a cessão precisa dizer

A cessão pode ir numa cláusula do contrato ou num contrato de cessão de direitos de software separado. Em qualquer caso, a Lei 9.610/98 impõe regras de forma que os modelos americanos ignoram (art. 49):

• a transmissão total e definitiva dos direitos só se admite por estipulação contratual escrita
• sem estipulação escrita, o prazo máximo é de cinco anos
• a cessão vale apenas para o país em que o contrato foi firmado, salvo estipulação em contrário
• só alcança modalidades de utilização já existentes na data do contrato
• sem especificação da modalidade, o contrato é interpretado restritivamente, limitado à indispensável para cumprir a finalidade

E o instrumento de cessão deve trazer, como elementos essenciais, o objeto e as condições de exercício do direito quanto a tempo, lugar e preço (art. 50, § 2º). Já a cessão de obras futuras abrange, no máximo, cinco anos (art. 51), e como o software encomendado ainda é obra futura quando o contrato é assinado, peça a um advogado que confirme como esse prazo se combina com o art. 4º da Lei 9.609/98.

Os quatro modelos de titularidade

Elementos preexistentes, derivações e cadeia de titularidade

Quase todo desenvolvedor traz ferramentas e bibliotecas escritas antes do seu projeto. O contrato deve identificá-las e dar a você uma licença de uso, sem transferir a propriedade dessas peças. Atenção às derivações: os direitos sobre as derivações autorizadas pelo titular, inclusive a exploração econômica, pertencem à pessoa autorizada que as fizer, salvo estipulação contratual em contrário (art. 5º da Lei 9.609/98). Se a sua equipe vai evoluir o código, diga no contrato quem fica com as versões novas. Peça também a cadeia de titularidade: o desenvolvedor só pode ceder o que tem, e o que os subcontratados criaram precisa ter sido cedido a ele por escrito. Para modelos de contrato de desenvolvimento web, a biblioteca de modelos do Chaindoc traz uma base editável; a redação da cessão você precisa adaptar ao seu caso.

Sobre Portugal

Em Portugal, a empreitada é o contrato pelo qual uma parte se obriga a realizar certa obra mediante um preço (art. 1207.º do Código Civil). Duas regras merecem atenção: se foi fixado preço global e a autorização para alterar a obra não foi dada por escrito com fixação do aumento de preço, o empreiteiro só pode exigir indemnização correspondente ao enriquecimento do dono (art. 1214.º, n.º 3), e a falta de verificação ou de comunicação do resultado equivale a aceitação (art. 1218.º, n.º 5). Quanto à titularidade, o Código do Direito de Autor remete para o que for convencionado na obra por encomenda e, na falta de convenção, presume que o direito pertence ao criador intelectual (art. 14.º). Em Portugal, portanto, a cessão escrita é ainda mais importante. O Código Civil português e o Código do Direito de Autor estão publicados pela PGDL.

Esses documentos se confundem o tempo todo. Em resumo: um contrato de desenvolvimento para um projeto isolado, e um contrato-mãe mais um SOW para uma relação que dura. Cada um cumpre uma função, e misturá-los cria lacunas de responsabilidade.

Para um projeto isolado, um contrato único como o deste guia basta. Para um parceiro de desenvolvimento com quem você toca vários projetos, o conjunto contrato-mãe e SOW é mais eficiente: você negocia a base jurídica uma vez e cada projeto acrescenta um SOW.

Conseguir um contrato de desenvolvimento de software assinado significava imprimir, escanear, enviar e torcer para que as duas versões coincidissem. Não há mais motivo para fazer assim.

O que torna válida uma assinatura eletrônica

Para um contrato entre empresas, uma assinatura eletrônica serve quando cumpre estas condições:

• identifica o autor e manifesta a sua vontade
• está ligada ao documento assinado
• permite detectar qualquer alteração posterior
• o registro é guardado de forma que possa ser consultado depois

No Brasil, a validade da declaração de vontade não depende de forma especial, salvo quando a lei a exige (art. 107 do Código Civil), e a MP 2.200-2/2001 admite, em seu art. 10, § 2º, outros meios de comprovação de autoria e integridade que as partes aceitem, ao lado dos certificados da ICP-Brasil. As assinaturas criptográficas vão além: cada uma fica ligada matematicamente ao hash do documento, e mudar um único caractere depois altera a impressão digital do arquivo. Nenhuma parte pode alegar depois que o documento foi alterado sem que isso apareça.

Como funciona o processo de assinatura

Um contrato de TI raramente anda sozinho: contrato-mãe, SOW, NDA e aditivos circulam ao mesmo tempo. Um circuito de assinatura próprio evita a bagunça de versões trocadas por e-mail:

• envie o contrato final, com os anexos, num único arquivo
• adicione o e-mail de cada signatário; todos recebem o convite ao mesmo tempo, e uma ordem fixa se obtém com os circuitos de aprovação do plano Business
• cada signatário assina do seu dispositivo
• o serviço emite um certificado de assinatura, com os carimbos de tempo e o hash do documento
• cada parte guarda o documento assinado, e a prova pode ser verificada depois com o serviço de verificação do Chaindoc

Marcos e faturamento

O mais útil de uma ferramenta de contratos não é a assinatura, mas o que vem depois. O termo de aceite de um marco é um documento que se assina como o contrato, e é ele que sustenta a fatura. Para equipes que acompanham pagamentos e contratos, assinar o termo de aceite no mesmo lugar do contrato mantém aceite e cobrança alinhados. Os planos estão detalhados na página de preços, e o serviço de assinatura, na página de assinatura eletrônica.

Textos de referência

• Lei 9.609/98 (Lei do Software), arts. 2º a 5º
• Lei 9.610/98 (Lei de Direitos Autorais), arts. 49 a 51
• Código Civil, Lei 10.406/2002, arts. 593, 610 a 625 e 412 a 413
• MP 2.200-2/2001, art. 10
• LGPD, Lei 13.709/2018, art. 39

Há mais guias práticos no blog do Chaindoc.