Licença de software não é rodapé

Licença de software é aquele arquivo que muita gente ignora até o jurídico aparecer na sala, até uma dependência virar risco de distribuição, até um fornecedor mudar as regras no meio do jogo, ou até uma empresa descobrir que “estava no GitHub” não significa “posso enfiar no produto e fingir que nasceu aqui”.

O problema é que licença parece burocracia porque fica no lugar mais sem graça possível do repositório: LICENSE, COPYING, package.json, Cargo.toml, rodapé de documentação. Um canto morto. Um detalhe administrativo. Um texto com cara de contrato que ninguém quer ler porque a vida já é curta o suficiente sem precisar decifrar parágrafo sobre redistribuição, sublicenciamento, patente e ausência de garantia.

Só que esse arquivo pequeno define coisas grandes. Ele define quem pode usar o código. Quem pode vender. Quem pode modificar. Quem precisa devolver mudanças. Quem pode empacotar em uma distribuição Linux. Quem pode transformar aquilo em SaaS. Quem pode fechar o código depois. Quem pode criar um fork sem pedir benção. Quem carrega o custo real de manter a infraestrutura digital que todo mundo usa, inclusive quem aparece depois para capturar valor com a serenidade de quem descobriu fogo.

Licença não é só um rodapé jurídico. É arquitetura social.

E, como toda arquitetura, ela embute política.

Antes de licença virar guerra santa

No começo, software não era exatamente um produto separado. Durante décadas, especialmente no ambiente de universidades, laboratórios, mainframes e centros de pesquisa, código circulava de forma muito mais informal. O valor comercial estava no hardware, no serviço, no acesso à máquina, no contrato de suporte. Software era frequentemente distribuído junto, compartilhado entre pesquisadores e adaptado por quem precisava fazer a máquina trabalhar. A cultura hacker nasceu nesse caldo: pessoas mexendo, corrigindo, melhorando e passando adiante porque era assim que o trabalho avançava.

Isso não quer dizer que o passado era um paraíso comunal de bytes puros e boas intenções. Nunca foi. Empresas sempre tiveram interesses, universidades sempre tiveram regras, e o direito autoral nunca tirou férias. Mas o software ainda não estava tão consolidado como mercadoria autônoma, fechada, empacotada e vendida como unidade central de poder.

Quando o software começou a se separar do hardware e virar produto por si só, a relação mudou. O acesso ao código-fonte deixou de ser algo presumido e passou a ser uma concessão rara. A possibilidade de estudar e modificar um programa saiu do campo da prática cotidiana e entrou no campo da permissão. A máquina continuava sua, mas o comportamento dela passava a ser controlado por alguém que não estava na sala.

É nesse contexto que o movimento do software livre aparece não como uma birra acadêmica contra empresas, mas como reação a uma mudança material na relação entre usuário e computador. A Free Software Foundation define software livre a partir de liberdades: executar o programa para qualquer finalidade, estudar como ele funciona, redistribuir cópias e distribuir versões modificadas. O detalhe importante, que muita tradução ruim enterra, é que “free” ali é liberdade, não preço. Software livre pode ser vendido. O ponto não é “grátis”. O ponto é controle.

Richard Stallman, GNU e a FSF colocaram uma tese forte na mesa: se o usuário não pode estudar, modificar e compartilhar o programa que executa, ele está subordinado ao fornecedor. Pode parecer exagerado quando estamos falando de um utilitário bobo, mas fica menos engraçado quando o software controla seu telefone, seu carro, sua comunicação, seu roteador, sua infraestrutura de produção ou o sistema que decide se você pode trabalhar hoje.

A GPL foi a materialização jurídica dessa tese. Ela usa copyright contra o fechamento do código. Em vez de simplesmente dizer “faça qualquer coisa”, ela diz algo mais específico: você pode usar, estudar, modificar e redistribuir, mas se distribuir uma versão derivada, precisa preservar essas mesmas liberdades para os próximos. Copyleft é isso: reciprocidade forçada por licença. Não é só generosidade; é uma trava arquitetural para impedir que o comum vire insumo gratuito de software proprietário.

Software livre e open source não são sinônimos perfeitos

Em 1998, parte da comunidade passou a usar “open source” como uma forma mais palatável de vender a ideia para empresas. A Open Source Initiative define open source por critérios de licença: redistribuição livre, acesso a código-fonte, permissão para trabalhos derivados, ausência de discriminação contra pessoas, grupos ou campos de atuação, neutralidade tecnológica e por aí vai. É uma definição prática, operacional, muito útil para saber se uma licença permite colaboração real ou se só colocou o código na vitrine.

Mas a troca de nome também foi uma troca de ênfase. O próprio GNU critica essa mudança no texto “Why Open Source Misses the Point of Free Software”: software livre fala de liberdade do usuário; open source tende a falar de eficiência, qualidade, colaboração e vantagem prática. Um discurso pergunta “quem controla o computador?”. O outro pergunta “esse modelo produz software melhor?”.

Na prática, muitos projetos cabem nas duas caixas ao mesmo tempo. Linux, Git, PostgreSQL, Python, Firefox, Apache HTTP Server, LLVM, Kubernetes: o mundo real é cheio de projetos que as pessoas chamam de open source e que também respeitam liberdades fundamentais. O problema começa quando os termos viram maquiagem.

