No tenía planteado asistir a este evento, pero un aviso del FT en su blog me decidió a asistir a un Foro organizado por la Fundación GNU Chile, sobre la postulación como Formato ISO del OOXML de Microsoft, y que se realizó este martes 15.
Si les interesa entender a que refiere este tema del OOXML, por favor lean los excelentes artículos del blog El Diablo en los Detalles titulados Chile y OOXML. Crónica de un voto anunciado. Y no crean que el tema no les toca, por que si escriben cualquier documento en un PC, entonces si les toca…

A continuación les presento los apuntes que extraje del Foro, para quienes estén interesados en saber lo que allí se dijo. Me disculpo por lo rudo del lenguaje, y los errores que puedan tener. Pero no tuve tiempo para realizar una investigación complementaria y aplicar corrección de estilo.

El Foro comenzó con representantes de la DCC que nos dan la bienvenida al evento. Ellos nos explican que el sentido de éste responde a que, puesto que Microsoft presentó en la misma DCC su posición sobre la postulación del OOXML como estándar ISO la semana pasada, correspondía que hoy se presentara la postura de las empresas que son la contraparte y opuestas al OOXML (Red Hat, Google, Oracle, IBM y otras).

Se presenta al primer expositor que es Avi Alkalay por IBM (Brasil).
Avi es miembro del Grupo de Trabajo numero 2 (la Comisión Espejo de Brasil) quienes realizaron un profundo estudio técnico, durante un casi un año, de las Especificaciones del OOXML.
Avi nos explica que el espíritu con que trabajó este grupo, es que el voto del equipo debe estar fundado principalmente en un estudio estrictamente técnico de la especificación (los brasileños dedicaron mucho trabajo e incluso recurrieron a los análisis de otros países para completar su propio estudio).
Su estudio concluyó con la convicción de que el camino de Microsoft, para implementar su especificación (el llamado Fast Track) es igual a intentar hacer pasar un elefante por una pequeña puerta. Es decir, el Fast Track fue “reventado” para hacer pasar la especificación del OOXML.
Con esto cabría interpretar, en opinión del representante de IBM, que las acciones de Microsoft intentan cambiar el como se hacen los estándares actualmente.

6063 páginas de especificaciones de la OOXML presentadas en el Foro de la DCC (la pila no son copias para repartir, todo es “un solo” documento).

Los hechos:
1.- La especificación del OOXML consta de una extensión de 6063 páginas, las cuales fueron presentadas para ser revisadas en un plazo de 6 meses.
El equipo de Brasil, en estos 6 meses, analizaron 3500 puntos de discusión, los que fueron condensados en 1027 observaciones.
La ECMA (la encargada de presentar la especificación) respondió presentando 2293 páginas con propuestas de cambios.
Así, sólo se dispuso de 30 días para volver a analizar las 6063+2293 páginas de especificaciones.
Y sólo 5 días para que la reunión de la BRM (reunión técnica) discutiera esas mismas 6063+2293 páginas.
Se supone que el Fast Track es para discutir estándares simples. Cosas sencillas. 6000 páginas no caben en un Fast Track. ¿Cómo el JTC1 permitió que el OOXML pasara por el Fast Track?

Volviendo a la reunión de 5 días del BRM, finalmente sólo el 18% de los problemas advertidos fueron discutidos. Y al final de esos 5 días, el BRM elaboró sólo 12 paginas de resoluciones y correcciones.
Pero esto no es todo, ya que Aviram nos advierte que lo que se supone debe votar cada nación, es decir, las nuevas especificación del OOXML (las 8356 páginas que incluyen todas las correcciones de las indicadas en el informe de la BRM) es un documento que no existe aun. La OOXML no ha sido corregida. Y es probable que no lo sea en el corto plazo, por el gran volumen de trabajo que significa traspasar las correcciones a toda la especificación.

2.- Otro punto discutido es el legal (licencias). La los abogados de la SFLC (Software Freedom Law Center) concluyen (también con un informe), que la licencia del OOXML no es recomendable para desarrolladores de open source.
Nuevo cuestionamiento ¿Por qué la JTC1 no detecto este básico problema legal?

3.- Ya de carácter técnico, algunas de las observaciones apuntan a que no existe en las especificación, “mapping” entre formatos binarios antiguos y el OOXML. Es decir, no hay compatibilidad garantizada entre documentos antiguos y el nuevo formato.

A raíz de todo esto, el equipo de Brasil llegó a la conclusión de:

a) El estándar no puede ser fruto de una votación, sino de un consenso.
b) Se debe realizar un profundo análisis técnico y estratégico a la especificación del OOXML
c) De acuerdo a las propias reglas de la JTC1, un voto SI es posible sólo si la especificación presenta cero problemas.
d)Se concluye que el voto SI realizado en las actuales condiciones obedece a un análisis sólo del tipo político del OOXML y no el que corresponde para un estándar ISO.

En resumen, para lograr un voto SI:
- Se requieren especificaciones técnicamente perfectas.
- No debe haber problemas de propiedad intelectual.
- Se debe asegurar la interoperatibilidad.

Y el caso es que actualmente, las especificaciones de la OOXML tiene 1 o más problemas técnicos. Hay problemas con la propiedad intelectual. Y no esta aún listo para la interoperatibilidad.

Diferentes testimonios e informes de empresas y entidades como RedHat o Google, desaconsejando la adopción del OOXML como estándar.

Las otras intervenciones fueron más breves y correspondieron a Juan Olguín de la empresa EMERGES y Óscar Valenzuela de GNU Chile

Olguín explicó brevemente sobre la participación de EMERGES en el Comité Espejo.
En resumidas cuentas, ellos critican el procedimiento en sí, en torno al tema del OOXML.
Más que acusaciones sobre la forma de delegar de la INN el tema de la especificación a la CCE, los representantes de EMERGES critican de que en Chile no se realizó ningún análisis técnico del OOXML (al menos como se realizó en otros países). En este sentido, Chile actuó con gran irresponsabilidad en su papel para con la votación de estándares internacionales. Acusan de que Chile no tiene los suficientes análisis y resultados que sostengan el votar tanto en un sentido o en otro. Los representantes de EMERGES proponen que Chile se abstenga en su voto, hasta realizar el correspondiente (y profundo) análisis técnico.

Finalmente, Oscar Valenzuela, de GNU Chile, tomó la palabra para, advertir sobre el grado de ambigüedad e indefinición en el ámbito de las licencias de uso, que se involucran en el OOXML.
Como ejemplo, comenta el caso de las licencias de uso de Microsoft, que citan a la RAND-Z como base. El tema es que, en el propio sitio web de Microsoft, no existiría definición clara de que es son las RAND (“reasonable and nondiscriminatory”).

Yo resolví retirarme de la charla después de la clásica ronda de preguntas. Y de las cuales rescato principalmente, la consulta por las consecuencias hacia Chile por la forma de votar en para los estándares ISO sin un estudio serio que avale su postura. La respuesta general fue que, para todos los presentes, fue un acto de gran irresponsabilidad por parte de los representantes chilenos, y que habría quedado en entredicho la imagen de seriedad de Chile (en este tema) frente a los representantes de la comunidad internacional.

Más imágenes del evento en Flickr.

Actualización Nº1 19-03-08:
Link: Postura oficial del DCC sobre ISO/IEC DIS 29500

Actualización Nº2 19-03-08:
Documentos presentados en el foro, disponibles como archivos PDF en el blog “Cultura Libre Universidad de Chile“.

Artículos relacionados:

• Chile mantiene voto de abstención al OOXML (2)