Open Voices part I: tradução

Tradução do conteúdo da transcrição do podcast "Open Voices: The Linux Foundation Podcast", publicado em http://linux-foundation.org/weblogs/openvoices/linus-torvalds-part-i/ em 7 de Janeiro de 2008. Procurei manter a idéia original, mesmo que existam erros por parte do Linus ou do Jim.



LINUS TORVALDS - PARTE 1

7/JANEIRO/2008

Nota do tradutor: JZ = Jim Zemlin, LT = Linus Torvalds, V2/V3 = GPLv2/GPLv3

JZ: Então, eu queria começar te fazendo a primeira pergunta. Como é a sensação de fazer parte da Linux Foundation?

LT: Pra mim, o que eu tenho feito pelos últimos 4 anos tem sido basicamente trabalhar no Linux o tempo todo. Antes disso eu sempre tive - eu tive um tal emprego que sustentava a mim e a minha família e então o Linux era como um hobby e, embora meus patrões conhecessem o Linux e dessem suporte para ele, mas não era meu emprego oficial.

Então, há cerca de 4 anos atrás eu basicamente disse que eu precisava fazer isso em tempo integral e eu estava pronto para me dedicar sozinho e dar uma largada da Transmeta e, no entanto, achei essa empresa que estava disposta a me sustentar fazendo o que eu precisava fazer, de certa forma.

Então, até onde eu me preocupo, a Linux Foundation é meu jeito de não ter que me preocupar sobre todos os detalhes quanto a sustentar minha família e fazer o que eu queria e o que eu precisava.

JZ: Que bom. O que te motiva a trabalhar no Linux?

LT: Bem, era que a tecnologia era exatamente - Eu estava interessado apenas em como o hardware funcionava e as interações entre hardware e software, e isso ainda faz parte, mas em grande parte agora é só o lado social.

Então, é bem divertido trabalhar com pessoas; apesar de, digo, eu sentar no meu escritório o dia todo e na verdade não me encontrar com ninguém, mas o que eu faço é essencialmente comunicar-me, e é bastante social: ler e-mails, responder, dizer a eles que eles estão sendo duros. Embora eu não faça isso - Eu apenas digo de uma forma educada ou que eles estão fazendo um bom trabalho e tentando empurrar pessoas para o caminho certo.

JZ: É dito que você sempre disse, "Linux é apenas diversão", e isso é o que te motiva a fazer isso.

LT: Certo.

JZ: Você vê o Linux, ou o desenvolvimento do Linux, como parte de uma causa maior?

LT: Não. Não, ao menos pra mim não; digo, para outras pessoas é. Digo, na verdade uma das coisas que eu acho interessante é o jeito em que algumas pessoas usam o Linux de formas que eu não planejei, e às vezes usam para coisas que eu realmente não tenho muito interesse.

E todo o uso onde pessoas usam o Linux em países de 3° mundo e ajuda humanitária, algumas pessoas pensam que foi por isso que eu comecei e não, não foi por isso que eu comecei e o crédito deveria ir para projetos como o OLPC que usam o Linux para tentar melhorar a imagem do mundo.

Pra mim tem sido - Eu acho que é bem interessante e, digo, quando eu digo que é - o que me move, o que me motiva é a parte da diversão, digo, parte da diversão é que deve ser difícil o suficiente para não ser banal. Então, divertido não quer dizer fútil; quer dizer que é interessante e legal.

JZ: Vamos falar sobre a parte de "difícil o suficiente para não ser banal." Então, tem um aspecto técnico quanto a ...

LT: Certo.

JZ: ... ser difícil. Tem um aspecto social, bem como um aspecto colaborativo para ser difícil. Qual você acha mais difícil? É apenas diferente?

LT: Todos eles estão, digo, todos eles estão mudando e são diferentes simplesmente, às vezes a tecnologia em si pode ser realmente desafiadora; o lado técnico é raramente frustrante. Então, o lado técnico é freqüentemente mais fácil no sentido em que eu não me frustro. OK, tivemos um bug e batemos nossa cabeça contra um bug técnico por meses e, sim, isso pode ser - parecer levemente frustrante - mas ao mesmo tempo, você sempre sabe que é algo que você vai resolver e você está simplesmente - Eu nunca me preocupo com isso.

O lado social é talvez um pouco mais difícil no sentido que pode ser realmente frustrante e às vezes você não resolve os problemas sociais e as pessoas se ofendem e eu acho que é bem interessante também. Eu digo, não é - e não seria - se todo mundo fosse fácil e todo mundo andasse para o mesmo lado, não seria tão divertido e interessante.

