Governança de código aberto: o caso do VLC no iPhone

Governança
de TI usualmente é tomada no sentido de um conjunto de padrões e
práticas assumidos pelos stakeholders da área de TI de uma organização e
que conduz a melhor suporte, a decisões e a alinhamento da TI às
estratégias da organização, por meio de melhores controles, processos de
segurança, gerenciamento dos riscos e aplicação dos recursos
disponíveis, entre outras disciplinas.

Quando
se aproxima dos projetos de código aberto, a governança de TI se
reveste de uma série de complicadores, devido à natureza dispersa
(geográfica e organizacionalmente) como as estruturas de desenvolvimento e suporte costumam ocorrer, entre outros fatores.

Não
é um desafio intransponível, desde que se tenha em mente os limites do
controle que pode ser exercido a um projeto aberto – os desenvolvedores
descontentes, ou parte deles, usualmente têm condições de “pular fora”
levando consigo (para continuar desenvolvendo com outro nome) uma cópia
completa do que em um projeto fechado seria propriedade inalienável da
organização.

Essa possibilidade, descrita pelo nome de “o poder do fork”,
é uma das grandes forças do modelo aberto quando se trata de oferecer
garantias contra arbitrariedades que possam ser cometidas por alguma
parte.

Outra
das forças que atua no mesmo sentido é a autoria coletiva, modelo de
propriedade e gestão do direito autoral adotado em diversos projetos de
renome, incluindo o kernel Linux: nele o autor de cada trecho de código
incluído no projeto retém os direitos autorais sobre o trecho que
contribui, comprometendo-se apenas a honrar os termos do licenciamento
escolhido para o projeto.

Com
a autoria coletiva, torna-se virtualmente impossível mudar a licença
inicialmente escolhida para um projeto coletivo. As únicas
possibilidades práticas de isso acontecer são extremamente custosas,
envolvendo abandonar ou reescrever os trechos de código que são de
autoria dos desenvolvedores que não concordam com uma eventual mudança.

Geralmente
ambas as forças atuam vigorosamente a favor dos desenvolvedores e
mantenedores do projeto, mas há algumas situações em que o oposto
ocorre, e elas merecem ser estudadas com atenção por quem pensa em dar
início ou contribuir para um projeto de software livre.

O caso do VLC para iPhone

O VLC
é um player de áudio e vídeo que dispensa apresentações. Presente em
praticamente todas as plataformas operacionais hoje em atividade nos
desktops, ele suporta grande variedade de formatos multimídia e, além de
exibi-los, também é craque em convertê-los, transmiti-los via rede e
muitas outras habilidades interessantes.

Mas
a versão para iPhone (e iPad, e outros equipamentos que rodam o sistema
iOS) é atualmente objeto de uma controvérsia intrigante: embora seus
principais mantenedores (a VideoLAN Association) tenham apoiado o
desenvolvimento de uma versão para o iPhone e o iPad, e ela tenha sido
aceita e disponibilizada na App Store oficial destas plataformas no
final de setembro, essa disponibilização não durou muito: no início de
janeiro o VLC foi retirado do repositório pela sua mantenedora, que
informou o motivo: conflito entre seus desenvolvedores.

Ocorre que tanto a VideoLAN quanto os desenvolvedores que fizeram o port
para a plataforma entendiam que as vantagens de oferecer seu software
livre para os milhões de usuários do iOS superavam os eventuais
prejuízos causados pelos termos de licenciamento da App Store em
questão, muito mais restritivos e incompatíveis com a licença adotada
desde 2001 pelo VLC – a GPL.

Ao
mesmo tempo, um dos desenvolvedores que já contribuíram código ao VLC
ao longo dessa década de atuação do projeto, chamado Rémi
Denis-Courmont, discordou e, na condição legal de co-autor do projeto,
entrou em contato diretamente com a App Store notificando do que ele via
como conflito dos termos de licenciamento, e pedindo providências.

A
App Store que, ao contrário do que se aventou, não havia rejeitado o
software devido ao seu licenciamento livre ou a oferecer uma
funcionalidade que duplica (com melhorias, na minha opinião) a de um
aplicativo que faz parte do iOS, não se fez de rogada quando notificada,
e avisou que estava removendo o VLC de sua coleção, devido ao conflito
entre seus autores.

