GNU General Public License - GNU General Public License

GNU General Public License
GPLv3 Logo.svg
Autor Richard Stallman
Última versão 3
Editor Fundação de Software Livre
Publicados 25 de fevereiro de 1989 ; 32 anos atras ( 25/02/1989 )
Identificador SPDX GPL-3.0-or-later
GPL-3.0-only
GPL-2.0-or-later
GPL-2.0-only
GPL-1.0-or-later
GPL-1.0-only
Compatível com Debian FSG sim
OSI aprovado sim
Copyleft sim
Vinculando a partir do código com uma licença diferente Não (exceto para software licenciado sob licenças compatíveis com GPL)
Local na rede Internet www .gnu .org / Licenças / gpl .html Edite isso no Wikidata

A GNU General Public License ( GNU GPL ou simplesmente GPL ) é uma série de licenças de software livre amplamente utilizadas que garantem aos usuários finais a liberdade de executar, estudar, compartilhar e modificar o software. As licenças foram originalmente escritas por Richard Stallman , fundador da Free Software Foundation (FSF), para o Projeto GNU , e concedem aos destinatários de um programa de computador os direitos da Definição de Software Livre . As séries GPL são todas licenças copyleft , o que significa que qualquer trabalho derivado deve ser distribuído sob os mesmos termos de licença ou equivalentes. Isso é uma distinção às licenças de software permissivas , das quais as licenças BSD e a Licença MIT são amplamente utilizadas, exemplos menos restritivos. GPL foi a primeira licença copyleft para uso geral.

Historicamente, a família de licenças GPL tem sido uma das licenças de software mais populares no domínio do software livre e de código aberto . Programas de software livre proeminentes licenciados sob a GPL incluem o kernel Linux e GNU Compiler Collection (GCC). David A. Wheeler argumenta que o copyleft fornecido pela GPL foi crucial para o sucesso dos sistemas baseados em Linux, dando aos programadores que contribuíram para o kernel a garantia de que seu trabalho beneficiaria o mundo inteiro e permaneceria livre, ao invés de ser explorado por empresas de software que não teriam que dar nada em troca à comunidade.

Em 2007, a terceira versão da licença (GPLv3) foi lançada para resolver alguns problemas percebidos com a segunda versão (GPLv2) que foram descobertos durante o uso de longo prazo desta última. Para manter a licença atualizada, a licença GPL inclui uma cláusula opcional "qualquer versão posterior", permitindo que os usuários escolham entre os termos originais ou os termos em novas versões atualizadas pela FSF. Os desenvolvedores podem omiti-lo ao licenciar seu software; o kernel do Linux, por exemplo, é licenciado sob a GPLv2 sem a cláusula "qualquer versão posterior".

História

A GPL foi escrita por Richard Stallman em 1989, para uso com programas lançados como parte do projeto GNU. A GPL original foi baseada em uma unificação de licenças semelhantes usadas para versões anteriores do GNU Emacs (1985), o GNU Debugger e o GNU C Compiler . Essas licenças continham disposições semelhantes à GPL moderna, mas eram específicas para cada programa, tornando-as incompatíveis, apesar de serem a mesma licença. O objetivo de Stallman era produzir uma licença que pudesse ser usada para qualquer projeto, possibilitando assim que muitos projetos compartilhassem o código.

A segunda versão da licença, a versão 2, foi lançada em 1991. Nos 15 anos seguintes, membros da comunidade de software livre ficaram preocupados com problemas na licença GPLv2 que poderiam permitir que alguém explorasse software licenciado GPL de maneiras contrárias às da licença intenção. Esses problemas incluíam tivoização (a inclusão de software licenciado pela GPL no hardware que se recusa a executar versões modificadas de seu software), problemas de compatibilidade semelhantes aos da Licença Pública Geral Affero e acordos de patentes entre a Microsoft e distribuidores de software livre e de código aberto software, que alguns viram como uma tentativa de usar patentes como uma arma contra a comunidade de software livre.

A versão 3 foi desenvolvida para tentar resolver essas questões e foi lançada oficialmente em 29 de junho de 2007.

Versão 1

GNU General Public License, versão 1
Publicados 25 de fevereiro de 1989
Local na rede Internet www .gnu .org / licences / old- licences / gpl-1 .0 .html

A versão 1 da GNU GPL, lançada em 25 de fevereiro de 1989, evitou o que eram então as duas principais maneiras pelas quais os distribuidores de software restringiam as liberdades que definem o software livre. O primeiro problema é que os distribuidores podem publicar apenas arquivos binários - executáveis, mas não legíveis ou modificáveis ​​por humanos. Para evitar isso, a GPLv1 declarou que copiar e distribuir cópias ou qualquer parte do programa também deve disponibilizar o código-fonte legível sob os mesmos termos de licença.

O segundo problema era que os distribuidores podiam adicionar restrições à licença ou combinando o software com outro software que tinha outras restrições à distribuição. A união de dois conjuntos de restrições se aplicaria ao trabalho combinado, adicionando restrições inaceitáveis. Para evitar isso, a GPLv1 afirmou que as versões modificadas, como um todo, deveriam ser distribuídas sob os termos da GPLv1. Portanto, o software distribuído sob os termos da GPLv1 poderia ser combinado com o software em termos mais permissivos, pois isso não mudaria os termos sob os quais o todo poderia ser distribuído. No entanto, o software distribuído sob GPLv1 não pode ser combinado com software distribuído sob uma licença mais restritiva, pois isso entraria em conflito com o requisito de que o todo seja distribuível sob os termos da GPLv1.

Versão 2

GNU General Public License, versão 2
Publicados Junho de 1991
Local na rede Internet www .gnu .org / licences / old- licences / gpl-2 .0 .html

De acordo com Richard Stallman, a principal mudança na GPLv2 foi a cláusula "Liberdade ou Morte", como ele a chama - Seção 7. A seção diz que os licenciados podem distribuir uma obra coberta pela GPL apenas se puderem cumprir todas as obrigações da licença, apesar de quaisquer outras obrigações legais que possam ter. Em outras palavras, as obrigações da licença não podem ser cortadas devido a obrigações conflitantes. Esta disposição tem como objetivo desencorajar qualquer parte de usar uma reclamação de violação de patente ou outro litígio para prejudicar a liberdade dos usuários sob a licença.

Em 1990, estava ficando claro que uma licença menos restritiva seria estrategicamente útil para a biblioteca C e para bibliotecas de software que essencialmente faziam o trabalho das proprietárias existentes; quando a versão 2 da GPL (GPLv2) foi lançada em junho de 1991, portanto, uma segunda licença - a GNU Library General Public License - foi introduzida ao mesmo tempo e numerada com a versão 2 para mostrar que ambas eram complementares. Os números da versão divergiram em 1999, quando a versão 2.1 da LGPL foi lançada, que a renomeou como GNU Lesser General Public License para refletir seu lugar na filosofia. A GPLv2 também foi modificada para se referir ao novo nome da LGPL, mas seu número de versão permaneceu o mesmo, resultando na GPLv2 original não ser reconhecida pelo Software Package Data Exchange (SPDX).

A licença inclui instruções para especificar a "versão 2 da Licença ou (por sua opção) qualquer versão posterior" para permitir o uso opcional flexível da versão 2 ou 3, mas alguns desenvolvedores mudam isso para especificar apenas a "versão 2".

Versão 3

