Licença open source: o que você pode vender de verdade

Existe um gênero inteiro de conteúdo que promete o mesmo: uma lista de repositórios grátis que substituem software caro, com a sugestão de que basta pegar, colocar uma marca e cobrar mensalidade.

A parte técnica dessa promessa costuma estar correta. Os projetos existem, funcionam e resolvem problemas reais. O que quase nunca aparece na peça é a única informação que decide se o plano é legal: a licença.

O código ser público não diz nada sobre o que você pode fazer com ele. Quem define isso é um arquivo de texto na raiz do repositório, e a diferença entre duas linhas ali dentro é a diferença entre um negócio viável e um passivo jurídico.

O que uma licença faz, em uma frase

Direito autoral é automático. No instante em que alguém escreve código, os direitos são de quem escreveu, e ninguém mais pode copiar, modificar ou redistribuir.

A licença é a concessão que devolve parte desses direitos a você, com condições. Toda a discussão sobre o que você pode fazer com um projeto de terceiro é, na prática, a leitura dessas condições.

Isso explica o caso que mais aparece e menos se comenta: repositório público sem arquivo de licença não é open source. Ele é código protegido que alguém deixou visível. Você pode ler; usar em produto, não.

Os três grupos de licença open source que resolvem 95% dos casos

O Apache 2.0 tem um item a mais que vale conhecer: uma concessão expressa de patente. Em produto corporativo isso costuma ser um diferencial em relação ao MIT, porque reduz uma categoria de risco que o MIT simplesmente não trata.

Permissiva: o caminho curto

MIT e Apache 2.0 permitem uso comercial, modificação e distribuição, inclusive em produto fechado. A obrigação principal é conservar o aviso de copyright e o texto da licença.

É o cenário em que a promessa da lista de repositórios se sustenta de verdade. Você pode pegar o projeto, adaptar, vender e não abrir nada.

Copyleft: o fonte acompanha o binário

A GPL permite a mesma coisa, com uma condição: quem recebe o software tem direito ao código-fonte, inclusive das suas modificações, sob a mesma licença.

Para software instalado no cliente, isso costuma ser incompatível com produto proprietário. Para uso interno, não gera obrigação nenhuma, porque não houve distribuição.

AGPL: onde o "pegue e venda" quebra

A AGPL foi escrita para fechar exatamente a brecha que a operação de SaaS usava. Na GPL clássica, rodar o programa num servidor e entregar só a interface pela internet não era distribuição, então a obrigação nunca disparava.

A AGPL trata a interação pela rede como o gatilho. Se o seu serviço roda um derivado de um projeto AGPL, os usuários do serviço têm direito ao código-fonte modificado.

Na prática, isso não impede que você cobre pelo serviço. Impede que você mantenha fechada a parte derivada, que costuma ser justamente onde está o trabalho de diferenciação. É por isso que projetos populares sob AGPL viram base de operação comercial com muito menos frequência do que as listas sugerem.

Open core e fonte disponível: as categorias que confundem

Duas famílias que aparecem como open source e não se comportam como tal.

• Open core. O núcleo é open source de verdade, sob licença reconhecida. Os recursos que empresa paga para ter, como autenticação corporativa, auditoria e multi-tenant, ficam num módulo proprietário. O repositório é honesto; a leitura apressada é que erra, porque o que você precisa para vender está do lado fechado.
• Fonte disponível. Licenças como a BSL e a SSPL publicam o código e proíbem usos específicos, tipicamente oferecer o produto como serviço concorrente, às vezes por um prazo após o qual a versão migra para uma licença aberta. É uma resposta comercial a provedores de nuvem, e é legítima. Só não é open source, e a Open Source Initiative não reconhece essas licenças como tal.

A confusão custa caro porque acontece na direção errada: a empresa planeja o produto acreditando que pode revender e descobre a restrição depois de meses de desenvolvimento.

O checklist antes de construir em cima

Cinco verificações, em ordem de custo se você errar:

1. Abra o arquivo LICENSE na raiz. Não o README, não o badge, não o que o post disse. Badge desatualizado é comum, e mudança de licença no meio da vida do projeto acontece.
2. Confira se o monorepo tem licenças diferentes por pasta. Projeto com cliente, servidor e SDK separados às vezes licencia cada parte de um jeito.
3. Veja a licença das dependências, não só a do projeto. Um projeto MIT que depende de uma biblioteca GPL carrega a obrigação dela para dentro do seu produto.
4. Confira se há acordo de contribuição. Projeto com CLA costuma ter uma empresa dona dos direitos, e empresa dona pode mudar a licença nas versões seguintes. Já aconteceu com projetos grandes mais de uma vez.
5. Registre a decisão. Que licença, qual versão do projeto, em que data, e quem leu. É a única defesa quando a pergunta voltar dois anos depois, numa due diligence.

Esse último item parece burocracia e é o que salva a operação. Na hora de uma auditoria ou de uma venda da empresa, a pergunta não é se o código é livre. É se você consegue provar sob quais condições ele entrou.

E o que isso muda na decisão de fazer ou comprar

A licença entra na conta antes do custo de desenvolvimento, porque ela define o teto do que o produto pode ser.

Repare na última linha, porque ela é a saída que quase nenhuma lista menciona. Vender implantação, integração, suporte e operação de um projeto AGPL é perfeitamente viável, e não dispara nada, desde que você não distribua derivado fechado. O produto, nesse caso, é o seu trabalho, e a discussão passa a ser de precificação de serviço, não de licença.

O mesmo raciocínio vale quando a escolha é entre adotar um projeto aberto e contratar uma solução pronta, assunto que o blog já trata em alternativas open source de IA e em CRM open source.

O ponto que fica

A frase "é open source, então é grátis" resolve o custo de aquisição e não resolve nenhuma das perguntas que vêm depois.

Antes de escolher um projeto para construir em cima, o trabalho é de dez minutos: abrir o LICENSE, identificar o grupo, conferir as dependências e registrar a decisão. Fazer isso depois de seis meses de desenvolvimento custa o projeto inteiro, e essa é a única parte da história que as listas de repositórios nunca contam.