En Febrero de este año, el Poder Judicial de la Nación presentó el proyecto informático de su Plan de Fortalecimiento Institucional, solicitando comentarios del público en general.
Desde Fundación Vía Libre nos hicimos eco de dicha solicitud, acercando lo que esperamos que sean sugerencias mejoradoras del proyecto. Agradecemos los aportes hechos a este texto por Román Gelbort, Beatriz Busaniche, Rayentray Tappa y Federico Heinz.
Resumen
Habiendo revisado en detalle la documentación publicada sobre el proyecto, hemos identificado algunos puntos que merecen ser observados para lograr un mejor resultado final. En términos generales, el proyecto es ambicioso y al menos en su concepto, beneficioso, pero debe prestarse mucha atención a los aspectos de interoperabilidad universal a través de estándares abiertos, a la vez que se reemplazan en el documento las referencias a productos específicos por requisitos funcionales.
Observaciones Puntuales
1.1.1.a Estándares
El documento explicita sobre el software a desarrollar o contratar:
“En aquellos casos en los que se utilicen SW de terceros, los mismos deberán contemplar criterios de conectividad basados en arquitecturas conocidas y estándares del mercado.”
Este requisito es importante, dado que el uso de arquitecturas, formatos y protocolos privativos pone en riesgo tanto la supervivencia a largo plazo del sistema y de los datos en él almacenados, así como su confidencialidad, seguridad e interoperabilidad.
Sin embargo, el requisito de utilizar “estándares del mercado” no es suficiente para resguardar al sistema de estos riesgos: suele entenderse por “estándar del mercado” a cualquier formato o protocolo que esté ampliamente difundido, aún cuando éste no esté completamente documentado ni existan implementaciones de distintos proveedores que compitan entre sí.
Para resguardar los aspectos críticos a la misión del sistema, entendemos que sería más correcto exigir lo siguiente:
“En aquellos casos en los que se utilicen SW de terceros, los mismos deberán contemplar criterios de conectividad basados en arquitecturas conocidas y estándares abiertos con múltiples implementaciones independientes .”
1.1.1.h Accesibilidad del sitio web
El documento prevé facilitar “el acceso a la información de las causas a través del sitio Web del Poder Judicial de la Nación”.
En concordancia con el Plan Nacional de Gobierno Electrónico de la Administración Pública Nacional, Decreto 378/2005, que tiene como una de sus premisas “el acceso a los servicios públicos electrónicos por parte de los usuarios desde cualquier computadora”, es importante que este punto exija lo siguiente:
“Dicho sitio web, y todos los componentes del sistema que se utilicen a través de un navegador, deberán cumplir estrictamente los estándares de la W3C y sus normas de accesibilidad, para permitir que sea accesible independientemente de la marca del computador, el sistema operativo o el navegador que el usuario emplee, así como para permitir el acceso a personas con discapacidades.”
1.1.2.b Escalabilidad
Este párrafo habla de escalabilidad, que es un concepto que puede aplicarse a varias dimensiones. En particular, se refiere a lo que se llama “escalabilidad funcional”, es decir, que el diseño del sistema no tenga límites implícitos al tipo de funciones que pueden agregársele. Para evitar que se confunda con la escalabilidad en volumen de datos y/o usuarios, es conveniente hacer explícito el tema al que se refiere. Sugerimos el siguiente texto:
“Deben ser escalables funcionalmente, lo cual implica que partiendo de un sistema con funcionalidades básicas, debe permitir la agregación de nuevos módulos a medida que los anteriores son incorporados y establecidos como parte de la rutina de trabajo. “
1.1.2.c Código fuente
El documento exige la disponibilidad del código fuente del sistema. Entendemos que este requisito se plantea por la necesidad de mantener la independencia de los proveedores, permitir la auditoría independiente de los programas, y mantener el control del desarrollo futuro y el mantenimiento del sistema.
Lamentablemente, la mera disponibilidad del código fuente no alcanza para estos objetivos: hay ejemplos de programas cuyo código fuente está disponible, pero no existe autorización para modificarlo e instalarlo, o que requieren bibliotecas específicas cuyo código fuente no está publicado. Por ello, creemos que este párrafo debería contar con una redacción más amplia:
“En todos los casos, el titular del código fuente y sus correspondientes derechos de autor de los sistemas desarrollados en el marco de este proyecto será el Poder Judicial de la Nación. De existir componentes del sistema de los que el proveedor desee mantener la titularidad de los derechos de autor, incluyendo bibliotecas, archivos auxiliares o cualquier otro elemento necesario para modificar el sistema, éstos deberán ser entregados al Poder Judicial de la Nación, incluyendo código fuente, bajo una licencia que permita su libre uso, estudio, modificación y distribución. También deberán contar con los respectivos procedimientos de transferencia tecnológica, a fin de viabilizar el mantenimiento directo desde las áreas técnicas del Poder Judicial de la Nación.”
1.1.3 Modelo de desarrollo alternativo
Además de las tres alternativas propuestas en el documento (“Desarrollo Propio”, “Adquisición de un Producto” y “Proyecto Mixto”), existe una cuarta dimensión a considerar, que puede proveer tanto un modelo alternativo como un complemento a cualquiera de las estrategias analizadas: la construcción del software en el marco de un proyecto de software libre, abierto a la participación de individuos y organizaciones interesadas:
Desarrollo Comunitario:
Este mecanismo, que puede ser usado alternativa o complementariamente a los ya planteados, consiste en llevar adelante el proyecto en forma pública, utilizando recursos y metodologías que fomenten la participación en él de personas y organizaciones interesadas.
Ventajas:
- Mayor know-how distribuido: al ser público el código fuente y la historia de desarrollo, se posibilita que haya mayor cantidad de personas dentro y fuera del Poder Judicial que lo conozcan íntimamente.
- Mayor capacidad de mantenimiento y soporte: el conocimiento distribuido acerca del funcionamiento del sistema hace que más personas y empresas estén en condiciones de brindar soporte, desarrollo y mantenimiento para el mismo.
- Potencial de menores costos a largo plazo: los mayores costos de un proyecto de software no son los que ocurren durante el desarrollo, sino durante la mucho más larga etapa de mantenimiento. Al poner el software a disposición de otros organismos con necesidades similares, se vuelve posible compartir este costo con ellos.
- Mejor respuesta de seguridad: al estar abierto el programa al escrutinio público, se vuelve más fácil identificar y corregir problemas de seguridad.
- Posibilidad de no empezar desde cero: al construir un proyecto libre, es posible utilizar en él muchos programas libres preexistentes y que pueden solucionar partes de la problemática.
De hecho,es muy posible que existan sistemas libres de gestión documental que cuenten con gran parte de la funcionalidad necesaria para el sistema propuesto.Desventajas:
Las propias de cada una de las alternativas de desarrollo expuestas, este mecanismo no agrega nuevas.
1.1.4. Licencias de productos
Esta sección hace mención específica de “áreas de cautividad insoslayable” en términos de licenciamiento de software, sin especificar en detalle su naturaleza, ni la razón por la que son insoslayables.
Dada la naturaleza crítica de la administración de justicia, es claramente inaceptable que ésta se encuentre de alguna manera en posición de cautividad de proveedores, de modo que dichas áreas deben ser identificadas y eliminadas en el menor plazo posible.
Creemos que es crucial que el documento contenga un listado detallado de las áreas de cautividad, incluyendo una justificación de por qué son insoslayables, así como una planificación para su eliminación paulatina.
1.3 Seguridad Física y Lógica de la información
Si bien en este apartado se abordan de manera concienzuda los conceptos relacionados con la seguridad informática, los autores del documento parecen haber prestado poca atención a los aspectos de seguridad relacionadas con el origen de los programas, y los riesgos que comporta el uso de programas de funcionamiento secreto e imposible de auditar para la gestión de información tan confidencial como la que administra el Poder Judicial.
Quizás baste, para ilustrar el problema, considerar el conflicto de intereses que surge del hecho de que las mismas empresas proveedoras de los programas en los que se basa el sistema pueden ser actores en causas administradas por éste. Si bien es probable que las empresas no abusen de los privilegios que esta situación les otorga, no es aceptable que la integridad del sistema judicial dependa de la buena fe de los actores sometidos a su accionar.
Otro aspecto a tener en cuenta en esta problemática son aquellas licencias de software que ponen como condición para su aceptación que el usuario autorice al titular de los derechos de autor del programa a transferir datos relativos a la estación de trabajo a servidores propiedad del proveedor. Cuando se trata de estaciones de trabajo en las cuales se procesa información de tal confidencialidad como la del Poder Judicial, tales licencias son claramente inaceptables.
Anexos II y III
En estos anexos, que detallan las licencias que serán necesarias para la ejecución del proyecto, llama poderosamente la atención el hecho de que se haga explícita mención de productos y modos de licenciamiento de empresas determinadas (en particular, Oracle, VMware y Red Hat), sin justificar esta decisión ni dar lugar a la competencia de otras alternativas.
También en el anexo III sería deseable mayor detalle funcional respecto de los requisitos que deben cumplir los programas que caben bajo el ítem “Licencia de Sistemas Operativos y Productos de Ofimática”, teniendo en cuenta aspectos de precio/prestación, soporte a estándares, interoperabilidad y seguridad.