BrBRHUHu0102-69092011000200005

Activist-driven innovation: uma história interpretativa do software livre

Introdução Os estudos sobre a produção de conhecimento - sejam eles da área de sociologia, economia, administração ou mesmo filosofia - reconhecem, em geral, a validade da ideia de que existem diferentes regimes ou sistemas de produção do conhecimento - aos quais correspondem formas específicas de estrutura organizacional, organização do trabalho, regime de recompensa, motivação subjetiva, práticas e valores sociais, e formas de gestão da propriedade intelectual (Merton, 1957, 1963, 1973; Bourdieu, 2004; Biaglioli, 1998; Nelson, 2004; Shinn, 2000a e b, 2008b).

Existem muitas possibilidades de classificação dos regimes de produção de conhecimento, dependendo da ênfase que se dê às diferentes dimensões que os caracterizam. Assim, a primeira hipótese do presente trabalho é a de que existem dois regimes sob os quais se organizou, historicamente, a atividade de desenvolvimento de software: um regime público/científico e um regime privado/ empresarial.1 Esta compreensão - de que existem dois regimes distintos para a produção de software - é cada vez mais comum na literatura sobre o tema (Gambardella e Hall, 2006; Laat, 2005; Bonaccorsi e Rossi, 2005, Osterloch e Rota, 2007). O que não é tão comum, e se configura, portanto, como a contribuição mais original deste artigo é, de um lado, a abordagem histórica da configuração desses dois regimes e, de outro, a análise dos fatores que determinam o sucesso técnico e "comercial" de um regime em detrimento do outro.

Assim, trabalhamos com duas hipóteses complementares: a primeira, de que o desenvolvimento do software livre pertence historicamente ao regime público/ científico de produção do conhecimento, ou seja, o software livre mimetiza a organização da "comunidade" científica porque tem nela as suas raízes históricas; e a segunda, de que em uma "competição de mercado" o regime público/científico se mostrou mais eficiente e, por isso, obrigou as empresas que trabalhavam no regime privado/empresarial a adotar o software livre ou de código aberto.

A colaboração pré-competitiva O PACT I e II Há um consenso mais ou menos difundido entre os principais estudiosos do software livre e/ou de código aberto de que as práticas colaborativas para o desenvolvimento de softwares são anteriores ao projeto GNU e à criação da Free Software Foundation (Raymond, 2000; Weber, 2004; Kim, 2005). Segundo Raymond: [...] a FSF [Free Software Foundation] nunca foi a única iniciativa na área. Sempre existiu uma força mais silenciosa, menos confrontadora e mais amigável em relação ao mercado na cultura hacker. Os "pragmáticos" foram leais menos a uma ideologia do que a um conjunto de tradições de engenharia fundado nos primeiros esforços do código aberto que precederam a FSF. Essas tradições incluem, mais notadamente, as culturas interligadas do Unix e da Internet pré- comercial (2000, p. 2).

De fato, não é difícil perceber - analisando a história das práticas de desenvolvimento de software  - que a colaboração parece ser tão antiga quanto o próprio software em si. Quando, no começo da década de 1950, surgiram os primeiros computadores comerciais - por exemplo, o 701 da IBM lançado em 1952 a um custo de manutenção mensal de U$ 15,000 -, a necessidade de desenvolver programas que os fizessem funcionar era tão grande quanto a dificuldade técnica envolvida nessa atividade. Também era um fator importante a escassez de mão de obra capaz de levar a cabo a tarefa2 e a inexistência de um mercado bem desenvolvido para esse tipo de produto. Neste contexto - de imensa necessidade de um rápido processo de desenvolvimento tecnológico e de um alto custo e risco envolvido na sua realização -, o processo de escrita das primeiras linhas de código acabou fortalecendo um ambiente favorável às práticas de colaboração.

O acontecimento que marcou, historicamente, a consolidação de práticas colaborativas nos processos de desenvolvimento de software foi a criação do Project For Advancement of Coding Techniques (PACT) em 1952. O PACT envolvia diversas empresas da área de informática3 num esforço cooperativo para o desenvolvimento de um sistema operacional4 automático para o IBM 701. O projeto teve duas edições - os assim chamados PACT-I e PACT-II - cujo resultado final foi o primeiro software desenvolvido de forma colaborativa por empregados de firmas diferentes (Bernstein, 1973), um esforço denominado, modernamente, de pesquisa pré-competitiva.

Por ser o primeiro projeto colaborativo de maior relevância que se conhece, o PACT é considerado, por alguns autores, um marco fundamental no surgimento de uma "cultura da colaboração" entre programadores de software. Para Eric E. Kim, por exemplo, é possível dizer que antes do PACT a cultura da colaboração, condição necessária para o surgimento de projetos colaborativos, simplesmente não existia (Kim, 2005).5 A nossa hipótese, neste artigo, é um pouco diferente da de autores como Kim e outros que atribuem o surgimento da cultura de colaboração entre programadores de software a projetos específicos de sistemas operacionais como o PACT ou mesmo ao BSD/Unix. Da nossa perspectiva, a cultura da colaboração está ligada, antes, à tradição acadêmico/científica na qual esses programadores se formaram.

