“Something wicked this way comes…”

Apesar do título, não, esse post não tem nada em absoluto a ver com Harry Potter. Mas como diz a música Double Trouble, “algo sinistro está vindo aí”.

No dia 29 desse mês, haverá a decisão final da ISO sobre a aprovação ou não do formato OOXML como padrão ISO. Como já falei anteriormente, existem coisas que estão extremamente complicadas sobre ele. Já disse também que existe uma série de defeitos técnicos no formato, além de uma série de implicações relacionadas à questão do Open Specification Promise (Promessa de Especificações Abertas) da Microsoft e da Covenant Not to Sue (Acordo Contra Processos) da mesma. Inclusive, recentemente o César Taurion da IBM deixa muito claro isso:

IBM developerWorks : Blogs : Software, Open Source, SOA, Innovation, Open Standards, Trends

Mais, não é só. Também é impossivel alguém dizer que existem 100% de certeza quanto a resolução dos vários problemas de propriedade intelectual que foram encontrados nos documentos Open Specification Promise (OSP) e Covenant Not to Sue da Microsoft. Nestes documentos lêem-se: “claims of Microsoft-owned or Microsoft-controlled patents that are necessary to implement only the required portions of the Covered Specification that are described in detail and not merely referenced in such Specification”. E “promises not to assert any Microsoft Necessary Claims against you for making, using, selling, offering for sale, importing or distributing any implementation to the extent it conforms to a Covered Specification…”.
O que isto signfica na prática? Que a promessa não cobre as especificações que “are not described in detail”, que são muitas; que limita a liberdade de uso à sintaxe da especificação, mas não a “application behavior” que estão espalhados nas suas mais de 6.000 páginas; e não inclui patentes das subsidiárias e afiliadas da Microsoft. E um ponto importantíssimo: a OSP é limitada a atual versão do OpenXML! Fica então a pergunta: o que acontecerá com as próximas e inevitáveis versões da especificação?

Como comentamos anteriormente nesse mesmo blog, e o Taurion ressalta no post dele, é impossível determinar claramente se o OSP e o CNS cobrem software livre. Na realidade, ela já foi considerada insegura pela Software Freedom Law Center para implementações livres do OOXML, e por diversos motivos. Ou seja, como algo que pode ser um verdadeiro “campo minado” de Propriedade Intelectual pode tornar-se um padrão ISO?
Podemos entender isso da seguinte forma. que o Avi Alkalay da IBM apresenta: a Microsoft não está tentando promover interoperabilidade (onde o que importa é o padrão e os produtos disputam entre si para ver qual o melhor), mas sim uma intraoperabilidade (onde o produto é importante e favorecem um produto em detrimento aos demais). Pode parecer uma diferença pequena, mas compare as seguintes imagens que o Avi publicou em seu site:

Esse é um exemplo de Interoperabilidade

Esse é um exemplo de intraoperabilidade

A coisa toda, porém, continua ficando cada vez mais estranha conforme você vai acompanhando os posts. Por exemplo, a Microsoft comemora o fato de que 98% das contradições (problemas) do OOXML tinham sido modificados e aprovados. Até que ponto isso é verdade? E se não foi, por que?

IBM developerWorks : Blogs : Software, Open Source, SOA, Innovation, Open Standards, Trends

(…) Embora alguns digam que a reunião foi um sucesso, com 98% dos comentários sendo resolvidos, indiscutivelmente que a realidade é outra. Cerca de 80% dos comentários não foram sequer analisados e da votação que se seguiu, seis países aceitaram as sugestões do Ecma, quatro foram contra e 18 se abstiveram. Ora 22 países de 26 não votaram a favor da proposta!

E porque? Na minha opinião existem muitos senões que impedem um voto SIM, de forma consciente e profissional. O próprio processo de Fast Track não permitiu que fossem feitas avaliações adequadas da especificação. Para termos uma idéia deste problema, das mais de 6.000 páginas originais (devem ser quase 7.000 agora, depois do BRM…), as entidades de padrões tiveram apenas um curto período de cinco meses para avaliar toda esta massa de documentação. Apesar desta limitação de tempo, foram detetadas 3.522 inconsistências e erros. A Ecma respondeu a estes 3.522 comentários com 1.027 propostas, para serem debatidas nos cinco dias do BRM.
Ora, fazendo uma simples conta, com 6.045 páginas divididas por 1.027, temos um erro a cada 5,8 páginas. Claro que, se houvesse mais tempo, muito mais erros seriam encontrados!

