Para mim, o autor do bitkeepe: Para mim, o autor do bitkeeper usou por todo esse tempo a comunidade, ele se aproveitou do linux, mysql e outros que usavam o software para ajudar no desenvolvimento e agora que está "pronto", tirou o corpo fora.

Sem máscaras: Olha isso tudo é muito chato, coisa e tal, mas não adianta querer mascarar para deixar bonito. O que aconteceu, sem filuras foi:

1. - Linux Torvalds decide usar o BitKeeper para ajudar seu amighuinho, autor do BiKeeper;


2. - A licensa do BitKeeper "free" proíbe o uso de engenharia reversa;


3. - Andrew decide usar engenharia reversa, já que não é proibido em vários países do mundo, para descobrer como funciona;


4. - O cara do BitKeeper fica revoltado (sem razão, o método é legal aonde foi feito);


5. - Linus sai em defesa de seu colega;


6. - Andrew diz que não vai parar a engenharia reversa;


7. - MvVoy fica ainda mais "emputecido" e decide acabar com a versão "free" (as in beer) do BitKeeper;


8. - Linus, sem escolha, decide abandonar o BitKeeper.

Isso pode ser motivo para flames, principalmente entre aqueles que acham que Linus Torvalds é o próximo messias, mas a culpa é exclusivamente dele. Larry MacVoy tem todo o direito sobre seu software, menos o de impedir que Andrew Tridgell estude-o por engenharia reversa. nenhum dos dois está errado.

Porém Linus Torvalds, na tentativa de "dar uma mãozinha" para seu amigo, usando da popularidade do Linux para alavancar o BitKeeper foi extremamente irresponsável ao aderir a um software cuja licensa fosse tão restritiva. Agora além dele, obviamente, estar pagando o próprio erro, todos nós estamos.

Lindo, Linus. Minhas congratulações.

--
Este espaço está disponível para publicidade.

Um detalhe: O que me enoja não é acabar com a licença gratuita. Um ponto, que parece esquecido, era de que o Bitkeeper, no ritmo de desenvolvimento em que estava o Linux, iria parar de funcionar em poucos meses. Motivo: um contador de changeset (ou coisa do gênero) de 16 bits apenas.

Lembrando. O Larry precisaria lançar uma versão nova do Bitkeeper devido a essa limitação na quantidade de changesets. Junto com essa nova versão, veio a proposta de mudança de licença, proibindo a engenharia reversa, impedindo o uso de outro SCM por um anós após o uso do Bitkeeper e por aí vai. Vejam o beco sem saída:
1) Querem usar o Bitkeeper novo? Então aceitem a licença nova e a condição de utilizarem Bitkeeper (e apenas ele) mesmo que vocês desistam da idéia (ou seja, liberdade zero).
2) Não querem? Tudo bem, daqui dois meses vai parar de funcionar mesmo... Boa sorte.

Difícil não acreditar que tal "limitação" do número de changesets não foi premiditada. Todos sabemos de 16 bits é nada hoje em dia. O que a Bitmover fez foi colocar um prazo de validade em seu produto. O detalhe é que ela avisou as pessoas de que esse prazo existia apenas quando o mesmo estava expirando, não quando começou o uso do mesmo. Como diria o provérbio: "Amigo amigos, negócios a parte".

Tomara que isso sirva de alerta aos projetos de software livre quanto ao uso de softwares proprietários, sem acesso ao código-fonte. Bitkeeper, Jira, e a lista continua a crescer. Uma hora, a empresa pode dar uma rasteira da qual pode ser difícil se levantar.

Por que não pagar: Se o Linus acha o bitkeeper tão bom, não seria de considerar pagar pelo programa?

Putz, enquanto é de graça ele usa, depois prefere criar outro a pagar pelo software?

Se está usando software proprietário então usa para valer e paga por ele. Tremendo pão-duro esse Linus.

Leandro

Bom questionamento, nem preci: Bom questionamento, nem precisava tirar do bolso dele, era só ele pedir que aposto que empresas patrocinariam isso. O problema é que o Linus queria uma desculpa para chamar atenção e aparecer um pouco mais, existem centenas de softwares para controle de versão, mas ele prefere criar o próprio. Muitos se adequam ao linux, ele mesmo falou de alguns, poderia ter pego o que ele gostou e criado um fork, mas ele quer a fama só para ele, tem que ser dele desde o início.

O problema não esta em ter q: O problema não esta em ter que pagar pelo BitKeeper, e sim que da forma que esta agora, continuando a usar o BitKeeper iria obrigar todos os desenvolvedores do kernel a comprar uma cópia do BitKeeper, o que não seria legal, apesar de que a maioria dos desenvolvedores do kernel serem patrocinados com uma empresa X ou Y que pagariam sem problema a licença.

Mesmo assim não sei pq fazer um novo programa de controle de versão já que existem muitos, free's e bons, por ai... desde o idoso CVS ao subversion.

--
"Precisamos de mais gênios humildes no mundo, hoje somos poucos!"
JID: hugo@jabber.org

O mundo é redondo: O engraçado disto tudo é que na época em que Linus decidiu usar o BitKeeper, houve um enorme protesto dos outros desenvolvedores. Lembro que muitas pessoas chamaram os que estavam protestando de xiitas, radicais e coisa e tal. Bem, e agora vejam no que deu.

Software fechado sempre usou esta tática de criar dependência e logo depois começar a explorar.

Porque não usam logo o subversion e põe um fim nesta novela. Afinal não é o próprio Linus que pregava o uso de medidas simples pra resolver os problemas?

Subversion não seria a escolha certa, segundo seus autores:

> Porque não usam logo o subversion e põem
> um fim nesta novela? Afinal não é o próprio Linus que pregava o
> uso de medidas simples pra resolver os problemas?

No texto "Please Stop Bugging Linus Torvalds About Subversion", os desenvolvedores do Subversion explicam a razão.

O quê ele fez foi só estuda: O quê ele fez foi só estudar o protocolo de comunicação ?

"Quebrar" protocolo de comunicação não é crime!!!

Se for crime, vão ter que processar o pessoal do SETI. Por que, até onde eu sei, eles não têm autorização dos alienigenas para "quebrar" e interpretar as comunicações deles.

Criar um soft que seja capaz de se comunicar com o bitkeeper também não me parece crime (desde que não tenham usado algum processo para ler o codigo original e fazer uma copia pura e simplesmente).

É a licença: Me parece que ninguém disse que é crime. O que o dono do BitKeeper diz é que houve uma violação da licença de uso do produto.

Para Linus o que vale é o mérito técnico...: Oi Pessoal,

Venho, pessoalmente, seguindo de perto a "saga" BitKeeper desde o início da sua utilização no desenvolvimento do Kernel e, sem de forma alguma querer sair em defesa do Linus, gostaria de mencionar que a escolha de tal sistema proprietário de gestão de código fonte se deu simplesmente devido à ausência de um similar de código aberto. Infelizmente, um software livre com tais características ainda inexiste até hoje, razão pela qual o próprio Linus resolveu criar o "git".

É óbvio que o Andrew Tridgell, sem ser usuário do BitKeeper, poderia fazer engenharia reversa dele. Mas o Larry McVoy acreditou que isso configurava uma quebra da licença da versão gratuita do programa e decidiu revogá-la, o que ele poderia ter feito a qualquer tempo, já que é de seu direito. A argumentação de McVoy, segundo Linus, é que, para ter acesso ao servidor BitKeeper, necessário para realizar a engenharia reversa do protocolo de comunicação que o programa usa, Tridgell precisaria ter tido também acesso a dados de algum dos desenvolvedores que já usam o BitKeeper no desenvolvimento do Kernel, e só a utilização de tais dados já configurariam quebra de licença.