Código disponível não é automaticamente open source. Se você pode ler o código, mas não pode usar comercialmente, modificar livremente, redistribuir ou oferecer em determinados contextos, isso pode ser “source-available”, não open source. A OSI é explícita: open source não significa apenas acesso ao código-fonte. A licença precisa permitir uso, modificação e redistribuição sem discriminar áreas de atuação.

Esse detalhe virou central nos últimos anos porque várias empresas descobriram que “open source” é ótimo para adoção, comunidade e reputação, mas bem desconfortável quando um provedor de nuvem pega o projeto, empacota como serviço gerenciado, ganha dinheiro e devolve pouco. A reação foi uma onda de licenças source-available, como SSPL, BSL e licenças próprias com restrições de oferta como serviço.

Dá para entender a motivação. Também dá para entender a crítica. O fato de uma empresa ter um problema real de captura de valor não transforma automaticamente sua nova licença em open source.

A pergunta certa não é “qual licença é melhor?”

A pergunta “qual licença devo escolher?” parece técnica, mas quase sempre é uma pergunta sobre futuro. Você não está escolhendo apenas como o código pode ser copiado hoje. Você está escolhendo o que pode acontecer se o projeto crescer, se uma empresa usar, se alguém criar um fork, se uma distribuição Linux empacotar, se um provedor de nuvem transformar em serviço, se você perder interesse, se a comunidade discordar da direção, se o projeto virar dependência de gente que você nunca vai conhecer.

Por isso, a resposta honesta começa com outra pergunta: o que você quer proteger?

Se você quer proteger adoção máxima, licenças permissivas costumam ser melhores. Se quer proteger reciprocidade, copyleft faz mais sentido. Se quer proteger uma biblioteca para que ela possa ser usada em produtos fechados sem abrir o produto inteiro, copyleft fraco pode ser o meio-termo. Se quer proteger um servidor contra captura por SaaS, AGPL entra na conversa. Se quer abrir mão praticamente de tudo, CC0 ou Unlicense parecem tentadoras, mas carregam sutilezas jurídicas que muita gente ignora porque “domínio público” soa simples demais.

O erro é escolher por estética. Colocar MIT porque todo mundo coloca. Colocar GPL porque parece mais ideológico. Colocar Apache porque tem cara de empresa séria. Colocar CC-BY porque você já usou em foto. Colocar nada porque “depois eu vejo”. Licença escolhida sem intenção vira arquitetura acidental. E arquitetura acidental é aquele tipo de coisa que só parece barata antes de alguém depender dela.

MIT

A licença MIT é provavelmente a licença permissiva mais reconhecida por desenvolvedores que só querem publicar código sem transformar o repositório em seminário jurídico. Ela permite usar, copiar, modificar, mesclar, publicar, distribuir, sublicenciar e vender cópias do software, desde que o aviso de copyright e a permissão sejam preservados. Em termos práticos, é curta, compreensível e amigável para adoção.

Escolher MIT faz sentido quando o objetivo é reduzir atrito ao máximo. Bibliotecas pequenas, utilitários, projetos pessoais, exemplos educacionais, ferramentas que você quer ver espalhadas pelo mundo, pacotes npm, crates Rust, libs Go e componentes que devem ser incorporados em contextos variados costumam se beneficiar dessa simplicidade. Quem recebe código MIT consegue usar em software livre, open source, proprietário, comercial, interno, embarcado, vendorizado e por aí vai.

O custo dessa liberdade é a apropriação. MIT permite que uma empresa pegue seu código, modifique, feche, venda e não devolva nada além do aviso de copyright. Isso não é abuso da licença. É a licença funcionando exatamente como foi desenhada. Se você escolhe MIT, precisa estar confortável com a possibilidade de o seu trabalho virar parte de um produto fechado sem que melhorias retornem para você ou para a comunidade.

MIT é uma boa escolha quando você prefere adoção a reciprocidade. É uma escolha ruim quando você espera que todos que se beneficiem do projeto devolvam modificações. A licença não faz esse acordo. Ela dá permissão ampla e pede pouco. Reclamar depois que alguém usou amplamente é como publicar “pegue à vontade” e ficar surpreso quando aparece alguém com uma empilhadeira.

BSD

A família BSD tem uma história importante porque vem de um ambiente em que o compartilhamento universitário e a portabilidade Unix moldaram muito do que hoje chamamos de infraestrutura. As versões mais comuns hoje são a BSD 2-Clause e a BSD 3-Clause. A diferença prática mais lembrada é que a BSD 3-Clause adiciona uma cláusula impedindo usar o nome dos autores ou contribuidores para endossar produtos derivados sem permissão.

BSD se parece com MIT na filosofia permissiva: use, copie, modifique, redistribua, inclusive em produto proprietário, preservando avisos básicos. A licença não tenta garantir que modificações voltem. Ela tenta garantir que o código possa circular com pouca fricção. Isso explica por que código BSD apareceu em tantos lugares, inclusive em produtos comerciais e sistemas proprietários.

Escolher BSD faz sentido quando você quer uma licença permissiva clássica, simples e com pedigree forte em sistemas operacionais, redes, ferramentas de baixo nível e infraestrutura. A BSD 3-Clause pode ser preferível quando você quer evitar a interpretação de que sua marca, universidade, empresa ou nome pessoal endossa um derivado. É uma cautela pequena, mas útil. Software não vive só de código; vive também de reputação.

O risco é o mesmo das permissivas: captura sem retorno. A diferença é mais cultural do que operacional. MIT virou a escolha automática de muita biblioteca moderna. BSD carrega uma tradição mais forte de sistemas, userland, rede e componentes fundacionais. Em ambos os casos, se sua preocupação central é impedir fechamento de derivados, você está olhando para a família errada.