Perceba um fato: essas pessoas que analisaram essa documentação, como o Taurion e o Avi da IBM, o Jomar da ODF Alliance, o Gebara da própria Microsoft, o Deivi Kuhn do SERPRO, nenhum deles é desocupado ou “caiu de paraquedas”. Todos são profissionais competentes, experientes, com dedicação total (ou ampla) para esse estudo. O processo Fast-Track tem sido uma constante dor de cabeça para as pessoas tentarem aprovar esse formato. Você continua ainda assim achando que está tudo OK e que a intraoperabilidade é uma boa idéia? Vejamos o que o Taurion fala sobre isso:

IBM developerWorks : Blogs : Software, Open Source, SOA, Innovation, Open Standards, Trends

A própria proposta da especificação, de produzir um padrão compatível com o Office nos leva a uma situação no mínimo preocupante: uma ferramenta (o Office) definindo um padrão e não o contrário. Imagino como seria se a especificação HTML refletisse as caraterísticas internas do Firefox ou do Explorer…Na minha opinião usar um software específico como modelo de referência obriga a que o padrão seja limitado pelas escolhas técnicas originalmente feitas pelos desenvolvedores do software. O que nem sempre é um bom negócio, principalmente quando o software tem mais de vinte anos de desenho, mantendo dentro de si idéias e algoritmos já ultrapassados pelo tempo…

Ou seja, o que podemos fazer ou deixar de fazer, o que devemos implementar ou não fica restrito por escolhas específicas de uma implementação específica cujo cenário era específico. Por exemplo: como seria uma implementação do OOXML em um ambiente Mainframe? Embarcado? Palms? Nintendo DS? Como seria replicar escolhas específicas feitas em um ambiente Windows para algum desses ambientes? Como proceder para portar recursos?
Mas as coisas continuam piorando:
Segundo o Jomar da ODF Alliance, existe uma espécie de “Lei do Silêncio” cercando os resultados do BRM, o que por si só é estranho, pois ao menos em teoria um processo como esse deveria ser aberto para o público interessado se antenar. Não cabe a mim fazer afirmações de que houve má-fé ou não pois não fui parte em momento nenhum desse processo e estou apenas dando opiniões. Mas percebamos o que o Jomar falou recentemente.

Afinal existe ou não SIGILO sobre o BRM ? | void life(void)

Como delegado Brasileiro no BRM do OpenXML, estou me segurando prá não sair por aí contando os detalhes daquela reunião, pois acredito que todos deveriam saber detalhadamente o que aconteceu dentro daquela sala, para poder entender como existem empresas mal intencionadas e sem limite ético nenhum hoje em dia.
Só para citar um exemplo, soube recentemente que foi utilizado em uma apresentação em um NB (ABNT de algum país), um SLIDE que foi inicialmente apresentado na reunião de encerramento do BRM. Apesar de não poder contar os detalhes, como última participação minha no BRM, pedi em nome da delegação brasileira ao responsável pelo ITTF (ISO/IEC) na reunião – Mr Barta – que o texto do slide apresentado fosse corrigido, pois ele distorcia tudo o que havia sido realizado naquela semana. Imediatamente ele determinou ao autor do slide (Mr. Oh, um japonês secretário do SC34) que aquele slide e aqueles números jamais deveriam sair daquela sala, pois eles não representavam o resultado do trabalho do BRM e também não detalhavam o processo utilizado na reunião.
Quando saí da reunião e cheguei no hotel, descobri que um profissional da empresa proponente já havia publicado na web os dados (e logo em seguida retirado… estranho, né). Para quem não sabe do que estou falando, é do absurdo número de 98% dos problemas resolvidos que a Microsoft insiste em utilizar no mundo todo, cometendo um CRIME cada vez que usam ou apresentam este números.

Para entender: perceba que há realmente uma “Lei do Silêncio”, como o Jomar falou anteriormente, mas que uma pessoa quebrou essa norma de sigilo imposta na reunião. Mas isso apenas piora:

Afinal existe ou não SIGILO sobre o BRM ? | void life(void)

O fato concreto é que fui informado por um colega do Chile, que na semana passada este slide (com o nome do Sr. Oh nele) foi utilizado em uma reunião do NB deles. O slide fazia parte de uma apresentação feita pela Microsoft para demonstrar como tudo estava resolvido no OpenXML. Isto é um CRIME DE VIOLAÇÃO DE SIGILO OU NÃO ?