Outros autores (Raymond, 1999; Bonaccorsi e Rossi, 2003; DiBona et al., 1999) também ressaltam as origens acadêmico-científicas da comunidade hacker: A comunidade de programadores é muito heterogênea, mas a explicação para o enorme resultado alcançado pelo projeto do código aberto reside na cultura hacker dos "programadores reais" vindos dos campos da física e das engenharias no pós-guerra. [...] muitas gerações de cientistas da computação foram formados no mundo acadêmico e nos centros de pesquisa das grandes corporações de software (Bonaccorsi e Rossi, 2003, p. 1245).

Mas independentemente do fato de o PACT não ter "originado" a cultura de colaboração entre programadores de software, o projeto acabou se tornando um marco do sucesso dessa forma colaborativa de produção de software, de tal modo que ela passou a ser considerada a "forma ideal" da atividade de desenvolvimento e programação. Segundo Paul Armer, um dos programadores envolvidos no PACT-I: O espírito de cooperação entre as organizações participantes e seus representantes durante a formulação do PACT-I foi um dos recursos mais valiosos que surgiu do projeto. É essencial que esse espírito de cooperação continue nos planos de projetos futuros (Armer, 1973, s/ p).

Embora acreditemos que o PACT não seja a raiz principal da colaboração incorporada pelo software livre, ele certamente contribuiu para consolidar a cultura de colaboração que tinha origem nas práticas científicas. No campo do software, esse ethos colaborativo se expressou de maneira mais clara em duas experiências: o projeto BSD, que se desenvolveu em torno da Universidade da Califórnia, e o projeto GNU, a partir do MIT. Na experiência californiana, a ausência de uma política de licenciamento de direitos autorais levou a uma incorporação pelo mercado que introduziu práticas competitivas e fragmentou o código; já no projeto GNU, a lição do BSD foi incorporada e uma inovadora estratégia de licenciamento foi desenvolvida para conter a dispersão competitiva e garantir a sustentabilidade da colaboração.

O projeto BSD/Unix A possibilidade de que os projetos para o desenvolvimento de softwares permanecessem no âmbito dos esforços colaborativos - ou, dito de outro modo, no âmbito do regime público/científico de produção do conhecimento - foi assegurada, alguns anos mais tarde, pelo acordo firmado entre o governo dos Estados Unidos e as grandes empresas da área de telefonia da época: AT&T e Western Eletric Company Inc.

Desde janeiro de 1949, o governo norte-americano, através da Divisão Antitruste do Departamento de Justiça, movia uma ação contra a AT&T e a Western Eletric Company Inc. pela violação da Lei Sherman - o famoso dispositivo norte- americano antitrustes e contra a propriedade cruzada de 1890. O processo, que durou mais de sete anos, terminou em 1956, com a deliberação do juiz Thomas F.

Meaney, por meio de um consent decree,6 segundo o qual as empresas envolvidas se comprometiam a não desenvolver atividades comerciais fora da área de telegrama e telefonia: "A acusada AT&T é forçada e impedida de se engajar, direta ou indiretamente (por intermédio de suas subsidiárias outras que não a Western e suas subsidiárias) em qualquer negócio que não seja o fornecimento de serviços de comunicação" (United States District Court, 1956, s/p). Mais do que isso, a deliberação de Meaney, e a interpretação que dela tiveram os advogados das duas empresas envolvidas, implicou uma determinação de que todas as patentes da AT&T, da Western Eletric e de suas subsidiárias fossem licenciadas a custos nominais e sem maiores restrições (Salus, 1994, p. 57).

Como os Bell Telephone Labs, mais conhecidos como Bell Labs, eram, nessa época, subsidiários tanto da AT&T como da Western Eletric - cada uma possuía 50% dos laboratórios -, eles também ficaram obrigados a licenciar todas as suas patentes considerando as determinações do consent decree: ou seja, a um custo mínimo e sem restrições significativas.

Segundo Salus (1994), o Consent Decree de 1956 e a interpretação conservadora dada a ele pelos advogados da AT&T e da Western Eletric, tiveram, juntos, um efeito decisivo para a política relativa às pesquisas que os Bell Labs viriam a desenvolver na área de software e programação em geral. Por não serem passíveis de comercialização - dado que eram consideradas, na época, externas às áreas de telegrama e telefonia, às quais deveriam se restringir as operações da AT&T e da Western Eletric -, essas pesquisas puderam se desenvolver, nos laboratórios, com certa liberdade e forte caráter colaborativo.

Assim, em 1964, os Bell Labs começaram a desenvolver um sistema operacional chamado Multics (Multiplexed Information and Computing Service) em parceria com o MIT e com a General Eletric, dentro desse registro colaborativo que marcava as pesquisas do laboratório na área. No entanto, em 1969, depois de cinco anos de pesquisas, o projeto foi abandonado pelos Bell Labs por razões consideradas, na época, de ordem "técnica". A decisão de abandonar o Multics, no entanto, foi antes da direção dos laboratórios do que dos pesquisadores envolvidos no projeto. Entre esses, Ken Thompson e Dennis Ritchie, em especial, estavam convencidos das potencialidades do Multics e se empenharam - a princípio, fora do âmbito da empresa7 - no projeto de um sistema operacional inspirado no Multics (Weber, 2004).