Apache 2.0

A Apache License 2.0 também é permissiva, mas não é “MIT com terno e reunião no calendário”. Ela permite uso, modificação, distribuição e sublicenciamento, inclusive em produtos comerciais, mas adiciona uma peça que muda bastante a conversa em ambientes corporativos: concessão explícita de patentes pelos contribuidores, junto com uma cláusula de terminação caso alguém inicie litígio de patente contra o projeto.

Isso importa porque software grande não vive só de copyright. Vive de patente, marca, contribuição corporativa, aquisição, compliance e medo jurídico. Em projetos com empresas grandes, ecossistemas de infraestrutura, APIs, SDKs, plataformas cloud e fundações, Apache 2.0 costuma ser mais confortável do que MIT justamente porque explicita melhor parte do risco que MIT deixa mais silencioso.

Escolher Apache 2.0 faz sentido quando você quer permissividade, mas também quer uma base mais robusta para colaboração empresarial. Kubernetes, Android em várias partes do espaço de usuário, Apache HTTP Server e inúmeros projetos de infraestrutura usam Apache 2.0 ou convivem com ela justamente por esse equilíbrio entre liberdade de adoção e governança jurídica mais madura.

O custo é complexidade. Apache 2.0 é maior, mais formal e tem pontos de compatibilidade que precisam ser verificados. A FSF considera Apache 2.0 compatível com GPLv3, mas não com GPLv2 puro. Esse é o tipo de detalhe que parece irrelevante até você tentar combinar dependências em um produto distribuído. Se o seu projeto é um script de 80 linhas para renomear arquivos, Apache 2.0 talvez seja mais contrato do que problema. Se o projeto tem ambição de virar infraestrutura usada por empresas, ela merece consideração séria.

GPL

A GNU GPL é a licença que mais sofre caricatura. Para alguns, ela é a defesa mais importante da liberdade do usuário. Para outros, é um vírus jurídico que sai contaminando tudo como se o linker fosse uma criatura mitológica. A realidade é menos preguiçosa e mais interessante.

A GPL é uma licença copyleft forte. Ela permite usar, estudar, modificar e redistribuir o software, mas exige que versões derivadas distribuídas preservem as mesmas liberdades. Se você distribui um programa derivado de código GPL, precisa fornecer o código-fonte correspondente sob os termos da GPL. O objetivo não é impedir uso comercial. A própria definição de software livre rejeita restrição de uso comercial. O objetivo é impedir que alguém transforme o trabalho livre em software não livre na distribuição.

Escolher GPL faz sentido quando o projeto é uma aplicação final, ferramenta, componente de sistema ou infraestrutura que você quer manter livre nos derivados distribuídos. Compiladores, sistemas, ferramentas de linha de comando, editores, programas de usuário e componentes em que reciprocidade importa podem ser bons candidatos. O exemplo simbólico é o próprio ecossistema GNU. O kernel Linux usa GPLv2, e isso moldou profundamente a relação entre fabricantes, distribuidores e comunidade.

A GPL pode ser problemática quando você quer que o código seja incorporado livremente por software proprietário. Empresas tendem a evitar dependências GPL em produtos fechados distribuídos porque a obrigação de fornecer código-fonte do derivado pode ser incompatível com o modelo de produto. Isso não faz da GPL uma licença ruim. Faz dela uma licença com uma intenção clara: o código pode viajar, mas não deve perder a liberdade no caminho.

A diferença entre GPLv2 e GPLv3 também não é detalhe decorativo. A GPLv3 adiciona respostas a problemas como tivoização e patentes, enquanto a GPLv2 continua relevante por projetos enormes, especialmente o Linux. O sufixo “or later” também importa. Código “GPLv2 only” não é automaticamente compatível com GPLv3. Código “GPLv2 or later” abre outro caminho. Uma palavra no cabeçalho muda o mapa de composição.

LGPL

A LGPL, ou Lesser General Public License, existe para um problema específico: bibliotecas. Ela é copyleft, mas mais fraca que a GPL. A ideia é permitir que uma biblioteca livre seja usada por programas proprietários sem obrigar que o programa inteiro seja licenciado como GPL, preservando obrigações sobre a própria biblioteca e suas modificações.

Escolher LGPL faz sentido quando você quer que uma biblioteca seja adotada amplamente, inclusive por software fechado, mas não quer que melhorias na biblioteca sejam simplesmente fechadas sem retorno. É um acordo mais pragmático do que a GPL forte. Ele reconhece que uma biblioteca, por natureza, existe para ser chamada por outros programas. Se cada uso exigisse abertura do programa inteiro, muita gente simplesmente não usaria.

O lado chato é que a LGPL traz mais detalhes técnicos de conformidade. Link dinâmico, link estático, possibilidade de substituir a biblioteca, distribuição de objetos relinkáveis, modificações na biblioteca e documentação de compliance entram no radar. Não é uma licença ruim; é uma licença que exige entender como o software é distribuído. Para uma biblioteca C usada por meio de link dinâmico, o cenário é um. Para uma aplicação mobile empacotada com tudo estático e loja no meio, a conversa fica menos confortável.

LGPL é uma boa escolha quando você quer proteger uma biblioteca sem transformar cada consumidor em projeto copyleft. É uma escolha ruim quando você quer simplicidade máxima ou reciprocidade forte no produto final. Ela mora justamente no meio do caminho, e meio do caminho é ótimo quando você sabe por que está nele.

