Aspectos do Trabalho Cooperativo no

Desenvolvimento de Software Livre

Marcelo Sávio
IT Architect
http://www.linkedin.com/in/msavio
http://msavio.myplaxo.com/

Rio de Janeiro - Janeiro de 2007

Resumo. Software livre é todo software cujo código fonte está disponibilizado publicamente, e
seu conteúdo pode ser livremente modificado e redistribuído (e não sendo permitida a
apropriação desse código). Uma conseqüência indireta desta liberdade é o aparecimento de
comunidades de desenvolvimento que trabalham de forma descentralizada, através da Internet,
desenvolvendo e mantendo os diferentes projetos de software livre. Essas comunidades,
que a primeira vista parecem estar desorganizadas, produzem software de qualidade, com
alta produtividade e satisfação entre os seus desenvolvedores e usuários. O objetivo deste
artigo é verificar os aspectos do Trabalho Cooperativo Suportado por Computador, CSCW
(Computer Supported Cooperative Work), que suportam o desenvolvimento
descentralizado de software livre, através do estudo de caso do desenvolvimento do sistema
operacional Linux.

1 Introdução

Apesar da definição apresentada acima, ainda existem controvérsias em relação ao que seja
precisamente considerado software livre. Isso se dá pelo fato de que se trata de um assunto
multifacetado, que contém questões relacionadas a assuntos como engenharia de software,
propriedade intelectual, modelo econômico, política tecnológica, cooperação1, liderança e
motivação. Uma olhada mais de perto em alguns projetos de software livre revela, ainda, uma
grande diversidade de objetivos, formas de participação e técnicas de implementação.
Ao analisar as atividades que suportam o desenvolvimento de software livre, do ponto de
vista do trabalho cooperativo suportado por computador, é possível identificar um desafio
comum a todos os projetos: a necessidade da criação e manutenção de um ambiente
sociotécnico onde os participantes possam, de forma cooperativa, construir soluções para os
problemas de interesse mútuo.
As práticas do desenvolvimento de software livre são importantes para a pesquisa em CSCW
por dois motivos principais. Primeiro porque o desenvolvimento de software é tradicionalmente
um processo de coordenação intensiva que tem atraído pesquisadores de CSCW (KRAUT,
1995; BUTTON, 1996) e segundo porque o processo de desenvolvimento de software livre é
efetuado por participantes geograficamente dispersos, com a ajuda de tecnologias colaborativas
como o email, conversação on-line, World Wide Web e sistemas de controle de versão e de
gerenciamento de configuração, tecnologias que, por sua vez, têm sido um aspecto central nas
pesquisas de CSCW.

1
O conceito de cooperação é mais complexo que o de interação e de colaboração, pois além de pressupor ambos
requer relações de respeito mútuo e não hierárquicas entre os envolvidos, uma postura de tolerância e convivência
com as diferenças e um processo de negociação constante. Percebemos que a diferença fundamental entre os
conceitos de colaboração e cooperação reside no fato de que para haver colaboração o indivíduo deve interagir com
o outro existindo ajuda - mútua ou unilateral. Para existir cooperação deve haver interação, colaboração, mas
também objetivos comuns, atividades e ações conjuntas e coordenadas. (MAÇADA; TIJIBOY, 1998).
1.1 Histórico Resumido do Software Livre (e do Linux)

Software Livre é um conceito antigo, embora ainda não tivesse este nome específico desde o
início. Até a década de 70, o valor de um computador estava contido essencialmente no
hardware, que tinha um custo muito alto. A maioria dos fabricantes fornecia, junto com o
hardware vendido, o código fonte de seus sistemas operacionais e aplicativos. Embora as
licenças não explicitassem claramente a liberdade, a redistribuição do software era vista como
positiva, e quase todo o software era fornecido com o seu código fonte (STALLMAN, 1999).
Os fabricantes até estimulavam, como forma de diminuir os custos de suporte, o
compartilhamento de informações e melhorias de software produzidas entre seus usuários2.
Assim o software era, em geral, desenvolvido de forma cooperativa e aberta em diversas
universidades e empresas. O sistema operacional UNIX, nos seus anos iniciais, foi um exemplo
desta época (MCKUSICK, 1999), assim como o desenvolvimento da Internet foi inteiramente
baseado no uso e compartilhamento de programas de código fonte aberto em escala mundial.
No início da década de 80 o cenário mudou, quando ganhou força o licenciamento restritivo,
que não permitia a redistribuição do software fornecido e este passou a significar basicamente o
módulo executável, suprimindo o acesso à maioria dos códigos-fonte. Esta mudança de cenário
fez com que, em 1984, (STALLMAN, 1999) criasse a Free Software Foundation (FSF3). A
filosofia do software livre se baseia em uma definição de liberdade. Por causa da ambigüidade
em inglês da palavra "free", tornou-se necessário esclarecer que free software não se refere ao
preço, mas à liberdade dos usuários de executar, copiar, distribuir, estudar, modificar e melhorar
o software. Mais precisamente, referem-se a quatro tipos de liberdades:
1. A liberdade de executar programas para qualquer propósito.
2. A liberdade de estudar como o programa funciona e adaptá-lo às suas necessidades (o acesso ao
código fonte é essencial para isso).
3. A liberdade para redistribuir cópias do programa de modo que outros se beneficiem.
4. A liberdade de melhorar o programa e distribuir o seu aperfeiçoamento para o público, de modo que
toda a comunidade se beneficie (novamente o código fonte é necessário).

O primeiro projeto da FSF foi o de promover o desenvolvimento de um novo sistema

operacional, completamente livre. Para garantir esta liberdade, criou em 1989 um novo modelo
de licenciamento de software, a General Public License (GPL), descrita no Anexo 1.
O novo sistema operacional que seria desenvolvido, e que teria o objetivo de ser compatível
com UNIX, foi chamado de GNU4 (um acrônimo recursivo que significa GNU is Not UNIX). O
desafio não se restringia apenas à criação do núcleo do sistema em si (chamado HURD e que
ainda não está pronto até hoje), mas também de uma coleção de aplicativos, ferramentas e
bibliotecas que permitissem sua plena utilização, sem perder a compatibilidade com o UNIX
original.
A cultura em torno do movimento de software livre, de certa forma, está ligada à cultura em
torno do UNIX, já que os principais representantes do movimento foram usuários desse sistema,
que tinha uma natureza aberta e uma filosofia própria, sumarizada por Gancarz (1995) como
sendo composta dos seguintes pontos:
1. Pequeno é belo;
2. Faça cada programa perfazer bem apenas uma tarefa apenas;
3. Construa um protótipo assim que possível;
4. Escolha portabilidade sobre eficiência;
5. Armazene dados numéricos em arquivos texto;
6. Faça reuso do software para sua vantagem;
7. Use scripts shell para aumentar portabilidade e reuso;
8. Evite interfaces restritivas com o usuário;
9. Faça cada programa ser um filtro de dados para que possa ser usado em conjunto com outros.

2 Havia um grande compartilhamento de software entre os participantes dos grupos de usuários, como o SHARE

(para usuários de sistemas IBM) e o DECUS (para usuários de sistemas DEC).

3 http://www.fsf.org/
4 http://www.gnu.org/
 Em 1991, Torvalds (1999) então estudante da Universidade de Helsinki (Finlândia), iniciou o
desenvolvimento do Linux, um núcleo de sistema operacional compatível com o UNIX, a partir
do reuso de códigos e idéias do Minix, um pequeno sistema operacional de uso acadêmico
criado por Tanenbaum (1987). A partir da primeira versão, Torvalds convidou, via newsgroups
da Internet, outros desenvolvedores a contribuírem nessa empreitada. Houve bastante adesão e,
de forma surpreendentemente rápida, a codificação e a manutenção constantes neste núcleo, o
fizeram evoluir para se tornar um software com funcionalidades similares às dos núcleos dos
sistemas UNIX do mercado (SCHENK, 2001). O Linux, ao longo do seu desenvolvimento,
utilizou (e ainda utiliza) muitas ferramentas do Projeto GNU da FSF e por esta razão o sistema
hoje também é chamado de GNU/Linux.
O licenciamento através da GPL e a utilização da Internet como o canal principal de
comunicação e desenvolvimento transformaram o Linux no mais importante exemplo de
software livre desenvolvido de forma aberta e descentralizada.
Raymond (1999) rotulou os modelos de desenvolvimento de software e chamou de “Bazar”
esse modelo descentralizado e cooperativo, em contraposição ao “Catedral”, modelo tradicional
no qual o desenvolvimento é realizado de forma fechada e pouco cooperativa. Ele reforçou esta
perspectiva através da afirmação de que o Linux é um contra-exemplo da “Lei de Brooks”, uma
lei clássica da Engenharia de Software, que diz o seguinte:
“...o tempo de um programador não é acumulativo, pois ao adicionar desenvolvedores em um projeto
atrasado de software faz com que ele se torne mais atrasado ainda e que a complexidade e os custos
de comunicação de um projeto crescem com o quadrado do número de desenvolvedores, enquanto o
trabalho feito cresce somente linearmente” (BROOKS, 1995).