Em outubro de 1973, na quarta edição do Symposium on Operating Systems Principles,8 ocorrido na Purdue University de Nova York, Thompson e Ritchie inscreveram um artigo que apresentava para a comunidade de programadores e pesquisadores de software, as possibilidades de "uso e implementação" do Unix, um "sistema operacional de propósito geral, multiusuário e interativo para o DEC/PDP -11/40" (Thompson e Ritchie, 1973, p. 1).

O fato de o Unix ter sido apresentado originalmente em um congresso acadêmico mostra o quanto os Bell Labs, apesar de serem um conjunto privado de laboratórios, valorizavam a relação com a academia, sobretudo a norte- americana. Essa valorização do mundo acadêmico refletia-se claramente na sua própria organização interna, que mimetizava, em muitos aspectos, a organização acadêmica de produção do conhecimento.

O Unix, apresentado no Symposium on Operating Systems Principles em 1973, despertou a atenção dos pesquisadores universitários imediatamente, de modo que, já em 1975, mais de quarenta universidades norte-americanas possuíam computadores que rodavam Unix (Salus, 1994). A rápida difusão do Unix foi possibilitada, em grande medida, pela política de licenciamento de software da AT&T. Como vimos, uma vez que a empresa não podia explorar comercialmente "softwares para computador", nem aferir royalties do seu patenteamento por conta das limitações instituídas pelo Consent Decree de 1956, a solução foi licenciar softwares como o Unix apenas para fins de pesquisa, a custos nominais, mas sem nenhum serviço de suporte ou manutenção, ou seja, sem ônus para a empresa. Essa política de licenciamento teve um efeito duplo e complementar: por conta do seu baixo custo, o Unix disseminou-se rapidamente entre instituições de pesquisa e universidades. Paralelamente, a ausência de qualquer serviço de suporte ou manutenção obrigou a comunidade de usuários de Unix a compartilhar informações, soluções de problemas e atualizações do sistema.

Entre os usuários mais interessados no sistema, estava o pesquisador Robert Fabry do Departamento de Ciência da Computação, Estatística e Matemática da Universidade de Berkeley, Califórnia. Fabry assistiu à apresentação de Ritchie e Thompson no simpósio de Nova York, em 1973, e passou a acompanhar o trabalho deles para fins de pesquisa. O interesse científico de Berkeley e o desinteresse comercial dos Bell Labs no Unix possibilitaram um longo processo de colaboração entre as duas instituições.

Esse processo intensificou-se a partir de 1978, quando os pesquisadores de Berkeley colocam, em um mesmo "pacote de distribuição", o kernel 9 do Unix e outros softwares, formatando uma linha de distribuição do Unix que ficou conhecida como BSD, ou Berkeley Software Distribution. No ano seguinte, Robert Fabry propôs oficialmente ao Darpa - Defense Advanced Research Projects Agency - um projeto de desenvolvimento de uma versão do BSD - com o kernel do Unix - para a Internet. O projeto foi aprovado em 1980, originando o Computer System Research Group, ligado ao Departamento de Ciência da Computação de Berkeley. O grupo desenvolveu, nos dezoito meses previstos para o projeto, uma versão do BSD integrada à Internet, também conhecida como a 4ª versão da BSD/Unix.

Mas esse processo de relativa liberdade e intensa colaboração inter- institucional passou a enfrentar algumas dificuldades a partir do final dos anos de 1970, quando a incipiente popularização do computador pessoal possibilitou o surgimento de um mercado de software, levando as empresas a iniciarem políticas mais agressivas de proteção e distribuição dos seus produtos. O documento paradigmático dessa mudança de atitude das empresas é a carta do jovem fundador da Microsoft aos "entusiastas" não profissionais que animavam o hoje lendário Homebrew Computer Club, um fórum de "amadores" interessados em microcomputadores e que se reunia na Universidade de Stanford, entre 1975 e 1977, para compartilhar diferentes versões de programas de computador. A carta, assinada por Bill Gates, reclamava do compartilhamento de um software, o Altair-Basic, que a Microsoft havia desenvolvido para o primeiro microcomputador pessoal, o Altair 8800: Como a maioria dos amadores deve saber, a maior parte de vocês rouba os seus softwares. O hardware precisa ser comprado, mas [para vocês] o software deveria ser compartilhado. Quem se importa se as pessoas que trabalharam nele serão pagas? Isso é justo? [...] O que vocês fazem é impedir que software de qualidade seja escrito. Quem pode bancar fazer trabalho profissional por nada? Que amador pode despender três anos-trabalho em programação, encontrar todos os bugs, documentar o trabalho e distribuí-lo de graça? O fato é que ninguém, com a exceção de nós, investiu tanto dinheiro no software para amadores. Nós escrevemos o Basic 6800 e estamos escrevendo o APL 8080 e o APL 6800, mas há muito pouco incentivo para tornar esse software disponível para os amadores. Falando francamente, o que vocês estão fazendo é roubo (Gates, 1976, p. 2) Essa mudança na forma como o compartilhamento de software passou a ser visto a partir do surgimento de um mercado específico de programas de computador ecoou também na AT&T. A empresa, que desde 1974 estava sendo novamente processada pelo governo norte-americano por monopólio, foi obrigada, em 1982, a se separar tanto dos Bell Labs como da Western Electric. Essas mudanças de natureza política e econômica fizeram com que, a partir de 1983, a AT&T internalizasse o desenvolvimento do Unix, criando o Unix System Labs e alterando radicalmente a forma de distribuição e licenciamento do software. Por conta disso, em 1988, a licença do Unix já custava aproximadamente U$ 100 mil chegando, alguns anos depois, a U$250 mil (Weber, 2004, p. 39). A mudança da política de licenciamento do Unix resultou no paulatino arrefecimento da colaboração entre os Bell Labs e a Universidade de Berkeley, que culminou no processo judicial movido pela AT&T contra a universidade californiana em 1992.

