Comentarios preliminares sobre el Real Decreto 4/2010 sobre el Esquema Nacional de Interoperabilidad

03-abril-2010

El 29 de enero de este año se publicó en el BOE el Real Decreto 4/2010, de 8 de enero, por el que se regula el Esquema Nacional de Interoperabilidad en el ámbito de la Administración Electrónica.

Interoperabilidad

Este RD 4/2010 es doblemente interesante. Primero, respecto de su principal objetivo, que es de determinar los criterios de seguridad, normalización (estandarización) y conservación de la información de los sistemas informáticos de la Administración Pública, con el objetivo de asegurar la “interoperabilidad organizativa, semántica y técnica de los datos, informaciones y servicios”. Por lo que el RD establece un marco regulador más detallado para el Esquema Nacional de Interoperabilidad, implementando la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los servicios públicos (LAECSP).

Como dice el mismo Decreto, la interoperabilidad es “la capacidad de los sistemas de información y de los procedimientos a los que éstos dan soporte, de compartir datos y posibilitar el intercambio de información y conocimiento entre ellos”. Y para ello, el RD establece criterios comunes, entre ellos el uso de estándares abiertos, arquitecturas modulares y multiplataformas, y la publicación de inventarios de información administrativa y de modelos de datos de intercambio, el uso de firmas electrónicas interoperables, etc.

Estándares abiertos
En esta parte del RD, de interés es la obligación – en casi todas las circunstancias, y quizá aquí falla - de usar estándares abiertos, por ejemplo para la documentación y los servicios, y en condiciones no discriminatorias. El uso de estándares no abiertos se limitará a los casos en los que “no se disponga de estándar abierto que satisfaga la funcionalidad satisfecha por el estándar no abierto en cuestión y sólo mientras dicha disponibilidad no se produzca”. Es decir, parece haber un progreso desde la posición anterior (el uso de estándares abiertos así como los “que sean de uso generalizado por los ciudadanos”), porque el nuevo marco delimite las circunstancias de uso de aquellos que no sean abiertos.

La definición de estándar abierto (siempre un tema de debate) recoge la establecida por la LAECSP: “aquel que reúna las siguientes condiciones: (a) sea público y su utilización sea disponible de manera gratuita o a un coste que no suponga una dificultad de acceso, y (b) su uso y aplicación no esté condicionado al pago de un derecho de propiedad intelectual o industrial.” No es lo ideal, ya que se argumenta que un estándar abierto requiere también que haya habido transparencia y participación en el proceso de estandarización, pero por lo menos no se habla de condiciones “RAND” (acceso razonable y no discriminatorio).

Habremos de ver exactamente cómo se implementará en la práctica.

Liberación y reutilización de programas
El otro elemento interesante de este Real Decreto (más interesante para mí, desde una perspectiva del software libre), es el capítulo VIII “Reutilización y Transferencia de Tecnología”. Este capítulo desarrollo los artículos 45 y 46 de la LAECSP, así como las Disposiciones Adicionales 16 y 17 de la Ley 56/2007, de 28 de diciembre, de Medidas de Impulso de la Sociedad de la Información (LISI). Básicamente, confirma la posibilidad para la Administración Pública de liberar aplicaciones bajo licencias de software libre (o “de fuentes abiertas”) y en qué condiciones. Pero agrega unos detalles adicionales interesantes.

La LAECSP confirmaba la posibilidad de compartir entre Administraciones, sin necesidad de convenio, los programas de ordenador de su titularidad (no hablamos de programas de terceros); así como la posibilidad de declararlas “de fuentes abiertas”. Este Real Decreto especifica las condiciones bajo las cuales las AA.PP. podrán liberar estas aplicaciones.

Primero, el objetivo de cualquier liberación será el aprovechamiento y reutilización de las aplicaciones (en el contexto del ENI, se entiende ya que el uso de una misma aplicación por dos administraciones garantiza la interoperabilidad de los datos y sistemas). Éste es también uno de los objetivos del movimiento de software libre.

Un segundo objetivo es proteger el programa contra su “apropiación en exclusiva por parte de terceros”. Leer, “usar una licencia copyleft”. Esto está reforzado por el artículo 16.2, que enumera los derechos que la AP deberá asegurar, incluyendo

  - Ejecutar el programa para cualquier propósito (un derecho de uso sin discriminación)

  - Conocer su código fuente (la distribución no puede ser solamente de forma binaria)

  - Modificarlo o mejorarlo (el derecho de transformación)

  - Garantizar que se pueden redistribuirse a otros usuarios con o sin cambios siempre que la obra derivada mantenga estas mismas cuatro garantías (el derecho de reproducción, transformación y distribución o comunicación pública, pero sujeto a condiciones que llamamos “copyleft”)

Este último criterio obligará por lo tanto a la Administración a usar una licencia copyleft, que establece que el destinatario/licenciatario del código deberá utilizar la misma licencia o una similar y compatible en el caso de redistribuir el programa o una transformación o mejora (obra derivada) del mismo. Garantiza por lo tanto la “libertad” del código en todo momento.

