24
Off Topic: A Controvérsia Ext JS 2.1 x GPL
on April 24, 2008
Você usa Ext JS? Num projeto comercial? Cuidado …
Alguns dias atrás iniciou-se uma longa discussão em diversos fórums sobre o framework ExtJS.
Para quem não conhece o framework ExtJS é um toolkit extremamente complexo feito em puro Javascript. O autor, Jack Slocum, começou criando uma extensão à biblioteca Yahoo UI mas ele cresceu para algo ainda maior.
Pense um toolkit gráfico completo, com elementos complexos como grids, tabelas, árvores e todo tipo de widget que você veria num Visual Basic, Delphi ou parecido. Ele faz interfaces quase tão complexas e bonitas quanto vocês fariam num Adobe Air, por exemplo.
A comunidade começou a usar o ExtJS em massa. Porém, uma grande controvérsia se iniciou no lançamento do ExtJS versão 2.1.
to GPL or not GPL?
A partir de agora, cuidado, eu não sou advogado e portanto o que sei de direitos autorais é muito pouco para tirar conclusões. Vou expôr o que eu entendi das discussões e peço que, se existe algum leitor aqui que tenha embasamento jurídico para comentar, que por favor o faça.
Enfim, até a versão 2.0, o ExtJS era distribuído como LGPL. O que eu entendo de diferença entre LGPL e GPL é que LGPL é adequado para código que seja usado como biblioteca (como .dlls, .so, .js, etc), ou seja, código que pode ser reusado em outro software. A vantagem é não ter a característica VIRAL do GPL. Ou seja, eu poderia criar um software que usa o ExtJS mas não precisaria que meu próprio código fosse GPL.
A partir da versão 2.1 eles retiraram a licença LGPL e a ela se sobrepôs a temida GPL 3. Qual o problema disso? Exatamente o toque de Midas: tudo que o GPL toca vira GPL. Nesse caso qualquer software que use o Ext de alguma forma deve se tornar necessariamente GPL.
Mas e se eu quiser criar um software comercial, que eu vendo a clientes, e ainda usar Ext? Assim como MySQL, por exemplo, o ExtJS também tem Dual Licensing, ou seja, em você querendo manter seu código fechado, você pode comprar licenças comerciais da empresa ExtJS, LLC. Assim você fica livre dos compromissos impostos pelo GPL.
Nas palavras do próprio Jack Slocum :
- Suponha que você tenha uma aplicação web com um index.php que inclui Ext JS. Nesse caso o index.php deve ser GPL já que está usando Ext. E já que ele precisa ser GPL, seu código fonte precisa ser distribuído. Também por causa disso, o efeito “viral” do GPL está agora em ação e qualquer coisa que use isso no lado do servidor também precisa ser GPL.
- Suponha que você está usando código server-side para gerar javascript que interaja com Ext JS. Esse código também precisa ser GPL.
Ou seja, o que está irritando a comunidade é:
- Ou você está fazendo um projeto que já é GPL;
- Ou você precisa comprar licenças comerciais da Ext JS, LLC.
Muitas questões ficam em aberto. Parece que o pessoal do Zope (Python) recomendaram no seu fórum que ninguém faça commit de código com ou derivado de Ext no trunk.
Isso também deixa em aberto o que outros projetos que são open source, mas não são GPL, podem fazer. Por exemplo quem usa a licença BSD, Apache, MIT e outros. Vejam este trecho no fórum deles.
Portanto, cuidado, se você pretende criar software comercial que utiliza Ext JS, deve pagar pela licença comercial, caso contrário deve liberar seu código como GPL.
É exatamente por isso que muitos projetos open source não gostam do GPL e preferem licenças realmente livres como BSD, que não tem tal cláusula viral.
Usem Ext JS se precisar, mas prestem atenção para qual lado da cerca você cai ao fazer isso.
Até onde entendo de licenças, não é problema você vender um software licenciado como GPL, desde que o código fonte do mesmo o acompanhe. O que não é problema no caso do index.php (exemplo do post). Você não precisa distribuir o código para a comunidade, o distribuir significa apenas que o fonte deve ser distribuido juntamente com os binários.
Acredito que o grande problema aqui, seja apenas você ser obrigado a licenciar seu produto como GPL, quando você na verdade não quer.
Eu acredito que o problema aqui não é você ter que licenciar o produto, o problema é você, de certa forma, está meio que obrigado a liberar o código lado servidor de uma aplicação comercial, caso não pague a lecença. Realmente temos um impasse.
Sou leitor do Akita On Rails há algum tempo e em geral adoro o conteúdo mas esse post (talvez pelo foco não ser técnico) me fez disparar a flag de ‘open source advocate’.
O propósito da licença GPL é garantir que quem faz uso do código desenvolvido por terceiros não posso aplicar ao resultado de seu trabalho uma licença mais restritiva do que a do código que utilizou. Em outras palavras, se eu desenvolvo um software X, que faz uso de uma biblioteca Y, é bem provável que Y > X (em termos de funcionalidade/complexidade/utilidade ou qualquer outra métrica similar). No entanto, se a licença de Y é mais restritiva do que a de X, então isso significa que caso alguém deseje escrever um terceiro software Z, onde Z > Y, ele terá que reproduzir todos os esforços desenvolvidos pelo autor de Y.
Tudo isso, a longo prazo, diminui bastante a velocidade com que o software de código aberto pode evoluir, uma vez que um mesmo degrau pode precisar ser escalado mais de uma vez apenas por restrições nas licenças dos trabalhos derivados de esforços que foram disponibilizados como software livre. Entendo perfeitamente as implicações disto para os desenvolvedores pagos por seu trabalho, mas não seriam justamente estes que deveriam pagar por suas bibliotecas também? O problemas da licença só introduz complicações para softwares e bibliotecas que fazem uso de licenças mais liberais do que a GPL e que incluem o ExtJS, porque você não pode incluir código GPL em uma biblioteca BSD/Artistic License, por exemplo.
Enfim, apenas meus $0.02 de contribuição para que todos entendam os diversos ângulos do problema.
É interessante como até os desenvolvedores, que tomaram a iniciativa de trocar a licença, desconhecem como a GPL 3 funciona.
” * Suponha que você tenha uma aplicação web com um index.php que inclui Ext JS. Nesse caso o index.php deve ser GPL já que está usando Ext. E já que ele precisa ser GPL, seu código fonte precisa ser distribuído. Também por causa disso, o efeito “viral” do GPL está agora em ação e qualquer coisa que use isso no lado do servidor também precisa ser GPL.”
Perfeito, mas a GPL não diz isso. O que diz é que, caso você queira distribuir a sua aplicação, deve distribuir também o fonte caso seja requisitado. Além disso, o fonte não pode ser distribuído por um preço maior do que o programa original.
Ou seja, as opções são:
- Você já está trabalhando em um projeto GPL: Nenhuma mudança - Você está trabalhando em um projeto comercial. Nesse caso, se for um produto, que vai ser vendido e distribuído, você deve adquirir a versão comercial.
Mas, se a sua aplicação vai rodar no servidor e não vai ser distribuída, não há o menor problema em ela ser GPL. Se alguém vier pedir o fonte, você pode mandar ele pra aquele lugar.
Lembrando: eles mudaram para a GPL e não para a Affero GPL.
http://www.gnu.org/licenses/gpl-faq.html
@ulisses, sim, eu entendo isso, porém peço que dê uma olhada nas discussões dos links (são longas).
O problema é que a biblioteca ExtJS antes era LGPL. Muita gente estava usando em projetos comerciais ou open source com outras licenças porque o LGPL é muito menos restritivo.
Porém, pulando da versão 2.0 para 2.1, o esquema mudou, o LGPL foi tirado fora e agora vale o GPL. Ou seja, ficou aquela sensação de “fui ludibriado”. Porque muita gente usou na confiança, agora depende desse projeto, e de repente seu projeto se torna GPL?
Outra coisa, antes disso o problema era que o autor do ExtJS tinha usado o LGPL com restrições. O problema é que a cláusula 7 do LGPL impede que ela sofra restrições extras, o que foi motivo de discussão também.
Depois de todo esse problema, a impressão que ficou em todos os fóruns é que o autor do ExtJS agiu de má-fé. Fez todos acreditarem que o projeto era de fato ‘livre’ e, de uma hora para outra, depois que ele conseguiu bastante gente, colocou o GPL para barrar todo mundo e ainda usar uma etiqueta de “sou open source” e agora quem não puder ser GPL precisa obrigatoriamente comprar licenças (que não são baratas).
Projetos comerciais, ok, não era o previsto mas vamos comprar. Agora e projetos open source que gastaram recursos investindo em usar o Ext e agora precisam parar. O pessoal do Struts2, do Zope chegaram a esse impasse.
O objetivo do Jack Slocum parece que foi de pintar uma imagem de “bonzinho” acrescentando um sistema de dual licensing que no fundo não é de fato aberto.
Leiam a discussão.
@stephen, parece que nem todos concordam com essa definição (eu também achava que fosse assim). Por exemplo, veja o que o pessoal tem escrito nos fóruns:
anonymous
It is a little confusing.
Your application’s client can use the current GPL version of Ext in which case the client would have to be GPL. If the client and server are tightly integrated you risk them being seen as a single program and it is possible the server would also have to be made GPL. Doing things like having the server dynamically generate JS code to create layouts, menus, windows, etc places you far into the risk area. This is fine though. Your code becomes GPLed. You still don’t have to distribute it, but it still is GPL. There are a few questionable GPL issues where you are distributing the client source in order for the user to even be able to run it. This risks requiring the server to be opened, but I don’t believe this is the intent.
As long as the client/server aren’t too tightly integrated and dependent on one another you should be able to have a GPL client and a closed source server. It’s dangerous territory though, and you need to be careful about crossing the line or risking copyright issues. For that reason many commercial apps would just buy a license.
The AGPL would make it difficult to run a server without opening the source. We should be careful. ExtJS may switch future releases to AGPL without any notice!
You can run the LGPL 2.0.2 version. This is tricky. The core dev for ExtJS says it wasn’t LGPL unless you met their terms. Once you met their terms however, it was. They are almost completely wrong. But their intent wasn’t for it to be LGPL without their terms. Still, it is probably acceptable to keep down this route and likely even meet their terms, but don’t expect fixes or support or community or anything, unless there is a fork. Pray for a fork.
Look up other toolkits. Dojo is decent, but the docs and examples aren’t there yet making it difficult to do a lot of things without digging through source code to find out what really is and isn’t supported. Still, Dojo is under a very unrestricted BSD styled license and has a big community and big commercial support (IBM, for one.) It’s going to be around. It’s going to grow. And nobody has any power to make a devestating decision that could wreck the community and openness like was done here with Ext.
Esse tipo de coisa é sempre passível de acontecer a um software livre sob GPL. O desenvolvedor sendo detentor do copyright pode mudar a licença a qualquer momento, como já aconteceu em diversos outros casos.
E justamente a grande vantagem de ele ter sido GPL (nesse caso LGPL) é que pode-se fazer um fork do projeto em sua última versão LGPL criando um projeto paralelo que continuará sendo livre. E nesse caso, o desenvolvedor que fizer esse fork não poderá mais alterar a licença, dado que ele não detém o copyright original do software.
Parece não estar mais disponível no site oficial as versões antigas. Se alguém se interessar, encontrei aqui o código da versão 2.0: http://pypi.python.org/pypi/ore.extjs/2.0.2
@sylvestre, pois é, esse é outro thread de discussão lá. Parece que mesmo a versão 2.0 é LGPL + restrições do Ext. O próprio autor do Ext disse que fazer um fork do 2.0 é infringir o copyright deles.
Outros estão argumentando que o LGPL não pode sofrer restrições extras. Por isso gerou a briga sobre o 2.0 também.
Segundo o autor, não, você é proibido de fazer fork do 2.0.
E a discussão continua !! E o Jack Slocum bate na mesma tecla!!
teoricmaente, voce pode continuar usando as versoes anteriores (antes dele “virar GPL”), ja que a licenca que eh distribuida junto com a versao eh a LGPL…
mas acho que todo mundo ja sabia disso.. :-P
@herval, então, teoricamente sim, mas a controvérsia é essa mesma. Segundo o autor não é a LGPL, ele só usou o palavreado ‘LGPL’ na descrição para facilicar dizendo ‘é quase a LGPL com algumas exceções’. Então, tecnicamente não é LGPL. Alguns disseram que sequer tem menção a LGPL nos headers do fonte, mas isso eu não chequei.
E pelo visto o Jack Slocum tirou todas as versões anteriores ao 2.1 do ExtJS para download do site.
Agora, todos que forem iniciar projetos deverão estar com versão 2.1 ou então que arrumem um colega com alguma versão anterior pra compartilhar!
E ainda o assunto continua rendendo: http://www.jroller.com/sjivan/entry/my_response_to_jack_slocum
Pessoal já existe um fork da versão 2.0.2. http://sourceforge.net/projects/openext/
Então não é preciso ir muito longe. Agora é torcer para que esse paralelismo ganhe força.
É essa razão, que por muitas vezes, tornam perniciosa a adoção de bibliotecas com esse tipo de licenciamento em projetos comerciais.
Fica a sensação de que a comunidade foi feita de cobaia até que a biblioteca alcancesse estabilidade. E a tendência é que casos como esses se tornem mais comuns. Espero que esses exemplos não auxiliem na retroação no processo de colaboração que foi consolidado com a web2.0.
É.. passaram a perna na galera toda que estava mexendo com ExtJs.. mas se eu tenho a versão 2.0.2 e eu tenho :).. posso distribuir aplicações comerciais usando a licensa LGPL ? Como o Adriando falou é verdade!! vc ajuda a desenvolver, depois que ela fica estável vem o nosso “amigo” e te passa a perna!
Pessoal ótima discussão!!!
Como que está esse projeto paralelo? Vocês acreditam que ele decola?
Abraços
by Kuesley@
Prezados,
Não sou jurista, não tenho pretensão de sê-lo. Até porque as palavras quando BEM aplicadas no discurso formal não devem conter significados além do sentido único, primário:o denotativo, pois Leis, Normas e outros regramentos – perdoem-me os rábulas, advogados e outros juristas, fãs das riquesas de significantes do bardo idioma português – NÃO são obras literárias.
A GPL, para a qual NENHUMA tradução é aceita pela FSF, no que tange a complexidade de interperetação tem bastante similaridades com a Constituição promulgada (sic) de 1988. E, portanto, é assunto predileto nas quadras e rodas de biritas de info-bêbados, além do bafômetro evidentemente.
É neste sentido que prentendo conduzir o meu raciocínio, evitando polêmicas desnecessárias acerca de termos que a própria GPL define para dirimir quasiquer dúvidas. A minha preocupação é pontual e restringe-se ao uso de .* sob GPL internamente em aplicativos comerciais de uma grande empresa.
A quem interessar possa e tiver paciência de ler a longa lista de FAQ, as respostas para estas e outras perguntas estão em http://www.gnu.org/licenses/gpl-faq.htm.
Destacamos, a seguir, questões bem pontuais para atendimento a nossa dúvida, comum em grande empresas., a pergunta “Does the GPL require that source code of modified versions be posted to the public?”é respondida assim: “The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization. But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program’s users, under the GPL.”
Não há o que se discutir. A GPL não obriga a distribuição de um código modificado. Mas observa que se você quiser e o fizer, terá que fazê-la sob a GPL.
Indo um pouco além, ela também estende e explica o que é distribuir uma software. A resposta a pergunta “Is making and using multiple copies within one organization or company “distribution”? A resposta é categórica: “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.”
Ou seja, usar uma aplicação dentro uma empresa sob a GPL NÃO é distribuir uma aplicação.
Há também questões envolvendo interpretadores licenciados sob a GPL, para os quais a aplicação é um dado a ser interpretado e,portanto, não há obrigação de licenciamento da aplicação sob a mesma licença. Tá escrito lá nas FAQs.
Concluindo, no caso de um código licenciado pela GPL usado internamente em uma empresa, independente para qual fim ela se destina, NÃO constitui violação da GPL.
Nos demais, casos, é procedente e portanto, se você for distribuir de graça ou cobrando por sua aplicação que usa código *. GPL, ou você manda código junto com a aplicação, de acordo com a orientação da GPL em http://www.gnu.org/licenses/gpl-faq.html#CouldYouHelpApplyGPL ou, mais simples, compre tantas quantas forem a licença, neste caso da EXT JS para livrar o seu cliente de problemas LEGAIS.
attn,
Érico
Bem minha gente…
Uma coisa eu concordo com vocês.
Fui meio que sacanagem oque o cara fez…
Mas, se o software dele tinha resalvas de licensa, porque as ninguém olhou isso antes de escolher a biblioteca.
Sou a favor do código aberto, gosto de ferramentas livres.
Mas convenhamos, se eu estou vendendo minha aplicacao, estou economizando muito tempo e fazendo um produto de qualidade, porque não comprar???
Não é caro!
Acredito que todos podemos ganhar dinheiro juntos!
Afinal, se é disso que a gente vive, no problem, ajudamos outros a viver também!
Estava eu navegando por aí quando me deparei com esse cara: http://gwt-ext.com/
Ele usa a versão 2.0.2 do ExtJs.
Abraços.