sexta-feira, 23 de março de 2007

O ideal do software livre

Outro dia eu falava sobre as licenças de software e como elas podem ser entendidas efetivamente como um contrato em que o autor do software "dá licença" para o usuário usufruí-lo de maneira parcial e limitada.

O movimento do software livre, orginado e liderado pelo Stallman, entende que este poder do autor pode ser usado de maneira abusiva e imoral. A questão não é que o autor possa impedir outras pessoas de utilizar o programa. O problema é que ele pode sujeitar o usuário a um conjunto de restrições que podem levar a situações de conflito moral.

O exemplo canônico deste tipo de conflito ocorre quando o usuário se vê obrigado a transgredir a Regra de Ouro, também conhecida como ética da reciprocidade, e que é um dos pilares da ética de todas as culturas e religiões. Trata-se meramente da regra que diz que você deve fazer pelos outros o que gostaria que os outros fizessem por você e que não deve fazer aos outros o que não gostaria que lhe fizessem.

Pois bem. Segundo Stallman, a Regra de Ouro diz que se eu gosto de um programa e devo compartilhá-lo com as outras pessoas que se interessarem por ele. Afinal, é assim que eu gostaria de ser tratado quando eu me interessasse por um programa de um colega. Notem que isso não vale para bens tangíveis, apenas para bens intangíveis e sobre os quais não hajam direitos morais associados, como o software. Não é porque eu gosto do meu iPod, por exemplo, que eu preciso dá-lo a quem mo pedir, pois ao dá-lo eu ficaria sem ele. No caso do software eu daria uma cópia e permaneceria com a minha, efetivamente incrementando a "riqueza" total do mundo.

Os tais direitos morais são coisas como o direito de ser reconhecido como autor e o direito de não ter sua obra artística, como um livro, conspurcada. Mas o autor de software não padece destes direitos.

Em última análise então, se eu me sinto compelido a seguir a Regra de Ouro, eu deveria me abster de assumir qualquer obrigação que possa me forçar a transgredi-la. Portanto, eu não deveria aceitar um contratro que restringisse meu direito de compartilhar um software com um amigo interessado. Se eu entendo corretamente, esta é a essência do ideal de Stallman: as licenças de software que impõem restrições ao compartilhamento me forçam a transgredir a Regra de Ouro e por isso eu não deveria aceitá-las.

Licenças de software

Hoje eu tive uma daquelas valiosas experiências que acontecem conosco quando percebemos que estamos errados. Ao ler a transcrição de uma palestra do Richard Stallman sobre a GPLv3 vi que ainda há detalhes sobre a GPLv2 que eu desconhecia.

Aliás, o assunto "licenças de software", em geral, é normalmente envolto em muito mistério, mito e ignorância. Não sei bem o porquê, mas tenho uma teoria: as pessoas não formam conceitos a partir de definições oficiais mas sim de analogias banais. Quando, à primeira vista, o significado de um termo parece óbvio, não nos passa pela cabeça a possibilidade de estarmos enganados a seu respeito.

Todo mundo acha que sabe o que é uma licença de software. É o preço do programa, certo? Afinal, não existe o "custo de licença"? E aí, quando alguém vem e diz que existem "licenças livres" dá um nó na cabeça, pois isso mais parece um oxímoro.

Errado. Eu já disse antes que uma licença de software é o contrato estabelecido entre o distribuidor do software e quem o adquire, especificando os direitos que o adquirente está obtendo. Como de costume eu estava errado. Não é o distribuidor mas sim o autor do software (ou o detentor do seu copyright, no direito anglo-saxão) que pode estabelecer um contrato com o usuário, pois ele é quem detém os direitos exclusivos sobre o software.

Uma licença de software não é um contrato de venda. O autor do software não cede seus direitos através da licença. Ele apenas os concede de maneira parcial e limitada. É como um ingresso de cinema. Você não sente que está comprando o filme. Você sabe que está apenas comprando o direito de assistir a uma determinada sessão.

As licenças de software propritário tradicionais são bem parecidas com o ingresso de cinema. Normalmente, elas concedem ao usuário o direito de executar o programa em um único computador e só. Há variações, como as licenças flutuantes, que permitem um número limitado de ativações simultâneas do programa em um número indeterminado de máquinas em rede. Outras vezes, a licença especifica o tipo de máquina em que o programa pode ser executado, não permitindo que ele seja usado em máquinas de maior poder computacional.