E é diferente e muda de tempo em tempo. Às vezes nós nos concentramos em problemas técnicos e então às vezes, felizmente são poucas, vêm estas tempestades de problemas sociais que começam e uma flame-war talvez traga à tona outras preocupações que as pessoas têm e que estavam escondidas sob a superfície, então.

Então, não é sempre que você tem essas preocupações técnicas e sociais; elas vão e voltam.

JZ: Vamos olhar mais a fundo na interação social, porque o código aberto é sempre descrito como este tipo de processo democrático que, você sabe, todo mundo opina, tem esse grande consenso, mas no final das contas, precisa ter algum tipo de opinião formada quando precisam fazer decisões. E como você lida com isto?


LT: Bem, digo, não é bem uma democracia e algumas pessoas chamam de uma meritocracia, o que não necessariamente está correto. É - Eu tenho uma política de quem faz o código ter o direito à decisão, o que reduz o problema - é muito fácil reclamar e falar sobre problemas e também é muito fácil eu dizer, "você tem que fazer deste jeito".


Mas no final das contas, apenas o que conta é o código em si, e a tecnologia em si, e as pessoas que não estão a fim de sujar as mãos e escrever o código, eles podem comentar e dizer que deve ser feito assim ou assado ou que não, mas no fim a opinião deles não é levada em conta. O que conta é o código.

E na verdade as pessoas são preguiçosas, então muitas pessoas ficam mais felizes batendo boca e às vezes você tem só um - um código de exemplo e não tem muito o que fazer aqui. Você - não tem muita gente que seja competente ao nível de escrever o kernel e que não seja preguiçosa a ponto de não fazer nada.

Então, às vezes acaba que a gente tem dois pedaços de código que fazem a mesma coisa, ou coisas parecidas, de jeitos diferentes então você chega ao ponto onde alguém tem que escolher, e às vezes sou eu, e isso pode causar alguns problemas sociais. Mas na verdade, isso é bem raro.


JZ: Mas você está disposto à tomar essas decisões quando você precisa, certo?

LT: Certo. E na verdade, as questões técnicas são bem simples no sentido que se eu acabar indo - fazendo a decisão errada, nós podemos desfazer. Acontece. Eu digo, as pessoas dizem, "OK, na hora pareceu uma boa idéia, mas depois vi que estava completamente errado."

E nós só damos a volta e pode ser um pouco sofrido às vezes, mas como já foi dito, não é comum de acontecer - fazer decisões grandes em primeiro lugar e na maioria das vezes a decisão é acertada.

JZ: Nos guie através da organização do processo de desenvolvimento em si. Você sabe, quem são as pessoas que estão no centro do projeto e como o projeto cresce em função dos participantes do desenvolvimento do kernel do Linux?

LT: Bem, uma das - minhas teorias favoritas é que a organização não existe de verdade e que ela se auto-organiza. E o que isto quer dizer é que não temos nenhuma regra rígida - quando não tem regras sobre quem é um mantenedor e mesmo quando temos um arquivo de mantenedor que diz "Fulano é responsável por este sub-projeto", isto é mais informativo. Isto significa que, se você tem problemas nessa área ou tem um patch que você quer ver aplicado para esta área, então Fulano é provavelmente a pessoa certa para entrar em contato.

Mas ainda assim é uma coisa bem suave e, no fim das contas, o que acaba acontecendo é que é mais como uma rede social onde algumas pessoas têm mais contatos que outras e um patch não é um problema; relatórios tendem a dar voltas longe da origem, através das pessoas que têm mais contatos, finalmente chegando À mim ou a outras pessoas mais importantes que têm vários contatos em diversas áreas.

JZ: Então, de certa forma, participar de um jeito significante no desenvolvimento é como ter amigos confiáveis?

LT: Isso.

JZ: Incluindo participantes diferentes?

LT: Sim. Não importa nada pra quem vocÊ trabalhe, porque ninguém dá bola para isto, e pode ter alguma política rolando, mas no fim das contas o que acontece é que as pessoas sabem - eles viram outras pessoas trabalharem por meses, anos ou até décadas, e eles sabem que "OK, eu posso confiar nessa pessoa. Quando ele me manda um patch, provavelmente está certo mesmo que eu não entenda porquê" e você constrói, de certa forma ,essa rede.

E porque ela é auto-organizada, significa que ela evolui com o passar do tempo. Então, as pessoas começam não sendo muito centrais, mas conforme elas se destacam em uma certa área, elas inspiram mais e mais confiança e conseguem mais conexões e ficam mais centrais sem realmente ter um - sem um lugar para torná-las oficialmente centrais.

