Se a sua empresa desenvolve ou usa software, o contrato de licenciamento é o documento que define se você tem controle sobre o que construiu ou se está se expondo sem perceber.
Não é exagero: contratos mal redigidos já custaram a empresas de tecnologia a perda de propriedade intelectual em processos de M&A, bloqueios de rodadas de investimento por contingências ocultas e disputas milionárias sobre o que era ou não ‘uso autorizado’. Este guia explica como evitar esses cenários.
Vamos cobrir a natureza jurídica do licenciamento, as cláusulas que não podem faltar, as particularidades do modelo SaaS, LGPD integrada ao contrato, proteção de código-fonte, open source e as perguntas mais frequentes, tudo com base na Lei de Software (Lei nº 9.609/98), na Lei de Direitos Autorais (Lei nº 9.610/98) e na jurisprudência brasileira atual.
O que você vai encontrar neste guia
- O que é e para que serve um contrato de licenciamento de software
- Licenciamento x Cessão: a distinção que pode custar a sua empresa
- As cláusulas obrigatórias — e as que a maioria esquece
- Métricas de uso e modelos de precificação protegidos
- SLA e responsabilidade civil no modelo SaaS
- Proteção do código-fonte, escrow e engenharia reversa
- LGPD integrada: controlador, operador e DPA
- Registro do software no INPI
- Open source: quando a ‘licença gratuita’ pode abrir seu código
- Resolução de conflitos: arbitragem ou Judiciário?
- FAQ: as dúvidas mais frequentes dos nossos clientes
- Como a Legroski aborda contratos de licenciamento
1. O que é um contrato de licenciamento de software?
O contrato de licenciamento de software é o instrumento jurídico pelo qual o titular dos direitos patrimoniais sobre um programa de computador autoriza um terceiro a utilizá-lo, dentro de condições e limites pré-definidos.
Note que o objeto do contrato não é o software em si, mas o direito de uso. A propriedade intelectual permanece com a desenvolvedora. É essa lógica que permite que uma empresa escale seu produto para centenas de clientes sem perder controle sobre o que criou.
A base legal no Brasil é a Lei nº 9.609/98 (Lei de Software), complementada pela Lei nº 9.610/98 (Lei de Direitos Autorais), pelo Código Civil (Lei nº 10.406/02), e, para SaaS com coleta de dados, pela LGPD (Lei nº 13.709/18).
2. Licenciamento x Cessão de Direitos: a distinção que define tudo
Esta é a distinção mais importante, e mais ignorada, em contratos de tecnologia.
Licenciamento: a desenvolvedora retém a titularidade do código e dos direitos autorais. O cliente recebe apenas o direito de uso, dentro dos limites definidos no contrato. A licença pode ser por prazo determinado, revogável, com restrições territoriais e funcionais.
Cessão de direitos: transferência definitiva da titularidade patrimonial. Quem cede se despoja dos seus direitos. O cessionário passa a ser o novo dono do software.
Uma cláusula ambígua que um tribunal interprete como cessão pode representar a perda do ativo mais valioso da sua empresa. Isso acontece com mais frequência do que se imagina em contratos de desenvolvimento por encomenda mal redigidos.
Regra prática: nunca use os termos como ‘venda’, ‘transferência’ ou ‘entrega do software’ em contratos onde a intenção é apenas licenciar. Cada palavra importa.
3. Cláusulas obrigatórias em um contrato de licenciamento de software
Um contrato robusto precisa endereçar, no mínimo, os seguintes pontos:
3.1 Identificação do objeto e do software licenciado
Parece óbvio, mas é onde muitos contratos falham. O objeto deve especificar: nome e versão do software, funcionalidades cobertas, módulos incluídos e excluídos, se há personalizações e quais, e o ambiente de entrega (on-premise, cloud, híbrido).
3.2 Natureza e modalidade da licença
O contrato deve deixar expresso: exclusiva ou não exclusiva, revogável ou irrevogável, transferível ou intransferível, sublicenciável ou não, e com ou sem limite territorial.
A ausência de uma dessas definições abre margem para interpretações que beneficiam o licenciado, não você.
3.3 Prazo de vigência
Licença perpétua (paga uma vez, usa para sempre) ou por prazo determinado (SaaS mensal, anual, etc.)? A Lei de Software exige que o prazo de validade técnica da versão seja consignado. Para contratos de prazo indeterminado, é necessário prever mecanismo de rescisão com aviso prévio razoável.
3.4 Restrições de uso
Proibições expressas reduzem litígios. As mais importantes: engenharia reversa e descompilação, criação de obras derivadas, compartilhamento de credenciais, uso para finalidades não previstas no contrato, e sublicenciamento sem autorização.
3.5 Confidencialidade e sigilo
Informações sobre código-fonte, algoritmos, bases de dados e arquitetura do sistema são ativo estratégico. A cláusula de confidencialidade deve: definir o que é informação confidencial, restringir acesso a pessoal autorizado, proibir divulgação sem consentimento e manter o sigilo mesmo após o término do contrato.
3.6 Propriedade intelectual sobre customizações
Quando o cliente paga por uma funcionalidade desenvolvida sob demanda, a quem pertence? Sem cláusula expressa, o Art. 4º da Lei 9.609/98 pode atribuir a propriedade ao contratante que custear integralmente o desenvolvimento. A solução: prever que a licenciante retém a titularidade de toda e qualquer evolução do software, concedendo ao cliente apenas o direito de uso das melhorias.
3.7 Responsabilidades e garantias
A licenciante deve garantir que o software é de sua autoria ou que possui as autorizações necessárias para licenciá-lo, que não infringe direitos de terceiros, e que funciona para as finalidades descritas no contrato. O licenciado deve garantir que utilizará o software dentro dos limites contratados, que não tentará burlar mecanismos de proteção e que notificará a licenciante sobre incidentes de segurança que afetem o software.
3.8 Limitação de responsabilidade (liability cap)
Sem um teto indenizatório definido em contrato, um único incidente pode comprometer o patrimônio da empresa. O cap é geralmente fixado como múltiplo dos valores pagos nos últimos 12 meses. Lembre-se: a limitação de responsabilidade não pode excluir dolo ou culpa grave.
3.9 Vigência, rescisão e consequências
Preveja: motivos para rescisão imotivada (com aviso prévio), rescisão por descumprimento (com prazo para cura), multas rescisórias escalonadas, e o que acontece com os dados e acessos após o encerramento.
3.10 Foro e método de resolução de conflitos
Arbitragem ou Judiciário? Para empresas de grande porte, a arbitragem oferece vantagens claras: árbitros com conhecimento técnico em TI, sigilo do processo e maior velocidade. Para contratos com PMEs e empresas de médio porte, o foro do Judiciário pode ser mais adequado pelo custo menor de acesso.
4. Métricas de uso: onde mora o revenue leakage
A métrica de licença define como a precificação escala com o uso do cliente. Errá-la é perder receita de forma silenciosa. As principais métricas utilizadas no mercado brasileiro de software:
O contrato deve definir com precisão o que conta para a métrica escolhida, o mecanismo de auditoria (direito de auditoria da licenciante), as penalidades por uso acima do contratado e o processo de ajuste periódico da licença (true-up).
5. SLA e responsabilidade civil no modelo SaaS
No modelo SaaS, a discussão não é só sobre o código, é sobre a disponibilidade do serviço. O SLA (Service Level Agreement) define as métricas de qualidade que a licenciante se compromete a entregar.
O que o SLA deve prever:
- Uptime mínimo garantido (ex.: 99,5% ou 99,9% mensais) e como é calculado (janela de manutenção excluída ou não);
- Tempo máximo de resposta para incidentes críticos, graves e moderados;
- Plano de contingência e disaster recovery;
- Service credits: créditos proporcionais ao descumprimento do SLA;
- Exclusões: manutenções programadas, falhas de infraestrutura de terceiros (AWS, Azure, GCP), incidentes por má configuração do licenciado.
Responsabilidade civil: o que pode e o que não pode ser limitado
A limitação de responsabilidade por danos indiretos e lucros cessantes é válida e recomendável. Mas atenção: o STJ tem precedentes limitando cláusulas abusivas de exclusão total de responsabilidade em contratos de adesão e muitos contratos SaaS se enquadram nessa categoria quando firmados com consumidores ou microempresas.
A proteção mais eficaz é a combinação de: teto indenizatório claro (liability cap), exclusões específicas e bem fundamentadas, e um SLA realista que a empresa consegue de fato cumprir.
6. Proteção do código-fonte: escrow, engenharia reversa e customizações
Escrow de código-fonte
O escrow (ou ‘depósito de código’) é uma garantia para o licenciado: se a desenvolvedora falir ou descontinuar o produto, o licenciado recebe o código-fonte para manter suas operações. Para a licenciante, é uma concessão que viabiliza contratos com clientes de maior porte e exigência. O acordo de escrow define quem é o agente depositário, as condições de liberação do código, o formato e a periodicidade de atualização do depósito.
Proibição de engenharia reversa
A vedação à engenharia reversa, descompilação e desmontagem do código deve ser expressa no contrato. A Lei de Software já prevê essa proteção, mas a cláusula contratual reforça o caráter civil da infração e facilita a busca e apreensão judicial.
Customizações e desenvolvimentos sob demanda
Este é o ponto de maior litígio em contratos de licenciamento no Brasil. Quando o cliente paga por uma feature personalizada, ele frequentemente entende que a ‘comprou’. A estratégia mais segura para a licenciante: cláusula expressa de que toda evolução do software, incluindo customizações pagas pelo cliente, permanece de titularidade da licenciante, cabendo ao cliente apenas o direito de uso. Isso deve ser combinado com uma política de roadmap que demonstre ao cliente que seus pedidos de customização serão incorporados ao produto.
7. LGPD integrada ao contrato de licenciamento
Todo software que coleta, processa ou armazena dados pessoais está sujeito à LGPD e o contrato de licenciamento precisa refletir isso. Ignorar essa camada não é apenas um risco regulatório; é um risco comercial, pois empresas maduras e investidores exigem conformidade em processos de due diligence.
Controlador x Operador: quem é quem
Controlador: decide a finalidade e os meios do tratamento. Geralmente é o cliente (licenciado) que define para que os dados serão usados.
Operador: trata os dados em nome e conforme as instruções do controlador. Geralmente é a licenciante (especialmente no modelo SaaS, quando os dados ficam no ambiente da fornecedora).
O DPA (Data Processing Agreement)
O DPA é o instrumento que formaliza a relação entre controlador e operador no contexto da LGPD. Ele deve integrar o contrato de licenciamento como anexo ou como cláusula específica e precisa contemplar: natureza, finalidade e tipos de dados tratados, obrigações de segurança da informação do operador, procedimento de notificação de incidentes (prazo máximo de 72h para comunicação à ANPD conforme orientação vigente), uso de suboperadores (ex.: provedores de nuvem), direitos dos titulares e como serão respondidos, e o que acontece com os dados ao término do contrato.
Portabilidade e devolução de dados ao término do contrato
O licenciado tem direito à portabilidade dos seus dados. O contrato deve prever: o formato de exportação (JSON, CSV, XML), o prazo para disponibilização após o término, a possibilidade de cobrança dos custos técnicos de exportação, e a vedação ao uso dos dados como instrumento de coerção para pagamento de dívidas.
8. Registro do software no INPI
Os direitos autorais sobre software existem desde a criação, independentemente de registro. Mas o registro no INPI (Instituto Nacional da Propriedade Industrial) oferece vantagens práticas relevantes: cria presunção de autoria e data de criação, fortalece a posição em disputas judiciais, facilita o sublicenciamento para terceiros e é um sinal positivo para investidores em processos de due diligence de IP.
O registro é feito perante o INPI e não é obrigatório. Para softwares estratégicos — especialmente aqueles que compõem o core product da empresa — o registro é altamente recomendável.
9. Open source: quando a ‘licença gratuita’ custa caro
Incorporar componentes open source ao software proprietário é prática comum e perigosa se feita sem análise jurídica. O risco principal está nas licenças copyleft, especialmente a GNU GPL.
A cláusula ‘viral’ da GPL exige que qualquer software que utilize um componente GPL também seja distribuído sob licença aberta. Se uma desenvolvedora incorpora código GPL ao seu produto proprietário sem a devida segregação técnica, pode ser compelida a abrir todo o código-fonte ao público, destruindo o valor comercial do ativo.
Tipos de licenças open source e seus riscos
- GPL (GNU General Public License): alto risco. Cláusula viral forte. Exige abertura do código derivado;
- LGPL (Lesser GPL): risco moderado. Permite uso em software proprietário se o componente for usado como biblioteca separada;
- MIT, BSD, Apache 2.0: baixo risco. Permissivas. Permitem uso em software proprietário com apenas obrigação de atribuição;
- Creative Commons: geralmente para conteúdo, não código. Mas atenção às variantes NC (não comercial) e SA (share-alike);
O contrato de licenciamento deve conter declarações e garantias expressas de que a licenciante possui todas as autorizações necessárias para os componentes de terceiros e que estes não comprometem a natureza proprietária do software. Internamente, a empresa deve manter um inventário atualizado de todos os componentes open source utilizados (Software Composition Analysis).
10. Resolução de conflitos: arbitragem ou Judiciário?
A escolha do fórum de resolução de conflitos tem impacto direto no custo e na velocidade de resolução de disputas.
Arbitragem — quando faz sentido: contratos com empresas de grande porte, especialmente quando envolvem valores relevantes e questões técnicas complexas. Vantagens: árbitros com expertise em TI e PI, sigilo do processo, maior velocidade em relação ao Judiciário.
Judiciário — quando faz sentido: contratos com PMEs, startups em estágio inicial ou empresas de médio porte, onde o custo da arbitragem pode ser desproporcionalmente alto. O foro de eleição (que define onde a ação será proposta) deve ser definido no contrato.
Uma opção intermediária crescente no mercado tech: mediação prévia obrigatória como etapa anterior à arbitragem ou ao Judiciário, reduz custos e preserva relacionamentos comerciais.
FAQ — Perguntas frequentes sobre contratos de licenciamento de software
Qual a diferença entre licenciamento de uso e desenvolvimento de software por encomenda?
No licenciamento, o cliente adquire o direito de usar um software já existente, e a desenvolvedora mantém a titularidade integral. No desenvolvimento por encomenda, se o contrato for omisso, o Art. 4º da Lei 9.609/98 estabelece que os direitos pertencem ao contratante que custeou integralmente o desenvolvimento. Para a desenvolvedora, a proteção está em uma cláusula expressa de retenção da propriedade intelectual, mesmo em desenvolvimentos pagos pelo cliente.
É possível rescindir um contrato de licenciamento sem pagar multa?
Depende do que está previsto no contrato. Em contratos de execução continuada (SaaS), a jurisprudência aceita rescisão imotivada mediante aviso prévio razoável (30 a 90 dias). Mas se houve investimentos expressivos da licenciante em implementação ou customização específica para aquele cliente, a interrupção abrupta pode ensejar indenização com base na teoria do investimento qualificado (Art. 473, parágrafo único, do Código Civil).
Como funciona a responsabilidade em caso de vazamento de dados?
No modelo SaaS, a licenciante geralmente atua como operadora e tem responsabilidade sobre a segurança do ambiente. O contrato deve delimitar claramente que a licenciante não responde por vulnerabilidades causadas por má gestão de senhas pelo usuário, falta de atualização em ambientes on-premise, ou ataques de engenharia social. O cap de responsabilidade (teto indenizatório) é essencial para tornar o risco gerenciável.
O que acontece com os dados do cliente após o término do contrato?
O cliente tem direito à portabilidade dos seus dados. O contrato deve prever um período de transição para exportação dos dados em formato interoperável, a possibilidade de cobrança dos custos técnicos (desde que previsto), e a vedação ao bloqueio dos dados como forma de cobrança de inadimplemento, prática condenada pelos tribunais.
Como lidar com bugs e falhas no software licenciado?
O contrato deve classificar os tipos de incidente (crítico, grave, moderado, baixo), estabelecer SLAs específicos para cada categoria, definir o processo de abertura e acompanhamento de chamados, prever o que é garantia de correção (warranty) versus suporte pago, e limitar as garantias a um período após a entrega.
Preciso de contrato mesmo para licenciar gratuitamente (freemium)?
Sim. Mesmo em modelos freemium, o contrato (geralmente os Termos de Uso) define os limites de uso, protege a propriedade intelectual, regula a coleta e uso de dados e estabelece as condições de upgrade para planos pagos. A ausência de instrumento formal em produtos gratuitos é uma das vulnerabilidades mais comuns encontradas em auditorias pré-investimento.
Checklist: seu contrato de licenciamento está completo?
Use esta lista para fazer uma primeira avaliação do seu contrato atual:
Como a Legroski aborda contratos de licenciamento
Na Legroski Advogados, contratos de licenciamento de software não são modelos prontos com campos para preencher. São instrumentos construídos a partir da realidade do produto, do modelo de negócio e dos riscos específicos de cada empresa.
Nosso processo envolve entender como o software funciona tecnicamente, mapear os riscos jurídicos antes de redigir uma linha do contrato, escrever cláusulas que protegem sem engessar a operação, e garantir que o contrato acompanha a evolução do produto porque um software de 2026 tem riscos diferentes de um software de 2020.
Atendemos startups e empresas em fase de estruturação, scale-ups que precisam profissionalizar seus contratos antes de uma rodada de investimento, e empresas maduras que vão a M&A e precisam de um IP stack sem passivos ocultos.
Quer revisar ou estruturar o contrato de licenciamento do seu software?
Fale com a gente! Primeira conversa sem custo para mapear onde estão os riscos da sua estrutura contratual atual.
Atualizado em março de 2026 | Por Gabriele Legroski Padilha | Legroski Advogados – Advocacia para Empresas de Tecnologia
@legroski.advogados | comercial@legroski.com