As contribuições da comunidade e os direitos autorais

Eu estive em seis conferências em três continentes diferentes no mês passado. Quando tenho que viajar desse jeito, me sinto na óbvia obrigação de determinar qual país tem a melhor cerveja; geralmente é preciso pesquisar um bocado para descobrir isso. Também é normal ouvir de outros pesquisadores tudo o que passa pela cabeça deles enquanto pesquisamos. Desta vez, ouvi alguns resmungos de um número surpreendentemente grande de pessoas, sempre sobre o mesmo assunto: políticas de atribuições de direitos autorais.

Os desenvolvedores parecem especialmente preocupados e insatisfeitos com a política de atribuição de direitos autorais escolhida pela Canonical para todos os seus projetos. O contrato [PDF] é relativamente fácil de ler; só toma uma página. Ele se aplica a uma longa lista de projetos, incluindo Bazaar, Lauchpad, Quickly, Upstart e Notify-osd; contribuições para esses projetos devem ser feitas sob os termos desse contrato.

E com o que os contribuidores precisam concordar? A cláusula mais importante é esta:

Ou seja, a Canonical tem posse total do código. Em troca, a Canonical oferece ao autor original o direito de fazer quase tudo com esse código.

A atribuição de direitos autorais à Canonical já poderia ser um obstáculo a contribuidores potenciais, mas há outros termos que pioram ainda mais as coisas. Um deles é este:

Muitos desenvolvedores de software livre vão reclamar de ter que dar seu código a alguém que “via de regra” irá disponibilizá-lo sob uma licença livre. E a frase final é ainda pior; “outros termos de licença” é, obviamente, um eufemismo para “termos proprietários”.

Por fim, há o compromisso com as patentes:

É provável que isso não seja problema para muitos desenvolvedores que não tenham a intenção de impôr patentes a terceiros. Mas vale observar que (1) a concessão da patentes é ampla, incluindo qualquer coisa que possa ser adicionada ao programa (por outros) no futuro e (2) não há exceção de “legítima defesa” que permita o uso de patentes para combater litígio iniciado por terceiros. Logo, para o proprietário de uma patente, isso vai parecer uma promessa de desarmamento unilateral com escopo desconhecido (e imprevisível). Para muitas empresas, mesmo para aquelas contrárias às patentes de software de modo geral, essa exigência sozinha já pode ser suficiente para matar o contrato.

Existem, obviamente, muito contratos de contribuição, embora seus termos variem bastante. Podemos comparar o contrato da Canonical ao texto da Free Software Foundation:

Nem todos os desenvolvedores são fãs da FSF, mas a maioria deles confia que ela manterá esses termos. O contrato da FSF não faz menção alguma às patentes (embora a GPLv3 certamente não mantenha o silêncio nesse aspecto).

E quanto a outros projetos? A Apache Software Foundation tem um contrato através do qual é concedida à ASF uma licença (que ela promete não usar “de forma contrária ao benefício público ou inconsistente com seu status sem fins lucrativos”) mas o autor continua sendo dono do código. O contrato de contribuidor da Sun [PDF], que agora também cobre o MySQL, dá à Sun o direito de fazer qualquer coisa com o código, mas compartilha a posse com o autor. Um exemplo extremo é o contrato do SugarCRM, que parece transferir não apenas os direitos do autor, mas também as patentes dele (as patentes mesmo, não uma licença).

Contratos como o da Sun e do SugarCRM são comuns quando estamos tratando de projetos que pertencem a corporações; elas priorizam claramente o controle e a capacidade de levar as coisas para o lado proprietário em detrimento da criação de uma comunidade de desenvolvimento independente. Já os projetos mais orientados à comunidade, por sua vez, costumam ter uma abordagem diferente nos contratos com seus contribuidores. A Canonical está sendo mais criticada do que a SugarCRM, apesar de seu contrato parecer mais amigável. Um motivo plausível para isso é a Canonical se apresentar como uma organização orientada à comunidade, mas estar impondo um contrato num estilo corporativo aos seus contribuidores.

A política da Canonical deve preocupar especialmente os outros distribuidores do Linux. Eles geralmente ficam felizes em contribuir com um projeto controlado por um distribuidor diferente, mas não o fazem sob termos que permitam a esse projeto tornar o código proprietário. Licenças como a GPL garantem um acordo justo entre as empresas; os contratos de contribuidores que permitem “outros termos de licença” removem quaisquer garantias de um negócio justo. Não é de se surpreender que algumas pessoas não estejam interessadas em contribuir com código sob esses termos.

O verdadeiro ponto de discórdia no momento parece ser o Upstart. Outros distribuidores o adotaram ou pensam em adotá-lo; ele parece representar uma melhoria significativa sobre o velho sistema init SYSV. Durante a adoção do Upstart, esses distribuidores certamente corrigirão problemas e farão melhorias de acordo com suas necessidades. Mas com certeza eles estarão menos propensos a contribuir com essas alterações para a Canonical. Nas minhas andanças, ouvi desenvolvedores falarem num possível fork do Upstart. Outro desenvolvedor afirmou estar trabalhando em um sistema alternativo completamente novo para inicialização do sistema, que usaria conhecimento obtido com o Upstart mas que teria desenvolvimento independente. Nenhuma das duas alternativas parece ser a ideal.

Eu mandei uma pergunta para a Canonical para saber o que a impede de adotar termos mais amigáveis diante dos contribuidores, mas já se passaram alguns dias e ninguém me respondeu. Os grupos que exigem a atribuição de direitos autorais geralmente afirmam que precisam ser capazes de agir contra infratores de direitos autorais. Mas os projetos que mais tiveram sucesso nessa área – o kernel do Linux e o Busybox, por exemplo – não possuem política de atribuição de direitos autorais. Outra coisa que a atribuição de direitos autorais permite, obviamente, é o relicenciamento do código. A FSF fez uso desse privilégio para migrar seus projetos para a GPLv3; empresas como a MySQL, por sua vez, usaram esse privilégio para distribuir código sob termos proprietários. É possível presumir que a Canonical não tenha essa intenção, mas o fato de que a Canonical se reservou explicitamente ao direito de fazê-lo dificilmente fará com que as pessoas se sintam confortáveis.

Quando os desenvolvedores contribuem com código para um projeto, eles costumam obter recompensas intangíveis em troca. Logo, pedir a eles que também abram mão da propriedade do código pode ser pedir demais. Ainda assim, muitos desenvolvedores estão dispostos a contribuir sob esses termos. Mas tudo tem limite, e permitir que a concorrência transforme seu código em código proprietário extrapola esse limite – e o mesmo vale para as concessões de patentes excessivamente amplas, que devem incomodar contribuidores preocupados com essas coisas. As empresas que exigem esses direitos podem acabar não atingindo o sucesso esperado em seus projetos comunitários.