Licença de software livre

Da Wikipédia, a enciclopédia livre
Ir para a navegação Saltar para pesquisar

O espectro de licenciamento de software livre e alguns exemplos de programas sob essas licenças [1]

Uma licença de software livre é um aviso que concede ao destinatário de um software direitos extensivos para modificar e redistribuir esse software. Essas ações geralmente são proibidas pela lei de direitos autorais , mas o detentor dos direitos (geralmente o autor) de um software pode remover essas restrições acompanhando o software com uma licença de software que concede ao destinatário esses direitos. O software que usa tal licença é software livre (ou software livre e de código aberto ) conforme conferido pelo detentor dos direitos autorais. As licenças de software livre são aplicadas ao software no código-fonte e também no código-objeto binárioforma, uma vez que a lei de direitos autorais reconhece ambas as formas. [2]

Comparação

Tipos de licença de software e licenças semelhantes. As colunas destacadas são software livre .
Domínio público e equivalentes Licença permissiva Copyleft (licença de proteção) Licença não comercial Licença proprietária Segredo comercial
Descrição Concede todos os direitos Concede direitos de uso, incluindo direito de relicenciar (permite propriedade , compatibilidade de licença ) Concede direitos de uso, proíbe a propriedade Concede direitos apenas para uso não comercial. Pode ser combinado com copyleft. Uso tradicional de direitos autorais ; nenhum direito precisa ser concedido Nenhuma informação é divulgada
Programas PD, CC0 MIT , Apache , MPL GPL , AGPL JRL , AFPL software proprietário , sem licença pública software interno e privado
Outros trabalhos criativos PD, CC0 CC-BY CC-BY-SA CC-BY-NC Direitos autorais , sem licença pública inédito

As licenças de software livre fornecem mitigação de risco contra diferentes ameaças ou comportamentos legais que são vistos como potencialmente prejudiciais pelos desenvolvedores:

Licenças protetoras e permissivas usadas com frequência
AGPLv3 GPLv3 GPLv2.1 LGPLv3 LGPLv2.1 MPL-2 BSD
SaaS/nuvem sim Não Não Não Não Não Não
Tivoização sim sim Não sim Não Não Não
Trollagem de patentes sim sim Não sim Não Não Não
Propriedade sim sim sim Parcial Parcial Parcial Não
Granularidade / alcance Projeto Projeto Projeto Biblioteca Biblioteca Arquivo N / D
Concessão de marca registrada sim sim ? sim ? Não Não

História

Pré-1980

Nos primeiros tempos do software, o compartilhamento de software e código-fonte era comum em certas comunidades, por exemplo, instituições acadêmicas. Antes que a Comissão de Novos Usos Tecnológicos de Obras com Direitos Autorais dos Estados Unidos (CONTU) decidisse em 1974 que "programas de computador, na medida em que incorporam a criação original de um autor, são objeto de direito autoral", [3] [4] software não era considerado protegido por direitos autorais. Portanto, o software não tinha licenças anexadas e era compartilhado como software de domínio público . A decisão do CONTU mais decisões judiciais como Apple v. Franklin em 1983 para código de objeto , esclareceu que a Lei de Direitos Autorais deu aos programas de computador o status de direitos autorais de obras literárias e iniciou alicenciamento de software .

As licenças de software livre antes do final da década de 1980 eram geralmente avisos informais escritos pelos próprios desenvolvedores. Essas primeiras licenças eram do tipo " permissivo ".

década de 1980

Em meados da década de 1980, o projeto GNU produziu licenças de software livre copyleft para cada um de seus pacotes de software. Uma dessas licenças anteriores (o "Aviso de Permissão de Cópia do GNU Emacs") foi usada para o GNU Emacs em 1985, [5] que foi revisada para a "Licença Pública Geral GNU Emacs" no final de 1985 e esclarecida em março de 1987 e fevereiro de 1988. [6] [7] [8] Da mesma forma, a similar GCC General Public License foi aplicada à GNU Compiler Collection , que foi publicada inicialmente em 1987. [9] [10] A licença BSD original também é uma das primeiras licenças de software, datadas de 1988. Em 1989, a versão 1 da GNU General Public License (GPL) foi publicada. A versão  2 da GPL, lançada em 1991, tornou-se a licença de software livre mais usada. [11] [12] [13]

Décadas de 1990 a 2000

Começando em meados da década de 1990 e até meados da década de 2000, o movimento de código aberto impulsionou e focou a ideia do software livre no público em geral e na percepção dos negócios. [14] Na época da bolha das pontocom , o passo da Netscape Communications para liberar seu navegador sob uma licença FOSS em 1998, [15] [16] inspirou muitas outras empresas a se adaptarem ao ecossistema FOSS. [17] Nesta tendência, empresas e novos projetos ( Mozilla , Apache Foundation e Sun , veja também esta lista ) escreveram suas próprias licenças FOSS, ou adaptaram licenças existentes. Esta proliferação de licençasfoi posteriormente reconhecido como um problema para o ecossistema gratuito e de código aberto devido à maior complexidade das considerações de compatibilidade de licença . [18] Embora a criação de novas licenças tenha diminuído mais tarde, a proliferação de licenças e seu impacto são considerados um sério desafio contínuo para o ecossistema de código aberto e gratuito.

Das licenças de software livre, a GNU GPL versão  2 foi testada em tribunal, primeiro na Alemanha em 2004 e depois nos EUA. No caso alemão, o juiz não discutiu explicitamente a validade das cláusulas da GPL, mas aceitou que a GPL deveria ser respeitada: "Se a GPL não fosse acordada pelas partes, o réu não teria os direitos necessários para copiar, distribuir , e tornar o software 'netfilter/iptables' publicamente disponível." Como o réu não cumpriu com a GPL, teve que cessar o uso do software. [19] O caso dos EUA ( MySQL vs Progress) foi resolvido antes do veredicto, mas em uma audiência inicial, o juiz Saris "não viu nenhuma razão" para que a GPL não fosse executória. [20]

