Contrato de licenciamento de software: o que precisa ter

Entenda o que é o contrato de licenciamento de software, o que muda no modelo SaaS, como proteger o código e as customizações e o que fazer quando o cliente usa além do contratado.

Uma empresa de tecnologia costuma dedicar anos ao produto, à infraestrutura e ao time comercial. O contrato de licenciamento de software, por outro lado, muitas vezes fica para depois: é um modelo antigo, adaptado de outro negócio ou herdado da fase em que a empresa tinha poucos clientes. Enquanto a carteira é pequena, quase ninguém relê esse documento. Ele passa a importar quando o produto cresce e os clientes crescem junto.

É nesse momento que os conflitos aparecem. O cliente que contratou o sistema para uma unidade passa a usá-lo em toda a rede, o grupo econômico entende que a licença comprada por uma de suas empresas vale para todas as outras e o contratante corporativo exige o código-fonte como condição para renovar. Há ainda o cliente que deixou de pagar e continua usando o sistema, porque nada no contrato autoriza a suspensão do acesso. Em todos esses casos, a discussão se resolve pelo que está escrito e, quando nada está escrito, pela interpretação de quem vier a julgar.

Licenciar um software é autorizar o uso de algo que continua pertencendo a quem o criou, o que é bem diferente de vender. O contrato de licenciamento existe para medir o tamanho dessa autorização e, por consequência, deixar claro tudo o que ficou de fora dela.

Neste artigo, explicamos o que esse contrato precisa ter na perspectiva de quem licencia, o que muda quando o produto é vendido como serviço na nuvem, como proteger o código-fonte e as customizações e o que fazer quando o cliente usa o sistema além do que foi contratado.

O que é um contrato de licenciamento de software

O contrato de licenciamento de software é o documento pelo qual a empresa titular de um programa autoriza outra pessoa ou empresa a usá-lo, dentro de condições definidas, sem transferir a propriedade. Ele também é chamado de contrato de licença de uso de software, que é o nome adotado pela própria lei. É nele que ficam registrados quem pode usar o sistema, de que forma, por quanto tempo, a que preço e com qual suporte.

No Brasil, o programa de computador é protegido como obra intelectual, no mesmo regime aplicado aos livros. Essa proteção nasce com a criação, independentemente de qualquer registro, e dura cinquenta anos. A Lei do Software prevê ainda que o uso de um programa no país seja objeto de um contrato de licença e, quando ele não existir, que a nota fiscal de compra ou de licenciamento sirva para comprovar que o uso é regular. Para quem licencia, isso significa que o contrato é a principal prova do que foi autorizado.

Licença de uso ou cessão: qual a diferença?

Na licença, a empresa autoriza o uso e continua dona do software. Na cessão, ela transfere a titularidade e deixa de ser dona daquilo que criou. Boa parte dos conflitos com clientes de grande porte nasce dessa confusão: o contratante entende que comprou o sistema quando, na verdade, comprou o direito de usá-lo dentro de certas condições. Por isso, o contrato precisa dizer com todas as letras que se trata de licença, e não de venda ou de cessão.

Há, nesse regime, uma regra que favorece quem licencia. A lei de direitos autorais determina que os contratos sobre esses direitos sejam interpretados de forma restritiva, ou seja, aquilo que não foi expressamente autorizado tende a ser considerado não autorizado. Essa vantagem, porém, só funciona quando o contrato descreve com precisão o que foi permitido, porque um texto vago enfraquece justamente a proteção que a lei oferece.

Licença tradicional ou SaaS: o que muda no contrato

Existem dois grandes modelos de comercialização de software, e cada um pede um contrato com eixo próprio. No modelo tradicional, o programa é instalado nos computadores ou servidores do cliente, e o que precisa ser controlado é a cópia. No modelo de assinatura, conhecido como SaaS (sigla em inglês para software como serviço), o cliente não recebe cópia nenhuma: ele acessa pela internet um sistema que roda na infraestrutura da empresa, e o contrato passa a girar em torno da disponibilidade do serviço, do volume de uso e dos dados hospedados.

Um contrato pensado para software instalado costuma ser silencioso justamente sobre disponibilidade e dados, que são o centro do SaaS. Já um contrato de SaaS que ignora a possibilidade de instalação local deixa brechas quando um cliente corporativo exige um ambiente dedicado. Definir o modelo antes de redigir é, portanto, a primeira decisão do processo, e a empresa que trabalha com os dois precisa de regras separadas para cada um.