Em miúdos: o que importa para o Linus não é necessariamente se um software é livre ou proprietário, mas o seu mérito técnico, as suas características funcionais. E, infelizmente, ainda não há similar livre ao BitKeeper em nossas lides. O Linus nunca fez segredo para ninguém que, se houvesse um similar livre que fizesse tudo que o BitKeeper é capaz de fazer, ele mudaria alegremente para essa opção. Aliás, para quem não sabe - e se não me falha a memória - o código fonte do BitKeeper chega a ser maior que o do próprio Linux.

A situação é complicada. Vamos ver como as coisas vão correr daqui pra frente. Recomendo a quem quiser ter uma opinião fundamentada a respeito do pensamento do Linus quanto ao caso, a ler pelo menos as suas respostas na longa "thread" disponível em:

http://www.realworldtech.com/forums/index.cfm?action=detail&PostNum=3322&Thread=2&entryID=49312&roomID=11

Abraços,

Rafael
--
Linux Magazine

Em defesa do Tridgell: sem de forma alguma querer sair em defesa do Linus, gostaria de mencionar que a escolha de tal sistema proprietário de gestão de código fonte se deu simplesmente devido à ausência de um similar de código aberto.

Rafael, nós não sabemos o quanto o bitkeeper fez de diferença em relação a outras ferramentas de controle de versão. O próprio Corben da lwn.net disse que o maior benefício do BitKeeper foi apenas fazer o Linus usar um sistema de controle de versões: antes do BK ele não aceitava usar nada - CVS, Subversion, GNU Arch ou o que fosse. Ou seja, as características técnicas do produto que o diferenciam dos outros parecem não ser tão significativas assim - e me parece que o fato de o Larry McVoy ser amigo pessoal do Linus o incentivou mais do que essas diferenças.

É óbvio que o Andrew Tridgell, sem ser usuário do BitKeeper, poderia fazer engenharia reversa dele. Mas o Larry McVoy acreditou que isso configurava uma quebra da licença da versão gratuita do programa e decidiu revogá-la, o que ele poderia ter feito a qualquer tempo, já que é de seu direito. A argumentação de McVoy, segundo Linus, é que, para ter acesso ao servidor BitKeeper, necessário para realizar a engenharia reversa do protocolo de comunicação que o programa usa, Tridgell precisaria ter tido também acesso a dados de algum dos desenvolvedores que já usam o BitKeeper no desenvolvimento do Kernel, e só a utilização de tais dados já configurariam quebra de licença.

Primeiro é que a própria legalidade da licença do McVoy é ambígua - pelo que sei mesmo nos Estados Unidos da DMCA ninguém pode restringir este tipo de engenharia reversa por uma licença e isso nunca passou na corte para ser testado. Segundo, como não houve nem mesmo uso do cliente bitkeeper, ele não pode inventar mil e uma indireções pra alegação da licença, é um absurdo. Então quer dizer que se eu descobrir a porta de um protocolo da empresa X que tem uma cláusula de proibição de engenharia reversa eu estou violando a cláusula? Terceiro, na discussão da slashdot isso também é colocado: o McVoy pode proteger por copyright o programa dele, mas os dados que ele produz não podem ser protegidos por copyright do detentor do controle de versão pois são produto do código-fonte de quem tem a licença de uso.

Em outras palavras: tudo bravata. Ou o Larry McVoy é muito burro pra realmente pensar isso ou ele está mentindo pra criar uma desculpa de fachada. Se existem outras situações possíveis pra explicar isso eu não as conheço.

Em miúdos: o que importa para o Linus não é necessariamente se um software é livre ou proprietário, mas o seu mérito técnico, as suas características funcionais.

Enorme engano. O lado político do software sempre existiu e, acredito, sempre existirá. Ele tomou uma decisão visivelmente errada - de usar o BitKeeper - e deu no que deu. Mesmo que tenha toda a excelência técnica, qualquer gerente de projeto competente veria que o BitKeeper não se encaixa no modelo de desenvolvimento open-source. Depois, claro, tinha que culpar alguém da equipe pelo desastre da decisão e o Tridgell foi o bode expiatório perfeito... típico dos gerentes. Pensei que o Linus fosse menos "pointy-haired boss".
--
Agora com o engine pronto, em fase BETA: http://linuxfud.org
LinuxFUD, mostrando as mentiras da mídia contra o software livre!

Mimo: qualquer gerente de projeto competente veria que o BitKeeper não se encaixa no modelo de desenvolvimento open-source.

Matou a pau, Patola!
Se ele não usava nenhum subversion da vida, qual seria a base de comparação com o Bitkeeper?

As vezes o Linus passa a impressão de menino mimado que dá aquelas birras memoráveis em supermercado. Ou você deixa-o esperneando e não dá bola ou você compra um pirulito e faz a vontade do pimpolho. Nesse mundo do Linus(x) parece que sempre dão o doce pra criança... :/

Alexandre de Arruda Paes

Eu li em algum lugar que o pr: Eu li em algum lugar que o problema com o subversion é que o Linus precisava de um software de gerenciamento des-centralizado com multiplos repositórios etc. O subversion oferece controle centralizado é essa a justificativa, tanto que agora sem o BK o linus e os manos estão de senvolvendo outra ferramenta que nada se parece com o subversion.
Não é birra do cara, realmente não existe similar ao BK no mundo opensource os prórios desenvolvedores do subversion admitem isso.

Dúvida...: Não estaria o próprio Linus "quebrando" a licença ao desenvolver o "git"? Já que quem usou o BK "grátis" não poderia participar de nenhum projeto de controle de versão por até um ano após seu uso?

E agora...?

Subversion não seria a escolha certa para o kernel: Confirmando o comentário do liquid slave, no texto "Please Stop Bugging Linus Torvalds About Subversion", os desenvolvedores do Subversion explicam a razão de sua ferramenta não se aplicar às necessidades do desenvolvimento do kernel Linux. O que aparentemente não invalida o argumento do Patola, mas é ao mesmo tempo um detalhe importante.

DMCA e licença:

>pelo que sei mesmo nos Estados Unidos da DMCA ninguém pode restringir este tipo de
>engenharia reversa por uma licença e isso nunca passou na corte para ser testado.

A licença de uso normalmente equivale a um contrato entre as partes, ela pode restringir o que as partes acordarem, talvez com exceção do que a lei expressamente diz que é permitido (e não daquilo que a lei não proíbe). Um tribunal poderia reverter algum termo da licença (se o que você disse sobre o DMCA tornar impossível restringir a reengenharia na licença estiver certo, por exemplo - e me parece que há situações em que a engenharia reversa não seria liberada pelo tribunal, mesmo pós-DMCA. Mas para efeito de argumento vou considerar que esta não é uma destas situações) se uma das partes decidisse solicitar isso, mas neste caso a possível parte interessada não solicitou, e o Tridgell não é parte neste acordo, ele agiu como um terceiro.