AGPL

A AGPL é a licença que aparece quando alguém olha para SaaS e pergunta: “espera, então você pode modificar um software livre, rodar como serviço, nunca distribuir binário e nunca devolver nada?”. A GPL tradicional é acionada principalmente na distribuição. A AGPL adiciona uma obrigação ligada ao uso pela rede: se você modifica o programa e permite que usuários interajam com ele remotamente, precisa oferecer o código-fonte correspondente aos usuários desse serviço.

Escolher AGPL faz sentido quando o projeto é servidor, plataforma web, banco de dados, sistema multiusuário, ferramenta de colaboração, serviço de rede ou infraestrutura que você teme ver virar oferta SaaS fechada sem retorno. É uma licença pensada para o mundo em que a distribuição deixou de ser “baixar um binário” e passou a ser “chamar uma API”.

O custo é adoção empresarial. Muitas empresas têm políticas internas que bloqueiam AGPL por padrão, justamente porque o gatilho de rede pode criar obrigações indesejadas em produtos SaaS. Isso pode reduzir contribuições, integrações e uso comercial. De novo: não é bug. É design. A AGPL existe para tornar desconfortável exatamente o tipo de captura que o SaaS tornou conveniente.

Se você mantém um serviço que depende de comunidade e quer evitar que um competidor pegue tudo, hospede, feche as melhorias e venda como produto gerenciado, AGPL merece estar na mesa. Se você quer que o software seja usado em qualquer empresa sem conversa com jurídico, AGPL provavelmente vai criar atrito. Às vezes esse atrito é o ponto. Às vezes é tiro no pé.

MPL

A Mozilla Public License 2.0 é uma das licenças mais interessantes para quem acha MIT permissiva demais e GPL forte demais. Ela é um copyleft fraco baseado em arquivo. Em termos práticos, modificações em arquivos MPL precisam continuar sob MPL, mas você pode combinar esses arquivos com código sob outras licenças no mesmo projeto, inclusive código proprietário, respeitando os limites da licença.

Escolher MPL faz sentido quando você quer proteger melhorias no núcleo do projeto sem obrigar que tudo ao redor seja aberto. É uma licença boa para bibliotecas, frameworks, componentes reutilizáveis e projetos que precisam conviver com ecossistemas mistos. Ela permite que o código protegido permaneça aberto, mas não tenta transformar cada integração em um derivado copyleft completo.

O benefício da MPL é que ela conversa bem com a realidade modular do software moderno. Nem todo projeto é um monolito jurídico. Às vezes você quer proteger arquivos específicos, preservar modificações úteis e ainda permitir que empresas integrem o componente em produtos maiores. A MPL oferece essa granularidade.

O risco é que granularidade exige entendimento. “Copyleft por arquivo” é mais sutil do que “pode tudo” ou “derivou, abre”. Times que não têm maturidade de compliance podem errar por ignorância. Mesmo assim, para muitos projetos, MPL é um meio-termo subestimado. Ela não tem o marketing simples da MIT nem a força simbólica da GPL, mas resolve um problema real.

EPL

A Eclipse Public License 2.0 aparece bastante no universo Eclipse, Java, ferramentas corporativas e projetos que nasceram em ambientes com forte preocupação de governança. Assim como a MPL, ela costuma ser entendida como copyleft fraco, mas sua estrutura e linguagem seguem a tradição da Eclipse Foundation e tratam contribuição, distribuição e patente de forma própria.

Escolher EPL faz sentido quando você está em ecossistemas que já adotam essa licença, especialmente projetos ligados à Eclipse Foundation ou ambientes Java corporativos. Licença também é compatibilidade social: usar a licença esperada pelo ecossistema reduz surpresa, facilita contribuição e evita que cada consumidor precise reaprender o contrato.

O risco da EPL é ser menos familiar para muita gente fora desse mundo. Desenvolvedores reconhecem MIT, Apache e GPL quase por reflexo. EPL exige um pouco mais de leitura. Isso não a torna pior, mas aumenta o atrito psicológico. Em projeto que quer adoção ampla fora do ecossistema Eclipse, talvez Apache 2.0 ou MPL sejam mais reconhecíveis. Em projeto que vive naturalmente naquele ambiente, EPL pode ser a escolha óbvia.

CDDL

A CDDL ficou famosa menos por ser moda e mais por um problema específico: ZFS no Linux. A licença nasceu no universo Sun/OpenSolaris e é aprovada pela OSI, mas sua compatibilidade com a GPL é controversa. O caso ZFS/Linux virou exemplo clássico de como duas licenças livres podem não ser combináveis de forma confortável na distribuição de um mesmo trabalho.

Escolher CDDL hoje provavelmente só faz sentido em contextos muito específicos, especialmente se você está mantendo ou contribuindo para código que já vive sob essa licença. Ela não é uma escolha comum para projeto novo. Não porque seja “não livre”, mas porque carrega uma história de compatibilidade que pode assustar distribuidores e integradores.

O caso ZFS é didático porque desmonta a fantasia do “é tudo open source, então pode misturar”. O código está aberto. As licenças são abertas. O software é tecnicamente útil. Ainda assim, distribuir certas combinações pode ser juridicamente arriscado. Compatibilidade de licença não é uma nota de rodapé; é parte da arquitetura do pacote.

CC0