No SaaS, o contrato costuma conviver com os termos de uso da plataforma, que regulam o comportamento de quem usa o sistema no dia a dia. Esse documento é um dos que explicamos ao tratar dos documentos obrigatórios para site e plataformas digitais.

O que o contrato de licenciamento de software precisa ter

Cada produto pede um contrato próprio, mas algumas cláusulas definem o alcance da licença em qualquer modelo. São elas que costumam decidir os conflitos com clientes e, por isso, merecem ser escritas com o mesmo cuidado dedicado ao próprio software.

Escopo: quem pode usar, quanto e onde

O escopo é o núcleo do contrato. É aqui que se define quem pode usar o sistema, quantos usuários, em quais unidades ou ambientes, para qual finalidade e em qual território. Também é aqui que entram as proibições que mais importam para quem licencia, como compartilhar senhas, estender a licença a outras empresas do mesmo grupo, transferir o contrato a terceiros ou usar o sistema para prestar serviço a outras companhias.

Dois cuidados merecem atenção. O primeiro é a sublicença e a revenda: se a empresa trabalha com parceiros ou distribuidores, o contrato precisa dizer se eles podem conceder licenças a clientes finais e em que condições, lembrando que a lei reserva ao titular a decisão de autorizar ou proibir o aluguel comercial do programa. O segundo é não proibir o que a lei já permite. Fazer uma cópia de segurança de uma cópia legítima, por exemplo, não é considerado violação, e por isso o contrato deve regular essa cópia em vez de simplesmente vedá-la.

Prazo, preço, reajuste e inadimplência

A licença pode ser perpétua, quando o cliente paga uma vez e pode usar aquela versão por tempo indeterminado, ou por prazo, com pagamento periódico e renovação. Nos dois casos, o contrato deve dizer com que antecedência qualquer das partes pode avisar que não quer renovar, qual índice corrige o preço e com que frequência. Essas regras evitam a negociação desgastante a cada aniversário do contrato e seguem a mesma lógica das cláusulas que todo contrato empresarial precisa ter.

A inadimplência merece uma cláusula própria. Se o contrato não autoriza expressamente a suspensão do acesso depois de um aviso e de um prazo para pagar, o bloqueio pode ser questionado pelo cliente, inclusive com pedido de indenização. Com a regra escrita, a empresa sabe o que pode fazer, o cliente sabe o que vai acontecer, e a suspensão deixa de ser uma decisão improvisada.

Atualizações, suporte e validade técnica

O mercado costuma misturar três obrigações diferentes: corrigir defeitos, entregar novas versões e dar suporte a quem usa o sistema. Cada uma tem escopo e custo próprios, e o contrato deve separá-las, dizendo o que está incluído no preço da licença, o que é cobrado à parte e em quanto tempo a empresa responde a cada tipo de chamado.

A lei acrescenta um ponto que muitas empresas desconhecem. Quem comercializa um programa precisa informar por quanto tempo aquela versão terá validade técnica e, durante esse período, tem o dever de manter os serviços técnicos necessários ao seu funcionamento, em regra mesmo que deixe de vender o produto. Por isso, esse prazo deve ser definido com realismo. Já a implantação, o treinamento e a personalização são prestação de serviço e podem ficar em um contrato de prestação de serviços separado ou em um anexo da licença.

Encerramento e devolução dos dados

O fim da relação precisa ser tão detalhado quanto o começo. No software instalado, o contrato deve dizer se o cliente precisa desinstalar o sistema e comprovar a exclusão das cópias. No SaaS, deve definir se o acesso termina imediatamente ou se o cliente terá um prazo para exportar os seus dados, em qual formato e por quanto tempo a empresa os manterá antes de apagá-los. É um dos pontos que mais geram discussão no fim do contrato e um dos que mais faltam nos modelos genéricos.

Quem é dono do código-fonte e das customizações?

A licença autoriza o uso do programa em funcionamento e nada além disso. Ela não entrega o código-fonte, que é o conjunto de instruções escritas pelos desenvolvedores, não permite que o cliente desmonte o programa para descobrir como ele foi feito e não transfere o uso da marca do produto. Essas restrições precisam estar expressas no contrato, e não apenas subentendidas. Antes de tudo, porém, a empresa precisa ter certeza de que é dona de tudo o que está licenciando.

Código feito por empregados, freelancers e terceirizados

