Guia do desenvolvedor para licenças de código aberto

Nem todas as licenças de código aberto são iguais. Alguns deles obrigam o fornecedor do software a conceder licenças de patente aos usuários e desenvolvedores do software. Outras licenças obrigam o desenvolvedor que utiliza o produto ou biblioteca licenciado a oferecer o código-fonte deste produto ou biblioteca nos mesmos termos. Outros simplesmente entregam o código, sem qualquer tipo de garantia ou preocupações. Neste artigo tentarei destacar as principais diferenças entre as licenças open source mais utilizadas na perspectiva de um usuário de software e de um desenvolvedor de software.

Quando em 1984 Richard Stallman iniciou o projeto GNU para a criação de um sistema operacional livre, ele recuperou a ideia de que software deveria ser compartilhado entre desenvolvedores, engenheiros e usuários; e eles devem ser capazes de melhorá-lo de forma colaborativa, da mesma forma que a ciência geralmente é feita.

Essa opção contrastava com o conceito usual de software licenciado escolhido pela maioria das corporações e desenvolvedores de software para distribuir e vender seus programas. Hoje, mais de trinta anos depois, o software de código aberto lentamente continua conquistando amplos setores de nossa indústria: Linux, Android, Apache e Git são exemplos de produtos de código aberto líderes em suas categorias.

Software livre ou de código aberto?

Neste artigo, usarei os termos “código aberto” e “gratuito” como sinônimos ao me referir a software ou licenças. Na minha opinião, ambos os termos expressam a mesma ideia. “Open-source” expressa isso de forma prática e técnica, e o uso de “Free” coloca o foco em um significado filosófico e político do conceito.

Infelizmente a palavra “free” em inglês, além de ser o adjetivo associado a “freedom”, também significa “sem custo”. Esta é a razão pela qual eu geralmente prefiro dizer “código aberto”.

Propriedades comuns de software de código aberto

Suponho que você já tenha uma ideia aproximada do que é software de código aberto. Mas como vamos falar sobre os detalhes das diferentes licenças, primeiro precisamos falar sobre as propriedades específicas que definem o software de código aberto.

Em primeiro lugar: não sou advogado, e isto não é aconselhamento jurídico. Em caso de dúvida, consulte o próprio texto das licenças de que estou falando e seu consultor jurídico.

Todo software de código aberto, de acordo com a Open Source Initiative, é distribuído sob uma licença que dá a seus usuários e desenvolvedores (os licenciados) alguns direitos. A lista completa pode ser consultada na Open Source Definition, mas aqui está um resumo básico:

1. Redistribuição gratuita do software: o software pode ser vendido ou dado como um produto ou incluído em um pacote de software. Isso pode ser feito sem pagar royalties.
2. O código-fonte do software licenciado está incluído na distribuição ou, pelo menos, existem meios bem divulgados de obter o código-fonte. Este código-fonte é utilizável para desenvolver versões modificadas do software.
3. A criação de trabalhos derivados é permitida, e a licença permite que eles sejam distribuídos sob os mesmos termos e licença do software original. Dependendo da licença do software original, em alguns casos, esses trabalhos derivados devem ser diferenciados do software original alterando seu nome ou número de versão, ou podem ser distribuídos apenas na forma de patches de código-fonte.
4. O software pode ser usado por qualquer pessoa ou grupo de pessoas, e em qualquer área de atuação, sem limitações.

Mas você deve ter em mente que as licenças de software falam apenas sobre o uso ou distribuição de permissões concedidas pelos detentores dos direitos autorais. As licenças de código aberto podem permitir que você redistribua o software ou trabalhos derivados livremente, mas essa permissão também pode ser restrita em alguns países onde a exportação de software criptográfico é proibida. De forma semelhante, as licenças de código aberto permitem que você use o software para qualquer finalidade, mas isso não significa que elas permitem que você invada um banco usando software licenciado de código aberto. As patentes de software são outro exemplo disso: algumas licenças de código aberto concedem permissões para usar patentes livremente, mas não todas.