Outra característica do modelo Bazar, importante para a qualidade do objeto produzido, é ter
uma grande base de usuários com acesso ao código fonte, pois segundo Raymond (1999) “Se
exposto a um número suficiente de olhos, todos os bugs são superficiais”, pois a depuração de
erros é uma atividade paralelizável e será resolvida mais rapidamente quanto maior for a base de
usuários participantes.
O tamanho e a agilidade de um projeto de software livre, não são as únicas qualidades que o
distinguem de um modelo “Catedral”. Outra importante diferença está em sua organização
interna, particularmente na ausência de uma coordenação global sob uma autoridade central e
pela inexistência de um planejamento de projeto do tipo “Top-Down”. Aliás, em software livre
normalmente a estratégia vem depois do desenvolvimento e a ação antes do planejamento
(TAURION, 2004).
A partir de 1988 o software livre se tornou notícia cada vez mais freqüente na imprensa,
quando a Netscape abriu o código do seu principal produto, o Communicator e também quando
empresas de grande porte como IBM e Oracle começaram dar suporte ao Linux e ao Apache.
Esse ano também ficou marcado como o ano que a Microsoft reconheceu, pela primeira vez, o
Linux como competidor importante (OSI, 1988).
Muitas vezes o termo software livre (free software) se confunde com software aberto (open
source). Isso passou a acontecer principalmente após a criação da Open Source Initiative (OSI5),
em 1988. Diferentemente da FSF, que suporta somente o uso de suas próprias licenças, a OSI
não tem licenças próprias, mas certifica todas as dezenas licenças existentes no mercado
(inclusive as da FSF) dentro de seus próprios parâmetros de software aberto. A OSI é uma
entidade conciliadora, que garante às empresas que praticam o modelo comercial de
desenvolvimento de software, uma porta de entrada no movimento de software aberto sem
necessariamente adotar as licenças da FSF, representando assim uma espécie de alternativa
intermediária. Desta forma, todo software livre é, por definição, aberto, porém nem todo
software aberto é livre.

5 http://www.opensource.org/
1.2 Os Projetos de Software Livre

Embora não exista uma definição precisa do que seja um projeto de software livre, existe um
consenso informal de que o software em conjunto com seus desenvolvedores, usuários e
repositórios de código e documentos constitui um projeto, que desta forma abrange:

• Código fonte, que é o software propriamente dito, mas que existe em forma de inúmeras
cópias entre todos seus usuários e repositórios de dados. Software livre, em geral, tem uma
versão bem definida e distribuída a partir de um ponto central conhecido para o Projeto.

• Um grupo de desenvolvedores, que trabalha para codificar e corrigir o software. Os

desenvolvedores, em todos os casos e sem exceção, trabalham cooperativamente através da
Internet e podem ter status diferenciados dentro do projeto (FIELDING, 1999).

• Os usuários do software. Apesar de todo software ter usuários, sua participação em

projetos de software livre é essencial, pois discutem inovações e apresentam erros
encontrados com freqüência, incentivando os desenvolvedores a trabalhar por um produto
melhor (RAYMOND, 1999).

• Os repositórios de documentos e códigos. Normalmente todo projeto tem algum site

central que é uma referência para desenvolvedores e usuários buscarem códigos e
informações atualizadas.

É interessante perceber que todo o processo de desenvolvimento e distribuição depende

essencialmente do uso da Internet, e que esta é um pré-requisito para a existência de um projeto
de software livre.
Segundo o Sourceforge6, website do Open Source Technology Group (OSTG7), que é o maior
repositório de software livre e de código aberto disponível na Internet, existem em seus registros
mais de 130 mil projetos, em diferentes estágios de desenvolvimento, classificados da seguinte
forma:

• Planejamento: Nenhum código foi escrito ainda e o escopo do projeto ainda está sendo
definido, Logo que algum resultado tangível em forma de código apareça, o projeto entra
no próximo estágio;

• Pré-Alfa: Código muito preliminar produzido. Não é esperado, entretanto que este código
seja capaz de compilar ou ser executado. Observadores externos ao projeto poderão ter
dificuldade em entender o significado do código. Assim que uma intenção coerente que
indique uma direção seja percebida no código, o projeto passa para o estágio seguinte;
• Alfa: O código produzido funciona pelo menos de forma parcial e o projeto começa a
tomar forma e absorver novas características. À medida que o número de sugestões e
modificações começa a diminuir, o projeto entra no estágio seguinte;

• Beta: O código está, de uma forma geral, completo em relação às características propostas
no projeto original, mas requer testes de depuração. Quando o número de erros estiver
reduzido o suficiente para entrar em produção, o projeto passa para o estágio seguinte;

• Estável: O software é utilizável e confiável o suficiente. As mudanças serão aplicadas

cuidadosamente e com o objetivo de aumentar a estabilidade, nunca de adicionar
funcionalidades. Se nenhuma mudança significante acontecer em um período longo, o
projeto entra no último estágio, mesmo se problemas menores ainda possam existir;

6 http://sourceforge.net/
7 http://www.ostg.com/
 • Maduro: Há muito pouco ou nenhum desenvolvimento no código, uma vez que o software
preenche todos os seus objetivos corretamente. Mudanças serão aplicadas com extremo
cuidado. Pode permanecer nesta fase por vários anos, até que se torne obsoleto ou
substituído por outro melhor. Ainda assim o código permanecerá indefinidamente
disponível para servir a objetivos educacionais;

• Inativo: Projeto interrompido por falta de manutenção, movimentação de arquivos ou

abandono por parte de seus líderes (projeto órfão).

2 O Modelo de Desenvolvimento do Software Livre

Quando o desenvolvimento é feito por uma equipe pequena e local, ou por uma comunidade
de prática, onde os participantes estão fortemente ligados uns aos outros, o trabalho cooperativo
é certamente mais fácil, pois, nessas comunidades de prática, os membros podem aprender as
novidades de forma mais eficiente, resolver seus problemas de maneira mais tranqüila, e ainda
têm mais possibilidades de encontrar novas oportunidades de inovação (BROWN, 1991). Em
contraste, a coordenação de uma equipe numerosa e remota precisa ser inevitavelmente formal e
o gerenciamento das contingências sempre é uma tarefa muito mais difícil de gerenciar
(KRAUT, 1995).

Os projetos de desenvolvimento distribuído de software livre apresentam características

comuns, quando analisados do ponto de vista de construção cooperativa. Segundo Scharff
(2002), essas características comuns podem ser mapeadas em um framework que as organiza de
forma descritiva em um modelo que enfatiza a construção cooperativa.
A figura abaixo representa graficamente este framework conceitual, ilustrando os quatro
componentes principais de um projeto de software livre: As pessoas (participantes), o que eles
estão criando (objeto produzido), os processos empregados (processos colaborativos) e os meios
usados para comunicação e coordenação do projeto (tecnologias colaborativas).

Fig. 1. Framework conceitual do desenvolvimento do software livre

2.1 Os Participantes

São os componentes principais de um projeto de software livre. Sem um grupo de

participantes ativos não haverá software produzido ou este será apenas um pedaço de software
sem mudanças. A participação em um projeto de software livre abrange, além da produção do
código fonte em si, a contribuição em forma de idéias, feedbacks, correções e demonstrações.
Assim, os participantes podem ser simpatizantes, usuários, desenvolvedores, testadores,
documentadores ou evangelistas. Geralmente são ativamente envolvidos em todas as fases de
um projeto e trabalham de forma voluntária, motivados por uma mentalidade altruísta
(RAYMOND, 1999).
 Um estudo demográfico realizado por Boston (2002) com uma população de líderes e
desenvolvedores principais de projetos registrados no Sourceforge, revelou que entre os
entrevistados:

• 72,6% disseram que, quando estão programando, perdem a noção do tempo por estarem
motivados, sendo o tempo de sono considerado a principal contrapartida resultante da
participação em um projeto de software livre seguida de perto pela vida social;
• 44,9% são motivados a trabalhar no projeto pelo desafio intelectual que representa;
• Apenas 11,1% revelaram como motivação principal desbancar o software proprietário;
• 70% dos participantes são voluntários e não são financeiramente recompensados (direta
ou indiretamente) pelo seu trabalho no projeto;
• O tempo médio de trabalho gasto nos projetos foi de 14,9 horas por semana;
• 48,1% revelou que o maior benefício pessoal é o aumento do conhecimento;.
• 83% se identificaram com a comunidade hacker;
• 70,2 % dos participantes estão entre 22 e 38 anos, com a média em torno de 30 anos;
• A população provém de dezenas de países, e a maior parte vem EUA, Alemanha e
Reino Unido;
• 45,4 % dos participantes são programadores profissionais e a média de experiência de
11 anos;
• A maioria afirmou esperar do líder do projeto não só a realização de tarefas práticas
(criação da base de código original e contribuições constantes), mas uma boa visão de
longo prazo, iniciativa para diálogo, e disposição para integrar contribuições.

2.2 O Objeto Produzido

É o resultado da criação e dos refinamentos sucessivos. Ainda que a produção de código

fonte seja atividade central de um projeto de software livre, este não é o único produto final,
pois também figuram neste componente toda a documentação, os relatórios de defeitos, as
ferramentas de instalação e outros materiais de suporte. A versão do software recomendada para
uso em produção é chamada de distribuição padrão.

2.3 Os Processos Colaborativos

São convenções, procedimentos, práticas, papéis e responsabilidades que regem as interações

entre os membros de um projeto de software livre. Geralmente são difíceis de definir, pois são
conhecimentos tácitos, que a comunidade pode nem perceber que adota, ainda que certamente
estejam presentes e desempenhem um papel importante. Diferentes comunidades podem ter
diferentes perspectivas em relação à construção cooperativa, seja enfatizando a correção de
erros, promovendo novas funcionalidades ou criando referências de implantação.
Essas diferentes perspectivas afetam a natureza dos processos colaborativos (NAKAKOJI et
al., 2002), e normalmente aparecem quando são endereçadas as questões dos participantes e as
respectivas respostas da comunidade. São situações que invariavelmente remetem a novas
situações de colaborações, como por exemplo:

• Quando uma comunidade é intolerante com perguntas simples ou assume uma postura
defensiva perante uma sugestão, pode inibir os participantes;
• Se algum participante quer contribuir com uma correção ou melhoria, a comunidade deve
ter processos para absorver e encaminhar estas questões;
• É necessário que a comunidade esteja preparada para atender às múltiplas contribuições
em paralelo para vários pedaços ou módulo do software em questão;
• Finalmente é preciso ter um processo de adoção de mudanças na distribuição padrão, pois
se nenhuma contribuição for incorporada, os participantes podem se sentir discriminados
no projeto.
 Em um projeto de software livre, este ciclo de discussão, mudança e incorporação de
mudanças, por definição não termina nunca, pelo menos enquanto houver o projeto.
A técnica mais adotada nos projetos de software livre é a utilização de alguma forma de
liderança. Normalmente um líder de projetos é uma pessoa (ou um pequeno grupo de pessoas)
que participou da concepção da idéia ou de sua implementação inicial e que, principalmente,
goza de respeito e reconhecimento por parte dos outros membros da comunidade. O papel
desempenhado por um líder em um projeto de software livre pode variar muito porque depende
fortemente da pessoa que exerce esta liderança, a começar pela própria definição desta função,
referenciada por diversos nomes como “chefe”, “arquiteto-chefe”, “mantenedor”,
“coordenador”, etc. Em linhas gerais o líder provê direção e coerência para o projeto, resolve
eventuais disputas e mantém o controle da distribuição padrão, diferenciando-se assim de um
ambiente corporativo tradicional, cuja liderança normalmente está inserida em um contexto
hierárquico de uma “cadeia de comando”.
Outra técnica muito disseminada na organização de processos colaborativos de software livre
diz respeito ao framework do projeto em si, que paraleliza a organização da comunidade e a
arquitetura do software que está sendo desenvolvido. Entre as estruturas organizacionais típicas
temos as decomposições funcionais hierárquicas em módulos fracamente acoplados e um núcleo
central com módulos encaixáveis. Um importante objetivo do framework deste tipo é a
capacidade que oferece de, dado um problema específico, saber quais as mudanças que serão
necessárias e onde precisam ser feitas.
A divisão de tarefas, diferente do modelo tradicional, é feita de forma democrática e baseada
no interesse pessoal dos participantes, ainda que, quando muitas pessoas estejam trabalhando no
desenvolvimento de uma mesma parte do sistema, possa haver uma delegação de tarefas
visando evitar conflitos e que normalmente é explicitada através de uma lista de participantes e
de subprojetos ativos, criando uma percepção informal de quem está trabalhando no quê. É
importante frisar que cada participante contribui com o software livre por motivos pessoais e,
normalmente, poucos se dedicam a fazer tarefas consideradas “chatas” (como documentação ou
interfaces), ainda que sejam importantes.
Um conceito implícito do software livre que tem profundas implicações no processo
colaborativo é o compartilhamento de informações. Qualquer um pode ter acesso, ler ou
modificar qualquer código fonte no sistema. Este caráter público do código cria uma espécie de
pressão social que motiva a produção de código de qualidade, pois todos os participantes
querem que suas contribuições sejam reconhecidamente positivas para a comunidade (AOKI et
al., 2001).
Mudanças em um projeto de software livre acontecem o tempo todo e o desafio é manter um
software de qualidade sem ofender os membros da comunidade, pois críticas ou mudanças em
um pedaço de código podem ser interpretadas como uma crítica pessoal. A submissão não só de
erros e críticas, mas de correções e sugestões é importante para o desenvolvimento de uma
comunidade (PAVLICEK, 2000).

2.4 As Tecnologias Colaborativas

As tecnologias colaborativas desempenham duas atividades essenciais ao processo de

construção cooperativa. A primeira é dar aos participantes um canal de comunicação entre si e a
segunda fornece mecanismos de armazenamento, distribuição e acompanhamento de versões de
objetos produzidos pela comunidade. Ambas as atividades podem se basear em ferramentas
síncronas ou assíncronas e de forma independente da sofisticação técnica e das questões
temporais, ou seja, podem ser realizadas por contato físico face-a-face, videoconferência, bate-
papo eletrônico, cartas postais, etc..
2.4.1 Comunicação

A maioria dos projetos de software livre é virtual, com participantes espalhados ao redor do
mundo e, mesmo quando a maioria das pessoas de um projeto está em um único país, as
dificuldades de agendar reuniões com presença física são consideráveis, porém quando os
participantes se encontram fisicamente, estas reuniões são tão importantes quanto qualquer
outra tecnologia colaborativa (LANCASHIRE, 2001).
A Internet é um elemento indispensável na criação e desenvolvimento de projetos de software
livre. Como os projetos de software livre tiveram sua origem e disseminação em paralelo com
origem e disseminação da própria Internet, as principais tecnologias colaborativas utilizadas
passam pelas ferramentas disponíveis nessa rede. Sobre esse aspecto Yamauchi (2000) oferece
uma visão geral dos mecanismos de comunicação usados em projetos de software livre e afirma
que, apesar da tendência acadêmica da pesquisa em CSCW apontar para a produção de
ferramentas complexas para suportar trabalho cooperativo desta natureza, os projetos de
software livre sobrevivem e comprovam a eficácia do uso de ferramentas e meios de
comunicação simples e disponíveis há muito tempo na Internet, como o email, as listas de
distribuição, os newsgroups, os chats e os sites repositórios de conteúdo.
Os canais de comunicação baseados na Internet são relativamente baratos (quando
comparadas às ligações telefônicas internacionais, reuniões com presença física e
videoconferência por satélites) e aqueles com características assíncronas são importantes para
minimizar o problema das fronteiras geográficas e dos fusos horários, especialmente na
coordenação de projetos de maior porte, que aliados à capacidade de alcance mundial da
Internet faz com que os projetos de software livre atraiam muito mais participantes do que
conseguiriam se fossem grupos locais ou geograficamente limitados.

2.4.2 Armazenamento e controle de versões e erros

Os mecanismos de armazenamento, distribuição e acompanhamento de objetos produzidos

pela comunidade também utilizam ferramentas disponíveis na Internet. A distribuição padrão
normalmente é disponibilizada em website conhecido, que funciona como repositório daquela
versão (estática) até que seja substituída por outra mais nova.
Cada vez mais projetos de software livre estão adotando ferramentas de controle de versão
para gerenciamento do conteúdo do objeto produzido. Essas ferramentas são vistas como uma
extensão natural do processo de desenvolvimento, permitindo que se possam realizar
modificações paralelas de forma coerente e padronizada, através de um mecanismo
automatizado para identificar e controlar as modificações realizadas nos arquivos de um projeto
ao longo do tempo, garantindo a integridade e a rastreabilidade das modificações.
Para enviar as modificações feitas em um objeto, um participante não precisa enviar todo o
conjunto de arquivos, pois as ferramentas específicas normalmente extraem a diferença do
conjunto original para o modificado e somente o delta precisa ser enviado. Um componente da
mesma ferramenta, do outro lado, se encarrega de aplicar as modificações e gerar a nova versão.
Esse recurso é importante na economia do uso da rede, pois os arquivos com as diferenças
normalmente são substancialmente menores do que as versões completas dos arquivos.
Existem diversas ferramentas em uso nos projetos de software livre, como BitKeeper8,
Subversion9 e Revision Control System (RCS10), porém a mais utilizada atualmente é a
Concurrent Versions System (CVS11), um software (livre) relativamente simples, que foi

8 http://www.bitkeeper.com/
9
http://subversion.tigris.org/
10 http://www.cs.purdue.edu/homes/trinkle/RCS/
11 http://ximbiot.com/cvs/wiki/
desenvolvido suportar grupos de trabalho voltados para o desenvolvimento de projetos de
construção cooperativa, seja de códigos fonte, documentação, arquivos de configuração, etc.
O CVS surgiu em 1986 como uma coleção de scripts para melhorar o RCS e depois se
transformou em uma ferramenta própria, que funciona segundo o modelo copy-modify-merge
(copia-modifica-integra) que, baseado no trabalho off-line, permite que múltiplos participantes
efetuem, de forma independente, alterações em suas cópias locais do objeto, uma vez que não
utiliza mecanismos de exclusão mútua. A seguir estão apresentados os principais aspectos do
fluxo de trabalho do CVS, extraído de Reis (2001):

Fig. 2. Diagrama de fluxo de trabalho com o uso do CVS (REIS, 2001).

• Repositório: Consiste em um conjunto de arquivos mantido em um local central

(normalmente um servidor conectado à Internet, que permita acesso anônimo). Opera,
principalmente, segundo um modelo de incrementos, ou seja, armazena as cópias mais atuais
dos arquivos do projeto, e as diferenças entre esta e as versões anteriores.

• Cópia Local: Qualquer participante interessado solicita ao servidor, através de uma

ferramenta front-end, uma cópia do objeto em uma determinada versão desejada. Uma vez
criada esta cópia local, também chamada de sandbox, o participante tem acesso total aos
arquivos que deseja trabalhar e pode aplicar suas modificações. O participante pode sempre
solicitar ao servidor uma atualização de sua base de objeto local, recebendo as alterações que
foram integradas ao repositório principal após a criação da sua cópia local.

• Integração: Ao alterar o código, o participante está livre de qualquer interação com o

repositório e quando julgar que sua versão alterada está pronta para ser integrada à base
principal, usa a ferramenta front-end para submeter o objeto de volta ao repositório central. A
esta ação de integração é dado o nome de checkin ou merge.

• Resolução de conflitos: Se múltiplos participantes alteram o mesmo trecho de um objeto,