JZ: Então, vamos falar um pouquinho sobre a comunidade, a partir deste aspecto de confiança e eu queria começar perguntando sobre o termo "comunidade". As pessoas usam este termo - sabe, "Não faça isso, vai ofender a comunidade" ou "A comunidade não aceita esta prática em particular."

Então - como você define comunidade? Digo, como você entende isso?

LT: Na verdade - eu evito usar a palavra comunidade porque ela é enganadora em várias maneiras. É enganadora no sentido de não ter só uma comunidade; é que todos têm seus problemas que eles se importam e que têm a ver - ou não - com outra pessoa que notavelmente está na mesma comunidade.

Então, outra coisa enganadora é pensar que as pessoas, digamos, compartilham idéias e objetivos e isto não e verdade. É bem claro nos casos em que pessoas têm objetivos diferentes; você tem empresas que têm seus objetivos comerciais bem nítidos e você tem pessoas que na dita "comunidade" do código aberto, você acha pessoas que não gostam de corporações, principalmente as maiores. Então, é bem comum que os objetivos sejam diferentes.

E outra coisa é, a comunidade tende a ser - se tornar - náo só como visão de uma entidade, mas você também vê pessoas como estando dentro e fora e isto costumava ser especialmente - Acho que a maioria das empresas começou a aprender lentamente, mas era um problemão quando empresas começavam a falar sobre "Como vamos interagir com a comunidade?"

E a comunidade acaba sendo alguma entidade externa, onde a resposta real acaba sendo "você não interage com a comunidade, você só age como um membro dessa comunidade não existente. Você realmente - você não interage, você faz parte."

JZ: Isso é algo que eu queria que aumentasse porque muitas vezes na Foundation, empresas vão nos questionar "Como nós podemos participar na comunidade? Como trabalhamos com a comunidade?" e nossa resposta, como a sua, é "Você pode ser uma parte da comunidade."

Que conselhos você daria para empresas que têm interesses em colaborar - não vou usar a palavra comunidade. Objetivos de desenvolvimento?

LT: Geralmente, digo, a maneira mais fácil é achar uma pessoa que já seja um membro do processo de desenvolvimento ou talvez não muito central, mas na verdade - que seja central o suficiente para estar envolvido e saiba como funcionam as coisas, e trazer esta pessoa para a empresa.

Freqüentemente as pessoas, digo, empresas têm este tipo de pessoa dentro delas, especialmente se for uma empresa de tecnologia e você tem interesse em algo como o kernel Linux, o motivo pelo qual você tem interesse provavelmente tem algo a ver com o tipo de pessoa que trabalha com você.

Então, provavelmente já há pessoas dentro da empresa que sabem como as coisas funcionam.

JZ: Mas você falou antes sobre confiança e porque confiança é importante em termos da influência que ela tem em realizar algo que você quer na comunidade.

Às vezes as empresas não pensam desta forma. Elas pensam "Ei, se eu empregar pessoas para trabalhar nisso e atirar recursos, eu vou cumprir meus objetivos."

Como podem estas empresas, se elas empregam pessoas, construir confiança? O que elas devem dizer para as pessoas que estão participando?

LT: Eu não sei se tem resposta pra essa pergunta. {risos} Eu - se você pensar sobre confiança tal como você pensa sobre confiar em um relacionamento pessoal, você não é confiado e você nem mesmo sabe se constrói confiança. A confiança vem ou não vem e depende em grande parte dos seus atos.

Então, o jeito de construir a confiança é não pensar nela como mera construção de confiança, mas tentar ter certeza que suas ações falam mais alto que suas palavras e talvez não se importar com suas estratégias internas. O que suas ações são é eventualmente o que vai te dar, ou não, confiança.

JZ: Vamos falar sobre o processo de desenvolvimento do kernel hoje e como ele mudou com o tempo. Me permita retratar um cenário para você e então eu quero saber o que você acha.

Há muitos anos atrás era um projeto divertido que era usado por empresas em alguns casos, mas não era tão adotado quanto hoje.

Hoje você tem essa onda de dispositivos móveis, de implementações enormes de servidores que são críticas ao interesse das empresas; esta participação maciça de um ponto de vista comercial.

Se você for parar para ver, como que o processo de desenvolvimento mudou? As pessoas mudaram? É, o que tem de diferente agora em relação ao que você fazia há, digamos, 3 ou 4 anos atrás quando você estava na Transmeta?

LT: Eu acho que o processo, a grosso modo, ainda é o mesmo. Houveram mudanças de processo que foram puramente técnicas no sentido de que fizemos alguns dos nossos processos mais abertos e existem ferramentas que suportam nosso jeito de fazer coisas que não existiam há 5 ou 10 anos atrás.