Então, podemos usar um software de código aberto no desenvolvimento de um produto ou projeto? Basicamente, depende da licença do software utilizado e da licença pretendida para o produto final. As diferentes licenças também são importantes quando você deseja publicar seu próprio código como código aberto e está decidindo qual licença deve usar.

Copyleft

Um conceito bastante interessante sobre licenças de código aberto é o que normalmente é chamado de copyleft, o oposto de copyright. Quando os direitos autorais são usados ​​para proteger a propriedade intelectual (incluindo software) de ser copiada ou distribuída, o copyleft é usado para garantir que a propriedade intelectual e o software de código aberto possam ser copiados ou distribuídos como código aberto.

De acordo com sua força, existem dois tipos de copyleft:

• Copyleft forte: quando obras derivadas de outras obras licenciadas com copyleft forte, ou vinculadas a essas obras, devem continuar tendo licenças copyleft forte, ou mesmo exatamente a mesma licença. Ou seja, esses trabalhos de código aberto não podem ser fechados no futuro.
• Copyleft fraco: quando os trabalhos usam trabalhos licenciados copyleft fracos, ou vinculados a ele, podem ser licenciados sob outras licenças, até mesmo licenças de código fechado. Nesse caso, o copyleft afeta apenas o trabalho licenciado com copyleft fraco original.

Existem também licenças de código aberto sem copyleft: elas simplesmente não se importam com a abertura futura do software derivado.

Permissividade

De acordo com sua permissividade, as licenças também podem ser classificadas em:

• Licenças estritas: quando você não pode misturar software licenciado forte com software de código fechado, ou mesmo com software licenciado de forma mais permissiva.
• Licenças permissivas: quando os produtos geralmente podem ser misturados com software de código fechado, ou software com licença totalmente de código aberto.

Normalmente, licenças copyleft fortes também são estritas, e licenças copyleft fracas são mais permissivas, mas não precisa ser assim.

Diferenças de licenças de código aberto

Existem muitas licenças de código aberto. A Open Source Initiative já aprovou mais de 80 deles. Alguns são redundantes e podem ser considerados equivalentes a outros. Outros são específicos aos interesses do editor do software (como a licença da NASA) ou para um determinado ambiente ou finalidade (como a Educational Community License ou a Open Font License).

Essa proliferação de licenças é baseada em termos específicos da licença que, somados às propriedades básicas de código aberto, permitem ou não outros usos. Exemplos dessas condições adicionais podem incluir:

• Tipo de copyleft: fraco ou forte ou inexistente.
• Tipo de permissividade: permissiva ou estrita.
• A obrigação de adicionar um aviso de direitos autorais no código-fonte ou na interface do usuário.
• Concessão automática de patentes aos licenciados.
• Considerando como licenciados não apenas as partes a quem o software é distribuído, mas também os usuários do software (para que as pessoas que usam um serviço na nuvem que usa esse tipo de software de código aberto tenham a opção de baixar o código-fonte do o software)

Problema de misturar código com licenças diferentes

De acordo com o que já dissemos anteriormente, algumas licenças são permissivas, permitindo que os usuários combinem o código com o código-fonte licenciado de forma diferente (talvez com condições adicionais). Este caso permitiria misturar este tipo de software licenciado de código aberto com software de código fechado. Um exemplo desse tipo de licença é a Licença MIT.

Outros são mais restritivos, portanto, o código-fonte só pode ser combinado com código licenciado de forma semelhante, devendo o resultado final ser licenciado com a mesma licença original. Um exemplo desse tipo de licença é a General Public License (GPL).

Talvez você queira combinar o código licenciado com duas licenças de código aberto restritivas diferentes. Usando a liberdade de código aberto para usar o software como quiser, você pode fazer isso. Mas o programa final não pode ser redistribuído, pois deve ser distribuído sob duas licenças que não são compatíveis entre si.