O enfraquecimento das redes de colaboração entre Berkeley - que tinha a sua distribuição própria do Unix, a BSD - e a AT&T - que também mantinha a sua versão de distribuição - começou, no entanto, antes mesmo da mudança da política de licenciamento da empresa. Já em 1981, a AT&T proibiu a Universidade de lançar a versão 4.1 da Berkeley Software Distribution (BSD) porque pretendia, ainda naquele ano, lançar a sua distribuição comercialmente.

Assim, a história do Unix na década de 1980 é marcada, de um lado, pela ruptura das relações colaborativas que pautaram o seu desenvolvimento em um contexto em que o mercado de software era pouco desenvolvido e que uma das principais empresas envolvidas nesse processo não podia explorar os resultados dessas pesquisas comercialmente; de outro, pela completa fragmentação do processo de desenvolvimento do Unix.

A história da fragmentação do projeto Unix e o seu consequente fracasso na década de 1980, bem como a ascensão do projeto GNU - cuja sigla significa, justamente, "GNU Não é Unix" - nos anos 1990 são processos incompreensíveis sem uma análise da política de licenciamento da Berkeley University. A licença BSD é considerada uma das mais liberais que existem porque permite, grosso modo, qualquer tipo de utilização sem imposição de nenhuma exigência específica sobre o caráter dos futuros licenciamentos derivados.10 Os termos da licença até 1994 diziam o seguinte: A redistribuição e o uso em código-fonte ou binário, com ou sem modificação, é permitida desde que as seguintes condições sejam seguidas: 1. Redistribuições do código-fonte devem conter a nota de copyright acima, esta lista de condições e as restrições que se seguem; 2. Redistribuições em forma binária devem reproduzir a nota de copyright acima, esta lista de condições e as restrições que se seguem na sua documentação e/ou em outro material oferecido com a distribuição; 3. Todo material de propaganda que mencione vantagens ou uso desse software deve conter o seguinte agradecimento: Este produto inclui software desenvolvido pela Universidade da Califórnia, Berkeley, e seus contribuidores. 4. Nem o nome da Universidade nem os seus contribuidores podem ser usados para endossar ou promover produtos derivados desse software sem a permissão prévia e específica (BSD License, s/d).11 Essa forma específica de licenciamento - sem qualquer exigência ou prescrição quanto à forma de distribuição dos softwares derivados - pode ser interpretada, grosso modo, como uma não-licença. Na medida em que abre possibilidade para que versões e modificações feitas em um software sejam posteriormente distribuídas sob uma licença restritiva, ou seja, sem a obrigação de publicização do código- fonte, a licença BSD implicou, concretamente, o fim de ciclos de desenvolvimento colaborativos. Em outras palavras, a licença de Berkeley não garantiu - ao contrário da General Public Licence, que seria desenvolvida anos depois - que todas as modificações feitas sobre o software licenciado permanecessem "públicas", abrindo caminho para a criação de obras derivadas proprietárias. Essa característica da Licença BSD determinou que os diferentes projetos derivados do Unix se fragmentassem, uma vez que deu origem a projetos comerciais que passaram a concorrer fortemente entre si.

Nesse registro, a AT&T manteve a sua distribuição do Unix, mas com uma política de licenciamento alterada a partir de 1983, quando a distribuição do software passou a ser cobrada. A Universidade de Berkeley, por sua vez, continuou com a sua distribuição própria até 1989, quando em um esforço coordenado pela universidade, a comunidade de usuários do BSD-Unix reescreveu, por engenharia reversa, partes inteiras do programa que era, então, disputado pela AT&T. Esse projeto resultou no Networking Release 1 - uma nova distribuição do Unix.12 Paralelamente, inúmeras empresas - como, por exemplo, a HP, a IBM, a Sun Microsystem, entre outras - começaram a desenvolver versões próprias do sistema. Desse modo, no início dos anos de 1990, o Unix era distribuído em inúmeras versões concorrentes e, muitas vezes, incompatíveis entre si.

A ruptura das relações de colaboração entre Berkeley e a AT&T e o surgimento de versões proprietárias do Unix explicam-se, sobretudo, como dissemos, pelo fortalecimento do mercado de software, impulsionado pelo surgimento do computador pessoal. Essa mudança, associada a outras como o sucesso comercial da Microsoft, marca a transição da produção de software de um regime público/científico - caracterizado, entre outras coisas, pelo compartilhamento de informações, em especial do código-fonte do software - para um regime privado/empresarial - no qual a venda do software e a proteção do código-fonte, via propriedade intelectual, desempenham papel central.

