segurança computacional > textos > Padrões : caso ODF x OOXML

---

I

Introdução

110 ou 220 Volts? Álcool ou gasolina? Aparelhos bivolt e motores flex ganharam a preferência do consumidor porque resolvem problemas inevitáveis no convívio com padrões superpostos. No caso, padrões para rede elétrica e combustível automotivo, respectivamente. E na informática? O convívio com padrões na informática é uma questão bem mais complexa, e crucial. Porém, por razões que convém aqui especular, pouco ou mal debatida. O objetivo deste artigo é contribuir para melhorar esse debate, pelo menos sobre um convívio que se faz inevitável em nossa sociedade infoglobalizada.

Na informática, quando uma tecnologia inova a ponto de causar rupturas em mercados, o processo de padronização de suas aplicações pode se consolidar antes que estratégias de negócio o dominem. Quando há apenas expectativas, e se busca criar novos mercados para aplicações, esse processo pode convergir, consolidando opções em um padrão único, aberto e livre de restrições artificiais. Rumo a rupturas, e inovação. A disposição das letras no teclado, o código ASCII e o padrão http/html (que torna possível a web), estão entre os exemplos mais conhecidos.

Mas essas rupturas são raras. Mais ainda é a convergência a padrão único, aberto e livre, sem elas. Quando visa a mercados já estabelecidos, o processo de padronização se expõe aos efeitos de estratégias negociais que, mesmo sendo positivos para quem os controla, resultam negativos para o consumidor. No Brasil, quem nunca se aborreceu com combustível adulterado? Quem nunca queimou um aparelho, ou deixou de usá-lo, por diferença de voltagem? Na informática, muitos padrões têm como único efeito prático o vendor lock-in. O que equivale, grosso modo, à voltagem da rede elétrica só poder ser conhecida, e utilizada, por um fornecedor de aparelhos, o mesmo que distribui energia.

Quando esse efeito atinge usuários de software, seu aprisionamento à marca ocorre através do controle que o fornecedor exerce sobre certos padrões, técnica ou legalmente fechados, pelos quais o software se comunica com outros, lê e grava dados para usuários. Tomando a analogia entre dados e energia, é como se o aparelho operasse produzindo resultados na própria rede elétrica, e a voltagem na rede variasse conforme certos segredos do fornecedor, manipulados pelo aparelho, inviabilizando o uso compartilhado dessa rede com aparelhos de outros fornecedores. É como se um tal fornecedor pudesse dizer: "eletrodomésticos Furnas proporcionam uma Experiência Aumentada".

Trata-se do "efeito rede", sobre a padronização. Padrões dominantes se tornam padrões de fato, confundidos com a marca. Quando um tal padrão é fechado, fornecedores que praticam o vendor lock-in (p.ex.: Windows, música ou vídeo com DRM) douram a pílula chamando-o de "descomoditização". Economês que parece inofensivo. Mas há padrões e padrões. Quando o esforço para se adotar um padrão único, aberto e livre de restrições artificiais, enfrenta os problemas de se conviver com padrões superpostos, fechados e restritos que não interoperam (padrões proprietários "de mercado"), a lógica premia a (quase) todos pela adoção. Com ganhos de escala e competitividade, via comoditização.

A lógica da Padronização

A lógica da padronização não é apenas técnica e econômica. É também social e política. Na sociedade, uma padronização sadia promove a articulação de estratégias concorrenciais sadias. E ao Estado, permite objetividade e eficácia na aplicação de leis concorrenciais e de consumo. Uma padronização sadia precisa garantir a transparência necessária para resolução equilibrada de conflitos entre interesses envolvidos na formação e manutenção do padrão. Os benefícios sociais e políticos de uma padronização sadia ficam bem evidentes no setor financeiro. Como reconhecer dinheiro legítimo? E seu valor futuro? Como auditar empresas de capital aberto? Padrões deficientes aí precipitam crises.

Através da padronização é que surge, como subproduto do desenvolvimento, a setorização produtiva. Um setor da indústria faz componentes eletrônicos, outro faz aparelhos, outro fornece energia elétrica. O mesmo com autopeças, automóveis e combustíveis. Quanto mais uma sociedade competitiva se desenvolve, em busca de maior produtividade, mais ela depende de padronização eficaz. E mais importância nela ganha o processo de negociação, adoção e manutenção de padrões. E nele, o equilíbrio de interesses. Cuja falta não só impõe riscos à sociedade, mas também condena a fracassos, por exemplo, tratados de "livre comércio" como os promovidos pela OMC.

Quando padrões proprietários se estabelecem como padrões de fato pela ação dominante de fornecedores, a lógica da padronização os leva a se aglutinarem, para a consolidação e expansão de monopólios e cartéis (p.ex.: celulares bloqueados, Windows media, etc.). Isso ocorreu, no início do século passado, no setor então emergente da indústria petrolífera, nos EUA. Até que os efeitos nefastos daquela consolidação "espontânea" levassem a sociedade norte-americana a intervir, impondo padrões "de jure" (p.ex.: sobre direitos de prospecção) e legislando contra práticas anti-competitivas. Através do Sherman's Act, de 1917, que até hoje tem servido de modelo para legislações anti-concorrenciais.