Acho que o melhor jeito de entender a função de uma licença de software é prestar atenção não na palavra "software", mas sim na palavra "licença". É exatamente isso. O autor "dá licença" ao usuário de usar o software de uma determinada maneira. Como ele detém os direitos exclusivos sobre sua obra, só ele pode "dar licença" para que outras pessoas o utilizem e ele pode dar uma licença tão ampla ou tão restrita quanto lhe der na telha. Chato pro usuário, não?

E tem mais. O autor pode dar uma licença diferente para usuários diferentes. Ele pode cobrar uma baba por uma licença flutuante que interesse a uma empresa. Pode cobrar um valor menor por uma licença individual. E pode não cobrar nada da sua esposa. A idéia é que enquanto seus direitos durarem ele os pode conceder como bem entender.

Então, em princípio, um software não licenciado só pode ser usado pelo seu autor. Outros usuários só podem usá-lo respeitando o contrato de licença estabelecido explicitamente pelo autor.

Licenças livres

http://www.fsfeurope.org/projects/gplv3/tokyo-rms-transcript
------------------
- internet distribution instead of mail order

-----------------
Q7: I'd like to know more about this term "use freely". In patent terminology, to use something freely means that as long as you pay the licence fees, then you can use it.

Richard Stallman: That's not Free Software. In any case, when I informally use terminology like "to use something freely", I am not referring to any country's patent law, and specifically, being free to do something means you don't have to pay for permission to do it. When we describe the four freedoms, when we say that freedom zero is the freedom to run the program as you wish, part of that is: you're not required to pay anyone for permission to run that program as you wish.

And, freedom 2 is the freedom to distribute copies of the program. That means you don't have to pay for permission to do so, you don't have to pay for each copy or negotiate with anybody. You're simply free outright to go and do it.

If there's a program that you're allowed to run only if you pay somebody, that's not Free Software. Therefore, the GNU GPL aims to make sure that nobody can create such a situation. If somebody can create a situation where people feel they must pay in order to be allowed to run a GPL covered program, then that is a flaw, a failing in the GPL and we are doing our best to make sure that can't happen.

--------------------------
I don't believe that all the important ethical issues in life can be modelled on the Free Software movement.
-----------------------------
We're not working on open source, we're not interested in open source. By the way, some open source licences are not Free Software licences, the definition of open source came from the definition of Free Software but it followed a circuitous path, and it's written very differently and it's interpreted by different people, so they've drawn the lines in different places, so most of the open source licences are Free Software licences, but there are some licences that the OSI accepted that we consider unacceptably restrictive.
-----------------------------
And then are licences that are file-level copylefts. The Mozilla Public License was the first of these. File-level copylefts say "If you modify the files of this program, the modified versions of those same files must be under this same licence". Now, that's not as strong as the GPL. The GPL says if you modify the program, you're whole modified program must be under the GPL. Those file-level copylefts, or we might call them weak copylefts, permit the additional of separate files which are non-free. They don't really achieve the goal of copyleft, but because they made this requirement about the file, it's impossible to relicense that file under the GPL. So the GPL will always be incompatible with those file-level copyleft licences.
-----------------------------
The licence of TeX says "You can't modify this file, but you can distribute it with a change file" and then when TeX is built, it's built by patching the standard TeX source code using the change file. So, in effect, you can distribute any modified version in that way, that's how I convinced myself in 1984 that that was a Free Software licence. But if you have two programs under the TeX licence, you can't merge them because each one says: anything that contains this can only be distributed as a changefile from this. So you have two things tugging at each other, each one insisting on being the base. So the TeX licence is incompatible with itself, but it's a Free Software licence.
--------------------------

quinta-feira, 22 de março de 2007

Diferenças individuais de produtividade

É uma percepção comum que há diferenças significativas de produtividade entre desenvolvedores de software. De fato, esta grande variação parece existir em todos os trabalhos intelectuais, coisa que não acontece com tanta ênfase em trabalhos mecânicos.

