Dormindo com o GPL
Enviado em 10 de fevereiro de 2008
Filed Under Legal , Open Source , Web2.0 | 2 Comentários
Hoje existe um monte de mal-entendidos e confusão sobre o que usa de software sob a GPL pode obrigar uma empresa para open source seu software. Ter passar por essa situação na Disney, Sony e várias startups, este artigo destina-se a esclarecer a minha própria compreensão, assim como espero ajudar alguns outros tomarem decisões informadas. Por favor, note que eu não sou um advogado e este artigo não deve ser invocado como um substituto para a leitura do GPL e obter aconselhamento jurídico específico de um advogado licenciado.
Embora existam muitas licenças menos restritivas ( MIT, BSD, MPL, etc ), o GPL é talvez uma das menos compreendidas e mais temido pelas empresas. Até certo ponto essa confusão não deve ser uma surpresa. O movimento FOSS (Software Livre e Open Source) é composta de um conjunto de activistas que têm ideais um pouco diferentes. Uma vez que a uma lei medida depende muito da intenção e tratamento consistente, as inconsistências nesta abordagem lamacento das águas. Ao longo do tempo os líderes do movimento fazem declarações contraditórias a respeito do escopo e intenção de o GPL, este injeta medo incerteza e dúvida (FUD).
Tornando as coisas ainda mais confusas, lei de direitos autorais também está em situação triste em relação aos princípios fundamentais em que assenta a GPL. Para software, o que constitui Fair Use e trabalhos derivados estão em desacordo dentro de jurisprudência. Em uma lei, caso extremo, infere-se que um produto é derivado, mesmo se você copiou nenhum código do sistema que interage com. Por outro lado, infere caso conflitantes lei, que é Fair Use para reverter a engenharia de um sistema para utilizá-lo sem se preocupar sendo considerados derivados.
Qual desses precedentes que pensamos vai jogar fora é potencialmente aleatório e depende muito da forma como usamos o código. Sem exclusões explícitas estabelecidas de desenvolvedores temos que voltar para a intenção dos autores da licença em si. Neste caso, a Free Software Foundation especificamente explicita suas crenças. Em sua interpretação da GPL seu programa é derivado se você incluir GPL código ou link para GPL código de qualquer forma (dinâmica ou estaticamente).
Existem várias exceções a esta regra reconhecida de tal forma que seu programa não pode ser considerado um trabalho derivado.
- Você pode vincular dinamicamente contra uma interface padrão, onde outras bibliotecas existentes podem ser substituídos.
- Você pode executar um programa GPL via fork () ou execute ().
- Você pode se comunicar com um programa através de rede padrão e os mecanismos de IPC. *
- Você pode distribuir o seu programa e um programa GPL em conjunto (na mesma mídia), desde que ainda representam programas separados e os termos da GPL são observados.
Essas exceções nos dar corda suficiente para usar os programas e bibliotecas GPL em conjunto dentro de um maior de sistemas de código fechado. No topo destes desenvolvedores alguns podem adicionar outros exceções explícitas como permitir dinâmico ( LGPL linkage) ou estáticos. Em alguns casos, também pode ser possível entrar em contato com os desenvolvedores e negociar uma licença de código fechado que elimina as limitações do GPL todos juntos.
Há uma brecha outros notáveis. O GPL só entra em ação quando você distribuir o programa derivado. Se você não distribuir um programa derivado para as pessoas fora de sua empresa você não tem para distribuir seu código fechado. Você ainda pode usar software GPL derivado como um serviço e cobrar dinheiro por isso sem liberar qualquer código.
Na prática, esta lacuna tem um pegadinhas casal. A primeira é que você não pode vender ou dar ao programa derivado de outra empresa ou pessoa. O segundo que muitos não consideram é que, durante alguns M & A operações realizadas pela empresa está vendendo os ativos, em vez de fundir as empresas e vendendo os ativos também pode ser considerado uma distribuição.
É claro que como acontece com qualquer software a sua licença (FOSS ou comercial), você deve estar ciente das questões de patentes, indenização, restrições de licença adicional (por exemplo GPL3 restringe DRM) eo custo total de propriedade relacionadas à manutenção e suporte. Como com qualquer coisa que fazemos como empresas há mais para a linha de fundo do que o preço entrando pela porta.
A outra coisa a considerar é a percepção do público e do movimento do software livre. Você está usando software FOSS eo contrato implícito é que você vai participar na comunidade e contribuir com melhorias. Não é o suficiente para usar software livre, você deve adotar uma política que os Estados como você usa software livre e como você apoiá-lo. Trabalhando com desenvolvedores de software livre e ser um bom cidadão vai um longo caminho.
Referências:
http://www.gnu.org/copyleft/gpl.html
http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html
http://www.fsf.org/licensing/licenses/gpl-faq.html
http://www.bu.edu/law/lawreview/v85n5/Stoltz.pdf
http://www.linuxinsider.com/story/38089.html?welcome=1202601329&welcome=1202602307
http://en.wikipedia.org/wiki/Free_software_licenses
http://en.wikibooks.org/wiki/FOSS_Licensing/Scenarios
Scridb filtro
Comentários
Como alguém recentemente apontado em uma lista, o GPL parece muito arbitrária em que você não tem que distribuir sua fonte, se você prestar um serviço, mas você se você fornecer um produto. Em outras palavras, o GPL promove software-as-serviços através de software-as-produtos.
Por que alguém deveria criar software com uma interface XML-RPC conseguem manter seus mods privada enquanto alguém distribuir uma biblioteca ser compelido a revelar suas mods?
Pesquisa
Arquivo
Blogroll
Administrador
 |  |  |  |  |  |  |  |  |  | ||||||||||||||||||||||||||||||||||||||
Oi Chuck,
Olhando para ela como um outsider Eu acho que há uma série de fatores.
1) O GPL costuras de ser concebido para redefinir os papéis dos programadores de produtores IP em provedores de serviços. Com o software cliente do serviço é simplesmente um modelo diferente (consultoria etc personalização).
2) É mais difícil fazer valer no servidor. Seria simples para esconder o uso de software sob a GPL.
3) Não permitir que o software seja rentabilizado como um serviço limita a adoção produtos.
Em poucas palavras limitando softwares GPL uso como um serviço que limitaria sua adopção, utilidade e aplicabilidade. Lembre-se também que o proprietário do software GPL pode dupla licenciar o produto e não está vinculado à respectiva GPL.
Embora eu usar algum software GPL, eu prefiro muito mais licenças menos restritivas e viral, mesmo como um serviço. Cada uso do software, comercial ou FOSS, requer alguma diligência para determinar a aptidão eo custo total de propriedade.
Há muitos fatores que levam ao sucesso ou fracasso de um projeto FOSS, a licença é um dos elementos que podem adicionar atrito para adoção. Já estamos vendo uma divisão e duplicação de esforços, como resultado das exigências de licença. Será interessante ver como cada licença compete.
-Marty
- Spam
- ofensiva
- discordar
- off topic
Como