| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | Mas que pergunta mais anormal é esta?
O objectivo da GPL é proteger quem desenvolve código aberto, não é para quem desenvolve código fechado.
Se tu queres desenvolver algo em código fechado não faz sentido usares GPL.
Se queres desenvolver algo em código aberto e não desejas que se aproveitem desse código não te dando crédito, fechando as modificações etc etc ai usas GPL.
Gustavo Felisberto
(HumpBack)
Web: http://dev.gentoo.org/~humpback |
| | | | | | A pergunta é interessante, so é preciso compreende-la.
O que o Anónimo pergunta é se a situação que ele descreve não permitirá a alguém criar um programa proprietário que se aproveite de componentes GPL "disfarçando-as" de plugins.
Fala-se bastante da situação dos plugins proprietários em programas GPL, mas a situação inversa é mais complicada.
O cerne do problema é que um terceiro não pode condicionar a licença do autor do programa. Assim, se eu escrever um programa proprietário com uma API para plugins, não é o facto de alguém escrever um plugin GPL que vai afectar o meu copyright. A questão é se isto pode servir de base a uma estratégia para contornar a GPL
|
| | | | A "viralidade" é um efeito colateral do GPL e não a razão da sua existência. Claro que podes fazer isso mas o programa GPL vai continuar a ser GPL em vez de ser "roubado" e integrado sem qualquer referência no produto principal.
Mindstorm |
| | | | | | Logo não vai poder levar alteração que sejam fechadas depois ;)
GPL wins!!!
"The greatest obstacle to discovery is not ignorance -- it is the illusion of knowledge."
Daniel J. Boorstin |
| | | | Se eu desenvolver um programa proprietário que tenha um sistema de plugins e depois desenvolver um plugin que faça a comunicação entre o programa proprietário e o código GPL necessito de libertar o código do plugin como GPL. Isto de sistema de plugins tem muito que se lhe diga. O que é isso, para ti, de uma forma mais clara? O que entendo por plugins é um pedaço de código que funciona na aplicação por carregamento dinâmico de estruturas de dados e funcionalidade dentro do endereçamento computacional da aplicação, por isso vamos por partes:
1. criar um plugin que inclui código licenciado sob a GPL
Nada mais claro: o plugin tem de ser libertado segundo a GPL.
2. O programa "pai" carrega o plugin
O cerne da dúvida está realmente aqui. Mas as respostas depende de demasiados factores para os quais uma descrição genérica sem análise concreta da forma como seria feito não permite uma resposta simples.
Podes ainda por cima cair no domínio dos direitos morais que os autores têm em algumas leis como a nossa, onde provavelmente se poderá argumentar que a obra está a ter um uso indevido que a desvirtua, ou até mesmo que goza de má fé.
Sendo assim, para que serve afinal a GPL? Sabendo que é fácil criar um sistema deste género Esta questão do "é fácil" cheira-me a muita parra e pouca uva. Se fosse meramente um caso de chamar programa, plugins, etc e tudo funcionava por magia seria fácil, mas a realidade é bastante diferente, e para conseguir utilizar o código importado pelo plugin de forma a ter objectivos que compensem o não publicar como GPL o codigo da aplicação pai vai existir uma carga de trabalho que provavelmente seria mais compensatório escrever um programa de raíz que implemente a mesma funcionalidade.
De qualquer das formas, não passa de mais uma tentativa de ser mais espertalhão que os outros. plugins não é uma "teoria" do ano passado, se fosse assim tão fácil fazer o que tentas dizer teríamos casos a pontapé :)
|
| | | | | | "Isto de sistema de plugins tem muito que se lhe diga. O que é isso, para ti, de uma forma mais clara? O que entendo por plugins é um pedaço de código que funciona na aplicação por carregamento dinâmico de estruturas de dados e funcionalidade dentro do endereçamento computacional da aplicação..." Segundo o teu ponto de vista, um sistema operativo pode ser interpretado como um sistema de plugins? A parte clara é que permite carregar código (aplicações). A parte menos clara é a do "endereço da aplicação". Os SOs actuais tendem a correr as aplicações em espaço de endereçamento unico, o que é equivalente a esconder os plugins uns dos outros. No entanto o endereçamento das aplicações é visivel para o SO. E portanto, as aplicações(plugins) são carregadas no espaço de endereçamento do SO (sistema de plugins).
Tendo em conta que, por exemplo, software GPL corre em windows, temos plugins GPL a correr num sistema de plugins não GPL.
|
| | | | Tendo em conta que, por exemplo, software GPL corre em windows, temos plugins GPL a correr num sistema de plugins não GPL.
O software GPL que estás a dizer que corre em Windows usa bibliotecas compatíveis com GPL, não usa directamente o Win32 que não me parece ser compatível com GPL.
Religion, the only confort left in a world splited by religion. (The Daily Show) |
| | | | Segundo o teu ponto de vista, um sistema operativo pode ser interpretado como um sistema de plugins? A parte clara é que permite carregar código (aplicações). Acho que tens de aprender a distinguir as coisas. Num sistema operativo em condições as aplicações não correm no espaço do núcleo.
Este tipo de abstrações fazem-me sempre lembrar a seguinte situação:
Professor: Após ter desenhado um quadrado representado por 9 pontos:
. . .
. . .
. . .
Agora quero que com um traço só percorram os 9 pontos.
Aluno: É fácil. Basta uma linha grossa o suficiente.
Claro que se arranja sempre alguma abstração para atingir determinada conclusão, mas se ela se aplica ao que realmente se pretendia... isso já é outra história...
|
| | | | Entretanto lembrei-me melhor da situação:
Professor: Após ter desenhado um quadrado representado por 9 pontos:
. . .
. . .
. . .
Agora quero que me digam o número mínimo de traços para percorrer os 9 pontos sem repetir.
Aluno: É fácil. Basta um! Com linha grossa o suficiente.
|
| | | | Se os plugins comunicarem com o programa principal por sockets/pipes, não há restrições nenhumas.
Se os plugins forem bibliotecas dinâmicas, então:
1. Se o programa principal for GPL, os plugins tb têm de ser, e vice versa;
2. Se o programa principal fo LGPL, os plugins podem ser proprietários, e vice versa;
Disclaimer: IANAL.
|
| | | | | O objectivo da GNU GPL é o de proteger código GNU GPL ou derivado de se tornar código fechado (ou mais concretamente, de impedir que se torne qq outra coisa que não GNU GPL). O teu exemplo não poê esse objectivo em causa.
|
| | | | | | O objectivo da GNU GPL é garantir as 4 liberdades para todos os utilizadores. Consegue fazê-lo utilizando o Direito de Autor para impedir que derivados possam não dar aos utilizadores as 4 liberdades.
Não mistures o objectivo com a forma de o alcaçar, até porque o software não é protegido por licença alguma, quem é protegido é o detentor dos direitos de exclusividade, concedidos por lei normalmente ao autor!
|
| | | | | Não é uma utopia semântica. O significado é completamente diferente, e leva a interpretações igualmente absurdas.
|
| | | | | Exacto, são tão absurdas umas como outras. ;> Exactamente por isso não interpretei nada, limitei-me a a relatar a situação da maneira mais 'agnóstica' e factual que me é possível (e recuso-me a entrar em guerras semânticas, não sabes mais de português que eu de certeza), e mesmo assim fui 'flamed'. :)
|
| | | | O problema é que a parte da factualidade falhou completamente. Não é uma questão semântica, nem foste flamed.
|
| | | | Não falhou absolutamente nada pq eu não interpretei, relatei.
|
| | | | Ai relataste? Então pergunto-me de onde, dado que nem sequer leste o preâmbulo! :)
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. A diferença não é semântica. O objectivo da GPL é garantir que todos os utilizadores têm as 4 liberdades, não é que o software e derivados sejam GPL. Confundes o objectivo com o método.
|
| | | | | Não percebes ou não queres perceber? Relatei o que acontece na prática, não interpretei o enunciado de intenções. Por outro lado já disse que não vou entrar em guerras demânticas sobre o significado da palavra 'objectivo'.
|
| | | | Confundiste o meio com o objectivo. E sim, interpretaste a intenção dado que foste tu quem disse (e erróneamente) qual o objectivo.
|
| | | | | E lá continuas tu armado em marreta... E agora a trocares-te todo. Continuas com uma palas nos olhos a discutir a semântica da palavra objectivo,a qual agora decidiste acrescentar a semântica da palavra intenção. Não vou discutir semânticas como já o disse várias vezes apesar das tuas desadequadas insistências. Até pq percebo que o que te chocou foi eu não ter mencionado os ideais do Open Source, nem sequer os habituais juízos de valor (o que confunde as pessoas pq estão a espera que quando se fala de GNU GPL automaticamente se ponham de um lado ou de outro da barricada ideológica) mas é exactamente isso que é o mais importante na minha sintética descrição, o relato prático e crú daquilo que objectivamente é em efeito prático o GNU GPL.
|
| | | | Até pq percebo que o que te chocou foi eu não ter mencionado os ideais do Open Source, Não. Aliás não mencionar a liberdade foi uma das intenções dos ideais "Open Source". Não foi isso que me chocou, mas o continuares a confundir o objectivo com o método:
nem sequer os habituais juízos de valor (o que confunde as pessoas pq estão a espera que quando se fala de GNU GPL automaticamente se ponham de um lado ou de outro da barricada ideológica) mas é exactamente isso que é o mais importante na minha sintética descrição, o relato prático e crú daquilo que objectivamente é em efeito prático o GNU GPL. A GNU GPL é um meio de atingir um objectivo, objectivo este que está declarado no seu preâmbulo.
|
| | | | E pronto lá continuas tu na tua cruzada pela tua visão fundamentalista do significado prescritivo da palavra 'objectivo'.
|
| | | | Don't feed the troll.
Religion, the only confort left in a world splited by religion. (The Daily Show) |
| | | | | Não é. É simplesmente uma questão de lei. Começando pelo nome, o Código de Direito de Autor e Direitos Conexos, não se chama Código de Protecção de Obra, e não tem o objectivo de proteger a obra mas sim o autor. A protecção do autor segundo o direito de autor, é feita concedendo-lhe monopolios relativamente a vários aspectos relacinados com a distribuição, criação de obras derivadas, estudo da obra, direito de utilizar a obra, etc... O direito de autor está-se borrifando para a integridade da obra, mas preocupa-se sim com os direitos morais e materiais do autor. Se o objectivo fosse proteger a obra o direito de autor seria extremamente ineficaz como um mecânismo criador de um ambiente propicio ao incentivo à criação de obras, por parte dos autores (o objectivo primordial do direito de autor).
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | Se o sistema de plugins funcionar por carregamento de bibliotecas dinâmicas no espaço de endereçamento da aplicação, então não só o plugin terá de ser GPL, como a aplicação também terá de ser GPL.
No caso geral esta utilização não difere em nada do caso das bibliotecas dinâmicas GPL que obrigam o software que as usa a ser também GPL (e esta relação é transitiva, portanto também afecta o programa principal).
É claro que o autor do código GPL pode autorizar este tipo de utilização, usando a LGPL, que só "contamina" as modificações ou a utilização parcial de código, e não a "linkagem" (estática ou dinâmica).
O caso inverso (software GPL a usar plugins proprietários), é que é mais complicado. Aqui já existe mais margem para discussão, pois se houver uma API exclusiva para "plugins", a obrigação dos plugins serem GPL já é bastante duvidosa, pois ao criar uma API exclusivamente para este efeito, o autor está a distinguir claramente os "plugins" da "linkagem".
--
Carlos Rodrigues
|
| | | | Penso que a confusão vem da interpretação do âmbito de aplicação das restrições da GPL.
Que eu saiba, a GPL só restringe a distribuição de software com licença GPL em conjunto conjunto com software de licença não GPL ou alguma outra licença incompatível com a GPL.
Isto quer dizer que se desenvolveres um programa de código fechado que usa bibliotecas ou plug-in com licença GPL, desde que não distribuas tudo no mesmo pacote, não estás a violar a GPL.
Isso significa que podes distribuir um programa de código fechado e apenas dar instruções ao utilizador de como obter uma biblioteca GPL que o programa precise.
O mesmo se pode dizer por exemplo de sites que precisam de componentes GPL. Não precisas abrir o código do teu site, porque na verdade não estás a distribuir o seu código. Agora não podes vender o site em conjunto com componentes GPL que precisas.
|
| | | | | | Isto quer dizer que se desenvolveres um programa de código fechado que usa bibliotecas ou plug-in com licença GPL, desde que não distribuas tudo no mesmo pacote, não estás a violar a GPL.
Sim e não...
A GPL não refere a distribuição em conjunto com software sob outras licenças, mas sim a distribuição de software derivado de software licenciado sob a GPL. Portanto, se o software proprietário necessitar obrigatoriamente da porção de código GPL (e esta só puder ser usada por "linkagem" e não usando "pipes" ou afins), é um produto derivado de software GPL e terá de estar licenciado sob a GPL.
Se isto não fosse assim, uma biblioteca GPL incluida numa distribuição de Linux nunca poderia obrigar qualquer software que a usasse a ser também GPL. Isto é reforçado com o facto de que a LGPL foi criada exactamente para este fim: para que se pudessem desenvolver bibliotecas GPL, sem obrigar o software que as use a ser GPL, quer sejam distribuidas com este ou à parte (numa distribuição de Linux).
O caso dos plugins é diferente, e a distribuição em separado já funciona. Mas apenas se o "plugin" não for essencial para o funcionamento da aplicação, porque nesse caso seria uma biblioteca e não um "plugin" (a diferença entre um e outro não é mais que isto, já que tecnicamente - ao nível do linker - são a mesma coisa).
O que irrita muita gente é mesmo ser quase impossível escapar à "viralidade" da GPL recorrendo a artimanhas "semânticas".
--
Carlos Rodrigues
|
| | | | A GPL não refere a distribuição em conjunto com software sob outras licenças, mas sim a distribuição de software derivado de software licenciado sob a GPL. Portanto, se o software proprietário necessitar obrigatoriamente da porção de código GPL (e esta só puder ser usada por "linkagem" e não usando "pipes" ou afins), é um produto derivado de software GPL e terá de estar licenciado sob a GPL. A licença não diz isso. A licença diz que tens de usar a licença GPL se distribuires um programa derivado de outro GPL. A clausula que diz isso é a 2. b) da licença GPL 2.
2. b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
Como podes verificar a licença não diz que és obrigado a distribuir um programa que desenvolveste derivado de outro como licença GPL, nem sequer se modificares o programa GPL. Portanto, se não tens de distribuir, nem sequer faz sentido falar em licenças porque as licenças servem apenas para esclarecer os que usam o teu software. Como apenas tu usas o software derivado, não tens de licenciar para ninguém.
Se isto não fosse assim, uma biblioteca GPL incluida numa distribuição de Linux nunca poderia obrigar qualquer software que a usasse a ser também GPL. Isto é reforçado com o facto de que a LGPL foi criada exactamente para este fim: para que se pudessem desenvolver bibliotecas GPL, sem obrigar o software que as use a ser GPL, quer sejam distribuidas com este ou à parte (numa distribuição de Linux).
O caso dos plugins é diferente, e a distribuição em separado já funciona. Mas apenas se o "plugin" não for essencial para o funcionamento da aplicação, porque nesse caso seria uma biblioteca e não um "plugin" (a diferença entre um e outro não é mais que isto, já que tecnicamente - ao nível do linker - são a mesma coisa).
|
| | | | A GPL não refere a distribuição em conjunto com software sob outras licenças, mas sim a distribuição de software derivado de software licenciado sob a GPL. Portanto, se o software proprietário necessitar obrigatoriamente da porção de código GPL (e esta só puder ser usada por "linkagem" e não usando "pipes" ou afins), é um produto derivado de software GPL e terá de estar licenciado sob a GPL. A licença não diz isso. A licença diz que tens de usar a licença GPL se distribuires um programa derivado de outro GPL. A clausula que diz isso é a 2. b) da licença GPL 2.
2. b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
Como podes verificar a licença não diz que és obrigado a distribuir um programa que desenvolveste derivado de outro como licença GPL, nem sequer se modificares o programa GPL. Portanto, se não tens de distribuir, nem sequer faz sentido falar em licenças porque as licenças servem apenas para esclarecer os que usam o teu software. Como apenas tu usas o software derivado, não tens de licenciar para ninguém.
Se isto não fosse assim, uma biblioteca GPL incluida numa distribuição de Linux nunca poderia obrigar qualquer software que a usasse a ser também GPL. Isto é reforçado com o facto de que a LGPL foi criada exactamente para este fim: para que se pudessem desenvolver bibliotecas GPL, sem obrigar o software que as use a ser GPL, quer sejam distribuidas com este ou à parte (numa distribuição de Linux).
O caso dos plugins é diferente, e a distribuição em separado já funciona. Mas apenas se o "plugin" não for essencial para o funcionamento da aplicação, porque nesse caso seria uma biblioteca e não um "plugin" (a diferença entre um e outro não é mais que isto, já que tecnicamente - ao nível do linker - são a mesma coisa). A licença não fala em plugins, mas sim em software derivado. Pela definição da licença, um módulo do Linux é software derivado.
No entanto, para fugir às restrições da GPL, por exemplo os drivers das placas NVIDIA são distribuidos como pacotes virtuais que quando são instalados em várias distribuições, são carregados do site da empresa e instalados na máquina do utilizador.
Assim nem a empresa que distribui o Linux viola a GPL porque não distribui os drivers ela mesma, nem o utilizador viola a GPL porque usa o Linux com esses drivers, mas não os redistribui em conjunto.
Esta prática é muito comum e é aprovada pela secção 2 da licença GPL onde diz:
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
|
| | | | Como podes verificar a licença não diz que és obrigado a distribuir um programa que desenvolveste derivado de outro como licença GPL, nem sequer se modificares o programa GPL. Portanto, se não tens de distribuir, nem sequer faz sentido falar em licenças porque as licenças servem apenas para esclarecer os que usam o teu software. Como apenas tu usas o software derivado, não tens de licenciar para ninguém.
Estás a confundir as coisas. É claro que não és obrigado a distribuir, e se não distribuires não és obrigado a licenciar sob a GPL, mas em lado nenhum eu falei disto. Estamos apenas a falar de distribuição (em conjunto ou não com código GPL do qual a aplicação depende).
A licença não fala em plugins, mas sim em software derivado. Pela definição da licença, um módulo do Linux é software derivado.
No entanto, para fugir às restrições da GPL, por exemplo os drivers das placas NVIDIA são distribuidos como pacotes virtuais que quando são instalados em várias distribuições, são carregados do site da empresa e instalados na máquina do utilizador.
Assim nem a empresa que distribui o Linux viola a GPL porque não distribui os drivers ela mesma, nem o utilizador viola a GPL porque usa o Linux com esses drivers, mas não os redistribui em conjunto.
O problema é que segundo a GPL, um módulo de Linux é software derivado (especialmente porque não são plugins, um módulo pode usar uma imensidão de estruturas internas do kernel). E, segundo a GPL, a nvidia seria obrigada a distribuir os seus drivers sob a GPL (ou não os distribuir, pura e simplesmente).
A diferença que existe no Linux (kernel) deve-se à existência de "regras" que estabelecem a interpretação dada pelo Linus ao que é um trabalho derivado no contexto dos loadable modules.
Este assunto já foi debatido na LKML, e as regras gerais são mais ou menos estas:
- se o código foi desenvolvido especificamente para Linux, então tem de ser GPL;
- se foi desenvolvido noutro lado, não tem de ser (o caso dos drivers da nvidia, cujo código foi desenvolvido inicialmente para Windows);
Em alguns casos isto entra em conflito directo com a GPL, mas a posição do Linus nesta matéria é que a licença do kernel é GPL+interpretações publicamente manifestadas.
Experimenta ler esta thread, julgo que basicamente resume tudo aquilo que estou a dizer.
--
Carlos Rodrigues
|
| | | | Como podes verificar a licença não diz que és obrigado a distribuir um programa que desenvolveste derivado de outro como licença GPL, nem sequer se modificares o programa GPL. Portanto, se não tens de distribuir, nem sequer faz sentido falar em licenças porque as licenças servem apenas para esclarecer os que usam o teu software. Como apenas tu usas o software derivado, não tens de licenciar para ninguém.
Estás a confundir as coisas. É claro que não és obrigado a distribuir, e se não distribuires não és obrigado a licenciar sob a GPL, mas em lado nenhum eu falei disto. Estamos apenas a falar de distribuição (em conjunto ou não com código GPL do qual a aplicação depende). Repara que tu é que disseste antes que: Portanto, se o software proprietário necessitar obrigatoriamente da porção de código GPL (e esta só puder ser usada por "linkagem" e não usando "pipes" ou afins), é um produto derivado de software GPL e terá de estar licenciado sob a GPL. Portanto não sou eu que estou a baralhar as coisas.
O que interessa é que se desenvolveres software derivado de outro GPL mas não o distribuires para outros, logo não tens de licenciar nem em GPL nem em nada, mesmo se modificares o código GPL original, porque não faz sentido.
Um exemplo, se desenvolveres um site que usa as bibliotecas cliente do MySQL 4 que vêem com licença GPL ou comercial, não és obrigado nem de abrir o código do site nem tens de comprar uma licença comercial, mesmo tendo em conta que o site é público, dado que o que publicas não é o código do site nem nenhuma forma compilada ou derivada desse código. Este é um equivoco comum.
A licença não fala em plugins, mas sim em software derivado. Pela definição da licença, um módulo do Linux é software derivado.
No entanto, para fugir às restrições da GPL, por exemplo os drivers das placas NVIDIA são distribuidos como pacotes virtuais que quando são instalados em várias distribuições, são carregados do site da empresa e instalados na máquina do utilizador.
Assim nem a empresa que distribui o Linux viola a GPL porque não distribui os drivers ela mesma, nem o utilizador viola a GPL porque usa o Linux com esses drivers, mas não os redistribui em conjunto.
O problema é que segundo a GPL, um módulo de Linux é software derivado (especialmente porque não são plugins, um módulo pode usar uma imensidão de estruturas internas do kernel). E, segundo a GPL, a nvidia seria obrigada a distribuir os seus drivers sob a GPL (ou não os distribuir, pura e simplesmente).
Não sei o que pretendias dizer a mais uma vez que só confirmaste o que eu disse antes.
|
| | | | Portanto não sou eu que estou a baralhar as coisas.
Não metas palavras na minha boca, eu estava a falar no contexto da distribuição (como é óbvio se leres o resto do post onde isso está escrito).
Não sei o que pretendias dizer a mais uma vez que só confirmaste o que eu disse antes.
Se tivesses lido a thread que indiquei já saberias. Posto em miúdos, a GPL utilizada no kernel obriga os drivers da nvidia a serem GPL (seguindo exactamente aquilo que eu disse até aqui). Tal não acontece porque foram definidas regras específicas do kernel que indicam as situações em que se autoriza a violação do exposto na GPL.
--
Carlos Rodrigues
|
| | | | Não sei o que pretendias dizer a mais uma vez que só confirmaste o que eu disse antes.
Se tivesses lido a thread que indiquei já saberias. Posto em miúdos, a GPL utilizada no kernel obriga os drivers da nvidia a serem GPL (seguindo exactamente aquilo que eu disse até aqui). Tal não acontece porque foram definidas regras específicas do kernel que indicam as situações em que se autoriza a violação do exposto na GPL. Hrmm... como podes ler a licença do driver de NVIDIA para Linux não é GPL, nem sequer algo compatível. Apenas as partes que invocam o kernel do Linux são GPL e por isso são distribuidas com source no mesmo arquivo de instalação pela própria NVIDIA.
|
| | | | Não sejas teimoso, o CrLf já te disse sobre a excepção à GPL para módulos. Se não acreditas, vê as seguintes páginas que encontrei numa simples pesquisa Google e que parecem interessantes:
- Linux: The GPL And Binary Modules
- Are non-GPL loadable Linux drivers really not a problem?
Já agora, a ATI e muitas outras companhias também disponibilizam drivers fechados para Linux. A nvidia não é nenhuma excepção.
Religion, the only confort left in a world splited by religion. (The Daily Show) |
| | | | Não sejas teimoso, o CrLf já te disse sobre a excepção à GPL para módulos. Se não acreditas, vê as seguintes páginas que encontrei numa simples pesquisa Google e que parecem interessantes:
- Linux: The GPL And Binary Modules
- Are non-GPL loadable Linux drivers really not a problem? Tu também estás a meter água. Se tivesses lido as páginas que indicaste poderias ter lido o que o próprio Linus escreveu que não existem excepções à GPL para módulos do Linux:
> I have heard many people reference the fact that the although the Linux
> Kernel is under the GNU GPL license, that the code is licensed with an
> exception clause that says binary loadable modules do not have to be
> under the GPL.
Nope. No such exception exists. E continua explicando o que é ou não é considerado software derivado do kernel no Linux. O driver da NVIDIA tem duas partes, uma GPL, que é derivada do kernel, e uma proprietária que é distribuida sem código fonte. Esta parte proprietária não é considerada trabalho derivado porque não invoca código GPL e por isso pode funcionar sem nada GPL.
Como já expliquei antes citando as partes relevantes da licença GPL, a parte proprietária do driver NVIDIA é considerada independente do kernel quando distribuida como trabalho separadamente (secção 2 da licença). De qualquer modo, já me estou a repetir, pelo que nada tenho a acrescentar.
|
| | | | Mas tu não leste o resto do que o Linus disse? Ele explica que é possível usar a interface ao sistema sem ser afectado pela GPL.
E quanto à licença da nvidia, não li essa parte. Deve estar em letras miúdinhas. :P
Religion, the only confort left in a world splited by religion. (The Daily Show) |
| | | | No entanto, para fugir às restrições da GPL, por exemplo os drivers das placas NVIDIA são distribuidos como pacotes virtuais que quando são instalados em várias distribuições, são carregados do site da empresa e instalados na máquina do utilizador.
Isso pura e simplesmente não é verdade. Para já, as distribuições são livres de redistribuir os drivers da nvidia juntamente com o seu pacote -- só não o fazem umas porque não querem ter software proprietário (ie. Debian), outras para dar mais valor aos seus pacotes comerciais (ie. Mandrake).
O Linus Torvalds fez uma excepção à licença GPL para módulos, de forma que é perfeitamente legal desenvolvê-los sob código fechado.
Por último, não é verdade que a nvidia distribuia pacotes "virtuais". Os pacotes disponibilizados na sua página são scripts que contém todo o código embutido. A razão pela qual eles pedem para aceder à página da nvidia é para verem se já há módulos compilados para a tua versão de kernel, de forma a evitar compilar a interface -- porque algumas distros não disponibilizam os headers do kernel, nem sequer o gcc.
Religion, the only confort left in a world splited by religion. (The Daily Show) |
| | | | Mais umas notas...
Isso significa que podes distribuir um programa de código fechado e apenas dar instruções ao utilizador de como obter uma biblioteca GPL que o programa precise.
Isto é exactamente aquilo que não se pode fazer. Se isto fosse possível, a GPL era irrelevante e nunca tinha atingido a notoriedade (e o estatuto polémico) que atingiu.
O mesmo se pode dizer por exemplo de sites que precisam de componentes GPL. Não precisas abrir o código do teu site, porque na verdade não estás a distribuir o seu código. Agora não podes vender o site em conjunto com componentes GPL que precisas.
É importante fazer aqui a distinção entre "software" e "código": podes sempre distribuir o código em separado das porções GPL porque o código é teu, mas os recipientes desse código não o poderão usar (compilar). Se o fizerem, poderão ser processados. E se for fácil para eles fazê-lo, também tu podes ser processado juntamente com eles.
Isto ocorre porque tu tens sempre todos os direitos sobre o código que escreves, podendo fazer com ele o que quiseres, inclusivé distribuir. Mas como este não está conforme a GPL, ao ser compilado o utilizador ficará obrigado a cumprir também a licença do código extra que vai usar, e como não pode alterar a licença do código que recebeu de ti (só tu o podes fazer), vai estar a violar a GPL.
--
Carlos Rodrigues
|
| | | | i beg to differ...
a GPL só "existe" quando distribuis o software. quando o compilas, não o estás a distribuir, logo o problema nunca pode ser aí.
quem distribui o código tem que o disponibilizar sobre GPL, uma vez que é uma obra derivada.
IMHO, IANAL.
-----
Windows isn't done until Lotus won't run. |
| | | | Isso significa que podes distribuir um programa de código fechado e apenas dar instruções ao utilizador de como obter uma biblioteca GPL que o programa precise.
Isto é exactamente aquilo que não se pode fazer. Se isto fosse possível, a GPL era irrelevante e nunca tinha atingido a notoriedade (e o estatuto polémico) que atingiu. Claro que podes fazer, basta ver o exemplo dos drivers NVIDIA que mencionei acima.
O mesmo se pode dizer por exemplo de sites que precisam de componentes GPL. Não precisas abrir o código do teu site, porque na verdade não estás a distribuir o seu código. Agora não podes vender o site em conjunto com componentes GPL que precisas.
É importante fazer aqui a distinção entre "software" e "código": podes sempre distribuir o código em separado das porções GPL porque o código é teu, mas os recipientes desse código não o poderão usar (compilar). Se o fizerem, poderão ser processados. E se for fácil para eles fazê-lo, também tu podes ser processado juntamente com eles. A GPL não proibe ninguém de compilar código. O que proibe é distribuir código compilado sem dar acesso a código fonte original se esse código for derivado de outro cujos direitos são de outras pessoas.
|
| | | | Claro que podes fazer, basta ver o exemplo dos drivers NVIDIA que mencionei acima.
Como eu digo acima, os drivers da nvidia seguem as regras gerais aplicadas ao Linux (kernel).
Mas se te referes à camada de código "cola" que está entre o kernel e o ".lib" binário, então apenas te digo que ambas as partes são da nvidia, logo o blob binário não tem de ser contaminado pela camada de adaptação, porque eles não querem que assim seja.
A GPL não proibe ninguém de compilar código. O que proibe é distribuir código compilado sem dar acesso a código fonte original se esse código for derivado de outro cujos direitos são de outras pessoas.
A GPL não proíbe, mas também não a podes violar. Portanto se compilar o código te colocar numa posição em que violas a GPL, não o poderás fazer.
--
Carlos Rodrigues
|
| | | | Claro que podes fazer, basta ver o exemplo dos drivers NVIDIA que mencionei acima.
Como eu digo acima, os drivers da nvidia seguem as regras gerais aplicadas ao Linux (kernel).
Mas se te referes à camada de código "cola" que está entre o kernel e o ".lib" binário, então apenas te digo que ambas as partes são da nvidia, logo o blob binário não tem de ser contaminado pela camada de adaptação, porque eles não querem que assim seja. Claro que não é contaminado porque é distribuido pelo seu dono e não por quem distribui o Linux.
Por isso é que não vem junto com as distribuições de Linux, mas estas vêem com pacotes virtuais que quando instalados trazem o driver do site da NVIDIA e estes são compilados pelo computador do utilizador.
Como o utilizador não vai redistribuir o código do driver depois de compilado na sua máquina, o utilizador não está a violar a GPL.
Este é o detalhe principal que venho a por em evidência desde o principio que a GPL não restringe o uso do código derivado se este não for redistribuido. Esta é uma solução para distribuir software derivado de GPL como drivers e plug-ins como a pessoa que iniciou este tópico queria saber.
|
| | | | Eu não vou dar mais murros na ponta desta faca, porque já entrei nesta discussão demasiadas vezes e vejo este filme em todas elas, portanto termino com isto:
Lê a FAQ sobre a GPL que a FSF tem online, especialmente a secção "Combining work with code released under the GPL".
Depois de o fazeres, vais constatar que tudo o que eu disse nesta discussão está lá escarapachado, incluindo a distribuição de bibliotecas GPL em separado do software proprietário que as usa (aqui a resposta é um simples "Yes", e não um "Yes, if it they are distributed bundled" ou qualquer coisa assim).
Se depois de leres a FAQ não vires como é falaciosa a tua posição, então não há mesmo nada a fazer.
--
Carlos Rodrigues
|
| | | | Mas isso em nada contradiz o que eu disse. O driver NVIDIA para Linux tem código dividido em duas partes. A de código aberto que invoca o kernel tem licença GPL e o resto é licença proprietária. Esta é que é a solução que é sugerida para problema original. De qualquer modo, já me estou a repetir, pelo que por mim nada tenho a acrescentar.
|
| | | | Só mais uma coisa, volta não volta aparecem estas discussões em que alguém se lembra de uma forma "óbvia" de contornar a GPL, que consiste normalmente numa de duas opções:
- criar uma camada de código GPL (B) entre o código proprietário (A) e o software GPL (C), esquecendo-se que C contamina B, logo B contamina A.
- distribuir o software proprietário em separado das "bibliotecas" GPL, esquecendo-se que isto não o impede de depender de código GPL e logo ser um derivado obrigado a cumprir a GPL.
Não é preciso mais que pensar um pouco para chegar à conclusão que a ideia "brilhante" na verdade já passou pela cabeça de muita gente que acabou por concluir que era falaciosa. É a velha "esperteza saloia" (sem ofensa).
Mais uma vez insisto nisto: pensem um bocado sobre este assunto de uma forma séria e concluirão que a ser verdadeira qualquer uma destas duas hipóteses, a GPL estaria completamente condenada e não teria qualquer efeito. Qualquer um poderia fazer thin wrappers e distribuir separadamente para fugir à GPL, era a anarquia, o cagar de porta aberta...
A GPL tem efeito, e causa polémica porque é muito difícil de contornar e não cede nestas ideias que invariavelmente passam pela cabeça das pessoas na primeira vez que leêm a licença.
--
Carlos Rodrigues
|
| | | | | a GPL estaria completamente condenada e não teria qualquer efeito Não me parece que a licença BSD, que no contexto da discussão actual é muito mais permissiva (não são precisos esquemas malucos para distribuir trabalhos e/ou trabalhos derivados com aplicações proprietárias) esteja, de alguma forma, debilitada ou esmorecida, como tentas fazer crer que a GPL estaria, se não fosse viral.
Why do you Linux and drive when you can BSD and fly? |
| | | | Mas a BSD permite que haja utilizadores sem as 4 liberdades mínimas. O objectivo da GPL é que todos os utilizadores as tenham.
|
| | | | Uma licença está condenada e não tem efeito quando os objectivos para os quais foi criada fracassam completamente. Ora o objectivo da licença BSD é mesmo ser permissiva, logo alcança o efeito desejado. Mas a GPL tem como objectivo evitar apropriação sem retorno à comunidade, e a "viralidade" é essencial para esse propósito. Se fosse trivial contorná-la, como algumas pessoas ingenuamente parecem acreditar, então teria fracassado completamente e ninguém andaria por aí a dizer como é um "cancro" e como é um "atentado" à propriedade intelectual...
--
Carlos Rodrigues
|
| | | | Referi mesmo agora isto num post mais enterrado, portanto podem moderar-me como redundante, mas acho que talvez seja importante referi-lo de novo no toplevel da discussão:
Estas dúvidas existênciais acerca das implicações da GPL, incluíndo no que respeita a plugins e módulos, têm resposta na FAQ da GPL, que eu aconselho a ler antes de formar opiniões (possivelmente erradas).
--
Carlos Rodrigues
|
| | | | | | Exactamente.
Já agora, as respostas que me parecem mais relevantes para esta questão:
Can I apply the GPL when writing a plug-in for a non-free program?
If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them. So you can use the GPL for a plug-in, and there are no special requirements.
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means that combination of the GPL-covered plug-in with the non-free main program would violate the GPL. However, you can resolve that legal problem by adding an exception to your plug-in's license, giving permission to link it with the non-free main program.
See also the question I am writing free software that uses a non-free library.
Can I release a non-free program that's designed to load a GPL-covered plug-in?
It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license of the plug-in makes no requirements about the main program.
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins.
If the program dynamically links plug-ins, but the communication between them is limited to invoking the `main' function of the plug-in with some options and waiting for it to return, that is a borderline case.
See also the question I am writing free software that uses a non-free library.
Religion, the only confort left in a world splited by religion. (The Daily Show) |
| |
|
