search

aricaldeira / PySPED

Sistema Público de Escrituração Digital em Python
GNU Lesser General Public License v2.1
108 stars 97 forks source link

Mudança de AGPL para LGPL #7

Closed alanjds closed 9 years ago

alanjds commented 11 years ago

Oi, Ari.

Fiquei algum tempo sem acompanhar os commits, e quando voltei notei que você colocou uma licença no projeto.

Nos commits vi que te influenciei a fazer isso, mas acho melhor trocar de licença.

A licença atual é a AGPL, mas eu sugiro que seja trocada para LGPL. Detalhes:

Basicamente, a LGPL é mais permissiva, a GPL é a padrão e a AGPL é a mais restrita das 3.

O problema da PySPED ficar AGPL, no meu ponto de vista, é que isso acaba com qualquer possibilidade de integrar um ERP com ele: qualquer pessoa que ACESSE a interface do sistema DEVE poder copiar o código do ERP inteiro!

Se ficar como GPL, isso não acontece, mas o sistema precisa ficar confinado a quem o desenvolveu, então uma filial não pode, por exemplo, compartilhar com outra, senão o mundo inteiro toma o "direito" de ter aquele sistema.

Eu sugiro trocar para LGPL porque permite integrar com ERP proprietário, mas mantém a obrigação de mandar de volta pra nós quaisquer alterações na PySPED.

O que você acha, @aricaldeira ?

rodrigopitanga commented 11 years ago

Oi, alanjds e demais.

GPL: A licença "padrão". Todo código "linkado" com GPL vira GPL, com efeito viral. Pode ser usado em projetos privados sem liberar código, mas se esses projetos forem distribuídos, digamos a um cliente ou parceiro, TODO o código precisa ser "doado" junto a qualquer interessado do mundo.

Na verdade isso não está correto. Todos os efeitos da GPL e da AGPL dizem respeito a quem recebe o binário (no caso da GPL) e quem tem interação com o software via rede (no caso da AGPL).

Ou seja, se você altera o código de um programa GPL ou faz um software que usa esse código e o envia a um parceiro, você deve apenas a esse parceiro a obrigação de repassar os mesmos direitos que você recebeu. É claro que é muito legal você contribuir para o mundo, mas não é uma obrigação. Você só tem obrigação de repassar os direitos que você recebeu de alguém a quem recebeu o código de você (seja "dado" ou através de uma transação comercial, como software por encomenda).

Esse é um equívoco de interpretação comum. Na dúvida, sugiro ler o texto da licença na íntegra ou ainda a FAQ no site da FSF:

https://www.gnu.org/licenses/gpl-faq.html

alanjds commented 11 years ago

Hum...

Mas, Rodrigo, e quanto à definição de "terceiros" em https://www.gnu.org/licenses/gpl-faq.html#TheGPLSaysModifiedVersions ??

O que eu entendo é que, se vc pega software GPL-AGPL-LGPL que eu contribuí, modifica, e manda para um cliente, eu (Alan) também sou "terceiros" nesse caso, então eu tenho direito ao software GPL-AGPL-LGPL que você mandou ao cliente. Agora, como GPL-AGPL "viraliza" o código linkado, eu tenho direito ao software do seu cliente (!!!) que linkar com o código GPL-AGPL descendente do que eu contribuí.

Tem que ter alguma falha na minha interpretação do conteúdo do link, se o que vc diz está certo. Pode me esclarecer?

jdahlin commented 11 years ago

Eu gostaria de integrar PySPED no aplicativo http://github.com/stoq/stoq que tem a licença (L)GPLv2. Para eu poder fazer isso precisa trocar licença para LGPLv2 ou mais liberal (MIT, Apache, MPL).

Também queria ajudar com:

Se não tem como mudar a licença, eu teria que criar uma outra biblioteca que é compatível com minha licença.

@aricaldeira tem como mudar licença?

alanjds commented 11 years ago

@aricaldeira , como a maioria do código atual é seu, e não é "trivial" mudar uma licença, gostaria da sua permissão pra mudar pra LGPL, mesmo já tendo condição "técnica" pra fazer isso.

Tenho permissão sua pra mudar pra LGPL ?

Alan Justino da Silva * Cel: +55 11 99822-5769

Em 23 de junho de 2013 13:39, Johan Dahlin notifications@github.comescreveu:

Eu gostaria de integrar PySPED no aplicativo http://github.com/stoq/stoqhttps://github.com/stoq/stoqque tem a licença (L)GPLv2. Para eu poder fazer isso precisa trocar licença para LGPLv2 ou mais liberal (MIT, Apache, MPL).

Também queria ajudar com:

  • suporte de certificados A3, assinar e acesso para webservices (já tem código separado funcionando)
  • remover dependência xmlsec (é simples fazer na mão)

Se não tem como mudar a licença, eu teria que criar uma outra biblioteca que é compatível com minha licença.

@aricaldeira https://github.com/aricaldeira tem como mudar licença?

— Reply to this email directly or view it on GitHubhttps://github.com/aricaldeira/PySPED/issues/7#issuecomment-19876760 .

aricaldeira commented 11 years ago

Era domingo, 23 de junho de 2013, 09:39, e Johan Dahlin me escreveu:

Eu gostaria de integrar PySPED no aplicativo http://github.com/stoq/stoq que tem a licença (L)GPLv2. Para eu poder fazer isso precisa trocar licença para LGPLv2 ou mais liberal (MIT, Apache, MPL).

Também queria ajudar com:

  • suporte de certificados A3, assinar e acesso para webservices (já tem código separado funcionando) * remover dependência xmlsec (é simples fazer na mão)

Se não tem como mudar a licença, eu teria que criar uma outra biblioteca que é compatível com minha licença.

@aricaldeira tem como mudar licença?

Johan,

Na verdade, eu não conheço quais são as diferenças, exatamente, entre as várias licenças.

Na época em que coloquei o licenciamento pela AGPL foi para deixar compatível com o projeto OpenERP, que está usando o PySPED para transmitir a NF-e.

A LGPL seria compatível com a AGPL também?

Atenciosamente,-- Aristides Caldeira Taŭga Tecnologia aristides.caldeira@tauga.com.br1 3411-0602

[1] mailto:aristides.caldeira@tauga.com.br

aricaldeira commented 11 years ago

Era seg, 24 de junho de 2013, 18:04, e Alan Justino da Silva me escreveu:

@aricaldeira , como a maioria do código atual é seu, e não é "trivial" mudar uma licença, gostaria da sua permissão pra mudar pra LGPL, mesmo já tendo condição "técnica" pra fazer isso.

Tenho permissão sua pra mudar pra LGPL ?

Alan,

Respondi agora a pouca ao Johan, sobre a questão da mudança da licença, acredito que você receba também.

Acho importante usar uma licença que permita o uso em sistemas comerciais também, lembro que o Renato Lima, me explicou na época as liberdades dadas pela licença AGPL.

Qual seria a licença que permitiria o livre uso do código, permitiria o uso em projetos comerciais, e não seria "viral" a ponto de projetos comerciais serem obrigados a liberar seu código?

Atenciosamente,-- Aristides Caldeira Taŭga Tecnologia aristides.caldeira@tauga.com.br1 3411-0602

[1] mailto:aristides.caldeira@tauga.com.br

alanjds commented 11 years ago

Entendi.

@aricaldeira: Bom, o que eu entendo dessas licenças diz que a AGPL é ainda mais "viral" que a GPL. A que você está procurando é LGPL mesmo.

Obrigado pelo apoio!

@Johan: Legal, então vai ficar LGPL mesmo! Eu estou estourado sem tempo nas próximas 2 semanas, então não vou conseguir trocar as licenças no código. Então se você trocar e mandar um pull-request eu vejo pra mergear, pode ser?

Outra coisa: no meu fork pessoal eu isolei a parte que valida e a parte que assina os arquivos XML, porque aqui na árvore principal está meio monolítico ainda. Se quiser pode dar uma olhada pra integrar as suas soluções sem xmlsec e com A3 também.

Obrigado pelo interesse e pelas features!

Alan Justino da Silva * Cel: +55 11 99822-5769

Em 24 de junho de 2013 22:31, Aristides Caldeira notifications@github.comescreveu:

Era seg, 24 de junho de 2013, 18:04, e Alan Justino da Silva me escreveu:

@aricaldeira , como a maioria do código atual é seu, e não é "trivial" mudar uma licença, gostaria da sua permissão pra mudar pra LGPL, mesmo já tendo condição "técnica" pra fazer isso.

Tenho permissão sua pra mudar pra LGPL ?

Alan,