No caso específico da licença gratuita do BitKeeper, o que é restrito não é a só a engenharia reversa em si (que de fato é restrita pela licença, cláusula 4g), mas também (novamente neste caso específico) o uso do sistema por pessoas que desenvolvem ou trabalhem em organizações que desenvolvem ou estão envolvidos em produtos que a BitMover considere como competidores, ou que tenham as mesmas características do BitKeeper. Deve ser por isso que chegou a ser aventada (mas aparentemente nunca considerada a sério, ainda bem) a saída do Tridgell do OSDL - embora ele não estivesse criando seu cliente BitKeeper livre sob patrocínio do OSDL. Isto está na cláusula 4d, mas há ainda algumas outras cláusulas de restrições que merecem uma olhada com atenção.

Mas ainda que este contrato fosse ilegal, leonino ou pudesse ser invalidado ou renunciado pelos desenvolvedores de software livre, acredito que abandonar o BitKeeper neste momento e buscar outra ferramenta para a função antes desempenhada por ele é uma solução melhor, ainda que o processo de mudança possa ser conturbado.

Quando eu disse "subversions: Quando eu disse "subversions da vida", me referi a qualquer controlador de versões.

A pergunta é: se ele não havia tentado outras ferramentas, porque uma ferramenta proprietária e com licença estranha foi escolhida ?

Alexandre de Arruda Paes

Um ano após o uso: Acredito que a licença não exige este prazo de um ano (nem de uma semana, ou um dia). A cláusula 4d (que é a que impede o envolvimento em outros projetos) certamente não especifica nenhum prazo posterior à expiração da licença.

Hoje: Embora isso não mude muito na razão da discussão em si, é errado dizer que o Linus não havia testado outras ferramentas. Na época em que anunciou a adoção do BitKeeper, o próprio Torvalds declarou que tinha experiência com o CVS (no trabalho), e que havia considerado o subversion (sem sucesso) para a mesma tarefa a que aplicou o BitKeeper.

Após a confusão do Bitkeeper, buscou-se novamente uma ferramenta livre que pudesse cumprir o seu papel, e não se encontrou alguma que atendesse (o monotone parece ter os recursos, mas o desempenho foi descrito como 'glacial'). Imagino que há alguns anos, quando foi feita a escolha do BitKeeper, as opções livres estivessem ainda menos evoluídas no que diz respeito às necessidades específicas do desenvolvimento do kernel.

Essas restrições de licenç: Essas restrições de licença do BK ne lembra muito patentes de software. Estranho demais desenvolvedores de SL terem se submetido à isso.

Nada serve para tudo...: Eu não entendo como eles conseguem perder tempo com tanta bobagem. Se o proprietário do BitKeeper não quer mais deixar que usem seu produto gratuitamente, por que eles não pagam pelo produto? Se o BitKeeper é bom e consegue satisfazer as necessidades deles é simples: paguem pelo produto.

A OSDN é patrocinada por um consórcio de *grandes* empresas e acredito que hoje em dia dinheiro não seja problema para eles. Enquanto Linus critica Andrew Tridgel por ter feito engenharia reversa do protocolo do BitKeeper, xinga Andrea Arcangeli que sugere o uso do CVS ou SVN para a manutenção dos fontes do Kernel (ao invés de reinventar a roda, escrevendo o GIT) o Andrew Morton declara em uma palestra num evento na Austrália que a falta de testes (e de certa forma atenção) ameaça a estabilidade do kernel Linux.

Enquanto eles ficam discutindo o "sexo dos anjos" o tempo passa e os problemas começam a se tornar maiores. Quando será que esses caras vão aprender? +_+

Assim falou Bruce Perens: Os "Radicais", mais uma vez, tinham razão. Mestre Perens que o profira. No mundo filosófico/ecnômico/político/ideológico, os radicais, necessariamente, são livres...

Razão vs. Emoção: Certamente. O problema é que os radicais estão cada vez mais radicais e que graças ao ego e a falta de visão dessas pessoas muitas coisas importantes tem deixado de ser feitas. Com o tempo, pequenos seixos que existem no meio do caminho podem acabar por se tornarem montanhas instransponíveis. ;)

O problema é que sem os radi: O problema é que sem os radicais nada de importante sequer teria sido tentado.

Hmmm...: Discordo de você pequeno gafanhoto. Existe muitas pessoas por aí, que não são *nada* radicais e que fazem muita coisa. Radicais, em geral são barulhentos por natureza. A questão é como você definiria "tentar alguma coisa" na sentença "O problema é que sem os radicais nada de importante sequer teria sido tentado"?

Correção...: s/OSDN/OSDL/g

Re: Em defesa do Tridgell: Olá Patola,

Ótimo podermos discutir o tema em uma lista brasileira.

Rafael, nós não sabemos o quanto o bitkeeper fez de diferença em relação a outras ferramentas de controle de versão. O próprio Corben da lwn.net disse que o maior benefício do BitKeeper foi apenas fazer o Linus usar um sistema de controle de versões: antes do BK ele não aceitava usar nada - CVS, Subversion, GNU Arch ou o que fosse. Ou seja, as características técnicas do produto que o diferenciam dos outros parecem não ser tão significativas assim - e me parece que o fato de o Larry McVoy ser amigo pessoal do Linus o incentivou mais do que essas diferenças.

Primeiro, só para deixar claro, não estou defendendo nenhum dos dois lados. Segundo, não é verdade que o Linus não aceitava usar nenhum sistema de gestão de código fonte no passado. Aliás, ferramentas foram até mesmo criadas com propósitos similares (como o LXR, por exemplo). Repito, para o Linus o que vale é o mérito técnico. Ponto. E NÃO há uma ferramenta livre ATUALMENTE com o mesmo mérito técnico que o BitKeeper. Ponto. Já usei o CVS e o Subversion, além de ter testado o GnuArch e o Monotone. E nenhum deles entrega a mesma performance ou o conjunto de recursos que o BitKeeper. Fazer o quê. Temos que correr atrás do prejuízo e é o que o Linus está tentando fazer ao criar o "git".

Pergunta: você leu os textos do Linus que eu recomendei? Neles ele descreve uma por uma as razões de ter começado a usar o BitKeeper, quais os recursos que são necessários no âmbito do desenvolvimento do Kernel, quais são as suas características no que tange a desempenho etc. E, sinceramente, tudo me parece muito plausível. O único problema que vislumbro com a utilização do BitKeeper é que se corre o risco de acontecer o que está acontecendo agora: as portas serem fechadas. Além disso, sua utilização desestimula a produção de similar livre. O conflito atual está, entretanto, criando demanda para o desenvolvimento de uma alternativa livre, o que encaro de modo positivo.

Primeiro é que a própria legalidade da licença do McVoy é ambígua - pelo que sei mesmo nos Estados Unidos da DMCA ninguém pode restringir este tipo de engenharia reversa por uma licença e isso nunca passou na corte para ser testado. Segundo, como não houve nem mesmo uso do cliente bitkeeper, ele não pode inventar mil e uma indireções pra alegação da licença, é um absurdo. Então quer dizer que se eu descobrir a porta de um protocolo da empresa X que tem uma cláusula de proibição de engenharia reversa eu estou violando a cláusula? Terceiro, na discussão da slashdot isso também é colocado: o McVoy pode proteger por copyright o programa dele, mas os dados que ele produz não podem ser protegidos por copyright do detentor do controle de versão pois são produto do código-fonte de quem tem a licença de uso.

