Risco de Fork no Linux está menor, mas ainda existe

Vale lembrar que o Linus disse que, caso o OpenSolaris seja licenciado pela GPLv3, este seria um bom motivo para mudar o licenciamento para a mesma com o fim de evitar possíveis problemas ao tomar código emprestado um do outro.

Qual o problema desses caras?!? Duvido que chegue as vias do fato, seria extremamente ridículo... Um Suicídio?

http://mundovoip.wordpress.com/

Acontece que o kernel é licenciado apenas pela "GPLv2" já faz tempo, ao contrário da imensa maioria dos projetos que licenciam sob "GPLv2 ou superior".

Já rolou até um atrito com o savannah (repositório no estilo do sourceforge, administrado pela FSF), onde eles proibiram um projeto de ser cadastrado, apesar do mesmo ser licenciado pela GPLv2. Acontece que era apenas por esta versão e os "defensores da liberdade" queriam que o autor do projeto fizesse o licenciamento "GPLv2 ou superior"...

-------------

"Se a verdade está lá fora, o que estamos fazendo aqui dentro?!"

Moral da história? 15 anos aparentemente jogados fora..

Será que o Linux e o BSD sobrevivem mais 10 anos? O BSD eu tenho certeza que sim, mas o Linux..

Pelo menos podemos escolher né!!!!

Ao contrários dos adoradores da EULA!

Accpet e vamo que vamo!!!

Seria pedir demais explicar o termo "fork", ao menos durante a notícia? :-/

Ei cara, esse seu outro artigo (Possível fork no GNU/Linux, http://www.meiobit.com/open_source/possivel_fork_n...) me deu uma confundida.

Na liberdade 4, você diz: "Você tem o direito (e ao mesmo tempo a obrigação) de redistribuir as modificações feitas.". Eu achava o seguinte: quando você modifica um programa e o distribui, você precisa distribuir também o código modificado. Mas quando você modifica um programa para uso próprio, você não precisa distribuí-lo, nem o programa nem o código, se não quiser.

Do jeito que você falou, ficou parecendo que você precisa distribuir o código de qualquer jeito.

É isso mesmo que eu disse ou estou errado?

Acredito que esteja ocorrendo um equivoco aqui, qual seria o problema de se ter o kernel sob GPL-2 e aplicações GNU sobre GPL-3 ?

Hoje em dia temos o kernel sob GPL-2 e usamos vários outros programas no linux sobre licenças diferentes, vide linceça apache, bsd, entre tantas outras.

O fato do kernel usar uma licença diferente dos programas GNU não impede de usar softwares GNU sobre o kernel Linux.
Quanto ao lado da FSF, que eu saiba o kernel oficial deles até hoje ainda é o GNU HURD,

E também, pelo que eu entendo, poderiam ser escritos novos componentes pro kernel sobre a GPL-3; o que Linus não pretende atualmente é mudar a licença do que existe hoje.

Logo, diante das coisas que eu levantei, ainda não vi aonde ocorreria uma fork no Linux.

As licenças que eu citei são incompatíveis entre si sim, eu estranhei até o post no meiobit, por que esse risco de fork ao meu ver ele não existe.

Eu tenho o ironpython instalado no linux, que usa licença Shared Source da microsoft, a Shared Source é incompatível com a GPL-2, mas não quer dizer que não possa rodar um programa Shared Source no linux.

Para a GPL-3 ser incompatível com a GPL-2 a ponto de necessitar de um FORK, deveria ter uma restrição nela dizendo que você não poderia usar em máquinas que contém software com a lincença GPL-2, o que certamente não acontece.

Pontos colocados na matéria:

* Necessidade da FSF criar um kernel.

* Necessidade do Linux criar um fork de todos os pacotes GNU.

* Diminuição da velocidade de desenvolvimento por causa dos itens acima.

* Divisão dos esforços de desenvolvimento.

* Divisão do mercado (muito maior do que a existente, hoje, por causa das diversas distribuições).

Nada acima é verdadeiro, uma vez que aplicativos diferentes pode ter licenças diferentes. O que não pode é o código de um aplicativo GPLv2 se misturar com algum código sob GPLv3. Ou seja, NÃO há necessidade nenhuma de criar forks, entre outras coisas, por esses motivos, e nem haverá duplicação de esforços.

O que pode acontecer é de alguns desenvolvedores de módulos ou outras partes do kernel quiserem escrever seus códigos sob GPLv3. Nesse caso, se o Linux não for adotar a GPLv3, esses códigos não entrarão no Linux. Um fork seria possível, mas os códigos em GPLv2 não poderiam entrar no Linux em GPLv3. Não acredito que acontecerá um fork sob essas condições, o mais natural será o Linux adotar a GPLv3 se a grande maioria de seus contribuidores escreverem códigos somente pela GPLv3.

Vejamos alguns trechos de um artigo do Stallman:

A GPL versão 2 vai continuar sendo uma licença válida e nenhum desastre vai acontecer se alguns programas continuarem sob a GPLv2 enquanto outros avançarem para a GPLv3. Essas duas licenças são incompatíveis, mas isso não é um problema sério. Continua: Quando dizemos que a GPLv2 e a GPLv3 são incompatíveis, significa que não há um meio legal de combinar código sob a GPLv2 com código sob a GPLv3 em um único programa. É assim porque ambas a GPLv2 e a GPLv3 são licenças copyleft: cada uma delas diz: "Se você incluir código sob esta licença em um programa maior, o programa maior deve estar sob esta licença também." Não há como torná-las compatíveis. Nós poderíamos adicionar uma cláusula de compatibilidade com a GPLv2 na GPLv3, mas isso não seria o suficiente, porque a GPLv2 precisaria ter uma cláusula similar.

Mais: Felizmente, incompatibilidade entre licenças somente importa quando você quiser linkar, mesclar ou combinar código de dois programas diferentes em um único programa. Não há problema em ter programas cobertos pela GPLv3 e programas cobertos pela GPLv2 lado a lado em um sistema operacional. Por exemplo, a licença TeX e a licença Apache são incompatíveis com a GPLv2, mas isso não nos impede de rodar o TeX e o Apache no mesmo sistema com Linux, Bash e GCC. É assim porque todos são programas separados. Do mesmo modo, se Bash e GCC mudarem para a GPLv3, enquanto o Linux continuar sob a GPLv2, não há nenhum conflito.

[...]

Manter um programa sob a GPLv2 não criará problemas. A razão para migrar são os problemas existentes que a GPLv3 vai resolver.

Artigo em http://www.fsfla.org/svnwiki/trad/GPLv3-why

--

aptitude install anarchism