Outra coisa que mudou é que as pessoas envolvidas certamente estão envolvidas há mais tempo e estão, talvez, mais alerta sobre o quanto eles podem causar problemas e tomam muito mais cuidado - eu falo por experiência própria. Era mais fácil há 10 anos atrás dizer "Ei, vamos tentar isso e se não funcionar, não dá nada."

E também não temos tanta liberdade assim, não podemos simplesmente pegar código totalmente experimental e dizer, "Ei, vamos ver se isso dá certo."

E isso - como conseqüência, nós temos múltiplas camadas de onde um código vai, onde ele não entra imediatamente para minha árvore. Se há algo aqui que é experimental, ele é desenvolvido numa árvore experimental e então atravessa, por exemplo, a árvore do Andrew Morton e pode ficar lá por um ano até alguém dizer, "OK, funcionou nessa árvore. Não foi testado amplamente por estar em uma árvore específica, mas parece bom então vamos colocá-lo na árvore prncipal."

Então, nós mudamos isso. Um monte disso aconteceu sozinho, não só por termos antevisto os problemas, mas porque simplesmente virou a maneira que trabalhamos, porque ficou claro que a minha árvore pode ser tão experimental que, por conseqüência, motivou outras pessoas a ficar nos arredores das árvores experimentais.

JZ: De certa forma, o que vocÊ descreve parece muito como ir do estado de solteiro ao estado de casamento e ter filhos, no que tange o aumento da sensação de responsabilidade pessoal.


LT: Isso. Quis dizer - até certo ponto é claramente como crescer e há várias semelhanças; há provavelmente várias diferenças também, então {risadas} não sei se - você pode levar essa analogia muito longe, mas tudo bem.

JZ: Você não ama a comunidade do kernel, ama?

LT: Bem, algumas pessoas que eu trabalhei com, digo, quando você trabalha com pessoas por 5 ou 10 anos, talvez você não os ame no sentido mais restrito da palavra mas ao menos você confia nelas num sentido bem real em nível pessoal.

JZ: Uma das coisas que acontece-continuando a falar sobre a comunidade-é o Linux estar começando a ficar mais importante no mundo - seja dos governos que o vêem como uma maneira estratégica de crescer com uma indústria de software, como usar o Linux para uma ferramenta que possa ser usada para isso, ou fabricantes de dispositivos em Taipei ou o OLPC, etc...

Uma das coisas que as pessoas perguntam é por quê não vemos mais participação globalizada no processo de desenvolvimento? Em outras palavras, observadores dizem que o centro é na América do Norte e na Europa.

Eu ficaria interessado em saber sua opinião sobre: a) por que não vemos mais gente de outros países; e b) como podemos conseguir participação de gente desses países

LT: Bem, fizemos seis estudos ao longo dos anos apenas olhando as origens dos desenvolvedores e uma coisa óbvia é que as pessoas tendem a vir não só de países populosos, mas de países com uma alta densidade de acesso à Internet e esta é uma das razões.

Digo, você pode facilmente dizer isso, sim, tem um bilhão de pessoas na China, um bilhão na Índia, mas China e Índia não estão bem representadas na comunidade desenvolvedora.

Mas se você olhar não só na população, mas no número de pessoas que têm acesso à Internet, China e Índia não são tão grande assim e um dos problemas é a conectividade.


JZ: Mas proporcionalmente, eles participam tanto quanto ou...?

LT: Há outras questões também, e claramente as barreiras linguísticas e culturais são uma das maiores questões, e coisas tão óbvias quanto a educação.

Então, as barreiras linguísticas tendem a ser um grande problema para - bem, na verdade, talvez mais ainda as diferentes questões culturais que - em países Asiáticos há uma boa penetração: alguns deles têm amplo acesso à Internet, uma educação claramente excelente e não contribuem muito para o código aberto, não para o kernel nem para outros projetos.

E parece que isto é ao menos parcialmente cultural e é realmente difícil, então, para essas pessoas que têm barreiras culturais e linguísticas participarem ativamente. Acontece, mas explica muitas razões pelas quais a Europa e os EUA são as maiores áreas de desenvolvimento.

JZ: Isto é algo que os desenvolvedores do kernel pensam, digamos, "Como podemos envolver mais gente? Como podemos facilitar e abrir o envolvimento de pessoas?"

LT: Aparece de vez em quando. Eu não acho que ninguém saiba a resposta. Adicionamos documentação. Geralmente o "leia-me" inicial: onde ir para participar, como se portar, e isto está disponível em vários idiomas.


Se isso faz diferença? Não sei. Eu acho que não, mas eu não duvido que possa fazer mais gente ao menos olhar para o projeto. Talvez assuste men os pessoas quando vejam o projeto, ao menos tentem chegar perto. Pessoas na Ásia podem se sentir como "OK, não vou contra isso, pode me dar problemas", mas ao menos elas estão alerta disso e estão tentando chegar lá. Então essa é uma das coisas que estamos olhando.