A CC0 é uma tentativa de dedicação ao domínio público, não exatamente uma licença comum. A própria Creative Commons explica que CC0 funciona como uma renúncia de direitos autorais na medida permitida por lei, acompanhada de uma licença fallback quando a renúncia completa não funciona em determinada jurisdição. Em português menos cerimonial: é a tentativa de dizer “não quero reservar direitos autorais sobre isto”.

CC0 faz sentido para dados, exemplos mínimos, snippets pequenos, fixtures, documentação auxiliar, materiais de teste, especificações simples, ícones genéricos, listas e conteúdos em que você quer reduzir atrito quase a zero. Em software, ela pode ser usada, e a própria FAQ da Creative Commons menciona que CC0 é aceitável para software e compatível com GPL, embora a organização recomende contra o uso das licenças Creative Commons comuns para software. Essa distinção importa: CC-BY, CC-BY-SA e companhia foram desenhadas principalmente para conteúdo, não para código.

O problema da CC0 é que “domínio público” não funciona igual em todos os países. Em algumas jurisdições, direitos morais podem não ser renunciáveis da mesma forma que direitos patrimoniais. Isso não significa que CC0 é inútil. Significa que ela tenta aproximar o projeto do domínio público, mas não transforma magicamente todos os sistemas jurídicos do planeta em uma única interpretação conveniente para o seu README.

Escolher CC0 é coerente quando você realmente não quer atribuição obrigatória, reciprocidade, preservação de aviso ou controle sobre derivados. É uma escolha radicalmente permissiva. Justamente por isso, ela é problemática quando você ainda quer algum reconhecimento mínimo, garantia de preservação de aviso, controle de marca ou proteção contra uso que pareça endosso. Se você quer “faça qualquer coisa, inclusive fingir que nunca existi”, CC0 conversa com essa intenção. Se isso te incomoda, não escolha CC0 esperando gratidão espontânea da indústria. Gratidão não é mecanismo de compliance.

Unlicense

A Unlicense tem uma intenção parecida com CC0: colocar o código no domínio público ou o mais próximo possível disso. Ela é curta, popular em alguns círculos e aparece em projetos de gente que quer explicitamente abrir mão de restrições. A diferença é que CC0 foi produzida por uma organização especializada em ferramentas jurídicas globais para o comum, enquanto a Unlicense é uma formulação mais direta, com menos aparato institucional ao redor.

Escolher Unlicense pode fazer sentido para projetos muito pequenos, experimentos, snippets e código que você realmente não se importa que seja usado sem atribuição ou retorno. Mas, para projetos maiores, eu teria cautela. Não porque Unlicense seja automaticamente inválida, e sim porque ela tenta resolver de forma muito simples um problema que varia bastante entre jurisdições. Quando a intenção é “quero o mínimo de atrito possível”, MIT às vezes entrega quase a mesma experiência prática com mais familiaridade para empresas, distribuições e scanners.

Unlicense é o tipo de licença que parece libertária e limpa no README, mas pode gerar mais perguntas do que MIT em uma auditoria corporativa. Se o público do seu projeto é composto por desenvolvedores individuais, talvez ninguém ligue. Se o público inclui empresas grandes, distribuições Linux e departamentos de compliance, familiaridade importa. Chato, mas real.

Licenças Creative Commons que não são CC0

Creative Commons é excelente para textos, imagens, vídeos, músicas, materiais educacionais e documentação. Para software, a própria Creative Commons recomenda contra usar licenças CC comuns em código, porque elas não tratam de forma adequada temas típicos de software, como distribuição de código-fonte, compatibilidade com licenças de software e patentes.

Isso não significa que CC-BY ou CC-BY-SA sejam ruins. Significa que são ferramentas para outro material. Um projeto pode perfeitamente usar MIT no código, CC-BY-SA na documentação, CC0 em dados de teste e uma política separada para marca. Na verdade, essa separação costuma ser mais madura do que tentar enfiar tudo em uma licença só como se código, logo, manual, dataset e screenshot fossem o mesmo tipo de obra.

O ponto é não usar Creative Commons comum em software por preguiça. Se você escreveu código, use licença de software. Se escreveu documentação, aí Creative Commons pode fazer sentido. Se quer abrir mão de direitos de forma radical, CC0 entra na conversa. Cada coisa no seu lugar. Uma revolução conceitual para quem já tentou licenciar logo, manual e backend no mesmo commit.

Sem licença

Sem licença não significa “liberado geral”. Significa quase o oposto. A página No License do Choose a License resume bem: por padrão, uma obra criativa, incluindo código, nasce sob copyright exclusivo. Publicar no GitHub permite certas ações dentro dos termos da plataforma, como visualizar e fazer fork na própria plataforma, mas não dá automaticamente permissão ampla para usar, modificar, distribuir ou incorporar em produto.

Escolher “sem licença” só faz sentido quando você quer que o código seja público para leitura, mas não quer conceder permissões abertas. Isso pode ser válido para portfólio, demonstração, material de estudo ou código que você ainda não decidiu como licenciar. Mas precisa ser intencional. Se você quer colaboração, adoção ou reuso, não colocar licença é basicamente colocar uma placa invisível dizendo “pergunte ao advogado antes”.

Para quem consome código, a regra prática é desagradável: repositório público sem licença deve ser tratado como código sem permissão de uso. Pode parecer paranoia, mas é só copyright funcionando. “Estava no GitHub” é uma defesa ruim. E provavelmente também é uma péssima frase para dizer em reunião com jurídico.

BSL

A Business Source License é uma licença source-available com atraso programado para abertura. Em geral, o código fica disponível sob restrições por um período, e depois muda para uma licença open source definida. A ideia é permitir transparência e acesso ao código enquanto protege um modelo comercial por alguns anos.

