Ainda me lembro quando a grande discussão sobre open source era se um pedaço de software era realmente open source, significando que ele era lançado sob uma licença certificada pela OSI. As marés estão mudando, os debates agoram se concentram em torno de qual licença open source usar. Adicionando complexidade ao debate a proliferação de licenças certificadas pela OSI. Agora, discussões estão crescendo sobre quais licenças open source são melhores para todas as partes envolvidas em um projeto open source. No caso de trabalhos de software coletivo, há também as complexidades adicionadas da compatibilidade da licença.
Parte do problema é que as empresas estão tentando conduzir suas próprias licenças vaidosas que reforçam suas macas e alavancam a boa vontade associada ao selo open source de aprovação. A SugarCRM uma vez montou uma ofensiva pedindo pela aprovação de sua Sugar Public Licence (derivada da licença Mozilla Public Licence, certificada pela OSI) que por um tempo ganhou popularidade entre desenvolvedores comerciais open source. A licença foi rejeitada e a Sugar desde então passou para GPLv3. Ironicamente a Common Public Attribution Licence (CPAL) apresentada pelo Social Text, que tem muitas semelhanças com a Sugar Public Licence, foi aprovada pela OSI. Atém mesmo a Microsoft teve sucesso pressionando o fórum da OSI para aprovação de duas licenças. A Microsoft Public Licence (M-PL) e a Microsoft Reciprocal Licence (Ms-RL), que são muito similares às licenças BSD e GPL.
O número de projetos open source tem crescido consideravelmente nos últimos dez anos, na verdade de modo exponencial, de acordo com uma notícia dada por Amit Deshpande e Dirk Riehle em março deste ano.
De acordo com a base de dados da Black Duck Software, a licença mais comum usada por projeto open source é a GPL versão 2.0. E de acordo com a mesma fonte, 94% dos projetos open source usam 10 licenças.
| Licença | % de uso |
| GNU General Public License (GPL) 2.0 | 58.69% |
| GNU Lesser General Public License (LGPL) 2.1 | 11.39% |
| Artistic License (Perl) | 7.46% |
| BSD License | 6.50% |
| Apache License 2.0 | 2.92% |
| MIT License | 2.58% |
| GNU General Public Liense (GPL) 3.0 | 1.64% |
| Mozilla Public License (MPL) 1.1 | 1.37% |
| Common Public License | 0.83% |
| zlib/lippng License | 0.64 |
| 93.92% |
Aualmente a decisão de passar de GPLv2 para GPLv3 está sendo altamente debatida por muitos projetos open source. De acordo com a Palamida, uma fornecedora de software de acordo de IP, houve cerca de 2489 projetos open source que passaram da GPLv2 para a última versão.
(Fonte: Palamida)
Aparentemente há muitas pessoas pensando em usar a AGPL por que, diferentemente da GPL, ela extende sua exigência da redistribuição de software para serviços de rede, como estes fornecidos pelas ASPs (veja a seção 13 da licença - Remote Network Interaction):.
No entanto qualquer outro fornecimento desta Licença, você tem permissão para unir ou combinar qualquer obra coberta com uma obra licenciada sob a versão 3 da Licença Pública Geral GNU Affero formando uma única obra, e fornecer a obra resultante. Os termos desta licença continuarão a aplicar-se à parte da obra que é uma obra coberta, mas as exigências especiais da Licença Pública Geral GNU Affero, seção 13, a respeito de interação através de uma rede se aplicarão à combinação como tal.
A SpringSource está causando um pequeno rebuliço dentro da comunidade Java lançando sua Spring Application Plataform sob a licença GPLv3 (Comentário pelo fundados da JBoss, Mark Fleury).
O Ubuntu está considerando usar a AGPL para o seu serviço Lauchpad, mas o debate ainda está aberto.
No caso do Launchpad, vemos você como sócio da informação, então a resolução deste problema é importante para nós. Como você observou, realmente não há uma prática clara que trabalhe bem e tenha se mostrado comercialmente sustentável. Isso é diferente da GPL (até mesmo a v3). Creio que a Affero GPL é uma forte candidata para a linha de frente no debate do assunto, e é por isso que estou inclinado a usar-la quando publicarmos os códigos abertos do Launchpad.
O Google se recusou a aceitar a licença AGPL no Google code, citando a proliferação de licenças como motivo.
De fato não damos suporte à AGPL no code.google.com. Estamos tentando lutar ativamente contra a proliferação de licenças que são consideradas open source, e a AGPL tem muito pouco mercado e não foi certificada como open source pela OSI.
No entanto, as disposições da AGPL para hospedagem de serviços não se opoem exatamente a seus negócios. Por exemplo, qualquer modificação que o Google faça ao código AGPL poderia obrigá-los a fornecer o código fonte quando fornecido como serviço.
O licenciamento de software é complexo, open source ou não. Suspeito que a maioria dos usuários não esta por dentro da licença do software em que estão baixando. Acho isso um pouco desanimador, sinto fortemente que o desenvolvimento open source é superior e o licenciamento do software open source na maioria não é fácil de entender ou aplicar.
