http://www.pedro.jmrezende.com.br/sd.htm > Padrões | PDF

Sobre adoção do formato .pdf como padrão

Debate sobre a adoção do formato .pdf como padrão pela Justiça Especial Federal de São Paulo

Prof. Pedro Antonio Dourado de Rezende
Departamento de Ciência da Computação
Universidade de Brasília
Janeiro de 2009


Entre 14 e 16 de janeiro de 2009, participantes da lista do IBDI debateram por e-mail uma notícia publicada no portal da OAB-SP (JEF Só Vai Aceitar Pedições em Formato .pdf), cujo lead diz:

"Desde 7 de janeiro o Juizado Especial Federal de São Paulo só está aceitando pelo protocolo eletrônico petições em formato PDF. Desse modo, não será mais possível protocolar em outros tipos de arquivos, como DOC. RTF E TXT. As petições não poderão ter tamanho superior a 100kb por página. O Sistema de Petições Eletrônicas dos Juizados vem aceitando desde 19 de novembro do ano passado arquivos no formato PDF. A página do protocolo eletrônico da Internet traz explicações sobre como proceder para gerar arquivos em PDF."

A presente síntese daquele debate, contextualizando os comentários do autor a respeito, teve sua edição e publicação autorizadas pelos demais debatedores, anonimizados conforme transcrição abaixo.



email 1:

Aos comentários sobre a decisão do JEF abaixo citados (em vermelho), gostaria de fazer algumas observações.
A: Parece que ao invés de facilitar para os advogados, tradicionalmente não muito afeitos às tecnologias, estão dificultando cada vez mais. Na verdade jogaram fora uma palavrinha muito importante da lei do procedimento eletrônico: padronização.
Considerando que há padrões e padrões, a intenção (e o efeito) do que se jogou pode ter sido na verdade o contrário, a saber, a busca da padronização, como aponta, abaixo, opinião de quem participou de reuniões a respeito na OAB/SP.

B: Depois de frequentar algumas reuniões da comissão de informática da OAB/SP, soube que o TJ/SP caminha no mesmo sentido, ou seja, adotar apenas PDF em razão da incompatibilidade entre os diversos formatos de arquivo utilizados por processadores de texto (.doc, .docx, .odt, etc). Considerando que o PDF é um formato aberto - recebeu ISO 32000 e pode ser gerado de diversas formas, sem ser necessário recorrer a programas comerciais - creio que será mesmo adotado como padrão.?
Há vários conjuntos de critérios para definir o que seja um formato ou padrão aberto. Esses conjuntos de critérios são propostos por distintos interesses e não se equivalem. Assim, para quem comunga dos interesses desta lista, considero conveniente estar atento às nuanças.

O PDF é um formato aberto no sentido de que seu padrão tem caráter público, é especificado de maneira completa, e com os direitos de marca e patentes a ele incidentes sob compromisso do(s) respectivos detentor(es) de serem licenciáveis, para implementação de softwares capazes de lidar com o formato, segundo o critério RAND (on Reasonable And Non-Dicriminatory terms). Este é o sentido de "formato aberto" conforme o conjunto de critérios adotado pelas normas internas da ISO (International Standards Organization) para definirem tal coisa, em referência aos padrões que ela homologa.

O PDF foi, portanto, homologado pelo comitê JTC1/SC34 da ISO conforme tais critérios. A empresa que controla o padrão, ou seja, a evolução do formato (Adobe), neste caso a "proprietária" do padrão (nem todo formato é controlado por uma só empresa), licencia pública e inominadmente (isto é, previamente a qualquer um) e sem ônus (on no-fee terms) o direito de implementar um renderizador (software para visualização) deste formato, e oferce licenças a preços módicos (por exemplar de software) ou em "termos razoáveis" para interessados em implementar um editor (software para visualização, modificação e gravação).

Mas nem sempre é assim; diante da evolução normativa sobre o uso das TIC por entidades públicas, devido à crescente importância política e econômica que nela vem ganhando o selo de "formato aberto homologado por organismo de padronização internacional", a ISO tem cedido a pressões de monopolistas renitentes, no sentido de relaxar a aplicação dos seus próprios critérios no processo de homologação de formatos candidatos a tal selo seu.