O livro Peopleware - Productive Projects and Teams é um clássico da gerência de projetos de software que eu sou incapaz de elogiar o suficiente. Seus autores, DeMarco e Lister, realizaram um estudo para verificar a extensão desta diferença de produtividade e como ela se distribui entre os desenvolvedores. O estudo consistiu em uma série de competições nas quais programadores de diferentes organizações realizavam várias atividades de programação e de testes. Ganhava quem terminasse primeiro e com o menor número de defeitos. A série de competições durou vários anos e os resultados se mantiveram constantes.

O gráfico abaixo mostra o resultado de uma das competições, considerando como métrica de produtividade o tempo que cada participante levou para terminar a tarefa. Segundo DeMarco e Lister, a característica da curva é a mesma, independentemente da métrica de produtividade que se empregue. Em particular, isto também vale para métricas de qualidade expressas em quantidade de defeitos.



As três regras gerais que eles puderam inferir sempre que mediram a variação de produtividade entre um grupo de indivíduos são seguintes:

  • A diferença de produtividade entre o melhor e o pior é da ordem de 10 vezes.

  • A diferença de produtividade entre o melhor e o mediano é da ordem de 2,5 vezes.

  • A diferença de produtividade entre a metade mais eficiente e a metade menos eficiente é da ordem de 2 vezes.

Analisando estes resultados eles procuraram correlacioná-los com fatores do ambiente de trabalho dos participantes. Alguns fatores que não tiveram grande influência na produtividade foram os seguintes:

  • Linguagem de programação: Não houve correlação entre a linguagem usada pelos participantes e sua produtividade.

  • Anos de experiência: Programadores com até seis meses de experiência na linguagem de programação utilizada saíram-se pior que programadores mais experientes. Contudo, a partir daí a variação passou a não ser significativa. Por exemplo, programadores com dez anos de experiência não se saíram melhor que programadores com apenas dois anos de experiência.

  • Número de defeitos: Aproximadamente um terço dos participantes completaram os exercícios sem nenhum defeito. Este nível de qualidade não teve impacto negativo na produtividade do grupo. De fato, eles levaram, em média, um pouco menos de tempo que os demais participantes que completaram o exercício com um ou mais defeitos.

  • Salário: Os níveis salariais variaram significativamente entre os participantes. Apesar disto, houve uma correlação muito fraca entre salário e produtividade. A metade mais produtiva dos participantes recebia, em média, 10% a mais que a metade menos produtiva, mas a diferença de produtividade foi de 100%. Já a variação de produtividade dentro de cada nível salarial era quase tão grande quanto sobre o total de participantes.

Um fator que teve surpreendente influência na produtividade dos participantes foi a sua origem, i.e., a organização em que trabalham. O estudo mostrou que a diferença de produtividade entre participantes da mesma organização foi de aproximadamente 21%. Já a diferença entre os grupos de desenvolvedores das 92 organizações que participaram da competição foi marcante. O melhor grupo trabalhou 11 vezes mais rápido que o pior e todos os desenvolvedores da organização campeã desenvolveram código sem defeitos.

Esta observação é ainda mais surpreendente quando se considera que os grupos não trabalharam como equipe durante a competição. Cada desenvolvedor trabalhou individualmente, no seu próprio ambiente de trabalho dentro da sua organização.

A conclusão é que os melhores desenvolvedores tendem a se concentrar em algumas organizações enquanto os piores tendem a se concentrar em outras. Isto contradiz um certo fatalismo manifestado por alguns gerentes em relação às diferenças individuais. Eles crêem que estas diferenças são inatas, de modo que não se pode fazer muito a respeito. Mas fica difícil ser fatalista sobre o efeito de concentração observado. Deve haver algo relacionado ao ambiente de trabalho e à cultura corporativa que afaste ou que atraia os bons desenvolvedores.

Uma das conjecturas mais fortes que DeMarco e Lister sugerem como explicação para o problema da improdutividade é o fato de que o ambiente de trabalho na maioria das empresas é tumultuado, barulhento e cheio de interrupções. Para testar esta hipótese, cada participante da competição preencheu um questionário sobre as condições físicas de trabalho, antes de executar o exercício. A Tabela 1 sumariza os resultados dos questionários respondidos pelo melhor e pelo pior quartil dos desenvolvedores. A diferença de produtividade entre os dois grupos foi de 2,6 vezes.



O ambiente de trabalho do primeiro quartil de produtividade é mais quieto, oferece maior privacidade, é menos susceptível a interrupções e mais espaçoso.