Respondi agora a pouca ao Johan, sobre a questão da mudança da licença, acredito que você receba também.

Acho importante usar uma licença que permita o uso em sistemas comerciais também, lembro que o Renato Lima, me explicou na época as liberdades dadas pela licença AGPL.

Qual seria a licença que permitiria o livre uso do código, permitiria o uso em projetos comerciais, e não seria "viral" a ponto de projetos comerciais serem obrigados a liberar seu código?

Atenciosamente,-- Aristides Caldeira Taŭga Tecnologia aristides.caldeira@tauga.com.br1 3411-0602

[1] mailto:aristides.caldeira@tauga.com.br

— Reply to this email directly or view it on GitHubhttps://github.com/aricaldeira/PySPED/issues/7#issuecomment-19947727 .

jdahlin commented 11 years ago

A questão da licença não é simples, tem muitos detalhes pequenos.

AGPLv3 realmente é uma boa escolha se você não quer que ninguém usa sua biblioteca em produtos comerciais, ele oferece a maior proteção entre todas as licenças que eu conheço. Acredito que motivo que OpenERP está usando ele é para OpenERP.com tem um business model que permite eles vender versão do código do OpenERP usando uma licença propretoria, em caso que uma empresa não quer abrir uma extensão.

LGPLv2 oferece a maior compatibilidade, com sistemas comerciais e software livres, e ela também protege o projeto para ninguém poder modificar sem incluir as mudanças.

Por exemplo:

  1. OpenERP, licenciada usando AGPLv3, pode usar bibliotecas em LGPLv2+.
  2. Stoq, licenciada usando GPLv2, pode usar bibliotecas em LGPLv2+.
  3. Uma sistema comercial, pode usar bibliotecas em LGPLv2+.
jdahlin commented 11 years ago

Massa, vou ver se eu consigo mandar um pull request para trocar licença.

Mas lembra, para poder mudar licença, todo mundo que fez uma contribuição que não é trivial teria que concordar.

Pelo que eu vi no código fonte só duas mudanças significativas, uma do @renatolima e outro do @daniel-hartman

@renatonlima e @daniel-hartmann vocês concordam com a mudança de AGPLv3 para LGPLv2?

rodrigopitanga commented 11 years ago

Respondi pelo e-mail, mas acho que nem todos receberam: Estou apenas acompanhando o projeto há algum tempo, mas como entendo razoavelmente bem de licenças vou dar meu pitaco. O stoq é gpl v2 or later, ao menos segundo um dos arquivos cujo cabeçalho eu verifiquei. Se for (L)GPLv2 or later, o código AGPLv3 é compatível. Cada código original será regido pela licença será regida pela AGPLv3.

rodrigopitanga commented 11 years ago

Ops, no final quis dizer "cada pedaço de código será regido pela respectiva licença, mas a obra combinada será regida pela AGPL."

rodrigopitanga commented 11 years ago

A licença Affero GPL, assim como a GPL ou a LGPL ou qualquer licença de software livre, não veda o uso comercial. Muito pelo contrário, se não pode fazer uso comercial então não pode ser considerado livre. Tanto que o  OpenERP é um projeto de software livre E explorado comercialmente.

Acho que, dentro de um equívoco de terminologia, você quis dizer "proprietário" no lugar de "comercial": software que não permite redistribuição ou adaptação, independente do preço.

Tomando a liberdade de dar a minha opinião, eu acho mais interessante manter uma licença viral como a AGPL, pois ela potencializa a comunidade incentivando mais desenvolvedores de software a contribuir seu código em troca do uso de algo que já está disponível sob essa licença. O uso de uma licença mais permissiva pode parecer mais atraente de cara, mas enfraquece esse laço.

A excelência do OpenERP se deve, em grande parte, ao uso da AGPL, a "mais viral" de todas, pois, além de maximizar o garante a todos os usuários de determinado módulo a possibilidade de obter o código fonte e adaptá-lo às suas necessidades, qualidade que nenhum outro ERP relevante no mercado tem. E isso sem impedir que as empresas o explorem comercialmente através de pacotes de suporte e customização.

rodrigopitanga commented 11 years ago

@alanjds respondendo à sua pergunta de 15/5, não, vc não tem direito ao código do meu cliente que foi linkado com o seu código. A viralidade é sempre para a frente :)

jdahlin commented 11 years ago

