http://www.pedro.jmrezende.com.br/sd.php > software livre : filosofia

Interoperabilidade com Java e o PJe


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

 

Introdução

Numa lista de discussão sobre informatização do Judiciário e processo eletrônico, uma trilha trouxe à tona os problemas que alguns advogados passaram a enfrentar com a quebra de funcionamento do recurso de assinatura digital em clientes do sistema PJe rodando em plataformas GNU/Linux, depois da atualização para uma nova versão do respectivo software (cliente PJe). Após essa atualização, tentativas de assinar documentos eletrônicos no PJe produziam a seguinte mensagem de erro: Para um desses advogados, Bruno Kussler Marques, que havia se queixado formalmente pedindo solução para um claro erro de programação, o TRT3 respondeu por email saindo-se pela tangente, alegando que "o sistema operacional homologado para o PJe é o Windows, conforme orientado no item 1-CONFIGURAÇÕES BÁSICAS DO COMPUTADOR do Manual do Advogado - versão 1.4.8.2.4".

A interoperabilidade de sistemas de informação complexos entre plataformas computacionais distintas é um desafio difcil, cheio de potenciais armadilhas, e requer boa vontade de todos os envolvidos. E este desafio está na origem da tecnologia escolhida para desenvolver o PJe, a linguagem Java.

Linguagem ou tecnologia?

Num projeto de software desenvolvido em Java, a máxima interoperabilidade possível com os Sistemas Operacionais (SOs) hoje existentes (com suporte) pode ser alcançada, com esforço mínimo, seguindo-se as diretrizes do padrão da linguagem Java, conhecido como Java Standard Reference (JSR). O padrão de referência JSR, através de sua evolução em versões (hoje na 7), é controlado (i.e., especificado e tornado verificável por meio de suítes automatizadas para testes de homologação, a cada nova versão) pelo Java Community Process (JCP), grupo de entidades interessadas do qual o detentor de direitos referentes à marca e à implementação de elementos da linguagem com restrição de direitos (patentário ou autoral) -- hoje a Oracle -- estatutoriamente é apenas um dos participantes, mas que lidera o processo.

O trabalho maior referente a interoperabilidade (entre aplicativos desenvolvidos na linguagem Java, e Sistemas Operacionais sobre os quais estes rodam), o de buscá-la e garanti-la, via homologações, sobre uma gama máxima de plataformas (versões de SO + hardware), é dos comitês técnicos do JCP. Quem licencia os direitos da marca Java para implementar e distribuir um interpretador dessa linguagem, isto é, uma Máquina Virtual Java (JVM), que é o software intermediário capaz de interpretar os comandos dos aplicativos escritos em Java para o SO e o hardware onde estes aplicativos irão rodar, é contratualmente obrigado a implementar um núcleo de classes da linguagem (grosso modo, principais comandos) com comportamento previsível, homogêneo entre todas JVMs, de forma verificável conforme descritos pelo JCP.

Dentre as entidades que licenciam o desenvolvimento de uma JVM, algumas também licenciam, nos mesmos termos contratuais, o desenvolvimento de um kit de ferramentes chamado Java Development Kit (JDK), destinado aos que queiram escrever (desenvolver, programar) aplicativos em Java. Exemplos de tais entidades incluem a Microsoft e alguns projetos de Software Livre com apoio institucional, como o IcedTea e o OpenJava (mais sobre estes aqui). O padrão JSR é aberto, pois a especificação é pública e qualquer um pode participar do JCP (embora a homologação de aderência, quando feita pelo JCP, seja onerosa), e o licenciamento para desenvolver JVMs e JDKs pode ser gratuito, quando as respectivas implementações (de JVM e JDK) se destinam a distribuição sob licença livre (i.e., licença que satisfaça os dez critérios do modelo Open Source Iniciative).

