Contribute and be proud of defending Software Freedom from monopolist control! We are intervening in the Apple vs. EC case: Find out more.

Esta tradução pode estar desactualizada, por alteração do texto original. Pedimos ajuda para a tradução desta e de outras páginas de fsfe.org, para que as pessoas possam ler a nossa mensagem nas suas próprias línguas.

Defendendo os Padrões Abertos: a FSFE refuta as falsidades que a BSA transmitiu à Comissão Europeia

Escrito por , , e  em  
Transferir: PDF

A Business Software Alliance (BSA) está a pressionar a Comissão Europeia para eliminar os últimos vestígios de apoio aos Padrões Abertos da última versão das recomendações da UE em matéria de interoperabilidade, o Quadro Europeu da Interoperabilidade.

A FSFE obteve uma cópia de uma carta enviada à Comissão pela BSA na semana passada. Nos parágrafos seguintes vamos analisar os argumentos da BSA e explicar por que as suas alegações são falsas, e por que os Padrões Abertos são essenciais para a interoperabilidade e a livre concorrência no mercado europeu de software. Temos compartilhado esta análise com a Comissão Europeia.

  1. O licenciamento de patentes livre de royalties abre a participação e promove a inovação
  2. Os padrões que a BSA põe como exemplo são irrelevantes para a área do software
  3. O licenciamento (F)RAND em padrões de software é injusto e discriminatório
  4. BSA não é representativa tão sequer dos seu próprios membros, e muito menos da indústria do software como um todo
  5. A (F)RAND é incompatível com a maioria das licenças de Software Livre
  6. A preferência recomendada pelos Padrões Abertos é totalmente alheia à posição na negociação vis-a-vis entre a UE e a China
  7. As especificações sem restrições promoverão a livre concorrência, a padronização e a interoperabilidade
  8. Recomendações

O licenciamento de patentes livre de royalties abre a participação e promove a inovação

Na sua carta, a BSA argumenta que "[] Se a UE adota uma preferência por especificações livres de patentes e/ou royalties, isso prejudica os incentivos com os que as empresas contribuem a inovações ponteiras para a padronização - o que resulta em especificações europeias menos inovadoras, e produtos europeus menos competitivos. []"

Na verdade isso reflete um desconhecimento grave dos padrões, do seu papel e do seu funcionamento.

  1. As condições de licenciamento livres de royalties (Zero-royalty) não impedem que as tecnologias patenteadas sejam incluídas nos padrões. Em certo grau, o contribuinte é obrigado a evitar a imposição de royalties sobre as implementações.
  2. A plataforma de tecnologia de maior sucesso na Terra, a Internet, está baseada em padrões que foram disponibilizados integralmente em condições de licenciamento zero-royalty. Na verdade, o W3C, a organização de padronização (SSO) que rege os padrões na web tem adotado por consenso uma "política de direitos de propriedade intelectual" zero-royalty, onde os royalties sobre as tecnologias podem ser aceitadas apenas sobre uns fundamentos muito excepcionais. Ao invés de sufocar a atividade inventiva, como afirma a BSA, isso transformou a internet em um foco de inovação. Na verdade, é a própria natureza dos padrões a que estabiliza uma plataforma sobre a qual os concorrentes podem criar soluções inovadoras e interoperáveis1.
  3. Contrariamente ao que a BSA reclama, as políticas de licenciamento de patentes zero-royalty abrem a participação na configuração dos padrões de software para o maior número possível de partícipes e implementadores do mercado. Como resultado, os padrões de software que saem das organizações de padronização com políticas de licenciamento de patentes zero-royalty, como o W3C foram amplamente aceites, como o padrão HTML, só por ser o exemplo mais notável.

Desde uma perspectiva política mais ampla, também é questionável que os inovadores, que já estão recebendo um incentivo através de uma patente, precisem ser mais incentivados por ter essa patente incluída em um padrão. Uma patente não é igual a ter direito a um fluxo de rendas garantido.