Os dados apresentados não provam que um ambiente de trabalho melhor vai ajudar os desenvolvedores a trabalhar melhor. Eles podem também estar indicando que os melhores desenvolvedores tendem a procurar trabalhar nas organizações que proporcionam um melhor ambiente de trabalho. Em última análise, porém, o importante é que um bom ambiente de trabalho tende a ser usado por bons desenvolvedores.

terça-feira, 20 de março de 2007

Perspectivas sobre Software Livre e de Código Aberto

A MIT Press liberou para download o PDF completo do livro Perspectives on Free and Open Source Software. Trata-se de uma coletânea de artigos sobre vários aspectos relacionados ao software livre: a motivação para produzi-lo, os métodos e ferramentas comumente usados para desenvolvê-lo, os modelos econômicos e modelos de negócio adotados pelas empresas, além de aspectos legais, culturais e sociais que afetam e são afetados pela sua existência.

Eu ainda não tive a oportunidade de lê-lo. Da lista de autores dos artigos eu já conheço e recomendo os seguintes: Robert Glass, David Parnas, Peter Neumann, Jason Matusow, Lawrence Lessig e Tim O'Reilly.

segunda-feira, 19 de março de 2007

A venda de licenças de software está virando um modelo de negócios obsoleto?

Segundo Bruce Perens, menos de 30% de todo o software produzido é negociado na forma de licenças. A maioria do software em uso é desenvolvido in house pelos próprios empregados da empresa que o utiliza ou sob encomenda, por uma empresa ou consultor externo que cobra pelo serviço de desenvolvimento.

Várias forças estão se alinhando para diminuir ainda mais este percentual, diminuindo a importância do modelo de negócios baseado na venda de licenças de software.

Em primeiro lugar, o número cada vez maior de computadores pessoais e de servidores que uma empresa utiliza impõe não apenas um altíssimo fator multiplicador para o custo total de licenças de software como também um alto custo para administrar a utilização legal destas licenças. Este efeito é particularmente relevante na implementação de infra-estrutura para Grid Computing. De acordo com Thomas Wailgum, a tecnologia de Grid destrói o modelo de licenciamento de software tradicional pois as aplicações em Grid não reconhecem os computadores físicos individualmente, mas consideram a agregação de milhares de computadores como um único computador virtual. O problema é prover os recursos quase ilimitados do Grid sem incorrer numa conta astronômica de licenças de software.

Outra força importante é a tendência recente de contratação de software como serviço. Quando se somam à licença do software os custos relacionados à infra-estrutura necessária para suportá-lo (computadores, rede, energia, espaço físico, etc.), os custos de depreciação, os salários da equipe técnica e os riscos de parada de serviço, fica claro como muitas vezes pode ser mais barato contratar o serviço de operação do sistema de uma empresa externa, a qual pode até mesmo oferecer um seguro contra paradas de serviço, mitigando os riscos da sua operação.

A terceira força que vem aumentando a resistência de muitas empresas em renovar seus contratos de licenciamento de software é a proliferação de produtos de software livre de qualidade igual ou superior aos seus concorrentes proprietários. Muitas empresas estão se acostumando a usar software livre sem pagar licença ou a utilizar o serviço de suporte de empresas locais, o que as leva a questionar o modelo tradicional em que além de pagar a licença é preciso ficar refém de uma única empresa para o contrato de suporte.

domingo, 18 de março de 2007

Como se vende um software?

Em quase todo o mundo desenvolvido o software é considerado "propriedade intelectual" do seu autor, do mesmo modo que uma obra de arte é considerada propriedade do artista que a criou. Digo "propriedade intelectual", assim, entre aspas, porque não se trata de um termo jurídico preciso. Em geral, considera-se "propriedade intelectual" todos os direitos concedidos principalmente por meio de marcas, patentes e direito autoral. Há alguma controvérsia em relação ao uso deste termo mas vou deixar pra discuti-la num outro dia.

Quando se considera um trecho de código ou um programa completo, a legislação que garante o direito de posse ao seu autor é o Direito Autoral. Este ramo do direito vem do droit d'auteur francês e vigora em quase todos os países de origem latina, como o Brasil. O Direito Autoral baseia-se na idéia de que o autor de uma obra intelectual tem direitos morais e patrimoniais exclusivossobre ela.