conceitualmente ocorre um conflito. O processo de resolução de conflitos é feito da seguinte
forma: O primeiro participante a integrar um objeto ignora, a princípio, o fato de que outros
estejam trabalhando no mesmo trecho. Cada participante subseqüente que iniciar uma ação de
merge receberá do repositório a mensagem de que precisa atualizar a sua versão local (já que
 uma integração no mesmo arquivo foi feita pelo primeiro participante). Neste momento, ao
atualizar a cópia local a ferramenta irá informar que houve alterações provindas do
repositório no mesmo trecho de código alterado localmente. Estes trechos do código são
marcados com indicadores que diferenciam a versão do repositório da versão local. O
participante precisa analisar com cuidado as alterações e decidir de que forma o código deve
ficar; ele pode resolver o conflito removendo uma das versões, mas freqüentemente a opção
correta é integrar mudanças de ambas as versões num novo trecho único.

• Versões: Cada arquivo modificado no repositório recebe uma versão numérica. É possível
criar aliases (apelidos) que abstraiam as versões de um conjunto de arquivos em um
determinado instante do tempo. Com isso, é possível reverter alterações de arquivos
individuais para versões anteriores, e também regenerar uma versão completa do repositório
em um determinado momento. Do ponto de vista do participante, o CVS permite que se
comparem facilmente as alterações feitas na sua cópia local com qualquer versão integrada
no repositório, e torna possível reverter alterações integradas no repositório central para
versões anteriores. Este último recurso é normalmente utilizado para remover alterações
problemáticas que tenham causado algum um defeito ou regressão funcional no objeto
produzido.

• Branches: Além das versões alternativas da base de objeto principal, o CVS permite que se
crie uma linha de versões paralelas à principal. Resumidamente, é estabelecido um branch
(bifurcação) a partir do código principal, chamado trunk (tronco). Alterações integradas sobre
este branch são isoladas, não refletindo no tronco. É possível criar um número arbitrário de
branches e cada um deles terá um nome simbólico, que o participante especifica ao usar a
ferramenta. Eventualmente alterações de um branch podem ser “aplicadas” no trunk
principal. Esta operação tem o nome de merge (incorporação). É prática comum, entre os
projetos de software livre, manter branches estáveis conforme apresentado a seguir:

Fig. 3 No exemplo acima, o branch estável foi criado logo após o lançamento da versão 0.9, e
mantido separado da versão principal (head), recebendo apenas reparos de bugs. Duas novas
versões estáveis foram lançadas (1.0.1 e 1.0.2). O desenvolvimento e a adição de
funcionalidades continuam normalmente na versão principal. (REIS, 2001).

• Branch Estável: Onde tendem a ser integradas apenas correções de erros, ainda que esta
regra não seja explícita. Esta versão é tratada de forma especial, e usuários têm
expectativas de que entre uma versão e outra do branch estável não ocorram regressões.

• Branch Instável: Onde são aceitos tanto reparos de erros quanto adições de funcionalidade.
Não há uma garantia de que as versões funcionem de forma confiável, especialmente nas
primeiras versões lançadas neste ciclo. Com o passar do tempo, é declarada uma
“moratória” à adição de funcionalidades (o chamado feature freeze), e a versão instável
passa por um período de estabilização. Ao final deste período, uma versão considerada
“estável o suficiente” é batizada de “nova versão estável”, e um novo ciclo se inicia.
 Além de manter versões estáveis, branches são utilizados para implementar mudanças que
tenham grande impacto sobre a base do objeto. Como visto anteriormente, cada participante
trabalha em relativo isolamento, com sua cópia local. Se não existissem branches, a integração
de mudanças extensas seria bem difícil, já que por grandes períodos de tempo corre-se o risco
de outro participante ter alterado o mesmo trecho. Utilizando um branch, é possível desenvolver
a alteração paralelamente, e integrar mudanças no trunk principal de forma incremental.
As ferramentas que documentam e controlam os erros encontrados (e suas correções) são
muito importantes para qualidade e a produtividade dos projetos de desenvolvimento distribuído
de software. Cada erro, informado por um usuário participante, é registrado em um informe
individual e cada informe possui um ciclo de vida que vai desde a sua criação, no momento em
que é informado, até seu fechamento, quando o erro é reparado no objeto produzido. Essas
ferramentas, que normalmente têm interface Web ou via email permitem, em geral, um bom
gerenciamento dos erros, com capacidade de localização, confirmação e detecção de erros
duplicados ou que não se apliquem à versão atual do objeto.
A ferramentas de controle de erros mais usada em projetos de software livre atualmente é o
Bugzilla12, que nasceu como ferramenta de controle de alterações do projeto do browser
Mozilla13, no qual é usada em todas as etapas do processo de desenvolvimento, desde a
definição de funcionalidades até o projeto, implementação e revisão de alterações. O Bugzilla
possui, além do registro de informes de erros, funcionalidades de priorização de atendimento,
assinalamento de erros aos participantes apropriados, configuração de dependências entre os
erros, organização de erros por produto ou componentes e, principalmente, a capacidade de
revisão de código, na qual cada informe pode ser vinculado a uma alteração de código
provisória, que deve ser revisada e aprovada para integração na base de código principal. Outra
ferramenta comumente utilizada é o GNATS14.

2.5 As Inter-relações

Nenhum dos componentes deste framework conceitual existe de forma isolada e assim como
cada aspecto muda com o tempo, o mesmo acontece com as relações. A seguir estão listadas as
inter-relações mais encontradas entre os componentes:

2.5.1 O Uso

O objeto produzido em um projeto de software livre é um pedaço de software de computador,

que as pessoas irão baixar e usar em um contexto específico. O uso é um tipo de atividade
reflexiva, na qual o usuário cria um modelo de percepção das limitações e pontos fortes do
software em uso e identifica mudanças e características que acreditam que o software deveria
ter para atender suas necessidades e preferências. Quando mais o software estiver relacionado
com cotidiano do usuário, principalmente relacionado ao seu trabalho, mais chances existem
desse usuário querer contribuir com críticas e sugestões para o desenvolvimento do software.

2.5.2 A Facilitação Social

O processo colaborativo emerge dos participantes ao mesmo tempo em que influencia suas
ações. A facilitação social é a maneira com que os processos colaborativos encorajam as
pessoas a se envolverem no desenvolvimento e evolução do projeto. Por exemplo, o processo
colaborativo pode requerer que as pessoas que corrijam erros anexem seus nomes às correções.
Em alguns grupos isso pode ser um grande incentivo à correção de erros porque o
reconhecimento pessoal e os elogios motivam as pessoas a contribuir cada vez mais. Em outro
exemplo, se um líder que precisa aprovar todas as mudanças nunca aceita as sugestões da

12
http://www.bugzilla.org
13 http://www.mozilla.org
14 http://www.gnu.org/software/gnats/gnats.html
comunidade, seus participantes perceberão que suas contribuições não estão recebendo o devido
reconhecimento e poderão abandonar o projeto. Em suma, a facilitação social se refere às
reações dos participantes ao contexto social do projeto.

2.5.3 A Facilitação Técnica

O processo colaborativo está intimamente relacionado com as tecnologias colaborativas

empregadas. Algumas vezes as limitações da tecnologia influenciam no processo colaborativo
em si. Por exemplo, as equipes que dependem da comunicação por email, muitas vezes têm
dificuldade de encontrar mensagens importantes devido ao volume e a inerente falta de estrutura
dos sistemas de correio eletrônico. Para compensar essa deficiência, o processo colaborativo
pode especificar que quando a palavra “ANNOUNCE” aparece entre colchetes no início do
assunto da mensagem, significa que se trata de um anúncio importante e que todos devem ler.
Em alguns grupos são criados filtros automáticos que varrem as mensagens em busca dos
identificadores de anúncios importantes que, uma vez identificados, são imediatamente postados
em uma página de anúncios no website do grupo. Neste caso uma tecnologia colaborativa foi
adaptada para reforçar um processo colaborativo de divulgação de anúncios importantes. A
facilitação técnica se refere às conexões entre os processos colaborativos e as tecnologias que
suportam esses processos.

2.5.4 Gerenciamento das Mudanças

O gerenciamento das mudanças está relacionado ao uso das tecnologias de comunicação,

armazenamento e controle de versões e de erros da distribuição padrão. Como os objetos
produzidos devem estar publicamente disponíveis e fáceis de serem acessados, a tecnologia
colaborativa deve prover uma maneira confiável de se armazenar e disponibilizar esses objetos.
A estrutura dos repositórios da distribuição padrão geralmente reflete as mudanças que
ocorreram ao longo do tempo que, junto com os padrões de nomenclatura (numeração de
versões) e com as tecnologias de controle de versão e de erros, ajudam no rastreamento das
mudanças no objeto produzido, facilitando a volta para uma versão anterior caso problemas
sejam encontrados após uma mudança na distribuição padrão.

2.5.5 As Contribuições

Contribuição são os processos nos quais os indivíduos propõem melhorias ou extensões no

projeto através de mudanças relacionadas à distribuição padrão do objeto produzido. A forma
como uma contribuição acontece varia de projeto para projeto, mas certamente envolve todos os
aspectos e componentes do framework. Participantes criam mudanças, que passam por alguns
processos colaborativos onde o grupo decide aceitar, refinar ou rejeitar as contribuições.
Durante esses processos, a tecnologia colaborativa coordena a comunicação e provê o suporte
técnico para rastrear as múltiplas versões de uma mudança. Se uma contribuição é aceita, passa
então a ser incorporada ao objeto produzido e atualizam-se todas as referências. Assim, apesar
das contribuições serem atividades desempenhadas por participantes, são fortemente
influenciadas pelo objeto, pela tecnologia e pelo contexto social dos processos colaborativos.