@rodrigopitanga Sim, simplifiquei. Queria realmente dizer "proprietário" ao invés de "comercial".

Não contei todos os detalhes, eu mesmo gostaria de ter a oportunidade de vender Stoq usando uma licença proprietário para clientes que estão preparados para pagar por isso. Por isso a AGPL não serve. Todos os serviços que comunicam com uma programa usando AGPL vira "viral", por exemplo nem sei se é possível usar um banco de dados que não seja software livre em conjunto com um aplicativo que é AGPL.

Se PySPED continua utilizado a licença, eu e meu equipe de desenvioladores não vai poder contribuir para o projeto, queria realmente evitar ter que duplicar a funcionalidade do PySPED dentro do meu aplicativo ou/e uma outra biblioteca licenciada usando uma outra licença menos restritiva.

rodrigopitanga commented 11 years ago

@jdahlin você não precisa sacanear o cliente com uma licença proprietária para ganhar dinheiro com o seu trabalho. Minha empresa usa OpenERP. Estamos contratando uma empresa para dar suporte técnico e outra para configurar e parametrizar o ambiente, pois não temos tempo ou capacidade técnica para isso. Agora, me parece meio incoerente vc pedir para a biblioteca adotar uma licença menos "restritiva" para que você possa aplicar uma mais restritiva ainda para o seu cliente ;) Sobre o banco de dados, acredito que a agpl não viralize para ele assim como nao viraliza para o sistema operacional, pois o software nao esta linkado com ele, apenas se comunica. O driver, entretanto, deve ser compativel. Vale lembrar que a licença "viralizar" quer dizer que os seus termos aplicam-se à obra derivada, mas cada pedaço de código detem a licença original.

jdahlin commented 11 years ago

@rodrigopitanga Eu concordo com você, eu realmente gostaria de ter a possibilidade de usar só AGPL para Stoq. Mas meus clientes estão me pedindo para eles poder usar Stoq junto com infraestrutura interna deles que utilizam uma licença proprietária. Simplesmente quero poder atender eles, para eles poder usar meu software, AGPL não permitiria isso.

Isso é exatamente como OpenERP funciona é por que eles também podem oferecer clientes deles uma licença proprietária se precisaria. Você pode usar OpenERP normalmente usando AGPL, mas também se você precisa você pode contratar OpenERP Enterprise tem uma exceção que permite uso com infraestrutura mista. Veja http://v6.openerp.com/legal e para mais detalhes http://v6.openerp.com/services/faq-onsite. Tenho certeza absoluta que OpenERP não teria sucesso com apenas a licença AGPL.

Também, podemos conversar quanto quisermos sobre o assunto, mas quem decide no final são os contribuidores do projeto, e me aparece que eles estão todos a favor de fazer esse re-licenciamento.

No final, se PySPED continua usando licencia AGPL, o projeto via pelo menos perder integração com minhas contribuições.

rodrigopitanga commented 11 years ago

@jdahlin

se o seu cliente vai usar apenas internamente, não há necessidade de mudar a licença, pois a AGPL é compatível com isso. O mecanismo de Copyleft só é disparado quando há distribuição do software. Se o seu cliente pegar o Stoq, modificar e distribuir (ou, no caso específico da AGPL, permitir interação por rede) para alguém (nesse caso, alguém é "third party", e não conta, por exemplo, funcionários da empresa usando o software em nome da empresa), aí ele deve, caso requisitado, repassar o código fonte para a pessoa que recebeu o software modificado. Se ele quiser usar o Stoq com um módulo proprietário de alguém ou com código dele que ele não pretende distribuir, não há nada na [A,L]GPL que impeça isso. Veja um comentário acima explicando isso.

No caso do OpenERP, talvez haja uma interpretação errônea por parte deles, pois, pelo que entendi dos links que você me passou, você teria que adquirir uma licença específica caso queira usá-lo internamente com um módulo incompatível com a AGPL. Isso não está correto, ao menos de acordo com a licença AGPL. Só está correto caso você queira distribuir o seu módulo, seja distribuindo diretamente ou disponibilizando como um serviço online (SaaS - Software as a Service).

Sobre a decisão final, certamente, é dos detentores do copyright. Só estou dando a minha opinião pessoal em alguns pontos, e esclarecendo especificidades das licenças, pois notei algumas interpretações erradas ao longo da discussão.

alanjds commented 11 years ago