Por volta de 2004, o advogado Lawrence Rosen argumentou no ensaio Por que o domínio público não é uma licença de software não poderia realmente ser renunciado ao domínio público e não pode ser interpretado como uma licença FOSS muito permissiva, [21] uma posição que enfrentou oposição por Daniel J .Berstein e outros. [22] Em 2012, a disputa foi finalmente resolvida quando Rosen aceitou a CC0 como licença de código aberto , embora admitindo que, ao contrário de suas reivindicações anteriores, os direitos autorais podem ser renunciados, apoiados por decisões do Nono Circuito . [23]

Em 2007, após anos de discussão preliminar, a GPLv3 como atualização principal da GPLv2 foi lançada. O lançamento foi controverso [24] devido ao significativo escopo estendido da licença, que a tornou incompatível com a GPLv2. [25] Vários grandes projetos FOSS ( kernel Linux , [26] [27] MySQL , [28] BusyBox , [29] [30] Blender , [31] VLC media player [32] ) decidiram não adotar a GPLv3. Por outro lado, em 2009, dois anos após o lançamento da GPLv3, o GoogleO gerente do escritório de programas de código aberto, Chris DiBona, informou que o número de projetos de software de código aberto licenciados que mudaram para a GPLv3 da GPLv2 foi de 50%, contando os projetos hospedados no Google Code . [33]

Anos 2010

Em 2011, quatro anos após o lançamento da GPLv3, 6,5% de todos os projetos licenciados de código aberto eram GPLv3, enquanto 42,5% ainda eram GPLv2, de acordo com dados da Black Duck Software. [27] [34] Seguindo em 2011 , o analista do 451 Group , Matthew Aslett, argumentou em um post de 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. [35] [36]

Em 2015, de acordo com as estatísticas da Black Duck Software [37] e do GitHub , [38] a licença permissiva do MIT destronou a GPLv2 como licença de software livre mais popular para o segundo lugar, enquanto a licença permissiva do Apache já segue em terceiro lugar. Em junho de 2016 uma análise dos pacotes do Projeto Fedora revelou como licenças mais usadas a GPL, MIT, BSD e a LGPL . [39]

Definições

Licenças de código aberto aprovadas pela OSI

O grupo Open Source Initiative (OSI) define e mantém uma lista de licenças de código aberto aprovadas . A OSI concorda com a FSF em todas as licenças de software livre amplamente utilizadas, mas difere da lista da FSF, pois aprova contra a Definição de Código Aberto em vez da Definição de Software Livre . Ele considera o grupo de licenças Permissivas de Software Livre como uma implementação de referência de uma licença de Software Livre. [ citação necessária ] [ esclarecimento necessário ] Assim, seus requisitos para aprovação de licenças são diferentes.

Licenças de software livre aprovadas pela FSF

A Free Software Foundation , o grupo que mantém a Free Software Definition , mantém uma lista não exaustiva de licenças de software livre. [40]

A Free Software Foundation prefere o licenciamento de software livre copyleft ( share-alike ) em vez de licenciamento permissivo de software livre para a maioria dos propósitos. Sua lista distingue entre licenças de software livre que são compatíveis ou incompatíveis com a GNU General Public License da FSF .

Condições nas licenças de software livre

Existe um debate contínuo dentro da comunidade de software livre sobre a linha tênue entre quais restrições podem ser aplicadas e ainda serem chamadas de "livres". [ citação necessária ]

Apenas " software de domínio público " e software sob uma licença de domínio público é livre de restrições. [ citação necessária ] Exemplos de licenças de domínio público são, por exemplo, a licença WTFPL e CC0 . Licenças permissivas podem conter pequenas obrigações como atribuição do autor, mas permitem praticamente todos os casos de uso de código. Certas licenças, nomeadamente as licenças copyleft , incluem restrições intencionalmente mais fortes (especialmente na distribuição/distribuidor) para forçar os projetos derivados a garantir direitos específicos que não podem ser retirados.

Copyleft

As licenças share-alike de software livre escritas por Richard Stallman em meados da década de 1980 foram pioneiras em um conceito conhecido como "copyleft". As cláusulas de copyleft que se seguiram declararam que quando versões modificadas de software livre são distribuídas, elas devem ser distribuídas sob os mesmos termos do software original. Por isso, eles são chamados de "compartilhar e compartilhar da mesma forma " ou " quid pro quo ". Isso faz com que o novo software também seja de código aberto. Como o copyleft garante que as gerações posteriores do software concedam a liberdade de modificar o código, isso é "software livre". As licenças sem copyleft não garantem que as gerações posteriores do software permaneçam livres.

Os desenvolvedores que usam código GPL em seus produtos devem disponibilizar o código-fonte para qualquer pessoa quando compartilharem ou venderem o código-objeto . Nesse caso, o código-fonte também deve conter quaisquer alterações que os desenvolvedores possam ter feito. Se o código GPL for usado, mas não compartilhado ou vendido, o código não precisa ser disponibilizado e quaisquer alterações podem permanecer privadas. Isso permite que desenvolvedores e organizações usem e modifiquem o código GPL para fins privados (ou seja, quando o código ou o projeto não for vendido ou compartilhado) sem serem obrigados a disponibilizar suas alterações ao público.

Os defensores da GPL afirmam que, ao exigir que os trabalhos derivados permaneçam sob a GPL, promove o crescimento do software livre e exige participação igual de todos os usuários. Os opositores da GPL alegam [41] que "nenhuma licença pode garantir a disponibilidade futura do software" e que as desvantagens da GPL superam [42] suas vantagens. Alguns também argumentam que restringir a distribuição torna a licença menos gratuita. Enquanto os proponentes argumentariam que não preservar a liberdade durante a distribuição a tornaria menos gratuita. Por exemplo, uma licença sem copyleft não concede ao autor a liberdade de ver versões modificadas de seu trabalho se for publicado publicamente, enquanto uma licença copyleft concede essa liberdade.

Retaliação de patentes