Cabe aqui observar que, como nem todas implementações de JVM e JDK são distribudas sob licença livre, como as da Microsoft por exemplo, e tampouco nem todos os aplicativos escritos com tais JDK, algumas pessoas se confundem a pensar que a linguagem Java em si é "não-livre". Doutro lado, um implementador que escolhe uma JDK para desenvolver seu aplicativo em Java (inclusive para terceiros, como no caso do PJe) pode receber, por transitividade, como valor agregado à licença de uso da JDK utilizada, a garantia de que os aplicativos a serem desenvolvidos com ela vão poder rodar sem problemas em qualquer plataforma JVM (JVM + SO + hardware) homologada como aderente ao padrâo JSR. Todavia, a extensão desse valor agregado depende, na prática, de três fatores:
  1. Da compatibilidade de versões da linguagem Java (entre a da JDK, usada para desenvolver o aplicativo, e a da JVM, usada por clientes desse aplicativo para rodá-lo)
  2. Da aderência de ambas -- 2.1) a JDK, e 2.2) a JVM -- ao padrão JSR; e finalmente,
  3. À disciplina do desenvolvedor do aplicativo, para, caso queira usufruir desse valor agregado, durante a escrita desse aplicativo ater-se a empregar somente comandos e recursos que fazem parte do núcleo da linguagem homologado pelo JSR.

E os competidores/concorrentes?

Quando a Microsoft, tendo dormido no ponto, na década de 90, quanto ao futuro da Internet (seu fundador chegou a dizer, numa entrevista em 1995, que não acredita[va] em "coisa" que "não tenha dono"), finalmente percebeu a vantagem competitiva, numa rede aberta (como é a Internet), do valor agregado à opção de desenvolvimento de aplicativos em plataformas com tais caractersticas de interoperabilidade (tipo JDK + JVM + JSR, conhecidas no jargão de marketing como "write once, run everywhere"), contratou junto à Sun (detentora dos direitos do Java à época) licença para implementar a linguagem Java (JDK + JVM), mas descumpriu a cláusula de implementação obrigatória do núcleo de comandos-padrão, que viabiliza a interoperabilidade downstream (aquela entre aplicativos desenvolvidos no JDK licenciado, a msJDK, e outras JVM, prometida pela "marca Java", a qual supõe aderência da JDK ao JSR). Promessa que aí falhou, pois certos comandos principais foram implementados na msJDK com comportamento ou sintaxe diferentes das descritas no padrão JSR.

Enquanto arrastava os pés no impasse resultante da falta de homologação JSR por esse motivo, e depois, na ação judicial em que foi ré por quebra de contrato, a Microsoft foi reduzindo a extensão desse valor implicitamente agregado à marca Java (interoperabilidade), na medida em que distribuía seu "produto Java" (msJDK + msJVM) matreiramente torto e manco (para as JVMs de terceiros), enquanto este contaminava o ecossistema Java com a disseminação de aplicativos que só funcionam direito em plataformas do mesmo fornecedor, nas duas pontas (msJDK e msJVM + windows). Ou seja, usando sua posição de mercado, a ré foi contaminando o ecossistema Java com desvalorização progressiva da sua prometida/esperada interoperabilidade, na medida em que tornava inócuo, com a disseminação do seu "produto", o esforço de terceiros no fator 3) descrito acima, uma vez que o fator 2.1 ela sabotava sorrateiramente, com sua capacidade de penetração no mercado de TI.

E quando finalmente, depois de três anos de litígio, admitiu a culpa e aceitou pagar menos de dois bilhões de dólares por danos decorrentes da quebra contratual, a Microsoft já havia conseguido degradar significativamente o valor da marca Java, enquanto emplacava seu produto licenciado, torto e manco para terceiros, com penetração e "vantagem" equivalentes (com seus SO) às de seu nativo produto não-livre: a plataforma dot net. Num mercado altamente competitivo e sujeito ao efeito-rede, onde o ciclo de inovação é muito rápido e a vantagem do pioneirismo é crucial, por tal prática anticompetitiva, por abuso de sua posição monopolista (com seus SO), ou a rigor quase (pois existem SOs livres) mas capaz de inviabilizar o "core business" de um competidor emergente e semiologicamente mais sofisticado, esta pena foi uma pechincha. Porém, isso foi em 2001: agora, em 2015, para quem souber ler nas entrelinhas das revelações de Edward Snowden e seus potenciais desdobramentos, o jogo se tornou incomensuravelmente mais brutal.

