OOXML = ISO 29500 – Microsoft Ganha, todos perdemos

Pois é Aconteceu o que temíamos: o OOXML agora é o ISO 29500 (com link apenas para que não achem que isso é um “1° de Abril” atrasado). Com uma série de defeitos técnicos e irregulariedades, e contando com o voto de “importantes países” como Azerbaijão, Costa do Marfim, Casaquistão, e Trinidad e Tobago, a Microsoft conseguiu seu intento e agora OOXML é um “padrão internacional”.
Ou seja: ela ganha, nós perdemos.
Por favor, não me venham dizer aquele positivismo polianista de que tudo está OK e que veremos implementações livres do OOXML logo. Sinceramente, um padrão de 6000 páginas, cheia de problemas técnicos e incertezas jurídicas, sobre os quais eu cansei de falar nesse blog, e que foi comentado por muita, muita gente, apenas fez com que a Microsoft conseguisse uma ferramenta para legitimar seu monopólio e ao mesmo tempo minou completamente a legitimidade da ISO, vítima de suas próprias decisões e da má-fé de Redmond. Mesmo que não houvessem os riscos de “patente submarina” (prefiro o termo “campo minado de Propriedade Intelectual”), a complexidade dos padrões e as questões dos artefatos de implementação complicam e muito o desenvolvimento de uma solução à parte da Microsoft de implementação do OOXML. Essa é a preocupação justamente do pessoal da ODF Alliance:

ODF Alliance Weblog – ODF Alliance Statement on the ISO Vote on OOXML

The process itself brought to the fore OOXML’s deficiencies that will prevent its use by public administrations, chief among them that OOXML remains a “community of one”—undocumented features, IPR restrictions, and features and functionality linked to other Microsoft products that will prevent OOXML’s use in other software products. (…) Nothing about the process will provide governments with any more confidence in OOXML’s openness and interoperability than they had before the vote.

Traduzindo:

O próprio processo [de padronização] trouxe à luz todas as deficiências que irão impedir o uso do OOXML na administração pública, a começar pelo fato de que o OOXML continua sendo uma “comunidade de uma pessoa só” – recursos não documentados, restrições relacionadas a Propriedade Intelectual, e recursos e funcionalidades ligadas a outros produtos Microsoft que o impedirão de ser usado com outros produtos (…) Não houve nada nesse processo que ofereceu aos governos qualquer confiança adicional na abertura e interoperabilidade do OOXML. (Grifos Meus)

Ou seja, qual a confiança que um governo, que possui necessidades críticas em vários sentidos quanto a documentação, possui de adotar o OOXML? Quais as garantias de compatibilidade, interoperabilidade, abertura e transparência do mesmo? Quais são as garantias que, uma vez que um governo crie uma estrutura baseada no OOXML, independente de utilizar produtos Microsoft ou não, ele poderá o fazer sem riscos e sem a possibilidade de processos por patentes ou qualquer outro tipo de infração de propriedade intelectual?
Governos necessitam armazenar documentos por 10, 20, 30, até mesmo 50 anos dependendo o documento, apenas pelo caráter legal. Confiar em um formato onde, a qualquer momento, uma pessoa, não importa qual, pode simplesmente dizer que vai levar a bola para casa e pior, que todo mundo que jogou com ele vai ter que pagar por ter usado a bola, é algo para dizer o mínimo temerário.
Isso é uma coisa que não poderia passar, como não passou e a ODF Alliance comenta:

ODF Alliance Weblog – ODF Alliance Statement on the ISO Vote on OOXML

The vote shined a spotlight on OOXML that will not dim. Only in response to growing public pressure has Microsoft promised to make changes to OOXML, and, to be sure, similar promises have been made on numerous occasions. To avoid any questions concerning the legitimacy of the vote, which included many documented irregularities, Microsoft needs to ensure that these promises made to national standards bodies are actually delivered.

Tradução:

A votação [de padronização da ISO] acendeu um sinal de alerta no OOXML que não irá apagar-se. Foi apenas graças à pressão pública que a Microsoft prometeu fazer mudanças no OOXML, o que, para ser sincero, já aconteceu antes em várias ocasiões. Para evitar questões relacionadas à legitimidade da votação, que inclui muitas irregularidades documentadas, a Microsoft tem que garantir que essas promessas feitas aos órgãos nacionais [de padronização] sejam realmente cumpridas. (Grifos meus)

Agora, será que isso acontecerá? De uma maneira otimista, eu gostaria que sim: gostaria de ver maior interoperabilidade entre os vários produtos. Porém, conhecedor do retrospecto (me sinto tentado a usar o termo karma) da Microsoft, não vejo como ter tais esperanças.
A ISO também sai perdendo nesse processo. Ao deixar que uma série de irregularidades ocorre-se (e perceba que a participação da Microsoft em vários NBs ou de seus Partners não é em si tal coisa), ela comprometeu todos os fundamentos que a tornavam digna de crédito: ao abaixar a cabeça para não ver o que aconteceu em vários países, ela acabou recebendo e aceitando sua parcela de culpa por um processo que, a meu ver, foi feito de maneira completamente errada. E se você acha que isso é blá-blá-blá meu, veja no mapa abaixo o tanto de caveiras que existem no mapa (cada caveira indica um país onde foram constatadas irregulariedades sérias no processo):

Clique para ampliar

Desse modo, o que aconteceu é que a ISO, ao “fechar-se em copas” em relação a essas falhas sérias do OOXML acabou perdendo muita coisa:

R.I.P. International Standards Organization « Adventures in a Perambulator

A failure, on the part of ISO, in so re-evaluating this situation during the next 2 months will result in my calling into question anything considered a standard by ISO. Any government, organization, agency or other that uses ISO as the authority for anything being a standard will be asked to prove that it actually is a standard: ISO authority will not be an acceptable response. It is my opinion that by this action of approving MSOOXML as a standard, ISO has demonstrated that it lacks the qualifications to adequately evaluate technical material and has further shown that its ethical behavior is subject to the highest bidder.

Traduzindo:

Uma falha por parte da ISO em reavaliar essa situação [de considerar padrão qualquer coisa que lhe seja empurrada goela abaixo] nos próximos dois meses me levará a questionar qualquer coisa que a ISO considere padrão. Qualquer governo, organização, órgão ou afim que use a ISO como autoridade para qualquer coisa que seja considerada um padrão deverá se questionar se realmente isso é um padrão: apenas a autoridade da ISO não será mais uma resposta aceitável. Na minha opinião, ao aprovar o MSOOXML como um padrão, a ISO demonstrou ter perdido as qualificações para adequadamente avaliar materiais técnicos e também demostrou que seu comportamento ético é digno de intenso repúdio. (Grifos meus)

Deixando-se penetrar por um processo que, embora tenha seguido (ainda mal-e-mal) a letra da norma, foi corrompido por trás dos panos por uma série de questionamentos, irregulariedades, lobbies e afins, a ISO perdeu (ou ao menos manchou) sua credibilidade. Se tal aprovação viesse de um consenso, seja por Fast-Track ou não, a ISO manteria sua credibilidade. Porém, ao aceitar as pressões de Redmond e não questionar como as coisas ocorreram nos países, aceitando passivamente isso, ela deixou essa credibilidade ser maculada (de maneira permanente, potencialmente) e, desse modo, colocou em xeque TODOS os padrões ISO. Alguns, como ODF, PDF e ISO 9000 escaparam ilesos, uma vez que são reconhecidos não apenas por meio da ISO, mas por suas próprias qualidades. Os demais, porém, passarão a ser questionados cada vez mais.
Eu duvido que em algum momento os questionamentos feitos foram realmente levados a sério. Parece choradeira de mau perdedor, mas se você ler os artigos do meu blog sobre o assunto, você verá que em si não sou contra o OOXML. O que eu sou contra é que, como colocado, o OOXML é uma forma de obter-se um crivo internacional a um monopólio que vem a dar poderes ilimitados apenas a uma empresa.
Não vou continuar repetindo meus entendimentos sobre o OOXML: basta ler aqui no meu blog todos os artigos que escrevi sobre o assunto. Porém, o que vou afirmar é que, a não ser que o processo de padronização do OOXML seja revertido, ninguém mais confiará na ISO e ela irá obter a mesma reputação que a Microsoft (que não é lá muito boa).
Gostaria de citar o desabafo do Jomar, alguém que camelou demais e viu seus esforços por um padrão realmente técnico e correto ser atropelado por um rolo compressor vindo de Redmond:


OpenXML: Eles realmente ganharam ? | void life(void)

Se a decisão é de que problemas são “coisinhas”, ela não foi técnica e portanto ganhamos todos um grande exemplo de onde se chega quando se coloca a boa técnica de lado (ou alguém aí consegue, sem consumir substâncias alucinógenas, acreditar que ter CINCO RECOMENDAÇÕES OFICIAIS PARA SE ESCREVER UMA SIMPLES DATA é algo lógico e natural !!! E que isso ainda irá contribuir para o aumento da interoperabilidade ?). Prá falar a verdade, como fã de Rock’n Roll eu até que vi um bom “revival” da lisergia dos anos 70 nisso tudo (pois só com muito LSD na cabeça eu talvez conseguisse explicar e defender publicamente a tese de que uma só norma internacional é na verdade cinco que na verdade possue duas cláusulas de conformidade que a torna dez sendo ao mesmo tempo uma… fiquei até tonto só de pensar nisso para poder escrever…e olha que eu não tomei nada, heim…).

Ou seja, na realidade, a ISO e todo o processo do Fast-track foi apenas uma forma da Microsoft conseguir um Selinho de ISO para o Office 2007. Sabe, como os selinhos ISO-9000 que qualquer empresa deseja para mostrar que seu produto é o máximo, ainda que ele seja uma porcaria… ainda que seja a mesma porcaria o tempo todo? Como um padrão com redundâncias, discrepâncias, contradições e afins passou pela ISO, que deveria zelar pela qualidade técnica?
E para realmente terminar esse post, deixo as mesmas perguntas do Jomar à Microsoft:

OpenXML: Eles realmente ganharam ? | void life(void)

  1. Quando o Microsoft Office vai suportar a IS 29500 (ele agora suporta apenas o ECMA-376, que é uma especificação diferente) ? E quais delas serão suportadas (IS 29500-1, IS 29500-2, IS 29500-3, IS 29500-4, IS 29500-5) com quais classes de conformidade (viu como agora vai ser bem fácil comprar uma suite de escritório que suporte o OpenXML…) ?
  2. Quando sai o próximo Service Pack do OpenXML ?
  3. Vocês já prepararam algum mecanismo de Auto-Update na ISO ? Vai ser via plug-in ou via backdoor mesmo ?

Por isso, apesar de tudo isso, continuo apoiando o ISO 26300 (ODF) como o verdadeiro formato de documentos padrão.

Office OpenXML (OOXML) e inapto pela ISO 29500

Powered by ScribeFire.

Anúncios

A sujeira continua a aparecer no OOXML

A verdade está aparecendo cada vez mais no OOXML, e de como o processo está se tornando não apenas estranho, mas totalmente fora de ordem. Hoje, o Jomar postou algumas informações sobre o que diabos aconteceu realmente no BRM: na realidade, a famosa “Lei do Silêncio” não foi ‘esclarecida’ (perceba a ironia aqui). A questão não é de que havia algum tipo de “Lei de Silêncio”, mas sim de que os participantes deveriam (não seriam obrigados) a permanencer em silêncio quanto a esses eventos… É engraçado que isso tenha sido colocado agora, quando todos ficaram calados, enquanto outras partes interessadas utilizaram-se desses valores para tentar “passar a perna” no debate. Isso mostra como essas coisas são úteis para aqueles que querem trapacear processos ISO.
Como sempre, o Jomar manda muito bem ao esclarecer as coisas: ele se preservou enquanto não tinha a certeza de poder ou não comentar o processo, o que mostra que ele é um cara ético. Agora, porém, ele resolveu “rasgar o verbo”:

Finalmente: os detalhes sobre o resultado do BRM | void life(void)

Como informado no meu penúltimo post, entrei en contato com a ISO e o IEC (na verdade com o Gabriel Barta do ITTF), e ele me esclareceu que apenas “recomendou” que os detalhes não fossem revelados e que não pode fazer nada contra isso (nem contra a Microsoft, nem contra este pobre delegado). Além disso me disse que eu posso falar o que quiser, mas mantém a recomendação… Tá bom…obrigado pelo conselho…

E vamos ver o que o Jomar tem a dizer:

Finalmente: os detalhes sobre o resultado do BRM | void life(void)

Para iniciar a história, na reunião de véspera do BRM, os Chefes de Delegação (HoD) foram avisados que na quarta feira teriamos todos que tomar uma decisão sobre o que fazer com as propostas do ECMA que não pudessem ser discutidas.

Vamos entender o que aconteceu: o BRM, que em teoria deveria resolver todos os problemas do padrão em estudo, ao invés de debater todos os problemas do padrão simplesmente fez uma postura de João-Sem-Braço, ignorando a função básica do BRM de alcançar um consenso normativo (como dito anteriormente) ignoraram sumariamente uma massa completa de inconsistências e erros, conforme citado pelo Cezar Taurion da IBM. Desse modo, além de perder-se fundamentalmente o objetivo principal do BRM, fez-se uma espécie de “padronização a toque de caixa” que demonstra que não houve por parte dos principais interessados nesse caso (ECMA e Microsoft) de u debate completo e técnico quanto ao formato.
Continuando, o Jomar explica como é feito o debate das contradições durante o BRM, e mostra uma coisa MUITO interessante:

Finalmente: os detalhes sobre o resultado do BRM | void life(void)

O forma de trabalhar adotada nos dois primeiros dias de reunião (e no papel funciona que é uma beleza), cada um dos países presentes (na verdade os chamados National Bodies ou NBs e se não me engano eram 33) poderiam apresentar para a discussão uma das propostas de seu interesse (ou seja, em ordem alfabética cada um apresentava um problema). O debate então se iniciava e caso fosse muito polêmico, os NBs envolvidos com a discussão eram convidados a discutir “off-line”, colocando o assunto para um backlog. Toda discussão terminava em instruções de alteração para o editor e qualquer coisa que não contivesse “instruções de alteração para o editor” era simplesmente ignorada.
O resultado disso é que até sexta feira, sequer duas rodadas completas foram realizadas (ou seja, houve NB que pode apresentar só uma vez) … explicação: Falta de Tempo (que aliás, explica todas as demais decisões tomadas lá, ok ?). (grifos meus)

Alguns detalhes a ressaltar:

  1. Perceba que cada NB podia apresentar por rodada um único problema. O dilema é: alguns NBs, como o brasileiro, tinham listas enormes de problemas a serem questionados. Mesmo considerando-se a possibilidade de um mesmo problema ser apresentado por vários NBs, como é que todos poderiam ser investigados dessa forma.
  2. O Jomar diz que “qualquer coisa que não contivesse “instruções de alteração para o editor” era simplesmente ignorada“. Ou seja, uma série de fatores que importantes, como a questão do mapeamento de binários entre outros foi simplesmente chutados para escanteio sumariamente. Desse modo, como pode-se alcançar um melhor esclarecimento sobre essas questões? Principalmente em um padrão lotado de artefatos de implementação (wrapLikeWord95 e afins)?

Mas ainda assim as coisas continuam piorando:
Finalmente: os detalhes sobre o resultado do BRM | void life(void)

Durante os debates, algumas discussões acabavam se expandindo e abrangendo mais do que uma resposta (ou as vezes as respostas tratavam de temas coligados) e isso explica o elevado grau de itens discutidos (ou como prefiro chamar “tocados”) no BRM (retirado deste documento, o documento final do BRM): 189 respostas ou 18,4 % do total (isso é que é o que se espera de um debate internacional sobre uma norma de tamanha relevância, não é mesmo… Já imaginou se nossa constituição fosse escrita assim, com apenas 18% das leis discutidas e analisadas ?).

Alguém vai falar: “18,4% não é bom?” Não, não é? Isso é um padrão internacional: em um mundo globalizado, a troca de informações (e portanto de documentos) por meios digitais assumirá cada vez mais uma importante função nas empresas de todos os portes e nos governos, e até mesmo nas relações pessoais. Um formato mal-padronizado, com “minas terrestres de patentes”, cheio de furos técnicos, redundante, e simplesmente complexo demais deveria ser aprovado com tão pouco debate em cima do mesmo? Como o Jomar disse: “Isto significa que especialistas do mundo todo foram a Genebra para resolver apenas 18,4 % de um tremendo problema. O resto (81,6%) foi “dado um jeitinho”.
Mas vocês acham que acabou? Não, ainda tem mais!