Durante a década de 1990, as licenças de software livre começaram a incluir cláusulas, como retaliação de patentes , para proteger contra casos de litígios de patentes de software – um problema que não existia anteriormente. Esta nova ameaça foi uma das razões para escrever a versão  3 da GNU GPL em 2006. [43] Nos últimos anos, um termo cunhado tivoização descreve um processo onde restrições de hardware são usadas para evitar que usuários executem versões modificadas do software naquele hardware, no qual o dispositivo TiVo é um exemplo. É visto pela FSF como uma forma de transformar software livre em não-livre, e é por isso que eles decidiram proibi-lo na GPLv3 . [44] A maioria das licenças de software livre recém-escritas desde o final da década de 1990 inclui alguma forma de cláusulas de retaliação de patentes. Essas medidas estipulam que os direitos de alguém sob a licença (como redistribuição) podem ser rescindidos se alguém tentar fazer valer patentes relacionadas ao software licenciado, sob certas circunstâncias. Como exemplo, a Apple Public Source License pode rescindir os direitos de um usuário se esse usuário iniciar um processo judicial contra ele devido a um litígio de patente. A retaliação de patentes surgiu em resposta à proliferação e abuso de patentes de software .

Restrições de hardware

A versão  3 da GNU GPL inclui linguagem específica que proíbe restrições adicionais impostas por restrições de hardware e gerenciamento de direitos digitais (DRM) , uma prática que a FSF chama de tivoização depois que a Tivo usou software GPL em dispositivos que não permitiam a modificação do usuário desse software.

Atribuição, isenções de responsabilidade e avisos

A maioria das licenças de software livre exige que o software modificado não pretenda ser não modificado. Algumas licenças também exigem que os detentores de direitos autorais sejam creditados. Um exemplo é a versão  2 da GNU GPL, que exige que programas interativos que imprimam informações de garantia ou licença não tenham esses avisos removidos das versões modificadas destinadas à distribuição.

Problemas práticos com licenças

Compatibilidade de licenças

Compatibilidade de licenças entre licenças de software FOSS comuns de acordo com David A. Wheeler (2007): as setas vetoriais denotam uma compatibilidade unidirecional, portanto, melhor compatibilidade no lado esquerdo ("licenças permissivas") do que no lado direito ("licenças copyleft") [45]

As licenças de pacotes de software contendo requisitos contraditórios impossibilitam a combinação do código-fonte desses pacotes para a criação de novos pacotes de software. [46] A compatibilidade de licença entre uma licença copyleft e outra licença geralmente é apenas uma compatibilidade unidirecional. [47] Essa característica de "compatibilidade unidirecional" é, por exemplo, criticada pela Apache Foundation , que fornece a licença Apache mais permissiva que não possui essa característica. [48] As licenças sem copyleft, como as licenças permissivas FOSS , têm uma interação de licença menos complicada e normalmente exibem uma melhor compatibilidade de licença. [49][50] Por exemplo, se uma licença diz que "versões modificadas devem mencionar os desenvolvedores em qualquer material publicitário" e outra licença diz que "versões modificadas não podem conter requisitos de atribuição adicionais", então, se alguém combinou um pacote de software que usa uma licença com um pacote de software que usa o outro, seria impossível distribuir a combinação porque esses requisitos contraditórios não podem ser atendidos simultaneamente. Assim, esses dois pacotes seriam incompatíveis com a licença. Quando se trata de licenças de software copyleft , elas não são inerentemente compatíveis com outras licenças copyleft, mesmo a GPLv2 é, por si só, não compatível com a GPLv3. [25] [51]

Finalidade de uso

Restrições ao uso de um software ("restrições de uso") são geralmente inaceitáveis ​​de acordo com as distribuições FSF, OSI , Debian ou baseadas em BSD. Os exemplos incluem a proibição de que o software seja usado para aplicações não privadas, para fins militares, para comparação ou benchmarking, para bom uso, [ esclarecimentos necessários ] para meios eticamente questionáveis, [52] ou em organizações comerciais. [53] Enquanto algumas restrições à liberdade do usuário, por exemplo, em relação à guerra nuclear, parecem gozar de apoio moral entre a maioria dos desenvolvedores de software livre, [54]geralmente acredita-se que tais agendas não devem ser atendidas por meio de licenças de software; entre outras coisas devido a aspectos práticos, como incertezas jurídicas resultantes e problemas com a aplicabilidade de critérios vagos, amplos e/ou subjetivos ou porque os fabricantes de ferramentas geralmente não são responsabilizados pelo uso de suas ferramentas por outras pessoas. No entanto, alguns projetos incluem apelos legalmente não vinculativos ao usuário, com destaque para o SQLite . [55] Entre as repetidas tentativas [56] [57] [58] dos desenvolvedores de regular o comportamento do usuário através da licença que provocaram um debate mais amplo estão a cláusula "no evil" de Douglas Crockford (brincando), que afetou o processo de lançamento do Distribuição Debian em 2012 [59]e conseguiu que o projeto JSMin-PHP fosse expulso do Google Code , [60] a adição de uma condição pacifista baseada na Primeira Lei da Robótica de Asimov à GPL para o software de computação distribuída GPU em 2005, [61] bem como vários projetos de software tentando para excluir o uso por grandes provedores de nuvem. [62] [63]

Conflitos de definição

Como existem várias organizações e grupos definidores que publicam definições e diretrizes sobre licenças FOSS, notadamente a FSF, o OSI, o projeto Debian e os BSDs, às vezes há opiniões e interpretações conflitantes.

Opiniões permissivas versus copyleft

Muitos usuários e desenvolvedores de sistemas operacionais baseados em BSD têm uma posição diferente sobre licenciamento. A principal diferença é a crença de que as licenças copyleft , particularmente a GNU General Public License (GPL), são indesejavelmente complicadas e/ou restritivas. [64] A GPL exige que qualquer trabalho derivado também seja lançado de acordo com a GPL, enquanto a licença BSD não. Essencialmente, o único requisito da licença BSD é reconhecer os autores originais e não impõe restrições sobre como o código-fonte pode ser usado.