Actualmente, podemos pensar que las licencias GPL, CPL, Eclipse PL, Mozilla PL, OSL y LGPL (y otras del mismo estilo, en sus distintas versiones) cumplen con este criterio: todas tienen un grado de copyleft sobre el código liberado y sus obras derivadas (pero con diferentes alcances en cuanto a obras compuestas que incluyan este código, u obras que utilicen este código... debate en el que no entraremos aquí).

En el apartado 3 del mismo artículo 16, el RD establece que “se procurará” utilizar la Licencia Pública de la Unión Europea (que conocemos bajo las siglas EUPL), sin perjuicio de otras licencias que garanticen los mismos derechos. Es decir, la preferencia será para la EUPL, pero la Administración podrá usar otra con copyleft, como por ejemplo la GPL (como lo hace la Generalitat para la suite “EinesTIC”). La EUPL 1.1 es una licencia redactada por encargo de la Comisión Europea para la liberación de aplicaciones de la Comisión, así como cualquier otra aplicación. Es reconocida “Open Source” por la Open Source Initiative. Se adecua más al marco legal “europeo” y tiene un anexo de licencias con copyleft expresamente compatibles, incluyendo la GPLv2, la OSL 3.0, Eclipse/Common PL y la licencia francesa CeCILL (permitiendo el uso de este software EUPL en o por aplicaciones bajo estas licencias).

La idea de usar una licencia copyleft parece ser la de asegurar que si alguien utiliza un código liberado por la Administración, por ejemplo para crear una aplicación mejor o más completa, no podrá “venderlo” de nuevo a la Administración (siempre que sea una obra “derivada”): deberá volver a distribuir esta mejora (a la misma Administración o a cualquiera) bajo los términos de una licencia libre/de fuentes abiertas.

Aunque entienda estos objetivos, no comparte necesariamente esta filosofía: con una licencia permisiva, el código de la Administración siempre estará a disposición del público, por lo que nadie podrá “apropiarse” del código liberado. Pero es cierto que esto no garantiza necesariamente que las obras derivadas (mejoras, adaptaciones, etc.) de este código estén disponibles. Sin embargo, liberar un programa bajo licencia copyleft también podrá ser un desincentivo para consultores y proveedores de soluciones, que podrían ser reacios a trabajar con este código en circunstancias en las que deberán liberar las mejoras (no la parte realizada por la Administración, sino el resultado de sus esfuerzos de mejora o adaptación).

Directorios
Finalmente, el artículo 17 del Real Decreto desarrolla la obligación establecida en LAECSP de crear directorios de aplicaciones (federados a nivel nacional e internacional) para la libre reutilización de las mismas. Se entiende, directorios dentro de la Administración pública – no necesariamente directorios abiertos a todos.

El apartado 3 va más allá que la LAECSP y se establece que las Administraciones públicas deberán “tener en cuenta las soluciones disponibles para la libre reutilización que puedan satisfacer total o parcialmente las necesidades de los nuevos sistemas y servicios o la mejora y actualización de los ya implantados”. Entiendo entonces que antes de contratar una nueva solución o la mejora de una existente, la Administración deberá consultar estos directorios para ver “lo que hay”. ¿Deberán también consultar repositorios abiertos como Sourceforge, Freshmeat or Google Code? Será interesante ver cómo se implemente esta obligación: qué procesos internos se establezcan. Además, ¿se podría atacar una decisión de una Administración de comprar un software no libre (o un desarrollo que utilice sistemas no libres - sistemas operativos o bases de datos), porque existen otros libres con iguales prestaciones, que “no han tenido en cuenta”?

Finalmente, en el apartado 4, otra novedad: las Administraciones deberán procurar la publicación del código de las aplicaciones, en desarrollo o finalizadas, en los directorios de aplicaciones para su libre reutilización, “con el fin de favorecer las actuaciones de compartir, reutilizar y colaborar, en beneficio de una mejor eficiencia”. La publicación de aplicaciones finalizadas (¡aunque una aplicación es raramente “finalizada”!) y que tengan cierta estabilidad y niveles de seguridad y certificación tiene sentido, en la línea de los apartados anteriores.

Lo que es interesante es la publicación del código en fase de desarrollo: esta apertura del proceso de desarrollo a las demás administraciones parece ser una forma de incentivar la implementación del modelo de desarrollo del software libre (un desarrollo abierto, progresivo, incremental, modular) en la administración pública. Mediante ello, otras administraciones podrán descargar el código publicado y comenzar a hacer sus versiones y mejoras. No se especifica si el directorio deberá contar con herramientas de controles de versiones, gestión de Bugs, y procesos de “commit” para terceros, para que otras administraciones puedan participar en el desarrollo. De nuevo, debemos esperar para ver cómo funciona este sistema, sobre todo por ejemplo en los casos en los que una entidad privada, proveedor de la Administración, sea la encargada de gestionar el desarrollo de la aplicación, y cómo se realizará la gestión de los riesgos y responsabilidades.

Conclusiones
En resumen, aunque el Real Decreto no establece ninguna “preferencia” para la adquisición de productos basados en software libre / de fuentes abiertas, sí propone unas mejoras bases para su uso dentro de la Administración y sobre todo para la reutilización y hasta liberación de las aplicaciones de las AAPP. ´╗┐



Tecnologias de la informaci├│n