O código aberto faz o mundo da tecnologia girar, formando até 90% da pilha de software moderna por meio de estruturas; bibliotecas; bancos de dados; sistemas operacionais; e inúmeros aplicativos 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 o domínio do código aberto e o domínio proprietário, levando muitas empresas a abandonar o código aberto para proteger os seus interesses comerciais. No centro de tudo isto está a espinhosa questão do licenciamento.
Existem dois tipos amplos de licenças que atendem à definição formal de código aberto estabelecida pela Open Source Initiative (OSI). As licenças “permissivas” trazem poucas restrições em termos de como os usuários podem modificar e distribuir o software, tornando-as populares entre as empresas que desejam utilizá-lo comercialmente. E há também 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. Isto 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 existentes em cada intervalo. Além disso, existem inúmeras licenças que, embora não sejam estritamente de código aberto, também vale a pena conhecer.
Permissivo
MIT
Originada no Instituto de Tecnologia de Massachusetts na década de 1980, a licença apropriadamente chamada MIT é a licença de código aberto mais popular pela maioria das métricas, ocupando o primeiro lugar entre a comunidade de desenvolvimento do GitHub por muitos anos.
Usada por projetos como React (biblioteca JavaScript front-end) e Ruby (linguagem de programação de uso geral), a licença MIT permite que os desenvolvedores usem o software como quiserem. Tal como acontece com a maioria dessas licenças, ela é fornecida sem garantias, o que significa que os autores estão isentos de qualquer responsabilidade resultante de danos causados pelo seu software (por exemplo, perda de dados). Todos os desenvolvedores precisam se preocupar em incluir o aviso de direitos autorais original e a licença do MIT em qualquer trabalho derivado.
Mas a licença do MIT tem uma falha: não concede explicitamente direitos de patente. Isto significa que se um determinado software depende de tecnologia patenteada, isso pode criar incerteza jurídica para os desenvolvedores que implantam o software sem garantir permissões separadas para a referida tecnologia patenteada.
No entanto, isto sublinha um dos principais pontos de venda da licença do MIT: com apenas 200 palavras, a linguagem é simples e concisa. Confundir as coisas com um discurso ambíguo e cheio de palavras sobre patentes adicionaria complexidade desnecessária para projetos que provavelmente não se preocuparão com patentes, como linguagens de programação de alto nível ou estruturas da web.
Mas muitos projetos de código aberto cruzam-se com tecnologias patenteadas, como software centrado em hardware, como o Android.
Licença Apache 2.0
A Apache Software Foundation publicou a Licença Apache 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 de processamento de imagem exclusivo para um projeto licenciado sob o Apache 2.0, quaisquer patentes que o desenvolvedor detenha sobre esse algoritmo serã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 conjunto de ferramentas e serviços desenvolvidos internamente. Mas o Android Open Source Project (AOSP) subjacente está substancialmente disponível sob a licença Apache 2.0, uma medida deliberada do Google em 2008 para combater a Apple e encorajar os fabricantes de telefones a usar o Android em vez de outros proprietários proprietários (por exemplo, Symbian) da época. E funcionou. Samsung, HTC, LG e todo o resto aderiram ao Android.
Um subproduto disso, porém, é que a Licença Apache 2.0 tem cerca de cinco vezes o número de palavras do MIT, devido ao texto de concessão de patente, entre outros acréscimos e esclarecimentos. Mas essa é a contrapartida e ilustra as principais distinções entre as duas licenças permissivas de código aberto mais comuns.
Outras licenças permissivas
A licença BSD de 2 cláusulas é semelhante ao MIT, mas com diferenças importantes em termos da linguagem usada. 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á também a Licença BSD de 3 cláusulas, que possui uma cláusula adicional de “sem endosso” que restringe o uso dos nomes dos detentores de direitos autorais e colaboradores para fins promocionais em qualquer projeto derivado.
Existe também a MIT No Attribution License (MIT-0), que é mais simples que o MIT, pois não há exigência de atribuição em software derivado. Usar isso é quase colocar o 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
Licença Pública Geral GNU (GPL) v. 2,0 e 3,0
A Free Software Foundation (FSF) publicou a Licença Pública Geral GNU (GPL) em 1989 e foi uma das primeiras licenças copyleft para uso geral.
As licenças Copyleft são muitas vezes mais adequadas para projetos que requerem contribuições da comunidade, em comparação com 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 garante aos colaboradores que seu trabalho árduo não será usado em software proprietário sem também beneficiar a comunidade em geral – pelo menos em teoria, pois pode ser difícil descobrir cada violação e, em seguida, fazer cumprir os termos da licença.
Lançada em 2007, a GPL 3.0 é a terceira licença mais popular, segundo dados do GitHub. A licença introduziu atualizações notáveis na GPL 2.0, incluindo disposições sobre concessão de patentes e melhor compatibilidade com outras licenças de código aberto. Também proíbe o que veio a ser conhecido como “Tivoização”, onde os fabricantes de hardware que se beneficiam de software licenciado pela GPL impedem os usuários de instalar versões modificadas desse software, usando mecanismos de gerenciamento de direitos digitais (DRM).
Os adotantes notáveis da GPL incluem o WordPress, que está disponível sob uma licença GPL 2.0 “ou posterior”, deixando para o desenvolvedor decidir sob qual licença distribuirá qualquer modificação.
O Linux, por sua vez, está entre os projetos de código aberto de maior sucesso de todos os tempos, utilizado em servidores, infraestrutura em nuvem, sistemas embarcados e até mesmo Android. No entanto, o kernel Linux subjacente só está disponível sob uma licença GPL 2.0, visto 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 Tivoization.
Licença Pública Geral GNU (AGPL) 3.0
A Licença Pública Geral Affero (AGPL) é semelhante à GPL 3.0, na medida em que é uma licença copyleft “forte” que promove liberdades de software e garante que as versões modificadas permaneçam de código aberto. No entanto, uma distinção importante da AGPL é que ela se concentra em serviços e aplicativos baseados 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 liberar o código-fonte do software modificado se ele for executado em uma rede, como acontece com os aplicativos SaaS. A licença AGPL fecha esta lacuna, exigindo que terceiros disponibilizem o código-fonte mesmo que o software modificado esteja sendo executado apenas em um servidor.
Publicada em 2007 pela Free Software Foundation, a licença AGPL 3.0 cresceu em popularidade devido, em grande parte, à ascensão da computação em nuvem e do SaaS, e hoje é a quinta licença de código aberto mais popular.
Licença Pública Geral Menor GNU (LGPL)
Também um produto da Free Software Foundation, a Licença Pública Geral Menor GNU (LGPL) é uma licença copyleft “fraca”, na medida em que é mais amigável aos negócios com estipulações menos rigorosas sobre o que é 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 ter que abrir o código-fonte de todo o seu código proprietário. Se alguém modificar a própria biblioteca de código aberto, precisará apenas liberar essas modificações sob a licença LGPL.
Licença Pública Mozilla 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 atualmente, de acordo com a métrica de licenças do GitHub. MPL também é uma licença copyleft fraca, projetada para proteger o código proprietário e, ao mesmo tempo, permitir que os desenvolvedores se beneficiem do software de código aberto.
No entanto, enquanto a LGPL se concentra no nível da biblioteca e a GPL no nível do projeto, a MPL opera em um nível de arquivo individual, exigindo que o usuário compartilhe um conjunto mais restrito de códigos.
Domínio público e bens comuns criativos
Embora uma “licença de código aberto” conceda direitos específicos, sempre há estipulações anexadas. Aqueles que desejam colocar seu software inteiramente em domínio público sem quaisquer ressalvas, entretanto, podem fazê-lo por outros meios.
Não basta simplesmente publicar software sem licença; a lei de direitos autorais se aplica por padrão à maioria dos trabalhos criativos, incluindo software. É aqui que uma “dedicação de domínio público” pode ajudar.
Projetada especificamente para software, a Unlicense é a nona licença mais popular no GitHub (embora seja discutível se ela pode realmente ser chamada de “licença”). Embora o OSI o tenha aprovado como licença em 2020, observou que o documento está “mal redigido” e questionou a sua eficácia jurídica em jurisdições (por exemplo, Alemanha) onde não é possível doar obras para o domínio público.
Assim como o Unlicense, o CC0-1.0 do Creative Commons também é uma ferramenta de dedicação de domínio público, embora seja mais amplamente focado em trabalhos criativos. Utiliza uma linguagem jurídica mais clara e profissional, que pode estar mais em sintonia com o direito internacional. Vale a pena notar que a Creative Commons solicitou a aprovação do CC0-1.0 como uma licença compatível com código aberto em 2012, mas retirou o pedido depois que o OSI levantou preocupações de que excluía explicitamente as concessões de patentes.
Existem outras ferramentas de dedicação pública, como o Zero-Clause BSD, que podem ser interessantes, pois possuem uma linguagem ainda mais simples. No entanto, não há consenso sobre o melhor mecanismo para ceder todos os direitos a um determinado software.
Fonte “caneta falsa”
Existem inúmeros outros paradigmas de licenciamento em todo o espectro de software.
Em alguns casos, as empresas lançarão software sob um modelo de licença dupla, com o utilizador a poder escolher entre uma licença de código aberto reconhecida e uma licença comercial, dependendo das suas intenções. Depois, há o “núcleo aberto”, que oferece o software sob uma licença de código aberto, mas com recursos principais com acesso pago. Em outros casos, uma empresa pode adicionar um adendo à Cláusula Commons a uma licença de código aberto que de outra forma seria permissiva, estabelecendo restrições comerciais.
Existem também muitas licenças que parecem e cheiram a código aberto, mas são, em última análise, incompatíveis com a definição de código aberto.
Em 2018, o gigante do banco de dados MongoDB fez a transição de uma licença AGPL copyleft para a licença pública do lado do servidor (SSPL), uma licença criada pelo próprio MongoDB. Embora o SSPL ainda seja bastante “aberto”, é o que é conhecido como “fonte disponível”, na medida em que o código é acessível, mas tem restrições comerciais significativas, o que é uma grande proibição no que diz respeito ao OSI.
O pessoal do MariaDB traçou um caminho semelhante com a licença de fonte comercial (BUSL), que impõe restrições comerciais antes da transição para uma verdadeira licença de código aberto após um determinado número de anos. Há outro movimento semelhante em andamento que busca transformar o licenciamento de “fonte justa” em algo. Isso inclui a Licença de Fonte Funcional, que é apresentada como uma alternativa mais simples ao BUSL.
Você também pode encontrar ocasionalmente licenças de “fonte ética”, como a Licença Hipocrática, que proíbe o uso de software que viole os direitos humanos reconhecidos internacionalmente. Da mesma forma, o formato de arquivo JSON de padrão aberto tem uma licença extremamente permissiva, exceto uma cláusula hilariante no final: “O Software deve ser usado para o Bem, não para o Mal.”