A reação da comunidade hacker O projeto GNU Em 1971, o Massachusetts Institute of Technology (MIT) contratou Richard Stallman, então um jovem estudante de Harvard, como programador do seu Laboratório de Inteligência Artificial. Stallman tinha trabalhado no laboratório científico da IBM, em Nova York, após concluir o secundário e, em Harvard, perseguia seus interesses em Biologia e Física enquanto trabalhava no laboratório do MIT. Durante esses anos, tomou contato com a assim chamada "cultura hacker", uma subcultura muito particular, forjada pelos primeiros programadores do MIT nos anos de 1960 e que se baseava em valores tais como a defesa da democratização do acesso aos computadores, a crença de que a informação deveria circular livremente, a desconfiança da autoridade baseada em credenciais, a defesa da meritocracia praticamente comprovada e a descentralização organizacional (Levy, 1984). Alguns desses valores, como a colaboração e a publicidade da informação, eram muito próximos do que era, então, chamado de ethos científico e, provavelmente, tinham sido incorporados à cultura hacker a partir da prática científica e universitária do MIT e de outras instituições de ensino e pesquisa. Nas palavras de Stallman: Quando comecei a trabalhar do Laboratório de Inteligência Artificial do MIT, em 1971, integrei uma comunidade de compartilhamento de software que já existia há muitos anos. O compartilhamento de software não era particularmente restrito à nossa comunidade [no MIT]; ele nasceu com os computadores, assim como o compartilhamento de receitas nasceu com o ato de cozinhar (Stallman, 1999).

Essa "cultura hacker", que em termos de valores gerais podia ser encontrada também em outras instituições como Stanford e Berkeley, sofreu um grande impacto a partir da emergência de um mercado autônomo de software.

Stallman costuma aludir a um evento que lhe serviu como uma espécie de "revelação" das mudanças que afetava a cultura dos programadores quando o software passou a ser visto como uma atividade comercial que deveria ser exercida de forma concorrencial e, portanto, produzido num regime outro que não o público/científico, que marcara o desenvolvimento do software até ali. O evento é o "mítico" episódio no qual a Xerox se nega a fornecer o código-fonte do software da impressora laser 9700 para Stallman. Em 1980, a impressora que era utilizada no laboratório do MIT começou a apresentar problemas no gerenciamento de trabalhos pela rede e Stallman buscou, sem sucesso, o código- fonte do software para poder consertá-lo, como já havia feito antes, no registro colaborativo que marcava, então, a pesquisa na universidade.

Foi devido a essa filosofia do dar e receber que, quando Stallman se deparou com o defeito na impressora a laser da Xerox, ele não entrou em pânico. Ele simplesmente procurou uma forma de atualizar o conserto antigo [que tinha desenvolvido para um modelo anterior] ou então hackear o novo sistema. Ao procurar o software da impressora, no entanto, Stallman fez uma descoberta perturbadora. A impressora não tinha um software, pelo menos não um que ele ou outro programador pudessem ler (Williams, 2002).

Quando as empresas começaram a comercializar e, consequentemente, proteger os seus softwares, elas deixaram de distribuir o código de programação aos usuários, disponibilizando apenas o código binário que era lido e executado pela máquina. Assim, quem comprava o programa não tinha mais acesso ao código no qual ele havia sido programado (o código-fonte), o que dificultava que o programa fosse imitado por empresas concorrentes. O efeito colateral desta estratégia de proteger o patrimônio intelectual das empresas por meio do sigilo era que o software não podia mais ser desenvolvido - e incrementado - colaborativamente, já que as companhias estavam competindo entre si.

Nos anos seguintes, esse processo de comercialização intensificou-se ainda mais e o laboratório de Inteligência Artificial do MIT viu seus melhores programadores serem contratados pelo mercado, em particular por uma nova empresa chamada Symbolics. Stallman se viu no difícil dilema de aceitar o processo inexorável de competição comercial, indo trabalhar para alguma empresa, ou abandonar a computação. Foi em meio a essa dúvida em relação à sua trajetória que Stallman teve a ideia ousada de desenvolver um sistema operacional inteiro baseado nos valores de colaboração dos primeiros hackers.

Seu projeto era criar um "mundo paralelo" de liberdade e colaboração que estivesse na contramão das práticas competitivas das empresas. Ele chamou esse projeto de GNU, um acrônimo recursivo cujo significado era "GNU Não é Unix", já que o sistema teria algumas características do sistema operacional Unix, mas não seria Unix.13 Em setembro de 1983, ele lançou um chamado à comunidade hacker pedindo a colaboração e, em 1985, lançou um manifesto que apresentava a filosofia do projeto: Eu considero uma regra sagrada a exigência de que eu compartilhe os programas de que gosto com outras pessoas que também gostem deles.

Vendedores de software querem dividir os usuários para conquistá-los, fazendo com que cada usuário não compartilhe com os outros. Eu me recuso a romper a solidariedade com os outros usuários desta maneira.