Escolher BSL pode fazer sentido para empresa que quer desenvolver em público, ganhar confiança técnica, permitir uso limitado, mas impedir concorrência direta durante um período. Foi o caminho adotado pela HashiCorp quando mudou Terraform e outros produtos de MPL 2.0 para BSL, justificando a decisão no comunicado “HashiCorp adopts Business Source License”. A reação foi o OpenTofu, justamente porque uma mudança de licença em infraestrutura crítica altera confiança, governança e futuro.

O ponto delicado é que BSL não deve ser vendida como open source no período em que restringe usos. Ela pode ser uma estratégia comercial legítima. Pode até ser razoável em alguns produtos. Mas é outra coisa. Chamar de open source porque o código está visível é maquiagem. Código visível não é liberdade de uso.

SSPL

A Server Side Public License nasceu no contexto do MongoDB e mira explicitamente o problema de oferecer software como serviço. Sua lógica amplia obrigações para quem disponibiliza o programa como serviço a terceiros, exigindo abertura de componentes necessários para oferecer esse serviço. A OSI não aprovou a SSPL como licença open source, justamente porque ela impõe restrições que entram em conflito com a definição tradicional de open source.

Escolher SSPL faz sentido se a prioridade é proteger uma empresa ou projeto contra provedores de SaaS que empacotam o software como serviço concorrente. Mas faz pouco sentido se o objetivo é participar do ecossistema open source clássico com distribuição ampla, empacotamento tranquilo e adoção sem susto. SSPL é um recado para cloud vendors. E recados para cloud vendors normalmente assustam também empresas menores, distribuições e comunidades.

Os casos MongoDB, Elastic e Redis mostram que esse terreno é inflamável. Elastic trocou Apache 2.0 por SSPL/Elastic License em 2021 e depois anunciou AGPL como opção em 2024 no texto “Elasticsearch Is Open Source. Again!”. Redis mudou de BSD 3-Clause para RSALv2/SSPLv1 em 2024 no comunicado “Redis Adopts Dual Source-Available Licensing”, o que ajudou a impulsionar o fork Valkey. Essas mudanças não são só ajustes jurídicos. São terremotos de governança.

Licenças próprias e source-available

Licenças próprias com restrições de uso aparecem cada vez mais em bancos de dados, ferramentas de infraestrutura, plataformas de IA, produtos de observabilidade e serviços que vivem sob ameaça de captura por nuvem. Algumas dizem “pode usar, menos para competir comigo”. Outras dizem “pode usar, menos como serviço gerenciado”. Outras permitem uso gratuito até certo faturamento, número de usuários ou contexto.

Essas licenças podem ser razoáveis como estratégia de produto, mas quase nunca são boas para colaboração aberta no sentido clássico. Elas criam incerteza. Distribuições Linux podem evitar. Empresas podem bloquear. Contribuidores podem desconfiar. Forks podem surgir. E o termo “open source” começa a virar embalagem de marketing.

Se a sua intenção é criar um produto comercial com código visível, talvez source-available seja honesto. Só não chame de software livre. Não chame de open source. Não venda restrição como liberdade porque isso só degrada o vocabulário e faz todo mundo perder tempo discutindo semântica enquanto o problema real é poder.

Compatibilidade é onde o README encontra o advogado

Licenças não vivem isoladas. Software moderno é uma lasanha de dependências, transpiladores, bibliotecas, plugins, imagens de container, snippets copiados, código gerado, pacotes vendorizados, binários empacotados e coisas que alguém instalou “só para testar” e que misteriosamente foram parar em produção.

Compatibilidade de licença é a pergunta menos divertida e mais importante: posso combinar esses códigos e distribuir o resultado legalmente?

Nem toda licença livre é compatível com toda licença livre. A própria FSF mantém documentação sobre compatibilidade e relicenciamento, e um exemplo clássico é que GPLv2 e GPLv3 não são automaticamente compatíveis se o código estiver marcado apenas como “GPLv2 only”. Já “GPLv2 or later” abre caminho para usar uma versão posterior. Parece detalhe burocrático. Não é. Uma palavra muda o grafo de composição do projeto.

A incompatibilidade entre CDDL e GPL no caso ZFS/Linux é um dos exemplos mais conhecidos. O ZFS foi liberado pela Sun sob CDDL, enquanto o kernel Linux usa GPLv2. A Software Freedom Conservancy argumenta que distribuir binários combinando ZFS e Linux viola as licenças envolvidas. É por isso que ZFS no Linux vive nesse limbo estranho: tecnicamente útil, desejado por muita gente, mas juridicamente desconfortável para distribuição junto ao kernel.

A parte irritante é que, do ponto de vista do usuário, tudo parece “open source”. O código está lá. As licenças são abertas. O projeto compila. Só que o direito autoral não se importa com sua vontade de montar um NAS bonito no fim de semana.

SPDX, SBOM e a tentativa de não enlouquecer

Em projetos pequenos, licença parece fácil. Você escolhe MIT, Apache, GPL, MPL, coloca um arquivo no repositório e segue a vida. Em projetos reais, a coisa vira inventário.

Uma aplicação moderna pode puxar centenas ou milhares de dependências. Cada uma tem licença própria. Algumas têm múltiplas licenças. Algumas usam exceções. Algumas vendorizam código. Algumas trazem arquivos gerados. Algumas mudam de licença entre versões. Algumas não declaram nada direito. Algumas dependências transitivas só aparecem quando você resolve o lockfile, faz build, empacota uma imagem ou gera um binário estático.