Nos países onde vigora o direito anglo-saxão, como os EUA e a Inglaterra, não se fala em Direito Autoral. Lá, o direito sobre as obras intelectuais é garantido pela Copyright Law (algo como Lei sobre o Direito de Cópia) que garante para o autor de uma obra o direito exclusivo sobre a sua cópia ou reprodução. O copyright foi criado para permitir que os primeiros editores de livros da Inglaterra tivessem um monopólio temporário do direito de cópia dos livros. De lá pra cá esta lei mudou bastante, nem sempre pra melhor. Eu acho fascinante a história desta lei. Quem tiver interesse não vai se arrepender de ler o fascinante livro Free Culture, de Lawrence Lessig, professor de direito de Stanford. (Vá em frente. Você pode baixar o livro em PDF de graça e legalmente!)

Apesar de terem origens e motivações diferentes, tanto o Direito Autoral quando a Copyright Law acabam tendo o mesmo efeito prático, garantindo para o autor os direitos exclusivos e temporários sobre o uso e cópia da obra. É importante ressaltar que esses direitos são temporários. Atualmente, o copyright nos EUA e o direito autoral no Brasil vigoram por longos 70 anos após a morte do autor. Depois deste tempo, a obra entra em domínio público e deixa de ter dono, podendo ser usada por qualquer um para qualquer propósito. Isso vale, obviamente, para todas as obras literárias, pictóricas e musicais clássicas.

No Brasil, o direito de autor é definido pela Lei 9.610, conhecida como Lei de Direitos Autorais. Um aspecto importante da lei é que ela permite que os direitos autorais sejam cedidos ou licenciados para terceiros. É nisto que se baseiam os modelos de negócio de venda e de licenciamento de software. Outro aspecto interessante e pouco conhecido da lei é que não é necessário "registrar" uma obra para que seu autor tenha seus direitos garantidos: basta que o autor tenha como provar sua condição de autor caso seja questionado. O registro funciona como uma prova inequívoca, que o autor pode opcionalmente garantir para si.

Acontece que o software tem uma legislação específica: a Lei 9.609, conhecida como Lei do Software. Esta lei é que diz que o software é protegido pelo direito autoral, mas ela faz algumas ressalvas e adaptações às disposições da Lei de Direitos Autorais. Por exemplo, ela diz que o autor do software goza apenas dos direitos patrimoniais da obra intelectual, mas não dos direitos morais que são garantidos pela Lei de Direitos Autorais. Isso significa, por exemplo, que o autor do software não pode impedir a utilização do software com a alegação de que este uso estaria, de algum modo, afrontando a sua reputação.

A Lei do Software também modifica o prazo para terminação dos direitos de autor. Ao invés de ele se extinguir 70 anos após a morte do autor, como no caso dos livros, o direito de autor sobre o software se extingue 50 anos após a sua publicação ou criação. Ainda assim, este tempo me parece excessivo. Provavelmente, só dentro de algumas décadas começaremos a ver os primeiros programas de computador entrarem em domínio público por decurso de prazo... E serão trechos na linguagem de máquina do ENIAC ou em FORTRAN dos mainframes da IBM da década de 1950. Portanto, controle a sua ansiedade.

Mas há uma outra maneira de se terminar o direito autoral e de se colocar uma obra em domínio público: o seu autor pode expressar sua vontade de torná-la assim. Tenho bem pouca notícia de software em domínio público. O mais famoso deles é o processador de texto TeX, que influenciou quase todos os processadores de texto modernos e que foi colocado em domínio público por Donald Knuth em 1990.

Vale notar que se você é um programador contratado, apesar de você ser o autor do software que escreve é a sua empresa que fica com os direitos patrimoniais sobre ele. A artigo quarto da Lei de Software deixa isso bem claro. Portanto, se você pretende escrever software pra uso próprio, pra vender ou disponibilizar como software livre, ainda que seja fora do horário de trabalho, sugiro que leia com muita atenção seu contrato de trabalho e pense se sua empresa não poderá vir a ter interesse em reivindicar pra ela própria os direitos sobre o que você desenvolve.