Mas a sociedade agora é outra, informatizada e globalizada. Nela, essas práticas são toleradas. Ofuscadas pela dogmática propaganda de uma suposta supremacia da "propriedade intelectual" (termo que significa nada, ou coisas díspares). E o desafio se renova: como reavaliar eficácia nos processos de padronização? Para uma resposta isenta, o maior complicador vem da natureza dos bens envolvidos: os mais estratégicos não são mais bens materiais, são simbólicos. Nas TIC, são realizações ou direitos de uso de tecnologias, licenças e -- no caso que iremos abordar -- softwares. Com custo de produção marginal irrisório, software executável é um bem de natureza não-rival. Mas o modelo negocial ainda dominante -- o proprietário -- trata-o como bem rival, baseando-se na venda de licenças de uso restritivas. Trata-o, portanto, como sabonete.

Todavia, a natureza não-rival do software acaba se manifestando no seu valor de uso. Software é conhecimento, condensado em código, para intermediar coletivamente a inteligência e a comunicação humanas. Tratá-lo como sabonete -- ou seja, como bem rival -- é um artifício, que só faz sentido na lógica econômica dos que o adotam. Sustentar tal artifício na esfera normativa não é mandamento de Moisés. É uma artificialidade que tem seu custo, que só foi competitivo numa certa fase evolutiva das TIC. Na fase entre a comoditização do hardware e a universalização da Internet. Passada esta fase, a eficácia sócio-técnica e econômica do modelo proprietário depreciam-se, frente a modelos alternativos baseados em licenciamento permissivo, produção colaborativa e rendimento sobre suporte e serviços.

Padronização em software

Com a infoglobalização, softwares de uso geral se tornam bens anti-rivais: seu valor de uso aumenta com sua disseminação, alavancando seus mercados de suporte e serviços, e estabelecendo padrões de interoperabilidade para outros softwares. Eis uma razão para modelos alternativos -- que precisam de massa crítica -- adotarem licenças permissivas, onde o direito de uso e de redistribuição são livres. A mesma razão para o modelo proprietário -- que precisa de consolidar marcas -- tolerar a pirataria doméstica, enquanto seus mercados estiverem se expandindo. Mas essa expansão já arrefeceu, e a competição entre modelos é darwiniana. Agora, a única maneira viável de se bancar apostas no modelo proprietário é com expansão e fortalecimento dos mecanismos de vendor lock-in. Ou, como preferem seus adeptos, de descomoditização.

Aí a competição inter-modelos recrudesce, como reflete a radicalização global de regimes de propriedade imaterial. No uso, por exemplo, das patentes de software como armas de achaque e de barreira à entrada de novos concorrentes nos mercados de TIC. Neste cenário, o Estado se torna um agente legitimador e um cliente estratégico. Não só pelo volume de compras e pela necessidade de interoperar seus sistemas, mas pela capacidade de impor padrões aos governados. Na educação, por exemplo, onde hábitos se formam. Ou no fisco, do qual ninguém escapa. Com o valor de uso de bens simbólicos anti-rivais (i.e., software) atrelado a padrões de fato, e com modelos negociais obsolescentes e emergentes assim competindo, o Estado se torna ator principal nos processos de padronização, de jure e de fato. E por isso, será pressionado.

Pressionado, de um lado, pelos que apostam no modelo proprietário. Para que o Estado sustente, com critérios normativos e licitatórios, as pontes que interligam seus padrões de mercado e suas práticas de negócio. Com a lógica de argumentação pela inércia, persuasiva na esfera operativa: o custo atual de migração para outros padrões e modelos é alto. E de outro lado, pelos que apostam em modelos emergentes. Para que o Estado lance, nesses critérios, as pontes que interligam a adoção de padrões sadios e o papel social dos envolvidos. Com a lógica de argumentação pela autonomia, persuasiva na esfera pública: o custo futuro da dependência a padrões fechados e monopólios é incerto.  

Numa sociedade cada vez mais dependente das TIC, o Estado eventualmente verterá em norma sua compreensão, inevitável ainda que tardia, de que sua infraestrutura digital precisa ser adequadamente protegida. Se seguir seu instinto de sobrevivência, em normas que protejam seu acervo de registros, documentos e canais eletrônicos, contra manipulação indevida e para controle sobre a sociedade. E se cumprir seu papel constitucional, em normas que protejam a sociedade, e a si mesmo, contra estratégias negociais de fornecedores que conflitem com seus interesses, sua função ou soberania. Diante de potenciais conflitos, essa pressão faz aumentar o risco de conluio entre fornecedores e governos.

Em 2004 o estado de Massachussetts (EUA), berço das democracias modernas, deu exemplo de como abordar essa pressão e risco: abriu ao debate público seu processo de normatização para o planejamento, desenvolvimento, aquisição e manutenção de sua infraestrutura de TICs, o ETRM (Entreprise Technical Reference Model). Pela necessidade de garantir, com neutralidade tecnológica a médio e longo prazos, racionalidade administrativa, acessibilidade aos recursos e interoperabilidade entre agências, serviços e usuários, o ETRM inclui uma política de padrões abertos, a OSP. Em debate, o que significa um padrão ser aberto. Em jogo, critérios técnicos para planejamento e licitações.

Padrões abertos livres

Nesse processo, a agência ITD (Information Technology Division) aprovou, em setembro de 2005, a versão 3.5 do ETRM, que define padrão aberto como "especificações que são publicamente disponíveis, desenvolvidas por uma comunidade aberta e atestadas por um órgão de padronização. HTML é um exemplo. Padrão aberto implica em vários fornecedores poderem competir com base em recursos e performance dos seus produtos, que a solução seja portável e possa ser substituída pela de outro fornecedor com esforço mínimo e sem muita interrupção." No domínio das aplicações de escritório (editores de texto, planilhas, etc.) o ETRM exige suporte default a formatos abertos, definidos como:

"Specifications for data file formats that are based on an underlying open standard, developed by an open community, affirmed and maintained by a standards body, and are fully documented and publicly available"

Junto com o ETRM, o ITD aprovou também a lista dos formatos para o domínio das aplicações de escritório que haviam sido homologados, durante a consulta pública até aquela data, com relação aos critérios da OSP.  Três formatos haviam se classificados como "Open Format": OASIS Open Document Format (ODF) for Office Applications (.odt, .odp, .ods, etc.) v. 1.1, Hypertext Document Format (.html) v. 4.01; e Plain Text Format (.txt). E um, como "Acceptable Format": Adobe's Portable Document Format (.pdf). A versão 3.5 do ETRM também identifica um plano de migração para os órgãos de governo de Massachussetts que geravam documentos em formatos proprietários. 

Esses órgãos teriam que desenvolver planos locais de migração, para que aplicações tais como MS Office, Lotus Notes, e WordPerfect pudessem ser substituídas, ou adaptadas para configurações que permitissem gravar por default documentos em formato ODF. Com prazo de implementação até 1º de Janeiro de 2007. Ainda, qualquer novo aplicativo de escritório adquirido deveria dar suporte nativo ao formato ODF. Durante o debate público sobre o ETRM, fornecedores interessados ou detentores de tecnologias envolvidas no padrão ODF buscaram ajustar suas licenças para que seus produtos pudessem, com o ODF, alcançar os critérios da política de padrões abertos do ITD.

Já a fornecedora com maior penetração na infraestrutura digital de Massachussetts, esta preferiu apostar na inércia; ao longo do debate público sobre a política de padrões abertos, hesitou, sofismou, confundiu ou confundiu-se em relação a critérios mínimos de transparência, portabilidade e neutralidade concorrencial. Ao final, não aceitou incluir no MS Office suporte nativo aos formatos abertos já homologados na OPS, nem cogitou alterar suas licenças de patente sobre tecnologias incluídas em seus formatos default, ainda padrões de fato. Quando seus formatos falharam nos critérios da OPS, acusou de conduta improba um diretor do ITD e buscou intervir politicamente sobre o processo.

O ODF é um padrão técnico para formato de arquivos, que usa a linguagem XML para representá-los internamente, aberto e livre de restrições patentárias, mantido pelo consórcio OASIS (Organization for the Advancement of Structured Information Standards), desenvolvido durante um período de mais de dois anos, aprovado em maio de 2005 (OASIS v1.0) e ratificado um ano depois pela ISO (International Standars Organization), como padrão ISO/IED 26300. É adotado por aplicativos de escritório de mais de vinte fornecedores, entre proprietários (ex.: Lotus Notes) e livres (ex.: OpenOffice.org), como formato nativo para visualização e gravação de documentos eletrônicos.

II

Contexto histórico do ETRM

O processo de consulta pública do ETRM, e as decisões do ITD, vinham sendo acompanhados de perto por outras jurisdições e atores do mercado, em busca de racionalidade e oportunidades na produção colaborativa, ou de escape a efeitos sedimentados por vendor lock-ins. Vários órgãos governamentais logo passaram a seguir o exemplo do ITD, em busca de políticas autônomas para suas infraestruturas digitais. A reação da maior empresa do planeta, encastelada no modelo proprietário e em práticas descomoditizantes, foi de intensa e disseminada resistência, agora proativa. Reação que o restante deste artigo busca descrever, sob a perspectiva limitada do autor.

Antes da aprovação do ETRM, a Microsoft  havia sido convidada a participar do Comitê Técnico do ODF na OASIS, mas preferiu ficar de fora. O Comitê fez o melhor a seu alcance para que o padrão ODF funcionasse bem com o MS Office, mas esse alcance foi limitado pela objeção da Microsoft em cooperar. Objeção que parece estratégica, apesar do que diga hoje em público sobre padrões abertos. Pois em todas as instâncias de ações onde é ré, por abuso monopolista ou práticas anti-concorrenciais, a Microsoft segue defendendo sua prática de tratar, quando convém, especificações de padrões implementados por seus softwares como segredo de negócio. E onde já condenada, segue arrastando os pés no cumprimento de ordens judiciais para cooperar com a interoperabilidade de seus softwares divulgando especificações.

Antes disso, em sua ascensão rumo à dominância no desktop, ela jogara com expectativas e frustrações de parceiros e clientes, no que diz respeito a essa interoperabilidade, para acumular vantagens econômicas pela transgressão a normas anti-competitivas -- esvaziadas pela dogmática neoliberal. O rastro desta exploração, traçado em vendor lock-ins, marca sua conduta no processo de padronização controlado por seus softwares, até o divisor de águas representado pelo ETRM 3.5 em Massachussetts. Para ilustrar, citamos o caso dos aplicativos de escritório, que ali falharam na homologação, e o caso dos protocolos para servidores de arquivo.

