http://www.cic.unb.br/~rezende/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 thread trouxe à tona os problemas que alguns advogados passaram a enfrentar com a quebra de funcionamento do recuso 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 para o 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 difícil, 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 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) 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, que lidera o processo.

O trabalho maior referente a interoperabilidade (entre aplicativos desenvolvidos na linguagem e SOs em uso), de buscá-la e garanti-la, via homologações, a uma gama máxima de plataformas (SO + hardware), é dos comitês técnicos do JCP. Quem licencia os direitos da marca Java para implementação de um interpretador dessa linguagem, ou seja, uma Máquina Virtual Java (JVM), que é o software intermediário capaz de interpretar os comandos do aplicativo para o SO e o hardware onde esteja instalado, é contratualmente obrigado a implementar um núcleo central de classes (grosso modo, comandos), de comportamento previsível, e verificável conforme descrito no JCP.

Algumas entidades quem licenciam o desenvolvimento de uma JVM (para distribuição a clientes usuários) também licenciam, nos mesmos termos contratuais, o desenvolvimento de uma JDK (Java Development Kit, para distribuição a implementadores de aplicativos). Exemplos incluem a Microsoft e alguns projetos de Software Livre com apoio institucional, como por exemplo 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 desenvolvimento de JVMs e JDKs podem ser gratuitos, quando as respectivas implementações de JVM e JDK se destinam a distribuição sob licença livre (obs: como nem todas essas implementações de JVM e JDK são distribuídas sob licença livre -- i.e., Microsoft --, nem tampouco os aplicativos nela desenvolvidos, 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 (inclusive para terceiros, como no caso do PJe) pode receber, por transitividade, como valor agregado à licença de uso da JDK, a garantia de que os aplicativos a serem desenvolvidos vão poder rodar sem problemas em qualquer plataforma JVM (JVM + SO + hardware) homologada como aderente ao JSR. Entretanto, a extensão dessa garantia na prática depende de três fatores: 1) da compatibilidade de versões da linguagem Java (entre a da JDK, usada para implementar o aplicativo, e a da JVM, usada por clientes desse aplicativo para rodá-lo); 2) da aderência de ambas (2.1- sua JDK e 2.2- JVM do seu cliente) ao padrão JSR, e finalmente, 3) à disciplina do implementador do aplicativo, para, caso queira usufruir desse valor agregado, durante a programação desse aplicativo ater-se a empregar somente comandos e recursos que fazem parte do núcleo da linguagem homologado pelo JSR.

E os competidores?

Quando a Microsoft, tendo na década de 90 dormido no ponto sobre o futuro da Internet (numa entrevista em 1995 seu fundador disse que não acreditava nessa "coisa" porque ela "não tem dono"), finalmente percebeu a vantagem competitiva, numa rede aberta como a Internet, do valor agregado à opção de desenvolvimento em plataformas com tais características (tipo JDK + JVM + JSR, conhecidas no jargão de marketing como "write once, run everywhere"), contratou junto à Sun (detentora dos direitos do Java à época) licenciamento para implementar a linguagem Java (JDK + JVM) mas descumpriu a cláusula de implementação obrigatória do núcleo mínimo de comandos-padrão que viabilizariam a interoperabilidade downstream (a dos aplicativos desenvolvidos na msJDK, a JDK da Microsoft) prometida pela marca (promessa que supõe JDK aderente à JSR). Os comandos faltantes foram implementados com comportamento ou sintaxe distintas.

Enquanto arrastava os pés no impasse resultante da falha na homologação JSR por esse motivo, e depois, na ação judicial em que foi ré por quebra contratual, a Microsoft foi reduzindo no ciberespaço a extensão da garantia implícita no valor agregado pela promessa da marca Java, enquanto distribuía sua JDK matreiramente manca, e essas, contaminavam o ecossistema Java com aplicativos que só funcionam direito com um sistema operacional dela nas duas pontas (msJDK e msJVM). Ou seja, usando sua penetração de mercado, ela foi contaminando o ecossistema Java com a desvalorização progressiva da prometida interoperabilidade na medida em que tornava o esforço 3) inócuo com sua JDK, uma vez que a condição 2.1 se descumpria sorrateiramente. 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, ela já havia conseguido fazer um estrago suficiente no valor da marca Java, e emplacado sua plataforma com penetração e "vantagem" equivalente (a dot net).