Primeiro: a GPL ainda também não foi testada em nenhuma corte norte-americana - ela só foi referendada atualmente em cortes na Europa, mormente na Alemanha. Segundo: licença de software é como tempero, cada um faz a sua. Se o software é proprietário, por mais absurda que seja a licença, eu posso revogá-la a qualquer instante. Simples assim. Posso conectar a disponibilidade do software para uso gratuito à influência dos ventos de monções na menstruação dos trogloditas azuis da Manchúria. Não está como eu quero? Licença revogada. Acordei de mau humor? Licença revogada. É meu direito revogar a licença se eu achar conveniente. O Larry McVoy sentiu um cheiro de que alguém estava andando fora daquilo que ele convencionou para disponibilizar o seu software gratuitamente e resolveu revogar a licença. Simples assim.

Sendo mais específico, ele convencionou em sua licença que a manipulação de metadados do BitKeeper para engenharia reversa era uma quebra de licença. Mas, lembremo-nos, ele não precisava de nenhum pretexto para revogar a licença. Mesmo porque o Andrew Tridgell alega não ter tido acesso aos metadados - coisa que o Linus contesta. Aí é que está o nó entre os dois!

Em miúdos: o que importa para o Linus não é necessariamente se um software é livre ou proprietário, mas o seu mérito técnico, as suas características funcionais.

Enorme engano. O lado político do software sempre existiu e, acredito, sempre existirá. Ele tomou uma decisão visivelmente errada - de usar o BitKeeper - e deu no que deu. Mesmo que tenha toda a excelência técnica, qualquer gerente de projeto competente veria que o BitKeeper não se encaixa no modelo de desenvolvimento open-source. Depois, claro, tinha que culpar alguém da equipe pelo desastre da decisão e o Tridgell foi o bode expiatório perfeito... típico dos gerentes. Pensei que o Linus fosse menos "pointy-haired boss".

É claro que existe um lado político no desenvolvimento de software, especialmente nos dias de hoje e em se tratando de software livre. Mas, de novo, para o Linus é o lado técnico que vale REALMENTE. Até hoje, para ele, só valeu isso e, apesar do McVoy ser amigo pessoal dele, não vejo uma mudança de paradigma da parte do Linus, que vai acabar, inclusive, "ferrando" o seu "amiguinho" com a criação do "git".

Adicionalmente, pode até ser que você tenha razão ao dizer que o BitKeeper tenha sido uma escolha errada para o projeto do Kernel. Eu não tenho como dizer - apesar de já ter usado a versão gratuita e de conhecê-la razoavelmente. Para mim, o maior problema foi a falta de uma alternativa melhor, pois TODAS AS OUTRAS, especialmente à época da introdução do BitKeeper, deixavam muito a desejar, infelizmente. Veja a seguinte frase de Linus, a respeito da velocidade do BitKeeper, por exemplo: "O BitKeeper é tão rápido que, se você estiver acostumado a usar o CVS e observar um usuário de BitKeeper trabalhando em um repositório grande, pode ser que você nem perceba o que está acontecendo, pois o BitKeeper faz em segundos o que você tende literalmente a preparar durante DIAS usando o CVS."

O Linus já testou o Monotone, e a velocidade do sistema, na opinião dele, foi "glacial". Assim ele partiu para fazer o próprio sistema de gestão de código fonte para o desenvolvimento do Kernel. Sabe o que eu acho que vai ocorrer? O "git" vai acabar se tornando um clone do BitKeeper no final das contas, e o McVoy vai ter dado um tiro no próprio pé ao revogar a licença gratuita do programa para o desenvolvimento do Kernel. Assim, vamos observar o que acontece. Para mim o grande problema é o McVoy: ele ficou realmente "P." da vida com a possibilidade de alguém estar usando engenharia reversa na sua "galinha dos ovos de ouro". Só que, quando o "git" começar a ficar funcional, o BitKeeper terá encontrado finalmente um concorrente sério e de código aberto no mercado de Sistemas Gestores de Código Fonte, e aí, meu amigo, acabou-se a mamata da BitMover (e, de quebra, talvez a amizade com o Linus ;-).

Abraços,

Rafael
--
Linux Magazine

Hum: OFF TOPIC/

Concordo com o gafanhoto.

Radical é quem busca a raiz de algo, busca um entendimento e comprometimento mais profundo com algo.

Visto desse modo, nada seria sequer tentado mesmo se não fossem pessoas "radicais", que meteram a cara mesmo nesse negócio de SL. Tudo começou com um ato de rebeldia. Se Linus e Stallman, só para citar os mais famosos, fossem acomodados, pense no que não teriamos hoje.

Mas os caras são rebeldes produtivos. Vc não vê os dois fazendo greve de fome contra o SP, ou ainda invadindo e quebrando a MS, ou o que seja. Pelo contrário.

O problema é que hoje em dia qualquer acéfalo é chamado de radical. Qualquer energúmeno é idolatrado. E a palavra "radical" virou sinônimo de algo irresponsável.

Pô, se não é radical criar o kernel e a GPL, então não sei o que é ser radical :-)

Eu acho que quem faz muita coisa por aí, quem afeta o seu campo de trabalho, quem produz algo novo, é radical sim. Radical no sentido puro, sem babaquices barulhentas e escandalosas.

Cara, se quiser ler sobre alguém realmente radical, procure sobre o Padre Landell de Moura. Outro revolucionário técnico.

Um abraço

Leandro

\OFF TOPIC

Já que tu falaste no Pe. Landell: Já que tu falaste no Pe. Landell, Leandro, oportuno demais concordar contigo; este sim, foi um radical. Muito do que sabemos hoje sobre radiotransmissão devemos a abnegados como ele. Pena que no meio do caminho havia uma Inquisição. Seria bom se as pessoas mais jovens soubessem quem foi este grande homem e como ele foi massacrado pela igreja. Ele foi, por assim dizer, o Giordano Bruno da eletrônica.
É por isso e por tantas outras coisas que penso ser graças a Radicais (estes sim, são eternamente livres) como o Pe. Landell, Bruce Perens, Galileu, Linus Torvalds, John Lennon, Martin Luther King e tais outros grandes homens que saímos (não totalmente!) da idade média.
"...Mas ela (a terra) é redonda!".

Uma vez, acho que no ano de 9: Uma vez, acho que no ano de 98 ou 99, eu estava lendo aquela revista Seleções Reader's Digest da minha vó (revista de velho), e aquela edição estampava o Linus Torvalds e o Tux na capa. Eu já conhecia o Linux e sua história, mas lendo a entrevista eu achei interessante quando o Linus falou algo mais ou menos assim, frente à sua insatisfação com o Minix: "Eu sabia que eu era o melhor programador do mundo e podia criar um SO melhor."
Pô, o cara teve a manha, a competência de criar um sistema operacional duca como o Linux... não tenho dúvida de que o git vá deixar o BitKeeper no chinelo, e com muitas linhas de código a menos. Não duvidem, porque ele pode, hehe!
Hail to the Linus!

O Linus agiu errado; funcionar pura e simplesmente não existe.: Primeiro, só para deixar claro, não estou defendendo nenhum dos dois lados.

Mas parece que você está considerando legítima a achincalhada que o Linus deu no Tridgell, quando a culpa, pra começar, foi da decisão errada que ele mesmo cometeu.

Segundo, não é verdade que o Linus não aceitava usar nenhum sistema de gestão de código fonte no passado. Aliás, ferramentas foram até mesmo criadas com propósitos similares (como o LXR, por exemplo).

O LXR é um índice de referência cruzada, já usei ele em um bugzilla que implantei no trabalho e não vejo realmente muita relação com fazer um sistema de controle de versões.