Tendo dito isto, eu digo, eu acho que a barreira cultural é maior que a barreira linguística. O motivo que eu digo isso? A América do Sul tem sido bem ativa, então não é isso - e eles não necessariamente falam inglÊs bem, mas eu acho que culturalmente eles estão mais perto da Europa e dos EUA o que facilita para que eles entrem.

Então - E as diferenças culturais, não sabemos como resolvê-las.


JZ: O - Vamos falar um pouco sobre os aspectos técnicos relativos ao futuro do kernel. No começo o Linux era mais usado no servidor. Obviamente é usado em desktop, e cada vez mais em sistemas móveis e embarcados.

Como você vê, mais e mais dispositivos móveis e embarcados usam Linux, isso afeta o kernel do ponto de vista técnico?

LT: Eu esperava que o impacto fosse maior. Na verdade, os dispositivos móveis evoluíram tanto que até um celular, até um modelo bem básico de smartphone atual tem mais capacidade de processament do que os primeiros desktops que rodaram o kernel do Linux, e isso não vai parar.

Então, eu acho especialmente, do ponto de vista do kernel, as pessoas se preocupam mais com isso do que elas deveriam, na minha opinião. Os maiores problemas no lado móvel não são bem assim - bem, ainda tem no lado do kernel; você quer ele menor, você quer ele mais eficiente mas eu acho que a coisa que vai fazer mais gente se preocupar são as interfaces.

Faz mais diferença que o jeito que você interage com um celular é diferente do jeito que você interage com um desktop. Você tem um teclado limitadíssimo, você tem problemas com a tela, você tem uma tela pequena, e eu acho que os problemas maiores tendem a ser em coisas como a interface gráfica.

Então, você tem o Qtopia, que parece ser famoso na parte de celulares e o kernel não viu muito disso. Pode ser que só eu pense assim e eu estou por fora de algumas questões porque eu não lido diretamente com os desenvolvedores de kernel para dispositivos móveis, mas suspeito que a maioria das pessoas se preocupe menos com o kernel do que com o userspace.

JZ: Bem, vamos falar sobre a segunda parte desse comentário que você fez sobre os diversos grupos ou distribuições Linux específicos para dispositivos móveis. E, você sabe, uma das coisas que você ouve as pessoas dizer é um motivo pelo qual elas participam no desenvolvimento do Linux e de outros código-aberto é por causa do trabalho coletivo que reduz os custos e permite que elas trabalhem em conjunto eficientemente.

E tendo, vocÊ sabe, alguns grupos se soltando, o que eles podem fazer de um ponto de vista de melhores práticas, se você é uma empresa de dispositivos móveis, para conseguir o que você quer na árvore principal para que você possa, bem, manter tudo lá por tempo indeterminado.

LT: Eu acho que o grande problema no mundo de dispositivos móveis tende a ser que o mercado está acostumado a ser fragmentado. Todo mundo faz esses dispositivos diferentes; fizeram isso pelas últimas décadas, eles estão acostumados a escrever código descartável e começar do zzero quando a nova geração de produtos começa.

Então, eles têm gerações de hardware que continuam por muitos anos e eles dão suporte à esta geração, mas então quando eles finalmente decidem fazer outra geração, eles começam do zero.


E quando você vem com esta mentalidade, você às vezes - até onde eu sei, muitas pessoas sequer entendem a noção de tentar trabalhar com o processo e tentar integrar com o kernel padrão ou os utilitários padrões porque não é como eles trabalhavam.

Então, o que muitos desses fabricantes fazem é pegar uma versão, pegam uma versão que é bem recente na época da escolha e dizem "OK, esta é a base", então nos próximos anos para esta plataforma particular, eles ficam com essa versão e melhoram ela para seus próprios fins.

E quando eles querem fazer isso entre a próxima versão e hardware da próxima geração, eles ficam na situação onde o mundo trabalhou em outra coisa nestes anos e todas as modificações são para uma versão antiga, nada a ver com a atual e eles são obrigados a atirar o trabalho fora e recomeçar.



E isso não é algo que eu - eu não acho que posso ajudar. Acho que o mercado móvel, até certo ponto, precisa crescer e largar esse mal-comportamento.

JZ: De certa forma é uma questão cultural, não de um ponto de vista histórico e geográfico, mas de um ponto de vista de negócios.

LT: Sim. É uma questão técnico-cultural e referente à prática da cultura de negócios.

JZ: Uma das coisas que você falou antes foi que há uma complexidade crescente em como você faz interface com o kernel e drivers são parte disto.