GNU General Public License, versão 3
Publicados 29 de junho de 2007
Local na rede Internet www .gnu .org / Licenças / gpl .html

No final de 2005, a Free Software Foundation (FSF) anunciou o trabalho na versão 3 da GPL (GPLv3). Em 16 de janeiro de 2006, o primeiro "esboço de discussão" da GPLv3 foi publicado e a consulta pública começou. A consulta pública foi originalmente planejada para nove a quinze meses, mas finalmente se estendeu para dezoito meses, com quatro rascunhos sendo publicados. A GPLv3 oficial foi lançada pela FSF em 29 de junho de 2007. A GPLv3 foi escrita por Richard Stallman, com assessoria jurídica de Eben Moglen e Richard Fontana do Software Freedom Law Center .

De acordo com Stallman, as mudanças mais importantes foram em relação a patentes de software , compatibilidade de licença de software livre , definição de "código-fonte" e restrições de hardware para modificações de software, como tivoization . Outras mudanças relacionadas à internacionalização, como as violações de licença são tratadas e como permissões adicionais podem ser concedidas pelo detentor dos direitos autorais. O conceito de "propagação de software", como um termo para a cópia e duplicação de software, foi definido explicitamente.

O processo de consulta pública foi coordenado pela Free Software Foundation com a assistência do Software Freedom Law Center, da Free Software Foundation Europe e de outros grupos de software livre. Os comentários foram coletados do público por meio do portal da web gplv3.fsf.org, usando um software específico chamado stet .

Durante o processo de consulta pública, foram enviados 962 comentários para a primeira versão. Ao final do período de comentários, um total de 2.636 comentários foram enviados.

O terceiro rascunho foi lançado em 28 de março de 2007. Esse rascunho incluía linguagem destinada a evitar acordos relacionados a patentes, como o polêmico acordo de patente Microsoft-Novell , e restringia as cláusulas anti-tivoização a uma definição legal de "usuário" e " bens de consumo". Também retirou explicitamente a secção "Limitações geográficas", cuja provável supressão havia sido anunciada no lançamento da consulta pública.

Richard Stallman no lançamento do primeiro rascunho da GNU GPLv3 no MIT , Cambridge, Massachusetts, Estados Unidos. À sua direita está o professor de direito da Columbia, Eben Moglen , presidente do Software Freedom Law Center.

O quarto rascunho de discussão, que foi o último, foi lançado em 31 de maio de 2007. Ele introduziu a compatibilidade da versão 2.0 da Licença Apache (as versões anteriores são incompatíveis), esclareceu a função de contratantes externos e abriu uma exceção para evitar os problemas percebidos de um Microsoft– Acordo de estilo da Novell, dizendo na Seção 11 parágrafo 6 que:

Você não pode transmitir um trabalho coberto se for parte de um acordo com um terceiro que está no negócio de distribuição de software, sob o qual você faz o pagamento a terceiros com base na extensão de sua atividade de transmissão do trabalho, e sob a qual o terceiro concede, a qualquer uma das partes que receberiam o trabalho coberto de você, uma licença de patente discriminatória  ...

O objetivo era tornar futuros negócios ineficazes. A licença também pretendia fazer com que a Microsoft estendesse as licenças de patentes concedidas aos clientes da Novell para o uso do software GPLv3 a todos os usuários desse software GPLv3; isso só era possível se a Microsoft fosse legalmente um "transportador" do software GPLv3.

Os primeiros rascunhos da GPLv3 também permitiam que os licenciadores adicionassem um requisito semelhante ao Affero que teria fechado a lacuna do ASP na GPL . Como havia preocupações expressas sobre os custos administrativos de verificação do código para este requisito adicional, foi decidido manter a licença GPL e a licença Affero separadas.

Outros, notavelmente alguns desenvolvedores de kernel Linux de alto nível , como Linus Torvalds , Greg Kroah-Hartman e Andrew Morton , comentaram na mídia de massa e fizeram declarações públicas sobre suas objeções às partes dos rascunhos de discussão 1 e 2. Os desenvolvedores de kernel referiram GPLv3 rascunho de cláusulas relativas a DRM / Tivoization , patentes e "restrições adicionais", e alertou sobre uma balcanização do "Universo de código aberto". Linus Torvalds, que decidiu não adotar a GPLv3 para o kernel Linux, reiterou sua crítica vários anos depois.

A GPLv3 melhorou a compatibilidade com várias licenças de software livre, como a Licença Apache, versão 2.0, e a Licença Pública Geral GNU Affero, com a qual a GPLv2 não pode ser combinada. No entanto, o software GPLv3 só poderia ser combinado e compartilhar o código com o software GPLv2 se a licença GPLv2 usada tivesse a cláusula opcional "ou posterior" e o software fosse atualizado para GPLv3. Embora a cláusula "GPLv2 ou qualquer versão posterior" seja considerada pela FSF como a forma mais comum de licenciamento do software GPLv2, o desenvolvedor da Toybox Rob Landley a descreveu como uma cláusula de barco salva - vidas . Projetos de software licenciados com a cláusula opcional "ou posterior" incluem o Projeto GNU , enquanto um exemplo proeminente sem a cláusula é o kernel do Linux.

A versão final do texto da licença foi publicada em 29 de junho de 2007.

Termos e Condições

Os termos e condições da GPL devem ser disponibilizados para qualquer pessoa que receba uma cópia da obra que tenha uma GPL aplicada a ela ("o licenciado"). Qualquer licenciado que aderir aos termos e condições tem permissão para modificar a obra, bem como para copiar e redistribuir a obra ou qualquer versão derivada. O licenciado pode cobrar uma taxa por este serviço ou fazê-lo gratuitamente. Este último ponto distingue a GPL das licenças de software que proíbem a redistribuição comercial. A FSF argumenta que o software livre não deve colocar restrições ao uso comercial, e a GPL afirma explicitamente que os trabalhos da GPL podem ser vendidos a qualquer preço.

A GPL afirma ainda que um distribuidor não pode impor "outras restrições aos direitos concedidos pela GPL". Isso proíbe atividades como distribuição de software sob um acordo ou contrato de não divulgação.

A quarta seção para a versão 2 da licença e a sétima seção da versão 3 requerem que os programas distribuídos como binários pré-compilados sejam acompanhados por uma cópia do código-fonte, uma oferta por escrito para distribuir o código-fonte através do mesmo mecanismo que o pré -compilado binário, ou a oferta por escrito para obter o código-fonte que o usuário obteve quando recebeu o binário pré-compilado sob a GPL. A segunda seção da versão 2 e a quinta seção da versão 3 também requerem o fornecimento de "a todos os destinatários uma cópia desta Licença junto com o Programa". A versão 3 da licença permite disponibilizar o código-fonte de maneiras adicionais em cumprimento à sétima seção. Isso inclui o download do código-fonte de um servidor de rede adjacente ou por transmissão ponto a ponto, desde que seja assim que o código compilado estiver disponível e haja "instruções claras" sobre onde encontrar o código-fonte.

A FSF não detém os direitos autorais de um trabalho lançado sob a GPL, a menos que um autor atribua explicitamente os direitos autorais à FSF (o que raramente acontece, exceto para programas que fazem parte do projeto GNU). Apenas os detentores de direitos autorais individuais têm autoridade para processar quando houver suspeita de violação de licença.

Declarações GPL impressas para dispositivos de entretenimento de consumidor que incorporam componentes GPL

Uso de software licenciado

