DevSecOps

24 dez, 2013

Conhecendo a licença Apache – #Melhores2013

Publicidade

Os softwares mantidos pela Fundação Apache, incluindo seu popular servidor web, vários componentes do ecossistema Java e até o SpamAssassin são todos livres e de código aberto, licenciados sob a Apache License 2.0.

Criada em 2004, a licença Apache 2.0 é uma evolução de versões anteriores lançadas entre 1995 e 2000, e uma das suas principais vantagens em relação a essas versões anteriores é poder ser facilmente aplicada, sem modificações no seu texto, a qualquer projeto que deseje fazer uso de suas políticas de licenciamento – mesmo que não seja e nem pretenda ser um projeto integrante da Fundação Apache.

Essa facilidade de aplicação é uma das razões que explicam a popularidade das licenças Apache: em 2009, mais de 5000 projetos externos à Fundação Apache hospedados no repositório SourceForge a adotavam, e em 2008 o Google informou que 25% dos 100.000 projetos então hospedados no seu Google Code a adotavam.

Combatendo ameaças de patentes de software

As condições gerais da licença Apache 2.0 lembram as das versões modernas das licenças BSD, que abordamos em outro post recente: permitem livre uso, redistribuição e alteração, sem exigir reciprocidade – ou seja, o código pode ser reaproveitado em projetos proprietários, se for esse o interesse de algum desenvolvedor.

Mas ela tem algumas características que a distinguem da simplicidade espartana das BSDs, a começar pela questão das patentes de software, que fica explícita na sua terceira cláusula, esclarecendo (de forma bastante extensa e específica) que todo contribuidor de código para o software em questão concede também uma licença mundial e perpétua para uso de suas patentes que sejam necessárias para uso ou distribuição do código contribuído por ele em combinação com o software em questão.

E há outros diferenciais em relação à BSD, como a possibilidade de ser adotada por referência (sem necessidade de reprodução do texto da licença – veremos mais sobre isso adiante) e a interessante possibilidade de incluir um arquivo chamado NOTICE, junto aos arquivos do projeto, cujo conteúdo (informacional e sem alterar as condições de licenciamento) precisará ser mantido e redistribuído junto com o código.

Como aplicar a licença Apache 2.0 ao seu código

O primeiro passo é ter certeza de que o texto da licença expressa as suas intenções quanto ao uso do código, de que ela é aplicável nas jurisdições em que você pretende distribuir o software, e outras questões típicas da seleção de uma licença de código aberto para qualquer projeto – possivelmente com apoio de alguem da área jurídica ou especialista na área.

Após chegar à conclusão de que a Apache 2.0 é a licença adequada para o seu projeto, basta seguir as instruções oficiais de aplicação, que são bem simples e se resumem a reproduzir, nos comentários de cada arquivo de código-fonte que vá ser licenciado, o texto abaixo (preenchendo os trechos entre colchetes da primeira linha):

Copyright [ANO] [NOME DO TITULAR OU AUTOR]

Licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Note que, ao contrário de outras licenças populares, a não é necessário incluir o texto integral da licença junto ao pacote para que tenha validade: ela faz a referência à versão integral por meio de uma URL na nota de licenciamento – e se você não confia na Fundação Apache para manter inalterado o texto da URL da licença, é melhor mesmo escolher outra licença!

Além disso, há a recomendação de que logo abaixo do comentário indicando a licença haja uma indicação do nome e finalidade do programa ou módulo – sempre uma boa prática.

Compatibilidade com a GPL

A questão da compatibilidade com a licença GPL é importante para muitos desenvolvedores que, embora desejem adotar uma licença mais permissiva, têm interesse que seu código possa ser linkado ou mesmo incorporado a projetos GPL, como o Linux e muitos outros.

Ao contrário do que pode parecer aos não-iniciados, entretanto, a compatibilidade ou incompatibilidade é dada pela própria GPL, e não pelas licenças livres dos outros projetos – a GPL é seletiva quanto à natureza das licenças dos códigos que podem ser ligados aos projetos licenciados sob ela, pois seus objetivos exigem rejeitar qualquer licença que imponha restrições adicionais às dela mesma.

Mas assim como ocorre com as licenças BSD correntes, a licença Apache não oferece nenhum obstáculo a que o código licenciado sob ela seja incorporado ou linkado em projetos sob a versão corrente da GPL. Isso foi alcançado após bastante esforço de adaptação pela Fundação Apache e pela FSF, removendo a incompatibilidade que existia (e permanece) entre a Apache e a GPLv2.

Vale mencionar que, apesar de toda a cooperação entre a Fundação Apache e a FSF, essa compatibilidade é unidirecional e só funciona a favor da GPL: ela permite que códigos sob a licença Apache sejam usados em projetos sob a GPL, mas impede que códigos GPL sejam usados em projetos sob a licença Apache.

Com licença

Adotar uma licença livre permissiva é uma decisão comum em projetos que desejam que seu código sirva como uma implementação de referência de um determinado serviço ou protocolo, ou fortalecer a infra-estrutura de um dado mercado tendo em vista benefícios a partir disso – como costuma acontecer com os softwares da Fundação Apache, autora da licença Apache.

Os próprios desenvolvedores do servidor web Apache descreveram a razão de optar por um licenciamento permissivo, e não pela alternativa de uma licença recíproca (“copyleft”) como a GPL. Para eles, este tipo de licença é ideal para promover o uso de um corpo de código que sirva como referência da implementação de um protocolo para um serviço comum.

Na época em que o projeto estava se estruturando, como muitos dos integrantes do projeto queriam ver o HTTP sobreviver e se tornar um padrão multilateral, a ideia de que a Microsoft, a Netscape ou qualquer outra empresa então dominante pudesse fazer uso do seu código não era negativa – pelo contrário, ela ajudaria no objetivo de manter o HTTP como um padrão de mercado.

Assim, sob um ponto de vista estratégico, valia a pena para os participantes contribuir código de qualidade para o projeto, mesmo que este código pudesse ter valor se fosse mantido como algo exclusivo e proprietário – o valor gerado pela adoção e disponibilidade do corpo de código comum seria ainda maior.

Nem sempre é este o caso, e muitas vezes a resposta certa para as demandas de um projeto é uma licença livre recíproca, como a GPL. Mas se a sua necessidade for bem satisfeita por uma licença livre permissiva, a facilidade de aplicação e a clareza no tratamento de patentes de software que a Apache License 2.0 oferecem podem ser os diferenciais de uma boa solução!