Um exemplo dessa situação foi o ZFS. ZFS é um sistema de arquivos muito avançado e inovador que foi incluído no OpenSolaris em 2005. É um software de código aberto licenciado sob os termos da Common Development and Distribution License (CDDL). Embora seja um código-fonte aberto, não pode ser integrado ao kernel do Linux porque o código-fonte do Linux é distribuído sob os termos da General Public License, outra licença restritiva de código-fonte aberto. Binários do kernel Linux compilados com suporte a ZFS não podem ser distribuídos devido ao conflito de licença.

Esses tipos de conflito só podem ser resolvidos se todos os proprietários de um dos programas de código aberto concordarem em alterar a licença ou em adicionar termos de exceção na licença do software. Por exemplo: muitos programas licenciados GPL estão vinculados à biblioteca OpenSSL. A distribuição da biblioteca OpenSSL é licenciada exigindo que uma frase apareça no material publicitário e em quaisquer redistribuições. Essas condições extras não são compatíveis com a GPL e, por causa disso, os desenvolvedores de produtos GPL que usam OpenSSL incluíram uma exceção em sua licença permitindo especificamente a vinculação com OpenSSL.

Recursos diferenciais de licenças de código aberto

Agora vou tentar analisar as licenças open source mais populares, destacando seus diferenciais, com um pequeno guia sobre quando usá-las ou não. Eu os classifiquei do mais para o menos usado, de acordo com o Black Duck Knowledgebase.

Licença Pública Geral GNU (GPL)

A GPL é a licença de código aberto mais popular. Ele foi criado pela FSF como a licença para o projeto GNU, e também é a licença do kernel Linux.

Suas características diferenciais:

• Copyleft forte.
• Licença muito rigorosa.
• Geralmente é chamada de licença 'viral': se você vincular seu código a outro trecho de código licenciado sob a GPL e quiser distribuir os resultados, todo o produto deve ser licenciado pela GPL.
• É também uma licença 'abrangente': se você estiver desenvolvendo um software e quiser licenciá-lo sob a GPL, você pode vinculá-lo ou incluir outro software de código aberto, desde que este software tenha uma licença compatível com a GPL. Não requer nenhuma obrigação não exigida pela GPL.

Normalmente, o texto da licença usada inclui o texto dizendo que o software é distribuído sob os termos da GPL versão N (ou qualquer versão posterior).

Atualmente existem duas versões de licença GPL em uso: v2 e v3. A versão 3 foi lançada em 2007 para resolver alguns problemas que surgiram desde o lançamento da versão 2 em 1991.

A GPL v3 inclui algumas cláusulas e termos extras, abordando os regulamentos de compatibilidade com outras licenças de código aberto, obrigando o licenciamento de patentes, definindo as condições de uso de software licenciado pela GPL como firmware em dispositivos e levando em consideração conceitos como gerenciamento de direitos digitais.

Licença MIT

A licença de código aberto geralmente conhecida como Licença MIT, também conhecida como licença X11, é uma licença não copyleft muito permissiva que permite que todos usem basicamente o código licenciado para o que quiserem, desde que mantenham a mensagem de direitos autorais e saibam que o software vem sem garantia de qualquer tipo.

Esta licença é muito popular, e é utilizada por diversos projetos como o X Window System, Ruby on Rails, jQuery ou Node.js.

É compatível com a GPL, então você pode misturar código licenciado pelo MIT em software GPL.

Licença Apache 2.0

A Licença Apache foi criada pela Apache Software Foundation (ASF) como a licença para seu Apache HTTP Server.

Assim como a Licença MIT, é uma licença não copyleft muito permissiva que permite usar o software para qualquer finalidade, distribuí-lo, modificá-lo e distribuir trabalhos derivados dele sem se preocupar com royalties. Sua principal diferença em relação à licença MIT são:

• Usando a Licença Apache, os autores do software concedem licenças de patente a qualquer usuário ou distribuidor do código. Estas licenças de patente se aplicam a qualquer patente que, sendo licenciável por qualquer autor do software, seja infringida pelo pedaço de código que eles criaram.
• A Licença Apache exigia que as partes não modificadas em obras derivadas mantivessem a Licença.
• Em cada arquivo licenciado, quaisquer avisos originais de copyright, patente, marca registrada ou atribuição devem ser preservados.
• Em cada alteração de arquivo licenciado, deve haver uma notificação informando que foram feitas alterações no arquivo.
• Se o software licenciado pelo Apache incluir um arquivo AVISO, esse arquivo e seu conteúdo devem ser preservados em todos os trabalhos derivados.
• Se alguém enviar intencionalmente uma contribuição para um software licenciado pelo Apache aos seus autores, essa contribuição poderá ser usada automaticamente sob a Licença Apache.

Esta licença é interessante por causa da licença de patente automática, e a cláusula sobre submissão de contribuições.

É compatível com a GPL, então você pode misturar o código licenciado do Apache no software GPL.

Licença BSD

Existem 3 licenças BSD diferentes. Todas são licenças muito permissivas sem copyleft.

A Licença BSD de 2 cláusulas (ou Licença BSD Simplificada) é totalmente equivalente à Licença MIT que foi explicada anteriormente.

A Licença BSD de 3 cláusulas (ou Nova Licença BSD) adiciona uma cláusula, especificando que nem o nome do detentor dos direitos autorais nem os nomes de seus contribuidores podem ser usados ​​para endossar ou promover produtos derivados do software sem permissão prévia específica por escrito. Esta versão é compatível com a GPL, permitindo que você misture código licenciado de 3 cláusulas BSD em software GPL.

A Licença BSD de 4 cláusulas (ou Licença BSD Original) adiciona outra cláusula, especificando que todos os materiais publicitários que mencionam recursos ou uso do software devem exibir uma confirmação dizendo que o produto inclui software desenvolvido pelo detentor dos direitos autorais. Esta Licença BSD de 4 cláusulas não é compatível com a GPL. O código com esta licença não pode ser relicenciado de acordo com os termos da GPL, pois a quarta cláusula adiciona um requisito que não é exigido na GPL.

Licença Pública Geral Menor GNU (LGPL)

A LGPL foi criada pela FSF como uma modificação da GPL com um copyleft mais fraco, permitindo a ligação de software licenciado pela LGPL com qualquer outro software. Em suas origens, LGPL significava “Library General Public License”, mas depois tomou seu nome atual “Lesser General Public License” representando a opinião da FSF que diz que todo software deve ser livre, e por isso a LGPL não deve ser geralmente usado.

Você pode vincular o código-fonte fechado a uma biblioteca ou software LGPL e distribuir os resultados finais desde que:

• Você fornece o código-fonte da parte LGPL, com todas as modificações feitas nela.
• Qualquer usuário com conhecimento suficiente pode substituir a parte LGPL do programa por uma versão modificada. Isso pode ser feito distribuindo a parte LGPL do programa como uma biblioteca dinâmica (DLL no Windows, .so no Linux/Unix), ou fornecendo o código objeto da parte não LGPL do programa.

A LGPL v3 é compatível com a GPLv3, então você pode inserir o código LGPLv3 no software GPL.

Licença artística

A Licença Artística, em sua versão atual 2.0, é uma licença de código aberto permissiva sem copyleft semelhante à licença do MIT.

A principal diferença entre a licença MIT e a Licença Artística é que esta última exige que qualquer modificação feita no código seja claramente declarada.

Esta licença é usada quase exclusivamente na comunidade Perl.

A Licença Artística 2.0 atual é compatível com GPL: você pode misturar código Artistic-Licensed em software GPL.

Licença Pública da Microsoft (MS-PL)

A Microsoft Public License foi criada em 2008 por esta empresa como uma das licenças de código aberto criadas por sua Shared Source Initiative.