O capítulo IV da Lei do Software fala dos contratos de licenciamento. Neste contexto, entende-se por “licença de software” o contrato estabelecido entre o distribuidor do software e quem o adquire, especificando os direitos que o adquirente está obtendo. Tradicionalmente, esta cessão de direitos é realizada como contrapartida de uma transação comercial, o que normalmente chamamos de “pagamento de licença”.

No caso de desenvolvimento de software por encomenda, normalmente a cessão de direitos é total, passando ao adquirente os direitos exclusivos de uso e distribuição do software. No caso de desenvolvimento de software “de prateleira”, a cessão de direitos é parcial. Normalmente o adquirente recebe apenas o direito de usar o software em uma configuração específica de computadores.

O modelo de negócios tradicional de “venda de licenças” baseia-se, portanto na cessão de direitos de uso do software em condições bastante específicas.

Mas por que é que este modelo não funciona para software livre? Tratarei deste assunto num próximo post. Mas já adianto que a razão pra isso não é jurídica, mas econômica. Até lá.

sábado, 17 de março de 2007

Papotech sobre Software Livre

Ontem eu participei pela segunda vez do Papotech, falando sobre software livre. Pra quem ainda não o conhece, trata-se de um podcast semanal sobre tecnologia feito pelo João Gandara e pelo Vinicius Lobo, de Americana.

Em setembro passado eles me entrevistaram para o episódio 47. Ontem gravamos o episódio 68, com a participação ainda mais especial dos meus colegas Andreyev Melo e Gustavo Moraes. O assunto: software livre.

Da primeira vez foi tudo de supetão. Nesta segunda eu até preparei um roteiro pra não deixar pontas soltas, mas o tempo passa rápido e o papo diverge. Mas é assim que tem que ser um bate-papo, eu acho. Espero não ter dito besteira e que os ouvintes gostem.

Vou tentar durante as próximas semanas postar aqui uma série de notas sobre software livre pra resumir meu entendimento sobre o assunto e, de certo modo, "completar" o bate-papo.

domingo, 4 de março de 2007

Software Livre: História

Começando hoje, pretendo publicar um pequeno conjunto de textos sobre software livre abordando sua história, as motivações para desenvolvê-lo e utilizá-lo, os modelos de negócio baseados nele e alguns dos mitos que ainda permanecem bastante difundidos. Os textos serão adaptações de partes da monografia que eu co-escrevi para a conclusão de um MBA em Gestão Empresarial. Agradeço à Christina, à Luciane, ao Paulo, ao Rafael e à Sofia, que compartilharam comigo as agruras de escrever o trabalho, por me permitire publicar este resumo.

A Free Software Foundation (FSF) define como software livre aquele que qualquer um pode executar, copiar, distribuir, estudar, modificar e aperfeiçoar. Mais precisamente, o conceito de software livre requer que os termos de distribuição do programa ofereçam estas quatro liberdades aos seus usuários:
  • A liberdade de executar o programa, para qualquer propósito.

  • A liberdade de estudar como o programa funciona e de adaptá-lo para as suas necessidades.

  • A liberdade de redistribuir cópias do programa.

  • A liberdade de aperfeiçoar o programa e de liberar os seus aperfeiçoamentos ao público, de modo que toda a comunidade de usuários possa se beneficiar.


Richard Stallman cunhou o termo "software livre" em 1984 e fundou a FSF em 1985 com o objetivo de promover o desenvolvimento e a utilização deste tipo de software. A estratégia original da FSF, idealizada por Stallman, foi a de implementar um sistema operacional completo, composto inteiramente de software livre. O sistema, inspirado nos sistemas Unix da época, ganhou o nome de GNU, um acrônimo recursivo significando GNU's Not Unix. Até 1990 a FSF já havia atraído o interesse de vários colaboradores individuais e desenvolvido um conjunto significativo de software no Projeto GNU, com a exceção de um núcleo (kernel) para o sistema. Em 1991 o finlandês Linus Torvalds iniciou o desenvolvimento do Linux kernel e disponibilizou-o como software livre. A concretização de um núcleo livre e o advento da Internet foram provavelmente os maiores responsáveis pela viabilização do ideal de Stallman. O Linux, por permitir pela primeira vez que um computador rodasse um sistema completamente livre. A Internet, por permitir que o modelo de desenvolvimento colaborativo pudesse ser adotado em grande escala.