E o PJe?

Comecei descrevendo tudo isso para leitores e usuários poderem entender a razão mais ponderável na escolha da linguagem Java para o desenvolvimento de um sistema como o PJe. E também para poderem melhor avaliar possíveis consequências indiretas de um menor esforço dirigido à intraoperabilidade, no desenvolvimento de sistemas como esse. Voltemos então para o problema em tela. O problema -- quebra do assinador do cliente PJe em plataformas GNU/Linux, após uma recente atualização do PJe -- parece ter surgido de um "kludge", ou "marreta" no jargão dos programadores brasileiros. Ou seja: a quebra teria surgido com uma solução canhestra, "na marra", para um problema ou dificuldade de implementação, na atualização em questão.

Isto é o que parece indicar a mensagem de erro relatada (tentativa de escalada de privilégios por um comando do aplicativo-cliente, para acesso a um recurso crítico, de conectividade em rede aberta, no sistema operacional). E também pelo sintoma (quais sistemas operacionais bloqueiam essa imprudente tentativa de escalada de privilégios): pois esse tipo de "marreta" acabou se tornando um vício comum entre os que programam em ambiente windows, mas que vem sendo implacavelmente cerceado na arquitetura de segurança interna do kernel Linux (devido à filosofia de design desse kernel). Tal "solução" teria, assim, quase certamente violado também a disciplina de programação necessária à interoperabilidade do Java (aquela de se ater a comandos que fazem parte do núcleo especificado na JSR, quando a operabilidade em distintas plataformas é desejável).

Se for este o caso, o problema, que é de segurança para qualquer cliente advogado que assina documentos no PJe, poderia ser resolvido com algum conhecimento mais geral de programação em Java. A solução aí dependeria apenas de uma combinação de boa vontade do gestor do projeto, e competência de algum programador. Porem, há sinais contraditórios para a expectativa de haver tal combinação disponível, na resposta evasiva e reiterada pelos Tribunais notificados: "o sistema operacional homologado para o PJe é o Windows", e ponto final. Enquanto uma marretada no PJe produz o efeito colateral de limitar seu funcionamento a plataformas onde o sistema operacional é seletivamente penetrável, conforme o interesse de seu fornecedor em instrumentar infraestruturas globais de vigilantismo para fins políticos, exposto em projetos como o PRISM. Por que só um SO, quando a principal razão para se escolher Java, é a de poder evitar tão questionável limitação? E eu acrescentaria, estrategicamente perigosa limitação, para um projeto institucional com o perfi do PJe, num contexto geopolítico cmoo o de hoje.

Qualquer esperança de se ver restaurada a interorerabilidade do PJe, que foi quebrada no -- e não pelo -- GNU/linux, repousa agora num jogo de empurra envolvendo a OAB e canais de comunicação obstruídos entre interessados e desenvolvedores, jogo este que não produziu nenhum resultado satisfatório em mais de nove meses. No subsequente e intermitente debate naquela lista, no qual se procurou manter essa esperança, várias justificativas para o status quo do PJe foram tentadas. Desde acusações de que os interessados nessa interoperabilidade (ou nas razões para sua quebra) estariam "construindo teorias da conspiração", a partir de um simples problema de atualização com incompatibilidade temporária no Linux, ou a partir de supostos ataques do lobby monopolista no mercado de TI que cobiça o filão desse projeto (formado por empresas que não conseguiram contrato de terceirização do PJe), até atenuantes baseados em reducionismo econômico, que desdenha a transparência no desenvolvimento de projetos desse porte como "sonho".

Como avaliar riscos com sistemas informáticos?