É uma licença copyleft estrita e fraca: permite a criação e distribuição de programas de código fechado com código MS-PL, mas obriga a usar o MS-PL como licença de trabalhos derivados se estes forem distribuídos em código fonte.

Eu pessoalmente acho que essa licença é um pouco perversa e contrária ao espírito do open-source, permitindo o fechamento do código para que de certa forma o detentor dos direitos autorais não se importe com o que você pode fazer com o software, mas você não pode compartilhe o código para ser misturado com outro código-fonte copyleft. Então, de outra forma, o detentor dos direitos autorais realmente se importa com o que você pode fazer, e ele não quer que você use o código por razões como melhorar o Linux.

A MS-PL é incompatível com a GPL.

Licença Pública Eclipse (EPL)

A Licença Pública Eclipse é a licença criada pela Eclipse Foundation para seu Ambiente de Desenvolvimento Integrado. É uma licença de copyleft restritiva e fraca, semelhante em muitos aspectos à LGPL. Também inclui cláusulas para concessão automática de licença de patente.

A EPL é incompatível com a GPL.

Licença Pública Mozilla (MPL)

A Mozilla Public License versão 2.0 é uma licença fraca de copyleft e permissiva criada pela Mozilla Foundation para seus produtos.

Poderíamos considerar esta licença como semelhante à LGPL, mas com a principal diferença de que a MPL também permite a vinculação estática dos pedaços de código MPLed em software de código fechado.

A MPL, em sua versão atual 2.0 é compatível com a GPL. Isso não é verdade para versões anteriores do MPL.

Licença Comum de Desenvolvimento e Distribuição (CDDL)

O CDDL é uma licença permissiva de copyleft fraca criada pela Sun (agora Oracle) baseada no MPL versão 1.1. Basicamente, tem as mesmas propriedades que o MPL. Seus termos foram esclarecidos, mas não substancialmente alterados.

O CDDL é a licença de código aberto escolhida pela Sun (agora Oracle) para muitos de seus produtos, como OpenSolaris ou NetBeans, entre outros.

Como esta licença foi baseada na MPLv1.1, esta licença não é compatível com a GPL, portanto, você não pode misturar fontes licenciadas por CDDL em um software licenciado pela GPL. Muitas pessoas dizem que isso foi intencional, então o código-fonte do OpenSolaris não pode ser introduzido no kernel do Linux.

Licença Pública Geral GNU Affero (AGPL)

A AGPL é uma versão da GPL com copyleft ainda mais forte e restritivo. Obriga-se a fornecer o código fonte do aplicativo não apenas para as pessoas que recebem uma cópia do software, mas também para as pessoas que utilizam este software através de uma rede de computadores.

Esta licença foi criada pela FSF para dar aos desenvolvedores os meios para evitar o fechamento prático do software de código aberto quando executado em servidores de rede ou na nuvem, pois a GPL não pode forçar os provedores de serviços a fornecer código-fonte aos usuários . Neste caso, o software não é distribuído.

A AGPLv3 é compatível com a GPL3. Você pode colocar o código AGPLv3 no código GPLv3, desde que o resultado final seja licenciado sob a AGPLv3.

Licença ISC

A Licença ISC é uma licença de software livre permissiva escrita pelo Internet Software Consortium (ISC). É funcionalmente equivalente às licenças BSD e MIT de 2 cláusulas, após a remoção de algum idioma considerado desnecessário.

Inicialmente usado para os próprios lançamentos de software do ISC, desde então se tornou a licença preferida do OpenBSD (a partir de junho de 2003), entre outros projetos.

É compatível com a GPL: você pode misturar código licenciado pelo ISC em software GPL.

Licença Recíproca da Microsoft (MS-RL)

A Licença Recíproca da Microsoft foi criada em 2008 por esta empresa como uma das licenças de código aberto criadas por sua Iniciativa de Fonte Compartilhada.