Por viralizar eu entendo: todo código linkado se torna licenciado pelos mesmos termos. Eu gostaria de LGPL para me permitir linkar código proprietário, que é o que tem financiado meu desenvolvimento na PySPED.

AGPL e GPL infectam todo código que for linkado nela. E com AGPL piora porque eu não posso nem fazer um SaaS que entao preciso doar o código do SaaS inteiro.

Eu QUERO compartilhar os custos de desenvolvimento do SPED, mas NAO POSSO compartilhar os códigos que o utilizam.

Por isso, só me serve LGPL ou mais liberal, como MIT.

Até o momento, estávamos numa situação de "sem licença". Se eu entendi a posicao do Ari, ele gostaria de obrigar contribuições livres mas permitir usos proprietários (é isso mesmo, @aricaldeira ?). Acredito que só a LGPL fornece isso.

Estou cogitando um fork do ultimo commit "sem licenca" do Ari, e trabalhar LGPL a partir deste ponto. Não porque é o que eu quero, mas porque é a opção que me permite continuar contribuindo, como é o caso para o @jdahlin Em 25/06/2013 10:45, "Rodrigo Rodrigues da Silva" notifications@github.com escreveu:

@jdahlin https://github.com/jdahlin você não precisa sacanear o cliente com uma licença proprietária para ganhar dinheiro com o seu trabalho. Minha empresa usa OpenERP. Estamos contratando uma empresa para dar suporte técnico e outra para configurar e parametrizar o ambiente, pois não temos tempo ou capacidade técnica para isso. Agora, me parece meio incoerente vc pedir para a biblioteca adotar uma licença menos "restritiva" para que você possa aplicar uma mais restritiva ainda para o seu cliente ;) Sobre o banco de dados, acredito que a agpl não viralize para ele assim como nao viraliza para o sistema operacional, pois o software nao esta linkado com ele, apenas se comunica. O driver, entretanto, deve ser compativel. Vale lembrar que a licença "viralizar" quer dizer que os seus termos aplicam-se à obra derivada, mas cada pedaço de código detem a licença original.

— Reply to this email directly or view it on GitHubhttps://github.com/aricaldeira/PySPED/issues/7#issuecomment-19976750 .

jdahlin commented 11 years ago

@rodrigopitanga do que você está falando aplica para GPL normal, mas AGPL tem uma clausula (13) adicional acaba deixando ele bem mais restritivo. Os aplicativos não pode nem comunicar com outros processos que não são licenciadas usando AGPL, veja:

13. Remote Network Interaction; Use with the GNU General Public License. Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer _all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph._

Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License.

No FAQ do AGPL, também explica em lingua um pouco menos denso:

If the program is expressly designed to accept user requests and send responses over a network, then it meets these criteria. Common examples of programs that would fall into this category include web and mail servers, interactive web-based applications, and servers for games that are played online.

If a program is not expressly designed to interact with a user through a network, but is being run in an environment where it happens to do so, then it does not fall into this category. For example, an application is not required to provide source merely because the user is running it over SSH, or a remote X session.

Em outras palavras, outros serviços comunicando com seu aplicativo também tem que usar AGPL. Pelo menos se eles accept user requests and send responses que pode basicamente aplicar para qualquer tipo de comunicação.

Para um aplicativo pode ser viável usar AGPL, mas para uma biblioteca isso significa que basicamente ninguém vai poder usar. Por exemplo, eu acredito que não pode usar oauth to google dentro de um aplicativo AGPL.

rodrigopitanga commented 11 years ago

Apenas para esclarecer o ponto em que acredito que a interpretação da OpenERP seja (parcialmente) incorreta:

http://www.gnu.org/licenses/gpl-faq.html#InternalDistribution

Is making and using multiple copies within one organization or company “distribution”?

No, in that case the organization is just making the copies for itself. As a consequence, a company or other organization can develop a modified version and install that version through its own facilities, without giving the staff permission to release that modified version to outsiders.

However, when the organization transfers copies to other organizations or individuals, that is distribution. In particular, providing copies to contractors for use off-site is distribution.

Eu acredito que o mesmo raciocínio aplique-se ao "interaction" da seção 13 da AGPL. Na dúvida, perguntei para a FSF.

@jdahlin

Os aplicativos não pode nem comunicar com outros processos que não são licenciadas usando AGPL