O software sob a GPL pode ser executado para todos os fins, incluindo fins comerciais e até mesmo como uma ferramenta para a criação de software proprietário , como ao usar compiladores licenciados pela GPL . Os usuários ou empresas que distribuem trabalhos licenciados pela GPL (por exemplo, software) podem cobrar uma taxa pelas cópias ou dá-las gratuitamente. Isso distingue a GPL das licenças de software shareware que permitem a cópia para uso pessoal, mas proíbem a distribuição comercial ou licenças proprietárias em que a cópia é proibida pela lei de direitos autorais . A FSF argumenta que o software livre que respeita a liberdade também não deve restringir o uso comercial e a distribuição (incluindo a redistribuição):

Em uso puramente privado (ou interno) - sem vendas e sem distribuição - o código do software pode ser modificado e as partes reutilizadas sem exigir que o código-fonte seja liberado. Para vendas ou distribuição, todo o código-fonte precisa ser disponibilizado aos usuários finais, incluindo quaisquer alterações e adições de código - nesse caso, copyleft é aplicado para garantir que os usuários finais mantenham as liberdades definidas acima.

No entanto, o software executado como um programa aplicativo sob um sistema operacional licenciado GPL, como o Linux, não precisa ser licenciado sob GPL ou distribuído com disponibilidade de código-fonte - o licenciamento depende apenas das bibliotecas e componentes de software usados ​​e não de a plataforma subjacente. Por exemplo, se um programa consiste apenas em código-fonte original ou é combinado com código-fonte de outros componentes de software , os componentes de software personalizados não precisam ser licenciados sob GPL e não precisam disponibilizar seu código-fonte; mesmo que o sistema operacional subjacente usado seja licenciado sob a GPL, os aplicativos executados nele não são considerados trabalhos derivados. Somente se partes sob GPL forem usadas em um programa (e o programa for distribuído), todos os outros códigos-fonte do programa precisam ser disponibilizados sob os mesmos termos de licença. A GNU Lesser General Public License (LGPL) foi criada para ter um copyleft mais fraco do que a GPL, no sentido de que não requer código-fonte desenvolvido sob medida (diferente das partes LGPL) a ser disponibilizado sob os mesmos termos de licença .

A quinta seção da versão 3 afirma que nenhum código licenciado pela GPL deve ser considerado uma "medida de proteção técnica" eficaz, conforme definido pelo Artigo 11 do Tratado de Direitos Autorais da WIPO , e que aqueles que transmitem o trabalho renunciam a todo poder legal para proibir a evasão do medida de proteção técnica "na medida em que tal evasão for efetuado pelo exercício de direitos sob esta Licença com relação ao trabalho coberto". Isso significa que os usuários não podem ser responsabilizados por burlar o DRM implementado usando o código licenciado GPL v3 de acordo com leis como o Digital Millennium Copyright Act (DMCA) dos EUA .

Copyleft

Os direitos de distribuição concedidos pela GPL para versões modificadas da obra não são incondicionais. Quando alguém distribui um trabalho GPL com suas próprias modificações, os requisitos para distribuir todo o trabalho não podem ser maiores do que os requisitos que estão na GPL.

Esse requisito é conhecido como copyleft. Ele obtém seu poder legal do uso de direitos autorais em programas de software. Como uma obra GPL está protegida por direitos autorais, o licenciado não tem o direito de redistribuí-la, nem mesmo na forma modificada (impedindo o uso justo ), exceto sob os termos da licença. Só é necessário cumprir os termos da GPL se desejar exercer direitos normalmente restritos pela lei de direitos autorais, como redistribuição. Por outro lado, se alguém distribuir cópias da obra sem respeitar os termos da GPL (por exemplo, mantendo o código-fonte em segredo), eles podem ser processados pelo autor original sob a lei de direitos autorais.

A lei de direitos autorais tem sido historicamente usada para impedir a distribuição de trabalho por partes não autorizadas pelo criador. Copyleft usa as mesmas leis de direitos autorais para atingir um objetivo muito diferente. Ela concede direitos de distribuição a todas as partes, na medida em que fornecem os mesmos direitos para as partes subsequentes e eles para as próximas, etc. Dessa forma, a GPL e outras licenças copyleft tentam impor acesso livre à obra e a todos os derivados.

Muitos distribuidores de programas GPL agrupam o código-fonte com os executáveis . Um método alternativo de satisfazer o copyleft é fornecer uma oferta por escrito para fornecer o código-fonte em um meio físico (como um CD) mediante solicitação. Na prática, muitos programas GPL são distribuídos pela Internet e o código-fonte é disponibilizado por FTP ou HTTP . Para distribuição pela Internet, está em conformidade com a licença.

O copyleft se aplica apenas quando uma pessoa busca redistribuir o programa. Os desenvolvedores podem fazer versões modificadas privadas sem obrigação de divulgar as modificações, desde que não distribuam o software modificado a ninguém. O copyleft se aplica apenas ao software, e não à sua saída (a menos que a própria saída seja um trabalho derivado do programa). Por exemplo, um portal da web público executando um derivado modificado de um sistema de gerenciamento de conteúdo GPL não é obrigado a distribuir suas alterações para o software subjacente, porque sua saída não é um derivado.

Tem havido um debate sobre se é uma violação da GPL liberar o código-fonte na forma ofuscada , como nos casos em que o autor está menos disposto a disponibilizar o código-fonte. O consenso era que, embora antiético, não era considerado uma violação. O problema foi esclarecido quando a licença foi alterada com a v2 para exigir que a versão "preferencial" do código-fonte fosse disponibilizada.

Licença versus contrato

A GPL foi projetada como uma licença , ao invés de um contrato. Em algumas jurisdições de Common Law , a distinção legal entre uma licença e um contrato é importante: os contratos são executáveis ​​pela lei contratual , enquanto as licenças são executadas pela lei de direitos autorais . No entanto, essa distinção não é útil em muitas jurisdições onde não há diferenças entre contratos e licenças, como sistemas de Direito Civil .

Aqueles que não aceitam os termos e condições da GPL não têm permissão, sob a lei de direitos autorais, para copiar ou distribuir software licenciado GPL ou trabalhos derivados. No entanto, se eles não redistribuírem o programa GPL, eles ainda podem usar o software dentro de sua organização como quiserem, e os trabalhos (incluindo programas) construídos pelo uso do programa não precisam ser cobertos por esta licença.

A desenvolvedora de software Allison Randal argumentou que a licença GPLv3 é desnecessariamente confusa para leitores leigos e poderia ser simplificada, mantendo as mesmas condições e força legal.

Em abril de 2017, um tribunal federal dos EUA decidiu que uma licença de código aberto é um contrato executável.

Derivações

O próprio texto da GPL é protegido por direitos autorais , e os direitos autorais pertencem à Free Software Foundation.

A FSF permite que as pessoas criem novas licenças baseadas na GPL, desde que as licenças derivadas não usem o preâmbulo GPL sem permissão. Isso é desencorajado, no entanto, uma vez que tal licença pode ser incompatível com a GPL e causar uma proliferação de licença percebida .

Outras licenças criadas pelo projeto GNU incluem a GNU Lesser General Public License , a GNU Free Documentation License e a Affero General Public License .