Pela lei, o programa desenvolvido por empregados no exercício das suas funções pertence à empresa, salvo combinação em contrário. A mesma regra vale para o programa encomendado a um prestador de serviços quando o contrato tem o desenvolvimento como objeto. O problema aparece quando parte do código foi escrita por freelancers, consultorias ou profissionais contratados sem nada por escrito, porque, sem contrato, fica difícil provar o que foi encomendado e a quem pertence o resultado.

Essa dúvida costuma surgir em momentos sensíveis, como uma rodada de investimento ou a venda da empresa, quando o investidor ou o comprador pede a comprovação de que o software é de fato da empresa. Por isso, todo desenvolvedor externo deve ter um contrato que trate expressamente da titularidade do que ele produz. O mesmo cuidado vale para os componentes de código aberto incorporados ao produto: cada um tem uma licença própria, e algumas delas exigem, em certas condições, que o software que as utiliza também tenha o código aberto, o que pode ser incompatível com o modelo de licenciamento da empresa.

Customizações feitas para um cliente

Quando a empresa adapta o sistema para atender um cliente específico, surge a pergunta sobre quem é o dono dessa adaptação, e sem cláusula a resposta pode não ser a esperada. A lei atribui a modificação autorizada a quem foi autorizado a fazê-la, salvo previsão em contrário, e o desenvolvimento feito sob encomenda pode ser reivindicado pelo cliente que pagou por ele. Na prática, o contratante pode sustentar que aquela funcionalidade é exclusiva e não pode ser oferecida aos concorrentes dele.

A solução é simples quando adotada no início. O contrato deve dizer que as customizações e melhorias, mesmo quando pagas pelo cliente, pertencem à empresa e podem ser incorporadas ao produto. Se o cliente fizer questão de exclusividade sobre alguma funcionalidade, ela pode ser negociada à parte, desde que tenha prazo e limites claros.

O cliente exige o código-fonte: o que é o escrow

Clientes de grande porte às vezes condicionam a contratação ao acesso ao código-fonte, com receio de ficar sem o sistema se a empresa encerrar as atividades. A forma de atender a essa preocupação sem entregar o principal ativo da empresa é o escrow de código-fonte, ou seja, o depósito do código com um terceiro de confiança, que só o libera ao cliente em situações definidas no contrato, como falência ou descontinuação do produto sem substituto.

O escrow não tem uma lei própria no Brasil e funciona como um acordo entre as partes, por isso tudo depende da redação: quais versões são depositadas e com que frequência, quem paga o custo do depósito, quais eventos autorizam a liberação e o que o cliente pode fazer com o código depois de recebê-lo, o que normalmente se limita a manter o sistema funcionando para uso próprio. Para reforçar a prova de autoria, a empresa também pode registrar o programa no INPI, um registro facultativo que mantém em sigilo os trechos do código apresentados.

O que acontece se o cliente usar o software além do que foi licenciado?

A empresa pode exigir a regularização do uso e, se não houver acordo, pedir à Justiça a interrupção do uso irregular e uma indenização. Esse é um dos conflitos mais comuns entre empresas de software e seus clientes, e ele aparece de várias formas: mais usuários do que os pagos, instalação em equipamentos não previstos, extensão a outras empresas do grupo ou uso continuado depois do fim do contrato. Em todos esses casos, o caminho começa pelo contrato, e a cláusula mais útil é a de auditoria, que permite à empresa verificar, com aviso prévio e dentro de limites razoáveis, se o uso corresponde ao que foi licenciado.

Constatado o excesso, a solução mais frequente é negociar a regularização, com a cobrança das licenças excedentes pelo período em que foram usadas. Se o caso chegar à Justiça, o pedido para interromper o uso pode vir acompanhado de multa em caso de descumprimento. Quanto à indenização, o Superior Tribunal de Justiça já entendeu, em casos de uso sem licença, que ela não precisa se limitar ao preço das licenças, justamente para não favorecer quem deixou de pagar, embora o valor dependa das circunstâncias de cada caso.

Também houve novidade sobre o prazo. Em decisão divulgada em fevereiro de 2026, uma das turmas do Superior Tribunal de Justiça entendeu que, quando a violação decorre do descumprimento de um contrato de licenciamento, o prazo para pedir indenização é o prazo geral de dez anos, e não o de três anos aplicado quando não há contrato entre as partes. Ter o uso permitido descrito em contrato, portanto, faz diferença também no tempo que a empresa tem para agir. Para outros tipos de quebra do combinado, os caminhos estão explicados no artigo sobre descumprimento contratual.