Num mercado altamente sujeito ao efeito-rede, onde o ciclo de inovação é rapidíssimo e a vantagem do pioneirismo é crucial, foi uma pechincha por uma clara prática anticompetitiva, via abuso de posição monopolista, para inviabilizar o "core business" de um competidor emergente e semiologicamente mais sofisticado. Mas isso foi em 2001: agora, para quem souber ler nas entrelinhas das revelações de Snowden e seus desdobramentos, o jogo se tornou incomensuravelmente mais brutal.

E o PJe?

Tendo descrito isso, para que leitores e usuários possam entender por que a escolha da linguagem Java para o desenvolvimento de sistemas como o PJe, e quais podem ser as consequências indiretas do menor esforço para intraoperabilidade de sistemas como esse, voltamos ao problema em tela.

O problema (quebra do assinador do cliente PJe em sistemas gnu/linux) parece ter surgido com um "kludge" -- ou "marreta", no jargão dos programadores brasileiros --, ou seja, uma solução canhestra para um problema de programação, durante a atualização em questão; Isto é o que parecem indicar tanto a mensagem de erro relatada (tentativa de escalada de privilégios por um comando da JVM, para acesso a algum recurso do sistema operacional), quanto o sintoma (em quais sistemas a tentativa de escalada é bloqueada e a mensagem de erro que é gerada). Pois esse tipo de marreta acabou se tornando vício comum entre programadores em ambiente windows, mas vem sendo implacavelmente cercado na arquitetura de segurança interna do kernel linux (devido à filosofia de design desse kernel). Essa "solução" teria, assim, quase certamente violado a disciplina de programação necessária à interoperabilidade do Java (a de ater-se a comandos que fazem parte do núcleo especificado na JSR).

Se for este o caso, o problema poderia ser facilmente resolvido com alguma conhecimento mais geral de programação em Java. A solução do problema dependeria, neste caso, apenas de uma combinação de boa vontade e competência de algum programador. Porem, há sinais contraditórios à expectativa de haver tal combinação disponível para resolver esse problema, na resposta evasiva reiterada por outro Tribunal: "O PJe não é homologado para o sistema linux", e ponto final. Enquanto a marretada aplicada 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, costuradas em projetos como o PRISM. Qualquer esperança de se ter reparada a interorerabilidade do PJe quebrada no GNU/linux repousa agora num jogo de empurra, envolvendo OAB e canais de comunicação obstruídos entre interessados e desenvolvedores, que não produziu nenhum resultado satisfatório em mais de nove meses.

No intermitente debate subsequente naquela lista, que procurou manter essa esperança, várias justificativas para o status quo do PJe foram ventiladas. Desde acusações de que os interessados nessa interoperabilidade (ou nos motivos para sua quebra) estariam construindo uma teoria da conspiração, a partir de um simples problema da atualização do java e de incompatibilidade temporária com o Linux, ou algo associado a ataques do lobby monopolista no mercado de TI que cobiça o filão desse projeto (empresas que não conseguiram o contrato de terceirização do PJe), até atenuantes baseados em reducionismo econômico, que desdenha a transparência no desenvolvimento de projetos dessa envergadura como "sonho".

Como avaliar riscos com sistemas informáticos?

Como colaborador convidado naquela lista, procurei esclarecer o motivo da minha participação naquele debate, reiterada nesta manifestação pública em forma de quase debate. É impossível descrever a natureza e o potencial de danos associados a riscos informáticos sem se fazer referência a possíveis intenções escusas e ocultáveis que possam potencialmente operar, interna ou externamente, no contexto ou projeto em análise. Portanto, a forma mais eficaz (e talvez a única) para administradores de qualquer projeto de TI -- principalmente os da envergadura do PJe -- afastarem, diante de críticas competentes, qualquer possível conotação de referencia negativa "à probidade ou competência das pessoas que trabalham no projeto", é adotar uma postura que seja distinguível de um óbvio diversionismo obscurantista. Cuja cobrança, em contrapartida, é um dos riscos que qualquer especialista em segurança computacional competente precisa correr se quiser ser também honesto e eficaz.