Os padrões que a BSA põe como exemplo são irrelevantes para a área do software

A BSA argumenta que "[] muitas das especificações abertas que na atualidade estão mais amplamente implantadas incorporam inovações patenteadas que foram inventadas por empresas comerciais... incluindo o WiFi, a GSM e a MPEG."

Esta é uma tentativa de criar uma falsa dicotomia entre o empresas "comerciais" que inventam uma tecnologia patenteada, em contraste com as "não-comerciais" que não são invenções patenteadas. Na realidade um grande banco de riqueza de modernas tecnologias não patenteadas com origem em empresas comerciais constituem padrões aplicados a nível mundial (como HTML5), embora continuem a proporcionar aos seus criadores uma renda. Não há como fazer a divisão, seja a nível econômico ou ideológico, entre tecnologias de hardware e software que são patenteadas, e aquelas que não são. No entanto, a divisibilidade da BSA implica que há uma diferença entre os métodos de negócio convencionais e aceites, aos que associam com as patentes, e as organizações não-eficientes e não-comerciais, que eles associam com a tecnologia livre de patentes. Dada a crescente prevalência do Software Livre no mercado europeu de serviços de TI, tal afirmação é claramente falsa.

As normas que a BSA cita como exemplos (com excepção da MPEG 2) estão relacionadas com tecnologias baseadas em hardware. A economia do mercado de hardware é muito diferente da do mercado de software. Embora a entrada no mercado de hardware requer investimentos muito substanciais, as empresas de software podem iniciar a sua atividade com pequenas quantidades de capital. Exigir a estes iniciantes no software o pago de royalties para a implementação de padrões de software elevaria significativamente as barreiras à entrada no mercado, reduziria a inovação e dificultaria a livre concorrência, e também aumentaria os preços para os consumidores (incluindo as organizações do sector público).

Para o software, no entanto, é claro que permitir a inclusão de patentes nos padrões de software baixo as condições (F)RAND vai aumentar indevidamente e desnecessariamente as barreiras à entrada no mercado europeu de software, tornando a economia das TIC da Europa menos competitiva.

O licenciamento (F)RAND em padrões de software é injusto e discriminatório

A BSA argumenta que "[] Os requerimentos de que uma especificação aberta seja "livremente implementável" e capaz de ser compartilhada e reutilizada são ambíguas, e sugerem que o padrão deve estar livre de direitos de propriedade intelectual (IPR)."

A BSA também argumenta que "[A FRAND garante que] os implementadores de um padrão podem utilizar as inovações em termos justos. Isto permite que os inventores cobrem uma taxa razoável quando as tecnologias são incorporadas as especificações[.]" Nos padrões de software, as condições (F)RAND, de facto, discriminam o Software Livre e qualquer modelo de negócio baseado nele. As licenças de Software Livre mais amplamente utilizadas não permitem a imposição de condições adicionais aos posteriores receptores. No entanto, as (F)RAND exigiria que tais condições foram impostas, geralmente sob a forma de royalties, interpretando-se que as políticas de licenciamento (F)RAND são incompatíveis com o Software Livre. Quando falamos de padrões de software, interpreta-se que a abordagem das (F)RAND não é razoável nem não-discriminatória.

Por outro lado, o "zero-royalty" não exclui as implementações privativas (nem sequer as fortemente patenteadas). Na verdade, "Zero-royalty" significa que, se certas tecnologias estão comprometidas por um padrão, estas deverão estar disponíveis para todos sem exigir royalties. Entretanto, as implementações podem ser distribuídas sob qualquer licença e incluir qualquer tecnologia, desde que a norma seja respeitada.

O padrão HTML livre de royalties, por exemplo, foi implementado em uma infinidade de navegadores, tanto em Software Livre como em privativo. Isto demonstra claramente que um padrão de software livre de royalties pode permitir a adoção generalizada, e impulsionar a inovação através da livre concorrência.

BSA não é representativa tão sequer dos seu próprios membros, e muito menos da indústria do software como um todo