Como colaborador convidado naquela lista, procurei esclarecer o motivo da minha particiação naquele debate, reiterado nesta manifestação pública desfulanizada. É impossível descrever a natureza e o potencial de danos associados a riscos cibernéticos sem se referir a possíveis intenções escusas e ocultáveis com potencial para operar, interna ou externamente, no contexto de projetos como esse. Portanto, a forma mais eficaz, e talvez a única, para gestores de qualquer projeto do perfil do PJe afastarem críticas competentes, incluindo as que conotem referência negativa "à probidade ou competência das pessoas que trabalham no projeto", é adotar uma postura distinguível de um óbvio diversionismo obscurantista. Em contrapartida, o risco de um tal conselho ser mal recebido, é um risco que qualquer especialista em segurança computacional competente precisa correr se quiser ser também honesto e útil.

No caso em tela, bastaria ao gestor expor, com franqueza verificável, os fatos e demandas que levaram à decisão de atualizar assim, com uma imprudente escalada de privilégios no código. Com uma "marretada" que ficou exposta, após setembro de 2014, ao quebrar a interoperabilidade do PJe em plataformas minoritárias. Porém, quebrada justamente com clientes que buscam melhor proteção, contra vários tipos de risco cibernéticos, optando por um sistema operacional cuja arquitetura e modelo negocial privilegiam sua autonomia. Quais os objetivos específicos de funcionalidade que se agregam ao PJe com tal decisão? Se, para alcançar tais objetivos, houver opção técnica que evite a escalada de privilégios hora exposta, ao alcance da compreensão dos críticos mas ainda fora do crivo dos desenvolvedores, meio caminho andado. Mas se uma tal opção já foi proposta e vetada por gestores do projeto por razões não técnicas, que o debate então evolua de nível, para enquadrar a relação custo/beneficio entre as opções conhecidas, ou a renúncia às ideais se inexistirem, ou perante objetivos maiores, de longo prazo para o projeto.

Estamos aqui diante de um caso de dissonância cognitiva, que, infelizmente, são comuns em projetos de TI desse porte. Se originalmente o do PJe tinha, entre seus objetivos, o de ser um projeto de software livre, ou agnóstico em relação a plataformas (via "promessa" da marca Java), tais objetivos foram sendo abandonados, sendo hoje nele irreconhecíveis. Ainda mais agora, com essa resposta à queixa dos que desejam, pelo menos, a volta da interoperabilidade com sistemas operacionais livres. Com essa pseudo-resposta na qual o motivo técnico para a citada quebra, uma escalada de priviláegios que expõe perigosamente, em rede aberta, o aplicativo com o qual clientes do PJe precisam assinar digitalmente documentos de valor jurídico, é solenemente ignorado. Ofuscado por uma restrição na n-ésima edição de um manual de usuário que vem sendo "atualizado" em cinco níveis de versionamento: a de que o PJe é homologado só para o windows, conforme o item "CONFIGURAÇÃO BÁSICA DO COMPUTADOR" da versão 1.4.8.2.4. Sem ninguém explicar por que essa nova restrição surge num projeto em Java.

Software livre com código-fonte fechado é oxímoro, e agnosticismo quanto a plataformas é, com Java, uma questão de disciplina na programação. A experiência da engenharia de software nos mostra, com exemplos ao longo da história, que projetos de tal porte tendem a "se frustrar" (p.ex., explodindo orçamentos) quando a mutação de seus objetivos ocorre em ritmo ou em saltos maiores que os da maturação do seu desenvolvimento. Ou ainda, com projetos grandiosos demais para seu tempo, que estes tendem a morrer, ou a transmutar para menor, quando sua maturação não consegue acompanhar, asfixiada por complexidade, o ritmo da evolução da TI, porquanto as tecnologias disponíveis para implementação ou migração carecem ou obsolecem. O preço é cobrado com juros de complexidade crescente, geralmente combatida com versionamento, que pode acabar realimentando-a na manutenção. Como em casos onde um reles manual de usuário chega a cinco níveis de versionamento! Em tais situações, quebras, restrições ad hoc ou coisa pior tendem a aparecer, pois a sonegação aí resulta em crescente inundação de bugs.

Colaboração versus planejamento