Ou seja, até que ponto valem essas normas de sigilo? Isso tudo está criando um precedente muito sério, que pode inviabilizar totalmente a credibilidade da ISO. É como a Red Hat publicou recentemente:

Red Hat Magazine | ISO approval: A good process gone bad

For a standards body to have credibility, the procedures it follows need to be credible. ISO’s JTC-1 directives say that the “objective in the development of International Standards should be the achievement of consensus between those concerned rather than a decision based on counting votes.” Clearly, there has been no achievement of consensus regarding the adoption of OOXML as a standard, and therefore ISO has turned to a voting process.

We believe that the flaws in the ISO voting process for OOXML are so serious that they must be addressed in order to maintain ISO’s credibility as a standards body. For a standards body to review a proposal adequately and achieve consensus, the participants need to be involved in the entire review process, not merely show up to cast a vote.

Para aqueles não proficientes no idioma inglês, a tradução:

Para um órgão de padronização ter credibilidade, os procedimentos que ele segue devem ser dignos de credibilidade. As diretivas do comitê JTC-1 da ISO definem que “o objetivo do desenvolvimento de Padrões Internacionais deve ser alcançar o consenso entre todos aqueles que estão envolvidos ao invés de meramente basear tudo na contagem de votos”. Mas claramente não houve nenhum consenso quanto à adoção do OOXML como um padrão, e portanto a ISO tornou-o [a padronização do OOXML] em um processo de votação.
Nós [da Red Hat] acreditamos que o processo de votação da ISO para o OOXML foi algo tão sério que deveria ser questionado de modo a manter a credibilidade da ISO como um órgão de padronização. Para que um órgão de padronização veja uma proposta adequadamente, de modo a alcançar consenso, os participantes devem se envolver no processo como um todo, e não apenas ir lá para votar. (grifos meus)

Isso tudo vem sendo mostrado a tempos: vários países receberam incentivos da Microsoft para irem lá e simplesmente votarem a favor do OOXML, sem um estudo prévio da proposta. A própria idéia do Fast-Track foi mal executada. Apesar de executivos da Microsoft terem criticado aqueles que criticam isso, lembrando de casos como os do MPEG, é importante lembrar que o MPEG já vinha passando por estudos a muito tempo, de modo que o Fast-Track foi mais uma formalização de um consenso já adquirido fora da ISO (tanto que recebeu bem menos contradições que o OOXML). Além do mais, existe toda uma questão estatística que impede a pessoa de ler um documento como esse, de 6000 páginas, para um padrão novo, pouco conhecido e debatido e extremamente amarrado a um produto específico, com uma série de exigências voltadas especificamente a esse produto, de ser analisado em tão pouco tempo.
Existe toda uma série de paradoxos sobre quais são os objetivos do OOXML, como exemplo, cito dois e dou recursos para uma leitura detalhada sobre eles:

• Interoperabilidade: existe uma questão relacionada com a falta do mapeamento de binários. Já tratei rapidamente desse assunto no meu blog, mas acho melhor que você vá direto à fonte e entenda melhor essa questão.
• Customização do formato: aqui o assunto se torna mais sério. Em resumo, a Microsoft afirma que o OOXML permite a expansão do formato por meio do conceito de Custom XML, onde em teoria você poderia implementar suas próprias tags. Até aqui sem problemas, exceto que o pessoal do OOXML is defective by Design descobriu que isso simplesmente não funciona, e que pode chegar a criar um pesadelo de segurança de dados, pois “eventually, confidential information from the corporate databases will end up there, and a PR disaster automatically follows“, ou seja, pode-se fazer inadvertivamente que dados importantes de bases corporativas vazem para dentro desses Custom XML, criando falhas de segurança simplemente grotescas. Recomendo a leitura do artigo para um maior esclarecimento sobre os perigos e problemas do Custom XML.

Simplesmente, as coisas foram feitas de uma forma extremamente arbitrárias, “socando goela abaixo” um formato que é enorme, inchado, voltado a um produto específico, sendo que já existe um bom formato para esse mesmo tipo de aplciação, que é o ODF. Alegações de “temos HTML, XML, PDF, etc…” não colam, pois esses formatos possuem outros objetivos (ou alguém acredita que HTML seja a melhor forma de editar-se documentos de texto?)
Existe um risco monstruoso de que o OOXML possa passar, ainda mais com a pressão que a Microsoft vem fazendo no plano político para que os órgãos nacionais de normatização (NBs) votem a favor. Realmente espero que isso não passe, mas o que posso fazer é assistir e esperar.
Vejamos os próximos lances.

Powered by ScribeFire.