O texto da GPL não está sob a GPL. O copyright da licença não permite a modificação da licença. A cópia e distribuição da licença são permitidas, uma vez que a GPL exige que os destinatários obtenham "uma cópia desta Licença junto com o Programa". De acordo com o FAQ da GPL, qualquer pessoa pode fazer uma nova licença usando uma versão modificada da GPL, desde que use um nome diferente para a licença, não mencione "GNU" e remova o preâmbulo, embora o preâmbulo possa ser usado em uma licença modificada se a permissão para usá-la for obtida da Free Software Foundation (FSF).

Vinculação e trabalhos derivados

Bibliotecas

De acordo com a FSF, "A GPL não exige que você libere sua versão modificada ou qualquer parte dela. Você é livre para fazer modificações e usá-las em particular, sem nunca liberá-las." No entanto, se alguém lança uma entidade licenciada pela GPL para o público, há um problema em relação à vinculação: a saber, se um programa proprietário que usa uma biblioteca GPL está violando a GPL.

A principal disputa é se o software não GPL pode vincular legalmente estaticamente ou vincular dinamicamente a bibliotecas GPL. Existem diferentes opiniões sobre este assunto. A GPL é clara ao exigir que todos os trabalhos derivados de código sob a GPL estejam eles próprios sob a GPL. A ambigüidade surge com relação ao uso de bibliotecas GPL e agrupamento do software GPL em um pacote maior (talvez misturado em um binário via link estático). Em última análise, esta é uma questão não da GPL em si , mas de como a lei de direitos autorais define os trabalhos derivados. Existem os seguintes pontos de vista:

Ponto de vista: links dinâmicos e estáticos violam GPL

A Free Software Foundation (que detém os direitos autorais de vários produtos de software licenciados pela GPL notáveis ​​e do próprio texto da licença) afirma que um executável que usa uma biblioteca vinculada dinamicamente é de fato um trabalho derivado. No entanto, isso não se aplica a programas separados que se comunicam entre si.

A Free Software Foundation também criou a LGPL , que é quase idêntica à GPL, mas com permissões adicionais para permitir links com o propósito de "usar a biblioteca".

Richard Stallman e a FSF encorajam especificamente os escritores de bibliotecas a licenciarem sob a GPL para que programas proprietários não possam usar as bibliotecas, em um esforço para proteger o mundo do software livre, dando-lhe mais ferramentas do que o mundo proprietário.

Ponto de vista: a vinculação estática viola a GPL, mas não é clara quanto à vinculação dinâmica

Algumas pessoas acreditam que, embora a vinculação estática produza trabalhos derivados, não está claro se um executável que se vincula dinamicamente a um código GPL deve ser considerado um trabalho derivado (veja copyleft fraco ). O autor do Linux, Linus Torvalds, concorda que os links dinâmicos podem criar trabalhos derivados, mas discorda das circunstâncias.

Um advogado da Novell escreveu que o vínculo dinâmico não sendo derivado "faz sentido", mas não é "claro", e que a evidência de vínculo dinâmico bem-intencionado pode ser vista pela existência de drivers de kernel Linux proprietários.

No caso Galoob v. Nintendo , o Tribunal de Apelações do Nono Circuito dos Estados Unidos definiu um trabalho derivado como tendo " 'forma' ou permanência" e observou que "o trabalho infrator deve incorporar uma parte do trabalho protegido por direitos autorais de alguma forma", mas houve não houve decisões judiciais claras para resolver este conflito específico.

Ponto de vista: a vinculação é irrelevante

De acordo com um artigo no Linux Journal , Lawrence Rosen (um ex- conselheiro geral da Open Source Initiative ) argumenta que o método de vinculação é irrelevante para a questão de saber se um pedaço de software é um trabalho derivado ; mais importante é a questão de saber se o software foi projetado para fazer interface com o software cliente e / ou bibliotecas. Ele afirma: "A principal indicação para saber se um novo programa é um trabalho derivado é se o código-fonte do programa original foi usado [no sentido de copiar e colar], modificado, traduzido ou alterado de alguma forma para criar o novo programa . Se não, eu argumentaria que não é um trabalho derivado ", e lista vários outros pontos relativos à intenção, agrupamento e mecanismo de ligação. Ele argumenta ainda no site de sua empresa que esses fatores "baseados no mercado" são mais importantes do que a técnica de vinculação.

Há também a questão específica de se um plugin ou módulo (como os módulos de kernel da placa gráfica NVidia ou ATI ) também deve ser GPL, se puder ser razoavelmente considerado seu próprio trabalho. Este ponto de vista sugere que plug-ins razoavelmente separados, ou plug-ins para software projetado para usar plug-ins, podem ser licenciados sob uma licença arbitrária se o trabalho for GPLv2. De particular interesse é o parágrafo GPLv2:

Você pode modificar sua cópia ou cópias do Programa ou qualquer parte dele, formando assim um trabalho baseado no Programa, e copiar e distribuir tais modificações ou trabalhos sob os termos da Seção 1 acima, desde que você também cumpra todas estas condições :  ...

b) Você deve fazer com que qualquer trabalho que você distribua ou publique, que no todo ou em parte contenha ou seja derivado do Programa ou de qualquer parte dele, seja licenciado como um todo sem nenhum custo para todos os terceiros sob os termos desta Licença .  ... Esses requisitos se aplicam à obra modificada como um todo. Se as seções identificáveis ​​desse trabalho não forem derivadas do Programa e puderem ser razoavelmente consideradas trabalhos independentes e separados em si mesmos, então esta Licença, e seus termos, não se aplicam a essas seções quando você os distribui como trabalhos separados. Mas quando você distribui as mesmas seções como parte de um todo que é um trabalho baseado no Programa, a distribuição do todo deve ser nos termos desta Licença, cujas permissões para outros licenciados se estendem ao todo e, portanto, a cada e cada parte, independentemente de quem o escreveu.

A GPLv3 tem uma cláusula diferente:

Você pode transmitir um trabalho baseado no Programa, ou as modificações para produzi-lo a partir do Programa, na forma de código-fonte nos termos da Seção 4, desde que você também atenda a todas estas condições:  ...

c) Você deve licenciar a obra inteira, como um todo, sob esta Licença para qualquer pessoa que obtenha uma cópia. Esta Licença, portanto, se aplicará, juntamente com quaisquer termos adicionais da Seção 7 aplicáveis, a todo o trabalho e todas as suas partes, independentemente de como foram embaladas. Esta Licença não dá permissão para licenciar o trabalho de qualquer outra forma, mas não invalida tal permissão se você a tiver recebido separadamente.  ... Uma compilação de uma obra coberta com outras obras separadas e independentes, que não são, por sua natureza, extensões da obra coberta, e que não são combinadas com ela de modo a formar um programa maior, em ou em um volume de um O meio de armazenamento ou distribuição é chamado de "agregado" se a compilação e seus direitos autorais resultantes não forem usados ​​para limitar o acesso ou os direitos legais dos usuários da compilação além do que as obras individuais permitem. A inclusão de uma obra coberta em um agregado não faz com que esta Licença se aplique às outras partes do agregado.

Como um estudo de caso, alguns plug-ins e temas / skins supostamente proprietários para software CMS GPLv2 , como Drupal e WordPress, foram criticados, com ambos os lados do argumento aceitos.

O FSF diferencia em como o plugin está sendo chamado. Se o plug-in for invocado por meio de ligação dinâmica e executar chamadas de função para o programa GPL, é mais provável que seja um trabalho derivado.

Comunicação e empacotamento com programas não GPL