3 O projeto de desenvolvimento do Linux

3.1 O Cerne da Questão

O Linux é um kernel (cerne ou núcleo) de sistema operacional multitarefa preemptivo

baseado na Application Program Interface (API) definida pelo padrão Portable Operating
Systems Interface (POSIX15). É um sistema multiplataforma que suporta mais de dez
arquiteturas de hardware diferentes (DEURZEN, 2004), sendo a mais importante, do ponto de
vista do desenvolvimento e uso, a arquitetura da Intel, utilizada na maioria dos computadores
pessoais.
Moon (2000) faz uma análise histórica do desenvolvimento do kernel e coloca claramente a
importância do desenvolvimento em comunidade, fornecendo estatísticas históricas da
participação de desenvolvedores externos:

“ ...em duas semanas do anúncio de Torvalds em Outubro de 1991, 30 pessoas tinham contribuído
com cerca de 200 informes de erros, contribuições de utilitários, drivers e melhorias para serem
adicionadas ao kernel [...] em Julho de 1995, mais de 15.000 pessoas de 90 países em 5 continentes
tinham contribuído com comentários, informes de erro, correções, alterações, reparos e melhorias.”
(MOON, 2000)

O primeiro release da primeira versão do kernel possuía um pouco mais de três mil linhas de
código, distribuídas em 88 arquivos escritos em linguagens C e Assembly. Atualmente o kernel
está no release 6 da versão 2, cujo tamanho ultrapassa a quantidade de dois milhões e meio de
linhas de código, distribuídos entre milhares de arquivos. O kernel fica disponível na Internet16 e
uma visão da sua estrutura atual pode ser vista em um mapa disponível no website do projeto
Kernel Mapper17
O desenvolvimento do kernel costuma ocorrer em duas séries separadas: uma delas é a de
produção, ou estável, cujo segundo número (de release) é sempre par: 2.0.x, 2.2.x, 2.4.x, 2.6.x,
etc. A outra série é a de desenvolvimento, que não é garantida para ser utilizada em sistemas em
produção, e tem o número de release sempre ímpar: 2.1.x, 2.3.x, 2.5.x etc. Quando a série de
desenvolvimento atinge a maturidade, ela muda de numeração e se transforma na nova série de
produção (feature freeze), e uma nova série de desenvolvimento tem início. O terceiro número
(x) refere-se ao patch (remendo) de correção em uso na versão.
O desenvolvimento do Linux segue a filosofia preconizada por Raymonds (1999) de “Faça
releases o quanto antes e libere-os com freqüência. E ouça o que os seus usuários têm a dizer”.
O kernel ainda hoje tem em Torvalds seu expoente máximo, que toma as principais decisões
e define a filosofia geral do projeto. Entretanto, cada release tem sempre um mantenedor
responsável, que aprova cada aperfeiçoamento e garante que não haja versões conflitantes. O
primeiro mantenedor do kernel estável foi próprio Linus Torvalds, seguido pelo inglês Alan
Cox (versões 2.0 e 2.2), depois pelo brasileiro Marcelo Tosatti (versão 2.4) e hoje pelo inglês
Andrew Morton (na atual versão 2.6). Torvalds e Cox continuam responsáveis por supervisionar
as versões do kernel que ainda estão em desenvolvimento.
Em julho de 2003, Torvalds passou, pela primeira vez na vida a trabalhar oficialmente e
integralmente dedicado ao projeto do Linux, como contratado da Open Source Development
Laboratories (OSDL18), uma entidade voltada para a disseminação internacional do Linux. A
OSDL foi fundada no ano 2000, com sedes nos Estados Unidos e Japão, e é mantida por
investimentos de cerca de 50 empresas como Cisco, HP, IBM, Intel e Sun. Posteriormente Cox
e Morton também passaram a fazer parte do OSDL.

3.2 Comunicação e Percepção

O projeto do desenvolvimento do Linux sempre foi, levando-se em conta o tamanho do

objeto produzido e do número de participantes envolvidos, um dos projetos mais minimalistas
em relação à infra-estrutura de desenvolvimento.
A lista de distribuição de emails linux-kernel mailing list (LKML) é o fórum central de
discussão entre os participantes do projeto de desenvolvimento do Linux, incluindo o próprio

15 http://www.pasc.org/
16 http://www.kernel.org/
17 http://kernelmapper.osdn.com/
18 http://www.osdl.org/
Torvalds, que sozinho recebe cerca mais de 200 emails diretos por dia, somente dos
participantes do projeto. A intensidade dessa lista dá uma boa idéia do que seja o
desenvolvimento no modelo “Bazar”, pois apenas em uma semana comum de trabalho é normal
alcançar um volume superior a 5 MB de mensagens, sejam relacionadas aos diversos
subprojetos em andamento ou a um conjunto de novas idéias ou mesmo às velhas questões
recorrentes e suas discussões persistentes, todas pertinentes ao assunto do desenvolvimento do
kernel (KUWABARA, 2000).
O conhecimento, por parte da comunidade, do trabalho produzido pelos participantes fica
registrado no arquivo de créditos que sempre acompanha o kernel. Trata-se de um arquivo de
texto simples onde o participante inclui suas informações pessoais e principais áreas de
contribuição, segundo o seguinte modelo:

Fig. 4 A estrutura do arquivo de créditos do Linux.

As informações são colocadas pelos próprios participantes, mas precisam
ser aceitas pelos mantenedores do kernel (TUOMI, 2004).

Ainda que não haja uma hierarquia definida e que todos trabalham de acordo com interesses e
aptidões pessoais, sabe-se que entre Torvalds e a comunidade de participantes existe um grupo
de consultores técnicos, informalmente chamados de “lieutenants” (“tenentes”), que são
participantes que ganharam o status de programadores competentes e com expertise de
comprovada importância para o projeto através de anos de participação. Apesar desse grupo não
existir de maneira formal, sua composição é aceita pela comunidade como uma espécie de
“seleção natural”, ainda que as informações e opiniões sobre quem faz (ou deveria fazer) parte
do grupo divergem entre os participantes do projeto (KUWABARA, 2000).

Fig. 5 A estrutura do Linux mostrada através do fluxo de informações.

Esta estrutura mostra que os “lieutenants" representam uma espécie de suporte da cadeia de valor e não uma camada,
pois os participantes podem interagir diretamente com Torvalds. Trata-se de uma estrutura em rede, na qual todos os
participantes têm acesso a todos os nós do sistema. O fluxo da informação também abrange toda a rede, uma vez que
toda a comunicação se da através da lista de distribuição linux-kernel mailing list (DAFERMOS, 2001).

Quando um novo participante entra na lista LKML, assim como acontece em outras listas na
Internet, é sempre convidado a ler a documentação de perguntas e respostas mais freqüentes
(LKML FAQ19), que nesse caso, entre suas questões principais, esclarece algumas regras
implícitas que regem o bom funcionamento da lista, a saber:

• Mantenha-se no assunto. É uma lista sobre o kernel do Linux, para programadores;

• Use somente o idioma inglês!;
• Não coloque mensagens em formato HTML, apenas em modo texto;
• Se você usa outro sistema operacional, esteja seguro de que seu programa de email não
usa Charset="Windows*" ou suas mensagens serão bloqueadas;
• Se for fazer uma pergunta, antes procure ver se já não há uma resposta na documentação
ou no arquivo da lista. Lembre-se que 99% das perguntas desta lista já foram respondidas
pelo menos uma vez. Normalmente a primeira resposta é a mais completa, desta forma a
resposta armazenada será sempre melhor do que qualquer outra que receba de alguém
que já respondeu a mesma pergunta uma dúzia de vezes.
• Seja preciso, claro e conciso ao fazer uma pergunta, comentário, anúncio de bug,
sugestão de correção ou qualquer outra coisa. Coloque fatos, evite opiniões.
• Seja gentil, não há necessidade em ser rude. Evite expressões que possam ser
interpretadas como agressivas em relação aos outros participantes da lista, mesmo que o
assunto tratado seja controverso ou particularmente relevante para você;
• Não se arraste em controvérsias. Não tente impor a última palavra. Você até poderá ter a
última palavra, mas certamente terá perdido toda sua simpatia;
• Uma linha de código vale mais do que mil palavras. Se está pensando em uma nova
funcionalidade, implemente-a primeiro e só depois coloque-a na lista para comentários;
• É fácil criticar o código dos outros, mas quando se escreve código pela primeira vez não
é fácil. Se você encontrar um erro ou alguma coisa que possa ser melhorada, não coloque
imediatamente uma mensagem do tipo “Este pedaço de código é um lixo, como foi parar
dentro do kernel?” Ao invés disso, entre em contato com o autor do código, explique a
questão e faça o entender de uma maneira simples e humilde. Faça isso algumas vezes e
será reconhecido como um bom depurador de códigos. E quando escrever o seu pedaço
de código, os outros irão prestar atenção no que fez;
• Não se aborreça e responda com veemência os iniciantes que fazem perguntas erradas.
Isso aumenta o ruído na lista. Envie-os um email privado apontando a fonte da
informação que procuram (por exemplo, esta FAQ);
• Não coloque nenhuma mensagem religiosa ou política, inclusive em sua assinatura de
email. Ao fazer isso no corpo da mensagem as pessoas irão se aborrecer, pois é um
assunto fora do objetivo da lista, além do desperdício de uso da banda de rede (lembre-se
que apesar de estarmos no século XXI, muitas pessoas ainda pagam pelo tempo de uso na
Internet); Se o fizer em sua assinatura de email, apesar de ser menos irritante, certamente
fará a maioria das pessoas ignorarem a sua mensagem. Deixe o palanque em casa. E se
quiser ser levado a sério, limite-se aos assuntos técnicos.

