O uso de software open source continua a crescer, à medida que mais utilizadores percebem o valor que traz a organização na redução da gestão de licenças e custos, evitando um único fornecedor, e promovendo a interoperabilidade.
Para muitos, o licenciamento de código aberto ainda é um desconhecido, e há muitas perguntas sobre como construir soluções proprietárias em conjunto com software de código aberto. Infelizmente, essa confusão levou muitos a hesitar na adotação do open source.
Este post é focado no uso de licenças de código aberto na distribuição de software para seus clientes. Esperamos ajudar as organizações a compreender melhor o licenciamento de fonte aberta, e dissipar quaisquer rumores em torno de como ele pode ser incorporado em soluções proprietárias.
Antes de falarmos de cada licença precisamos entender as principais diferenças entre licenças de código aberto:
– Software que usam uma licença permissiva (permissive) coloca restrições mínimas sobre como o software pode ser distribuído.
– Bibliotecas que usam uma licença fracamente (weak) protetora desejam permanecer open source (para os seus clientes), mas permitir a integração com o software proprietário.
– Componentes que usam uma licença fortemente (strong) protetora são obrigados a manter o tipo da licença quando alterações ou adições são feitas.
As diferenças de licenças permissivas, fracas e fortes guiará nossa compreensão de onde o software fechado pode ser integrado com o software open source. Estas restrições são todas expressas em termos de distribuição de software para o seu cliente, não necessariamente o público em geral . Estas licenças não impõem nenhuma obrigação em contribuir com as modificações para a comunidade.
1. Berkeley Software Distribution (BSD)
A licença BSD permite o uso comercial, incluindo o software em seu próprio aplicativo ou site. A única restrição é a inclusão de uma nota de licença e direitos autorais em qualquer trabalho que você crie. O seu próprio trabalho permanece inalterado.
Exemplo: OpenLayers usa BSD, permitindo que a biblioteca possa ser usada como parte de sua própria aplicação web. Ao usar o OpenLayers, você será solicitado a manter o copyright OpenLayers e não a dar crédito que o seu site foi produzido/validado pela Open Source Geospatial Foundation. Este é um exemplo de como uma licença permissiva permite usar OpenLayers, sem colocar nenhuma restrição sobre o seu próprio trabalho.
2. Apache License v2.0
A Licença Apache é uma licença permissiva semelhante às licenças MIT e BSD com alguns benefícios adicionais. A Licença Apache fornece idioma adicional em torno de patentes com caminhos claros, tanto para o desenvolvimento de código aberto quanto fechado. Mas não há nenhuma obrigação de realizar contribuição, e os licenciados são livres para produzir o seu trabalho derivado e licenciá-lo sob uma licença diferente.
3. GNU Lesser General Public License (LGPL)
O GNU Lesser General Public License (LGPL) é outra licença criado com a finalidade de permitir que as bibliotecas de código aberto sejam licenciadas, permitindo ao mesmo tempo a integração com software proprietário. A LGPL permite que as alterações realizadas na biblioteca sejam fornecidos para o seu cliente, mas não impõe nenhuma restrição sobre o uso de tecnologia proprietária, tornando-o um pouco mais liberal do que a licença GPL.
4. GNU General Public License (GPL)
GPL estabelece que quaisquer modificações feitas no aplicativo original e suas extensões, deverá ser fornecido para o seu cliente. Isso permite que a obra licenciada originalmente seja distribuída ou vendida pelo seu cliente. Assim, qualquer pessoa pode adquirir e reembalar software licenciado sob GPL, comercializá-lo e vendê-lo sem qualquer trabalho adicional. Esta licença se concentra em resguardar os seus clientes, garantindo que os administradores de sistemas que executam o software tenham acesso total ao código do software que eles são responsáveis.
Exemplo: Desenvolvimento de um novo formato de saída para o GeoServer deve ser distribuído sob uma licença GPL. Isso significa que o executável compilado, e o código-fonte, teria que estar acessível mediante solicitação ao comprador do software. O comprador de seu software pode ser definido como seu cliente ou o administrador do sistema, mas não necessariamente o público em geral.
Assim, agora você pode dizer: “Obrigado, toda esta informação é útil, mas o que isso significa para uma organização que quer construir soluções em cima de código aberto?”
Talvez a melhor maneira de abordar esta questão é responder a algumas perguntas mais frequentes:
a. “Minha organização gostaria de realizar alterações no código do Core do GeoServer. Sou obrigado a compartilhar essas alterações com a comunidade?”
Não, você não é obrigado a compartilhar essas alterações com a comunidade. A licença GPL estabelece que quaisquer modificações feitas no código principal do aplicativo deve ser fornecido para quem necessitar implementar o aplicativo. Então, você é obrigado a compartilhar essas alterações com o seu cliente, mediante solicitação, mas não necessariamente o público em geral.
b. “Minha organização gostaria de criar um plugin para o GeoServer, mas não vai realizar qualquer alteração no código do Core do GeoServer. Sou obrigado a compartilhar o plugin com a comunidade?”
Não, você não é obrigado a compartilhar essas alterações com a comunidade, mas você é obrigado a compartilhar o plug-in com o seu cliente sob os termos da licença GPL.
c. “A minha empresa gostaria de desenvolver uma aplicação web proprietária usando a biblioteca OpenLayers. Posso vender o software que desenvolvemos? “
Sim, isso é especialmente possível para licenças “permissivas”, como BSD. Você pode combinar bibliotecas abertas com seu código proprietário, e revender a solução obtendo lucro.
d. “Minha organização criou um plugin QGIS sob encomenda para um cliente. O cliente determina que o software desenvolvido dentro de sua rede não pode ser compartilhado com o público em geral na Internet. Sou obrigado a compartilhar este plug-in com o público? “
Não, você não é obrigado a compartilhar o plug-in personalizado, ou seu código fonte, com o público em geral. No entanto, a GPL diz que você é obrigado a compartilhar o código-fonte com o seu cliente caso ele solicitar. Mas, dado o fato que eles estão pedindo um plugin personalizado, compartilhar o código fonte com ele não deve ser um problema.
Este post foi adaptado e traduzido livremente por Fernando Quadro a partir do post original escrito por Jody Garnett e Anthony Calamito (Boundless).
Fonte: Boundless Blog
