O código aberto faz o mundo da tecnologia girar, formando até 90% do stack de software moderno através de frameworks, 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 o mundo do código aberto e o proprietário, levando muitas empresas a se afastarem do código aberto para proteger seus interesses comerciais. No centro de tudo isso está a espinhosa questão das licenças.
Há dois tipos amplos de licenças que atendem à definição formal de código aberto conforme estabelecido pela Open Source Initiative (OSI). As 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 as empresas que desejam usá-lo comercialmente. E então há 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 existentes em cada categoria. Além disso, há inúmeras licenças que, embora não sejam estritamente de código aberto, também valem a pena conhecer.
Permissivas
MIT
Originária do Massachusetts Institute of Technology na década de 1980, a licença MIT, de nome apropriado, é 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 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 acontece com a maioria dessas licenças, ela é fornecida sem garantias, o que significa que os autores são isentos de qualquer responsabilidade por danos causados pelo software (por exemplo, perda de dados). Todos os desenvolvedores precisam se preocupar é incluir o aviso de direitos autorais 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 depender de tecnologia patenteada, isso pode criar incerteza legal para os desenvolvedores que implantam o software sem obter permissões separadas para essa tecnologia patenteada.
No entanto, isso destaca um dos principais pontos de venda da licença MIT: com apenas 200 palavras, a linguagem é simples e concisa. Embutir coisas com uma palestra de patentes ambíguas e confusas adicionaria complexidade desnecessária para projetos improváveis de se preocupar com patentes, como linguagens de programação de alto nível ou estruturas da web.
Mas muitos projetos de código aberto se intersectam 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 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 único para um projeto licenciado sob a Apache 2.0, todas as patentes que esse desenvolvedor detém sobre esse algoritmo são automaticamente licenciadas para todos os usuários do software.
A maioria das pessoas está familiarizada com a marca do Google, o Android, repleto de loja de aplicativos e uma suíte de ferramentas e serviços internos. Mas o Android Open Source Project (AOSP) subjacente 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 telefones a usarem o Android em vez dos outros incumbentes proprietários (por exemplo, Symbian) da época. E funcionou. Samsung, HTC, LG e todos os outros aderiram ao Android.
Um subproduto disso, no entanto, é que a Licença Apache 2.0 tem cerca de cinco vezes mais palavras do que o MIT, devido ao texto da concessão de patente, entre outras adições e esclarecimentos. Mas esse é o compromisso, e ilustra as distinções-chave entre as duas licenças de código aberto permissivas mais comuns.
Outras licenças permissivas
A Licença BSD 2-Clause é semelhante à 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 com o código-fonte quanto com a forma binária compilada. E então há a Licença BSD 3-Clause, que tem uma cláusula adicional de 'sem aval' que restringe o uso dos nomes dos detentores dos direitos autorais e colaboradores para fins promocionais em qualquer projeto derivado.
Há também a Licença de Não Atribuição MIT (MIT-0), que é mais simples do que a MIT, pois não há requisito de atribuição no software derivado. Usar isso se assemelha a colocar o software em domínio público, exceto que o autor mantém os direitos autorais e a capacidade de alterar 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 frequentemente mais adequadas para projetos que exigem contribuições da comunidade, em oposição a 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 contribuidores que seu trabalho árduo não será usado em software proprietário sem também beneficiar a comunidade em geral - na teoria, pelo menos, 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, de acordo com os dados do GitHub. A licença trouxe atualizações significativas para a GPL 2.0, incluindo disposições de concessão de patente e maior compatibilidade com outras licenças de código aberto. Também proíbe o que ficou conhecido como 'Tivoização', onde fabricantes de hardware que se beneficiam do software licenciado sob a GPL impedem os usuários de instalar versões modificadas desse software, usando 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 distribuirá 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 kernel Linux, que o sustenta, está disponível apenas sob a licença GPL 2.0, dado 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 Tivoização.
Licença Pública Geral Affero GNU (AGPL) 3.0
A Licença Pública Geral Affero (AGPL) é semelhante à GPL 3.0, no sentido de que é uma licença copyleft 'forte' que promove a liberdade de software e garante que as versões modificadas permaneçam de código aberto. No entanto, uma distinção fundamental da AGPL é que ela se concentra em serviços e aplicativos baseados na web, nos quais o software é executado a partir de servidores em vez de ser 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 as aplicações SaaS. A licença AGPL fecha essa brecha, exigindo que terceiros tornem o código-fonte disponível mesmo que o software modificado esteja sendo executado apenas de um servidor.
Publicada em 2007 pela Free Software Foundation, a licença AGPL 3.0 cresceu em popularidade devido, em grande parte, ao aumento da computação em nuvem e 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', no sentido de que é mais amigável aos negócios com estipulações menos rígidas 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 conecte às bibliotecas sem ter que abrir todo o código proprietário. Se alguém modificar a biblioteca de código aberto em si, então eles precisam apenas liberar essas modificações sob a licença LGPL.
Licença Pública Mozilla 2.0
Publicada pela Fundação Mozilla em 2012, a Licença Pública Mozilla (MPL) 2.0 é a décima licença de código aberto mais popular hoje, conforme 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, permitindo que os desenvolvedores se beneficiem do software de código aberto.
No entanto, enquanto a LGPL está focada no nível da biblioteca e a GPL no nível do projeto, a MPL opera em 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
Enquanto uma 'licença de código aberto' concede direitos específicos, sempre há estipulações anexadas. Aqueles que desejam colocar seu software inteiramente em domínio público sem nenhuma ressalva, no entanto, podem fazê-lo por 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. É aí que uma 'dedicação de domínio público' pode ajudar.
Projetado especificamente para software, o Unlicense é a nona licença mais popular no GitHub (embora possa realmente ser chamada de 'licença' seja discutível). Mesmo que a OSI o tenha aprovado como uma licença em 2020, ela observou que o documento é 'mal redigido' e questionou sua eficácia legal em jurisdições (por exemplo, Alemanha) onde não é possível doar o trabalho ao domínio público.
Assim como o Unlicense, o CC0-1.0 da Creative Commons é também uma ferramenta de dedicação ao domínio público, embora sua atuação seja mais abrangente em obras criativas. Ele usa linguagem legal mais clara e profissional que pode estar mais alinhada com a legislação internacional. Vale ressaltar 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 a solicitação depois que a OSI levantou preocupações de que ela excluía explicitamente concessões de patentes.
Há outras ferramentas de dedicação pública, como a Zero-Clause BSD, que podem ser atrativas por ter uma linguagem ainda mais simples. No entanto, não há consenso sobre o melhor mecanismo para renunciar a todos os direitos a um determinado software.
Fonte 'Falso-código'
Há 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 usuário podendo escolher entre uma licença de código aberto reconhecida e uma licença comercial, dependendo de suas intenções. Em seguida, há o 'núcleo aberto', que oferece o software sob uma licença de código aberto, mas com recursos-chave bloqueados por pagamento. Em outras situações, uma empresa pode adicionar um adendo Cláusula de Comuns a uma licença de código aberto permissiva, colocando restrições comerciais em vigor.
Há também 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, o gigante dos bancos de dados MongoDB fez a transição de uma licença copyleft AGPL para a Licença Pública 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', ou seja, o código é acessível, mas tem restrições comerciais significativas, o que é um grande não-não para a OSI.
Os colaboradores da MariaDB seguiram um caminho semelhante com a Licença de Código de Origem Empresarial (BUSL), que impõe restrições comerciais antes de fazer a transição para uma verdadeira licença de código aberto após um número determinado de anos. Há outro movimento semelhante em andamento que está tentando tornar o licenciamento 'fonte justa' algo. Isso inclui a Licença de Fonte Funcional, que é divulgada como uma alternativa mais simples à BUSL.
Você também pode encontrar licenças de 'código ético' de vez em quando, como a Licença Hipocrática, que proíbe o uso de software em violação dos direitos humanos internacionalmente reconhecidos. Da mesma forma, o formato de arquivo JSON de padrão aberto tem uma licença extremamente permissiva, exceto por uma cláusula hilariante no final: 'O Software deve ser usado para o Bem, não para o Mal'.