na verdade a seção 13 fala de interação com o usuário, não com outros aplicativos (por exemplo, o sistema operacional ou um bd). A "interação" com outro software (seja por linkagem, combinação de código, ou apenas comunicação entre processos distintos) funciona exatamente como na GPL: a mera comunicação não "viraliza". Por exemplo, não é porque você faz um software GPL que roda em Windows que o Windows teria que ser GPL.

De todo modo, meu ponto era apenas esclarecer sobre as licenças. Acho que essa discussão não cabe mais aqui. Caso alguém esteja interessado ou ainda tenha alguma dúvida, fico à disposição para discutir por e-mail.

alanjds commented 11 years ago

Minha posição é de que o licenciamento atual (AGPL) impede que alguns de nós comecem ou continuem a contribuir, e proponho re-licenciamento para LGPL.

Dado que:

Pergunto:

Se sim, a LGPL pode ser usada com o OpenERP. Se não, não.

Acho que saber isso é necessário pro Ari descobrir se podemos re-licenciar ou se teremos que fazer um novo projeto para usar LGPL.

Eu não sou advogado, mas também é discutível um licenciamento duplo AGPL/LGPL, ou fazer uma LGPL com uma exceção explícita que diga "caso linkada com AGPL, usar os termos da AGPL ao invés da LGPL"

Faz sentido para vocês @aricaldeira, @renatolima e @daniel-hartman ? Proponho que exponham quais licenças vocês preferem/permitem para o código de vocês no PySPED.

jdahlin commented 11 years ago

AGPL permite que você linka com LGPL, sem nenhuma dúvida.

alanjds commented 11 years ago

@jdahlin eu dei control+f na página e não achei nada sobre isso. Só tem uma exceção explícita para a GPL "padrão"

jdahlin commented 11 years ago

LGPL pode automaticamente ser convertido para GPL, então se permite linkar para GPL também permite linkar para LGPL, certo?

alanjds commented 11 years ago

@jdahlin: Acredito que você tem razão: http://www.gnu.org/licenses/gpl-faq.en.html#compat-matrix-footnote-7 e http://www.gnu.org/licenses/gpl-faq.en.html#compat-matrix-footnote-1

Se estiver licenciado como LGPL 2.1+, é compatível com AGPL via conversão automática para GPL, e então com o OpenERP

(btw, a tabela completa de compatibilidade entre LGPL x GPL: http://www.gnu.org/licenses/gpl-faq.en.html#AllCompatibility)

Então proponho trocar para LGPL 2.1+. Para acontecer, @aricaldeira @renatolima e @daniel-hartman precisam se manifestar aprovando a troca, é isso?

renatonlima commented 11 years ago

Olá Pessoal,

O pessoal falou um pouco sobre a licença do OpenERP que é AGPL3 desde 2007 (antes era GPL), para deixar claro o OpenERP e em 2011 foi anunciado pela OpenERP S.A. a possibilidade de ter um licenciamento duplo, mas na pratica ISSO NÃO EXISTE porque a AGPL3 não permite, já que a OpenERP S.A. não tem um CLA com todos os contribuidores que fizeram contribuições inclusive no core do projeto, e alguns contribuidores já deixaram claro que é contra o licenciamento duplo do ponto de vista legal o licenciamento duplo não existe e depois de muita pressão da comunidade a OpenERP S.A. colocou no FAQ observações dizendo que o licenciamento duplo é incompatível com módulos AGPL3, aqui no Brasil onde o projeto de localização brasileira http://openerpbrasil.org é todo em AGPL3 você não pode usar com módulos privados com a localização brasileira por exemplo.

Eu tinha aconselhado o @aricaldeira a colocar a licença AGPL3 no PySPED já que não tinha uma licença sendo que a AGPL3 é a mais viral, eu trabalho com alguns projetos que usam a AGPL3 e na minha opinião é a que mais protege os conceitos do software livre já que quem usa o software ou oferecer serviços devem disponibilizar as melhorias ao cliente (lembrando que a licenças *GPL não obrigam você a pulicar na internet o codigo), No caso da GPL e LGPL permite que você "feche" o código até mesmo para o seu cliente já que a maioria dos software são acessados pela rede/internet principalmente se você fizer um SAAS, por isso que tinha aconselhado a mais viral.

Eu trabalho com o OpenERP que é AGPL3 há mais de 4 anos, mas no caso do PySPED que é uma biblioteca que não tinha pensado muito no caso das pessoas querem usar com software proprietário, acho que é mais uma questão de estrategia, eu gostaria que todo mundo usasse software livre :) mas temos que ser realista, e sou favorável que tenha mais pessoas contribuindo com o projeto PySPED, então por mim se o @aricaldeira pensa da mesma maneira eu aprovo a mudança.

