Licenças open source em softwares e SaaS: riscos jurídicos

Licenças open source permitem usar, modificar e distribuir software, mas não eliminam direitos autorais nem obrigações jurídicas. Uma empresa SaaS pode incorporar bibliotecas abertas ao produto e até explorá las comercialmente, desde que identifique a licença aplicável e cumpra suas condições. O risco aparece quando dependências entram no código sem inventário, avisos obrigatórios são removidos, componentes incompatíveis são combinados ou um produto é distribuído sem atender deveres de disponibilização do código correspondente.

Este guia foi preparado para founders, software houses, empresas SaaS e equipes jurídicas que precisam transformar uma lista de pacotes em uma política de governança verificável. A análise correta depende da licença, da forma de uso, das alterações realizadas e, principalmente, de o software ser apenas executado em servidores ou efetivamente entregue a terceiros.

O que são licenças open source?

Uma licença open source é a autorização concedida pelo titular do código para que terceiros possam usar, estudar, modificar e redistribuir o software segundo condições previamente definidas. O código continua protegido. A licença funciona como o conjunto de permissões e deveres que torna lícita a utilização por outras pessoas ou empresas.

A Open Source Initiative mantém uma lista de licenças aprovadas e explica que elas permitem o uso, a modificação e o compartilhamento do software. Isso não torna todos os modelos equivalentes. Algumas licenças exigem apenas a manutenção de um aviso. Outras estabelecem regras sobre patentes, identificação de alterações ou disponibilização do código correspondente quando ocorre distribuição.

No Brasil, programas de computador recebem proteção específica pela Lei nº 9.609 de 1998, complementada, no que for aplicável, pela Lei nº 9.610 de 1998. Por isso, copiar uma biblioteca sem observar a licença não é um detalhe de engenharia. Pode produzir discussão sobre direitos autorais, descumprimento contratual, obrigação de regularização e impacto na exploração comercial do produto.

MIT, Apache 2.0, GPL 3.0 e AGPL: qual é a diferença?

A licença precisa ser lida na versão exata indicada pelo projeto. Usar apenas o nome popular cria erro, pois uma dependência pode adotar uma versão específica, permitir versões posteriores ou combinar licenças. A tabela abaixo resume diferenças úteis para uma triagem inicial, mas não substitui a análise do texto aplicável ao componente.

Licença MIT

A licença MIT concede permissões amplas, inclusive para uso, modificação, distribuição, sublicenciamento e venda. Sua condição central é manter o aviso de direitos autorais e o texto da permissão nas cópias ou partes substanciais. Ela não obriga, por si só, que uma aplicação proprietária publique todo o seu código.

O erro mais comum é interpretar “permissiva” como “sem tarefa”. Se a equipe remove arquivos de licença durante o processo de build ou entrega um aplicativo sem a seção de avisos de terceiros, uma obrigação simples deixa de ser cumprida.

Licença Apache 2.0

A Apache License 2.0 também permite exploração comercial e criação de trabalhos derivados. O texto trata expressamente de licenças de direitos autorais e patentes, exige identificação relevante de arquivos modificados e disciplina a preservação de avisos, inclusive quando o projeto contém um arquivo NOTICE.

Para uma empresa, o processo precisa capturar mais do que o nome “Apache”. É necessário conferir se existe NOTICE, onde ele será reproduzido e como a alteração será identificada na distribuição. A licença também deixa claro que marcas do licenciador não são liberadas automaticamente.

GPL 3.0 e a distribuição do software

A GNU General Public License 3.0 é uma licença copyleft. Em termos práticos, a distribuição de software coberto ou de determinadas obras baseadas nele pode atrair deveres de fornecer o código fonte correspondente, preservar avisos e licenciar o conjunto nos termos exigidos pela GPL.

Nem todo contato técnico com uma biblioteca GPL produz automaticamente o mesmo resultado. A análise considera como os componentes se relacionam, o que é entregue, se há mera comunicação entre programas separados e quais elementos formam uma única obra. É uma questão técnica e jurídica, não um teste baseado apenas no gerenciador de pacotes.

AGPL e serviços acessados pela internet

A GPL 3.0 distingue o uso de um programa em rede da entrega de uma cópia. A AGPL foi criada para incluir uma obrigação específica em certas interações por rede com versões modificadas. Por isso, dizer que “todo SaaS com GPL deve abrir seu código” é impreciso, mas ignorar uma dependência AGPL em uma aplicação online também é arriscado.

O que muda quando o produto é SaaS?

