Usar software open source não significa usar código sem regras. Toda licença open source é um contrato de licenciamento: o autor mantém a titularidade sobre o programa e autoriza o uso sob condições específicas. Descumprir essas condições encerra a autorização e transforma o uso legítimo em violação de direito autoral, protegido no Brasil pela Lei 9.609/98, que trata da proteção da propriedade intelectual de programa de computador.
Para uma empresa de tecnologia, a pergunta central não é “posso usar este componente”, mas “sob quais obrigações”. Uma licença permissiva como MIT pede pouco. Uma licença copyleft como a GPL pode obrigar sua empresa a abrir o código-fonte do produto que a incorpora. A diferença entre uma e outra decide se seu software pode ser licenciado comercialmente como proprietário ou não.
Este guia separa os tipos de licença, explica as obrigações que cada família impõe e mapeia os riscos que costumam aparecer tarde demais: em due diligence, rodada de investimento ou notificação de titular.
Licença open source é contrato, não ausência de dono
Código aberto e código sem dono são coisas diferentes. Quando um desenvolvedor publica software sob licença open source, ele não abre mão da titularidade. Ele concede uma autorização de uso condicionada aos termos daquela licença.
A base dessa autorização está na Lei 9.610/98, que trata dos direitos autorais e, no seu art. 49, disciplina a transferência e o licenciamento de direitos. O programa de computador tem regime próprio na Lei 9.609/98, que remete supletivamente à lei autoral. O autor pode licenciar o uso nas condições que definir, e a licença open source é exatamente esse instrumento.
A consequência prática é direta: se você usa o componente fora das condições da licença, a autorização deixa de existir. Não há mais base jurídica para o uso. O que era uso lícito passa a ser reprodução e distribuição não autorizada de obra protegida.
As três famílias de licença que importam
As licenças open source se agrupam por grau de exigência. Entender a família resolve a maior parte das decisões antes de ler o texto integral.
Permissivas: MIT e BSD
A licença MIT é o modelo mais simples. Autoriza uso, cópia, modificação, fusão, publicação, distribuição e sublicenciamento, inclusive em produto proprietário e comercial. A única obrigação relevante é manter o aviso de copyright e o texto da licença nas cópias ou partes substanciais do software.
Traduzindo: você pega o componente MIT, incorpora no seu produto fechado, vende e não precisa abrir seu código. Basta preservar a atribuição de autoria. As licenças BSD seguem lógica próxima, com variações menores.
Permissiva com cláusula de patente: Apache 2.0
A Apache 2.0 é permissiva como a MIT, mas adiciona duas camadas. A primeira é uma concessão expressa de licença de patente: quem contribui com código concede aos usuários uma licença sobre as patentes envolvidas naquela contribuição. A segunda é a exigência de documentar alterações feitas nos arquivos modificados.
Para empresas que se preocupam com litígio de patentes, a cláusula da Apache oferece previsibilidade que a MIT não traz. É uma das razões pelas quais projetos corporativos de grande porte a preferem.
Copyleft: GPL e LGPL
A GPL (General Public License) opera pela lógica do copyleft: quem recebe o software pode usá-lo e modificá-lo, mas se distribuir uma obra derivada, precisa distribuí-la também sob GPL, com o código-fonte disponível.
O ponto crítico para empresa de tecnologia é o efeito de contaminação. Se você incorpora código GPL no seu produto proprietário e distribui esse produto, a obrigação de abrir o código-fonte pode alcançar a distribuição inteira. Isso colide frontalmente com um modelo de negócio baseado em software fechado.
A LGPL (Lesser GPL) suaviza essa lógica para bibliotecas: em regra, linkar contra uma biblioteca LGPL não obriga a abrir o produto que a utiliza, desde que respeitadas as condições de substituição da biblioteca. A diferença entre GPL e LGPL não é cosmética: define se você pode ou não vender seu produto como proprietário.
Distribuição é o gatilho: uso interno versus produto entregue
A maioria das obrigações copyleft só é acionada quando há distribuição. Enquanto o software roda apenas dentro da sua empresa, sem entrega a terceiros, a GPL em regra não obriga você a abrir nada.
Isso muda quando você entrega o produto: instalador, dispositivo, biblioteca embarcada, aplicativo distribuído. Aí a obrigação de disponibilizar o código-fonte da obra derivada se torna exigível para quem recebe.
O modelo de software como serviço (SaaS) cria uma zona sensível. Na GPL clássica, rodar o software em servidor e oferecê-lo pela rede não é distribuição no sentido tradicional. A licença AGPL foi criada justamente para fechar essa lacuna: ela estende a obrigação de abertura ao acesso pela rede. Um componente AGPL no backend de um SaaS proprietário exige análise específica, porque pode disparar a obrigação de disponibilizar o código aos usuários do serviço.
Compatibilidade entre licenças: o risco que se esconde nas dependências
Um produto de tecnologia moderno não usa uma licença. Usa dezenas ou centenas, somando dependências diretas e transitivas. Cada biblioteca traz outras bibliotecas, e cada uma tem sua própria licença.
O problema surge na combinação. Nem toda licença é compatível com outra. Código GPL combinado com código sob licença incompatível gera uma obra que não pode ser distribuída legalmente sob nenhuma das duas. Uma dependência transitiva GPL, três níveis abaixo na árvore, pode contaminar um produto que o time acredita ser totalmente permissivo.
A forma de controlar isso é o inventário de licenças, frequentemente materializado num SBOM (Software Bill of Materials): a lista completa de componentes e suas respectivas licenças. Ferramentas de análise de composição de software geram esse inventário automaticamente. A interpretação da compatibilidade jurídica entre as licenças listadas, no entanto, não é automática.
| Família | Exemplos | Uso em produto proprietário | Obrigação principal |
|---|---|---|---|
| Permissiva | MIT, BSD | Livre | Manter aviso de copyright |
| Permissiva com patente | Apache 2.0 | Livre | Atribuição + documentar alterações |
| Copyleft forte | GPL | Restrito na distribuição | Abrir código-fonte da obra derivada |
| Copyleft de biblioteca | LGPL | Permitido com condições | Permitir substituição da biblioteca |
| Copyleft de rede | AGPL | Restrito inclusive em SaaS | Abrir código aos usuários do serviço |
O que diz a lei
No Brasil, programa de computador é protegido pela Lei 9.609/98, que lhe dá o regime das obras literárias (art. 2º) e regula o contrato de licença de uso (art. 9º). A ela se aplica supletivamente a Lei 9.610/98, sobre direitos autorais.
O art. 49 da Lei 9.610/98 disciplina a transferência e o licenciamento dos direitos do autor. A licença open source é uma modalidade de licenciamento voluntário: o titular autoriza o uso nas condições que estabelecer. Essas condições são vinculantes. Quando não cumpridas, a autorização não subsiste, e o uso passa a ser não autorizado.
A violação de direito autoral sobre programa de computador expõe o infrator às sanções civis das duas leis (cessação do uso e reparação de danos) e, no plano penal, ao art. 12 da Lei 9.609/98. Não existe no ordenamento uma isenção genérica para “software livre”: o caráter aberto do código não afasta a proteção autoral nem torna dispensável o cumprimento dos termos da licença.
Litígios sobre licença open source ainda são raros no Brasil, mas a proteção autoral do programa de computador e a validade das licenças de uso são reconhecidas na prática dos tribunais. O ponto de partida da análise é sempre o texto da licença aplicável combinado com a titularidade sobre a obra.
Quando vale procurar advogado
Boa parte das decisões de licenciamento pode ser resolvida internamente. Se sua empresa usa apenas componentes MIT e Apache, mantém os avisos de copyright e não distribui código GPL, o risco é baixo e o próprio time de engenharia consegue gerir a conformidade com um SBOM atualizado.
A análise jurídica se torna necessária em situações específicas. Presença de componentes GPL ou AGPL em produto que você distribui ou oferece como SaaS proprietário. Dúvida sobre se a arquitetura do software dispara a obrigação de copyleft (linkar, incorporar ou derivar). Preparação para due diligence em rodada de investimento ou aquisição, quando o inventário de licenças será auditado por terceiros. Recebimento de notificação de titular alegando descumprimento de licença.
Também vale antecipar a análise quando sua empresa pretende licenciar seu próprio software, seja para escolher uma licença open source de saída, seja para estruturar licenciamento comercial que conviva com componentes de terceiros. Se a dúvida é sobre proteger a tecnologia em si, o post sobre patente de software separa o que é código, invenção e segredo.
O custo de corrigir uma incompatibilidade de licença antes do lançamento é baixo. O custo de descobrir a contaminação durante a due diligence, com o produto já no mercado, é outro: retrabalho de engenharia, atraso na operação e redução de valuation.
Licença open source não é permissão irrestrita. É um contrato que define o perímetro do que sua empresa pode fazer com o código de terceiros e, por consequência, com o próprio produto. Tratar cada licença como parte da arquitetura jurídica do software, e não como detalhe do repositório, é o que separa uma base de código auditável de um passivo latente.
Mapear as licenças presentes no seu produto, avaliar a compatibilidade entre elas e definir uma política interna de uso são medidas que reduzem risco antes que ele apareça no pior momento possível.