No caso em tela, bastaria para isso expor, com franqueza verificável (disponibilizando o atual código fonte do PJe para análise), os fatos e demandas concretas que levaram à decisão de programação em favor da escalada de privilégios que, em setembro de 2014, quebrou a interoperabilidade entre plataformas no cliente, e os reais objetivos específicos que se pretendia alcançar com tal decisão. Se houver solução técnica para alcançar tais objetivos evitando-se o problema em tela, ao alcance da compreensão dos críticos mas que ainda não estava ao alcance dos desenvolvedores, ou que foi vetado pelos gerentes do projeto por razões não técnicas, que o debate então evolua de nível, para o patamar da relação custo/beneficio entre as opções possíveis para se implementar tais objetivos específicos, ou renúncia deles diante de objetivos maiores, quais sejam, os de longo prazo do projeto.

Estamos aqui diante de um caso de dissonância cognitiva, que, infelizmente, é comum em todo projeto de TI dessa envergadura. Se o projeto do PJe originalmente tinha, entre seus objetivos ou especificações iniciais, o de ser um projeto de software livre, esse objetivo está sendo abandonado, estando hoje nele irreconhecível. Software livre com código-fonte fechado é figura de linguagem conhecida como oxímoro. Agora, a partir das pseudo-respostas aos questionamentos de usuários que demandam o retorno desta interoperabilidade, informando -- ninguém sabe se é oficialmente ou não, mas vindas do suporte de dois tribunais --, que o projeto (agora) é "homologado só para windows". Ninguém soube ou sabe explicar onde, ou como, surgiu essa nova especificação de projeto, nem tampouco como ela está sendo executada.

A experiência da engenharia de software nos mostra, com fartos exemplos ao longo de toda a história da TI, que o que mais quebra projetos de grande envergadura é a mutação dos objetivos em ritmo ou em saltos maiores que a maturação do seu desenvolvimento. Ainda, que projetos muito ambiciosos para seu tempo tendem a morrer porque o ritmo de maturação não consegue acompanhar o da evolução tecnológica, porquanto as escolhas tecnológicas para implementação acabam caducando. Então, minha participação anterior naquele debate, a partir da notícia que o Bruno postou na lista, foi no sentido de incluir essa possibilidade entre os prováveis diagnósticos para o que poderia ter levado os desenvolvedores a lançar mão de um recurso de programação tão drástico e perigoso, diria até desesperado.

Colaboração versus planejamento

Se a OAB só pôde entrar tardiamente para colaborar no projeto, isso em si não seria necessariamente um problema. Poderia até ser parte das soluções. Se estivesse, por exemplo, entrando para, antes de tudo, demandar mais transparência do projeto ao longo do seu desenvolvimento, para contribuir na abertura ou desobstrução dos canais de comunicação direta entre "power-users" e desenvolvedores (que até no mundo do software proprietário são usados, com o nome de beta-testing), ela estaria certamente contribuindo para acelerar e catalizar a maturação desse desenvolvimento. O que faria todo o sentido, pois, afinal, dentre os power-users do PJe há muitos profissionais da classe que ela institucionalmente representa.

Mas se a OAB estiver entrando com a intenção apenas de ampliar os objetivos do projeto, de expandi-los com grandiloquência incompatível com o estágio atual de maturação do projeto (relativa os principais objetivos iniciais), e a gestão do projeto gostar da ideia, o alto escalão pode se sentir então "justificado" a agir como se estivesse mexendo nas traves do campo durante o jogo. Introduzindo novos objetivos, mais amplos, e alterando suas prioridades, com a bonde andando. Quando isso acontece (não seria a primeira vez, nem seria a última em grandes projetos de TI), o caos e o pânico se instalam no escalão mais baixo, responsável pelo cumprimento de prazos e metas -- inclusive orçamentárias -- que costumam ser marcos contratuais para a execução de projetos cuja implementação é terceirizada.