O mero ato de comunicar-se com outros programas não exige, por si só, que todo o software seja GPL; nem distribuir software GPL com software não GPL. No entanto, pequenas condições devem ser seguidas para garantir que os direitos do software GPL não sejam restritos. O que se segue é uma citação do FAQ GPL de gnu.org , que descreve até que ponto o software tem permissão para se comunicar e ser agrupado com programas GPL:

Qual é a diferença entre um "agregado" e outros tipos de "versões modificadas"?

Um "agregado" consiste em vários programas separados, distribuídos juntos no mesmo CD-ROM ou outra mídia. A GPL permite que você crie e distribua um agregado, mesmo quando as licenças do outro software não são gratuitas ou são incompatíveis com a GPL. A única condição é que você não pode liberar o agregado sob uma licença que proíbe os usuários de exercer os direitos que a licença individual de cada programa concederia a eles.

Onde está a linha entre dois programas separados e um programa com duas partes? Esta é uma questão legal, que em última instância os juízes decidirão. Acreditamos que um critério adequado depende tanto do mecanismo de comunicação (exec, pipes, rpc, chamadas de função dentro de um espaço de endereço compartilhado, etc.) e da semântica da comunicação (quais tipos de informação são trocados).

Se os módulos estiverem incluídos no mesmo arquivo executável, eles serão definitivamente combinados em um programa. Se os módulos são projetados para serem executados juntos em um espaço de endereço compartilhado, isso quase certamente significa combiná-los em um programa.

Por outro lado, pipes, soquetes e argumentos de linha de comando são mecanismos de comunicação normalmente usados ​​entre dois programas separados. Portanto, quando são usados ​​para comunicação, os módulos normalmente são programas separados. Mas se a semântica da comunicação for íntima o suficiente, trocando estruturas de dados internas complexas, isso também poderia ser uma base para considerar as duas partes combinadas em um programa maior.

A FSF, portanto, traça a linha entre "biblioteca" e "outro programa" por meio de 1) "complexidade" e "intimidade" da troca de informações e 2) mecanismo (em vez de semântica), mas renuncia que a questão não é clara e que em situações complexas, a jurisprudência decidirá.

Status legal

A primeira violação conhecida da GPL foi em 1989, quando a NeXT estendeu o compilador GCC para suportar Objective-C , mas não divulgou publicamente as alterações. Após uma investigação, eles criaram um patch público . Não houve ação judicial movida por essa infração.

Em 2002, a MySQL AB processou a Progress NuSphere por violação de direitos autorais e marcas registradas no tribunal distrital dos Estados Unidos . NuSphere supostamente violou os direitos autorais do MySQL ao vincular o código GPL do MySQL à tabela NuSphere Gemini sem cumprir a licença. Depois de uma audiência preliminar perante a juíza Patti Saris em 27 de fevereiro de 2002, as partes entraram em negociações e, finalmente, chegaram a um acordo. Após a audiência, a FSF comentou que "a juíza Saris deixou claro que ela vê a GNU GPL como uma licença executável e obrigatória."

Em agosto de 2003, o SCO Group declarou que acreditava que a GPL não tinha validade legal e que pretendia entrar com ações judiciais sobre seções de código supostamente copiadas do SCO Unix para o kernel do Linux . Esta foi uma posição problemática para eles, já que distribuíram Linux e outros códigos GPL em sua distribuição Caldera OpenLinux , e há poucas evidências de que eles tivessem qualquer direito legal de fazê-lo, exceto sob os termos da GPL. Em fevereiro de 2018, após o julgamento do tribunal federal de primeira instância, recurso e o processo ter sido (parcialmente) devolvido ao tribunal distrital, as partes reafirmaram suas reivindicações remanescentes e forneceram um plano para avançar para o julgamento final.

Em abril de 2004, o projeto netfilter / iptables obteve uma injunção preliminar contra a Sitecom Alemanha pelo Tribunal Distrital de Munique depois que a Sitecom se recusou a desistir de distribuir o software GPL da Netfilter em violação aos termos da GPL. Harald Welte , da Netfilter, foi representado pelo cofundador do ifrOSS , Till Jaeger. Em julho de 2004, o tribunal alemão confirmou essa liminar como uma decisão final contra a Sitecom. A justificativa do tribunal foi que:

O réu infringiu os direitos autorais do autor ao oferecer o software 'netfilter / iptables' para download e ao anunciar sua distribuição, sem aderir às condições de licença da GPL. As referidas ações só seriam admissíveis se o réu tivesse a concessão da licença.  ... Isso independe da questão de saber se as condições de licenciamento da GPL foram efetivamente acordadas entre o autor e o réu ou não. Se a GPL não fosse acordada pelas partes, o réu, não obstante, não teria os direitos necessários para copiar, distribuir e tornar o software 'netfilter / iptables' publicamente disponível.

Isso refletiu exatamente as previsões dadas anteriormente por Eben Moglen da FSF. Essa decisão foi importante porque foi a primeira vez que um tribunal confirmou que a violação dos termos da GPL poderia ser uma violação de direitos autorais e estabeleceu jurisprudência quanto à aplicabilidade da GPL versão 2 sob a lei alemã.

Em maio de 2005, Daniel Wallace entrou com uma ação contra a Free Software Foundation no Distrito Sul de Indiana , alegando que a GPL é uma tentativa ilegal de fixar preços (em zero). O processo foi indeferido em março de 2006, com o fundamento de que Wallace não apresentou uma reivindicação antitruste válida; o tribunal observou que "a GPL incentiva, em vez de desencorajar, a livre concorrência e a distribuição de sistemas operacionais de computador, cujos benefícios passam diretamente para os consumidores". Wallace foi negada a possibilidade de emendar ainda mais sua reclamação e foi condenado a pagar as despesas legais da FSF.

Em 8 de setembro de 2005, o Tribunal Distrital Central de Seul decidiu que a GPL não era relevante para um caso que lidava com segredos comerciais derivados de obras licenciadas pela GPL. Os réus argumentaram que, uma vez que é impossível manter segredos comerciais e ao mesmo tempo estar em conformidade com a GPL e distribuir o trabalho, eles não violam segredos comerciais. Este argumento foi considerado sem fundamento.

Em 6 de setembro de 2006, o projeto gpl-violations.org prevaleceu em um litígio judicial contra a D-Link Germany GmbH em relação ao uso de partes do kernel Linux em dispositivos de armazenamento que a D-Link infringia os direitos autorais . O julgamento declarou que a GPL é válida, juridicamente vinculativa e está no tribunal alemão.

No final de 2007, os desenvolvedores do BusyBox e o Software Freedom Law Center iniciaram um programa para obter a conformidade com a GPL dos distribuidores do BusyBox em sistemas embarcados , processando aqueles que não cumpriam. Esses foram alegados ser os primeiros usos dos Estados Unidos de tribunais para o cumprimento das obrigações da GPL. (Consulte as ações judiciais da BusyBox GPL .)

Em 11 de dezembro de 2008, a Free Software Foundation processou a Cisco Systems, Inc. por violações de direitos autorais por sua divisão Linksys, dos pacotes de software coreutils licenciados pela GPL da FSF , readline , Parted , Wget , GNU Compiler Collection , binutils e GNU Debugger , que A Linksys distribui o firmware Linux de seus roteadores sem fio WRT54G , bem como vários outros dispositivos, incluindo modems DSL e a cabo, dispositivos de armazenamento conectado à rede, gateways de voz sobre IP, dispositivos de rede privada virtual e um dispositivo de home theater / reprodutor de mídia.

