O problema de não ler a licença
Todo mundo já fez isso: encontrou um projeto open source no GitHub, leu que era “MIT License” ou “GPL”, deu um npm install ou git clone, e seguiu a vida. A pergunta que ninguém faz na hora é: o que exatamente essa licença me permite fazer?
O problema é que “open source” não significa a mesma coisa para todo projeto. Existem dezenas de licenças diferentes, cada uma com regras específicas sobre uso comercial, modificação, distribuição e obrigações de compartilhar o código.
E a diferença entre uma licença e outra pode significar:
- Você poder ou não vender um serviço baseado naquele código
- Você ter ou não que abrir o código das suas modificações
- Você poder ou não trocar o nome e logo e vender como se fosse seu
- Você estar ou não protegido contra processos de patente
As duas grandes famílias
Antes de mergulhar nas licenças específicas, é importante entender a divisão fundamental:
Licenças permissivas — permitem usar, modificar e distribuir o software com mínimas restrições. Você pode incorporar o código em produtos proprietários, fechados, e não precisa publicar suas alterações. Exemplos: MIT, Apache 2.0, BSD.
Licenças copyleft — permitem usar e modificar, mas exigem que alterações e trabalhos derivados sejam distribuídos sob a mesma licença. A lógica é garantir que o código permaneça aberto. Exemplos: GPL, AGPL, LGPL.
Dentro do copyleft, ainda existe variação de força: o GPL é considerado “copyleft forte” (qualquer trabalho derivado precisa ser GPL), enquanto o LGPL é “copyleft fraco” (só as alterações na biblioteca precisam ser abertas).
As licenças que você mais vai encontrar
MIT
A licença mais popular do ecossistema open source (cerca de 95% dos projetos no GitHub usam alguma variação). É extremamente permissiva: você pode usar, modificar, distribuir, sublicenciar e vender o software. A única exigência é manter o aviso de copyright e a licença original.
Na prática: você pode pegar um projeto MIT, modificar todo o código, trocar o nome e logo, e vender como seu produto proprietário — sem precisar abrir o código das suas alterações.
Projetos famosos: React, Node.js, jQuery, Rails, Babel.
Apache 2.0
Similar ao MIT, mas com um adicional importante: inclui uma concessão explícita de direitos de patente. Isso significa que quem contribui com o código também concede uma licença de patente para quem usa o software. Se alguém tentar processar você por violação de patente relacionada ao software, a licença é automaticamente rescindida para essa pessoa.
Na prática: é a escolha mais segura para projetos empresariais, especialmente se envolvem tecnologia patenteável.
Projetos famosos: Kubernetes, Docker, Android, Apache HTTP Server.
GPL (General Public License)
A licença copyleft original, criada por Richard Stallman e a Free Software Foundation. Se você distribui um software que contém código GPL — seja modificado ou não — você é obrigado a distribuir o código fonte completo sob a mesma licença GPL.
A pegadinha: essa obrigação só vale se você distribuir o software. Se você usa internamente na sua empresa, sem distribuir para terceiros, não precisa abrir nada. É por isso que empresas podem rodar sistemas GPL internamente sem problemas.
Projetos famosos: Linux (GPL v2), WordPress, Ansible, Git.
AGPL (Affero GPL)
Fechou a brecha do GPL para SaaS. Se o GPL exige compartilhamento do código só quando há distribuição, a AGPL considera que disponibilizar o software como serviço online também conta como distribuição. Isso significa que se você modifica um software AGPL e oferece como SaaS para clientes, você precisa disponibilizar o código fonte das suas modificações.
Projetos famosos: MongoDB (mudou para SSPL depois), Nextcloud, Mastodon.
LGPL (Lesser GPL)
Pensada para bibliotecas. Permite que você use a biblioteca LGPL em projetos proprietários sem precisar abrir o código do seu projeto — desde que você não modifique a própria biblioteca. Se você modificar a biblioteca, as alterações precisam ser LGPL.
Projetos famosos: Qt, OpenOffice, FFmpeg.
MPL (Mozilla Public License)
Um meio termo interessante. Exige que arquivos modificados permaneçam sob MPL, mas permite que novos arquivos adicionados ao projeto tenham licenças diferentes (inclusive proprietárias). É um copyleft em nível de arquivo.
Projetos famosos: Firefox, Thunderbird.
E quando não é open source de verdade?
Nem todo projeto com código disponível é open source. Existe uma categoria chamada “source-available” ou “fair-code”: o código está público, mas a licença não é aprovada pela OSI (Open Source Initiative) e impõe restrições de uso comercial.
O n8n é um exemplo clássico. Ele usa a Sustainable Use License, que:
- Permite uso interno gratuito em empresas de qualquer porte
- Permite oferecer consultoria e serviços baseados no n8n
- Permite usar o n8n como parte do seu produto interno
- Não permite revender o n8n como serviço hospedado para terceiros sem uma licença Enterprise
- Anteriormente tinha limite de faturamento (~US$ 30k/ano para uso comercial irrestrito), mas versões recentes simplificaram para “uso interno é livre, revenda como SaaS precisa de licença”
Outros exemplos de licenças não-OSI:
- SSPL (MongoDB, Elasticsearch) — permite uso interno gratuito, mas oferecer como SaaS exige abrir todo o stack, não só o código modificado
- BSL (Business Source License, usada por MariaDB, CockroachDB) — código aberto, mas com restrições comerciais que expiram após alguns anos (conversão automática para GPL ou Apache)
- Commons Clause — adicionada sobre uma licença open source existente para restringir revenda
Casos práticos do dia a dia
Uso interno na empresa
Na grande maioria dos casos, não importa a licença: você pode baixar, instalar e usar qualquer software open source internamente. Seja MIT, GPL, AGPL — uso interno é sempre permitido. O problema começa quando você distribui o software ou oferece como serviço.
SaaS: você hospeda e vende
Se você quer pegar um software open source, hospedar e vender como serviço para clientes:
- MIT / Apache / BSD: pode. Sem restrições.
- GPL: pode. A “brecha do SaaS” permite porque você não está distribuindo o software, só oferecendo acesso.
- AGPL: não pode sem abrir suas modificações. A licença fecha a brecha.
- Sustainable Use License (n8n): não pode sem licença Enterprise.
Rebranding: trocar o nome e vender como seu
Se você quer pegar um projeto, modificar, trocar o nome e logo, e vender:
- MIT / Apache: pode completamente.
- GPL: pode, mas precisa manter o código aberto sob GPL.
- AGPL: pode, mas precisa manter o código aberto sob AGPL e qualquer usuário do seu SaaS tem direito ao código fonte.
- Licenças restritivas (PerfexCRM e similares): não pode. O código está disponível para consulta, mas você não tem permissão para modificar ou redistribuir.
Cliente pediu o código fonte
Depende da licença:
- MIT / Apache: você não é obrigado a entregar o código fonte se não fez modificações. Se modificou, também não precisa — a licença não exige distribuição do fonte.
- GPL: se você distribuiu o software para o cliente, precisa entregar o código fonte completo, incluindo suas modificações, sob GPL.
- AGPL: se você oferece como SaaS e o cliente pede, precisa entregar o código fonte (a licença considera o acesso via rede como distribuição).
Tabela resumo
| Licença | Uso interno | SaaS | Revenda | Rebranding | Precisa abrir fonte? |
|---|---|---|---|---|---|
| MIT | OK | OK | OK | OK | Não |
| Apache 2.0 | OK | OK | OK | OK | Não |
| BSD | OK | OK | OK | OK | Não |
| GPL | OK | OK (brecha) | Condicional | Condicional | Sim, se distribuir |
| LGPL | OK | OK | Condicional | Condicional | Só alterações na lib |
| AGPL | OK | Obriga abrir | Condicional | Condicional | Sim, inclusive SaaS |
| MPL | OK | OK | Condicional | Condicional | Só arquivos modificados |
| Sustainable Use | OK | Proibido sem licença | Proibido sem licença | Proibido | N/A |
E o PerfexCRM?
O PerfexCRM é um caso interessante: ele é descrito como “open source” porque o código fonte é acessível, mas a licença dele é restritiva — você pode usar para seus projetos, mas não pode redistribuir, modificar ou criar trabalhos derivados. Na prática, é mais próximo de um software proprietário com código visível do que de open source de verdade. Sempre vale ler o arquivo LICENSE que acompanha o projeto.
A recomendação
Se você está começando um projeto e quer escolher uma licença:
- MIT se quer máxima adoção, sem preocupações
- Apache 2.0 se quer o mesmo do MIT mas com proteção de patentes
- GPL se quer garantir que melhorias voltem para a comunidade
- AGPL se quer fechar a brecha do SaaS e garantir que serviços hospedados também compartilhem alterações
E se você está usando um projeto open source: sempre leia a licença antes de construir um negócio em cima dele. Uma licença restritiva ou um modelo fair-code pode inviabilizar seu modelo de negócio se descoberto tarde demais.
A regra de ouro: se o projeto tem uma licença aprovada pela OSI, você provavelmente está seguro. Se tem uma licença personalizada, “fair-code”, “source-available” ou “Sustainable Use License”, leia com atenção — podem existir restrições que impactam diretamente seu negócio.