As quatro liberdades citadas na definição são centrais ao conceito de software livre. A associação comum, mas errônea, que se faz entre software livre e software grátis resulta de dois fatores: um semântico e outro econômico. O fator semântico está relacionado ao fato de que a palavra free em inglês pode significar tanto “liberdade” quanto “gratuidade”. Stallman alerta que o termo free deve ser entendido como em free speech e não como em free beer. Existe um termo específico para designar software grátis que também é comumente confundido com software livre: freeware.


O fator econômico que leva a esta confusão é que quase todo software livre pode ser baixado gratuitamente da Internet. Mas o que leva a quase todo software livre estar disponível gratuitamente não é uma restrição conceitual ou jurídica, mas sim efeito indireto da liberdade de redistribuição. Como qualquer usuário pode redistribuir o software (cobrando ou não por isso) este se torna um bem abundante e perde seu valor de venda: uma simples aplicação da Lei da Oferta e da Procura. Portanto, software livre não é anti-comercial ou não-comercial. Ele apenas dificulta a sua comercialização através do modelo tradicional de venda de licenças de uso.


O termo software proprietário é comumente usado para designar o software não-livre. Isto não é estritamente correto porque a maioria dos softwares livres são de propriedade de seus autores originais. A legislação de direito autoral (no Brasil e em outros países de direito romano) ou de copyright (nos EUA e em outros países de direito anglo-saxão) garante ao autor do software direitos exclusivos sobre a sua utilização e distribuição. A maioria dos sistemas de software livre são distribuídos mediante licenças de uso bastante liberais nas quais os autores abrem mão da maioria dos seus direitos para conferir aos usuários as quatro liberdades fundamentais. O contrário de software proprietário seria software em domínio público, i.e., software cujo autor tenha abdicado explicitamente de todos os seus direitos ou cujos direitos tenham expirado. Apesar disto, o termo "software proprietário" está tão fortemente associado ao conceito de software livre como sendo seu antônimo que já não é mais possível substituí-lo por outro mais correto.


(Na verdade, não existe ainda software em domínio público por expiração do copyright ou do direito de autor porque o prazo de expiração destes direitos é muito grande. No Brasil, o direito autoral expira 70 anos depois da morte do autor. Nos EUA, o copyright de uma obra criada por um autor individual expira 70 anos depois da sua morte e o copyright de uma obra criada por uma corporação expira 95 anos depois da primeira publicação ou 120 anos depois da sua criação, o que vier primeiro. Os poucos sistemas de software em domínio público de que se tem notícia estão nesta condição por terem sido assim colocados explicitamente pelos seus autores. Um dos exemplos mais conhecidos é o do processador de texto TeX.)


De fato, a definição de software livre cita apenas as quatro liberdades fundamentais que os termos de distribuição do software precisam garantir. Por não ser regido por nenhuma regra, o software em domínio público não impõe nenhuma restrição ao usuário, podendo ser considerado uma forma degenerada de software livre, visto que seus usuários têm liberdade de fazer com ele o que bem entenderem. Dentre os sistemas de software livre que não estão em domínio público há uma grande variedade de licenças de uso que conferem minimamente as quatro liberdades fundamentais. Algumas licenças são tão liberais que exigem apenas a preservação do termo de copyright, e ressaltam o não oferecimento de qualquer garantia. Programas regidos por este tipo de licença, assim como aqueles em domínio público, podem ser re-distribuídos como software proprietário ou servir de base para o desenvolvimento de outros sistemas de software proprietários.


Outras licenças impõem restrições aos termos que os usuários podem usar para redistribuir o software regido por elas. Normalmente estas licenças não permitem que o código fonte do software seja usado como parte de uma obra maior, a menos que o produto final seja também regido pela mesma licença. Estas licenças funcionam efetivamente como uma “vacina” para que o código fonte do software livre não seja “contaminado” por código fonte proprietário. (Infelizmente, é mais comum encontrar mençoes à metáfora inversa, falando no “efeito virótico” destas licenças, no sentido de que se alguém incorporar código fonte regido por elas em um programa proprietário o programa passa a ser necessariamente livre.) A GNU GPL é a licença livre mais antiga e mais utilizada. Ela se enquadra no rol das licenças que restringem a utilização do produto como base para o desenvolvimento de software proprietário. Ela foi idealizada por Richard Stallman como parte de sua estratégia para preservar o corpo de software livre que a FSF produz.