É por isso que identificadores padronizados importam. A SPDX License List fornece identificadores curtos, nomes oficiais, textos de licença e URLs canônicas. Em vez de escrever “GPL 3”, “GPLv3”, “GNU GPL versão três ou posterior talvez”, você usa algo como GPL-3.0-or-later. Em vez de “Apache”, usa Apache-2.0. Parece detalhe de metadado, mas é o tipo de detalhe que permite ferramentas de auditoria funcionarem sem depender de adivinhação mística.

SBOM, scanners de licença, política de dependência e revisão de pacote não são glamour. São encanamento. E, como todo encanamento, só viram assunto quando estoura água no teto.

Microsoft, Rust Coreutils e o detalhe que não é detalhe

O caso Microsoft/Coreutils é interessante justamente porque ele obriga a separar fato, inferência e torcida.

O fato documentado é que o projeto Coreutils for Windows da Microsoft é uma build mantida pela Microsoft de uutils/coreutils, findutils e grep, empacotada para Windows. O repositório diz que o objetivo é tornar comandos, flags e pipelines mais consistentes entre Linux, macOS, WSL, containers e Windows. O projeto uutils/coreutils é uma reimplementação em Rust das GNU Coreutils, com objetivo de ser um substituto compatível e cross-platform. O próprio repositório da Microsoft aparece com licença MIT. O projeto uutils também está sob MIT. Já as GNU Core Utilities são parte do ecossistema GNU e usam GPL.

O que não dá para afirmar, sem fonte primária explícita, é que “a Microsoft escolheu uutils só por causa da licença”. Isso seria chute com roupa de análise. Pode ter sido licença. Pode ter sido portabilidade. Pode ter sido Rust. Pode ter sido integração com Windows. Pode ter sido arquitetura de build. Pode ter sido manutenção. Pode ter sido a soma disso tudo, que é o mais provável.

Mas a licença certamente muda o espaço de decisão. Usar uma base MIT dá à Microsoft muito mais flexibilidade para empacotar, integrar, redistribuir e modificar dentro de um produto comercial sem acionar as obrigações de copyleft da GPL. Para uma empresa que distribui software proprietário em escala planetária, isso não é detalhe. É custo de produto, risco jurídico, governança de supply chain e liberdade de implementação.

A parte engraçada é que o usuário final provavelmente só quer que ls, cp, grep e companhia funcionem no Windows sem precisar montar uma torre de Babel entre PowerShell, WSL, Git Bash, MSYS2 e trauma. Mas a decisão de qual implementação usar carrega uma camada profunda: a Microsoft não está apenas escolhendo uma linguagem ou um port. Está escolhendo um contrato social mais conveniente para o produto dela.

E isso não torna uutils “errado”. MIT permite isso. Esse é o ponto.

O dev e a fantasia do “está público, então posso usar”

Para desenvolvedor, a regra mais prática é simples e desagradável: se não tem licença, você provavelmente não tem permissão.

Isso vale para dependência sem licença, gist aleatório, snippet de issue, resposta de fórum, código colado de blog, projeto abandonado e aquele pacote npm com três downloads semanais que resolve exatamente seu problema de validação de CPF com suporte a runas astrais. Se você está usando no seu computador para brincar, o risco prático é um. Se você está distribuindo binário, imagem Docker, aplicativo mobile, firmware, SDK ou SaaS para cliente, o risco muda de categoria.

Uso interno e distribuição também não são a mesma coisa. Em muitas licenças copyleft, a obrigação forte aparece quando há distribuição. Se você modifica um programa GPL e usa internamente, sem distribuir, normalmente não precisa publicar suas mudanças. A AGPL muda parte desse cenário ao tratar interação via rede como gatilho para disponibilização do código modificado. Isso é justamente o motivo de ela incomodar empresas SaaS e interessar comunidades que querem evitar que o software vire serviço fechado com maquiagem aberta.

Também não dá para resumir tudo em “linkou, contaminou”. A discussão entre link estático, link dinâmico, chamada de processo externo, plugin, API, extensão, header, IPC e serviço remoto depende da licença, do caso concreto e da jurisdição. Às vezes a resposta técnica parece óbvia e a jurídica não é. É aqui que “chamar advogado” deixa de ser piada e vira higiene básica de engenharia.

Não porque todo dev precise virar jurista. Mas porque copiar código sem entender licença é o equivalente jurídico de instalar pacote do AUR sem ler PKGBUILD: funciona até parar de funcionar.

Licença como arquitetura de produto

A licença afeta adoção porque define atrito. Afeta contribuição porque define retorno. Afeta forks porque define quem pode continuar o projeto se a governança azedar. Afeta empacotamento porque distribuições como Debian filtram software com base em critérios de liberdade e redistribuição, formalizados nas Debian Free Software Guidelines. Afeta SaaS porque a rede virou forma dominante de entrega. Afeta bibliotecas porque ninguém quer descobrir tarde demais que uma dependência obriga abrir um produto inteiro. Afeta ferramentas CLI porque elas podem ser distribuídas dentro de sistemas proprietários. Afeta bancos de dados porque provedores de nuvem adoram transformar infraestrutura aberta em serviço gerenciado. Afeta drivers porque integração com kernel e firmware é uma festa de compatibilidade. Afeta frameworks porque adoção depende de confiança de longo prazo.