Apesar de ser um projeto virtual, com participantes espalhados ao redor do mundo, a

comunidade de desenvolvimento do Linux se reúne pessoalmente em eventos anuais informais
como o Kernel Summit20 para trocar experiências, combinar as agendas e próximos passos.

19 http://www.tux.org/lkml/
20 http://lwn.net/Articles/KernelSummit2006/
3.3 Controle de Versões e Erros

O projeto do desenvolvimento do Linux sempre foi, levando-se em conta o tamanho do

objeto produzido e do número de participantes envolvidos, um dos projetos mais minimalistas
em relação à infra-estrutura de desenvolvimento. Até a versão 2.4, incrivelmente, apenas listas
de discussão e emails eram utilizadas por sua comunidade de desenvolvimento.
No de final de 2002, no entanto, foi lançado o Kernel Bug Tracker21 sistema para controle de
erros, baseado na ferramenta Bugzilla. Este sistema está hospedado em um website no OSDL,
com a administração do banco de dados de erros sendo realizada pela IBM.
Outro recente projeto importante na manutenção da qualidade é o Kernel Janitor22, que
objetiva “limpar” constantemente o código-fonte do kernel através da busca e eliminação de
erros em trechos antigos através do reaproveitamento de correções recentes, originalmente feitas
para outros trechos do código do kernel.
A implantação de uma ferramenta automática de controle de versão (e integração) do objeto
produzido ainda demorou a acontecer no Linux, pois Torvalds sempre se opôs à idéia, uma vez
que somente confiava tal tarefa aos mantenedores credenciados (SHAIKH, 2003).
Com o número, cada vez maior, de mudanças sugeridas pelos participantes, entretanto, o
projeto precisou adotar uma ferramenta de controle de versões. Torvalds, que nunca quis
trabalhar com o CVS, apesar de alguns participantes usarem essa ferramenta extra-oficialmente,
decidiu pelo uso do BitKeeper, uma ferramenta que, apesar de ser tecnicamente superior à outra,
gerou uma enorme polêmica, com discussões dentro (e fora) da comunidade pois, ao contrário
do CVS, o BitKeeper não possuía a licença de uso segundo os conceitos de software livre
preconizados pela GPL (SHAIKH, 2003). Ideologias à parte, o controle de versões do kernel23
com BitKeeper proporcionou um ganho significativo de produtividade em um sistema que fica
cada dia mais complexo. Como exemplo, somente nos nove primeiros meses do ano de 2003
ocorreram mais de 12 mil mudanças no código do kernel, efetuadas por mais de 550
participantes (SEARLS, 2003). No início de 2005, entretanto, o próprio Linus Torvalds
começou o desenvolvimento de uma nova ferramenta, chamada Git24, que foi disponibilizada
sob a GPL e passou a ser a ferramenta usada na manutenção do kernel, sendo hoje também
aplicada em outros projetos de software.

3.2 A Padronização das Distribuições do Linux

Nos primeiros anos de existência do Linux, Torvalds simplesmente disponibilizava a versão

estável do kernel e alguns comandos bem básicos. O usuário interessado em usar o sistema,
entretanto, tinha que, além do baixar o kernel pela Internet, também arranjar todos os demais
programas complementares, compilar tudo e acertar os arquivos de configuração para então
poder proceder com a instalação. Como isso é trabalhoso até mesmo para um hacker iniciado no
assunto, surgiram as distribuições, baseadas na idéia de se disponibilizar os programas
principais pré-compilados, de tal forma que o usuário só precisasse pegá-los (em CD-ROM ou
via Internet) e instalá-los em sua máquina.
Hoje existem dezenas de empresas e instituições, ao redor do mundo, que mantém centenas
de distribuições e as principais diferenças entre elas são:

• O sistema de empacotamento do software;

• A estrutura dos diretórios. Teoricamente todas as distribuições seguem um mesmo padrão,

o Filesystem Standard (FSSTND) mas esse padrão é bem relaxado e, especialmente os
arquivos de configuração do sistema, são bastante diferentes entre as distribuições;

21 http://bugme.osdl.org/
22
http://janitor.kernelnewbies.org/
23 http://linux.bkbits.net/
24 http://git.or.cz/
 • A biblioteca básica libc, que contém funções básicas para o funcionamento do sistema
operacional. Quando uma nova versão dessa biblioteca é lançada, algumas distribuições a
adotam imediatamente, enquanto outras, mais conservadoras, aguardam um pouco. Nesse
meio-tempo, alguns programas podem funcionar em algumas distribuições e não em
outras.
A diversidade de distribuições de Linux, que foi providencial na disseminação do sistema em
seus primeiros anos de vida, teve como conseqüência uma falta de padronização que terminou
por criar problemas para a comunidade Linux. Entre outras questões, durante muito tempo era
difícil obter versões pré-compiladas de aplicativos, exceto se tivessem sido preparadas
especificamente para a distribuição de Linux que o usuário estivesse utilizando, o que exigia um
conhecimento da instalação de programas a partir da compilação de seu código-fonte, o que se
constituía numa grande barreira ao uso e adoção do Linux.
Com a entrada de participantes de maior porte no mercado criado em torno do Linux surgiu a
necessidade de convergência em torno de um padrão, sem restringir a possibilidade de
diferenciação entre as distribuições - mantendo assim a liberdade, sem permitir a fragmentação
do Linux em uma série de alternativas incompatíveis entre si, como ocorreu com o sistema
operacional UNIX. Assim, em 2001, foi criado o Linux Standard Base (LSB25), que visa
desenvolver e promover um conjunto de padrões para aumentar a compatibilidade entre as
distribuições de Linux. O LSB é dividido em três componentes principais: a especificação do
sistema, as ferramentas de teste e um exemplo de distribuição para referência. A especificação
do sistema define a chamada Binary Application Interface (BIA), que é o ambiente que toda
aplicação desenvolvida, levando em conta o LSB, deverá esperar encontrar em qualquer
distribuição de Linux, incluindo o nome e localização dos arquivos, versão das bibliotecas, e
diversos outros fatores. Apesar do padrão LSB ter sido adotado pelos principais participantes do
mercado Linux, incluindo as principais distribuições, os desenvolvedores de aplicativos e as
empresas de suporte, ainda é possível encontrar aplicações que somente funcionam em
determinadas distribuições do Linux.
Os esforços de padronização são coordenados pelo Free Standards Group (FSG26), que além
de cuidar do LSB, também promove outros padrões do Linux relacionados à
internacionalização, clusterização, impressão, etc.

3.3 O Projeto de Documentação do Linux

Visando diminuir a barreira de entrada do uso do Linux através da disponibilização de

informações para facilitação do uso, surgiu o Linux Documentation Project (LDP27), um projeto
cujo foco está na produção de documentação padronizada do Linux. Existem quatro tipos de
objetos produzidos no LDP:

• Guias, que são livros com informação detalhada e aprofundada do sistema, segundo um
referencial variado (guia usuário, do programador, do administrador do sistema, etc.);

• HOWTOs, que são como “receitas de bolo” para execução de tarefas comuns no uso do
sistema, como a instalação, gerenciamento de caixas postais, habilitação de recursos de
segurança, etc;

• Man pages, que são as páginas do manual on-line, que contém informações a respeito dos
programas, funções e utilitários de que fazem parte do sistema;

25
http://www.linuxbase.org/
26 http://www.freestandards.org/
27 http://www.tldp.org/
 • FAQs (Frequently Asked Questions) que são as perguntas e respostas mais comuns
colecionadas ao longo da existência do projeto e que são divididas em categorias
específicas (Linux, projeto LDP, intgração com outros sistemas operacionais, etc.)

Além dos objetos descritos acima, o LDP coordena a tradução do conteúdo produzido para
dezenas de idiomas, inclusive o português do Brasil, onde utiliza um vocabulário padronizado
com milhares de entradas (entre termos simples, frases-exemplo reais e acrônimos). Os termos e
suas traduções foram obtidos de outros glossários em papel, web, e termos discutidos (em várias
listas de discussão) quando da tradução de outros livros e programas (ou seja, a experiência de
inúmeros tradutores).

4 Desafios para o Software Livre

O software livre vem ganhando espaço sistematicamente no cenário mundial e talvez esse
interesse esteja crescendo mais rápido do que a consciência sobre a filosofia na qual é baseado,
e isto pode conduzir a problemas.
Como já foi dito na introdução deste texto, trata-se de um assunto multifacetado, que contém
questões relacionadas a diversos assuntos (engenharia de software, propriedade intelectual,
etc.). Do ponto de vista dos aspectos relacionados à construção cooperativa, Rothfuss (2002)
indica que esses fatores são decorrentes, principalmente, da falta de organização formal, e
podem ser resumidos conforme a seguir:

4.1 Redundância de Esforços

A coordenação em projetos de software livre é relativamente pouca. Grupos independentes

muitas vezes desenvolvem tarefas similares em paralelo sem conhecer o trabalho de seus pares,
gerando um consumo adicional de recursos. Não há dúvida que o efeito colateral benéfico disso
é o aumento do número de opções a escolher e que as diferentes alternativas melhoram a
qualidade final do software. Entretanto estes trabalhos paralelos dificultam a escolha de
alternativas por parte dos usuários, o que pode terminar em conflitos de posicionamento no
mercado, gerando discussões apaixonadas, quase religiosas, com potencial de provocar “rachas”
e enfraquecer o movimento de disseminação do software livre.

4.2 Problemas de Comunicação