Como resultado, o código BSD pode ser usado em software proprietário que reconhece apenas os autores. Por exemplo, o Microsoft Windows NT 3.1 e o macOS possuem pilhas de IP proprietárias derivadas de software licenciado pelo BSD. [65] Em casos extremos, as possibilidades de sub ou re-licenciamento com BSD ou outras licenças permissivas podem impedir o uso futuro no ecossistema de código aberto. Por exemplo, o repositório FileExchange do MathWorks oferece a licença BSD para contribuições de usuários, mas impede com termos de uso adicionais qualquer uso além de seu próprio software MATLAB proprietário , por exemplo, com o FOSS GNU OctaveProgramas. [66] [67] [68]

Os defensores da licença BSD argumentam que ela é mais livre do que a GPL porque concede o direito de fazer qualquer coisa com o código-fonte, desde que a atribuição seja preservada. A abordagem levou o código BSD a ser usado em software proprietário amplamente utilizado. Os defensores da GPL apontam que uma vez que o código se torna proprietário, os usuários são negados as liberdades que definem o software livre. [69] Como resultado, eles consideram a licença BSD menos livre do que a GPL, e essa liberdade é mais do que uma falta de restrição. Uma vez que a licença BSD restringe o direito dos desenvolvedores de ter mudanças retribuídas à comunidade, [ duvidoso ] nem ela nem a GPL são "livres" no sentido de "sem restrições".

Debian

O projeto Debian usa os critérios estabelecidos em suas Diretrizes de Software Livre Debian (DFSG). Os únicos casos notáveis ​​em que o Debian e a Free Software Foundation discordam são sobre a Licença Artística e a Licença de Documentação Livre GNU (GFDL). O Debian aceita a Licença Artística original como sendo uma licença de software livre, mas a FSF discorda. No entanto, isso tem muito pouco impacto, já que a Licença Artística é quase sempre usada em uma configuração de licença dupla , juntamente com a Licença Pública Geral GNU .

Casos limítrofes controversos

A grande maioria do software livre usa licenças de software livre indiscutíveis; no entanto, tem havido muitos debates sobre se certas outras licenças se qualificam ou não para a definição.

Exemplos de licenças que provocaram debate foram a série 1.x da Apple Public Source License , que foi aceita pela Open Source Initiative mas não pela Free Software Foundation ou Debian e a RealNetworks Public Source License , que foi aceita pela Open Source Initiative e Free Software Foundation, mas não pelo Debian .

Além disso, a FSF recomendou a GNU Free Documentation License , [70] que é incompatível com a GPL, [71] foi considerada "não-livre" pelo projeto Debian por volta de 2006, [72] Nathanael Nerode, [73] e Bruce Perens . [74] A FSF argumenta que a documentação é qualitativamente diferente do software e está sujeita a requisitos diferentes. O Debian aceitou, em uma resolução posterior, que a GNU FDL cumpriu com as Diretrizes de Software Livre Debian quando a controversa " seção invariante " é removida, mas considera que "ainda não está livre de problemas". [75]Não obstante, a maioria da documentação GNU inclui "seções invariáveis". Da mesma forma, a fundação FLOSS Manuais , organização dedicada à criação de manuais para software livre, decidiu em 2007 deixar de lado a GFDL em favor da GPL para seus textos, alegando a incompatibilidade entre as duas, dificuldades na implementação da GFDL e o fato de que o GFDL "não permite fácil duplicação e modificação", especialmente para documentação digital. [76]

SLUC é uma licença de software publicada na Espanha em dezembro de 2006 para permitir todos, exceto o uso militar. Os escritores da licença afirmam que é um software livre, mas a Free Software Foundation diz que não é livre porque infringe a chamada "liberdade zero" da GPL, ou seja, a liberdade de usar o software para qualquer finalidade. [77]

Participação de mercado

Embora historicamente a licença FOSS mais usada tenha sido a GPLv2, em 2015, de acordo com a Black Duck Software [37] , a licença MIT permissiva destronou a GPLv2 para o segundo lugar, enquanto a licença permissiva Apache segue em terceiro lugar. Um estudo de 2012, que utilizou dados disponíveis publicamente, criticou a Black Duck Software por não publicar sua metodologia utilizada na coleta de estatísticas. [78] Daniel German, professor do Departamento de Ciência da Computação da Universidade de Victoriano Canadá, apresentou uma palestra em 2013 sobre os desafios metodológicos para determinar quais são as licenças de software livre mais utilizadas e mostrou como não conseguiu replicar o resultado da Black Duck Software. [79]

Um estudo do GitHub em 2015 sobre seus dados estatísticos descobriu que a licença do MIT era a licença FOSS mais proeminente nessa plataforma. [38]

Em junho de 2016 uma análise dos pacotes do Projeto Fedora mostrou como licenças mais utilizadas a família GPL, seguida por MIT, BSD, a família LGP, Artistic (para pacotes Perl), LPPL (para pacotes texlive ) e ASL. A GNU GPLv2+ foi a licença mais popular [39]

Veja também