A BSA argumenta que "O Quadro Europeu da Interoperabilidade (EIF) pode ser lido com a interpretação de que as empresas europeias e estrangeiras mais inovadoras não são convidadas a participar de processos de padronização se têm patentes próprias em tecnologias relevantes e buscam compensações pelas suas invenções se essas patentes são integradas no padrão."

A BSA ainda reivindica que "Os investidores reconhecem que existe um vínculo importante entre o DPI e a padronização - e também reconhecem que os padrões baseados nas FRAND são altamente flexíveis e podem ser implementados em uma ampla gama de soluções de código aberto e privativo".

Contrariamente ao alegado pela BSA para representar uma posição unificada do setor de software, lembremos que a ECIS, que está formado por importantes membros da indústria (alguns dos quais também são membros da BSA) diz o contrário3. Apesar de ter um grande portfólio de patentes, os membros da ECIS querem padrões para que a interoperabilidade do software permaneça sem as cargas de funcionar baixo os requisitos de royalties das patentes []. Para citar apenas um exemplo, a Google tem contribuído fortemente com os padrões zero-royalty, oferecendo uma alternativa para a MPEG patrocinada pela indústria.

A (F)RAND é incompatível com a maioria das licenças de Software Livre

A BSA afirma que "a maioria das licenças das OSS são totalmente compatíveis com o licenciamento baseado nas FRAND."

Desde um ponto de vista razoável (quer seja baseado na quantidade de código disponível ou a importância do mesmo, ou ambos) as licenças de Software Livre ou open souce mais relevantes são:

  1. A GNU GPL e LGPL
  2. A Mozilla Public License
  3. A Apache Public License
  4. A BSD/MIT e outras licenças ultra-permissíveis
  5. A EUPL

Todas elas, com a única excepção discutível mas incerta da categoria ultra-permissiva, são claramente incompatíveis com um regime de patentes com royalties. De acordo com as estatísticas publicadas pelo Black Duck Software, mais do 85% dos projetos de Software Livre são distribuídos sob licenças que são incompatíveis com os regimes de patentes com royalties. Está demostrado que a GNU General Public License (GPL) é, de longe, a licença de Software Livre mais amplamente utilizada, por ser usada por quase a metade de todos os projetos. Incluir as tecnologias patenteadas em produtos de Software Livre, quando é possível, exige que os implementadores misturem partes privativas com Software Livre de forma desajeitada. Nesses casos, o código resultante é necessariamente software privativo5.

A preferência recomendada pelos Padrões Abertos é totalmente alheia à posição na negociação vis-a-vis entre a UE e a China

A BSA afirma que "[a] ambiguidade da preferência proposta pelo EIF, sem dúvida compromete a capacidade da Comissão para manter a sua firme defesa dos titulares de direitos de propriedade intelectual da Europa [contra as ameaças da China]."

As alegações de que uma recomendação para expressar preferência por especificações abertas vai enfraquecer a posição na negociação vis-a-vis entre a UE e a China são claramente falsas. As recomendações relativas à utilização de especificações de software abertas no setor público não têm influência alguma sobre a posição da Comissão. Além disso, vale a pena repetir que as normas "zero royalty" não colidam com a "defesa robusta" das patentes, do copyright e das marcas comerciais.

Note-se que nos Estados Unidos, preocupações semelhantes foram submetidas à US Trade Representative na preparação para o relatório 2010 US Special 301 sobre os obstáculos ao comércio. A US Trade Representative optou por não incluir estas preocupações no relatório, demonstrando claramente que o governo dos Estados Unidos considera que este não é um problema. Embora tais alegações podem ser feitas como esforços para influenciar políticas públicas, há uma marcada ausência de tentativas para suprimir essas preferências por meios jurídicos - presumivelmente porque aqueles que fazem estas afirmações sabem muito bem que eles, de fato, não têm respaldo.

As especificações sem restrições promoverão a livre concorrência, a padronização e a interoperabilidade