Quando lançou, em 1994, seu software de planilha eletrônica, o Excel, a Microsoft divulgou especificações do formato de arquivos utilizado, junto com um kit para desenvolvedores, antes de incorporá-lo ao pacote Microsoft Office 95. Em 1997, pouco antes da aprovação da primeira versão da linguagem XML, depois de lançar a versão seguinte desse pacote (Office 97) a empresa passou a restringir, através da licença MSDN, o uso de seus formatos binários por desenvolvedores concorrentes. Em um memorando interno, depois incluído nos autos de uma ação judicial por práticas anti-concorrenciais (Comes vs. Microsoft, Iowa, 2006), Bill Gates instrui:

"One thing we have got to change is our strategy -- allowing Office documents to be rendered very well by other peoples' browsers [...]. We have to stop putting effort into this and make sure Office documents very well depend on proprietary IE capabilities"
(Trad. do autor: Uma coisa que precisamos mudar é nossa estratégia -- de permitir que documentos do Office sejam visualizados muito bem por navegadores alheios [...]. Temos que parar de fazer isso e garantir que documentos do Office dependam bem de recursos proprietários do Internet Explorer)

Quando a versão seguinte do MS Office -- a 2000 -- foi lançada, formatos de arquivos implementados -- usando XML -- foram apenas parcialmente documentados. A documentação dos formatos binários foi abruptamente retirada do serviço MSDN e disponibilizada apenas sob "licença especial", restrita ao desenvolvimento de aplicações "complementares" ao MS Office. Depois que foi lançado, em 2000, o software livre OpenOffice, com formatos de arquivos nativos usando padrões abertos em XML e livres de restrições patentárias, a versão XP do MS Office foi lançada, em 2001, com novos formatos em XML, documentados também parcialmente.

Manipulação de padrões fechados-o-suficiente

Clientes e desenvolvedores que se precipitaram a investir nos padrões anteriores do MS Office viram seu investimento erodido, por mais este ciclo de mudanças em padrões incompletos. ciclo que se repetiu com as versões seguintes. Com o MS Office 2003, depois da formação do comitê técnico para desenvolvimento do padrão ODF na OASIS, e agora com o MS Office 2007, em seguida à aprovação do ODF pela ISO (em 2006). Certas especificações para formatos de arquivos do MS Office 2007 foram juntados num calhamaço batizado de "Office Open XML" (o nome "Open Office XML" já havia sido usado num padrão anterior), e este, submetido a um comitê de padronização da ECMA (European Computer Manufacturers Association)

O caso dos protocolos de servidor de arquivos também mostra ambivalência. Nos dias em que o Netware Novell dominava esse segmento de mercado, a Microsoft era grande entusiasta da padronização. Ela publicou as especificações do seu próprio protocolo (então chamado SMB, Server Message Block), e apoiou sua implementação em outras plataformas, além do Windows. Cobriu despesas de convidados para a primeira conferência que organizou sobre o tema, dentre eles Andrew Tridgell, futuro arquiteto do software SAMBA, e até submeteram o protocolo SMB (agora chamado CIFS, Common Internet File System) como um padrão da Internet (IETF).

Porém, assim que o Netware foi derrotado pelo Windows NT suas atitudes mudaram, e o fluxo de informação acerca dos protocolos estancou. Seguiram-se modificações proprietárias a protocolos básicos, como o de autenticação Kerberos, modificações tratadas como segredo de negócio, quando não patenteadas. E quando divulgadas, quase sempre em cumprimento a sentença judicial por práticas anti-concorrenciais (i.e., MCPP, Microsoft Communications Protocol Licensing Program), apenas sob contrato de sigilo.

Pelo simples fato de usar XML, e da ECMA tê-lo aprovado (ECMA-376, dezembro 2006) com o nome "Office Open XML", o OOXML quer se fazer passar por padrão aberto, enquanto é controlado pela Microsoft, incompleto -- apesar de excessos detalhistas -- e sujeito a restrições patentárias indefinidas, em subreptício e fundamental contraste ao ODF. Submetido pela ECMA, em maio de 2006, ao comitê JTC-1 da ISO para aprovação em regime Fast Track (DIS 29500), foi ali rejeitado, em primeira votação em setembro de 2007, devido a centenas de deficiências técnicas. Cabe então entender porque um padrão técnico aprovado por uma associação de fabricantes assim fracassa.

Primeiro, sobre o regime Fast Track na ISO. O Fast Track não é um processo para desenvolvimento de padrões. Serve para transpor padrões já amadurecidos, por consenso na indústria, com rapidez ao status de padrão global. Por isso o regime inicia-se no último estágio -- o quinto -- do processo normal para desenvolvimento de padrões na ISO. E só algumas instituições regionais, como a OASIS e a ECMA, têm lá status semelhante ao de despachantes, para submissão de propostas em regime Fast Track.

O que é ECMA?

Segundo, sobre a ECMA. O nome poderia sugerir um fórum ou grupo onde a indústria européia amadurece e pactua padrões. Como a OASIS, que levou dois anos e meio para desenvolver o ODF, como um padrão aberto de fato, antes de aprová-lo e submetê-lo ao regime Fast Track no JTC-1 da ISO. Mas não é bem isso que diz, por exemplo, uma apresentação do próprio grupo (slide 21), em resposta à pergunta retórica sobre o valor da ECMA. A ECMA seria...

"A proactive, problem solving experts' group that ensures timely publication of international standards;
Offers industry a "fast track" to global standard bodies, through which global standards are made available on time;
Balances Technical quality and Business Value:

• [...] Better a good standard today than a perfect standard tomorrow!
• Offers a path which will minimize risk of change to input specs
• Solid IPR policy and practice [direitos de propriedade imaterial]
  

Nesta linha, com uma "proposição de valor" equiparável à de transformar organismos internacionais de padronização em clubes filatélicos,  para o comércio de selos raros com carimbo de "padrão aberto", a ECMA processou, aprovou e despachou, em menos de um ano, o calhamaço OOXML para o Fast Track do JTC-1 da ISO. Ao invés de arregimentar o talento técnico da proponente para desenvolver, com a participação de demais interessados, um padrão de verdade, um padrão que poderia passar sem problemas pelo processo na ISO, preferiu intermediar um jogo que, conforme anunciado, está se revelando um verdadeiro seqüestro político-econômico desse processo.

Esse jogo é jogado com a análise técnica do padrão, oferecida por demais interessados em padronização de documentos eletrônicos. As falhas técnicas encontradas na proposta OOXML, e reportadas à Microsoft, foram ignoradas, sobre o pretexto de que não eram falhas, ou de que não eram técnicas. Depois, quando reportadas à ECMA, durante o período de 30 dias que o comitê encarregado (TC45) alocou para "resolução de contradições", foram também ignoradas.

Numa reunião do TC45, quando Stephen Mutkowski, representando a Microsoft, depois de apresentar sua enrolação marqueteira, foi perguntado o que, exatamente, nas milhares de páginas de especificação do OOXML garante compatibilidade retroativa com os 40 bilhões de documentos criados pelos aplicativos legados da empresa, ele sequer tentou responder. Questionamentos como esse foram ali ignorados sob o pretexto de que seriam resolvidos durante o período de 5 meses que a ISO aloca para a primeira votação em regime Fast Track, encerrado para o OOXML em setembro de 2007.

E quando, nesses cinco meses, as falhas foram levantadas pela terceira vez, agora por organismos nacionais votantes no JTC-1, a Microsoft hora argumentava que as mesmas já haviam sido discutidas no processo da ECMA, hora que seriam discutidas na reunião de resolução de voto (BRM, Ballot Relosution Meeting), segunda votação que pode encerrar o processo Fast Track do OOXML na ISO, em fevereiro de 2008. Pode-se imaginar que, se o BRM ocorrer, a Microsoft irá sugerir que as falhas serão remediadas durante o processo de manutenção do padrão. Isso cairia bem em seus planos, pois ela já emplacou como fato, em grandes serviços de mídia, a enrolação marqueteira ainda inexplicada, e já peticionou o comitê JTC-1 da ISO para que a manutenção do OOXML seja delegada ao comitê TC45 da ECMA. Assim, ela fecharia o ciclo do controle desse padrão, no qual "remediaria" o que e como quiser.

Por que o OOXML não é padrão aberto

Da mesma fonte judicial anterior (Comes vs. Microsoft), entendimento próprio do que significa esse controle:

[Microsoft]: “…we should take the lead in establishing a common approach to UI and to interoperability (of which OLE is only a part). Our efforts to date are focussed too much on our own apps, and only incidentally on the rest of the industry. We want to own these standards, so we should not participate in standards groups. Rather, we should call ‘to me’ to the industry and set a standard that works now and is for everyone’s benefit. We are large enough that this can work.”

Ou ainda, da introdução no artigo "Effective Evangelism":

"It is our job to ensure that those choosing [software] are presented with an overwhelming abundance of evidence and reasoned argument in favor of our standards."
(Trad. do autor: É nossa tarefa garantir que aqueles que escolhem software sejam apresentados a uma esmagadora abundância de evidência e argumento arrazoado em favor dos "nossos padrões")

Para isso, há mais de 50 bilhões de dólares em caixa. Para esmagar consumidores com arrazoados em favor de padrões da Microsoft, não em favor de padrões que solucionam problemas criados por vendor lock-ins. Com rendição à "proposta de valor" da marca, com cumplicidade da imprensa corporativa que de verba publicitária precisa para se manter solvente. Neste sentido, logo após aprovada a versão 3.5 do ETRM a empresa inverteu sua postura em relação a padrões internacionais de jure. Passou a buscar o selo de "padrão internacional aberto" para vários dos seus, o quanto antes e de qualquer jeito. Com dano colateral ao valor de organismos de padronização, como a ISO, ainda por estimar.

A ISO, por exemplo, tem uma regra para padrões superpostos. Essa regra diz: para aprovar uma proposta de padrão que se sobreponha a outro padrão ISO, deve haver justificativa suficiente . Afinal, quem nunca queimou um aparelho elétrico por ligá-lo em voltagem errada? A proposta OOXML, submetida ao JTC-1 em regime de Fast Track, é um padrão para documentos eletrônicos que se sobrepõe ao padrão ODF, já aprovado pela ISO. Ao propor, via aprovação na ECMA, o OOXML como padrão ISO a Microsoft justificou a sobreposição alegando que o ODF não permite interoperabilidade retroativa com seus aplicativos legados, o que seria coberto pelo OOXML.

Entretanto, na proposta submetida ao JTC-1, funcionalidades necessárias para alcançar inoperabilidade retroativa com esses aplicativos legados não são especificadas. Na proposta, muitas são apenas referenciadas, através apenas de indicação da necessidade de se simular  o comportamento dos respectivos aplicativos legados. Uma das conseqüências dessa omissão, camuflada como especificação pelo encapsulamento XML, é que a implementação dessas funcionalidades foge à "promessa de especificação aberta" da Microsoft, (OSP, Open Specification Promise), de não processar judicialmente, por violação de patentes sob seu controle, implementações que cubram padrões "abertos" por ela adotados.