Finalmente: os detalhes sobre o resultado do BRM | void life(void)

Aliás, me reservo o direito de não comentar aqui o que levou a aprovação desta proposta [da transformação da especificação em uma Multi-Part standard, na qual o Brazil apresentou uma objeção], que na verdade transforma o OpenXML (ou a DIS 29500) em singelas cinco normas internacionais que poderão ter vida própria (única diferença de cinco normas “tradicionais” é a sua numeração compartilhada, DIS 29500-1, DIS 29500-2 … DIS 29500-5). Lindo isso, não ?

Ou seja, existiram coisas tão atrapalhadas (ou intencionalmente manipuladas), que o Jomar se absteve de comentar. Em uma situação como essa, o que leva a pessoa a se abster, senão um processo terrivelmente mal-feito (ou intencionalmente manipulado).
Agora, vem uma parte importante desse post do Jomar e uma resposta para muitas coisas: de onde a Microsoft tirou a questão dos 98% de aprovação dos comentários ao OOXML?!
Finalmente: os detalhes sobre o resultado do BRM | void life(void)

Quando chegou a quarta feira, nos foram apresentadas quatro opções de “destino” às demais respostas (ou seja, 81,6% do total). Eram apenas quatro opções e uma delas deveria ser escolhida (na hora eu me lembrei do filme “A escolha de Sofia”):
1 – Todas rejeitadas.
2 – Todas aprovadas.
3 – O ITTF decide tudo.
4 – Decisão por voto em lote (com a possibilidade de declaração de voto individual para cada resposta e/ou definição de um voto global, do tipo “aceito tudo”).
Evidentemente que a opção menos ridícula era a opção 4 e por isso ela foi aprovada (no documento final existe uma cópia da cédula de votação). Muito foi debatido sobre a possibilidade de que alguns NBs fizessem votos de bloqueio (como votar tudo sim para forçar a aprovação ou tudo não para desaprovar), mas nada poderia ser feito a este respeito…
Houve um protesto muito interessante de uma delegação que disse que não tinha ido até a Suiça para votar, que poderia fazer isso de casa e a resposta: “Paciência… a vida é assim” .
Outro NB protestou dizendo que só recebeu o documento contendo as respostas para seus próprios questionamentos e não tinha tido a oportunidade sequer de analisar as demais respostas. Por isso foi criada a opção “Não quero registrar uma posição” na cédula. O problema apontado ocorreu com outros NBs e portanto, teve NB que votou em propostas que nunca leu !!! (legal isso, né ?).
(…)
Fiz questão de contar isso apenas para que seja pública a explicação aos 98% de aprovação que certas empresas andam utilizando mundialmente.
Viu como agora os 98% não significam absolutamente nada ? E os 18,4%… estes sim merecem ser debatidos (e explicados por alguém).

Repare aqui a questão: houve uma verdadeira “aprovação em massa” de uma série de questões importantíssimas e que foram simplesmente ignoradas pela ISO. Desse modo, como confiar no OOXML? Como desenvolver para isso? Qual a segurança que temos de que os documentos irão abrir corretamente, mesmo no Microsoft Office 2007? Quais são as garantias que o esforço potencial para desenvolver-se sistemas que abram e manipulem tais formatos não será jogado fora ao perceber-se que os documentos resultantes não abrem ou oferecem informações errôneas em outros sistemas compatíveis com esse formato? Pequenas discrepâncias são aceitas (grave um documento no OOo e abra no Lotus Symphony da IBM e você poderá ter isso), mas quais são as garantias?
A postura brasileira de Dizer NÃO ao OOXML está correta por tudo isso: esse formato é simplesmente horrível e não tem condições de fazer NADA ao que se propõe a fazer. Aprovar o OOXML agora é transformar a ISO em um órgão de “ceder selinhos” para empresas, o que desvritualizaria tudo o que a ISO representa. A ISO não é perfeita (X.25 alguém), mas muitos padrões que ela divulgou foram adotados a partir de um consenso e tornaram-se importantes no mercado (os próprios padrões ISO 9000 são exemplos).
Se o OOXML passar agora, vai ser a submissão da ISO à Microsoft e resultará em um lock-in oficializado, uma vez que até agora, à exceção dos produtos Microsoft, não existe nada que abra os documentos OOXML do MS Office 2007 corretamente. Sendo que atualmente ainda é impossível desassociar o OOXML do MS Office (o que acontece com o ODF em relação ao seu “software de referência”, o OpenOffice.org), temos uma situação como nunca foi vista na ISO: uma única empresa poder oficializar um gigantesco monopólio por meio de um padrão “consolidado de um consenso”.
Quem tem a ganhar nesse caso? O Brasil ou a Microsoft? Sua empresa ou a Microsoft? Você ou a Microsoft?
Pense muito nisso…

Office OpenXML (OOXML) e inapto pela ISO 29500


Powered by ScribeFire.

O que a Microsoft e sites pornô têm em comum?

Pode parecer uma pergunta absurda, mas existe uma relação sim, denunciada pelo pessoal do site open… e pelo pessoal do NoOOXML.com: a prática de Cybersquatting, ou seja, a idéia de, segundo a Wikipedia, “registrar, traficar ou usar um nome de domínio com a má intenção de obter lucros com a boa fê de uma marca pertencente a outros“. Em geral, essa prática é normalmente feita por sites pornôs que (a) tentam obter acessos quando a pessoa digita o nome de um site conhecido de maneira errada ou (b) tentam vender posteriormente os domínios aos verdadeiros detentores da marca registrada em questão por rios de dinheiro. Além disso, há também a prática de scam de redirecionamento, quando você digita uma URL e é redirecionada para outra por meio de scripts. Embora não seja sempre um site pornô e seja uma prática que pode ser legítima (com em sites que mudaram de domínio), ela pode ser usada para levar o usuário a locais indesejados.
Agora, você pode se perguntar: “o que a Microsoft tem a ver com tudo isso?
Ontem, dia 26/03, foi comemorado o Document Freedom Day (Dia da Liberdade de Documentos), ou seja, o dia de defender a liberdade de formatos de documentos e independência de ferramenta ao editar documentos. Para divulgar a iniciativa e criar meios para registrar-se grupos que se organizariam para tomar ações, foi registrado o site http://www.documentfreedom.org.
OK: um grupo conhecido como OpenXML Community (sem links para eles pela sacanagem que fizeram), que se apresenta como “uma comunidade de instituições públicas, empresas, profissionais de tecnologia, acadêmicos e desenvolvedores que suportam o ECMA Office Open XML e (…) acreditam na promoção da escolha, interoperabilidade, inovação e excelência técnica nos padrões de documentos” (conforme o próprio site deles), registrou o domínio http://www.documentfreedomday.COM (perceba o top-level domain comercial, oposto ao .org da iniciativa do Document Freedom Day). Ao tentar acessar essa página, a pessoa era redirecionada a um documento chamado “Dispelling Common Myths About Open XML” (o qual ainda pretendo desmitificar…).
Agora, o que há de errado? É um domínio livre, qualquer um pode pagar para o registrar!“, você pode dizer.
O problema é que justamente quando existe toda uma iniciativa para que o OOXML não seja aprovado (e não por ser da Microsoft, mas sim por ser um formato simplesmente horrível, como eu e vários outros estamos falando a bastante tempo) aparece um grupo realmente astroturf (ou seja, embora aparentando ser algo realmente espontâneo ser algo criado por grupos com os mais diversos interesses) vem tentando minar essa iniciativa por meio de uma técnica que pode ser considerada na melhor das hipóteses um jogo baixo.
Isso reflete muitas questões e mostra os verdadeiros objetivos do OOXML. Como disse anteriormente, toda a questão da ISO é baseada em consensos. Em um processo normal, todas as contradições seriam resolvidas, de modo que o consenso fosse atingido e a votação passasse a ser apenas uma formalização desse consenso formado entre todas as partes. Esse consenso não precisa derivar de um formato perfeito, pois mesmo o ODF não o é, e espaço para evoluções são sempre interessantes.
O problema é que cada vez mais fica claro que a Microsoft não tem como objetivo nenhum consenso ou portabilidade. As “minas terrestres de patentes“, as várias contradições não explicadas, e a confusão entre inter e intraoperabilidade, o fato de um produto não estar sendo usado apenas de formato referência, mas como fundamento para manutenção de falhas graves no formato, devido a escolhas específicas de implementação de recursos (o que é conhecido tecnicamente como artefatos de implementação), e os diversos problemas de “inflação dos NBs” e de obstruções e atritos com aqueles que vão contra o formato OOXML mostra que na realidade a iniciativa de transformar o OOXML em um padrão ISO é apenas uma jogada de marketing da Microsoft:

  • Ela passa a posar de boazinha, mas na realidade pode minar completamente qualquer iniciativa livre de desenvolvimento de parsers e conversores do OOXML para outros;
  • Mesmo que seja possível tais sistemas, eles não teriam o mesmo comportamento que o dos produtos da Microsoft, criando a “dependência de DLLs”, o que em resumo quer dizer que qualquer sistema bom deveria recorrer a DLLs ou bibliotecas da mesma;
  • Cria uma verdadeira aberração jurídica, um lock-in oficializado por meio de um “padrão”;