Repito, para o Linus o que vale é o mérito técnico. Ponto. E NÃO há uma ferramenta livre ATUALMENTE com o mesmo mérito técnico que o BitKeeper. Ponto. Já usei o CVS e o Subversion, além de ter testado o GnuArch e o Monotone. E nenhum deles entrega a mesma performance ou o conjunto de recursos que o BitKeeper. Fazer o quê. Temos que correr atrás do prejuízo e é o que o Linus está tentando fazer ao criar o "git".

Desculpe, Rafael, mas você percebe que ao frisar essa parte você está batendo o martelo num dos maiores mitos do software proprietário contra o software livre? Pra começar, isso faz parecer que o Software Livre "não funciona" ou é realmente inviável para ser utilizado. Será que é mesmo? Conheço muita gente que mesmo sabendo que o LaTeX é mais produtivo para fazer uma tese de mestrado - o tempo que você leva pra aprender o comando mais o tempo que você leva pra escrever um documento em LaTeX ainda é menor que o tempo para escrever o mesmo documento, que geralmente sai pior, em um programa como o Word (estou falando de experiência, não tenho estatísticas para demonstrar isso) - vai preferir utilizar o Word apenas por achar que é a maneira "certa" de funcionar. Do mesmo jeito, será que o GNU Arch ou outros sistemas distribuídos colocariam um ônus tão grande ao kernel?

Não quero dizer com isso que estou realmente contestando a decisão "técnica" do Linus de que "O Bitkeeper" fosse o melhor, e sim a conclusão secundária de que os outros são inviáveis (por isso a comparação com o LaTeX - muita gente o considera "inviável"). Por comentários no slashdot e em fóruns técnicos sobre GNU Arch e Bitkeeper, me pareceu que bem-configurado o Arch poderia fazer este papel, quer dizer, funcionaria.

Agora, sobre escolher o BitKeeper: fica tão difícil perceber uma coisa? A decisão NÃO PODIA SER só do Linus. Não é só ele que programa o kernel. Ele SABE que existem muitos colaboradores que se importam mais com a "ideologia de ser livre" do que ele. Foi burrice ou má-vontade, pra dizer o mínimo, agir assim - tomar uma decisão tão unilateral, tão ligada a uma amizade que ele tem com um sujeito (o McVoy) - e não escutar os que eram contra.

Sem contar que foi assinar um contrato com o Diabo! Ele viu as cláusulas draconianas da licença e mesmo assim as aceitou. Passando por todos os que não queriam. Deixe eu ilustrar a situação: você quer pregar um prego na parede. Você pode usar seu alicate que é bem pesadinho e apesar de não ser feito pra isso, serve, ou você pode comprar um martelo do sujeito que está te oferecendo. Com o martelo, você pode pregar com menos riscos, mas tem um problema: o sujeito que te vende o martelo diz que você não pode mais usar alicates e além disso tem que matar toda a sua família como condição pra usá-lo. Ok, o que importa é funciona, então você mata sua família, joga o alicate no lixo e usa o prego no martelo. A QUE CUSTO?

Questões técnicas TÊM QUE ENVOLVER CUSTO! O custo da licença, das conseqüências dela, os custos políticos, toda essa coisa. E você tem que assumir o que você não pode controlar: o Linus NÃO TEM CONTROLE sobre o que as pessoas fazem à revelia do kernel. Foi o Andrew Tridgell quem fez a engenharia reversa, mas poderia ter sido qualquer outro; mas o Andrew Tridgell, por ser celebridade do software livre, foi o bode expiatório ideal. O Linus jogou toda a culpa nele, quando a culpa era do próprio Linus em ter escolhido aquela licença ridícula em primeiro lugar. Justamente, o McVoy podia cessar a licença de uso a qualquer momento, e cessou no pior deles. Culpa do Linus, que a aceitou em primeiro lugar.

Pergunta: você leu os textos do Linus que eu recomendei? Neles ele descreve uma por uma as razões de ter começado a usar o BitKeeper, quais os recursos que são necessários no âmbito do desenvolvimento do Kernel, quais são as suas características no que tange a desempenho etc.

Li um pouco em casa, sim. Não entendi muito bem, no entanto, e não pude embrenhar mais a fundo - outros projetos e coisas pessoais. Mas com o que eu disse anteriormente, fica mais ou menos explícito o que eu quis dizer.

Primeiro: a GPL ainda também não foi testada em nenhuma corte norte-americana - ela só foi referendada atualmente em cortes na Europa, mormente na Alemanha.

Em um artigo recente, acho que saiu aqui na br-linux, uma reportagem falando sobre a SCO diz que como conseqüência ela acabou ratificando a GPL nos tribunais, depois de ter falado que a licença era inválida e ter voltado atrás. Não sou um advogado, no entanto, muito menos tão informado do conjunto de leis bizarras dos EUA, apesar de estar tentando me informar sobre isso lendo alguns livros.

Segundo: licença de software é como tempero, cada um faz a sua. Se o software é proprietário, por mais absurda que seja a licença, eu posso revogá-la a qualquer instante. Simples assim. Posso conectar a disponibilidade do software para uso gratuito à influência dos ventos de monções na menstruação dos trogloditas azuis da Manchúria. Não está como eu quero? Licença revogada. Acordei de mau humor? Licença revogada. É meu direito revogar a licença se eu achar conveniente. O Larry McVoy sentiu um cheiro de que alguém estava andando fora daquilo que ele convencionou para disponibilizar o seu software gratuitamente e resolveu revogar a licença. Simples assim.

Licenças, como contratos, têm limites para o que podem exigir. Por exemplo, você não pode criar uma licença que exija que o licenciado mate a família pra usar o produto.

Mais ainda: vamos falar do Samba? Ele é um claro exemplo disso: os protocolos que ele fez por engenharia reversa têm até mesmo patentes protegendo - e a Microsoft não é nem um pouquinho boazinha, mas o Samba está lá, funcionando com eles. Por que ela não revogou a licença de ninguém por isso? Nas EULAs da Microsoft existem as cláusulas de não poder haver engenharia reversa. Isso dá a ela o direito de revogar as licenças e ela não faz porque é boazinha?

Vamos lá, abra os olhos. Veja um pouco melhor o que aconteceu e pare de dar razão a uma pessoa que teve atitude tão cretina quanto o McVoy. Não adianta dizer que o demônio está certo porque ele tem que inspirar a maldade nas pessoas, isso é ruim do mesmo jeito.

É claro que existe um lado político no desenvolvimento de software, especialmente nos dias de hoje e em se tratando de software livre. Mas, de novo, para o Linus é o lado técnico que vale REALMENTE. Até hoje, para ele, só valeu isso e, apesar do McVoy ser amigo pessoal dele, não vejo uma mudança de paradigma da parte do Linus, que vai acabar, inclusive, "ferrando" o seu "amiguinho" com a criação do "git".

Isso se o "amiguinho" dele não ferrar o Linus primeiro dizendo que ele já trabalhava no git mesmo antes de parar de usar o BitKeeper (que provavelmente é verdadeiro). Afinal, a licença do BitKeeper impedia isso, não?

Quanto ao "apenas funcionar", não existe tal sandice. Ninguém mata a família só pra martelar um prego, como no exemplo (exagerado, claro) dado em cima. As poucas pessoas que agem assim, de modo automático e desligado do mundo, que matariam a família pra martelar um prego, têm uma doença chamada autismo.