Na minha opinião seira bom o @aricaldeira colocar no projeto um acordo de contribuição CLA http://en.wikipedia.org/wiki/Contributor_License_Agreement para evitar problemas futuro com as contribuições.

jdahlin commented 11 years ago

@renatonlima Obrigado por ter contado a historia sobre AGPL e licença dupla dentro do OpenERP, eu não conhecia.

Hoje tem dois jeitos diferentes de usar um software, executando localmente ou acessando pelo internet. Para primeiro caso a LGPL protege bem, no segundo teria que usar AGPL para realmente proteger, mas os efeitos laterais do AGPL é que fica muito difícil usar em qualquer ambiento com licencias mistas.

Sobre CLA, estou fortemente contra. CLAs acabam restringindo os contribuidores totalmente, eu pessoalmente não assinaria um CLA. Michael Meeks com muita experiencia na area já escreveu melhor as problemas aqui. LGPLv2.1 ou mais tarde acredito que seria suficiente para não ter muitos problemas futuras.

alanjds commented 11 years ago

Se existisse uma ALGPL, que implicasse em distribuição obrigatória a clientes web, mas apenas para a lib, não para o código proprietário linkado, então eu seria a favor desta ALGPL.

Quem sabe quando sair uma GPLv4 ou GPLv3+, mas acho difícil de acontecer. Também não gosto de CLA, porque cria fricção a novos desenvolvedores, mas eu não deixaria de contribuir se existisse.

Alan Justino da Silva * Cel: +55 11 99822-5769

Em 26 de junho de 2013 09:41, Johan Dahlin notifications@github.comescreveu:

@renatonlima https://github.com/renatonlima Obrigado por ter contado a historia sobre AGPL e licença dupla dentro do OpenERP, eu não conhecia.

Hoje tem dois jeitos diferentes de usar um software, executando localmente ou acessando pelo internet. Para primeiro caso a LGPL protege bem, no segundo teria que usar AGPL para realmente proteger, mas os efeitos laterais do AGPL é que fica muito difícil usar em qualquer ambiento com licencias mistas.

Sobre CLA, estou fortemente contra. CLAs acabam restringindo os contribuidores totalmente, eu pessoalmente não assinaria um CLA. Michael Meeks com muita experiencia na area já escreveu melhor as problemas aquihttps://people.gnome.org/%7Emichael/blog/copyright-assignment.html. LGPLv2.1 ou mais tarde acredito que seria suficiente para não ter muitos problemas futuras.

— Reply to this email directly or view it on GitHubhttps://github.com/aricaldeira/PySPED/issues/7#issuecomment-20044012 .

renatonlima commented 11 years ago

Sobre a questão do CLA, para deixar claro que o CLA não tira o seu copyright e a autoria da sua contribuição, mas é um acordo que é feito com o líder do projeto para evitar futuras disputas sobre a contribuição, acho que isso é bom para o projeto, porque imagine que alguma pessoa que contribuiu se oponha ao líder do projeto ou a maioria dos contribuidores, eu não vejo problema em fazer um CLA com o líder do projeto, porque se mais pessoas contribuem com o projeto, fazer qualquer alteração de licença como possíveis novas versões das licenças *GPLs pode ser difícil alterar mesmo que a maioria absoluta queira, lembrando também que em casos de disputas tanto com a CLA quanto sem pode existe a possibilidade de fork em caso de insatisfação com o líder ou com rumo dos projetos (como aconteceu com o OpenERP que em 2008 surgiu um fork chamado Tryton).

Eu conheco o @aricaldeira um pouco, e não tenho nenhum problema em fazer esse acordo com ele, a única exigencia que eu faria é de numca o código fosse fechado ou existir uma versão "community" e "enterprise" do pysped. Mas foi só uma sugestão que eu levantei e já que estamos mudando a licença seria bom os atuais contribuidores pensar nesta possibilidade

daniel-hartmann commented 11 years ago

Eu aprovo a alteração da licença para LGPL. Abraços!

alanjds commented 9 years ago

Resolvida com o merge da #10.