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.
--------------------------

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.

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.

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.

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á.