Analisando alegações de violação da GPL

Há
algumas semanas uma controvérsia vem se formando ao redor da decisão da
Red Hat sobre mudar a forma como empacota o kernel Linux incluído em seu
carro-chefe, a distribuição Red Hat Enterprise Linux.

Mesmo que não tenha o objetivo de atrapalhar (e não atrapalha) as distribuições comunitárias de Linux (como o CentOS) –
cuja operação básica é obter o código-fonte do Red Hat Enterprise
Linux, compilá-lo e disponibilizá-lo a usuários interessados em rodar
uma distribuição com qualidade corporativa, mas que não topariam pagar à
Red Hat pelo suporte, a medida pisa em cheio no pé de todos que têm
interesse em saber os detalhes das alterações que a Red Hat faz em seu
kernel: quais patches aplica, por que, quais modificações tem relação a
problemas relatados pelos usuários, etc.

Trata-se de uma medida tomada para dificultar a atividade de um
tipo específico de concorrente: aqueles que acompanham atentamente as
informações divulgadas pela própria Red Hat para então oferecer aos
clientes da empresa serviços de suporte concorrentes aos dela e a preços
mais baixos – pois não precisam desenvolver e integrar as soluções, mas
apenas estudá-las depois de prontas e publicadas.

Em
síntese, a partir de agora a Red Hat não mais divulga para o público em
geral o código-fonte do kernel Linux separando o que veio diretamente
dos desenvolvedores do sistema e o que são modificações (“patches”) obtidos de terceiros ou mesmo desenvolvidos por ela.

Agora o pacote do código-fonte é uma versão compactada (“tarball”)
do código resultante após a aplicação dos patches, sem explicitar
detalhadamente para desenvolvedores externos o teor de cada modificação
individualmente. Quem quiser estudar as diferenças, vai ter de encontrar
outra fonte de informações, ou arcar com o custo e o risco da análise.

A medida provocou variadas repercussões, incluindo uma mais grave, que
tomou a forma de uma alegação: o novo modo de distribuir o kernel
violaria a licença livre GPL.

Desde então a alegação já foi negada pelo parecer de um diretor da Free Software Foundation
mas, como se trata de uma questão interessante de licenciamento, cabe
destacar os pressupostos (equivocados, segundo o parecer) que buscavam
fundamentar a alegação de violação:

• Forma preferida:
  a GPL estabelece que o código-fonte deve acompanhar o software na
  “forma preferida da obra para permitir modificações nela”. Havia a
  alegação que esta “forma preferida” seria o modelo antigo da Red Hat,
  detalhando cada patch. Mas a interpretação que prevalece é de que a
  “forma preferida”, no caso, são simplesmente os arquivos de
  código-fonte, e que uma violação desta norma seria, por exemplo,
  oferecer o código-fonte em uma listagem impressa, ou como um arquivo PDF
  ou documento ODT.

• Suporte com limitação adicional:
  as informações que constavam anteriormente no pacote público do kernel
  da Red Hat continuam disponíveis para os seus clientes de serviços de
  suporte, que se comprometem contratualmente a não repassá-las a
  terceiros sob pena de ter cancelado o serviço. Este tipo de comprometimento foi visto como uma “restrição adicional” à livre redistribuição, o
  que em tese violaria a GPL também (certamente viola o espírito com que
  ela foi concebida). Mas como se trata de uma restrição baseada na
  relação contratual entre as partes e não de um termo de licenciamento,
  em ocasiões similares no passado a FSF já esclareceu que não há violação da licença quando uma das partes renuncia via contrato a fazer uso de uma liberdade da licença desta forma.

Minha
visão é de que ainda veremos surgir mais peças deste quebra-cabeça. Afinal de contas a cooperação open source é multilateral e concluir que a medida
não viola a GPL não equivale a dizer que o equilíbrio nesta dinâmica
está preservado. Acompanharemos!