III

Ambivalência

Assim, a proposta OOXML viola o próprio cerne da definição de padrão ISO, de que um tal padrão serve para permitir o uso "comum e repetido" daquilo que especifica. A Microsoft tenta menosprezar tal violação, quando não consegue evitar o questionamento, afirmando que essas funcionalidades não detalhadas no OOXML são opcionais, e podem ser implementadas em parceria com o fornecedor desses aplicativos legados, que é ela. Como no caso dos conversores OOXML-ODF, que cita como exemplos. Exemplos que, em termos de interoperabilidade, são apenas promessa ou talvez piada.

Há um ditado que diz que o diabo mora nos detalhes. E no caso do OOXML, ele pode estar morando em pelo menos três detalhes. Primeiro, o detalhe das licenças. Se e quando essas parcerias finalizarem tais conversores, serão eles distribuídos sob licença BSD, como anunciado, ou sob alguma licença tipo "shared source, BSD-like", que discrimina contra redistribuição sob licenças com copyleft, como a GPL? Seria um precedente, em se tratando de código desenvolvido sob patrocínio da Microsoft com rótulo de "aberto".

Segundo, o que esses conversores de fato oferecem. Será que oferecerão, ao longo da vida útil dos padrões envolvidos, a interoperabilidade no sentido que interessa aos usuários? Ou no sentido que interessa ao fornecedor, com base no casuísmo de que praticamente tudo no OOXML é opcional? Quando se diz que a tortura em Guantánamo é opcional, entende-se que o chefe do carcereiro, e não o prisioneiro, é quem escolhe; mas quando se diz que funcionalidades descritas no OOXML são opcionais, muitos ignoram, ou preferem ignorar, o detalhe de quem controla essas escolhas, e suas conseqüências. São escolhas que definem, na prática, o que significa interoperar com esse novo padrão.

Essas escolhas serão exercidas por parceiros, ou bloqueadas aos concorrentes, ao sabor das estratégias da Microsoft, que buscam a consolidação do monopólio camufladas de obrigação fiduciária para com os acionistas. E não exercidas por usuários, cada vez mais confrontados com a necessidade de converter documentos entre formatos para manter seus acervos digitais. O que historicamente tem significado vendor lock-in, violando tanto o sentido literal de padrão aberto, pretendido nas políticas de TIC que seguem o modelo do ETRM, quanto a definição de padrão ISO.  

Terceiro, em meio ao alarde sobre um grande volume de downloads de conversores ODF-OOXML, versão beta, há que se ter clara a distinção entre, de um lado, promessas de um fornecedor, que aponta esses conversores como prova de que o OOXML especifica o suficiente, e de outro lado, garantias técnicas de interoperabilidade, continuada e adequada em sentidos que interessam aos usuários. Do contrário algo se queimará, depois, quando conectado.

Dialética da padronização aberta

Pode-se, ainda, argumentar tecnicamente que um produto Microsoft nunca deixa de ser beta, fato que pode estar relacionado à extensa ficha de condenações em matéria anti-concorrencial. Pode-se, também, argumentar que interoperabilidade é um conceito para ela meramente endógeno. E que suas promessas... bem, melhor parar por aqui com os detalhes, e concluir. Para concluir, bastar conectar esses três detalhes e deduzir, logicamente, que das duas uma:

Ou a justificativa apresentada pela Microsoft, aferida por regras da própria ISO, para a sobreposição do OOXML (proposto) ao ODF (já aprovado) não faz sentido, e o ODF pode, sim, representar documentos gerados por seus aplicativos legados (salve os conversores!), ou então a interoperabilidade oferecida por esses conversores se limita àquela dosada por estratégias negociais da empresa, na medida necessária ao seqüestro do sentido de "aberto" para padrão digital ou código fonte (salve o monopólio).

Nessa dialética, os conceitos envolvidos tornam-se alvo e presa de manipulações políticas, camufladas de discussões técnicas. Sob pressão do lobby da empresa, o legislativo de Massachussetts ameaçou amputar o poder normativo do ITD, trocou (por três vezes) seu secretário até que o OOXML fosse incluído na lista dos formatos homologados. Ignorando o próprio critério que define padrão aberto no ETRM, claramente violado pelo OOXML, um mês antes do mesmo OOXML falhar em primeira votação na ISO, ele foi homologado na versão 4.0 do ETRM, sob o pretexto de que a ECMA o havia aprovado como padrão aberto, e de que, no que tange às críticas, padrões evoluem para remediar eventuais problemas.

Tais manipulações, digamos, político-filatélicas não se limitaram ao ETRM de Massachussetts. Na Flórida, em menos de uma hora após apresentar emenda a um projeto de lei propondo algo semelhante ao ETRM, o deputado Ed Horman, um cirurgião ortopédico representando um distrito central daquele estado, recebeu a visita de lobistas da Microsoft, que o pressionaram para retirar a proposta de emenda. Sob ameaça de que, caso contrário, ele teria grandes dificuldades para levantar contribuições de campanha em eleições futuras. Em outros cinco estados dos EUA, propostas semelhantes foram também retiradas ou rejeitadas.