Me perguntam muito, e isto não vai te surpreender, por que é que o kernel não tem uma ABI estável para drivers?

LT: Bem - a falta de uma ABI tem 2 lados: uma é que nós realmente NÃO queremos uma. Toda vez que alguém pergunta por uma ABI estável, a razão principal é que elas querem ter seus drivers binários e não querem abrir nem abrem seu código - certamente não querem combinar seu código no kernel estável ou no kernel padrão.

E isto, por conseqüência, significa que as pessoas que realmente fazem o trabalho no kernel e o mantém estão basicamente incapacitadas de trabalhar com esta ferramenta de hardware e este fabricante porque, se há algum bug, não pode ser corrigido.

Então, os vendedores comerciais - até os que aceitavam drivers binários - mudaram ou estão mudando para evitarem ter drivers binários por eles serem péssimos de serem mantidos.


Então, aí está um motivo. Algumas pessoas o vêem como ideológico. Provavelmente tem um aspecto ideológico, mas muito dele é pragmático: nõs simplesmente não daríamos conta.

JZ: Isto parece com uma questão cultural onde, você sabe, pessoas estavam simplesmente acostumadas a dar suporte para drivers bnários, e têm benefícios com isso, mas eles nem entendem o benefício de compartilhar o suporte.

LT: Bem, não é assim, você sabe, nem tanto pelo benefício. É o fato de que, quando o suporte é distribuído, digo, eu acabo não tendo que dar suporte para muitos dispositivos, mas acabo sendo a última opção de suporte para quando - quando a casa cai e tem um problema grande, no final das contas cai tudo em mim.

E quando você tem este tipo de sistema de suporte distribuído quando - onde todo mundo acaba envolvido em certo ponto, vocÊ realmente não pode ter a situação onde só um pequeno grupinho tem acesso ao código que pode estar causando o problema. Você precisa ter o código disponível, não por questão social, mas porque você não tem como saber quem pode consertar.


Então, tem um motivo real pelo qual precisamos ter o código-fonte, o que significa para todos os desenvolvedores do kernel, uma interface binária é basicamente uma coisa ruim. Não há vantagem nenhuma.


Mas há outra razão que é que nós acabamos mudando coisas de forma radical dentro do kernel e isto acaba resultando no fato de que mesmo que quiséssemos ter uma interface binária, nós simplesmente não poderíamos, ou poderíamos mas então isto nos impediria de consertar e mudar coisas internamente.

E isto é uma coisa que você vê em outros projetos, onde, sim, eles têm interfaces binárias por um motivo ou outro - muitas vezes por questões comerciais - e isto significa que eles não podem mudar seu projeto fundamental. Eles não assinam só as interfaces binárias, eles assinam o projeto todo, exatamente o mesmo de quando eles criaram a interface binária.

Então, está aí a segunda maior razão pela qual uma ABI estável não vai sair - na verdade, isto significa que a gente não vai nem garantir uma API estável; então, mesmo em nível de código-fonte nós dizemos, "OK, esta é a API e a gente - se você tiver drivers que usem isto, a gente vai te ajudar a corrigí-los quando mudarmos a API, mas não podemos garantir que a API vai continuar igual em outras versões.". E não vai.

JZ: Mas ao abrir, vocês obviamente poderiam resolver estes problemas.

LT: Sim. Imediatamente quando as pessoas trabalham com, digamos, a API, nós podemos ajudar quando alguém reclama "Ei, não compila mais. Meu módulo dependia desta função e agora não funciona mais", ao menos a gente pode resolver o problema.

Isso nem é tanto o problema. Significa que pessoas que mantém módulos externos, mesmo com código-fonte disponível, não podem assumir que o código simplesmente compila sem mudanças entre versões.

JZ: Por quê você acha que mais fabricantes não abrem seus drivers? Existem culpados? Quais?

LT: Certamente existem culpados. Certamente existem fabricantes específicos que acabam tendo mais problemas que os outros. Na verdade, Às vezes o mesmo fabricante pode ser muito bom em uma área e péssimo em outra.

A Broadcom é um exemplo disso. Eles são - e tem sido muito bons em adaptadores Gigabit high-end, dispositivos para redes cabeadas, mas quando descemos para redes sem fio e outros dipositivos para o usuário final, eles não podem ou não querem ajudar.

Então, às vezes você tem a mesma empresa atuando de formas bem diferentes dependendo de qual mercado eles trabalham. Certos mercados, Linux é um sucesso e um ótimo negócio; em outros, não é.