Como já disse em outros posts e pretendo escrever no futuro com mais tempo: eu não sou contra o OOXML. Ser pró-ODF não é o mesmo que ser contra-OOXML, como foi dito pelo Mark Shuttleworth do Ubuntu (e eu traduzi aqui nesse blog). O grande problema é: o OOXML tem muitas, muitas, MUITAS, MUITAS FALHAS! Existe muita coisa, para dizer o mínimo, estranha no OOXML que simplesmente passou no BRM, devido ao curto tempo e ao tamanho monstruoso da documentação. Artefatos de implementação e coisas bizarras como wrapLikeWord95 (que diz que você deve quebrar linhas como Word 95… sem dizer como isso é feito) e documentos que, uma vez validados contra as DFDs do OOXML ainda assim dão erro (ou seja, existe uma inconsistência entre o formato descrito nas especificações e o descrito pelas DFDs).
Enquanto as coisas estiverem nesse pé, e enquanto a ECMA e a Microsoft não ouvirem as contradições todas e realmente as acertar, concordo com o NÃO dado pelo Brasil, e torço para que outros países sigam a mesma iniciativa. Mas como disse o Jomar, “a guerra continua (e o outro lado está levando a sério a expressão VALE TUDO)“.
Espero que você que esteja lendo entende as coisas e tenha realmente entendido os fatos (sim, a “piada” com Get the facts foi intencional).

Office OpenXML (OOXML) e inapto pela ISO 29500

Powered by ScribeFire.

“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.

Office OpenXML (OOXML) e inapto pela ISO 29500

Powered by ScribeFire.

As coisas se complicam para o OOXML

Bem, desculpem o hiato: as minhas novas atividades de serviço exigiram um tempo meu especial, onde precisei me focar mais nele e abandonei um pouco o blog.
Nesse meio tempo, ocorreu o Ballot Resolution Meeting (BRM) para a aprovação ou não do Office Open XML. Basicamente, esse é o momento onde todas as contradições (ou comentários) aplicados ao mesmo quando ele não foi aprovado, em uma tentativa de resolver os problemas e com isso aprovar o formato.
Antes que se pense que isso é mais um empurrão da nossa “amiga de Redmond”, na realidade isso é parte do processo de Fast track da ISO, portanto não há nada de errado nesse processo. Muito pelo contrário, ele é completamente válido na medida em que é parte de um processo já validado dentro de uma organização como a ISO.
Os problemas vão surgindo, porém, quando você entende o que está acontecendo por trás dos panos.
Como já comentei anteriormente nesse mesmo blog, existem uma série de problemas sobre como o formato está sendo publicado na ISO. Esse é inclusive o motivador do Ballot Resolution Meeting (BRM): estudar e chegar a um consenso sobre como serão corrigidos os problemas no mesmo. Mas como chegar a um consenso sendo que o formato possui mais de 6000 páginas de documentação técnica com coisas específicas para emular a formatação do Word 95 (?!) ou do Wordperfect (?!)?
Mas isso ainda não é o pior do que está acontecendo sobe o Ballot Resolution Meeting (BRM). Existem coisas ainda piores ocorrendo.
O Jomar, do Homembit e da ODF Alliance Brasil, é um dos representantes da ABNT no comitê JTC1 da ISO, responsável pelo OOXML (DIS 29000), sendo que os outros foram o Deivi Kuhn do SERPRO e o Fernando Gebara, da Microsoft, dois profissionais respeitados na área. Ele é uma fonte de referência para saber o que se passa nesse processo. Além dele, recomendo a leitura do blog do César Taurion, da IBM, também bastante respeitado, que vêm falando bastante do ODF e do OOXML. Eles foram para Genebra participar do BRM como representantes brasileiros. E as coisas começaram a aparecer, apesar da “lei de silêncio” envolvendo o BRM:
Comecemos pelo post do Jomar onde ele esclarece uma proposta do Brasil para facilitar a aceitação do OOXML, principalmente quanto à questão das famosas questões de retrocompatibilidade (lineWrapLikeWord6), que era a possibilidade de um mapeamento de formatos binários (como o .doc) para o OOXML (.docx).
Bem, vamos deixar que ele fale:

Afinal: O que fomos fazer em Genebra ? | void life(void)

Não posso contar os detalhes da reunião, mas posso contar uma conversa que tivemos (eu e mais um delegado brasileiro) com uma pessoa no início da pausa para o almoço de sexta feira. Vou divulgar esta conversa pois nosso interlocutor se identificou como sendo membro do ECMA, membro de uma delegação nacional presente no BRM mas não disse que estava falando em nome de ninguém (como é o protocolo lá), e por isso entendo que esta foi uma conversa que não está coberta pela escandalosa “Lei do Silêncio” imposta a todos nós.
Esta pessoa nos procurou dizendo que considera que não deveríamos apresentar nossa proposta que pedia o mapeamento, pois não havia tempo hábil na reunião (pouco mais de três horas) para escrevermos o documento. Nós dissemos que nossa proposta partia da premissa de que o ECMA já tinha este documento, pois, se justifica a necessidade do OOXML por causa do suporte ao binário e se afirma ainda que existem coisas que não podem ser traduzidas (deprecated), eles devem ter estudado aprofundadamente esta situação e no mínimo ter feito o mapeamento.
Eu nunca vi uma pessoa tão nervosa e envergonhada na minha vida… Ele disse que a Microsoft deve ter este mapeamento e se nós quisermos, podemos pedir à Microsoft mas não pedir ao ECMA. Disse que o ECMA só foi responsável por criar o novo schema XML e que não têm esta documentação.
Como nossa conversa não ia a lugar nenhum, eu lhe expliquei que o que iriamos propor era o resultado do trabalho de um comitê no Brasil e que infelizmente se ele não pudesse voltar ao tempo e vir ao Brasil contar esta história toda, que teríamos que insistir com nossa proposta.
Fiz questão de contar isso aqui, pois não deixaram o Brasil apresentar a proposta…

OK… Pode parecer correto o que a pessoa disse. Mas vejamos o que diz outro profissional envolvido, o Avi Alkalay, da IBM:

OOXML: Está rolando um barraco na ISO :: Avi Alkalay

Só pra lembrar qual é o propósito do OOXML, extraido (em livre tradução) de sua especificação:

O objetivo deste padrão [OOXML] é […] representar fielmente o corpo de documentos existentes […]

Os tais “documentos existentes” são no caso todos os documentos em formato binário legado do MS Office (.doc, ,ppt, .xls), algo fora do escopo do OOXML.
Se esse mapeamento não fizer parte da especificação OOXML, seu objetivo primordial é inválido. A especificação é inválida. E a delegação brasileira queria levantar essa bola: cadê o mapeamento ?

Sem um mapeamento, é praticamente impossível obter a total fidelidade no corpo de documentos existentes e transpor isso ao OOXML, mesmo recorrendo-se a engenharia reversa. Qualquer um que tenha aberto um arquivo .DOC no BrOffice.org ou exportado um documento do BrOffice.org para .DOC sabe disso. Sem esse mapeamento, o resultado prático é que características estranhas dos documentos, principalmente .DOC, não poderão ser representados adequadamente em um OOXML. E é justamente isso que questiona Rob Weir, que é parte da representação americana no OOXML:

An Antic Disposition: The Carolino Effect

The scope of OOXML, as amended by the BRM is stated as:

This International Standard defines a set of XML vocabularies for representing word-processing documents, spreadsheets and presentations. The goal of this standard is, on the one hand, to represent faithfully the existing corpus of word-processing documents, spreadsheets and presentations that have been produced by Microsoft Office applications (from Microsoft Office 97 to Microsoft Office 2008 inclusive). It also specifies requirements for Office Open XML consumers and producers , and on the other hand, to facilitate extensibility and interoperability by enabling implementations by multiple vendors and on multiple platforms.

Faithful representation of Microsoft Office 97-2008. I’ve learned it is rarely polite to ask a man what he means by “faithful”, but let me make an exception here. We have now the binary Office format specifications, not part of the standard, but posted by Microsoft. And we have OOXML specification. In what way does the OOXML “represent faithfully” the “existing corpus” of legacy documents?
Does OOXML tell you how to translate a binary document into OOXML? No. Does it tell you how to map the features of legacy documents in OOXML? No. Does it give an implementor any guidance whatsoever on how to “represent faithfully” legacy documents? No. So it is both odd and unsatisfactory that primary goal of the OOXML standard is so tenuously supported by its text.
Now, certainly, someone using the binary formats specifications, and using the OOXML specification, could string them together and attempt a translation, but the results will not be consistent or satisfactory. (…). Knowing the two endpoints is not the same as knowing how to correctly map between them. A faithful mapping requires knowledge not only of the two vocabularies, but also the interactions.

Uma tradução livre desse trecho é a seguinte:

O Escopo do OOXML, como foi corrigido no BRM é definido como:


Esse padrão internacional define um conjunto de vocabulários XML para a representação de documentos de processamento de texto, planilhas e apresentações eletrônicas. O objetivo desse padrão é, por um lado, representar fielmente a formatação existente de
documentos de processamento de texto, planilhas e apresentações eletrônicas produzidas por aplicações do Microsoft Office (do Microsoft Office 97 ao Microsoft Office 2008, inclusive). Também especifica requisitos para consumidores e produtores de documentos Office Open XML e, por outro lado, facilita a extensibilidade e a interoperabilidade ao permitir implementações por vários desenvolvedores e em várias plataformas.


Representação fiel de documentos do Microsoft Office 97 ao 2008. Aprendi que raramente é polido perguntar a alguém o que ele quer dizer com “fiel”, mas aqui há uma exceção. Nós temos agora as especificações do formato dos arquivos binários do Office, não incluídos como parte do padrão, mas sim fornecidos pela Microsoft; e temos a especificação do OOXML. Como é que o OOXML “
representar fielmente a formatação existente” dos documentos legados?
O OOXML nos diz como traduzir um documento binário em OOXML? Não. Diz como mapear as
features dos documentos legados para OOXML? Não. Oferece um caminho para o desenvolvedor “representar fielmente”, seja lá o que queira isso dizer, os documentos legados? Não. Portanto é ao mesmo estranho e insatisfatório que o objetivo principal do OOXML seja tão tenazmente definido por esse texto.
Na verdade, alguém que queira tentar uma tradução usando as especificações dos formatos binários e do OOXML poderia amarrá-los e tentar seguir em frente, mas os resultados não serão consistentes ou satisfatórios. (…) Saber os pontos de chegada e partida não significa saber o caminho entre eles. Um mapeamento fiel exige não apenas o conhecimento das duas especificações, mas também das interações entre elas. (Grifo meu)

Perceba aqui o problema: não é possível saber como “representar fielmente” os documentos em questão. O máximo que um desenvolvedor pode fazer é “ir no chute”, mas “os resultados não serão consistentes ou satisfatórios“. Como disse, basta tentar abrir um arquivo do Word em qualquer outro editor e ver que isso é uma verdade. O resultado nunca é o mesmo. Mesmo quando o formato é conhecido, existem leves diferenças na implementação (quem nunca desconfigurou a formatação de um documento ao abrir ele na versão mais atual de um editor?). Problemas entre formatos é obviamente uma realidade.
E isso é apenas a ponta do Iceberg.
No dia que eu escrevo isso, o Avi Alkalay publicou em seu blog um post falando sobre uma das “features” que serão exigidas no OOXML. No caso, cito a fonte do mesmo, novamente o Rob Weir:

An Antic Disposition: A Leap Back

(…) in 1582 Pope Gregory XIII promulgated a new way of calculating leap years, saying that years divisible by 100 would be leap years only if they were also evenly divisible by 400. So, the year 1600 and 2000 were leap years, but 1700, 1800 and 1900 were not leap years. This Gregorian calendar was initial adopted by Catholic nations like Spain, Italy, France, etc. Protestant nations pretty much had adopted it by 1752, and Orthodox countries later, Russia after their 1918 revolution and Greece in 1923.

traduzindo (desculpem, o post vai se tornar longo, mas tenho a prática de citar a fonte “as is” e as traduzir a posteriori quando isso pode ser relevante):

(…) em 1582 o Papa Gregório XIII promulgou uma nova forma de calcular-se anos bissextos, determinando que os anos divisíveis por 100 só seriam bissextos se fossem divisíveis também por 400. Portanto, 1600 e 2000 foram anos bissextos, mas 1700, 1800 e 1900 não. Esse calendário gregoriano foi inicialmente adotado em nações católicas como a Espanha, Itália, França, etc… As nações protestantes o adotaram em 1752, e as nações ortodoxas mais tarde: a Rússia após a revolução de 1918 e a Grécia em 1923.

OK… Um pouco de história? Qual é o problema?
O problema é a seguinte imagem:

O que foi feito aqui?
Quando se formata uma casa do Excel como data, ela conta a partir de 01/01/1900. Ou seja, se quero representar o dia de hoje, eu somo o número de dias que passou entre 01/01/1900 e hoje (um princípio básico da computação que é adotado em diversos formatos, com leves diferenças entre unidades e “ponto zero” adotados). Isso facilita a computação para fórmulas, principalmente envolvendo datas. Pensando assim, e lembrando o que foi dito anteriormento, o Avi definiu que o valor da data como a primeira data do escopo (01/01/1900) + os trinta dias seguintes (ou seja, levaria até 31/01/1900) e somou mais 29 dias em seguida. O resultado seria 29 dias após o dia 31/01/1900. Como não é bissexto (como o Rob explicou anteriormente), o resultado adequado seria 01/03/1900. A imagem comprova que o resultado foi 29/02/1900 (também conhecido como dia de São Nunca).
Agora, você pergunta: “Qual é o problema?”
Lembra a questão de “‘representar fielmente a formatação existente‘ dos documentos legados”? Bem, isso quer dizer representar inclusive os bugs!!! Pode-se alegar que é um bug inconveniente, mas não é, e mesmo que fosse isso não é desculpa. E a questão é a seguinte: se um erro bobo como esse passa (lembrando que esses documentos legados podem estar por aí em 2100, que também não é um ano bissexto), imagina detalhes mais complexos?
E as coisas não acabaram:
As pessoas que estão acompanhando esse processo do OOXML sabem que a Microsoft prometeu liberar totalmente de royalties o OOXML, atraves do que ela chama de “Microsoft Open Specification Promise” (OSP). Basicamente, ela afirma por meio disso que está não irá processar ninguém por usar ou desenvolver em cima dessas patentes. Porém, o pessoal do Software Freedom Law Center, que estuda licenças de software para analisar sua compatibilidade com o Software Livre, procurou analisar a OSP e verificar sua compatibilidade com as licenças livres, como a GPL, a Artistic (do Apache) ou a CDDL (Sun/OpenOffice.org). O resultado é:

Microsoft’s Open Specification Promise: No Assurance for GPL – Software Freedom Law Center

(…), we publicly conclude that the OSP provides no assurance to GPL developers and that it is unsafe to rely upon the OSP for any free software implementation, whether under the GPL or another free software license.

traduzindo:

(…), concluímos publicamente que a OSP não oferece nenhuma segurança para desenvolvedores que usem a GPL e que não é seguro se basear na OSP para qualquer implementação livre [do OOXML], seja segundo a GPL ou segundo qualquer outra licença de software livre. (grifos meus)

