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