Além de desenvolverem software livre, Stallman e a FSF iniciaram um movimento ideológico atrelado ao conceito de software livre. Mas ao final da década de 1990, nem todos os participantes da comunidade de software livre compartilhavam dos ideais de Stallman. Um conjunto de hackers influentes na comunidade viam motivações mais pragmáticas e menos ideológicas para o desenvolvimento e a utilização de software livre. (O significado original do termo hacker era usado para designar uma pessoa altamente competente na programação de computadores. Sua associação aos vândalos e criminosos da Internet é uma conotação mais recente e extremamente infeliz. A wikipedia conta a história dessa controvérsia.) Eles julgavam que o modelo de desenvolvimento colaborativo tradicionalmente empregado nos projetos de software livre tinha vantagens importantes, em termos de qualidade e custo, em relação ao modelo usado no desenvolvimento dentro das empresas. Mas eles viam fortes barreiras para a adoção do software livre no mundo empresarial, principalmente em função da conotação fortemente ideológica do movimento liderado por Stallman e da associação infeliz entre software livre e software grátis.


Em 1998 esses hackers se organizaram com o objetivo explícito de delinear uma campanha de marketing para promover o conceito de software livre no mundo empresarial. Sua primeira ação foi cunhar o termo open source software, ou software de código aberto, como sinônimo de software livre mas usando palavras menos ambíguas e menos carregadas. Com ligações dentro de algumas empresas de tecnologia do Vale do Silício e na imprensa, eles empreenderam uma campanha visando criar visibilidade para o novo termo e associá-lo às vantagens pragmáticas do modelo de desenvolvimento. Nesta época surgiram dois documentos seminais que influenciaram tremendamente o sucesso da campanha. Eric Raymond escreveu The Cathedral and the Bazaar, artigo no qual procurou explicar o funcionamento do modelo de desenvolvimento e foi importante na decisão da Netscape de liberar o código fonte do seu browser. Bruce Perens escreveu a Open Source Definition que define software de código aberto em função de um conjunto de critérios que seus termos de distribuição devem respeitar, incluindo a liberdade de redistribuição, modificação e redistribuição e a disponibilização do código fonte.


O termo “código aberto” não está livre de ambiguidades, porém. Exatamente por ressaltar um dos aspectos do software livre, a necessidade de disponibilizar o código fonte, há quem entenda que basta vir acompanhado do código fonte pra que um software seja considerado de código aberto. Isto não é o caso, como ressalta a Open Source Definition logo na sua introdução. Além de ter acesso ao código fonte, é preciso que o usuário tenha a liberdade de modificá-lo e redistribuí-lo sem restrições adicionais.


Apesar de possuirem definições bem diferentes, software livre e software de código aberto são essencialmente a mesma coisa em termos de classificação. Isto é, todo software livre é software de código aberto e vice-versa. A diferença, nem sempre percebida, está na conotação que cada termo traz e implica em relação ao produto qualificado. Ao falar em software livre o interlocutor está ressaltando as liberdades que ele confere ao usuário. Já ao falar em software de código aberto o interlocutor está ressaltando as vantagens inerentes ao seu modelo de desenvolvimento.


A campanha de marketing desses hackers funcionou. Pelo menos no que se refere ao novo nome. Hoje o termo “open source” é usado três vezes mais freqüentemente que o termo “free software”, de acordo com os resultados da pesquisa no Google. Mas é interessante perceber que no Brasil este fenômeno não ocorreu. O termo “software livre” é usado duas vezes mais freqüentemente que os termo “código aberto” e “open source” juntos, de acordo com o Google. Eu creio que isso se deva, em primeiro lugar, ao fato de que o termo “livre” em português não tem conotação de “grátis”. Além disso, é mais fácil falar e escrever “software livre” que “open source” ou “código aberto”.


Eu prefiro falar "software livre". Acho que soa melhor. Talvez porque eu tenha começado a usá-lo alguns anos antes de o termo "código aberto" ter sido inventado. Há um conjunto de hackers para os quais a escolha do termo reflete um posicionamento ideológico. Respeito isso e acho que os argumentos dos dois lados são bastante fortes. Mas não é o meu caso. Meu uso do termo "software livre" não traz nenhum juízo de valor.