Você pode se perguntar: “o que mais esses open-xiitas querem? Não basta as especificações da ECMA?
Não basta! Tanto não basta que a própria ISO não aceita padrões que possuam patentes, a não ser que essas patentes estejam para acesso a qualquer um sem cobrança de royalties. A pergunta então pode ser: “qual é o problema?” Bem, vamos aos fatos:


Microsoft’s Open Specification Promise: No Assurance for GPL – Software Freedom Law Center

Microsoft makes its promise “irrevocably,” but upon careful reading of the entire OSP, this promise is weakened considerably in the definition of Covered Specifications. In that provision, Microsoft clarifies that:

New versions of previously covered specifications will be separately considered for addition to the list.

Because of this narrow definition of the covered specifications, no future versions of any of the specifications are guaranteed to be covered under the OSP. Each new version is subject to Microsoft’s ongoing discretion on a case by case basis. In other words, every time a specification changes, Microsoft can effectively revoke the OSP as it had applied to previous versions of that same specification. Microsoft states that it will commit to renewal of the promise for future versions of specifications subject to standardizing activity “to the extent that Microsoft is participating in those efforts,” which means that Microsoft reserves the right to cancel the promise with respect even to standardized specifications, by merely withdrawing from the relevant standard-setting workgroup or activity. While technically an irrevocable promise, in practice the OSP is good only for today.

tradução:

A Microsoft torna sua promessa “irrevogável”, mas se lemos a OSP completamente, percebemos que essa promessa é enfraquecida sensivelmente pela definição de Especificações Cobertas pela mesma. Nessa provisão, a Microsoft deixa claro que:

Novas versões de especificações anteriormente cobertas pela mesma poderão ser consideradas separadamente para serem adicionadas à lista [de especificações].

Devido à essa definição ampla de Especificações Cobertas, nenhuma versão futura de nenhuma dessas especificações estarão seguramente cobertas pela OSP. Cada nova versão é alvo da decisão da Microsoft em uma situação caso-a-caso. Em outras palavras, cada vez que uma especificação mudar, a Microsoft pode efetivamente revogar a OSP do modo como ela se aplica às versões anteriores da mesma especificação. A Microsoft determinou que irá renovar a promessa para futuras versões das especificações sujeitas à atividade de padronização “enquanto a Microsoft participar desses esforços”, o que na prática quer dizer que a Microsoft se reserva no direito de cancelar a promessa até mesmo para as especificações que passaram por padronização, simplesmente abandonando os grupos de trabalho ou atividades relevantes. Embora tecnicamente ela seja irrevogável, na prática a OSP só funcionaria de imediato. (grifos meus)
Atentemos aos grifos: por eles, compreendemos que, ao bel-prazer, a Microsoft pode, mesmo após aprovado o padrão, revogar sua OSP e sair processando todo mundo, criando uma patente submarina potencial, uma vez que, pelos termos citados, ao revogar sua OSP, todo usuário potencial da OSP estaria infringindo direitos de patente e, com isso, sendo alvo potencial de processos. Sem sombra de dúvidas, uma forma capciosa de implementar minas-terrestres de Propriedade Intelectual contra os usuários.
Mas não acabou: você não poderia incorporar código de implementações do OOXML em qualquer coisa que não envolva implementação OOXML. Vejamos o que a SFLC tem a dizer sobre isso:

Microsoft’s Open Specification Promise: No Assurance for GPL – Software Freedom Law Center

(…) any code written in reliance on the OSP is covered by the promise only so long as it is not copied into a program that does something other than implement the specification. This is true even if the code has not otherwise been modified, and code that conforms to the specification cannot be modified if the resulting modified code does not conform.

Traduzindo:

(…) qualquer código que tenha sido escrito em observância à OSP estará coberto pela promessa enquanto ele não for incorporado a qualquer programa que faça qualquer outra coisa que imp,ementar a especificação. Isso é verdadeiro mesmo se o código não for modificado, e o código que estiver seguindo a especificação não pode ser modificado se o código modificado resultante não estiver em observância.

O que isso quer dizer? Basicamente, não temos um uso livre para incorporação em qualquer situação, o que é definido pela Liberdade 2 da Free Software Foundation e que é parte do princípio por trás da GPL. Embora possa-se alegar que uma biblioteca poderia rodar segundo LGPL e assim trabalhar em conjunto com software GPL, ainda assim não pode-se afirmar que esse seja um uso livre ou mesmo seguro do mesmo.
O pior é que, segundo a Microsoft, a culpa é da GPL:
Microsoft’s Open Specification Promise: No Assurance for GPL – Software Freedom Law Center

In its FAQ regarding the OSP, Microsoft confuses the issue further, saying:

Because the General Public License (GPL) is not universally interpreted the same way by everyone, we can’t give anyone a legal opinion about how our language relates to the GPL or other OSS licenses, but based on feedback from the open source community we believe that a broad audience of developers can implement the specification(s).

While not attempting to clarify the text of the OSP to indicate compatibility with the GPL or provide a safe harbor through its guidance materials, Microsoft wrongly blames the free software legal community for Microsoft’s failure to present a promise that satisfies the requirements of the GPL. It is true that a broad audience of developers could implement the specifications, but they would be unable to be certain that implementations based on the latest versions of the specifications would be safe from attack. They would also be unable to distribute their code for any type of use, as is integral to the GPL and to all free software.

traduzindo:

Em sua FAQ relacionada à OSP, a Microsoft distorce essa questão [do licienciamento segundo a GPL] dizendo que:

Uma vez que a Licença Pública Geral (GPL) não é universalmente interpretada da mesma forma por todos, não podemos dar uma opinião legal sobre como nosso texto se relaciona à GPL e a outras licenças de software livre ou aberto, mas baseado no feedback que recebemos da comunidade do software aberto acreditamos que uma ampla gama de desenvolvedores pode implementar a(s) especificação(ões).

Além de não tornar claro o texto da OSP para indicar compatibilidade com a GPL ou oferecer um porto seguro por meio de eus materiais, a Microsoft erroneamente culpa a comunidade jurídica relacionada ao software livre por sua incapacidade de oferecer uma promessa que satisfaça as condições da GPL. É verdade que uma ampla gama de desenvolvedores poderá implementar as especificações [segundo a OSP], mas eles não terão certeza de que implementações baseadas nas versões mais recentes estarão seguras contra litígios. Eles também não terão garantias de que poderão distribuir tais códigos para serem usados como necessário, o que é uma parte fundamental da GPL e de qualquer software livre. (Grifos meus)

Perceba que citei anteriormente a possibilidade de adotar-se a LGPL. O problema é que pela primeira questão levantada (a possibilidade de revogação da OSP), não há garantias de que, mesmo sob LGPL, o software continue legalmente sendo aceito, devido às patentes.
Pretendo comentar mais sobre essa questão, uma vez que em alguns dias haverá a decisão final sobre a padronização do OOXML. Mas é importante ficarmos com a orelha em pé: não sabe-se o que pode acontecer.

Office OpenXML (OOXML) e inapto pela ISO 29500

ODF: Consenso emergente em favor de um formato padrão de documentos unificado?

Por Mark Shuttleworth

Link original: http://www.markshuttleworth.com/archives/132

Ainda é cedo demais para ter certeza, mas há muitos sinais encorajadores de que as organizações de padronização de todo mundo irão votar a favor de um padrão único para formatos de documento na ISO (International Standards OrganisationOrganização Internacional de Padronização). Já existe um formato de documentos padronizado, o ODF, e atualmente a ISO está considerando uma proposta para abençoar um formato alternativo, o OpenXML da Microsoft, como outro padrão. Nos movimentos mais atuais, os comitês de padronização da África do Sul e dos Estados Unidos disseram ambos que irão votar contra um segundo padrão e desse modo irão lançar uma luz sobre a necessidade de união em um padrão sensato, aberto e comum para documentos comerciais na área de processadores de texto, planilhas eletrônicas e apresentações.

É muito importante que nos apoiemos nessas decisões corajosas e convocássemos nossos comitês nacionais de padronização para apoiar a idéia de um padrão único comum para esses documentos críticos.