Ah, sim! Quando você defender o software livre, como você vai responder a uma pessoa que quer continuar usando Windows porque "apenas funciona"? Você vai ter que explicar a visão equivocada de uma visão de curto prazo falando os benefícios da mudança, ou então... engolir em seco pois é um bordão que, apesar de colocar nas palavras do Linus, você está assumindo!
--
Agora com o engine pronto, em fase BETA: http://linuxfud.org
LinuxFUD, mostrando as mentiras da mídia contra o software livre!

kernel de hoje: "..achei interessante quando o Linus falou algo mais ou menos assim, frente à sua insatisfação com o Minix: "Eu sabia que eu era o melhor programador do mundo e podia criar um SO melhor."
Pô, o cara teve a manha, a competência de criar um sistema operacional duca como o Linux... não tenho dúvida de que o git vá deixar o BitKeeper no chinelo, e com muitas linhas de código a menos. Não duvidem, porque ele pode, hehe!"

Existe "um abismo" de diferença (e pessoas) entre o primeiro e o último release do kernel linux.

Sim, e isso tira o mérito do: Sim, e isso tira o mérito do cara? IMHO, Acho que não.

Re: O Linus agiu errado; funcionar pura e simplesmente não exis: Oi Patola,

Vamos, em primeiro lugar, analisar a frase no título da sua resposta:

O Linus agiu errado; funcionar pura e simplesmente não existe.

Primeiro, não posso dizer que o Linus agiu errado: a escolha que ele fez refletiu as necessidades para o projeto do Kernel à época em que o SCMS (Source Code Management System) foi implantado. Segundo, se uma coisa funciona, ela funciona e ponto. Agora, no caso do BitKeeper, ela não só funcionava, mas funcionava melhor que todas as outras alternativas disponíveis...

O LXR é um índice de referência cruzada, já usei ele em um bugzilla que implantei no trabalho e não vejo realmente muita relação com fazer um sistema de controle de versões.

Eu sei, eu sei. Só estava explicando que outras ferramentas foram criadas para dar apoio ao desenvolvimento do Kernel, e com o beneplácito do Linus. Só estava contra-argumentando com um exemplo o seu argumento de que o Linus não aceitara ferramentas de controle de versão no desenvolvimento do Kernel. Ele não só aceitava como até mesmo estimulou a criação de ferramentas variadas.

Desculpe, Rafael, mas você percebe que ao frisar essa parte você está batendo o martelo num dos maiores mitos do software proprietário contra o software livre? Pra começar, isso faz parecer que o Software Livre "não funciona" ou é realmente inviável para ser utilizado. Será que é mesmo? Será que é mesmo? Conheço muita gente que mesmo sabendo que o LaTeX é mais produtivo para fazer uma tese de mestrado - o tempo que você leva pra aprender o comando mais o tempo que você leva pra escrever um documento em LaTeX ainda é menor que o tempo para escrever o mesmo documento, que geralmente sai pior, em um programa como o Word (estou falando de experiência, não tenho estatísticas para demonstrar isso) - vai preferir utilizar o Word apenas por achar que é a maneira "certa" de funcionar. Do mesmo jeito, será que o GNU Arch ou outros sistemas distribuídos colocariam um ônus tão grande ao kernel?

E você não percebe, Patola, que essa história de uma solução qualquer apenas "funcionar" não basta para que ela seja a melhor solução para um determinado problema? E que esse é, hoje, um dos maiores problemas para a adoção do Software Livre de maneira mais ampla?

Para ser adotado com sucesso, não basta ao Software Livre somente "funcionar". Isso é muito pouco! Especialmente se for necessário ao usuário mudar do software (proprietário) ao qual estava acostumado para a alternativa de código aberto. O que vale são as características técnicas e funcionais do software. Aliás, é por isso que o Linux faz tanto sucesso: por causa das suas características técnicas, que vêm de encontro com as necessidades de um sem-número de usuários e projetos. Não basta o software ser livre para ser melhor: o software tem que funcionar melhor que suas contrapartes proprietárias e trazer o conjunto de recursos que atenda à necessidade do usuário. O fato de ele trazer independência tecnológica para quem usa é, a curto prazo, secundário. Infelizmente, há muito Software Livre mal feito por aí, da mesma forma que há software proprietário de excelente qualidade.

A grande vantagem do Software Livre, que, entretanto, aparece mais a médio prazo, está no seu modelo de desenvolvimento. É aí que o Software Livre traz vantagens e, de modo geral, se destaca, porque apresenta:

• Tempo de desenvolvimento mais curto


• Custos de desenvolvimento mais baixos


• Acesso a um time de desenvolvimento global


• Rápida integração de novas tecnologias


• Marketing


• Auditabilidade

Isso gera para o usuário, a médio prazo:

• Competição


• Inovação mais rápida


• Custos mais baixos


• Soluções mais flexíveis


• Controle e independência


• Estabilidade e segurança

Mas para chegar a tudo isso, o Software Livre precisa SER TECNICAMENTE SUPERIOR.

Não quero dizer com isso que estou realmente contestando a decisão "técnica" do Linus de que "O Bitkeeper" fosse o melhor, e sim a conclusão secundária de que os outros são inviáveis (por isso a comparação com o LaTeX - muita gente o considera "inviável"). Por comentários no slashdot e em fóruns técnicos sobre GNU Arch e Bitkeeper, me pareceu que bem-configurado o Arch poderia fazer este papel, quer dizer, funcionaria.

O GNU Arch poderia "funcionar", realmente. Só que não com o mesmo desempenho e a mesma gama de recursos do BitKeeper - pelo menos não à época em que o BitKeeper foi adotado. Seria uma solução para o SCMS do Kernel, do ponto de vista técnico. Mas será que seria a melhor solução? Aquela que iria acelerar o desenvolvimento do sistema e aumentar a sua qualidade? Não posso responder a isso. O que posso dizer é que, com o BitKeeper, essa melhora ocorreu. E, antes que eu me esqueça, o "git" está sendo desenvolvido pelo Linus, sob a GPL, porque as outras soluções existentes hoje ainda não foram capazes de suprir as necessidades de um SCMS para o desenvolvimento do Kernel.

Agora, sobre escolher o BitKeeper: fica tão difícil perceber uma coisa? A decisão NÃO PODIA SER só do Linus. Não é só ele que programa o kernel. Ele SABE que existem muitos colaboradores que se importam mais com a "ideologia de ser livre" do que ele. Foi burrice ou má-vontade, pra dizer o mínimo, agir assim - tomar uma decisão tão unilateral, tão ligada a uma amizade que ele tem com um sujeito (o McVoy) - e não escutar os que eram contra.

Permita-me discordar. Aliás, permita também ao Andrew Tridgell discordar:

"I would like to point out the obvious fact that Linus was perfectly within his rights to choose bk for the kernel. I personally would not have chosen it, but it was his choice to make, not anyone elses."

Em bom português (tradução livre):

"Eu gostaria de ressaltar o fato óbvio de que Linus tinha todo o direito de escolher o BitKeeper para gerenciar o desenvolvimento do Kernel. Eu, pessoalmente, não o teria escolhido, mas a escolha era prerrogativa dele e de ninguém mais."