A licença também afeta a psicologia da comunidade. Um projeto permissivo pode atrair empresas, mas também pode gerar a sensação de que contribuidores voluntários estão subsidiando produto fechado. Um projeto copyleft pode proteger o comum, mas também pode afastar integradores que poderiam financiar desenvolvimento. Um projeto source-available pode proteger receita da empresa, mas quebrar confiança de quem entrou acreditando em open source. Um projeto dual-license pode sustentar um negócio, mas levantar suspeita sobre CLA, relicenciamento e controle centralizado.

Não existe licença perfeita porque não existe objetivo único.

Como escolher sem fingir neutralidade

Se o projeto é um pacote pequeno e você quer que ele seja usado em qualquer lugar, MIT ou BSD provavelmente resolvem. Se você quer permissividade com uma proteção mais explícita de patentes, Apache 2.0 é uma escolha melhor, especialmente em projetos que podem atrair empresas. Se o projeto é uma biblioteca e você quer que ela seja usada por software proprietário, mas quer preservar melhorias na própria biblioteca, LGPL ou MPL podem ser mais coerentes do que GPL forte.

Se o projeto é uma aplicação final e você quer garantir que derivados distribuídos continuem livres, GPL é uma escolha consciente. Se o projeto é um servidor e sua preocupação é captura por SaaS, AGPL é a ferramenta mais direta dentro do campo do software livre. Se o projeto é documentação, material didático, imagem, áudio ou texto, Creative Commons pode ser ótima; se é código, prefira licença de software. Se é um snippet mínimo, dataset, fixtures ou material que você quer colocar o mais perto possível do domínio público, CC0 pode fazer sentido. Se você quer que empresas adotem sem susto, Unlicense pode ser menos confortável do que MIT apesar da intenção parecida.

Se o projeto é produto comercial com código visível, talvez você esteja no território de source-available, open core ou dual licensing. Isso não é automaticamente pecado, mas precisa ser dito com honestidade. O usuário merece saber se está entrando em um commons, em uma vitrine técnica, em um produto aberto só até onde não compete com o fornecedor ou em uma comunidade que pode perder o chão no próximo comunicado de mudança de licença.

O ponto central é não escolher licença pelo template do GitHub. Escolha pelo comportamento que você quer permitir e pelo comportamento que você quer impedir. Licença é um desenho de incentivos. Ela não garante que as pessoas serão justas, mas define o que elas podem fazer quando não forem.

A parte econômica que ninguém gosta de admitir

Open source tem um problema estrutural: todo mundo quer usar, pouca gente quer pagar, e quase ninguém quer manter o pacote que quebra no Natal.

Empresas financiam muito software livre e open source. Isso precisa ser dito porque a narrativa “empresa só explora comunidade” é falsa. Kernel Linux, Kubernetes, LLVM, PostgreSQL, OpenJDK, systemd, Rust, Python, OpenSSL, curl e uma quantidade obscena de infraestrutura crítica recebem contribuição, salário, hospedagem, patrocínio, tempo de engenharia e governança de empresas. Sem isso, muito do que usamos quebraria mais, andaria mais devagar ou dependeria de meia dúzia de mantenedores exaustos sendo pagos em estrela no GitHub e cobrança mal-educada em issue.

Ao mesmo tempo, também é verdade que empresas capturam valor de comunidades sem devolver proporcionalmente. Pegar biblioteca mantida por voluntário, colocar em produto bilionário e tratar o mantenedor como helpdesk gratuito não é colaboração. É extração.

Licença tenta responder a isso, mas não resolve tudo. Permissiva maximiza uso, mas não garante retorno. Copyleft garante reciprocidade em certos cenários, mas não garante dinheiro, manutenção ou governança saudável. Source-available protege empresa, mas pode reduzir confiança e distribuição. Fundação neutra ajuda governança, mas não paga automaticamente o trabalho invisível. CLA pode facilitar relicenciamento e dual licensing, mas também concentrar poder no patrocinador. DCO é mais leve, mas não resolve toda estratégia jurídica.

No fim, licença é uma ferramenta. Governança, financiamento, cultura de contribuição, marca, trademark, roadmap e comunidade são o resto da máquina.

Conclusão: licença é o desenho do poder

Licença de software não decide apenas como o código pode ser copiado. Ela decide como o poder circula ao redor do código.

A GPL não é só uma licença “restritiva”; é uma tentativa de impedir que liberdade vire insumo descartável. MIT e BSD não são licenças “sem consequência”; elas são uma escolha consciente por permissividade, inclusive quando isso permite apropriação proprietária. Apache 2.0 não é só MIT com gravata; sua cláusula de patentes muda a conversa em ambientes corporativos. LGPL e MPL não são indecisão; são respostas para o problema real de bibliotecas e composição. AGPL não é paranoia anti-SaaS; é uma resposta ao fato de que a web mudou o que significa distribuir software. CC0 não é “MIT sem texto”; é uma tentativa de dedicação ao domínio público, com suas próprias sutilezas. Source-available não é open source com nome moderno; é outra categoria, com outras promessas e outras restrições.

A pior escolha é fingir que não há escolha.

Licença não é burocracia. É arquitetura social. É o contrato que define se o código será bem comum, insumo comercial, ferramenta comunitária, produto de empresa, plataforma de colaboração, base de captura ou alguma mistura instável de tudo isso.

E talvez essa seja a parte mais importante: nenhuma licença salva um projeto sozinha. Mas uma licença mal escolhida consegue estragar muita coisa antes do primeiro grande bug de produção.