A conformidade com licenças FOSS em eletrônicos de consumo

[ Este é um artigo de opinião, e não de assessoria jurídica. Os autores não são advogados ]

A conformidade com licenças FOSS – sigla para “software livre e de código aberto” – é um tópico controverso. Há diferentes perspectivas sobre quando e como se aplicam os termos das licenças, quais licenças podem ser usadas em conjunto e como problemas potenciais devem ser resolvidos. O mercado de eletrônicos de consumo é uma área na qual a conformidade com licenças FOSS é particularmente problemática. Isso se deve principalmente a razões econômicas e não à desonestidade, mas em um mercado que rendeu mais do que 335 bilhões de dólares em 2008, vale a pena investigar essa questão.

Devido à relativa juventude do ecossistema FOSS, não há muita jurisprudência nem informações sobre práticas recomendadas disponíveis. No passado, um dos poucos recursos disponíveis para a comunidade era o Debian Legal (em inglês), e as empresas não podiam contar com muita coisa além do apoio do Open Bar (EUA) e do ifrOSS (Europa).

Essa situação está melhorando. Organizações como o Free Software Licensing and Compliance Lab (Laboratório de Licenciamento e Conformidade do Software Livre, da FSF), o gpl-violations.org, a Freedom Task Force (Força-tarefa da Liberdade, da FSFE) e o Software Freedom Law Center (SFLC, ou “Centro da Lei da Liberdade de Software”) ajudaram a trazer abordagens legais e corporativas profissionais para a linha de frente do discurso do software livre. O lançamento recente da International Free and Open Source Software Law Review (Revista Internacional sobre a Lei do Software Livre e de Código Aberto) proporcionou uma plataforma neutra para discussões futuras. Assim como o FOSS amadureceu, o mesmo aconteceu com o nível das informações acessíveis para o apoio de empresas e projetos.

O ramo dos eletrônicos de consumo

Os eletrônicos de consumo são vendidos em grandes quantidades por margens de lucro pequenas, e a competição nesse mercado é dura. A maior parte das vendas ocorre durante os três primeiros meses após o lançamento, e o os consumidores buscam preço e funcionalidade ao escolher novas tecnologias. Os produtos são desenvolvidos na Ásia por fabricantes de dispositivos originais (os ODMs) e fabricantes de equipamentos originais (OEMs), e expedidos já completos. Poucas empresas ocidentais cuidam do próprio desenvolvimento, e mesmo as que possuem capacidade para montar internamente um produto completo geralmente optam por não fazê-lo.

Os ODMs/OEMs podem desenvolver produtos para empresas ocidentais concorrentes usando uma placa única, para poupar dinheiro. Um design de placa e um kit de desenvolvimento de software (ou SDK) são entregues pelo fornecedor que está acima na cadeia, como o fornecedor de chips, e o ODM/OEM adiciona hardware ou funções de software, para que então o sistema concluído ganhe uma embalagem personalizada. As empresas que compram esses itens podem rotulá-los como se fossem seus, adaptando painéis de controle, informações de contato e documentação.

Durante esse processo, podem surgir questões problemáticas acerca da conformidade com as licenças. O software livre e de código aberto originário de um fornecedor de chips pode ser fornecido com o código fonte incompleto ao ODM/OEM. Se o código fonte for fornecido de maneira completa, ele pode ser personalizado posteriormente pelo ODM/OEM e ser reintegrado apenas parcialmente na árvore de fontes. A equipe de marketing pode esquecer de incluir as licenças ou mesmo ofertas de código fonte por escrito no manual do produto. Ou seja, a lista de pontos de falha potenciais é longa.

A questão fundamental é simples. Se o código FOSS e as alterações feitas nele não forem integradas aos lançamentos dos fontes, ou se outros termos de licenças populares não forem atendidos, pode haver problemas de conformidade. Esses problemas ganham corpo quando uma placa “infratora” aparece em dispositivos fornecidos a diversas empresas ocidentais. Uma leva de relatos sobre violações de licença, englobando dezenas de empresas europeias e americanas, pode acabar apontando para um simples engano ocorrido durante o desenvolvimento provindo de um fornecedor asiático.