Linus é o líder do projeto de desenvolvimento do Kernel. Ele está nessa posição por méritos técnicos. Qualquer um que quiser criar um outro projeto a partir do kernel HOJE pode fazê-lo tranqüilamente. Por que será que isso não acontece? Aconteceu com o FreeBSD (vide o fork do projeto DragonFly). Aconteceu com o NetBSD (vide o fork OpenBSD). É prerrogativa dele determinar o que é melhor para o projeto. E ele o fez de um modo que não impactou de modo algum no modo de trabalho daqueles que não queriam trabalhar com o BitKeeper. Quem quisesse usar o programa, poderia fazê-lo. Quem não quisesse, não precisava usar. Entretanto, o desempenho do Linus cresceu sensivelmente com o uso do programa, de modo que ele conseguiu aplicar mais "patches" de maneira mais eficiente e acelerar o trabalho de desenvolvimento do Kernel, o que foi bom para todo mundo.

E, de mais a mais, se o BitKeeper estivesse incomodando tanto, qualquer um poderia ter escrito um clone a qualquer momento. O próprio Linus afirmou que não hesitaria em adotá-lo NA HORA, mesmo que a alternativa não fosse tão boa quanto o BitKeeper! Leia abaixo:

"Tridge [sic] could have done something constructive: he could have written the best damn SCM on the planet, and believed that open source generates better things, and competed against BitKeeper that way.

He'd have been a hero to me. It's unquestionably true that BitKeeper has advanced the state of SCM technology. Anybody who argues against that just doesn't know what the hell he is talking about. But I'd have loved even an "almost-as-good" open source SCM, because that would obviously just be a good idea."

Me dou ao trabalho de traduzir:

"Tridge [sic] poderia ter feito algo construtivo: ele poderia ter escrito o melhor sistema de gerenciamento de código fonte (SCMS) do planeta e acreditado que o Software Livre cria coisas melhores e competido contra o BitKeeper dessa forma.

Ele teria sido o meu herói. É inquestionável que o BitKeeper contribuiu para o avanço da tecnologia SCM. Qualquer um que diga o contrário não tem a mínima noção do que está falando. Mas eu teria adorado até mesmo um SCMS de código aberto quase tão bom quanto o BitKeeper, porque isso seria obviamente mais que uma boa idéia."

Sem contar que foi assinar um contrato com o Diabo! Ele viu as cláusulas draconianas da licença e mesmo assim as aceitou. Passando por todos os que não queriam. Deixe eu ilustrar a situação: você quer pregar um prego na parede. Você pode usar seu alicate que é bem pesadinho e apesar de não ser feito pra isso, serve, ou você pode comprar um martelo do sujeito que está te oferecendo. Com o martelo, você pode pregar com menos riscos, mas tem um problema: o sujeito que te vende o martelo diz que você não pode mais usar alicates e além disso tem que matar toda a sua família como condição pra usá-lo. Ok, o que importa é funciona, então você mata sua família, joga o alicate no lixo e usa o prego no martelo. A QUE CUSTO?

He! He! He! Adoro quando a coisa fica emocional... Vamos lá:

1. O Linus não obrigou ninguém a usar o BitKeeper.


2. Usar o sistema era opcional. Isso não influia de modo algum no modo de trabalho dos desenvolvedores que NÃO usassem o BitKeeper. Andrea Arcangeli, Daniel Phillips e muitos outros nunca usaram, pois eram pessoalmente contra.


3. O trabalho de desenvolvimento do Kernel foi acelerado.


4. Agora, na falta do BitKeeper, o Linus desenvolveu o "git", que, usando a sua analogia, ainda é um alicate, mas está se desenvolvendo a passos largos e vai se tornar um belo martelo de uso livre. Esse martelo vai bater de frente com um outro martelo proprietário de um certo Larry McVoy! É por essas e outras que eu adoro Software Livre!


5. O uso do martelo proprietário não levou à morte de nenhum membro das famílias dos desenvolvedores desde a sua adoção no curso do desenvolvimento do Linux... ;-)

Questões técnicas TÊM QUE ENVOLVER CUSTO! O custo da licença, das conseqüências dela, os custos políticos, toda essa coisa. E você tem que assumir o que você não pode controlar: o Linus NÃO TEM CONTROLE sobre o que as pessoas fazem à revelia do kernel. Foi o Andrew Tridgell quem fez a engenharia reversa, mas poderia ter sido qualquer outro; mas o Andrew Tridgell, por ser celebridade do software livre, foi o bode expiatório ideal. O Linus jogou toda a culpa nele, quando a culpa era do próprio Linus em ter escolhido aquela licença ridícula em primeiro lugar. Justamente, o McVoy podia cessar a licença de uso a qualquer momento, e cessou no pior deles. Culpa do Linus, que a aceitou em primeiro lugar.

O Linus tinha todo o direito de escolher o que julgasse ser a melhor opção para o desenvolvimento do Kernel, que, afinal, é o projeto que ele dirige. Ele só ficou chateado com o Tridgell porque não havia uma opção ao BitKeeper (e, efetivamente, não há AINDA HOJE uma opção para ele) e, a atitude do Tridgell levou ao cancelamento da licença do software que ele, Linus, estava usando - e sendo muito produtivo devido a esse uso, diga-se de passagem. Linus não encara Software Livre como religião. Ele é pragmático. Eu, pessoalmente, TAMBÉM NÃO TERIA ESCOLHIDO o BitKeeper para gerenciar meu projeto de Software Livre. O problema é que era necessário um sistema descentralizado de gerenciamento de código fonte para o Kernel. Se eu precisasse de um sistema desses, provavelmente iria acabar escolhendo uma das alternativas livres disponíveis (provavelmente o monotone). O problema é que o código fonte do Linux é imenso, e qualquer um dos projetos de SCM livres atuais não dão efetivamente conta do recado.

Outra coisa: te dou inteira razão quando você fala que a culpa é do Linus pelo que está acontecendo hoje. O caso inteiro era uma bomba relógio, programada para pipocar a qualquer hora. Mas também é "culpa" dele o desenvolvimento do kernel ter se tornado mais estruturado e organizado, estar recebendo cerca de 3 vezes mais contribuições por dia do que antes, ser passível de controle de qualidade apurado, e, uma das coisas mais importantes, poder ser auditado quanto à origem de patches - coisa muito importante depois que a SCO/Caldera começou a criar caso com a IBM...

Licenças, como contratos, têm limites para o que podem exigir. Por exemplo, você não pode criar uma licença que exija que o licenciado mate a família pra usar o produto.

Óbvio. Eu estava usando de uma dose de humor no meu comentário anterior. De qualquer modo, o espírito do que eu quis dizer brincando ainda se aplica: dentro das limitações impostas pela lei, eu posso exigir qualquer coisa em uma licença de uso de software - e revogá-la quando alguma cláusula da licença for quebrada. Uma licença é um contrato entre partes, que pode ser revogado a qualquer momento. O Larry McVoy achou que era o momento. Efeito borboleta: a revogação da licença terá como resultado um furacão de origem finlandesa, que vai provavelmente doer no bolso dele a médio prazo. É bom ele se preparar.

Mais ainda: vamos falar do Samba? Ele é um claro exemplo disso: os protocolos que ele fez por engenharia reversa têm até mesmo patentes protegendo - e a Microsoft não é nem um pouquinho boazinha, mas o Samba está lá, funcionando com eles. Por que ela não revogou a licença de ninguém por isso? Nas EULAs da Microsoft existem as cláusulas de não poder haver engenharia reversa. Isso dá a ela o direito de revogar as licenças e ela não faz porque é boazinha?