Quem
está certo e quem está errado? Tenho visto que há várias respostas
diferentes, dependendo dos pesos que cada analista dá às questões do
benefício aos usuários, da liberdade de escolha, da liberdade de
software, do respeito ao desejo do autor individual, ou do respeito ao
desejo da maioria dos autores.

Mas há duas dessas possíveis respostas que quero destacar, por terem relação com nosso tema de hoje.

A
primeira delas é a questão do direito do autor: análises morais e de
motivação à parte, as regras adotadas pelo projeto e a legislação dão ao
co-autor Denis-Courmont pleno direito de objetar à distribuição do
software que inclui o trecho contribuído por ele de maneiras que não
atendam aos termos de licenciamento com os quais ele concordou.

E
a outra é a das decisões de projeto que, uma vez tomadas, dificilmente
mudam. No que diz respeito ao atual conflito, a mantenedora VideoLAN é
apenas um terceiro interessado: juridicamente, as partes são o
desenvolvedor descontente e os desenvolvedores que se envolveram no port para o iOS.

Estes
últimos divulgaram que – juntamente com a VideoLAN – buscariam agir
para impedir que este seja o fim do VLC para iOS. Até o momento,
entretanto, a VideoLAN, assistindo ao que ocorre ao projeto que mantém,
apenas pôde publicar uma nota lamentando o inconveniente causado aos usuários e se comprometendo a conversar com as partes para buscar uma solução rápida.

Um caso de estudo para os desenvolvedores

Este
é um caso emblemático das consequências da escolha de uma forma de
licenciamento: quando um projeto de software livre tem autoria coletiva,
cada autor retém o direito de fazer o que Rémi fez: objetar sozinho à
distribuição do software como um todo, quando considera que há conflito
com os termos de licenciamento, com base nos direitos autorais sobre o
trecho que contribuiu.

Essa
situação fica mais evidente quando reúne alguns temperos extras, como o
uso de uma licença que imponha restrições no estilo copyleft
(caso da GPL), e a ausência de qualquer estatuto que limite a um
desenvolvedor atuar sozinho sem representar o posicionamento da
coletividade dos desenvolvedores envolvidos.

O
que ocorreu com o VLC está exatamente dentro das regras escritas deste
jogo do licenciamento: é assim que funciona, e nem foi a primeira vez: a
disponibilização do jogo Battle for Wesnoth na App Store gerou uma situação bem parecida, mas com menos repercussão – possivelmente por não ser uma aplicação tão popular como o VLC.

Em
retrospecto, os desenvolvedores do VLC poderiam ter agido de várias
maneiras (no início de seu projeto) que evitariam esta situação. Duas
possibilidades seriam:

• Ter
  escolhido uma licença livre sem as restrições no estilo copyleft, como
  as licenças BSD ou a Apache (evitando assim a situação de
  incompatibilidade com os termos da App Store, mas abrindo mão das
  características de reciprocidade da GPL).
• Ter
  adotado a prática, similar à da Free Software Foundation, de só aceitar
  contribuições de usuários se eles transferirem os direitos a uma
  entidade central (que aí poderia relicenciar, ou conceder uma licença
  especial, quando fosse o caso)

Ambas
as alternativas têm seus riscos e suas vantagens, assim como há também
vantagens em manter a autoria coletiva sob uma licença com restrições no
estilo copyleft.

O
importante é que a escolha de uma alternativa ocorra de maneira
informada e racional para refletir as intenções de todos os integrantes.

Caso
contrário, o risco maior é o de chegar a uma situação de impasse como
esta, em que um único desenvolvedor tem pleno direito de brecar sozinho
uma iniciativa bancada pelos demais integrantes do projeto, que em casos
usuais poderiam ter a expectativa de poder tomar todas as decisões
estratégicas sobre o projeto – e poderiam, se esse tivesse sido o acordo
desde o início.

E
como não dá de mudar a regra do jogo depois que a partida já está em
andamento, e pode não ser possível convencer o desenvolvedor em questão a
mudar de ideia, nem convencer a proprietária a mudar os termos de uso
da App Store do iOS, no caso concreto agora o que
resta é se conformar em não usar este canal de distribuição desejado
pelos demais desenvolvedores, ou reescrever o aplicativo para retirar as
contribuições do desenvolvedor que discordou.

*

Artigo publicado originalmente no blog do developerWorks