É semelhante ao MS-PL explicado anteriormente, mas tem um copyleft um pouco mais forte, lembrando as condições do LGPL, CDDL e EPL. Ela exige que, se você misturar seu código com o código-fonte licenciado pela MS-RL e quiser distribuir os resultados finais, pelo menos a parte original da licença MS-RL deve continuar a ser licenciada com esta licença.

Não é compatível com a GPL.

Domínio Público (CC0)

Segundo a Wikipedia, “obras de domínio público são aquelas cujos direitos de propriedade intelectual expiraram, foram caducados ou são inaplicáveis”. Dedicando uma obra ao domínio público, o autor renuncia a todos os seus direitos sobre ela sob a lei de direitos autorais.

Existem vários projetos de software sob Domínio Público, por exemplo SQLite, a biblioteca que implementa um mecanismo de banco de dados SQL simples e incorporável que está incluído em vários outros projetos, como projetos Mozilla, Android, etc.

Há muitas maneiras de dedicar um software ao domínio público. A Creative Commons criou a Dedicação de Domínio Público CC0, uma forma universal de doar uma obra para o domínio público. A FSF recomenda usar este texto para dedicar software ao domínio público.

Obras sob domínio público são compatíveis com quaisquer licenças de código aberto ou fechado e podem ser misturadas com qualquer outro software.

Licenciamento múltiplo

Existem alguns softwares de código aberto com licença dupla ou tripla. Isso significa que uma pessoa que recebe esse software com licença múltipla pode escolher sob qual licença deseja distribuí-lo. Como cada licença concede diferentes permissões e impõe diferentes obrigações, deve ser feita uma seleção para escolher a licença que melhor atende às necessidades.

Este é um caso comum para algumas bibliotecas. Por exemplo, NSS é uma biblioteca feita pela Mozilla que implementa suporte a SSL/TLS, entre outros recursos relacionados à segurança. É triplamente licenciado sob licenças MPL, GPL e LGPL.

Por favor, escolha uma licença

Muitas pessoas publicam código em plataformas como GitHub sem nenhuma licença escrita. Ninguém deve usar esse código. Não temos ideia de quais permissões temos para usá-lo. Se você usá-lo, você pode ser processado por isso. É como se essas pessoas estivessem nos provocando, dizendo “Ei, olha o que eu fiz! Legal, não é? Mas você não pode usar, eu só queria te mostrar!”.

Por favor, não seja um deles. Se você enviar seu código para o GitHub ou sites públicos semelhantes, permita que outras pessoas o usem e o aprimorem. Se você não quer pensar muito, estas são minhas recomendações:

• Se você deseja mantê-lo simples e permissivo, permitindo que todos façam o que quiserem com seu código, desde que forneçam atribuição de volta a você e não o responsabilizem, use a Licença MIT.
• Se você deseja mantê-lo permissivo, permitindo que todos façam o que quiserem com seu código, mas enumerando sabiamente os direitos sob a lei de direitos autorais e concedendo esses direitos, além de fornecer uma concessão explícita de direitos de patente de contribuidores para usuários, use a licença Apache 2.0 .

• Se você se preocupa em compartilhar modificações e não quer que seu código seja usado em desenvolvimentos fechados (nem em produtos de software fechados nem em dispositivos de hardware fechados), use a GPL v3.

  • Se você não se importa com a possibilidade de seu software ser usado em um dispositivo fechado, use a GPL v2. Mas por favor, com a frase “ou qualquer versão posterior”, para que seu código também possa ser usado em projetos GPLv3.
  • Se você não se importa com a possibilidade de seu software ser usado em software fechado, desde que seu software ou a parte que o utiliza continue sendo de código aberto sob os mesmos termos, use a LGPL v3.
  • Se você deseja que todos que usam seu software através de uma rede tenham o direito de obter seu código-fonte, use AGPL v3.

Depois de tudo isso, você pode estar exausto de todas essas bobagens quase legais. Mas você sabe o quê? É necessário. Porque sem uma licença, você não tem o direito de usar ou distribuir qualquer código.