Depois de seis anos de reclamações repetidas à Cisco pela FSF, alegações da Cisco de que eles iriam corrigir, ou estavam corrigindo, seus problemas de conformidade (não fornecendo cópias completas de todo o código-fonte e suas modificações), de novas violações repetidas sendo descobertas e relatadas com mais produtos e falta de ação por parte da Linksys (um processo descrito no blog da FSF como um "jogo Whack-a-Mole de cinco anos de duração"), a FSF os levou ao tribunal.

A Cisco resolveu o caso seis meses depois, concordando em "nomear um Diretor de Software Livre para a Linksys" para garantir a conformidade ", para notificar destinatários anteriores de produtos Linksys contendo programas FSF de seus direitos sob a GPL", para fazer o código-fonte dos programas FSF gratuitamente disponível em seu site, e para fazer uma contribuição monetária para o FSF.

Em 2011, foi notado que o GNU Emacs estava lançando acidentalmente alguns binários sem o código-fonte correspondente por dois anos, em oposição ao espírito pretendido da GPL , resultando em uma violação de direitos autorais . Richard Stallman descreveu este incidente como um "erro muito grave", que foi prontamente corrigido. A FSF não processou nenhum redistribuidor downstream que também violou a GPL sem saber ao distribuir esses binários.

Em 2017, a Artifex, criadora do Ghostscript , processou a Hancom , criadora de um pacote de escritório que incluía o Ghostscript. Artifex oferece duas licenças para Ghostscript; uma é a licença Affero GPL e a outra é uma licença comercial. A Hancom não adquiriu uma licença comercial da Artifex nem lançou seu pacote de escritório como software livre. A Artifex processou Hancom no Tribunal Distrital dos Estados Unidos e fez duas ações. Primeiro, o uso do Ghostscript por Hancom foi uma violação de direitos autorais; e, segundo, o uso do Ghostscript por Hancom foi uma violação de licença. A juíza Jacqueline Scott Corley concluiu que a licença GPL era um contrato executável e que a Hancom estava em violação do contrato.

Compatibilidade e licenciamento múltiplo

Guia rápido de compatibilidade de licença com GPLv3 de acordo com a FSF. A linha tracejada indica que a GPLv2 só é compatível com a GPLv3 com a cláusula "ou qualquer versão posterior".

O código licenciado sob várias outras licenças pode ser combinado com um programa sob a GPL sem conflito, desde que a combinação de restrições no trabalho como um todo não coloque nenhuma restrição adicional além do que a GPL permite. Além dos termos regulares da GPL, existem restrições e permissões adicionais que podem ser aplicadas:

  1. Se um usuário deseja combinar código licenciado sob diferentes versões da GPL, isso só é permitido se o código com a versão anterior da GPL incluir uma declaração "ou qualquer versão posterior". Por exemplo, a biblioteca GNU LibreDWG com licença GPLv3 não pode mais ser usada por LibreCAD e FreeCAD que têm dependências apenas GPLv2.
  2. O código licenciado sob a LGPL pode ser vinculado a qualquer outro código, independentemente da licença desse código, embora a LGPL acrescente requisitos adicionais para o trabalho combinado. LGPLv3 e somente GPLv2 podem, portanto, normalmente não ser vinculados, já que o trabalho do Código combinado adicionaria requisitos LGPLv3 adicionais ao software licenciado somente GPLv2. Código licenciado sob LGPLv2.x sem a instrução "qualquer versão posterior" pode ser relicensed se todo o trabalho combinado é licenciado para GPLv2 ou GPLv3.

A FSF mantém uma lista de licenças de software livre compatíveis com GPL contendo muitas das licenças de software livre mais comuns, como a licença MIT / X original , a licença BSD (em sua forma atual de 3 cláusulas) e a Licença Artística 2.0.

Começando com a GPLv3, é unilateralmente compatível para materiais (como texto e outras mídias) sob a Licença Internacional Creative Commons Atribuição-Compartilhamento pela mesma Licença para serem remixados nos materiais licenciados pela GPL (principalmente software), e não vice-versa, para casos de uso de nicho como jogos motor (GPL) com scripts de jogo (CC-BY-SA).

David A. Wheeler defendeu que os desenvolvedores de software livre / de código aberto usam apenas licenças compatíveis com GPL, porque fazer o contrário torna difícil para outros participarem e contribuírem com código. Como um exemplo específico de incompatibilidade de licença, o ZFS da Sun Microsystems não pode ser incluído no kernel Linux com licença GPL, porque é licenciado sob a Licença de Desenvolvimento e Distribuição Comum incompatível com GPL . Além disso, o ZFS é protegido por patentes, portanto, distribuir uma implementação GPL desenvolvida de forma independente ainda exigiria a permissão da Oracle.

Várias empresas usam licenciamento múltiplo para distribuir uma versão GPL e vender uma licença proprietária para empresas que desejam combinar o pacote com código proprietário, usando links dinâmicos ou não. Exemplos de tais empresas incluem MySQL AB , Digia PLC ( framework Qt , antes de 2011 da Nokia ), Red Hat ( Cygwin ) e Riverbank Computing ( PyQt ). Outras empresas, como a Mozilla Foundation (produtos incluem Mozilla Application Suite , Mozilla Thunderbird e Mozilla Firefox ), usaram licenças múltiplas para distribuir versões sob a GPL e algumas outras licenças de código aberto.

Texto e outras mídias

É possível usar a GPL para documentos de texto em vez de programas de computador, ou mais geralmente para todos os tipos de mídia, se estiver claro o que constitui o código-fonte (definido como "a forma preferida de trabalho para fazer alterações nele") . No entanto, para manuais e livros didáticos, a FSF recomenda a GNU Free Documentation License (GFDL), que foi criada para esse propósito. No entanto, os desenvolvedores Debian recomendaram (em uma resolução adotada em 2006) licenciar a documentação para seus projetos sob a GPL, por causa da incompatibilidade da GFDL com a GPL (texto licenciado sob a GFDL não pode ser incorporado ao software GPL). Além disso, a FLOSS Manuals Foundation, uma organização dedicada à criação de manuais para software livre, decidiu evitar a GFDL em favor da GPL para seus textos em 2007.

Se a GPL for usada para fontes de computador , quaisquer documentos ou imagens feitos com essas fontes também podem ter que ser distribuídos sob os termos da GPL. Este não é o caso em países que reconhecem as fontes (a aparência das fontes) como sendo um artigo útil e, portanto, não qualificado para direitos autorais , mas os arquivos de fontes como software de computador protegido por direitos autorais (o que pode complicar a incorporação de fontes, uma vez que o documento pode ser considerado 'vinculado 'para a fonte; em outras palavras, incorporar uma fonte vetorial em um documento poderia forçá-lo a ser lançado sob a GPL, mas uma renderização rasterizada da fonte não estaria sujeita à GPL). A FSF oferece uma exceção para os casos em que isso não é desejado.

Adoção

Historicamente, a família de licenças GPL tem sido uma das licenças de software mais populares no domínio FOSS .

Uma pesquisa de 1997 do MetaLab , então o maior arquivo de software livre, mostrou que a GPL respondia por cerca de metade do software licenciado. Da mesma forma, uma pesquisa de 2000 do Red Hat Linux 7.1 descobriu que 53% do código-fonte foi licenciado sob a GPL. Em 2003, cerca de 68% de todos os projetos e 82,1% dos projetos licenciados certificados pela indústria de código aberto listados no SourceForge.net eram da família de licenças GPL. Em agosto de 2008, a família GPL respondia por 70,9% dos 44.927 projetos de software livre listados no Freecode .