Manipulação ademais psicologicamente projetada, por quem a pratica sobre quem a repele, quando o foco é o processo OOXML na ISO. Tendo manipulado o processo em favor de sua proposta a ponto de envolver-se em tentativa de compra voto (Suécia), com entidades que manipularam, subverteram ou ignoraram deliberações de seus respectivos comitês técnicos (EUA, Espanha, Portugal, Alemanha, Dinamarca, Noruega, Suíça, Hungria, Polônia, Rússia, etc.), com países que se inscreveram de última hora no JTC-1 e votaram a favor, mesmo sem tempo ou interesse de analisar a proposta (Chipre, Venezuela, Paquistão, Líbano, Trinidad & Tobago, Turquia, Uruguai, Malta, Costa do Marfim), a Microsoft acusa de hipocrisia quem tem interesse no ODF e quer ver os critérios da ISO aplicados com seriedade. Hipocrisia ou não, cabe perguntar: Quando outras propostas estiverem em pauta no futuro, como é que o inflacionado JTC-1 da ISO irá obter quorum?

A ética da filatelia digital

Não seria mais racional, do ponto de vista técnico ou consumista, a Microsoft adotar o padrão já adotado pela ISO, o ODF, como formato suportado nativamente em seus produtos? Se o que ela diz sobre conversores ODF-OOXML é verdade, já que sua justificativa para sobrepor o OOXML ao ODF e sua apreciação desses conversores são logicamente excludentes? Ou corrigir as falhas, para que "seu padrão" seja de fato aberto? Tais perguntas parecem irritar os defensores do atual OOXML na ISO, desde que foi publicada pela FSFE (Free Software Foundation Europe). A ambivalência dos motivos e justificativas para se buscar o mais valioso selo de "padrão internacional aberto" -- o da ISO -- para o OOXML, levam esses defensores a se enredar em freqüentes contradições. Alguns partem para ataques ad hominem, enquanto outros, menos exaltados, sofismam: "Se o ODF é tão bom assim, por que seus defensores se preocupam tanto com um padrão concorrente?".

A resposta curta é: justamente por isso. Como na pergunta: "Se a agua do rio é tão boa assim, por que se preocupar com mineração à base de mercúrio?" A resposta longa está no papel dos padrões abertos, que esses defensores decidem ignorar ao tratar o conceito de "aberto" como assunto de marketing. O OOXML é um padrão destinado a manter cativo os clientes de uma base instalada e dominante, como admite um evangelista da Microsoft num de seus seminários, e não para interoperabilidade entre quaisquer fornecedores, como alardeia seu marketing. Um tal padrão corrói o valor de padrões abertos quando se sobrepõe a estes como se fora um deles. Erode não só esse valor, mas também o do processo de padronização em si, ao contaminar o modus faciendi de políticas públicas do tipo manifesto pelo ETRM. Enquanto essa tentativa, de assim emplacar o OOXML a todo custo, expõe o papel crucial de padrões fechados-o-suficiente nas estratégias de vendor lock-in.

Nessa tentativa, a cacofonia num debate que deveria ser racional despista um ataque letal ao cerne do processo de padronização, que é baseado em colaboração, confiança mútua e trabalho voluntário. Este cerne opera como mecanismo social de auto-defesa, para consumidores e fabricantes controlarem ineficiências e efeitos indesejados do poder econômico concentrado pelo efeito rede. Padrões digitais devem convergir, e não concorrer, para que produtos e serviços possam concorrer, de forma sadia e não viciada. Pois devido ao efeito rede, distorções proliferaram em mercados de bens não-rivais, como os de bens simbólicos (hoje baseados nas TIC), quando alavancados por padrões fechados ou legalmente restritos. A convergência de padrões digitais abertos funciona para neutralizar essas distorções, permitindo que novas tecnologias, mercados e valores proliferem sobre essa convergência, como mostra claramente a própria história da Internet.     
 
O problema geral, no fundo, se caracteriza por distintas percepções da fronteira que separa o que é ético, ou legítimo, daquilo que não o é, na conduta de quem alcança controlar mercados sob o efeito rede. E o problema particular, em foco nesse artigo, é o da fronteira entre o que é e o que não é ético ou legítimo na conduta da Microsoft no processo OOXML da ISO, à luz da história de como ela tem usado esse controle para bloquear, esvaziar ou sabotar a convergência verdadeiramente aberta de padrões para documentos eletrônicos. Além dos questionamentos legais, o perigo maior aqui é o deslocamento gradual da percepção coletiva dessa fronteira ética, sob a influência de um fundamentalismo neoliberal que predomina como filosofia no nosso tempo (tema da minha série "sapos piramidais").

O deslocamento gradual da fronteira ética não é novidade: já ocorreu antes, geralmente em meio a crises econômicas, como por exemplo na ascensão do nazi-fascismo. Historicamente, esse deslocamento tem sido pendular, donde a percepção atual de perigo por quem não teme a pecha de conspiracionista ou de fanático. No episódio em tela, começando pelo processo ISO relativo ao ODF, cujos interessados incluem uma empresa que outrora ocupou a posição de monopolista-mor na área das TIC, e que dessa posição contribuiu para o holocausto nazista, não houve -- diferentemente do OOXML --, no entender dos votantes, abuso de processo, já que nenhum deles votou contra a aprovação do ODF, eliminando inclusive a necessidade do BRM (Balot Resolution Meeting).

Conclusão