Eu não posso, em sã consciência, assinar um contrato com cláusula de sigilo ou uma licença de software. [...] Assim, para continuar a utilizar computadores sem desonra, eu decidi elaborar um conjunto de softwares livres, de forma que eu consiga utilizá-los sem qualquer recurso a software não livre. Eu me demiti do Laboratório de Inteligência Artificial do MIT para não permitir que o MIT tenha qualquer pretexto legal para impedir que eu distribua o GNU (Stallman, 2002, s/p).

O projeto GNU fazia um apelo moral para resgatar o "ato fundamental de amizade entre os programadores", que consistia no "compartilhamento de software". As novas práticas comerciais das empresas, que enfatizavam o sigilo e a competição, tornavam "fora da lei" a ação moral da amizade e da colaboração comunitária e era preciso, portanto, resgatá-la, conciliando a "hospitalidade" e a "obediência da lei" (Idem, s/p). A forma pela qual se efetivava essa conciliação do princípio moral e da lei era uma licença de software "pública", que foi chamada de Licença Pública Geral (General Public License ou GPL). A GPL foi desenvolvida para licenciar os primeiros softwares livres que estavam substituindo os softwares proprietários. Era uma licença que subvertia o propósito original do direito autoral, de restringir a cópia para garantir a remuneração do detentor do direito. Como o titular original do direito autoral é "soberano" para estabelecer as condições de uso de suas obras, a GPL simplesmente afirmava que, no exercício desse direito, o detentor autorizava o livre uso, a modificação e a cópia do programa na forma original ou modificada, desde que essa cópia mantivesse as liberdades originais: Os contratos de licença da maioria das empresas de software tentam manter os usuários à mercê dessas empresas. Contra isso, nossa Licença Pública Geral tem o objetivo de garantir sua liberdade de compartilhar e modificar software livre - garantir que o software seja livre para todos os usuários. [...] Em particular, a Licença Pública Geral foi concebida para garantir que você tenha a liberdade de dar ou vender cópias de software livre, que receba o código-fonte ou tenha acesso a ele se quiser, que possa modificar o software ou usar partes dele em novos programas livres e que você saiba que pode fazer essas coisas. Para proteger seus direitos, precisamos criar restrições que proíbem alguém de negar esses direitos ou de pedir que você entregue os direitos (Idem, s/p).

O licenciamento da GPL diferia de estratégias anteriores de autorizar cópias e modificações (por exemplo, colocando as obras em domínio público) por exigir que versões subsequentes mantivessem as liberdades de modificar e copiar. Sem esse caráter "viral", o código liberado poderia ser reapropriado por empresas e fragmentado num processo competitivo subsequente, como tinha acontecido com a BSD. Stallman chamou esse efeito viral de copyleft, incorporando um trocadilho que havia sido sugerido por um amigo - Don Hopkins - em 1984 ou 1985.14 O copyleft - que é a grande inovação conceitual da licença GPL - buscava evitar as apropriações de código que Stallman havia testemunhado, entre elas, uma experiência própria relativa a uma versão de um editor de textos que ele havia originalmente desenvolvido no MIT em 1976. O editor, chamado Emacs, tinha sido elaborado para o sistema operacional ITS (utilizado no laboratório do MIT) e depois fora reescrito para funcionar no Unix por James Gosling em 1981. Gosling tinha distribuído o código do programa livremente buscando colaboração, mas depois o vendeu para uma empresa chamada UniPress que impediu a sua distribuição livre a partir de então.

No verão daquele ano, cerca de dois anos atrás [1984], um amigo me disse que devido à sua colaboração no desenvolvimento inicial do Gosling Emacs, tinha recebido permissão do Gosling, numa mensagem, para distribuir a sua versão do programa. Gosling tinha elaborado seu Emacs e distribuído de forma livre, conseguindo que muita gente colaborasse com ele no desenvolvimento, na expectativa, segundo o próprio Gosling diz no manual, de que seguiria com o mesmo espírito com o qual eu havia lançado o Emacs original. Então, ele deu uma facada pelas costas em todo mundo, colocando direitos autorais no programa, fazendo as pessoas prometerem não distribuí-lo e vendendo o software para uma empresa. [...] Neste ponto, a companhia para a qual Gosling tinha vendido o programa contestou o direito de meu amigo distribuí-lo e a mensagem [onde Gosling o autorizava a fazê-lo] estava armazenada em fitas de backup que ele não conseguia encontrar. E Gosling negou que tivesse dado permissão a ele (Stallman, 1986).

Com o copyleft, no entanto, esse tipo de manobra proprietária não era mais possível. A licença GPL garantia em termos legais sólidos que a obra podia ser modificada e redistribuída, e o caráter viral do copyleft fazia com que cópias ou obras derivadas adotassem compulsoriamente a mesma licença, difundindo as liberdades presentes na licença original. Foi sem dúvida devido ao caráter viral dessa forma de licenciamento que o projeto GNU conseguiu se expandir rapidamente nos anos seguintes. Com programas de excelente qualidade técnica, quase sempre distribuídos gratuitamente e acompanhados do código-fonte, muitos programadores, tanto do meio acadêmico como empresarial, passaram a fazer uso desse patrimônio "público" para produzir novos programas, mais complexos. E ao construir ferramentas baseadas em outras ferramentas licenciadas sob a GPL, terminavam inserindo essas obras derivadas no fundo público comum compulsoriamente. O crescimento do software livre assumia, assim, uma velocidade exponencial.