Até onde vai a responsabilidade da empresa quando o sistema falha

Nenhum software funciona sem interrupções, e o contrato deve reconhecer isso. Ele precisa dizer qual nível de disponibilidade a empresa promete, como são tratadas as manutenções programadas, em quanto tempo os chamados são respondidos conforme a gravidade e o que acontece quando esse compromisso não é cumprido. Essas regras, conhecidas como acordo de nível de serviço (ou SLA, na sigla em inglês), costumam prever descontos em faturas futuras como compensação.

Também é legítimo limitar a responsabilidade da empresa, afastando prejuízos indiretos, como o lucro que o cliente deixou de ganhar, e fixando um teto de indenização, em geral ligado aos valores pagos em determinado período. Nos contratos empresariais, o Código Civil presume que as partes negociaram em condições de igualdade e determina que a divisão de riscos combinada entre elas seja respeitada, o que dá força a esse tipo de cláusula quando ela foi de fato negociada.

Cabe aqui uma ressalva honesta. Quando o cliente usa o software como destinatário final, a relação pode ser de consumo, e o Código de Defesa do Consumidor considera nulas as cláusulas que afastam ou reduzem a responsabilidade do fornecedor por defeitos. Isso vale para pessoas físicas e pode valer também para pequenas empresas em posição de vulnerabilidade, caso em que a limitação só é aceita em situações justificáveis. Cláusulas traduzidas de contratos estrangeiros, sem adaptação, dificilmente passam por esse exame.

Licenciamento de software e LGPD: quem responde pelos dados

Se o sistema armazena ou processa dados de pessoas, como clientes, pacientes, empregados ou usuários finais do contratante, a LGPD passa a fazer parte da relação, mesmo que o contrato não a mencione. Na lógica da lei, quem decide por que e como os dados são usados é o controlador, e quem os trata em nome dele, seguindo as suas instruções, é o operador. No licenciamento, especialmente no SaaS, o cliente costuma ocupar a primeira posição e a empresa de software, a segunda, mas esse enquadramento depende do que cada parte de fato decide na operação, e o contrato é o lugar certo para registrá-lo.

A posição de operador não deixa a empresa de software fora do risco. A LGPD prevê que o operador responde junto com o controlador pelos danos quando descumpre a lei ou não segue as instruções recebidas. Essa responsabilidade não é automática, existem excludentes, mas o risco é real, e por isso o contrato deve definir as finalidades do tratamento, as medidas de segurança, as regras para os subcontratados, como o provedor de nuvem que hospeda o sistema, e um prazo curto para a empresa avisar o cliente sobre qualquer incidente.

Esse último ponto é decisivo. Pela regra atual da autoridade nacional de proteção de dados, o cliente tem três dias úteis para comunicar um incidente relevante, e esse prazo só é cumprido se o aviso da empresa de software chegar rápido. A divisão de responsabilidades com fornecedores que tratam dados é detalhada no artigo sobre compartilhamento de dados com fornecedores. Nossa equipe atua na estruturação e na revisão de contratos de licenciamento, alinhando as exigências de proteção de dados à realidade técnica de cada produto.

Licenciar bem é delimitar o que continua sendo seu

Um bom contrato de licenciamento não existe para antecipar uma disputa, mas para descrever com precisão aquilo que foi negociado, de modo que a disputa deixe de ser necessária. Quando escopo, prazo, preço, suporte, titularidade do código, responsabilidade e destino dos dados estão bem definidos, sobra pouco espaço para interpretações divergentes, e a regra da lei que favorece quem licencia passa de fato a trabalhar a favor da empresa.

Modelos genéricos raramente cumprem essa função, porque não conhecem a arquitetura do produto, o modelo de cobrança nem o perfil dos clientes. O contrato de quem licencia um sistema de gestão instalado em redes de lojas não pode ser o mesmo de quem vende uma plataforma por assinatura a clientes corporativos, e os dois precisam mudar à medida que o produto cresce.

Se a sua empresa licencia um software e quer revisar o contrato que vem usando, ou se está estruturando um novo modelo de comercialização para atender clientes de maior porte, nossa equipe pode analisar o seu produto e orientar a elaboração ou a revisão do contrato com clareza e responsabilidade.