Ao opinar, numa lista, que a conduta da Microsoft no processo OOXML da ISO foi abusiva, anti-ética e ilegítima, fui acusado de preconceito. Entre os motivos, por desconsiderar a conduta da IBM, que apóia o ODF. Não só nesse processo, mas também no holocausto nazista. Doutra feita, quando a ocupante atual da posição de monopolista-mor em TICs usa essa posição para ações que põem em risco, dentre outros valores, o direito à privacidade dos seus clientes [1, 2], é plausível considerar a possibilidade dela vir a servir como instrumento de controle do Estado-aliado-ao-Capital, definição de Mussolini para o fascismo. Da mesma forma que a ocupante de antanho foi usada naquele ciclo da História. Esse tipo de assalto a processos de padronização, e o achaque a seus colaboradores, pode ser o primeiro passo da transmutação do vendor lock-in em algo mais sinistro.

Ao considerar tal possibilidade, não me vejo usando dois pesos e duas medidas para abusos de quem ocupa posições monopolistas. Não me vejo desprezando abusos da ocupante anterior, ao contrário. Vejo-me tentando aprender com as lições da história. Desviar o debate para promessas, ou especulações sobre futuros produtos, não me parece adequado para iluminar essa fronteira ética. Defender a legitimidade da conduta da Microsoft no processo OOXML na ISO, muitas vezes com foco em nivelar por baixo o debate, me aparece como mais um empurrão nessa fronteira. Mais um passo, caso a máquina marqueteira transmute tal defesa em senso comum, rumo ao próximo ciclo de totalitarismo globalizante (vide PNAC).

Para quem confunde bem simbólico e bem material pode parecer paradoxal, mas, padrões digitais verdadeiramente abertos e livres são uma garantia do direito de escolha entre fornecedores. Conseqüentemente, também uma garantia do direito ao anonimato dos dados e, por extensão, à privacidade de quem os gera ou precisa acessá-los. Em resumo, uma garantia de que esses dados estarão aptos a representar informação sem a obrigatória intervenção de um único fornecedor. Se o fiel acesso a seu acervo de documentos eletrônicos exige software de um único fornecedor, ou de um de seus parceiros, você está preso a modelos de negócio deste fornecedor. E seus dados, à mercê de lógica dos softwares envolvidos. E a sua privacidade também, se esses softwares só rodam direito em sistema operacional do fornecedor. Fornecedor que, como a Microsoft [3, 4], pode buscar garantir o cumprimento de suas licenças restritivas através de espionagem automática.

Padrões digitais abertos e livres permitem que a capacidade dos dados representarem informação se dissocie das estratégias negociais de fornecedores de software. Softwares livres podem concorrer em igualdade de condições funcionais, enquanto seus modelos negociais empoderam  usuários, dando-lhes o direito de auditar os softwares que rodam, adaptá-los para suas necessidades, inclusive as de proteger sua privacidade. Livrando-os da dependência a um fornecedor único, que, uma vez ungido ao monopólio, passa a tratá-los como massa cativa. Disto, consumidores ainda infensos à síndrome de Estocolomo digital estão se dando conta. Bem como juízes, como ilustra nota da FSFE sobre o julgamento de recurso impetrado pela Microsoft na União Européia, contra condenação por abuso de posição monopolista, mantida:

"Through tactics that successfully derailed antitrust processes in other parts of the world, including the United States, Microsoft has
managed to postpone this day for almost a decade. But thanks to the perseverance and excellent work of the European Commission, these tactics have now failed in Europe ... FSFE and the Samba Team welcome the decision of the court. This is a milestone for competition. It puts an end to the notion that deliberate obfuscation of standards and designed lock-in is an acceptable business model and forces Microsoft back into competing on the grounds of software technology."

Todavia, leis antitrust defasadas e esvaziadas têm se mostrado insuficientes, antes estimulando do que coibindo condutas anti-competitivas nos mercados de TIC. Escolhas são importantes, mas há escolhas e escolhas. Nesse momento, a maior empresa de software do planeta busca, por todos os meios a seu alcance, manter sua posição monopolista conquistando mais "espaço vital" para suas estratégias proprietárias de vendor lock-in. Camuflar essas estratégias em escolha do consumidor é cada vez menos convincente. Apostar em auto-correção dos mercados, via inovações tecnológicas, considerando a história das TIC é cada vez mais arriscado. Se a ISO ceder seu espaço, aprovando a atual proposta OOXML no BRM em fevereiro de 2008, ela pode se tornar apenas a primeira das vítimas desse aval de jure ao vendor lock-in.

---

Autor:

Pedro Antônio Dourado de Rezende é matemático, professor de Ciência da Computação na Universidade de Brasília (UnB), Coordenador do Programa de Extensão em Criptografia e Segurança Computacional da UnB, ex-representante da sociedade civil no Comitê Gestor da Infra-estrutura de Chaves Públicas brasileira (ICP-BR), conselheiro do Instituto Brasileiro de Direito e Política de Informática e da Free Software Foundation Latin America. www.pedro.jmrezende.com.br/sd.php

Direitos autorais:
Pedro Antônio Dourado de Rezende publica este artigo sob licença Creative Commons (CC NC-ND-2.0): Livre para republicações com Atribuição, uso Não Comercial e Não Derivável. (outras republicações requerem autorização expressa) Texto da licença em: http://creativecommons.org/licenses/by-nc-nd/2.0/deed.pt