A BSA afirma que "a preferência proposta pela EIF pelas especificações livres de PI vai minar... a padronização, a competitividade e a interoperabilidade, a longo prazo."

Nós somos incapazes de determinar o que a BSA entende por especificações "livres de PI", embora acreditamos que tal formulação sugere um conhecimento insuficiente do processo de normalização por parte da BSA.

A alegação de que a atual formulação da EIF poderia prejudicar a interoperabilidade é simplesmente inaceitável. Ela flui de hipóteses não comprovadas que temos demonstrado ser falsas na discussão exposta anteriormente. Atualmente, o efeitos de bloqueio resultantes da utilização de programas e formatos de arquivo privativos muitas vezes impede as administrações públicas escolherem livremente as suas soluções de TI. Em vez disso, eles permanecem ligados a um determinado fornecedor. As dificuldades do Município de Brighton e do cantão suíço de Solothurn (por citar apenas dois exemplos dos últimos meses), juntamente com inúmeras outras entidades públicas, na migração de uma solução de TI para outra ilustra como o aprisionamento tecnológico causado por padrões de software coberto por patentes, vinculam os usuários a soluções precárias, com um grande custo para os contribuintes.

Por outro lado, os padrões de software que podem ser implementados sem restrições permitem muitas implementações concorrentes para interagir umas com as outras. Neste cenário, os lucros dos monopólios para um número muito limitado de grandes competidores são substituídos por um mercado vibrante e inovador impulsionado por uma concorrência feroz. Isso resulta em melhores soluções e serviços a preços mais baixos.

Recomendações

À luz das considerações expostas, instamos a Comissão a promover a interoperabilidade e a livre concorrência no mercado europeu de software, ao invés de dar às empresas dominantes uma alavanca adicional para manter o seu controle sobre o mercado. Para este fim, pedimos à Comissão que não aprove as políticas de licenciamento (F)RAND para os padrões de software. Em vez disso, instamos a Comissão a manter a recomendação de que as especificações podam ser consideradas abertas apenas se podem ser implementadas e compartilhadas baixo diferentes modelos de licenciamento de software, incluindo o Software Livre 6 licenciado sob a GNU GPL.

Pedimos também à Comissão que inclua na revição do Quadro Europeu da Interoperabilidade uma robusta recomendação para que os organismos públicos se beneficiem das vantagens do software baseado em Padrões Abertos 7 em termos de escolha, livre concorrência, liberdade de aprisionamento tecnológico e acesso a longo prazo aos dados.

Notas de rodapé

  1. Ver, por exemplo: Rishab Aiyer Ghosh, Philipp Schmidt (2006): Documento da Política da Universidade das Nações Unidas, Número 1, de 2006: "Os padrões abertos, definidos de forma consistente, podem ter o efeito econômico excepcional de permitir a formação de monopólios "naturais" em uma determinada tecnologia, garantindo a livre concorrência plena entre os fornecedores dessa tecnologia." [ênfase adicionada]
  2. A MPEG está desenhada especificamente para usar de maneira explícita tecnologias patenteadas, mesmo quando são em grande parte substituíveis (provavelmente) por alternativas não patenteadas que são menospreçadas. Isto é concebível devido à necessidade de extrair o máximo lucro possível com a utilização da sua peculiar aplicação de certos princípios matemáticos, anteposta à necessidade de criar uma plataforma comum e padronizada para fins de interoperabilidade.
    Além disso, a maioria dos padrões MPEG foram estabelecidos em uma época em que os codecs foram feitos em hardware tanto porque a largura de banda disponível era limitada como porque o hardware genérico não era suficientemente potente.
  3. Veja a reação da ECIS à carta da BSA, do 13 outubro de 2010
  4. Para uma discussão sobre soluções híbridas em protocolos de rede, veja a resposta da FSFE e o Samba Team ao artigo 18.
  5. Veja a definição de Software Livre da FSFE
  6. Como definimos nas definições da FSFE de um padrão aberto