Por que ocorrem violações de licença?

Há muitos tipos de problemas relacionados à conformidade no FOSS. Os problemas específicos dependem da licença em uso, mas podem englobar pessoas que esqueçam de incluir uma cópia do texto da licença nos produtos, pessoas que esquecem de distribuir o código fonte junto com os binários ou a ausência de uma política para lidar com solicitações de código fonte, apesar desse serviço ter sido prometido por escrito. Costuma haver falta de comunicação entre o suporte, a manutenção do website e os departamentos legais, de modo que até mesmo material que tenha sido preparado corretamente pode se perder na confusão. À primeira vista, fazer tudo como deve ser feito pode parecer um desafio gigantesco.

No entanto, a conformidade com licenças FOSS não é mais complexa por natureza do que a conformidade com licenças proprietárias, e a conformidade como um todo não é tão difícil de ser alcançada ao ponto de infrações serem perdoadas. Existe até uma área chamada engenharia de conformidade, na qual especialistas externos ou uma equipe interna confirmam se o código distribuído com esses produtos atende aos requisitos da licença. O problema do mercado de eletrônicos de consumo é que a engenharia de conformidade é vista como um risco aos lucros. Há dois motivos para isso.

O primeiro é o fato do “timing” do mercado ser extremamente importante, e um atraso para que o produto chegue ao consumidor pode significar a derrota diante da concorrência. Uma engenharia de conformidade com níveis razoáveis de fidelidade leva alguns dias, e quando as empresas contam com apenas uma ou duas amostras de testes do produto à disposição para verificar sua funcionalidade, fica difícil achar um jeito de conseguir tempo para a verificação de conformidade. Além do mais, quaisquer perguntas que surgirem terão que ser respondidas pelo fornecedor, e potencialmente por outros interessados na cadeia de fornecimento. Qualquer código fonte ausente terá que ser localizado e integrado ao SDK. Se faltar código, ou se um fornecedor na cadeia simplesmente não liberar o código necessário (e isso acontece mais do que você imagina), é possível que um dispositivo sofra meses de atraso.

O segundo motivo é que os custos da engenharia de conformidade podem acabar com os lucros de um projeto. Um custo de 1.200 euros para a verificação de um dispositivo é razoável de acordo com as taxas praticadas no mercado, e isso é bastante dinheiro para o mercado de eletrônicos de consumo. O lançamento inicial de um produto geralmente é um teste para conferir a demanda, e pode consistir em uns 200 dispositivos disponibilizados ao público. Uma verificação de conformidade nesse estágio aumentaria o preço do produto em seis euros, e ainda que isso seja justificável por lei – a conformidade com a licença não se baseia na quantidade distribuída – ela pode ser difícil sob uma perspectiva econômica. Mesmo depois que a fase de testes é concluída e mais encomendas são feitas, se a empresa tiver planos de distribuir dez mil ou menos dispositivos, o custo por unidade continua sendo de pelo menos 12 centavos de euro.

Sofrendo essas duas pressões, as empresas envolvidas geralmente não perdem muito tempo tentando entender o licenciamento FOSS, nem montando uma infraestrutura para garantir a conformidade. Eles podem se ver em uma situação de ter que optar entre a distribuição de software fora da conformidade e o risco de um processo legal ou a perda de mercado por vendas perdidas. Como os casos envolvendo software FOSS nos tribunais são relativamente raros, os riscos de problemas legais parecem menores do que os de perda de mercado.

Se essa percepção continuará sendo verdadeira no futuro é algo discutível. O gpl-violations.org parece vir engendrando mudanças que parecem permanentes na abordagem corporativa ao software livre e de código aberto na Europa desde 2004, e o SFLC começou a se tornar proativo na busca pela conformidade de projetos nos Estados Unidos. A tolerância da comunidade ao comportamento negligente das entidades comerciais está diminuindo.

Essa mudança no mercado é previsível, dado o estado da tecnologia FOSS. A Comissão Europeia estima que o ecossistema de aplicativos FOSS com controle de qualidade e distribuição razoáveis em 2007 valia por volta de 12 bilhões de euros. Para a obtenção desse código, o custo é o de seguir os termos da licença, e como o valor desse código vem crescendo, seus criadores têm se tornado naturalmente menos tolerantes ao uso indevido.