Em um SaaS puramente hospedado, o cliente normalmente acessa funções pela internet e não recebe o código do servidor. Essa arquitetura pode mudar a incidência de deveres ligados à distribuição, especialmente em licenças que usam a entrega de cópias como gatilho. O modelo comercial “SaaS”, porém, não resolve o problema sozinho.

É comum o produto entregar elementos ao usuário ou a parceiros, como:

• aplicativo móvel ou aplicativo para computador;
• código JavaScript executado no navegador;
• SDK para integração;
• conector instalado no ambiente do cliente;
• imagem de contêiner ou pacote para instalação local;
• versão white label ou on premise;
• firmware incorporado a equipamento.

Cada entrega precisa ser mapeada. A empresa que trata todo o produto como “apenas nuvem” pode não perceber que um módulo distribuído carrega obrigações próprias. A revisão deve conversar com a arquitetura, o pipeline de build e o modelo contratual descrito no contrato SaaS com cláusulas essenciais.

Principais riscos jurídicos do open source em software proprietário

1. Não saber quais dependências estão no produto

Uma aplicação moderna pode incorporar centenas de componentes diretos e transitivos. A planilha manual tende a ficar desatualizada. Sem inventário, a empresa não consegue responder quais versões usa, quais licenças se aplicam, onde o componente é distribuído nem quem aprovou a exceção.

O padrão SPDX oferece identificadores padronizados de licenças e uma estrutura para Software Bill of Materials, ou SBOM. A adoção de SBOM não decide a interpretação jurídica, mas torna o conjunto de componentes rastreável e auditável.

2. Misturar licenças incompatíveis

O problema não está apenas em usar um componente isolado. Duas licenças podem impor condições que não convivem no mesmo modo de distribuição. Uma política interna deve definir licenças pré aprovadas, licenças que exigem revisão e licenças bloqueadas para determinados produtos.

3. Remover avisos durante o build

Minificação, empacotamento e criação de imagens de produção podem eliminar arquivos LICENSE, NOTICE e cabeçalhos. O processo de conformidade precisa verificar o artefato que chega ao cliente, não apenas o repositório usado pelo desenvolvedor.

4. Prometer ao cliente uma propriedade intelectual impossível

Contratos comerciais às vezes declaram que todo o software é exclusivo, inteiramente próprio e livre de componentes de terceiros. Isso raramente corresponde à arquitetura real. Uma declaração excessiva pode transformar uma dependência regular em inadimplemento contratual.

A solução é separar código próprio, componentes licenciados, serviços externos e materiais do cliente. O mesmo cuidado deve aparecer no contrato de desenvolvimento de software SaaS.

5. Descobrir o problema durante investimento ou venda

Investidores e compradores avaliam titularidade do código, contratos com desenvolvedores e dependências de terceiros. Um pacote sem licença clara, uma biblioteca copyleft incompatível ou a ausência de cessão de direitos pode reduzir valor, atrasar a operação ou exigir correção antes do fechamento. Esse levantamento deve integrar a due diligence jurídica da startup.

Como criar uma política de compliance open source

Governança eficaz não significa proibir código aberto. Significa estabelecer uma rota rápida para o uso seguro e uma rota de revisão para os casos sensíveis. A norma ISO/IEC 5230, mantida no ecossistema OpenChain, é uma referência útil para estruturar um programa de conformidade de licenças open source.

Checklist prático

• Inventário: gere a lista de componentes diretos e transitivos em cada versão liberada.
• Identificação: registre nome, versão, origem, licença, copyright e local de uso.
• Classificação: defina licenças permitidas, condicionadas e proibidas por tipo de produto.
• Análise de distribuição: mapeie o que permanece no servidor e o que é entregue a clientes, parceiros ou lojas.
• Avisos: produza um arquivo de terceiros e preserve LICENSE, NOTICE e atribuições exigidas.
• Código fonte: quando aplicável, determine como a oferta ou entrega do código correspondente será feita.
• Exceções: documente responsável, fundamento, prazo e medida de mitigação.
• Pipeline: inclua varredura e bloqueio no processo de integração e entrega contínua.
• Contratos: alinhe declarações de propriedade intelectual à composição real do software.
• Auditoria: revise o inventário antes de lançamento, versão relevante, investimento ou aquisição.

Esse processo pode integrar um programa de compliance digital para startups e os cuidados jurídicos antes de lançar um SaaS.

O que exigir em contratos com desenvolvedores e software houses?

O contrato deve transformar o processo técnico em obrigação verificável. Uma cláusula genérica afirmando que “não haverá infração” é insuficiente quando ninguém entrega o inventário nem define o tratamento de uma licença problemática.