Após o lançamento da GPLv3 em junho de 2007, a adoção desta nova versão GPL foi muito discutida e alguns projetos decidiram não fazer a atualização. Por exemplo, o kernel Linux, MySQL , BusyBox , AdvFS , Blender , VLC media player e MediaWiki decidiram não adotar GPLv3. Por outro lado, em 2009, dois anos após o lançamento da GPLv3, o gerente do escritório de programas de código aberto do Google , Chris DiBona, relatou que o número de software licenciado de projeto de código aberto que mudou da GPLv2 para a GPLv3 foi de 50%, contando os projetos hospedado no Google Code .

Em 2011, quatro anos após o lançamento da GPLv3, 6,5% de todos os projetos de licença de código aberto são GPLv3, enquanto 42,5% são GPLv2, de acordo com dados da Black Duck Software. Em 2011 , o analista do 451 Group , Matthew Aslett, argumentou em um blog que as licenças copyleft entraram em declínio e as licenças permissivas aumentaram, com base nas estatísticas da Black Duck Software. Da mesma forma, em fevereiro de 2012 Jon Buys relatou que entre os 50 principais projetos no GitHub, cinco projetos estavam sob uma licença GPL, incluindo projetos com licença dupla e projetos AGPL.

As estatísticas de uso da GPL de 2009 a 2013 foram extraídas dos dados do Freecode por Walter van Holst enquanto analisava a proliferação de licenças .

Uso de licenças da família GPL em% no Freecode
2009 2010 2011 2012 2013 18/06/2014
72% 63% 61% 59% 58% Aproximadamente. 54%

Em agosto de 2013, de acordo com a Black Duck Software, os dados do site mostram que a família de licenças GPL é usada por 54% dos projetos de código aberto, com o detalhamento das licenças individuais mostrado na tabela a seguir. No entanto, um estudo posterior em 2013 mostrou que o software licenciado sob a família de licenças GPL aumentou e que mesmo os dados da Black Duck Software mostraram um aumento total de projetos de software licenciados sob GPL. O estudo usou informações públicas coletadas de repositórios do Projeto Debian , e o estudo criticou a Black Duck Software por não publicar sua metodologia usada na coleta de estatísticas. Daniel German, professor do Departamento de Ciência da Computação da Universidade de Victoria no Canadá, apresentou uma palestra em 2013 sobre os desafios metodológicos em determinar quais são as licenças de software livre mais utilizadas e mostrou como não conseguiu replicar o resultado de Black Duck Software.

Em 2015, de acordo com a Black Duck, a GPLv2 perdeu sua primeira posição para a licença do MIT e agora é a segunda, a GPLv3 caiu para a quarta posição enquanto a licença Apache manteve sua terceira posição.

Uso de licenças da família GPL no domínio FOSS em% de acordo com a Black Duck Software
Licença 08/05/2008 11/03/2009 22/11/2011 12/08/2013 19/11/2015 06/06/2016 02/01/2017 04/06/2018
GPLv2 58,69% 52,2% 42,5% 33% 23% 21% 19% 14%
GPLv3 1,64% 4,15% 6,5% 12% 9% 9% 8% 6%
LGPLv2.1 11,39% 9,84% ? 6% 5% 4% 4% 3%
LGPLv3 ? (<0,64%) 0,37% ? 3% 2% 2% 2% 1%
Família GPL junta 71,72% (+ <0,64%) 66,56% ? 54% 39% 36% 33% 24%

Uma análise de março de 2015 dos repositórios GitHub revelou, para a família de licenças GPL, uma porcentagem de uso de aproximadamente 25% entre os projetos licenciados. Em junho de 2016, uma análise dos pacotes do Projeto Fedora revelou a GNU GPL versão 2 ou posterior como a licença mais popular, e a família GNU GPL como a família de licenças mais popular (seguida pelas famílias MIT, BSD e GNU LGPL) .

Uma análise do whitesourcesoftware.com em abril de 2018 do ecossistema FOSS viu a GPLv3 em terceiro lugar (18%) e a GPLv2 em quarto lugar (11%), depois da licença MIT (26%) e da licença Apache 2.0 (21%).

Recepção

Barreira legal para lojas de aplicativos

A GPL é incompatível com muitos sistemas de distribuição digital de aplicativos , como a Mac App Store e algumas outras plataformas de distribuição de software (em smartphones e também em PCs). O problema está no direito "Fazer uma cópia para o seu vizinho", pois esse direito é violado pelos sistemas de gerenciamento de direitos digitais embutidos na plataforma para impedir a cópia de software pago. Mesmo que o aplicativo seja gratuito na App Store em questão, isso pode resultar em uma violação dos termos dessa loja de aplicativos.

Há uma distinção entre uma loja de aplicativos , que vende software restrito a DRM sob licenças proprietárias, e o conceito mais geral de distribuição digital por meio de alguma forma de repositório de software online. Várias distribuições do tipo UNIX fornecem repositórios de aplicativos, incluindo Fedora , RHEL , CentOS , Ubuntu , Debian, FreeBSD , OpenBSD e assim por diante. Todos esses repositórios de aplicativos específicos contêm aplicativos de software licenciados pela GPL, em alguns casos, mesmo quando o projeto principal não permite código licenciado pela GPL no sistema base (por exemplo, OpenBSD). Em outros casos, como o Ubuntu App Store , aplicativos de software comercial proprietários e aplicativos licenciados pela GPL estão disponíveis através do mesmo sistema; o motivo de a Mac App Store (e projetos semelhantes) ser incompatível com aplicativos licenciados pela GPL não é inerente ao conceito de loja de aplicativos, mas sim especificamente devido ao requisito dos termos de uso da Apple de que todos os aplicativos da loja utilizam Restrições de DRM da Apple. A app store do Ubuntu não exige nenhum desses requisitos: "Estes termos não limitam ou restringem seus direitos sob quaisquer licenças de software de código aberto aplicáveis."

Microsoft

Em 2001, o CEO da Microsoft , Steve Ballmer, referiu-se ao Linux como "um câncer que se liga a tudo que toca" no sentido de propriedade intelectual. Em resposta aos ataques da Microsoft à GPL, vários desenvolvedores e defensores de Software Livre proeminentes divulgaram uma declaração conjunta de apoio à licença. A Microsoft lançou o Microsoft Windows Services for UNIX , que contém código licenciado GPL. Em julho de 2009, a própria Microsoft lançou um corpo de cerca de 20.000 linhas de código de driver do Linux sob a GPL. O código Hyper-V que faz parte do código enviado usava componentes de código aberto licenciados sob a GPL e estava originalmente vinculado estaticamente a partes binárias proprietárias, sendo a última inadmissível em software licenciado pela GPL.

Natureza "viral"

A descrição da GPL como "viral" , quando chamada de 'Vírus Público Geral' ou 'Vírus Público GNU' (GPV), data de um ano após o lançamento da GPLv1.

Em 2001, o termo recebeu atenção pública mais ampla quando Craig Mundie , vice-presidente sênior da Microsoft, descreveu a GPL como sendo "viral". Mundie argumenta que a GPL tem um efeito "viral" por permitir apenas o transporte de programas inteiros, o que significa que os programas que se vinculam a bibliotecas GPL devem estar sob uma licença compatível com GPL, do contrário não podem ser combinados e distribuídos.