O modo como a ISO funciona é interessante. Há algo em torno de 150 países membros que podem votar em qualquer proposta específica. Normalmente, algo em torno de 40 países realmente votam. Para que a proposta passe, ela deve receber 75% de votos “sim”. Países podem votar “sim”, “não” ou “abstenção”. Portanto, normalmente bastariam 10 “nãos” ou abstenções para que uma proposta seja mandada de volta para uma maior consideração. Nesse caso, porém, a Microsoft tem trabalhado duro e gasto rios de dinheiro para convencer diversos países que normalmente não votariam a apoiar o formato que ela propôs.

Portanto existe algo concreto que você pode fazer, agora, nesse instante, nesse momento! Descubra qual organização é responsável pela representação do seu país junto à ISO. Na África do Sul é o Bureau de Padronização Sul-Africano (South African Bureau of Standards – SABS), e nos EUA acho que é a ANSI. (NT: No Brasil, a organização responsável é a Associação Brasileira de Normas Técnicas – ABNT). Há uma lista de alguma dessas organizações nesse link mas ela pode não ser completa, portanto você não precisa desistir se o seu país não estiver listado aqui!

Entre em contatos por ele, por telefone ou email, e pergunte a eles qual comite estará avaliando a proposta do OpenXML. Então prepare comentários para esse comitê. É realmente importante que os seus comentários sejam profissionais e corteses: você está lidando com pessoas de um alto nível técnico que tem uma responsabilidade enorme e levam-a a sério – eles não irão o levar a sério se os seus comentários não estiverem bem redigidos, escrito com cortesia e parecerem lógicos.

Se você tem uma opinião técnica forte, foque em um problema técnico único que você acredite que seja a melhor razão para que a proposta da Microsoft seja declinada. Existem vários bons argumentos descritos nesse link. Não apenas reescreva uma idéia já enviada – encontre um ponto técnico específico que signifique para você e o descreva de maneira sucinta e cuidadosa por você mesmo. Você pode o fazer de maneira curta, de apenas um parágrafo, ou mais longa. Há algumas sugestões de como proceder ao “falar com órgãos nacionais” aqui.

Aqui estão alguns pontos que eu considero particularmente interessantes:

  • Esse não é um voto “a favor ou contra a Microsoft”

Na verdade, esse é um voto a favor ou contra um padrão unificado. A Microsoft é um membro do comitê que define o ODF (o formato ISO atualmente existente) mas está na esperança de que seu formato seja considerado um padrão, ao invés de participar do comitê em questão. Um voto de “não ao OpenXML” é um voto contra múltiplos padrões incompatíveis entre si, e portanto um voto em favor da unidade. Se o voto da ISO for “não”, então haverá todos os motivos para esperar que a Microsoft irá adotar o ODF e ajudar a torná-lo um padrão ainda melhor para todos, inclusive para eles. Se manarmos uma mensagem firme para a Microsoft de que o mundo deseja um formato único e unificado, e que o ODF é o melhor caminho para que esse formato seja definido, então teremos um formato unificado e global, que incluirá a Microsoft. A importância dessa questão é que muitos técnicos governamentais reconhece a posição fundamental que a Microsoft exece em suas operações e países, e temem votar de uma forma que pode custar o dinheiro público. Se eles acharem que um voto “não” possa tornar impossível para eles trabalhar com a Microsoft, então eles irão votar “sim”. Claro que a Microsoft está falando para eles tudo isso, mas a verdade é que a Microsoft irá abraçar um formato unificado se as organizações de padronização em todo mundo afirmarem que isso é uma demanda.

  • Padrões abertos e consensuais funcionam REALMENTE BEM – veja o caso do HTML

Nós já temos um sucesso total na definição de um formato de documentos aberto, no caso o HTML. O Consórcio W3 (W3 Consortium – W3C), que inclui a Microsoft entre outras companhias, define o HTML e o CSS. Embora inicialmente a Microsoft tenha resistido à idéia, preferindo empurrar as extensões proprietárias à Web do Internet Explorer, ela acabou no fim das contas a participar das discussões do W3C. O resultado é um format de documento altamente rico, com muitas implementações diferentes. Muito dessa riqueza da web atualmente veio do fato de que existe um formato de documentos e interações na web totalmente aberto. Dê uma olhada em uma página Web comum e então dê uma olhada em um documento Word comum, e pergunte a si próprio qual desses formatos é mais impressionante! Claro que o Word poderia se beneficiar se ele fosse um padrão aberto, e não definido por apenas uma companhia.

  • Um padrão ÚNICO com várias implementações é MUITO mais valioso que múltiplos padrões.

Imagine o que poderia acontecer se houvessem padrões diversos de documentos Web incompatíveis entre si. Você não poderia ir a um site Web qualquer e imaginar que ele iria funcionar. Você teria que saber qual formato seria usado no site. O fato de haver um padrão de documentos Web aberto – o HTML – é a mola propulsora da eficiência da Web como repositório de informação. A Web é um exemplo claro de como o ODF é a estrutura preferencial para um padrão público. O ODF, o padrão existente, é definido de maneira aberta por diversas companhias, e a Microsoft pode participar como todas as outras. Eles saberm que podem – e eles participam de discussão sobre outros padrões na mesma organização. A Microsoft irá dizer que “múltiplos formatos permite que os consumidores escolham”, mas eles sabem que ter um único padrão que evolua de maneira rápida e eficiente, como o HTML, oferece muito mais valor. Os efeitos de rede na troca de documentos significam que um padrão em qualquer evento irá emergir como dominante, e o importante para os governos, negócios e consumidores que o padrão EM SI ofereça maior escolha em implementações As pessoas não compram um padrão e elas não usam um padrão de documentos. Elas usam uma ferramenta de software ou hardware. Se o “padrão” puder ser manipulado por apenas uma ferramenta de um fornecedor, no fim das contas os consumidores não terão escolha quanto ao fornecedor. Considere o valor do ambiente de telefonia celular GSM, com centenas de fornecedores de soluções seguindo um padrão único para o mundo todo, comparado com a ineficiencia de países que permitiram que redes proprietárias fossem implementadas em freqüências públicas. O ODF já é implementado por muitas companhias diferentes. Isso quer dizer que já existem muitas ferramentas diferentes que as pessoas podem escolhar para trabalharem com seus documentos ODF de maneiras diferentes. Algumas dessas ferramentas são preparadas para uso na WEB, outras para armazenamento de documentos, outras para análise de dados, e outras para edição. No caso do OpenXML, não há nenhuma implementação completa do mesmo. Isso porque mesmo o Microsoft Office 12 não implementa OpenXML da maneira correta. Além disso nenhuma outra companhia desenvolveu nenhuma ferramenta para gerenciar documentos OpenXML. A Microsoft tenta fazer parecer que já exista uma ampla participação, mas analise um pouco mais fundo e perceberá que tudo está baseado em apenas uma companhia. O padrão ODF é um formato muito mais adequado para armazenarmos nossos documentos.

Eu gostaria de agradecer o time da TSF pelo trabalho que tiveram em participar do comitê de padronização Sul-Americano. Eu espero que cada um de vocês que tenham lido até aqui peguem o telefone dos órgãos de padronização e entre em contato com os mesmos para ajudá-los a tomar uma decisão adequada.

Os EUA, a África do Sul, a China e outros países irão votar “não”. Não permita que um lobby intensivo influencie o que deveria ser uma discussão calma, racional, sensata e acima de tudo técnica. Padrões são importantes, e ainda mais quando definidos em fóruns abertos e transparentes. Entre em ação!!

Office OpenXML (OOXML) e inapto pela ISO 29500

Powered by ScribeFire.

BrOffice.org – ODF: O formato Inevitável

Em 1999, um cientista desejava ter acesso a alguns dados de amostras de solo de Marte coletadas em 1975 pela sonda espacial Viking. Ele desejava testar uma teoria sobre uma possível existência de bactérias e micróbios em Marte – ou seja, a existência de vida em Marte. O cientista pensou que ele poderia encontrar o que precisava em um dos diversos sites da NASA, mas não foi tão fácil quanto aparentava. Os dados originais não estavam onde se esperava, e quando as grandes fitas magnéticas que continham esses dados foram localizadas, eles estavam “em um formato tão antigo que os programadores que sabiam como ele funcionava haviam morrido”. Alguém então encontrou um conjunto de versões impressas dos dados que estavam servindo como peso de papel e o entendimento da humanidade quanto ao universo aumentou um pouco mais. O senso de tragédia que poderia ter resultado da perda de tais conhecimentos são ecoados em registros sobre a destruição da Biblioteca de Alexandria, e explica porque em uma sociedade sadia a queima de livros normalmente é vista como insanidade.