Notas

  1. ^ Wheeler, David A. (2015). "A luta pela liberdade" . Arquivado a partir do original em 4 de julho de 2017 . Recuperado em 17 de fevereiro de 2016 .
  2. Hancock, Terry (29 de agosto de 2008). "E se os direitos autorais não se aplicarem aos executáveis ​​binários?" . Revista Software Livre . Arquivado a partir do original em 25 de janeiro de 2016 . Recuperado em 25 de janeiro de 2016 .
  3. Apple Computer, Inc. v. Franklin Computer Corporation coloca o byte de volta na proteção de direitos autorais para programas de computador na Golden Gate University Law Review Volume 14, Issue 2, Article 3 by Jan L. Nussbaum (janeiro de 1984)
  4. ^ Lemley, Menell, Merges e Samuelson. Lei de Software e Internet , p. 34.
  5. ^ "Aviso de permissão de cópia do GNU Emacs (1985)" . Recuperado em 8 de novembro de 2015 .
  6. ^ "GPLv3 - Transcrição de Richard Stallman da terceira conferência internacional GPLv3, Barcelona; 2006-06-22 - FSFE" . Recuperado em 15 de julho de 2021 .
  7. Rubin, Paul (12 de dezembro de 1985). "Montgomery EMACS: quando saiu do Domínio Público?" . Grupo de notíciasnet.emacs . Este último é coberto pela GNU Emacs General Public License, que diz que as fontes de qualquer coisa que o use devem estar disponíveis gratuitamente para todos.
  8. ^ "Software Livre - Aplicação GPL" . Técnico Insider . Recuperado em 1 de maio de 2015 .
  9. ^ "Lançamentos GCC" . Recuperado em 19 de março de 2015 .
  10. ^ "GPLv3 - Transcrição de Richard Stallman da segunda conferência internacional GPLv3, Porto Alegre, Brasil; 2006-04-21" . Arquivado a partir do original em 15 de junho de 2010 . Recuperado em 19 de março de 2015 .
  11. ^ Mark (8 de maio de 2008). "A Maldição da Proliferação de Licenças de Código Aberto" . socializedsoftware. com. Arquivado a partir do original em 8 de dezembro de 2015 . Recuperado em 30 de novembro de 2015 . Licença Pública Geral GNU (GPL) 2.0 58,69% Licença Pública Geral Menor GNU (LGPL) 2,1 11,39% Licença Artística (Perl) 7,46% Licença BSD 6,50% Licença Apache 2.0 2,92% Licença MIT 2,58% Licença Pública Geral GNU (GPL) 3.0 1.64 % Licença Pública Mozilla (MPL) 1.1 1.37% Licença Pública Comum 0.83% Licença zlib/lippng 0.64%
  12. ^ David A. Wheeler. "Estimando o tamanho do Linux" .
  13. ^ "SourceForge.net: Mapa de Software" . Dwheeler . com . Recuperado em 17 de novembro de 2008 . Licença -> OSI: […] GNU General Public License (GPL) (32641 projetos), GNU Library ou Lesser General Public License (LGPL) (4889 projetos de 45727, 82,1%)
  14. ^ Kelty, Christpher M. (2008). "O Significado Cultural do Software Livre - Dois Bits" (PDF) . Imprensa da Universidade de Duke - Durham e Londres. pág. 99. Antes de 1998, Software Livre referia-se à Free Software Foundation (e ao olhar atento e microgerenciador de Stallman) ou a um dos milhares de diferentes projetos, processos, licenças e ideologias comerciais, não profissionais ou de pesquisa universitária que haviam uma variedade de nomes: sourceware, freeware, shareware, software aberto, software de domínio público e assim por diante. O termo Open Source, por outro lado, procurou abarcá-los todos em um movimento.
  15. ^ "Netscape anuncia planos para tornar o código-fonte do comunicador de próxima geração disponível gratuitamente na rede" . Corporação de Comunicações Netscape . 22 de janeiro de 1998. Arquivado a partir do original em 1 de abril de 2007 . Recuperado em 8 de agosto de 2013 . Movimento ousado para aproveitar o poder criativo de milhares de desenvolvedores de internet; empresa torna o Netscape Navigator e o Communicator 4.0 imediatamente gratuitos para todos os usuários, semeando mercado para empresas e negócios netcenter
  16. ^ "MOUNTAIN VIEW, Califórnia, 1º de abril /PRNewswire/ -- Netscape Communications e desenvolvedores de código aberto estão comemorando o primeiro aniversário, 31 de março de 1999, do lançamento do código-fonte do navegador da Netscape para mozilla.org" . Comunicações Netscape . 31 de março de 1999. Arquivado a partir do original em 26 de março de 2014 . Recuperado em 10 de janeiro de 2013 .... a organização que gerencia desenvolvedores de código aberto que trabalham na próxima geração do navegador e software de comunicação da Netscape. Este evento marcou um marco histórico para a Internet, pois a Netscape se tornou a primeira grande empresa de software comercial a abrir seu código-fonte, uma tendência que vem sendo seguida por várias outras corporações. Desde que o código foi publicado pela primeira vez na Internet, milhares de indivíduos e organizações o baixaram e fizeram centenas de contribuições para o software. Mozilla.org está comemorando agora este aniversário de um ano com uma festa na noite de quinta-feira em San Francisco.
  17. ^ Kelty, Christpher M. (2008). "O Significado Cultural do Software Livre - Dois Bits" (PDF) . Imprensa da Universidade de Duke - Durham e Londres. pág. 100. O termo Open Source, por outro lado, procurou abarcá-los todos em um movimento. O evento que precipitou essa tentativa de golpe de estado semântico foi o lançamento do código-fonte do navegador da Web Communicator da Netscape. É difícil superestimar a importância da Netscape para o destino do Software Livre. […] Mas a Netscape é muito mais famosa entre os geeks por dar outra coisa, em 1998: o código-fonte do Netscape Communicator (nascido Navigator).
  18. ^ "Relatório do Comitê de Proliferação de Licenças e esboço de FAQ" . Iniciativa de código aberto . 12 de dezembro de 2007.
  19. ^ "Groklaw - A Ordem GPL alemã - Traduzido" . Recuperado em 19 de março de 2015 .
  20. ^ Veja Progress Software Corporation v. MySQL AB , 195 F. Supp. 2d 328 (D. Mass. 2002), sobre o pedido de liminar do réu.
  21. ^ Lawrence Rosen (25 de maio de 2004). "Por que o domínio público não é uma licença" . rosenlaw . com . Recuperado em 22 de fevereiro de 2016 .
  22. ^ Bernstein, Daniel J. (2004). "Colocar documentos em domínio público" . A maioria dos direitos pode ser voluntariamente abandonada ("renunciada") pelo proprietário dos direitos. Os legisladores podem fazer um esforço extra para criar direitos que não podem ser abandonados, mas geralmente não fazem isso. Em particular, você pode abandonar voluntariamente seus direitos autorais nos Estados Unidos: "É bem estabelecido que os direitos adquiridos sob a Lei de Direitos Autorais podem ser abandonados. Mas o abandono de um direito deve ser manifestado por algum ato explícito indicando a intenção de abandonar esse direito. v. Paramount Pictures Corp., 279 F.2d 100, 104 (9º Cir. 1960)."
  23. ^ Lawrence Rosen (8 de março de 2012). "(Revisão de licença) (Discussão de licença) CC0 incompatível com OSD em patentes, (era: MXM comparado a CC0)" . opensource.org. Arquivado a partir do original em 12 de março de 2016 . Recuperado em 22 de fevereiro de 2016 .O caso que você mencionou em seu e-mail, Hampton v. Paramount Pictures, 279 F.2d 100 (9º Cir. Cal. 1960), representa a proposição de que, pelo menos no Nono Circuito, uma pessoa pode de fato abandonar seus direitos autorais (contra ao que escrevi em meu artigo) -- mas é preciso o equivalente a uma licença manifesta para fazê-lo. :-) ... Para o registro, eu já votei +1 para aprovar a dedicação de domínio público CC0 e a licença de fallback como compatível com OSD. Admito que tenho argumentado há anos contra o "domínio público" como uma licença de código aberto, mas em retrospecto, considerando o risco mínimo para desenvolvedores e usuários que confiam em tal software e a evidente popularidade dessa "licença", mudei de ideia . Não se pode ficar no caminho de uma mangueira de incêndio de software livre de domínio público, mesmo que não
  24. ^ Mark (8 de maio de 2008). "A Maldição da Proliferação de Licenças de Código Aberto" . socializedsoftware. com. Arquivado a partir do original em 8 de dezembro de 2015 . Recuperado em 30 de novembro de 2015 . Atualmente, a decisão de passar da GPL v2 para a GPL v3 está sendo muito debatida por muitos projetos de código aberto. De acordo com a Palamida, fornecedora de software de conformidade de IP, houve aproximadamente 2.489 projetos de código aberto que passaram da GPLv2 para versões posteriores.
  25. ^ a b "Perguntas frequentes sobre as licenças GNU – A GPLv3 é compatível com a GPLv2?" . gnu.org . Recuperado em 3 de junho de 2014 . Não. Alguns dos requisitos da GPLv3, como o requisito de fornecer informações de instalação, não existem na GPLv2. Como resultado, as licenças não são compatíveis: se você tentasse combinar o código lançado sob ambas as licenças, estaria violando a seção 6 da GPLv2. No entanto, se o código for lançado sob a GPL 'versão 2 ou posterior', isso é compatível com a GPLv3 porque a GPLv3 é uma das opções que ela permite. 
  26. Kerner, Sean Michael (8 de janeiro de 2008). "Torvalds ainda interessado na GPLv2" . internetnews . com . Recuperado em 12 de fevereiro de 2015 . De certa forma, o Linux foi o projeto que realmente deixou clara a divisão entre o que a FSF está promovendo, que é muito diferente do que o código aberto e o Linux sempre foram, que é mais uma superioridade técnica do que uma -- essa crença religiosa em liberdade," Torvalds disse a Zemlin. Então, a versão 3 da GPL reflete os objetivos da FSF e a versão 2 da GPL se aproxima muito do que eu acho que uma licença deve fazer e agora, a versão 2 é onde o kernel está.   
  27. ^ a b Byfield, Bruce (22 de novembro de 2011). "7 razões pelas quais o software livre está perdendo influência: página 2" . Datamation . com . Recuperado em 23 de agosto de 2013 . Na época, a decisão parecia sensata diante de um impasse. Mas agora, a GPLv2 é usada por 42,5% do software livre e a GPLv3 por menos de 6,5%, de acordo com a Black Duck Software.
  28. ^ "MySQL altera licença para evitar GPLv3" . Revisão de negócios de computador on-line . 4 de janeiro de 2007. Arquivado a partir do original em 6 de fevereiro de 2007 . Recuperado em 21 de novembro de 2016 .
  29. ^ corbet (1 de outubro de 2006). "Ocupado ocupado ocupado" . lwn.net . Recuperado em 21 de novembro de 2015 . Como o BusyBox pode ser encontrado em tantos sistemas embarcados, ele se encontra no centro do debate anti-DRM da GPLv3. […] Os resultados reais, no entanto, são estes: BusyBox será GPLv2 apenas a partir do próximo lançamento. É geralmente aceito que remover a "ou qualquer versão posterior" é legalmente defensável e que a fusão de outro código somente GPLv2 forçará esse problema em qualquer caso.
  30. ^ Landley, Rob (9 de setembro de 2006). "Re: Mover GPLv2 vs v3 divertido..." lwn.net . Recuperado em 21 de novembro de 2015 . Não invente um argumento do espantalho, por favor. Considero o licenciamento do BusyBox sob a GPLv3 inútil, desnecessário, complicado e confuso, além de ter desvantagens reais. 1) Inútil: Nós nunca vamos abandonar a GPLv2.
  31. Prokoudine, Alexandre (26 de janeiro de 2012). "O que há com a adoção de DWG em software livre?" . libregraphicsworld.org. Arquivado a partir do original em 9 de novembro de 2016 . Recuperado em 5 de dezembro de 2015 . O Blender também ainda é 'GPLv2 ou posterior'. Por enquanto, mantemos isso, mudar para a GPL 3 não tem benefícios evidentes que eu conheça.
  32. ^ Denis-Courmont, Rémi. "VLC media player permanecerá sob GNU GPL versão 2" . videolan.org . Recuperado em 21 de novembro de 2015 . Em 2001, o VLC foi lançado sob a versão 2 do GNU General Public aprovada pela OSI, com a opção comumente oferecida de usar 'qualquer versão posterior' (embora não houvesse nenhuma versão posterior na época). Após o lançamento pela Free Software Foundation (FSF) da nova versão 3 de sua GNU General Public License (GPL) em 29 de junho de 2007, os contribuidores do VLC media player e outros projetos de software hospedados em videolan.org, debateram a possibilidade de atualizar os termos de licenciamento para versão futura do media player VLC e outros projetos hospedados, para versão    3º do GPL. ... Há uma forte preocupação de que esses novos requisitos adicionais possam não corresponder à realidade industrial e econômica do nosso tempo, especialmente no mercado de eletrônicos de consumo. Acreditamos que alterar nossos termos de licenciamento para a versão  3 da GPL atualmente não seria do melhor interesse de nossa comunidade como um todo. Consequentemente, planejamos continuar distribuindo versões futuras do VLC media player sob os termos da GPL versão  2.
  33. ^ Asay, Matt (23 de julho de 2009). "GPLv3 atinge 50% de adoção | The Open Road - CNET News" . News.cnet . com . Recuperado em 2 de setembro de 2013 .
  34. ^ Proffitt, Brian (16 de dezembro de 2011). "GPL, uso de copyleft em declínio mais rápido do que nunca" . ITworld .
  35. ^ Proffitt, Brian (16 de dezembro de 2011). "GPL, uso de copyleft declinando mais rápido do que nunca - Os dados sugerem uma taxa de declínio mais acentuada, o que levanta a questão: por quê?" . mundo de TI . Recuperado em 23 de agosto de 2013 .
  36. Aslett, Matthew (15 de dezembro de 2011). "Sobre o declínio contínuo da GPL" . Arquivado a partir do original em 9 de dezembro de 2016 . Recuperado em 17 de fevereiro de 2016 .
  37. ^ a b "Top 20 licenças" . Software Pato Preto. 19 de novembro de 2015. Arquivado a partir do original em 19 de julho de 2016 . Recuperado em 19 de novembro de 2015 . 1. Licença MIT 24%, 2. GNU General Public License (GPL) 2.0 23%, 3. Apache License 16%, 4. GNU General Public License (GPL) 3.0 9%, 5. BSD License 2.0 (3-cláusula, Nova ou revisada) Licença 6%, 6. GNU Lesser General Public License (LGPL) 2,1 5%, 7. Artistic License (Perl) 4%, 8. GNU Lesser General Public License (LGPL) 3,0 2%, 9. Microsoft Public Licença 2%, 10. Licença Pública Eclipse (EPL) 2%
  38. ^ a b Balter, Ben (9 de março de 2015). "Uso de licença de código aberto no GitHub.com" . github . com . Recuperado em 21 de novembro de 2015 . 1 MIT 44,69%, 2 Outros 15,68%, 3 GPLv2 12,96%, 4 Apache 11,19%, 5 GPLv3 8,88%, 6 BSD 3 cláusulas 4,53%, 7 Sem licença 1,87%, 8 BSD 2 cláusulas 1,70%, 9 LGPLv3 1,30% , 10 AGPLv3 1,05%
  39. ^ a b Anwesha Das (22 de junho de 2016). "Licenças de Software no Ecossistema Fedora" . anweshadas.in . Recuperado em 27 de junho de 2016 . A partir do gráfico acima fica claro que a família GPL é a mais usada (eu tinha calculado errado como MIT antes). ), ASL.
  40. ^ "Várias licenças e comentários sobre eles - GNU Project - Free Software Foundation" . Recuperado em 19 de março de 2015 .
  41. ^ "Por que você deve usar uma licença estilo BSD para seu projeto de código aberto" . Recuperado em 19 de março de 2015 .
  42. ^ "Por que você deve usar uma licença estilo BSD para seu projeto de código aberto" . Recuperado em 19 de março de 2015 .
  43. ^ "GPLv3 - Transcrição de Richard Stallman da quinta conferência internacional GPLv3, Tóquio, Japão; 2006-11-21" . Recuperado em 19 de março de 2015 .
  44. ^ "Richard Stallman discute mudanças na GPLv3" . um novo método de tentar privar os usuários da liberdade. Em termos gerais, nos referimos a isso como tivoização.
  45. ^ Wheeler, David A. (27 de setembro de 2007). "O Slide de Licença de Software Livre-Livre/Open Source (FLOSS)" .
  46. ^ "Como GPLv3 aborda a proliferação de licenças" . Arquivado a partir do original em 2 de maio de 2013.
  47. ^ LAURENT, Philippe (24 de setembro de 2008). "A GPLv3 e os problemas de compatibilidade" (PDF) . Evento Europeu de Advogados Open Source 2008 . Universidade de Namur – Bélgica. pág. 7. Arquivado a partir do original (PDF) em 4 de março de 2016 . Recuperado em 30 de maio de 2015 . Copyleft é a principal fonte de problemas de compatibilidade.
  48. ^ Fundação Apache (30 de maio de 2015). "Compatibilidade GPL" . Recuperado em 30 de maio de 2015 . O software Apache 2 pode, portanto, ser incluído em projetos GPLv3, porque a licença GPLv3 aceita nosso software em trabalhos GPLv3. No entanto, o software GPLv3 não pode ser incluído em projetos Apache. As licenças são incompatíveis apenas em uma direção, e é resultado da filosofia de licenciamento da ASF e da interpretação dos autores da GPLv3 da lei de direitos autorais.
  49. Hanwell, Marcus D. (28 de janeiro de 2014). "Devo usar uma licença permissiva? Copyleft? Ou algo no meio?" . opensource . com . Recuperado em 30 de maio de 2015 . O licenciamento permissivo simplifica as coisas Uma razão pela qual o mundo dos negócios e cada vez mais desenvolvedores […] preferem licenças permissivas está na simplicidade da reutilização. A licença geralmente diz respeito apenas ao código-fonte que está licenciado e não tenta inferir quaisquer condições sobre qualquer outro componente, e por isso não há necessidade de definir o que constitui um trabalho derivado. Também nunca vi um gráfico de compatibilidade de licenças para licenças permissivas; parece que todos são compatíveis.
  50. ^ "Compatibilidade e interoperabilidade de licença" . Software de código aberto - Desenvolva, compartilhe e reutilize software de código aberto para administrações públicas . joinup.ec.europa.eu. Arquivado a partir do original em 17 de junho de 2015 . Recuperado em 30 de maio de 2015 . As licenças para distribuição de software livre ou de código aberto (FOSS) são divididas em duas famílias: permissivas e copyleft. Licenças permissivas (BSD, MIT, X11, Apache, Zope) são geralmente compatíveis e interoperáveis ​​com a maioria das outras licenças, tolerando mesclar, combinar ou melhorar o código coberto e redistribuí-lo sob muitas licenças (incluindo licenças não-livres ou 'proprietárias ').
  51. ^ Landley, Rob. "CELF 2013 Toybox talk" . landley.net . Recuperado em 21 de agosto de 2013 . A GPLv3 quebrou "a" GPL em forks incompatíveis que não podem compartilhar código.
  52. ^ "Os problemas do HESSLA - Projeto GNU - Fundação de Software Livre" . Recuperado em 19 de março de 2015 .
  53. ^ "GPLv3 - Transcrição de Richard Stallman da terceira conferência internacional GPLv3, Barcelona; 2006-06-22" . Recuperado em 19 de março de 2015 .
  54. ^ "Inveja da censura e licenciamento - Free Software Foundation - Trabalhando juntos pelo software livre" .
  55. ^ "Recursos distintos do SQLite" .
  56. ^ "Uma licença pacífica de código aberto | Wise Earth Technology" .
  57. ^ "Apenas para uso não militar" .
  58. ^ "❌(REVERTED): Adicionar texto à licença do MIT banindo colaboradores do ICE por jamiebuilds · Pull Request #1616 · lerna/Lerna" .
  59. ^ "Mal, ou porque Douglas Crockford é prejudicial ao Software Livre" . 8 de novembro de 2012.
  60. ^ https://wonko.com/post/jsmin-isnt-welcome-on-google-code
  61. ^ https://www.linux.com/news/open-source-project-adds-no-military-use-clause-gpl/
  62. ^ https://commonsclause.com/
  63. ^ https://opensource.org/node/1099
  64. ^ "Política de direitos autorais do OpenBSD" . a restrição de que o código fonte deve ser distribuído ou disponibilizado para todos os trabalhos que são derivados […] Como consequência, softwares vinculados aos termos GPL não podem ser incluídos no kernel ou "runtime" do OpenBSD
  65. ^ "FreeBSD der unbekannte Riese" (em alemão).
  66. ^ "termos de uso" . O conteúdo que você enviar não deve competir diretamente com os produtos oferecidos pela MathWorks. O conteúdo enviado ao File Exchange só pode ser usado com produtos MathWorks.
  67. ^ "Perguntas frequentes sobre a transição de licenciamento para troca de arquivos" .
  68. ^ "Por que não posso usar o código do File Exchange in Octave? É lançado sob uma licença BSD!" .
  69. ^ "Liberdade ou Poder? por Bradley Kuhn e Richard Stallman" .
  70. ^ "Perguntas frequentes sobre as licenças GNU: Por que você não usa a GPL para manuais?" . Recuperado em 20 de junho de 2009 .
  71. ^ Braakman, Ricardo. "Re: Declaração proposta wrt GNU FDL" . Debian-legal (Lista de discussão).
  72. ^ Srivastava, Manoj (2006). "Declaração de Posição do Debian sobre a Licença de Documentação Livre GNU (nerGFDL)" . Recuperado em 25 de setembro de 2007 .Não é possível emprestar texto de um manual GFDL e incorporá-lo em qualquer programa de software livre. Esta não é uma mera incompatibilidade de licença. Não é apenas que a GFDL é incompatível com esta ou aquela licença de software livre: é que ela é fundamentalmente incompatível com qualquer licença de software livre. Portanto, se você escreve um novo programa e não tem nenhum compromisso sobre qual licença deseja usar, exceto que é uma licença gratuita, não pode incluir texto GFDL. O GNU FDL, como está hoje, não atende às Diretrizes de Software Livre Debian. Existem problemas significativos com a licença, conforme detalhado acima; e, como tal, não podemos aceitar obras licenciadas sob a GNU FDL em nossa distribuição.
  73. Nerode, Natanael (24 de setembro de 2003). "Por que você não deve usar o GNU FDL" . Arquivado a partir do original em 9 de outubro de 2003 . Recuperado em 7 de novembro de 2011 .
  74. ^ Bruce Perens (2 de setembro de 2003). "intervindo entre o Debian e o FSF" . list.debian.org/debian-legal . Recuperado em 20 de março de 2016 . A FSF, uma organização de Software Livre, não está sendo inteiramente fiel ao ethos do Software Livre enquanto está promovendo uma licença que permite que seções invariáveis ​​sejam aplicadas a qualquer coisa, menos ao texto e atribuição da licença. FSF não é Creative Commons: a documentação que a FSF manuseia é um componente essencial do Software Livre da FSF, e deve ser tratada como tal. A essa luz, o GFDL não é consistente com o ethos que a FSF promove há 19 anos.
  75. ^ "Resolução: Por que a GNU Free Documentation License não é adequada para o Debian" . Projeto Debian . Fevereiro-Março de 2006 . Recuperado em 20 de junho de 2009 .
  76. ^ Fundação dos manuais do FLOSS (6 de junho de 2007). "Alteração de Licença" . Blog de Manuais FLOSS . Fundação de Manuais FLOSS. Arquivado a partir do original em 28 de fevereiro de 2008 . Recuperado em 20 de junho de 2009 .
  77. ^ "Transcrição de Richard Stallman na 3ª conferência internacional GPLv3" . Fundação de Software Livre Europa. 22 de junho de 2006 . Recuperado em 23 de julho de 2017 .
  78. ^ Sam Varghese (7 de fevereiro de 2012). "Uso de GPL no Debian em ascensão: estudo" . Itwire . com . Recuperado em 2 de setembro de 2013 .
  79. ^ "Pesquisando licenças de código aberto" . Lwn.net . Recuperado em 2 de setembro de 2013 .

Referências

Links externos