Licenças de software

2007-03-23

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.

Anúncios

Diferenças individuais de produtividade

2007-03-22

É 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

2007-03-20

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?

2007-03-19

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?

2007-03-18

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


Papotech sobre Software Livre

2007-03-18

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.


2007-03-15

First post!

Primeiro post!

Premier post!