O que os desenvolvedores podem fazer para proteger seus direitos

Os desenvolvedores que detêm direitos autorais sobre código têm várias maneiras de garantir que as licenças sejam obedecidas. Se você não possui os direitos autorais do código mas encontrou evidências claras de uma violação, é uma boa ideia avisar aos detentores dos direitos. Garantir um jogo limpo no uso das licenças ajuda a manter a confiança no ecossistema FOSS. Isso significa que as pessoas podem tomar decisões acerca de como o código será usado e ter uma certeza razoável de que todos seguirão os termos.

Ao avaliar as violações, talvez a coisa mais importante seja expressar os fatos corretamente. A cartilha de questões legais do SFLC para projetos de software livre e de código aberto (em inglês) pode ajudar nesse sentido, assim como seu Guia prático de conformidade com a GPL (em inglês). A segunda coisa mais importante é ser razoável e profissional. Deixar-se levar pela emoção ou não ter um bom entendimento do problema não ajuda a resolvê-lo, e certamente não vai contribuir para o desenvolvimento de um relacionamento produtivo.

Se tiver certeza absoluta de que uma violação ocorreu, você pode decidir o rumo a tomar para o cumprimento da lei (caso detenha os direitos autorais) ou informar aos proprietários do código (caso você não detenha os direitos). O primeiro passo em ambos os casos provavelmente consiste em documentar tudo cuidadosamente. A FSFE e o gpl-violations.org publicaram um breve documento sobre como relatar e corrigir violações a licenças (em inglês), que explica alguns dos pontos mais importantes a serem considerados. De acordo com as sugestões, seu relatório deve conter:

• O nome do produto afetado

• O motivo para que você acredite na ocorrência de uma violação

• O nome do código de projeto suspeito de violação

• Uma declaração indicando qual é a licença do código

• Um link para o site do projeto

Essas informações poderão ser usadas por você, pelo projeto em questão, por seus advogados, pela empresa infratora ou por terceiros como o gpl-violations.org, a FSFE, a FSF ou o SFLC para a análise da situação. Evite encaminhar debates anteriores por email e incluir comentários, pois isso dificulta a avaliação da situação.

Há um mecanismo formal estabelecido para que os detentores de direitos autorais garantam seus direitos por meio de ações legais. Para fazer isso, é preciso levar a parte infratora à justiça ou tentar um acordo extrajudicial. Sem dúvida, essa abordagem é eficaz, como podem atestar os membros do projeto gpl-violations.org, embora isso possa sair caro em termos de tempo e taxas iniciais. Há outras maneiras de se resolver casos de uso indevido de licença, e eles podem ser mais rápidos em algumas circunstâncias. Por exemplo, conversas informais podem funcionar quando ocorrem infrações acidentais, e a mediação da Freedom Task Force da FSE ou do Free Software Licensing and Compliance Lab da FSF já se mostraram eficazes no passado. Quando se trata de assessoria jurídica, profissionais independentes como Carlo Piana prestam uma assessoria excelente tanto para desenvolvedores quanto para as empresas interessadas.

Geralmente, conquistar a conformidade é uma questão educacional. O FOSS tem muitos novos adeptos, e muitas entidades comerciais que usam o código no mercado de eletrônicos de consumo têm um passado proprietário. Isso não é desculpa para o não entendimento das licenças, mas deve bastar, considerando-se que essas empresas podem se transformar em boas cidadãs na comunidade. As ações produtivas rumo à conformidade devem servir como um chamariz para que as pessoas se comuniquem e cooperem com os criadores de códigos, projetos e outras empresas da área.

A ideia não é punir. O objetivo é trabalhar em equipe e com boa fé.

Sobre os autores

Armijn Hemel é consultor de tecnologia na holandesa Loohuis Consulting, e é o engenheiro principal do projeto gpl-violations.org.

Shane Coughlan é consultor de negócios e tecnologia na japonesa Opendawn. Ele é um expert em licenciamento de código livre e aberto, padronização, métodos de comunicação e desenvolvimento de negócios.