O critério de 'especificação completa', por exemplo, que vinha sendo aplicado na prática (não na ISO, mas também em outros organismos de padronização) pela exigência de que existam no mínimo duas implementações independentes e interoperáveis (no caso, de softwares capazes de ler e/ou gravar no formato), consideradas como referências, foi totalmente abandonado quando da aprovação do formato OOXML. Nem mesmo sua proprietária implementava, ou implementa hoje, um formato completamente aderente ao tal padrão (nem com o .docx). Não bastasse isso, no processo de homologação do OOXML o debate sobre aderência ou não ao critério RAND foi completamente censurado em todas as instâncias decisórias, inclusive com atropelo de casuísmos normativos e processuais no âmbito do JTC1 (ver, por exemplo, "Padrões Digitais, Escolha e Privacidade - O Caso OOXML"). 

C: Padronizar é importante. Permitir o uso de um formato proprietário me parece um pouco incongruente em um país que estimula tanto o uso de formatos abertos como uma das maneiras de combater a pirataria. Nada mais natural que a escolha seja pela extensão pdf, gratuita e acessível (vários programas gratuitos lêem e produzem pdf).

Padronizar é tão importante nas TIC que se quem depende delas não o fizer, farão-no os que dominam suas implementações, para seu próprio e crescente benefício e ao final às custas do benefício daqueles.

Considerando que os conjuntos de critérios para definir "formato aberto" são, via de regra, independentes da natureza do processo que controla sua padronização, podemos dizer que um formato pode ser ao mesmo tempo aberto e proprietário; aí se enquadrariam o formato de documento eletrônico PDF e também a linguagem de programação Java, conforme, por exemplo, o conjunto de critérios adotados pela ISO para definir padrão aberto.

Já no âmbito dos ecosistemas FOSS e A2K, o conjunto de critérios adotados para definir formato ou padrão aberto costumam ser mais fortes, especialmente no que se refere a direitos de marcas e patentes incidentes, onde o regime RAND é considerado insuficiente e substituído pelo critério NAND (on No-fee And Non-Discriminatory licensing). Isso ocorre porque qualquer cobrança de direitos "por exemplar", seja do software que manipula o formato, seja de obra fixada no formato, inviabiliza os modelos de licenciamento e distribuição do software livre (com ou sem copyleft) e do Creative Commons.

Além disso, se a evolução do formato é controlado por apenas uma empresa o padrão ou formato é considerado não-livre. Como exemplos podemos citar a linguagem Java (cuja especificação é controlada pela Sun), cujo padrão é aberto no sentido forte (porém não livre), o formato .odf e a linguagem html (controlados por consórcios), cujos padrões são fortemente abertos e livres.

Todavia, todo esse mosaico se embaralha completamente quando 'padrão aberto' é confundido com 'padrão' ou com 'padrão abertamente usado' (vide, p. ex., IP Watch: Concerns Voiced At WIPO Over Potential Conflicts Between IP And Standards). Os formatos preferenciais das diversas versões do pacote de escritório mais usado são padrões. Pois sendo os mais usados, são padrões 'de mercado'. São, portanto, usados abertamente, mas sem se encaixar em nenhuma definição racionalmente útil de padrão aberto. Até porque o mesmo padrão é implementado, na sua série de versões, por formatos que via de regra são incompatíveis entre si. Padrões de mercado que não se encaixam em nenhuma definição de padrão aberto exceto naquelas que pintam todos gatos de pardo. Ou mais precisamente, pintam 'vendor lock-in' de 'preferência do consumidor'.

