O código aberto faz o mundo da tecnologia girar, formando até 90% da pilha de software moderna através de estruturas; bibliotecas; bancos de dados; sistemas operacionais; e inúmeras aplicações independentes.
Os benefícios do software de código aberto são bem compreendidos, prometendo maior controle e transparência. No entanto, há uma luta perene entre os reinos de código aberto e proprietário, levando muitas empresas a recuar do código aberto para proteger seus interesses comerciais. No cerne de tudo isso está a espinhosa questão das licenças.
Existem dois tipos amplos de licenças que atendem à definição formal de código aberto, conforme estabelecido pela Open Source Initiative (OSI). Licenças “permissivas” têm poucas restrições em termos de como os usuários podem modificar e distribuir o software, tornando-as populares entre empresas que desejam usá-las comercialmente. E então existem as licenças “copyleft”, que oferecem liberdades semelhantes, mas com uma ressalva notável: qualquer versão modificada do software também deve ser distribuída sob a mesma licença copyleft original. Isso não é tão atraente para empresas que desejam proteger seu trabalho proprietário.
Mas há mais do que isso, com várias licenças existindo dentro de cada categoria. Além disso, existem inúmeras licenças que, embora não sejam estritamente de código aberto, também valem a pena conhecer.
Permissiva
MIT
Originando-se no Massachusetts Institute of Technology na década de 1980, a licença MIT, apropriadamente nomeada, é a licença de código aberto mais popular por métricas, ocupando o primeiro lugar na comunidade de desenvolvimento do GitHub há muitos anos.
Usada por projetos como React (biblioteca JavaScript de front-end) e Ruby (linguagem de programação de propósito geral), a licença MIT permite que os desenvolvedores usem o software como quiserem. Como na maioria das licenças desse tipo, é fornecida sem garantias, o que significa que os autores são isentos de qualquer responsabilidade resultante de danos causados por seu software (por exemplo, perda de dados). Tudo o que os desenvolvedores precisam se preocupar é em incluir o aviso de copyright original e a licença MIT em qualquer trabalho derivado.
Mas a licença MIT tem uma desvantagem: ela não concede explicitamente direitos de patente. Isso significa que se um determinado software depende de tecnologia patenteada, isso pode criar incertezas legais para desenvolvedores que utilizam o software sem garantir permissões separadas para a referida tecnologia patentada.
No entanto, isso sublinha um dos principais pontos de venda da licença MIT: com apenas 200 palavras, a linguagem é simples e concisa. Tornar as coisas confusas com um elaborado discurso de patentes adicionaria complexidade desnecessária para projetos que provavelmente não se preocupam com patentes, como linguagens de programação de alto nível ou frameworks web.
Mas muitos projetos de código aberto intersectam com tecnologias patenteadas, como software centrado em hardware, como o Android.
Apache License 2.0
A Apache Software Foundation publicou a Apache License 2.0 em 2004, uma atualização de uma licença anterior com uma concessão de patente explícita para proteger os usuários de litígios. Portanto, se um desenvolvedor, por exemplo, contribuir com um algoritmo exclusivo de processamento de imagem para um projeto licenciado sob a Apache 2.0, quaisquer patentes que o desenvolvedor detenha sobre aquele algoritmo são automaticamente licenciadas para todos os usuários do software.
A maioria das pessoas estará familiarizada com a marca Android do Google, repleta de loja de aplicativos e uma suíte de ferramentas e serviços próprios. Mas o subjacente Android Open Source Project (AOSP) está substancialmente disponível sob a licença Apache 2.0, uma decisão deliberada do Google em 2008 para combater a Apple e incentivar os fabricantes de telefone a utilizar o Android em vez de outros concorrentes proprietários (por exemplo, Symbian) da época. E funcionou. Samsung, HTC, LG e todos os outros se apressaram no Android.
Um efeito colateral disso, no entanto, é que a Apache License 2.0 possui cerca de cinco vezes o número de palavras da MIT, devido ao texto da concessão de patente, entre outras adições e esclarecimentos. Mas essa é a troca, e ilustra as principais distinções entre as duas licenças de código aberto permissivas mais comuns.
Outras licenças permissivas
A Licença BSD de 2 Cláusulas é semelhante à MIT, mas com diferenças-chave em termos da linguagem utilizada. Por exemplo, especifica que uma cópia da licença deve ser incluída tanto no código-fonte quanto na forma binária compilada. E há a Licença BSD de 3 Cláusulas, que tem uma cláusula adicional de “nenhuma endosse” que restringe o uso dos nomes dos detentores de direitos autorais e dos contribuintes para fins promocionais em qualquer projeto derivado.
Há também a Licença MIT Sem Atribuição (MIT-0), que é mais simples que a MIT, na medida em que não há exigência de atribuição em software derivado. Usar isso é quase como colocar software em domínio público, exceto que o autor retém os direitos autorais e a capacidade de mudar as coisas no futuro.
Copyleft
GNU General Public License (GPL) v. 2.0 e 3.0
A Free Software Foundation (FSF) publicou a GNU General Public License (GPL) em 1989, e foi uma das primeiras licenças copyleft para uso geral.
Licenças copyleft geralmente são mais adequadas para projetos que exigem contribuições da comunidade, em vez de projetos apoiados por uma única entidade corporativa. Ao exigir que todas as modificações permaneçam disponíveis sob a mesma licença de código aberto, isso assegura aos contribuintes que seu trabalho árduo não será utilizado em software proprietário sem também beneficiar a comunidade mais ampla — na teoria, pelo menos, já que pode ser difícil descobrir cada violação e, em seguida, aplicar os termos da licença.
Lançada em 2007, a GPL 3.0 é a terceira licença mais popular, de acordo com os dados do GitHub. A licença trouxe atualizações notáveis sobre a GPL 2.0, incluindo disposições de concessão de patentes e melhor compatibilidade com outras licenças de código aberto. Ela também proíbe o que veio a ser conhecido como “Tivoization”, onde fabricantes de hardware que se beneficiam de software licenciado sob GPL impedem os usuários de instalar versões modificadas daquele software, utilizando mecanismos de gerenciamento de direitos digitais (DRM).
Adotantes notáveis da GPL incluem o WordPress, que está disponível sob uma licença GPL 2.0 “ou posterior”, deixando ao desenvolvedor decidir sob qual licença distribui qualquer modificação.
O Linux, por sua vez, está entre os projetos de código aberto mais bem-sucedidos de todos os tempos, usado em servidores, infraestrutura de nuvem, sistemas embarcados e até mesmo no Android. No entanto, o núcleo subjacente do Linux está disponível apenas sob a licença GPL 2.0, uma vez que o criador do Linux, Linus Torvalds, é contra algumas das disposições adicionadas na versão 3.0 da licença — incluindo a cláusula de Tivoization.
GNU Affero General Public License (AGPL) 3.0
A Affero General Public License (AGPL) é semelhante à GPL 3.0, na medida em que é uma licença copyleft “forte” que promove as liberdades do software e garante que as versões modificadas permaneçam de código aberto. No entanto, uma distinção chave da AGPL é que ela é voltada para serviços e aplicações baseadas na web, onde o software é executado a partir de servidores, em vez de distribuído como arquivos executáveis.
Sob uma licença GPL 3.0, os desenvolvedores não são obrigados a divulgar o código-fonte de software modificado se for executado em uma rede, como acontece com aplicativos SaaS. A licença AGPL fecha essa brecha, exigindo que terceiros disponibilizem o código-fonte mesmo que o software modificado esteja apenas sendo executado a partir de um servidor.
Publicada em 2007 pela Free Software Foundation, a licença AGPL 3.0 cresceu em popularidade em grande parte devido ao aumento da computação em nuvem e SaaS, e hoje é a quinta licença de código aberto mais popular.
GNU Lesser General Public License (LGPL)
Também um produto da Free Software Foundation, a GNU Lesser General Public License (LGPL) é uma licença copyleft “fraca”, na medida em que é mais amigável para negócios, com estipulações menos rigorosas sobre o que deve ser compartilhado. A LGPL é normalmente usada para bibliotecas de software, onde os autores do projeto desejam incentivar contribuições da comunidade, mas permite que software proprietário se vincule às bibliotecas sem a necessidade de abrir todo seu código proprietário. Se alguém modificar a própria biblioteca de código aberto, então deve apenas liberar essas modificações sob a licença LGPL.
Mozilla Public License 2.0
Publicada pela Mozilla Foundation em 2012, a Mozilla Public License (MPL) 2.0 é a décima licença de código aberto mais popular hoje, de acordo com a métrica de licenças do GitHub. A MPL também é uma licença copyleft fraca projetada para proteger o código proprietário enquanto permite que os desenvolvedores se beneficiem do software de código aberto.
No entanto, enquanto a LGPL foca no nível de biblioteca, e a GPL no nível de projeto, a MPL opera em um nível de arquivo individual exigindo que o usuário compartilhe um conjunto mais restrito de código.
Domínio público e creative commons
Embora uma “licença de código aberto” conceda direitos específicos, sempre há estipulações anexadas. Aqueles que desejam colocar seu software inteiramente no domínio público, sem quaisquer ressalvas, no entanto, podem fazê-lo através de outros meios.
Não é suficiente simplesmente publicar software sem uma licença; a lei de direitos autorais se aplica por padrão à maioria das obras criativas, incluindo software. É aqui que uma “dedicação ao domínio público” pode ajudar.
Desenvolvido especificamente para software, o Unlicense é a nona licença mais popular no GitHub (embora se possa debater se pode realmente ser chamado de “licença”). Embora a OSI tenha aprovado como uma licença em 2020, notou que o documento é “mal redigido” e questionou sua eficácia legal em jurisdições (por exemplo, Alemanha) onde não é possível doar trabalho ao domínio público.
Assim como o Unlicense, o CC0-1.0 do Creative Commons também é uma ferramenta de dedicação ao domínio público, embora se concentre mais amplamente em obras criativas. Usa uma linguagem legal mais clara e profissional que pode estar mais em sintonia com a lei internacional. Vale notar que o Creative Commons aplicou para ter o CC0-1.0 aprovado como uma licença compatível com código aberto em 2012, mas retirou a aplicação após a OSI levantar preocupações de que excluía explicitamente concessões de patentes.
Existem outras ferramentas de dedicação pública, como a Licença BSD de zero cláusulas, que pode ser atraente, pois possui uma linguagem ainda mais simples. No entanto, não há consenso sobre o melhor mecanismo para abrir mão de todos os direitos sobre um determinado software.
“Faux-pen” source
Existem inúmeras outras paradas de licenciamento em todo o espectro de software.
Em alguns casos, empresas liberam software sob um modelo de licença dupla, onde o usuário pode escolher entre uma licença de código aberto reconhecida e uma licença comercial, dependendo de suas intenções. Em outros casos, há o “código aberto” que oferece o software sob uma licença de código aberto, mas com recursos principais bloqueados para pagamento. Em outras instâncias, uma empresa pode adicionar um adendo de cláusula comum a uma licença permissiva de código aberto diferente, impondo restrições comerciais.
Também existem muitas licenças que parecem e cheiram a código aberto, mas são incompatíveis com a definição de código aberto.
Em 2018, a gigante de banco de dados MongoDB fez a transição de uma licença copyleft AGPL para a licença pública do lado do servidor (SSPL), uma licença de criação própria da MongoDB. Embora a SSPL ainda seja bastante “aberta”, é o que é conhecido como “disponível por fonte”, na medida em que o código é acessível, mas tem restrições comerciais significativas, o que é um grande “não” para o que a OSI considera.
Os responsáveis do MariaDB seguiram um caminho semelhante com a licença de fonte comercial (BUSL), que impõe restrições comerciais antes de transitar para uma licença de código aberto verdadeira após um determinado número de anos. Existe outro movimento semelhante em andamento que procura tornar a “licença de fonte justa” uma realidade. Isso inclui a Licença de Fonte Funcional, que é considerada uma alternativa mais simples ao BUSL.
Você também poderá encontrar ocasionalmente licenças chamadas de “código ético”, como a Licença Hipocrática, que proíbe o uso de software em violação dos direitos humanos reconhecidos internacionalmente. Da mesma forma, o formato de arquivo JSON padrão aberto possui uma licença extremamente permissiva, com uma cláusula hilariante no final: “O Software deve ser usado para o Bem, não para o Mal.”