Às vezes, é simplesmente - especialmente quando falamos com fabricantes de Taiwan - um dos problemas é - algumas das pessoas do hardware mudam seus projetos diversas vezes por ano; eles têm centenas de versões diferentes dos chips. Eles têm engenheiros que fazem drivers para Windows; eles não têm os recursos. Eles não conseguiram se tornar parte da comunidade Linux, então - então eles têm problemas. Achar documentação é realmente difícil; talvez não exista de uma forma que eles possam liberar.

Então, às vezes é uma questão prática. Às vezes eles têm boas intenções, mas os seus recursos acabam não indo para esta área.


JZ: Você viu as mudanças ocorrerem conforme o Linux torna-se mais uma parte crítica da indústria, mais pessoas o adotam, que há um motivo crítico que, se é que você me entende, não tinham tempo antes mas agora eles têm que ter tempo?

LT: Definitivamente está mudando. Digo, é - poucos fabricantes de hardware realmente ajudavam os desenvolvedores Linux a escrever drivers. E agora, ao menos, estou pessoalmente tendo a sensação de que as empresas que não tentam ajudar, ao menos com a documentação e, em alguns casos, até com o desenvolvimento de drivers, estão virando minoria.

Então, está definitivamente mudando, mas ainda assim é o caso - especialmente em certas áreas nós não temos o tipo de suporte que a gente queria ter.

JZ: Vamos mudar para assuntos que estão bem perto do seu coração: questões jurídicas.

LT: Oh, eu amo questões jurídicas. [Risos]

JZ: Eu queria falar um pouco sobre licenciamento, tlavez um pouco sobre patentes. Deixe - nos diga um pouco sobre a GPLv3 e, vocÊ sabe, você diz que a GPLv2 funciona bem para você.

Você imagina alguma situação onde você diria que a GPLv3 funciona para você?

LT: Bem, eu posso ter opiniões radicais, mas ao mesmo tempo eu não tenho - ou eu posso dizer que eu sou bem pragmático, então eu não me importo, por si só, com uma licença ou outra. Eu quero escolher a licença mais adequada para meus fins. E atualmente, a versão 2 nos atende muito, muito melhor que a versão 3.

E sempre houve uma tensão bem clara entre o Linux e o código-aberto de um lado e a FSF e o software livre do outro onde, até certo ponto, Linux foi o projeto que causou toda essa divisão.

De certa forma, Linux foi o projeto que realmente deixou claro a diferneça entre o que a FSF promove - o que é bem diferente do que o código aberto e o Linux propõem, e o Linux sempre esteve mais interessado no mérito técnico e não na crença religiosa na liberdade.

Então, a GPLv3 reflete os fins da FSF e a GPLv2 se aproxima do que eu acho que uma licença deve fazer e, assim, a GPLv2 é onde o kernel está.

Poderia acontecer algo que causasse a mudança? Talvez.

JZ: E o que poderia causar a mudança?

LT: Bem, uma das - o que era uma grande vantagem para a GPL era que havia só uma licença e esta licença era a V2. E isto resultou num grande volume de código-fonte que estava todo sob a mesma licença, o que significa que você poderia compartilhar tanto código quanto possível.

E uma das coisas que a V3 fez foi basicamente dividir essa base de código, de forma que atualmente tem certos projetos que são só V2, outros projetos que são V2 ou posterior e outros que são V3 ou posterior.

E isto significa que agora, de repente você não possa compartilhar código por causa da licença e isto não é algo novo; sempre tivemos isso. Tivemos com outras licenças. Então, existia código que estava licenciado sob a licença Apache e isto não era compatível com a V2. [N.T. Isto não é mais o caso e a licença Apache é compatível]

Então, não é algo novo, mas há uma clara vantagem e existem efeitos colaterais quando o assunto são licenças então esta - el, realmente, um dos poucos motivos pelos quais eu vejo que a V3 seja útil é que simplesmente acaba tendo toneladas de código que nos parece útil e importante que está sob a V3. E então, para evitar problemas de licenciamento, nós - eu não duvido que eu possa ver o pessoal do kernel dizendo, "OK, nós vamos relicenciar para a V3 não porque é a melhor licença, mas porque ela nos abre mais oportunidades de código."

JZ: Então, basicamente o que você descreve é um jeito de - você acaba no mesmo lugar, mas por razões bem diferentes; um é um motivo filosófico e uma idéia de liberdade - liberdade no sentido de acesso ao código de um ponto de vista livre - e outro de um pragmático, "Ei, queremos resultados. Se tem mais código disponível com essa licença, é algo em que estamos interessados."

LT: Sim, então eu sempre - sempre quero que as decisões de licenciamento do Linux sejam feitas baseadas nessas questões pragmáticas. Claramente existem ideologias que andam lado-a-lado com estas escolhas, mas acho que licenças são tão importantes para pensar, que não são tanto sobre questões práticas quanto ideológicas.