Convém tratar, conforme o projeto, dos seguintes pontos:

1. obrigação de informar componentes de terceiros antes da incorporação;
2. lista de licenças autorizadas e fluxo de aprovação de exceções;
3. entrega de SBOM atualizada junto a cada versão relevante;
4. preservação de avisos, atribuições e arquivos exigidos;
5. proibição de componentes sem origem ou licença identificável;
6. correção, substituição ou regularização de componente não autorizado;
7. cooperação em auditorias e diligências de investimento;
8. compatibilidade entre as obrigações open source e as garantias dadas aos clientes;
9. responsabilidade por descumprimento atribuível à parte que escolheu ou inseriu o componente.

A redação precisa considerar o poder real de cada parte. Uma software house não deve garantir fatos fora do seu controle, enquanto a contratante não pode exigir titularidade exclusiva sobre bibliotecas que já pertencem a terceiros. A solução é descrever o que é próprio, o que é licenciado e quais documentos comprovam essa separação.

Quando procurar revisão jurídica?

A revisão é recomendável antes de distribuir um produto com componente copyleft, lançar versão on premise, fornecer SDK, negociar contrato que exige propriedade exclusiva, receber investimento ou comprar uma empresa de software. Também é prudente agir quando uma ferramenta aponta licença desconhecida ou quando o repositório contém código copiado sem histórico verificável.

Quanto mais cedo a análise ocorre, maior a chance de substituir o componente, isolar a arquitetura ou ajustar a documentação sem interromper o produto. Depois que clientes receberam o software, a regularização pode exigir comunicação, nova versão e revisão de declarações contratuais.

Perguntas frequentes sobre licenças open source

Software open source pode ser usado comercialmente?

Sim. Licenças open source aprovadas permitem uso comercial, mas cada uma estabelece condições próprias. A empresa deve verificar a versão da licença, preservar avisos e cumprir eventuais deveres sobre modificações, patentes ou disponibilização do código quando houver distribuição.

Usar código open source obriga a abrir todo o sistema?

Não automaticamente. O efeito depende da licença, da arquitetura, da relação entre os componentes e da forma de entrega. Licenças permissivas normalmente não exigem abertura do sistema proprietário. Licenças copyleft podem impor deveres mais amplos em determinadas distribuições.

A GPL obriga um SaaS a publicar seu código?

A mera execução de software GPL em servidor, sem entrega de cópia, não produz necessariamente o mesmo efeito de uma distribuição. A análise muda com AGPL, aplicativos, SDKs, contêineres, módulos instalados no cliente ou outras entregas. O caso concreto deve ser revisado.

O que é SBOM?

SBOM é um inventário estruturado dos componentes que formam um software. Pode registrar pacotes, versões, fornecedores e licenças. Ela melhora rastreabilidade e auditoria, mas não substitui a análise jurídica sobre compatibilidade, distribuição e cumprimento das condições.

Biblioteca sem licença pode ser usada?

Disponibilidade pública do código não equivale a autorização de uso. Se não há licença identificável, a empresa não deve presumir permissão ampla para copiar, modificar ou distribuir. O caminho seguro é obter autorização, localizar a licença correta ou substituir o componente.

Quem responde por uma dependência inserida por desenvolvedor terceirizado?

A resposta depende do contrato, da participação de cada parte e do dano. A empresa que explora o produto não deve confiar apenas em indenização posterior. O contrato precisa prever aprovação, inventário, correção e cooperação, sem afastar a verificação técnica própria.

É necessário registrar o software no INPI para protegê lo?

A proteção autoral do programa não nasce apenas do registro. O registro pode servir como elemento probatório de autoria e titularidade, mas não corrige licenças de terceiros nem substitui contratos de cessão, documentação de desenvolvimento e governança de dependências.

Conclusão

Licenças open source podem acelerar o desenvolvimento de softwares e SaaS com segurança quando a empresa conhece seus componentes, entende o modo de distribuição e cumpre as condições de cada licença. O maior risco não é usar código aberto. É operar sem inventário, política, documentação e contratos coerentes com a arquitetura real.

O escritório Diego Castro Advogado atua na revisão de licenças, contratos de desenvolvimento, documentação de SaaS e diligências de propriedade intelectual. Uma análise preventiva pode organizar o ativo antes que a inconsistência apareça em uma venda, auditoria ou negociação com investidor. Consulte também como funciona a validade jurídica dos contratos digitais.

Este conteúdo é informativo e não substitui análise jurídica individual da licença, do código, da arquitetura e dos contratos envolvidos.