O Linux No final dos anos de 1980, o projeto de criar programas "livres" que substituíssem os "proprietários" constituindo, assim, um sistema operacional completo estava próximo do fim. Faltava apenas um kernel, a parte central do sistema operacional encarregada da comunicação entre o software e o hardware.

Enquanto a Free Software Foundation de Stallman se dedicava a um complexo projeto de kernel chamado Hurd, um estudante de pós-graduação da Finlândia, Linus Torvalds, anunciava o desenvolvimento de um kernel simples, mas eficiente, inspirado em um kernel acadêmico chamado Minix, que havia sido desenvolvido por Andrew Tanenbaum na Universidade Vrije de Amsterdã. Em 25 de agosto de 1991, Torvalds enviou uma mensagem para o grupo de Usenet comp.os.minix anunciando o projeto do Linux e, no mês seguinte, lançou a primeira versão do kernel (versão 0.01) com a seguinte nota de copyright: Este kernel é ©1991 Linus Torvalds, mas ele pode, no todo ou em partes, ser redistribuído desde que você faça o seguinte: - Todo o código deve ser disponibilizado (livremente), se não com a distribuição, pelo menos quando requisitado - Notas de copyright devem permanecer intactas (na verdade, se você distribuir apenas parte dele, você precisará adicionar copyright, uma vez que não há ©s em todos os arquivos). Trechos menores podem ser copiados sem dar atenção a copyrights.

- Você não pode distribuir exigindo uma taxa, nem mesmo para cobrir custos de "envio".

Mande-me um email se você tiver perguntas.

Infelizmente, um kernel sozinho não faz nada. Para ter um sistema que seja operacional, você precisará de um shell, compiladores, uma biblioteca etc. Tratam-se de partes separadas e que podem estar [licenciadas] sob copyrights mais estritos (ou frouxos). A maior parte das ferramentas utilizadas com o Linux são programas GNU e estão sob o copyleft GNU. Essas ferramentas não estão na distribuição. Para maiores informações, me escreva (ou escreva para o GNU) (Torvalds, s/d [a]).

Curiosamente, nessa primeira versão do Linux, a licença não é livre, pelo menos não na definição que Stallman havia dado ao termo. Desde o começo, Stallman havia incluído entre as liberdades do software, a de vendê-lo. O que tornava um software livre era o fato de que ele permitia a colaboração entre seus programadores, garantindo o acesso ao código-fonte e a livre reprodução e execução; e a mercantilização do software em si, por outro lado, não se constituía em um problema, embora, naqueles primeiros anos, se acreditasse que a oferta do código-fonte tornava inviável a venda de software livre - o que, depois, se mostrou possível, agregando-se a ele uma marca, por exemplo (Young, 1999). Era exatamente por isso que Stallman sempre enfatizou que o termo free da expressão free software referia-se à liberdade e não ao preço - na fórmula que ficou consagrada: "To understand the concept you should think of free as in free speech, not as free beer" (Stallman, 1996).

Torvalds afirma que a adoção de uma licença que permitia a cópia e o acesso ao código-fonte era parte da tradição acadêmica de compartilhamento de resultados científicos. Por outro lado, a restrição ao uso comercial vinha do temor de que a introdução do Linux no circuito comercial tirasse do autor o controle sobre o seu produto e desvirtuasse, consequentemente, seus objetivos técnicos: Quando, originalmente, publiquei o Linux, senti que estava seguindo as pegadas de séculos de cientistas e outros acadêmicos que construíram seu trabalho sobre as fundações de outros - nos ombros de gigantes, nas palavras de Sir Isaac Newton. [...] Creio que teria abordado a coisa de modo diferente se não tivesse sido criado na Finlândia, onde qualquer um exibindo o menor sinal de ganância é visto com suspeita, ou inveja. [...] E sim, eu sem dúvida teria abordado de maneira diferente a coisa do "sem dinheiro" se não tivesse sido criado sob a influência de um avô resolutamente acadêmico e um pai resolutamente comunista. De qualquer modo, eu não queria vender o Linux. E eu não queria perder o controle, o que significa que eu não queria que ninguém o vendesse também. Eu deixei isso claro na política de copyright que incluí na cópia da primeira versão que "subi" em setembro. [...] Pense bem. Você coloca seis meses da sua vida nessa coisa e quer torná-la disponível e quer tirar algo dela, mas não quer que as pessoas se aproveitem. [...] Fazia sentido para mim que a melhor maneira do Linux se desenvolver tecnologicamente era mantê-lo puro. Se houvesse dinheiro envolvido, as coisas ficariam obscuras. Se não há dinheiro em jogo, não há pessoas gananciosas (Torvalds e Diamond, 2001, pp. 93-94).