Ainda que o inglês seja o principal idioma usado nos projetos de software livre, certamente
não é o idioma nativo de todos os participantes. Isso pode acarretar em diversos problemas de
entendimento, que tendem a piorar conforme os projetos aumentem de número de participantes
ao redor do mundo.
Outro problema de comunicação, que também está relacionado à expansão, diz respeito ao
volume e à relevância do conteúdo das mensagens, que ainda são a base da comunicação dos
grupos de desenvolvimento. É comum perceber em grupos de discussão, cada vez mais, os
participantes reclamando da falta de etiqueta e boas maneiras em meio a uma profusão de
informações inúteis. Isso certamente é menor nos grupos moderados, mas é inegável que a
relação sinal-ruído na Internet não é das melhores atualmente e está piorando cada vez mais.

4.3 Senso de Prioridade

Em projetos de software livre, dificilmente as decisões importantes e profundas são tomadas

com a agilidade necessária. Isso acontece devido à natureza distribuída do processo, que aliada
a uma liderança tênue, pode impossibilitar a resolução de uma prioridade ou distorcê-la em
direção às tendências pessoais de algum participante influenciador. Uma necessidade de
mudança mais profunda normalmente desencadeia uma seqüência interminável de argumentos
favoráveis e contrários, uma vez que ninguém pode forçar sua opinião aos demais e todos se
sentem no direito de opinar, mesmo aqueles que não têm o conhecimento ou a preparação
necessária para analisar suas considerações à luz de outras questões.

4.4 Proliferação de “grupos fechados”

Os projetos de software livre não têm regras formais ou convenções escritas. As relações
entre seus participantes são regidas por um conjunto de regras consuetudinárias – não escritas,
baseadas em costumes – criando uma “netiqueta” (regras de etiqueta na Internet). Dessa forma,
os novos membros têm que gradualmente aprender as regras informais e, de certa forma, são
medidos pelo sucesso em reagir às dicas passadas pelo grupo. As comunidades, principalmente
as mais antigas, são entrosadas e conseguem melhorar a comunicação entre os membros através
do compartilhamento de contextos culturais, porém acabam por dificultar ainda mais a
integração do grupo com os recém chegados. À medida que os participantes competem por
atenção e reconhecimento de talento, essas barreiras são danosas ao projeto, principalmente aos
menores, que ainda se estruturam. O desenvolvimento de software livre é um processo de
aprendizado, onde as partes envolvidas contribuem para (e aprendem da) comunidade e esse
equilíbrio é importante. Edwards (2000) chamou este fenômeno de “Comunidades
Epistêmicas”.

4.5 Falta de Foco

De acordo com estudos cerca de 70% dos participantes de software livre gastam 10 horas ou
menos por semana em trabalhos relacionados ao projeto e essas horas são, em sua maioria,
gastas durante à noite ou nos finais de semana (BERLECON, 2002). O baixo nível de
participação pode introduzir problemas de comunicação, dado que muitos participantes têm
dificuldade em acompanhar todos os desenvolvimentos realizados no projeto. Essas
circunstâncias certamente dificultam o foco dos participantes no desenvolvimento do projeto.
Normalmente o trabalho é conduzido aos pedaços e finalizado apenas após um longo período. O
esforço dispensado em estar a par de todas as questões é geralmente tão grande que sobra pouco
tempo para as contribuições efetivas. Muitos participantes perdem o interesse ou são absorvidos
por outros comprometimentos externos, deixando muitos projetos pela metade.

4.6 Dependência de Pessoas-Chave

Muitos projetos de software livre dependem de poucas pessoas. Taurion (2004) afirma que
10% dos participantes contribuem com 78% do código; o segundo décimo, com 12%, o terceiro,
com 3%; os outros, com menos de 1% cada. Existem algumas explicações plausíveis para este
fenômeno. A mais óbvia é que o nível de conhecimento necessário para se analisar e entender
um código-fonte de um sistema grande requer treinamento e experiência. O esforço em adquirir
este conhecimento não é efetuado pela maioria dos participantes. Outra explicação está
relacionada ao nível de reconhecimento que os participantes esperam receber por suas
contribuições. Apenas um número pequeno de participantes acaba se tornando amplamente
reconhecido por suas contribuições, o que tende a fortalecer ainda mais o papel dos
contribuidores principais. Essa dependência pode se tornar um risco se uma pessoa-chave não
puder continuar seu trabalho no projeto por algum motivo. Talvez seja impossível reconstruir
todo seu conhecimento implícito a partir de seus objetos (código-fonte e documentação).
4.7 Escassez de Lideranças Competentes

O sucesso de um projeto de software livre depende de uma boa e carismática liderança. Além
das qualidades intrínsecas da perspectiva da Engenharia de Software, o líder de projeto precisa
endereçar questões de comunicação, marketing, juízo político e motivação. A liderança
normalmente é feita por persuasão, pois não há um mandato oficial hierarquicamente
estabelecido. O líder é avaliado não só por seus conhecimentos técnicos, mas por sua visão e
habilidade em se comunicar com os co-participantes. (BCG, 2002). Ainda que haja muitos
participantes com conhecimentos técnicos, as exigências são tão seletivas que se torna difícil
preencher todas as posições de liderança com pessoal qualificado. Raymond (1999) diz que o
sucesso do Linux se deve muito mais à excelente liderança exercida por Torvalds do que por
suas habilidades técnicas. A escassez de novos e bons líderes é uma questão muito sensível para
o futuro dos projetos de software livre, conforme atestado pelo próprio Torvalds (SEARLS,
2003).

4.8 Problemas Legais

A propriedade intelectual, com seus copyrights, patentes, marcas registradas e segredos

comerciais é certamente um dos campos mais obscuros e esotéricos da esfera jurídica,
principalmente quando aplicada ao software e seus algoritmos. É muito difícil saber se
determinado método para se resolver um problema de software já foi patenteado ou não, e a
interpretação dessas leis varia conforme o país.
Stallman (1999) chegou a afirmar que “A pior ameaça que nós enfrentamos são as patentes
de software que podem colocar algoritmos e características fora dos limites do software livre
por mais de vinte anos”.
Ainda que esse problema exista para todo o mercado de software (livre e proprietário), no
modelo de desenvolvimento de software livre, distribuído pelo mundo e sem organização
formal, existe um maior risco potencial de se infringirem essas leis. Apenas como exemplo, um
estudo recente conduzido pela Open Source Risk Management28 mostrou que apenas o kernel do
Linux potencialmente viola 283 patentes, incluindo 27 que pertencem à Microsoft. Esse tipo de
preocupação legal, que também varia conforme o país pode prejudicar o futuro do software
livre.

5 Conclusão

Este artigo procurou mostrar o modelo de desenvolvimento do software livre através da

perspectiva do Trabalho Cooperativo Suportado por Computador. Essa análise ajudou a revelar
um pouco mais do contexto no qual software livre está inserido e reforçar o argumento de que
esse assunto não pode ser explicado somente por uma disciplina ou visão, mas sim através de
um conjunto delas.
Através da apresentação de um framework conceitual, complementada com um estudo de
caso do desenvolvimento do Linux, foram apresentados os principais elementos e inter-relações
que existem em um projeto típico, com participantes, processos, ferramentas e objetos
produzidos em um modelo cooperativo de trabalho.
O estudo mostrou também que o fenômeno do software livre, apesar de ainda estar em
formação, vem crescendo bastante nos últimos anos e que sua expansão (e futuro) dependem da
estabilização de alguns fatores hoje apresentados como desafios.

28 http://www.osriskmanagement.com/
Referências
AOKI, A., Hayashi, K., Kishida, K., Nakakoji, K., Nishinaka, Y., Reeves, B., Takashima,
A., & Yamamoto,Y. A case study of the evolution of Jun: an object-oriented open-source
3D multimedia library. In Proceedings of the 23rd international conference on software
engineering (ICSE 01) (pp. 524–533). Toronto, Canadá, 2001.

BCG, Boston Consulting Group. Hacker Survey release 0.73, 2002. Disponível em
www.osdn.com/bcg/BCGHACKERSURVEY-0.73.pdf . Visitado em Jan de 2007.

BERLECON, Research. FLOSS. Free/Libre and Open Source Software: Survey and Study.
European Commission, 2002. Disponível em http://www.infonomics.nl/FLOSS/. Visitado
em Jan de 2007.

BROOKS, F. P. Jr. The Mythical Man-Month. Addison-Wesley. 2ª ed. 1995

BROWN, J. S. and Duguid, P. Organizational Learning and Communities-of-Practice:

Toward a Unified View of Working, Learning, and Innovation, Organization Science, 2(1),
1991, 40-57

BUTTON, G., Sharrock, W. Project Work: The Organisation of Collaborative Design and
Development in SoftwareEngineering, Computer Supported Cooperative Work: The Journal
of Collaborative Computing, 5, 1996, 369-386

DAFERMOS, George. Management and Virtual Decentralised Networks: The Linux

Project, First Monday, 2001. Disponível em
http://www.firstmonday.dk/issues/issue6_11/dafermos/ . Visitado em Jan de 2007.

DEURZEN, Van. Linux Architectures. 2004.

Disponível em http://home.hccnet.nl/p.van.deurzen/linuxweb/docs/architectures.htm .
Visitado em Jan de 2007.

EDWARDS, Kasper. Epistemic Communities, Situated Learning and Open Source Software
Development Department of Manufacturing Engineering and Management, Technical
University of Denmark, 2000.

FIELDING, R. T. Shared leadership in the Apache Project. Communications of the ACM,

v. 42, n. 4, p. 42–43, abr 1999.

GANCARZ, M. UNIX Philosophy. Prentice-Hall, 1995.

HEXSEL, Roberto, Propostas de Ações de Governo para Incentivar o Uso de Software