Em 2006, Richard Stallman respondeu em uma entrevista que a metáfora de Mundie de um "vírus" é errada, já que o software sob a GPL não "ataca" ou "infecta" outro software. Stallman acredita que comparar a GPL a um vírus é uma coisa extremamente hostil de se dizer, e que uma metáfora melhor para software sob a GPL seria uma planta aranha : se alguém pegar um pedaço dele e colocá-lo em outro lugar, ele cresce lá também .

Por outro lado, o conceito de natureza viral da GPL também foi adotado por outros mais tarde. Por exemplo, um artigo de 2008 declarou: "A licença GPL é 'viral', o que significa que qualquer trabalho derivado que você criar contendo até mesmo a menor parte do software previamente licenciado GPL também deve ser licenciado sob a licença GPL."

Barreira para comercialização

O projeto FreeBSD afirmou que "um uso menos divulgado e não intencional da GPL é que ela é muito favorável para grandes empresas que querem minar empresas de software. Em outras palavras, a GPL é adequada para uso como uma arma de marketing, potencialmente reduzindo benefício econômico geral e contribuindo para o comportamento monopolista "e que a GPL pode" representar um problema real para aqueles que desejam comercializar e lucrar com software. "

Richard Stallman escreveu sobre a prática de vender exceções de licença para licenças de software livre como um exemplo de prática de comercialização eticamente aceitável. Vender exceções aqui significa que o detentor dos direitos autorais de um determinado software o libera (junto com o código-fonte correspondente) ao público sob uma licença de software livre ", então permite que os clientes paguem pela permissão para usar o mesmo código em termos diferentes, por exemplo, permitindo sua inclusão em aplicações proprietárias ". Stallman considerou a venda de exceções "aceitável desde os anos 1990, e algumas vezes eu sugeri isso às empresas. Às vezes, essa abordagem tornou possível que programas importantes se tornassem software livre". Embora a FSF não pratique a venda de exceções, uma comparação com a licença X11 (que é uma licença de software livre não copyleft) é proposta para sugerir que esta técnica de comercialização deve ser considerada eticamente aceitável. O lançamento de um determinado programa sob uma licença de software livre sem copyleft permitiria embutir o código em software proprietário. Stallman comenta que "ou temos que concluir que é errado liberar qualquer coisa sob a licença X11 - uma conclusão que considero inaceitavelmente extrema - ou rejeitar essa implicação. Usar uma licença não copyleft é fraca e geralmente uma escolha inferior, mas não é Em outras palavras, a venda de exceções permite alguma incorporação em software proprietário, e a licença do X11 permite ainda mais incorporação. Se isso não torna a licença do X11 inaceitável, não torna a venda de exceções inaceitável ".

Críticas de código aberto

Em 2000, o desenvolvedor e autor Nikolai Bezroukov publicou uma análise e crítica abrangente dos fundamentos da GPL e do modelo de desenvolvimento de software de Stallman, chamada "Labyrinth of Software Freedom".

A versão 2 da WTFPL (licença pública Faça o que você quiser) foi criada pelo líder do projeto Debian Sam Hocevar em 2004 como uma paródia da GPL.

Em 2005, o defensor do software de código aberto Eric S. Raymond questionou a relevância da GPL para o ecossistema FOSS, afirmando: "Não precisamos mais da GPL. É baseado na crença de que o software de código aberto é fraco e precisa ser protegido . O código-fonte aberto teria sucesso mais rápido se a GPL não deixasse muitas pessoas nervosas sobre sua adoção. " Richard Stallman respondeu: "A GPL foi projetada para ... garantir que cada usuário de um programa obtenha as liberdades essenciais - para executá-lo, estudar e alterar o código-fonte, redistribuir cópias e publicar versões modificadas  ... [Raymond ] aborda a questão em termos de diferentes objetivos e valores - aqueles do 'código aberto', que não incluem a defesa da liberdade dos usuários de software de compartilhar e alterar o software. "

Em 2007, Allison Randal , que participou do comitê de rascunho da GPL, criticou a GPLv3 por ser incompatível com a GPLv2 e por falta de clareza na formulação. Da mesma forma, Whurley profetizou em 2007 a queda da GPL devido à falta de foco para os desenvolvedores com GPLv3, o que os levaria a licenças permissivas.

Em 2009, David Chisnall descreveu em um artigo da InformIT , "The Failure of the GPL", os problemas com a GPL, entre eles a incompatibilidade e a complexidade do texto da licença.

Em 2014, o desenvolvedor dtrace e Joyent CTO Bryan Cantrill chamou o copyleft GPL de " Anti-padrão de código aberto corporativo " por ser "anti-colaborativo" e recomendou licenças de software permissivas .

Crítica GPLv3

Já em setembro de 2006, no processo de rascunho da GPLv3, vários desenvolvedores de alto nível do kernel do Linux, por exemplo Linus Torvalds, Greg Kroah-Hartman e Andrew Morton , alertaram sobre uma divisão da comunidade FOSS: "o lançamento de A GPLv3 prenuncia a balcanização de todo o Universo de código aberto no qual confiamos. " Da mesma forma, Benjamin Mako Hill argumentou em 2006 sobre o rascunho da GPLv3, observando que uma comunidade unida e colaboradora é mais importante do que uma única licença.

Após o lançamento da GPLv3 em 2007, alguns jornalistas e desenvolvedor de Toybox Rob Landley criticaram que com a introdução da GPLv3 a divisão entre o código aberto e a comunidade de software livre tornou-se maior do que nunca. Como a GPLv3 significativamente estendida é essencialmente incompatível com a GPLv2, a compatibilidade entre ambas é dada apenas sob a cláusula opcional "ou posterior" da GPL, que não era considerada, por exemplo, pelo kernel do Linux. Bruce Byfield observou que antes do lançamento da GPLv3, a GPLv2 era um elemento unificador entre o código aberto e a comunidade de software livre.

Para o LGPLv3, o mantenedor do GNU TLS, Nikos Mavrogiannopoulos, argumentou de forma semelhante: "Se assumirmos que seu [o LGPLv3] objetivo principal é ser usado por software livre, então ele falha descaradamente", depois que ele re-licenciou o GNU TLS do LGPLv3 de volta para LGPLv2.1 devido a problemas de compatibilidade de licença .

Lawrence Rosen , advogado e especialista em informática, elogiou em 2007 como a comunidade que usava a licença Apache agora era capaz de trabalhar em conjunto com a comunidade GPL de maneira compatível, pois os problemas de compatibilidade da GPLv2 com o software licenciado Apache foram resolvidos com a GPLv3. Ele disse: "Prevejo que uma das maiores histórias de sucesso da GPLv3 será a compreensão de que todo o universo de software livre e de código aberto pode ser combinado em soluções abrangentes de código aberto para clientes em todo o mundo."

Em julho de 2013, o desenvolvedor do Flask , Armin Ronacher, traçou um currículo menos otimista sobre a compatibilidade da GPL no ecossistema FOSS quando concluiu: "Quando a GPL está envolvida, as complexidades do licenciamento se tornam uma versão não divertida de um enigma", observando também que o conflito entre Apache License 2.0 e GPLv2 ainda tem impacto no ecossistema.

Veja também

Notas

Referências

links externos