JZ: Você sabe, um monte de vezes eu falo com pessoas e descrevo problemas de licenciamento a partir da sua perspectiva, que há uma extrema direita da Microsoft falando sobre quão ruim são licenças e na extrema esquerda advogados falando sobre quanto tempo você precisa ficar examinando licenças e que eles gostariam de fazer este trabalho para você.

Qual é a sua opinião? Digo, a licença pode representar um risco? Digo, é um problema se comparado com as licenças de software proprietário?

LT: Bem, pessoalmente acho que a escolha de licenças são realmente, realmente importantes. Para mim, digamos, a escolha de licença pelo autor sob o qual ele lança qualquer código-fonte ou, digo, não precisa ser código-fonte, é quase sagrada. Digo, é que - se alguém veio com algo realmente inovador de interessante, cabe a ele o direito de escolher como será usado. Eu digo, claramente, que devem existir razões como o bem comum, que é por isto que o copyright existe.

Dito isso, é uma escolha pessoal e eu não acho que seja - Eu digo, uma vez que alguma pessoa ou empresa tenha feito esta decisão, eu não acho que tenha muito motivo para eles começarem a discutir sobre dizer ou não "Ei, esta licença é melhor que a outra."

Eu não acho que tenha um - Digo, isso simplesmente não faz mais sentido.

JZ: Eu vou te colocar no centro por um segundo, então, sobre a idéia de escolha pessoal e a licença. Do ponto de vista do kernel, é uma escolha pessoal entre muita gente, certo?

LT: Bem, de certa forma começou como uma escolha pessoal de uma pessoa só: eu.

JZ: você.

LT: E quando você tem um projeto existente, é diferente de começar um novo. Quando você tem um projeto existente, a escolha muda um pouco. A primeira escolha é "Qual licença eu escolho?" Assim que você passa desse ponto a escolha torna-se "Eu quero participar e eu vou participar considerando que a licença já foi escolhida?"

Então, você não escolhe mais a licença, mas sim o projeto. Sim, é uma escolha pessoal, mas é uma escolha pessoal completamente diferente.

JZ: Então, deste ponto de vista, você tem uma obrigação com a grande comunidade do kernel e as pessoas participando dela, para que elas sejam incluídas se a escolha de licença mudar.

LT: Bem, não é só uma obrigação, é um requisito jurídico. Eu não posso mais mudar a licença sozinho. Digo, porque eu aceitei código por 15 anos de pessoas que aceitaram minha escolha original da V2, eu não estou apenas, penso eu, ligado eticamente à essas escolhas, eu estou ligado juridicamente.


Eu não posso dizer "Ei, agora nós vamos mudar da licença X para a Y." Muita gente participou no desenvolvimento e me mandaram patches, e ainda são donos do copyright dos patches ou das mudança. E se a gente realmente quiser mudar para a GPLv3, não é diferente de mudar para qualquer outra licença; nós podemos - eu digo, é teoricamente possível os outros decidirem "Ei, nós queremos mudar para a licença BSD" ou nós queremos a mudança para outra licença.

Em termos práticos, para que isto ocorra, todo mundo que é dono do copyright precisaria concordar ou os que não concordam precisariam ter seu código reescrito.

Então, em termos práticos, isso não vai acontecer. A V3 é muito mais provável, simplesmente por quê então você provavelmente vai achar pessoas que começaram com a V2 ou posterior, então elas aceitaram implicitamente a V3.

Ou você provavelmente vai ver pessoas dizendo "Ei, eu aceitei a V2. A V3 não é uma grande mudança; eu aceito."

JZ: Você se sente como se estivesse fazendo um papel como um líder com as implicações morais e jurídicas, por assim dizer, você ajuda pessoas no sentido de seu julgamento pessoal?

LT: Sim, eu me sinto. E é um dos motivos que eu me pronunciei contra a V3 antes que ela fosse lançada, e todos os rascunhos, porque eu queria ter certeza que, como um líder na comunidade do kernel, eu dissesse para as pessoas o que esperar do meu ponto de vista, visto que eu estava infeliz com os rascunhos, mas explicar por quê e talvez explicar para pessoas na área de sistemas embarcados, na qual a cláusula anti-TiVO [N.T.: cláusula que impede sistemas DRM de serem inseridos no kernel] era um ponto fraco, que elas não podiam ser ignoradas.

E elas são parte da comunidade também. E aqui eu usei essa palavra "comunidade", mas não quer dizer que se o número da versão aumenta, automaticamente torna-se uma licença melhor.

--

Esta obra está licenciada sob uma Licença Creative Commons.