A julgar pelo farto material histórico relativo a outros grandes projetos, sabemos que esse tipo de situação é capaz de levar programadores a medidas extremas. Um nível mais abaixo, e sob pressão para "cortar cantos", eles irão tocar o bonde da programação na forma que lhes for possível, ao ponto de fazerem coisas tais como a imprudente escalada de privilégios, que ficou camuflada detrás da novidade "homologação só para windows". Seria irresponsável da minha parte aventar aqui essa hipótese diagnóstica para o PJe antes de haver sinais que a corroborassem, mas uma matéria postada naquele debate -- sobre colaboração da OAB com o CHJ para o desenvolvimento do PJe -- encaixou sinais suficientes.

É provável que minhas preocupações tenham sido mal entendidas naquele debate. Acredito, sim, na competência dos programadores encarregados de implementar o PJe: caso contrário, eles não permaneceriam num projeto de tal envergadura. Acredito a ponto de ser capaz de imaginar como esses programadores se justificariam para si mesmos, numa tal situação hipotética; Sabendo das consequências nefastas, para o projeto, dessa pressão para se cortar cantos, se os chefes e gerentes em escalões acima não os querem ouvir sobre os efeitos colaterais futuros dessa toada, estando os gestores muito ocupados mudando as traves de lugar no meio do jogo do projeto, é natural que os programadores deixem então ao encargo da plateia reclamar, quando um dos times se sentir "tungado". No fim, em tese pelo menos, haverá o que tocar de responsabilização para todos.

Segurança de quem, contra o que?

O pretexto 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 é coisa diferente para diferentes atores e em diferentes situações. Em projetos de TI de grande envergadura, conflitos entre interesses concomitantes e legítimos abundam (do ponto de vista da segurança computacional, como a entendo, isto é o que caracteriza um sistema 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 referencia a quantias de probidade e/ou competência neles, isso é referência à natureza humana). Para o usuário, pode ser várias outras coisas, inclusive exposição a riscos em patamar que ele considere aceitável. Então, esse tipo de justificativa simplória para não abrir código, só produz mais dissonância cognitiva.

A citada matéria fala da expansão de funcionalidades do PJe, como fruto daquela referida colaboração. 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, juízes e advogados atuantes, a forma tecnicamente adequada de se implementar esse tipo de expansão -- do ponto de vista de uma segurança minimamente defensável, em rede aberta, para um sistema cuja função social é judicatva --, mesmo com autenticação via certificado X-509 emitido sob o regime da ICP-BR, é 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 num tal projeto sem a especificação inicial de que teria que integrar, com o bonde andando, na plataforma do cliente as redes corporativas dos Tribunais servidos, para autenticação precípua dos seus usuários internos e externos. Situação que suponho estar sinalizada pela contextualização da matéria citada em discussões anteriores daquela lista, sobre origem e fases iniciais do projeto PJe. E a matéria fala também de prazo ainda mais exíguo, e fixo, para "testes", sem mais detalhes.

Numa situação como esta, o caminho óbvio que caberia a um desenvolvedor terceirizado, mesmo a um que já tenha domínio sobre a implementação de sistemas em rede federada, será o de cortar cantos, onde a implementação de um protocolo para autenticação minimamente adequado a tal expansão, que usaria troca de credenciais criptográficas entre as redes federadas seguindo alguma padronização mínima de segurança, como o OpenID por exemplo, vai sendo ignorado ou empurrado com a barriga, enquanto marretadas semiológicas -- como a escalada de privilégios até agora inexplicada e aplicada há nove meses no cliente, e remendos para suas consequências visíveis -- puderem ir sendo aceitas em seu lugar.

Aguardemos os desdobramentos.




Autor

Pedro Antonio Dourado de Rezende é professor concursado no Departamento de Ciência da Com­putação da Universidade de Brasília. Advanced to Candidacy a PhD pela Universidade da Cali­fornia em Berkeley. Membro do Conselho do Ins­tituto Brasileiro de Política e Direito de In­formática, ex-membro do Conselho da Fundação Softwa­re Li­vre América Latina, e do Comitê Gestor da Infraestrutura de Chaves Públicas Brasileira (ICP-BR), en­tre junho de 2003 e fevereiro de 2006, como representante da Sociedade Civil. http://www.­cic.unb.br/~rezende/sd.php

Direitos do Autor

Pedro A D Rezende, 2014: Este artigo é publicado no portal do autor sob a licença disponível em http://creativecommons.org/licenses/by-nc/2.5/br/