A Microsoft não é boazinha. Ela só não é (muito) burra. Uma das PROIBIÇÕES impostas pelo conhecido caso antitruste do Departamento de Justiça contra a Microsoft é não interferir em sistemas que promovam a interoperabilidade, caso do Samba. De acordo com o "Sherman Act", que eles têm que seguir desde que foram declarados como monopólio pela corte norte-americana, isso seria especificamente ilegal. De acordo com a lei, a Microsoft não pode bloquear interoperabilidade.

Vamos lá, abra os olhos. Veja um pouco melhor o que aconteceu e pare de dar razão a uma pessoa que teve atitude tão cretina quanto o McVoy. Não adianta dizer que o demônio está certo porque ele tem que inspirar a maldade nas pessoas, isso é ruim do mesmo jeito.

Não sei se entendi bem. Você acha que eu estou dando razão para o McVoy? Eu só acho que ele está no seu direito divino de proteger o seu produto. De outro lado, acho que ele está sendo estúpido em matar o seu "Ganso dos Ovos de Ouro", uma vez que é sabido que o BitKeeper nunca seria tão conhecido se ele não estivesse sendo usado no desenvolvimento do Kernel. Se você estiver querendo dizer que eu estou dando razão ao Linus, bem, tudo o que ele disse nos textos que eu mencionei me pareceu bem plausível. Eu só acho que ele deveria esclarecer bem as coisas com o Tridgell - o que eu acho que inevitavelmente acontecerá, pois ele acredita (ou acreditava) que o Tridgell havia feito a engenharia reversa dos protocolos do BitKeeper usando os metadados de algum desenvolvedor do Kernel que usava o programa - o que não é o caso, de acordo com o Tridgell. É nisso que o Linus está, a meu ver, pecando. É nisso que eles precisam se entender.

Isso se o "amiguinho" dele não ferrar o Linus primeiro dizendo que ele já trabalhava no git mesmo antes de parar de usar o BitKeeper (que provavelmente é verdadeiro). Afinal, a licença do BitKeeper impedia isso, não?

Pelo que sei, o "git" começou a ser desenvolvido depois. Aliás, por conta da amizade entre o Linus e o McVoy, que todo mundo não cansa de dizer serem como de dois irmãos (será que é assim mesmo?), acho difícil que o Linus tenha tomado pessoalmente qualquer iniciativa para trocar o BitKeeper antes do problema atual. Não me parece razoável, pelo menos...

Ah, sim! Quando você defender o software livre, como você vai responder a uma pessoa que quer continuar usando Windows porque "apenas funciona"? Você vai ter que explicar a visão equivocada de uma visão de curto prazo falando os benefícios da mudança, ou então... engolir em seco pois é um bordão que, apesar de colocar nas palavras do Linus, você está assumindo!

Sofismo, meu amigo. Isso que você está usando tem esse nome. "Apenas funciona" nunca foi e nem é a minha divisa. Se fosse, eu estaria usando SunOS até hoje, que foi o meu primeiro Unix em 1991 - eu usei o SOX, da Cobra em 1987/1988, mas isso é outra história. Não basta funcionar - TEM QUE FUNCIONAR MELHOR. Por isso uso Linux (OpenBSD e, de vez em quando, Mac OS X). E é esse o caso do BitKeeper e a razão de o Linus ter fincado o pé em usá-lo: ele é, até hoje, tecnicamente superior a todas as outras opções livres disponíveis. Mas eu confio que a comunidade vai desenvolver uma solução ainda melhor, agora que há demanda para isso. Afinal, essa é a etiologia de qualquer bom programa de código aberto (bem sucedido): a necessidade de uma solução para um problema específico, que conduz à criação do software.

Grande abraço,

Rafael
--
Linux Magazine

Respondeu na hora do almoço! =P: Nem sei se vou ter condições de responder a essa mensagem, mas só para destacar algumas que julgo terem sido equívocos de significado:

"Eu gostaria de ressaltar o fato óbvio de que Linus tinha todo o direito de escolher o BitKeeper para gerenciar o desenvolvimento do Kernel. Eu, pessoalmente, não o teria escolhido, mas a escolha era prerrogativa dele e de ninguém mais."

Quando eu disse que o Linus NÃO PODIA ter escolhido, não quis dizer que ele não tinha direito; e sim que foi uma afronta imensa. Eu li, sim, tanto os comentários do Tridgell quanto do Linus sobre o assunto.

...como você vai responder a uma pessoa que quer continuar usando Windows porque "apenas funciona"?...

Sofismo, meu amigo. Isso que você está usando tem esse nome. "Apenas funciona" nunca foi e nem é a minha divisa. Se fosse, eu estaria usando SunOS até hoje, que foi o meu primeiro Unix em 1991 - eu usei o SOX, da Cobra em 1987/1988, mas isso é outra história. Não basta funcionar - TEM QUE FUNCIONAR MELHOR...

Deixe eu tentar reformular a minha frase: como você vai responder a uma pessoa que quer continuar usando Windows porque, por bugado, controlado e fechado que seja, atende a seus propósitos de produtividade?

O "apenas funciona" ficou, como se vê pela sua compreensão, parecendo como se funcionasse parcamente, quando o que eu quis passar não era carência de recursos e sim que atende aos requisitos.

Por outro lado, sua resposta também mostrou que, se formos te impingir uma "orientação ideológica", você seria claramente um proponente do "open-source", enquanto eu, por não poder deixar de lado o aspecto de liberdade (a ponto de em muitos contextos desprezar a eficiência) me categorizaria mais posicionado como proponente do "software livre". Para mim, mesmo que uma ferramenta livre não seja a melhor, mais eficiente, é justificado utilizá-la no lugar de um software proprietário melhor - respeitados alguns limites, claro. Mas eu tornaria isso duplamente importante em um caso público como o kernel, pois o uso do BitKeeper ainda por cima gerou uma imensa propaganda política a favor do software proprietário (como bem ressaltado no comentário do Richard Stallman).

Bom, clareados esses pontos, vamos apenas a mais dois comentários sobre frases suas:

E, de mais a mais, se o BitKeeper estivesse incomodando tanto, qualquer um poderia ter escrito um clone a qualquer momento. O próprio Linus afirmou que não hesitaria em adotá-lo NA HORA, mesmo que a alternativa não fosse tão boa quanto o BitKeeper! Leia abaixo:

Na frase do Linus não ficou claro que a alternativa podia não ser tão boa quanto o Bitkeeper. =) Mas com aquela licença, como é que as pessoas poderiam construir algo pra competir? Se até uma mísera captura dos metadados, protegida pelo copyright do detentor deles (que não é a BitMover), foi considerada violação da licença?

Pelo que sei, o "git" começou a ser desenvolvido depois. Aliás, por conta da amizade entre o Linus e o McVoy, que todo mundo não cansa de dizer serem como de dois irmãos (será que é assim mesmo?), acho difícil que o Linus tenha tomado pessoalmente qualquer iniciativa para trocar o BitKeeper antes do problema atual. Não me parece razoável, pelo menos...

Tão irmãos que o McVoy não se incomodou em fazer a licença leonina em primeiro lugar e depois de puxar o tapete do Linus cessando a versão grátis, não é? Como diria o ditado: "amigos, amigos, negócios à parte..."
--
Agora com o engine pronto, em fase BETA: http://linuxfud.org
LinuxFUD, mostrando as mentiras da mídia contra o software livre!