Minha particiação naquele debate teve, desde o início, o condão de incluir este cenário no contexto técnico da discussão do problema. Para uma melhor aferição das condições que teriam levado programadores do PJe a lançar mão de recurso tão drástico e perigoso. Diria até desesperado, considerando o perfil funcional do PJe. Visava um diagnóstico de causas condizente com o sintoma descrito pela mensagem de erro relatada. Se a OAB só pôde entrar para colaborar no projeto tardiamente, isso em si não seria um problema correlato. Poderia até ser parte de uma eventual solução, caso tenha entrado para antes cobrar mais transparência de sua gestão, ao longo do seu desenvolvimento. Ou, se para contribuir na abertura ou desobstrução de canais de comunicação direta entre desenvolvedores e os chamados power-users (usados também no mundo dos softwares não-livres, ali chamados de beta-testers). A OAB estaria aí contribuindo para catalizar a maturação desse desenvolvimento, o que faria todo o sentido, pois, afinal, dentre os power-users do PJe há muitos profissionais cuja classe ela representa.

Mas se a OAB estiver entrando com intento apenas, ou principal, de ampliar os objetivos do projeto, de expandi-los com base em ambições incompatíveis com o estágio atual de sua maturação (relativa aos principais objetivos iniciais), e o alto escalão da gestão do projeto gostar da ideia, este pode se sentir justificado em agir, com licença da metáfora, como se estivesse mexendo nas traves do campo durante o jogo. Introduzindo objetivos novos e mais amplos, e alterando suas prioridades, com a bonde do jogo andando. Quando isso acontece (não seria a primeira vez, nem a última em grandes projetos de TI), o caos, a ansiedade ou o pânico tendem a se instalar nos escalões mais baixos, onde desenvolvedores e programadores respondem pelo cumprimento de prazos e metas -- inclusive orçamentráias -- que costumam ser balizas contratuais para a execução de projetos terceirizados para desenvolvimento de software in house.

A julgar pelo farto material histórico relativo a outros grandes projetos (incluindo minha esperiência como testador de software na Apple Computer), sabemos que esse tipo de situação é capaz de levar programadores a medidas extremas (pense agora na analogia da "marreta"). Nos níveis mais abaixo, sob pressão para "cortar cantos", seus ocupantes empurrarão o bonde da programação na forma que lhes for possível. A ponto de fazerem coisas imprudentes, tais como escaladas de privilégios onde isso for "aceito" (pense no windows). A do nosso caso restou ofuscada, por não menos de oito meses, por uma nova restrição-surpresa: uma impromptu "homologação" só para windows, comunicada através do quinto nível de versionamento em um manual de usuário. Seria irresponsável da minha parte cogitar tal hipótese de diagnóstico sem mais sinais que a corroborassem. Eis então que uma matéria postada naquele debate -- sobre colaboração da OAB com o CNJ para o desenvolvimento do PJe -- transmitiu-me sinais suficientes, motivando-me a escrever este artigo.

É bem provável que minhas preocupações tenham sido ali, ou sejam alhures, mal compreendidas. Acredito, sim, na competência dos programadores que implementam o PJe: caso contrário, eles não permaneceriam num projeto de tal porte. Acredito a ponto de ser capaz de imaginar como eles se justificariam para si mesmos, numa tal situação hipotética; Sabendo das consequências nefastas de uma pressão velada para se cortar cantos, se os chefes e gestores não os querem ouvir, ou fingem que não os entendem, a respeito dos potenciais efeitos colaterais dessa toada no futuro, estando estes mais ocupados em mudar as traves de lugar no meio do jogo do projeto, é natural que os programadores deixem então as queixas ao encargo da plateia de usuários finais. Vindo deles, as de que seu time está se sentido "tungado" nesse jogo. No fim, em tese pelo menos, haverá o que tocar de responsabilização para todos, embora quase sempre mais para os "de baixo" e os "de fora".

Segurança de quem, contra o que?