Livre, Relatório Técnico do Departamento de Informática da UFPR, 004/2002 , 2002.

KRAUT, R. E. and Streeter, L. Coordination in SoftwareDevelopment, Communications of

the ACM, 38(3),1995, 69-81

KUWABARA, Ko. Linux: A Bazaar at the Edge of Chaos. FirstMonday 5(3), 2000.
Disponível em http://www.firstmonday.dk/issues/issue5_3/kuwabara/ . Visitado em Jan de
2007.

LANCASHIRE, D. Code, culture, and cash: The fading altruism of open source
development. FirstMonday, 6(12), 2001. Disponível em
http://firstmonday.org/issues/issue6_12/lancashire/ . Visitado em Jan de 2007.
MAÇADA, D. L. TIJIBOY, A.V. Aprendizagem Cooperativa em Ambientes Telemáticos.
In: Congresso Ibero-Americano de Informática na Educação, IV. Brasília, outubro de 1998.

MCKUSICK, M. K. Twenty years of Berkeley UNIX. In: Open Sources. Sebastopol:

O’Reilly and Associates, 1ª ed., 1999. p. 31–46.

MOON, J., SPROULL, L. Essence of Distributed Work: The Case of Linux Kernel. First
Monday. 2000. Disponível em http://www.firstmonday.org/issues/issue5_11/moon/.
Visitado em Jan de 2007.

NAKAKOJI, K., Yamamoto, Y., Nishinaka, Y., Kishida, K., & Ye, Y.. Evolution patterns
of open-source software systems and communities. In Proceedings of the international
workshop on principles of software evolution (IWPSE 2002), Orlando, FL, 2002.

OSI. The Halloween Documents, 1988. Disponível em http://www.catb.org/~esr/halloween/.

Visitado em jan de 2007.

PAVLICEK, C. Embracing insanity: Open source software development. Indianapolis,

Sams, 2000.

RAYMOND, E. S. The Cathedral and The Bazaar. O’Reilly and Associates, 1ª ed., 1999. p.
27–78.

REIS, Christian. Caracterização de um Modelo de Processo para Projetos de Software

Livre, Instituto de Ciências Matemáticas e de Computação, São Carlos SP, 2001.

ROTHFUSS, Gregor. A Framework for Open Source Projects, Universität Zürich, Institut
für Informatik, 2002. Disponível em http://greg.abstrakt.ch/docs/OSP_framework.pdf .
Visitado em Jan de 2005.

SCHARFF, E. D. Open Source: A Conceptual Framework for Collaborative Artifact and

Knowledge. University of Colorado, 2002

STALLMAN, R. M. The GNU Operating System and the Free Software Movement. In:
Open Sources. Sebastopol: O’Reilly and Associates, 1ª. ed., 1999. p. 53–70.

SCHENK, Thomas. Linux: Its history and current distributions. Disponível em

http://www-106.ibm.com/developerworks/library/it-schenk1/schenk1.html, 2001.Visitado
em Jan de 2007.

SEARLS, Doc. Linus & the Lunatics. Transcrição de palestra no Linux Lunacy Geek Cruise
2003. Disponível em http://www.linuxjournal.com/article/7272. Visitado em Jan de 2007.

SHAIKH, M. Cornford, T. 2003. Version Management Tools: CVS to BK in the Linux

Kernel, disponível em http://opensource.mit.edu/papers/shaikhcornford.pdf . Visitado em
Set 2004.

TANENBAUM, Andrew. Operating Systems, Design and Implementation. Prentice-Hall,

1987.

TAURION, Cezar. Software Livre - Potencialidades e Modelos de Negócios. Brasport,

2004.

TORVALDS, L. The Linux Edge. In: Open Sources. Sebastopol: O’Reilly and Associates,
1ª ed., 1999. p. 101–111.
TUOMI, Ilkka. Evolution of the Linux Credits File: Methodological Challenges and
Reference Data for Open Source Research. FirstMonday, 2002 Disponível em
http://www.firstmonday.dk/issues/issue9_6/tuomi/ . Visitado em Jan de 2007.

YAMAUCHI, Y., Yokozawa, M., Shinohara, T., Ishida, T. Collaboration with Lean Media:
How Open Source Succeeds. In: Proceedings of CSCW, 2000. ACM Press. p. 329-338.
 Anexo 1

Definições de termos relacionados ao software livre (HEXSEL, 2002)

• BSD: A licença BSD cobre as distribuições de software da Berkeley SoftwareDistribution,

além de outros programas. Esta é uma licença considerada 'permissiva' porque impõe poucas
restrições sobre a forma de uso, alterações e redistribuição do software licenciado. O software
pode ser vendido e não há obrigações quanto à inclusão do código fonte, podendo o mesmo
ser incluído em software proprietário. Esta licença garante o crédito aos autores do software,
mas não tenta garantir que trabalhos derivados permanecem como software livre.

• Copyleft: A maioria das licenças usadas na publicação de software livre permite que os
programas sejam modificados e redistribuídos. Estas práticas são geralmente proibidas pela
legislação internacional de copyright, que tenta justamente impedir que alterações e cópias
sejam efetuadas sem a autorização dos autores. As licenças que acompanham software livre
fazem uso da legislação de copyright para impedir utilização não-autorizada, mas estas
licenças definem clara e explicitamente as condições sob as quais cópias, modificações e
redistribuições podem ser efetuadas, para garantir as liberdades de modificar e redistribuir o
software assim licenciado. A esta versão de copyright, dá-se o nome de copyleft.

• Debian: A licença Debian é parte do contrato social celebrado entre a Debian e a

comunidade de usuários de software livre, e é chamada de Debian Free SoftwareGuidelines
(DFSG). Em essência, esta licença contém critérios para a distribuição que incluem, além da
exigência da publicação do código fonte. Estes critérios são: (a) a redistribuição deve ser
livre; (b) o código fonte deve ser incluído e deve poder ser redistribuído; (c) trabalhos
derivados devem poder ser redistribuídos sob a mesma licença do original; (d) pode haver
restrições quanto à redistribuição do código fonte, se o original foi modificado; (e) a licença
não pode discriminar contra qualquer pessoa ou grupo de pessoas, nem quanto a formas de
utilização do software; (f) os direitos outorgados não podem depender da distribuição onde o
software se encontra; e (g) a licença não pode 'contaminar' outro software.

• Freeware: O termo freeware não possui uma definição amplamente aceita mas é usado com
programas que permitem a redistribuição mas não a modificação, e seu código fonte não é
disponibilizado. Estes programas não são software livre.

• GPL: A Licença Pública Geral GNU (GNU General Public License) é a licença que
acompanha os pacotes distribuídos pelo Projeto GNU, e mais uma grande variedade de
software, incluindo o kernel do sistema operacional Linux. A formulação da GPL é tal que ao
invés de limitar a distribuição do software por ela protegido, ela de fato impede que este
software seja integrado em software proprietário. A GPL é baseada na legislação
internacional de copyright.

• Open Source: A licença da Open Source Initiative é derivada da Licença Debian, com as
menções à Debian removidas.

• Shareware: É o software disponibilizado com a permissão para que seja redistribuído, mas a
sua utilização implica no pagamento pela sua licença. Geralmente, o código fonte não é
disponibilizado e portanto modificações são impossíveis.

• Software Comercial: É o software desenvolvido por uma empresa com o objetivo de lucrar
com sua utilização. Note que 'comercial' e 'proprietário' não são o mesmo. A maioria do
software comercial é proprietário mas existe software livre que é comercial, e existe software
não-livre não-comercial.
• Software em Domínio Público: É o software sem copyright. Alguns tipos de cópia, ou
versões modificadas, podem não ser livres porque o autor permite que restrições adicionais
sejam impostas na redistribuição do original ou de trabalhos derivados.

• Software Livre (Free Software): É o software disponível com a permissão para qualquer um
usá-lo, copiá-lo, e distribuí-lo, seja na sua forma original ou com modificações, seja
gratuitamente ou com custo. Em especial, a possibilidade de modificações implica em que o
código fonte esteja disponível. Se um programa é livre, potencialmente ele pode ser incluído
em um sistema operacional também livre. E importante não confundir software livre com
software grátis porque a liberdade associada ao software livre de copiar, modificar e
redistribuir independe de gratuidade. Existem programas que podem ser obtidos
gratuitamente, mas que não podem ser modificados, nem redistribuídos. Por outro lado, existe
a possibilidade de uso não-gratuito em todas as categorias listadas no que segue. Há uma
cópia da definição de software livre pela Free SoftwareFoundation publicada na página
http://www.fsf.org/philosophy/free-sw.pt.html

• Software Proprietário: É aquele cuja cópia, redistribuição ou modificação são em alguma

medida proibidos pelo seu proprietário. Para usar, copiar ou redistribuir, deve-se solicitar
permissão ao proprietário, ou pagar para poder fazê-lo.

• Software Semi-livre: É software que não é livre, mas é concedida a permissão para que
indivíduos o usem, copiem, distribuam e modifiquem, incluindo a distribuição de versões
modificadas, desde que o façam sem o propósito de auferir lucros. Exemplos de software
semi-livre são as primeiras versões do Internet Explorer da Microsoft, algumas versões dos
browsers da Netscape, e o StarOffice.

• X.org: O Consórcio X distribui o X Window System sob uma licença que o faz software livre
mas não adere ao copyleft. Existem distribuições sob a licença da X.org que são software
livre, e outras distribuições não o são. Existem algumas versões não-livres do sistema de
janelas X11 para estações de trabalho e certos dispositivos do IBM-PC que são as únicas
funcionais disponíveis, sem similares distribuídos como software livre.