Claro que nem todos os dados perdidos ou inacessíveis armazenam pistas para a vida em Marte, e obviamente nem toda informação precisa ir além da vida do seu autor. Muitos documentos ilegíveis não farão falta, mas políticas públicas responsáveis exigem que documentos do governo – contratos, escritúras e registros processuais que têm força por décadas ou mesmo séculos – precisam ser arquivadas e estar disponíveis a todos. Seja como for, quando os dados são armazenados e compartilhados em formatos antigos ou obsoletos, com o tempo se tornará cada vez mais caro o acesso aos mesmos, sendo que eles podem até mesmo desaparecer.

Quando estamos falando de documentos que podem ser criados, armazenados e compartilhados digitalmente, a tecnologia para a prevenção do desaparecimento devido a formatos já existe e está tornando-se cada vez mais popular. Ela é chamada de Formatos para Documentos Abertos (Open Document Format – ODF) e se você ainda não o usa, algum dia irá usar.

O ODF é um formato de marcação de documentos baseado em XML que foi inicialmente desenvolvido em 1999 pela Stardivision e então no projeto OpenOffice.org, financiado pela Sun Microsystem. Concebido para ser uma alternativa a um software proprietário de manipulação de documentos, que então dominava completamente o mundo, a força motriz que impulsiona o ODF é a necessidade de um formato de documentos independente de fabricante ou de aplicação, que possa ser escrito e aberto por todos, sem a necessidade de royalties ou de licenciamento. Ele foi promovido com a idéia de que empresas e consumidores possam economizar dinheiro. Um formato aberto pode criar competição na esfera das aplicações de escritório. Todos os documentos podem ser abertos e compartilhados por todos. Não haveria perdas pelo tempo ou por mudanças em códigos proprietários ou pelas exigências de licenciamento. Informações de grande interesse público, como informações censitárias, informações sobre o clima, estatísticas sobre saúde, informações de investigações, registros jurídicos e informações de pesquisas científicas, pagas com os empostos dos contribuíntes, não precisariam mais serem escritas em um formato proprietário e fechado, obrigando os cidadãos a pagar duas vezes pelo acesso à informação que eles próprios produziram. Usando ODF, dizem seus proponentes, os documentos públicos permanecem sempre públicos.

A Organização para o Avanço dos Padrões de Informação EstruturadaOrganization for the Advancement of Structured Information Standards – OASIS) foi criada em 2002 para padronizar o formato, que foi reconhecido pela Organização Internacional para PadronizaçãoInternational Organization for Standardization – ISO) em 2006. Em Março de 2006 foi fundada a Aliança para o Formato Aberto de Documentos (Open Document Format Alliance) para promover o formato, criando condições públicas, legais e políticas para a adoção de padrões abertros de tecnologia por parte de instituições públicas egovernos.

– A Red Hat é um dos membros fundadores da ODF Alliance e Tom Rabon (Vice-presidente para assuntos corporativos) é parte do conselho executivo da organização. – diz Stephanie McGarrah, antiga Gerente de Políticas Públicas da Red Hat. – A Red Hat trabalha com os outros membros do conselho executivo para coordenar esforços e conversar com os governos de todo o mundo sobre o ODF.

Embora o ODF tenha sido lançado com um grande impulso derivado do bom-senso soprando forte, o momento para adoção em massa do formato foi enfraquecido pela inércia da burocracias, políticas locais, conceitos errôneos persistentes sobre a viabilidade do ODF (reforçados por oponentes do formato) e pelos “perigos” da adoção do formato. Muito do medo, incerteza e dúvida surgiram de uma fonte, cujos formatos proprietários são usados na maior parte dos documentos de todo o mundo.

Os oponentes do ODF não aceitam a sua adoção inevitávl, e ativamente fazem lobby contra ele. Não é que todos sejam contra o ODF per se, ou que tenham encontrado alguma razão real que questione a necessidade do mesmo. A lógica por trás do ODF e a transparência na sua criação é algo que dificilmente pode ser questionado. Na verdade, é a questão de padrões abertos que está por trás do ODF que é o alvo principal. Do ponto de vista dos detratores do formato, as coisas estão indo muito bem do jeito que estão atualmente. O “padrão” é deles, eles são donos do “mercado” de documentos, e pensam nele como um “território” “conquistado” de maneira limpa. Eles não conseguem imaginar um futuro sem esse “território” (isso sequer consta de seu plano de negócios), e já que todos utilizam suas aplicação e formatos, por que mudar? Os oponentes do ODF devotam recursos consideráveis no lobby de comissões de aconselhamento de TI tanto no Executivo quanto no Legislativo em uma tentativa de convencê-los de que a adoção do ODF na realidade limita a escolha e fere a eficiência do modelo de mercado ao “expulsar” empresas como eles. Eles afirmam que a migração é cara, e até mesmo argumentam que a adoção do ODF irá limitar o acesso público ao fatiar o ambiente de TI em milhares de formatos “incompatíveis”. E quem realmente confia em toda essa idéia de “gratuito”?

Mas os propontentes do formato, como a ODF Alliance, tem seus próprios argumentos, muitos deles partindo do princípio de refutação que diz que “Inicialmente, o oponente está certo…”

A ODF Alliance afirma que os padrões abertos na verdade promovem a escolha e a competição entre fabricantes ao definir as regras básicas do jogo. Os padrões são abertos e disponíveis livremente para que qualquer um possa implementá-los. Não existe nenhuma competição envolvendo o formato, e sim a aplicação que será usada para o manipular. Nesse universo, a melhor aplicação ganha. A ODF Alliance também aponta que implementar ou migrar para ODF não é mais complicado ou custoso do que a atualização períodica de uma versão de uma aplicação proprietária para a seguinte, e ao tornar a mudança para versões futuras mais simples, existe uma redução nos custos ao longo do tempo. Quanto à questão de disponibilidade de aplicações, o OpenOffice (e outras aplicações que seguem o ODF) podem ser copiadas da internet livremente e podem ser usadas já. Não existem questões de compatibilidade na realidade, dizem os defensores, apenas questões de não-cooperação.

– Acho que muitos governos não sabem da existência ou não têm um corpo técnico capaz de entender o valor do ODF. – explica McGarrah. – Portanto, o trabalho da aliança divulgar essa mensagem para as pessoas nos governos que possam tomar tais decisões.

Mas o principal argumento em favor do uso do ODF para documentos públicos é o fato de que é um melhor negócio para os cidadãos no longo prazo. Usar software proprietário e com padrões fechados para documentos públicos é como comprar uma privada de 10 mil dólares, ou proibir o governo federal de negociar preços melhores nos remédios a serem distribuídos pelo SUS, ou tentar suprir um exército e apoiar a reconstrução de antigos campos de batalha por meioo de contratos secretos, não licitados e não competivitivos. É a não competitividade em seu pior sentido.

Apesar da oposição, a adoção do ODF está indo em frente, devagar mas inexoravelmente, e conforme os governos vão entendendo melhor o ODF, o ODF vem desafiando a atual ubiqüidade dos formatos proprietários. Indo mais adiante, o Japão obrigou recentemente que todos os contratos de seus ministérios com vendedores de software fossem feitos de modo a envolver padrões abertos. Brasil, Polônia, Malásia, Itália, Coréia, Noruega, França, Holanda, Dinamarca, Bélgica, o Estado de Massachusetts nos EUA e o Estado de Dehli na Índia estão todos fazendo mudanças nas leis de forma a adotar o ODF e, provavelmente mais importante de tudo, reconhecer o imperativo de usar-se padrões abertos. A ODF Alliance continuar a armar e iluminar os legisladores com as informações e ferramentas que eles precisam para fazer recomendações e mudanças de políticas, mas ninguém que promova o ODF acredita que sua adoção em massa é iminiente. Ela levará algum tempo.

– Esses legisladores tem muitas outras coisas importantes para resolver, como saúde, educação, transporte, combate a pobreza e outros, portanto decisões sobre tecnologia não estão normalmente no topo de suas listas. – diz McGarrah – Já tivemos avanços quanto a uma maior adoção do ODF. Muitos governos adotaram o ODF e estão trabalhando na implementação do padrão, mas ainda há muito o que fazer.

Powered by ScribeFire.