A justificativa oficial para não se abrir o código-fonte do PJe, segundo o CNJ, seria o receio com "a segurança" ... segurança, sim, mas, de quem, e contra o que? Segurança significa diferentes coisas para diferentes atores, e em diferentes situações. Em projetos de TI de grande porte, conflitos entre interesses concomitantes e legítimos abundam (do ponto de vista da segurança computacional, como a entendo, isto é justamente o que caracteriza um sistema de porte ou perfil complexo). Para gestores do projeto, pode ser sinônimo de controle, no sentido de quanto mais na mão deles, mais "seguro" (e isso não é nenhuma referência a quantias de probidade, e/ou de competência, e/ou de distorções na autoimagem neles; isso é referência à natureza humana). Para o usuário/cliente, pode ser várias outras coisas, primordialmente exposição a riscos em níveis que ele considere aceitveis. Então, esse tipo de justificativa simplória para não se abrir o código-fonte Java desse projeto, só acescenta à respectiva dissonância cognitiva.

A citada matéria, que me motivou, fala de expansão nas funcionalidades do PJe como fruto da colaboração entre OAB e CNJ. Trata-se de uma expansão que deve permitir a um cliente advogado integrar, numa mesma interface do cliente PJe, suas conexões e interações com diversos Tribunais que usam o PJe. Supondo, com base em debates técnicos anteriores naquela lista, que cada Tribunal tenha sua própria base de dados referente a processos, controles, juízes e advogados nele atuantes, a forma tecnicamente adequada de se implementar tal tipo de expansão -- do ponto de vista de uma segurança para usuários/clientes em rede aberta minimamente defensável, de em sistema cuja função social é judicatva -- mesmo com autenticação via certificado X-509 emitido sob o regime da ICP-BR --, seria, a meu ver, através da opção tecnológica conhecida pelo nome de "federalização", ou de "rede federada".

Ocorre que a matéria citada fala também de prazos, os quais são claramente exíguos para a curva de aprendizado de um desenvolvedor que tenha entrado no projeto sem a especificação inicial de ter que integrar, com o bonde andando, a plataforma do cliente às redes corporativas de vários Tribunais servidos. Especialmente para autenticação precípua dos seus usuários/clientes mediante controles internos e externos. Tal situação é a que suponho estar sendo apontada pela contextualização da mesma matéria em discussões anteriores, na mesma lista, sobre origem e fases iniciais do projeto PJe. Sendo que a matéria fala ainda de prazo ainda mais exíguo, e fixo, "para testes", sem dar mais detalhes.

Numa tal situação, o caminho óbvio que caberia a um prudente desenvolvedor terceirizado, mesmo a um que já tenha domínio sobre a implementação de sistemas em rede federada, será o de cortar cantos, devido principalente a prazos exíguos. Assim, a implementação de um protocolo para autenticação minimamente adequado a tal expansão, que use troca de credenciais criptogrficas entre as redes federadas no sistema conforme algum padrão de segurança específico para o caso, como por exemplo o OpenID, vai sendo ignorado. Ou, empurrado com a barriga. enquanto marretadas semiológicas -- como a tal, que escala privilégios indevidamente -- puderem ir sendo aceitas no seu lugar.

Para finalizar, voltamos à fatídica questão sobre abertura do código-fonte. Com o perdão de uma última metáfora, código-fonte é como roupa de baixo: ninguém gosta de mostrar o seu; a menos que esteja limpa e na moda. Aguardemos então os desdobramentos.



Autor

Pedro Antonio Dourado de Rezende professor concursado no Departamento de Ciência da Computação da Universidade de Brasília. Advanced to Candidacy a PhD pela Universidade da California em Berkeley. Membro do Conselho do Instituto Brasileiro de Política e Direito de Informática, ex-membro do Conselho da Fundação Software Livre America Latina, e do Comitê Gestor da Infraestrutura de Chaves públicas Brasileira (ICP-BR), entre junho de 2003 e fevereiro de 2006, como representante da Sociedade Civil. http://www.pedro.jmrezende.com.br/sd.php

Direitos do Autor

Pedro A D Rezende, 2014 (revisado em 2022): Este artigo é publicado no portal do autor sob a licença disponvel em http://creativecommons.org/licenses/by-nc/2.5/br/