C: Concordo que existem algumas falhas nas políticas de estímulo aos formatos abertos, mas, ainda assim, são muitas as políticas públicas que tentam tal inserção (ao menos, essa é a sensação que o portal de software livre do governo nas passa - http://www.softwarelivre.gov.br - ao mostrar suas ações pró-migração).

Mas, como meu pai sempre fala, "uma cultura não se muda com cem ou duzentos anos". Obviamente, não temos todo esse tempo, mas as informações têm fluido com mais rapidez e estrutura institucional auxilia as mudanças culturais. Ninguém nunca prometeu que seria fácil (e se assim o fez, é notório que que era uma promessa absurda).

Sobre o pdf ser editado, sabemos que alguns programas podem fazer isso, como o póprio Acrobat. O problema é que ignoro a existência de algum programa gratuito que faça isso. Alguém conhece?

Desconheço, suspeito que inexistam e que continuarão inexistindo (mutatis mutantis) pelos motivos que expus, acima, em referência à definição forte (i.e. FOSS, com critério NAND) versus fraca (i.e. ISO, com critério RAND) de formato aberto.

C: De qualquer maneira, dificultar a edição do pdf pode ser algo bom neste caso, não?! Se for fazer notações sobre o documento, vários programas fazem.
A meu ver, talvez tão bom ou melhor do que a escassez de editores em uso para o formato, para os fins aqui discutidos a grande vantagem do PDF talvez esteja no fato do documento embutir seus próprios fonts.

Esse detalhe permite a quem controla o formato (talvez não por coincidência, a mesma empresa que controla a titularidade da maioria dos fonts hoje em uso nas diversas interfaces gráficas, a Adobe), garantir, com total eficácia, o verdadeiro WYSISYG (What You See -- where the document is saved -- Is What You Get -- where the document is seen) para usuários do formato.

Devido à variedade e profusão de fonts instalados nos ambientes gráficos, esta garantia, nem o .odt, com toda a sua liberdade e forte abertura, e nem o .doc, com toda a sua ampla penetração de mercado, podem oferecer. Para quem entende o que é vendor lock-in, o trocadilho referente a esse último pode não ser acidental.




email 2

A: No caso o Acrobat Pro, que é pago e não é barato. Acredito que existam programas gratuitos com o mesmo fim, e se não me engano a MS ventilou a possibilidade de adotar o PDF, inclusive para edição, na próxima suite Office. O BrOffice/OpenOffice devia fazer o mesmo - não sei por que não fez, já que alguns defendem ser o PDF um formato "aberto" (e tenho minhas dúvidas, e enquanto perdurarem soucontra sua utilização).
A MS ventilou, mas foi impedida de realizá-lo por decisão judicial ou extra-judicial, obtida a pedido da Adobe em virtude da impossibilidade de acordo sobre os termos de licenciamento (supostamente em regime RAND) para implementação de um conversor PDF pela MS (ou de um módulo editor, não sei dos detalhes, via de regra nebulosos quando envolvem a primeira: ver, por exemplo, "Why Adobe and Microsoft Hit Delete on PDF Deal").

O motivo alegado, pelo que me consta, foi o de que a Adobe queria, neste licenciamento, garantias adicionais de que o formato PDF não se tornaria, com a implementação licenciada, mais uma vítima da estratégia EEE da MS: Embrace (an open standard), Expand (the implementation of the standard to break interoperability), Extinguish (the life of competing products and/or the openess of the standard as a market standard), estratégia que já atingiu outros formatos abertos, como por exemplo os das linguagens HTML e Java.

No caso da linguagem Java, a vitimação da interoeprabilidade do formato pela estratégia EEE da MS foi objeto de ação judicial, a qual foi encerrada em acordo pelo qual a ré, MS, teve que pagar indenização bilionária à Sun (ver. por exemplo, "Sun, Microsoft Settle Java Lawsuit"). No caso de editores PDF, parece que a Adobe considera mais prudente, e/ou menos danoso, prevenir do que remediar. O que eu considero sensato, entre outros motivos porque na jurisdição dos EUA quem ganha uma causa cível raramente tem suas despesas judiciais cobertas pela apenação da outra parte, e porque os efeitos da estratégia EEE podem asfixiar de morte um formato aberto usado abertamente, inclusive durante o transcurso de uma disputa judicial sobre contrato de licenciamento para implementação do padrão.

Já a vitimação no HTML, e (principalmente) em suas extensões para conteúdo ativo, esta atinge a todos os que precisam manter páginas web e os que querem navegar a web com navegador de sua própria escolha. Quanto ao BROffice e o PDF, o aplicativo já inclui, desde longa data, um conversor (cujos direitos a Adobe licencia sob regime NAND) para gravar em PDF arquivos que podem ser abertos pelo aplicativo em formatos editáveis (.odt, .doc em várias versões, .htm, .rft, etc.). O BROffice muito provavelmente nunca terá a funcionalidade de edição em PDF (a de abrir e editar em PDF) devido à estratégia negocial da Adobe para este formato (NAND para visualizadores e conversores, RAND para editores), cuja incompatibilidade (para editores) com o regime FOSS foi explicada em email anterior.

A: Dificultar a edição de PDF é tapar o sol com a peneira. Se há como fazer, e houver quem tenha intenção de fazê-lo para fins não nobres,fatalmente descobrirá que não só é possível como é fácil fazer.
Como entendo, "dificultar" a edição de PDF não é uma medida de segurança tomada pela proprietária do formato PDF em favor dos usuários deste formato, mas antes, uma estratégia negocial para lucrar com editores (com o licenciamento do Acrobat PRO para usuários finais, e de marcas e patentes incidentes ao formato para concorrentes deste editor) em cima da popularidade do formato, popularidade esta impulsionada pelo licencimento NAND de vizualizadores e conversores (softwares que gravam em PDF arquivos editáveis em outros formatos, sem no entanto editar sobre formato PDF).

B: Não entendo a ressalva de (A). Editar um arquivo em formato PDF de terceiros - uma petição da parte contrária, por exemplo -  não significa conseguir inserir o arquivo modificado no sistema em substituição ao original. Qual é a preocupação?
Talvez a ressalva decorra de uma extrapolação precipitada, uma confusão entre o que (C) citou anteriormente como possível benefício da adoção do PDF, e um possível motivo para a JEF-SP adotar o formato como padrão em seus processos, não?

A: Fiz o comentário porque uma hipótese de terem escolhido o PDF é por pensarem que ele não pode ser editado (ou não tão facilmente).
Uma outra hipótese, mais racional, é pelo regime NAND para visualizadores e conversores 100% WYSIWYG (esta última vantagem garantida pelo menos enquanto inexistir distribuição de editores PDF fornecidos por monopolistas renitentes sob estratégia EEE).

D: Vendo a discussão dos Srs. acerca da possibilidade de edição do .PDF, eu, particularmente, entendo que a solução, por ora, seria a assinatura digital (utilizando o certificado da AC-OAB) no arquivo .PDF.Desta forma, geraria um hash do documento, cuja alteração (no caso, a utilização dos programas PDF2DOC, por exemplo) importaria na quebra do sigilo. Assim, seria possível ao tribunal verificar a veracidade e, se for o caso, a devolução do prazo ao usuário que os enviou..
Esta é a solução para um problema (integridade dos documentos) que é ortogonal (independente) do problema da escassez ou da falta de editores para o formato em que o documento é fixado para tramitação judicial. Um programa que assina digitalmente documentos em determinado formato, ou que verifica essas assinaturas, pode ou não fazer parte (integrante ou extensiva) de um programa que converte e grava, ou que abre e edita, documentos neste formato.

Até a assintura ditial per se, a sequência binária que constitui o autenticador (a assinatura digital propriamente dita) de um signatário sobre um documento, pode ou não fazer parte (apensada) do arquivo que contém esse documento. Pois o suporte da assinatura digital é a sequência binária que constitui o documento, e não o arquivo que a contém, pelo que uma assinatura digital do documento pode estar em outro arquivo, vinculada ao arquivo do documento apenas pelo nome de ambos (assinatura destacada). A questão da comodidade ou facilidade de uso (a de ter que lidar com um ou com mais de um programa ou arquivo) é também independente da questão da viabilidade técnica (a de ser possível assinar e verificar com um ou mais de um programa ou arquivo).

Para melhor compreensão dos detalhes, talvez cause menos confusão dizer que um documento digitalmente assinado permite detectar sua quebra de integridade, e não de sigilo, pois sigilo é algo que a assinatura digital não garante, não oferece e não conhece (exceto o presumido acerca da chave privada do signatário, o que nada inclui do documento). Não se deve confundir a autenticação que a chave privada do remetente de um documento pode oferecer, via assinatura digital (a quem confia na titularidade da chave pública correspondente e tenha acesso a ela), com o sigilo que a chave pública do destinatário do documento pode oferecer, via cifragem (a quem confia no controle e acesso à chave privada correspondente unicamente pelo seu titular e destinatário).

D: Uma notícia, em caráter de informação, é que no TJMS (Mato Grosso do Sul) o tribunal sugere somente o envio do arquivo em .PDF, e ainda por cima gerado no software PDFCreator. Digo isto porque certa vez foi enviado um arquivo gerado no Adobe, e o sistema retornou um aviso, dizendo que seria aceito somente arquivos gerados no PDFCreator.
Tecnicamente esta exigência não decorre de uma possível necessidade de compatitilidade WYSIWYG entre gerador (software conversor de formatos) e visualizador (software renderizador) de documentos PDF, mas poderia decorrer da necessidade de compatibilidade de formatos da assinatura digital apensada ao documento PDF, entre o módulo de software que lavra a assinatura digital e o que a verifica.




email 3

B: Pelo que percebi desta análise, a adoção do formato .pdf como padrão é algo muito bom, ainda que não se enquadre na definição NAND, mas apenas RAND. Ou haveria alguma outra alternativa, com grau similar de eficiência?

Como procurei esclarecer no email anterior, o PDF pode ser considerado um padrão proprietário e aberto num sentido mixto, isto é, aberto num grau entre forte (pelos critérios FOSS) e fraco (pelos critérios ISO), já que tem especificação pública comprovadamente completa, licenciamento em regime NAND para renderizadores e conversores, e RAND para editores. Assim, em relação ao critério de coerência com uma política pública de estímulo ao uso de Software Livre, antes aqui posta em dúvida, considero a escolha do .pdf como padrão para troca de documentos eletrônicos com uma entidade pública, nas condições atuais, satisfatória.

A maior desvantagem em um padrão de formato digital ser proprietário (não confundir com o formato ser opaco ou fechado), mesmo que seja fortemente aberto, em relação a um padrão de formato livre, vejo-o nas dificuldades legais para evolução e sobrevivência do padrão caso a empresa que controle o padrão venha a falir, ou a ser engolida por outra interessada em matar o formato (o que não significa que padrões livres sejam imortais: eles podem morrer de inanição -- por desinteresse dos consorciados -- ou asfixia -- pela estragégia EEE de um monopolista renitente, por exemplo). Quanto a alternativas com grau similar de eficiência, depende de como se mede a eficiência.

Para os que usam a escala do comodismo imediatista, os que preferem não ter que lidar agora com o comando 'salvar como' e o gerenciamento de documentos em dois formatos para fins de interoperabilidade (.doc e .pdf ou então .odt e .pdf, por exemplo), existe a alternativa óbvia dos padrões 'de mercado'.

Esta alternativa seria, obviamente, a de sempre adotar a 'solução' oferecida por quem domina o mercado (mensagem subliminar do FUD), e portanto, no caso em tela seria a de seguir (submeter-se a) a estratégia negocial de um fornecedor de pacotes de escritório que, para proteger sua posição monopolista, é levado a adotar em seus softwares formatos 'default' opacos que na prática são fechados (i.e., propositalmente ofuscados) e licenciáveis apenas sob o regime UAD (on Unreasonable And Discriminatory terms).

Doutra feita esta alternativa, ao invés de livrar o usuário de ter que lidar com 'salvar como' e dois formatos, apenas adia o problema, enquanto o acumula e o agrava. Pois quem se submete a esta alternativa terá que lidar com o problema depois, ao ter que eventualmente migrar o seu acervo, para atualizar seus documentos entre versões incompatíveis de formatos do mesmo fornecedor, sempre que este fornecedor, que já prendeu seus clientes com vendor lock-in em alguma escolha de plataforma (hardware, sistema operacional, banco de dados, etc.), decidir inovar também seu padrão de documentos, se necessário 'descontinuando' suporte e/ou atualizações 'de segurança' para formatos 'obsoletos' (como se pode ver, por exemplo, em "Legacy Format FUD").

E não, não se trata de maiqueismo (aos olhos de quem quer ver), de mero alarmismo contaminado por ranço ideológico, mas de pragmatismo indicado pela lógica econômica: para um forncedor de software monopolista, a limitação do direito autoral que permite a engenharia reversa para fins de interoperabilidade (como na jurisdição dos EUA) erode a competitividade dos seus 'produtos' caso estes softwares permaneçam usando formatos estanques ou facilmente conversíveis entre si. Pois os competidores vão decifrando e, principalmente no ecosistema FOSS, coletivamente acumulando conhecimento sobre a semântica do padrão de formatos dominante no mercado para, seguindo a mesma lógica econômica, oferecer aos usuários o graal da interoperabilidade a preços imbatíveis.

Sob a perspectiva da lógica proprietária aplicada a bens simbólicos de natureza não-rival, portanto, os concorrentes de um fornecedor dominante que buscam, em sua evolução e sobrevivência, a interoperabilidade com os produtos deste fornecedor dominante agem como um bando de cupins, corroendo aos poucos a preciosa 'propriedade intelectual' representada por esses formatos opacos dominantes. Processar concorrentes (ainda) pequenos ou consorciados entre si, para achacá-los, intimidá-los ou extorqui-los com patentes de 'invenções' de formatos digitais, faze-los réus que podem estar sob proteção de acordos de não-agressão patentária cruzada envolvendo outros concorrentes de peso, pode não ser tão eficiente e previsível quanto 'inovar' esses formatos. Inovar com o objetivo técnico primordial de re-atrasar a interoperabilidade dos concorrentes jamais publicamente admitido, e com danos colaterais na interoperabilidade com versões anteriores dos seus próprios clientes fetichizado como 'evolução' ou inovação necessária.

Essa lógica não tem por que mudar, e historicamente não tem mudado, a não ser pela escolha consciente de usuários quando estes são levados, em massa, a superar as barreiras do vendor lock-in estabelecidas pelo modelo negocial dominante, quando este modelo chega ao fim de seu ciclo de eficácia técnico-econômica. Assim foi, por exemplo, com o modelo negocial monolítico estabelecido no ciclo em que os computadores de grande porte eram dominantes. Embora hoje me pareça claro que um tal ciclo esteja se esgotando, não me parece claro qual será o próximo. Mas parece que, em nome de alguma eficiência ou de sabe-se lá o quê, os acometidos pela "Síndrome de Estocolmo Digital" continuarão racionalizando até ao oblívio ou à morte. Até o próximo ciclo, e até nesta lista.




email 4

A: [Sobre a afimação de que há padrões e padrões, na primeira resposta] Parece-me que a partir do momento que existe um exemplar de formato, ou ele é único ou admite outro(s). Portanto, o objeto do questionamento é pela busca uma tal de padronização, citada na Lei 11.419, no caso em tela começando pelo PDF (e levando-se em conta que a JEF-SP não é a única nem a primeira, mas a maior e mais acessível)

Se entendi corretamente sua observação, vou tentar responder considerando que sobre a citada Lei suponho apenas que ela pugna pela busca de padronização na informatização processual.

No trecho a que voce se refere eu estava respondendo à afirmação sua de que "Na verdade jogaram fora uma palavrinha muito importante da lei do procedimento eletrônico: padronização". Ao responder, eu supus que voce se referia, como indica a sintaxe da sua mensagem, à escolha do PDF como formato único para o padrão da JEF-SP. Entendi que sua afirmação acusava a escolha desse padrão de fugir dos objetivos do que seja padronização.

No trecho a que voce se refere eu quis dizer que, no contexto (referente a documento eletrônico), há mais de um formato disponível para a JEF-SP escolher, já que há mais de um formato que poderia ser, loosely speaking, considerado 'padrão no mercado' (ver adiante). E quis dizer, também, que há mais de um tipo de padrão ou forma de padronização (no caso, para formato de documentos eletrônicos): proprietário ou livre; aberto ou opaco (livre e opaco não faria sentido, mas por incompetência pode haver); aberto fracamente ou fortemente; opaco por especificação pública insuficiente ou fechado por ofuscamento deliberado (por regime UAD ou por codificação hermética), etc.

E também, quis dizer que há mais de um critério para se escolher um ou mais formatos como padrão para um certo serviço: a base instalada dos usuários deste serviço, a situação do mercado, a interoperabilidade no sentido da independência de fornecedores (em ambos os lados da comunicação), a interoperabilidade no sentido visual (i.e. WYSIWYG), etc.

E quis dizer que, a meu ver, ao escolher um conjunto ou lista (lista = conjunto ordenado) de critérios para selecionar seu padrão de formatos para documentos eletrônicos visando a informatização processual, considerando as nuanças citadas acima, haveria pelo menos uma lista de critérios, dentre as possíveis de serem escolhidas pela JEF-SP, que seleciona o PDF como único formato atualmente em uso (disseminado) capaz de atendê-la. E depois, nos comentários seguintes, procurei opinar do porquê, a meu ver, um tal conjunto ou lista de critérios (qualquer que tenha sido) ser razoável, e boa -- no sentido da qualidade do serviço a longo prazo -- para os fins a que se propõe.

A: Quais seriam mesmo os padrões 'de mercado' fora os citados no email 3, em especial DOC e PDF? A decisão do JEF-SP foi acertada em escolher o PDF? Pode-se falar em liberdade no contexto da padronização? Conversão ou interoperabilidade?

Quanto à primeira pergunta, se por padrão de mercado entendermos aquilo que estabelece o critério de o formato estar em uso largamente disseminado (ou abertamente disseminado, se incluirmos a 'pirataria' de software), poderíamos citar, além do .doc (e variantes) e .pdf, o .odt, o .rtf e o.html se a diagramação for um componente importante para a escolha (como se pode presumir do contexto, o que excluiria o mais disseminado de todos os formatos em uso para documentos textuais, que é o txt, baseado na mais universal das codificações para caracteres em binário, que são as extensões ISO ou UTF do código ASCII, e base para os demais citados).

Quanto à segunda pergunta, pelos motivos que expus até aqui, procurei expressar no email 3 a minha opinião de que a decisão da JEF-SP foi sim acertada.

Sobre conversão ou interoperabilidade, pode-se notar que, devido ao critério da base instalada (softwares) de usuários não ter sido determinante para o conjunto de formatos que resultou da decisão da JEF-SP, a conversão passa a ser componente prático para a uso do formato escolhido, para aqueles que sustentam como importante este critério, de manter editores já instalados, ao se verem obrigados a aderir ao padrão.

Doutra feita, analisando o contexto, que indica desnecessidade do uso de editores PDF dada a profusão de conversores sobre todo o espectro de regimes de licença hoje praticados, considero que as duas formas de interoperabilidade (independência de fornecedores de software e WYSIWYG) foram determinantes na escolha do formato PDF como padrão único.

Em relação à liberdade no contexo da padronização, gostaria de lembrar que toda a liberdade que a Internet proporciona, inclusive àqueles hoje assustados com ela, e aos ávidos para cercear nacos dela, emana, advém, decorre e se ergue sobre um acordo para comunicação em uma rede heterogênea de redes de computadores, estabelecido pela escolha, em camadas, de padrões livres e fortemente abertos para a implementação do modelo OSI de rede aberta, a saber, a suíte TCP/IP, comforme controlada pela força-tarefa de engenharia da Internet (IETF).