Está claro que, neste relato, Torvalds demonstra uma diferença em relação a Stallman quanto ao papel da permissão de uso comercial, referindo-se, no fundo, a free como em free beer ("Você não pode distribuir cobrando uma taxa"). Em um momento posterior, no entanto, devido ao fato de querer utilizar uma ferramenta licenciada em GPL no Linux (o compilador GCC, desenvolvido por Stallman), ele é obrigado a adotar a licença GPL, que não restringe o uso comercial (Torvalds, 1999). Essa adoção, aliás, mostra de maneira clara o efeito prático de uma licença viral, com copyleft. Na versão seguinte do Linux (0.0.12) de fevereiro de 1992, já aparece a seguinte nota: O copyright do Linux vai mudar: recebi algumas solicitações para torná-lo compatível com o copyleft do GNU, removendo a condição "você não pode distribuí-lo por dinheiro". Eu concordo. Proponho que o copyright seja mudado de forma a conformar-se com o GNU - se tiver a aprovação das pessoas que ajudaram a escrever o código. Presumo que não será problema para ninguém: se você tem queixas ("Eu escrevi o código presumindo que o copyright permaneceria do mesmo modo") me envie uma mensagem. Do contrário, o copyleft do GNU terá efeito a partir de primeiro de fevereiro. Se você não conhece a essência do copyright do GNU - leia (Torvalds, s/d [b]).

Assim, no começo dos anos de 1990, o projeto GNU havia realizado seu objetivo principal de desenvolver um sistema operacional completo baseado em uma licença livre (a versão 1.0 do Linux foi lançada em 1994). Nos anos seguintes, o Linux ganhou reputação como um sistema eficiente e estável; por suas virtudes técnicas e cooptação de esforços por meio do copyleft, despertou o interesse e a preocupação da comunidade empresarial.

A incorporação do regime público/científico e os novos modelos de negócios As primeiras empresas de software livre, como a Cygnus e a VA Research, eram relativamente pequenas e baseavam-se no único modelo de negócios viável que se imaginava naqueles primeiros anos da década de 1990: a distribuição gratuita do software e a venda de serviços. No manifesto GNU, de 1985, Stallman já havia sugerido que os programadores poderiam garantir seus rendimentos deslocando a sua fonte de renda do licenciamento dos direitos autorais para os serviços de instalação, personalização e manutenção dos programas: A restrição de cópia não é a única base para os negócios no software.

É a base mais comum porque é a que traz mais dinheiro. Se fosse proibida ou rejeitada pelo cliente, as empresas de software teriam que encontrar outras bases de organização que agora são pouco exploradas. Existem diversas formas de organizar qualquer tipo de negócio. [...] Um fabricante que introduza um novo computador poderá pagar pela transposição de sistemas operacionais para o novo hardware. A venda da atividade de ensino, orientação e serviços de manutenção também podem empregar programadores. Pessoas com novas ideias poderão distribuir programas como freeware, pedindo doações de usuários satisfeitos ou vendendo serviços de orientação. Já conheci pessoas que estão trabalhando desta maneira com sucesso. Usuários com necessidades parecidas poderão formar grupos de usuários e pagar taxas. Um grupo poderá contratar empresas de programação para escrever programas que os membros queiram utilizar (Stallman, 2002, s/p).

Mas o mundo do software livre só sentiu, de fato, o impacto do mundo dos negócios quando as grandes empresas de tecnologia da informação começaram a se aproximar daquele modelo de produção - mais ou menos no mesmo momento em que as primeiras empresas de software livre começam um processo de fusão (VA Research unindo-se à empresa Linux Hardware, e a Cygnus à Red Hat) e de abertura de capital na bolsa. O primeiro precedente significativo do interesse da parte tradicional do mundo dos negócios pelo software livre foi a decisão da Netscape de liberar o código do seu navegador para impedir a dominação do mercado pela Microsoft, migrando seu modelo de negócios totalmente para a oferta de serviços para o setor empresarial.

Com o crescimento da Microsoft no mercado de navegadores, a Netscape temia que ela passasse a impor padrões de protocolos não públicos, sabotando, assim, as suas concorrentes no mercado de servidores (que teriam dificuldade para servir páginas num padrão privado). À medida que ia dominando o mercado de navegadores, com o Internet Explorer, a Microsoft passava a utilizar uma codificação própria para páginas Web que apenas os seus próprios servidores eram capazes de produzir. Dessa maneira, ela transpunha a dominação do mercado de navegadores para o mercado de servidores. Para impedir, então, que a Microsoft dominasse o mercado de navegadores, a Netscape decidiu transferir o desenvolvimento do seu programa de navegação para a comunidade de software livre e, tendo garantido a concorrência neste mercado, passou a se concentrar nos servidores, que lhe eram mais rentáveis. Assim, em janeiro de 1998, a Netscape anunciou que passaria a distribuir o código do seu programa para a comunidade de software livre sob uma licença "herdeira" da GPL, passando a se concentrar no mercado de "soluções empresariais": A Netscape migrou com sucesso seu modelo de negócios no ano passado em direção à venda de softwares empresariais, para rendimentos ligados ao seu site, afastando-se assim dos rendimentos advindos de clientes isolados. No terceiro quadrimestre de 1997, os rendimentos advindos destes clientes representavam aproximadamente 18% da receita da Netscape - todo o resto vinha do software empresarial, serviços e o site. [...] Juntamente com o seu cliente gratuito [free], a Netscape anunciou também que está lançando um conjunto de produtos e serviços aperfeiçoados que alavancam seu cliente, tornando fácil para consumidores individuais e empresariais adotarem soluções Netscape.