Derrumbar los mitos comunes acerca de Open XML

Mito 1: Sólo debe existir un estándar de documento

Un solo formato de archivo no puede satisfacer las necesidades actuales de los gobiernos, las empresas y los consumidores. Los consumidores deben tener la capacidad de elegir el formato que se adapte mejor a sus exigencias. La innovación y la competición tienen un mayor rendimiento si se permite que el mercado determine el ganador entre los diferentes estándares. El concepto de que el primer estándar que consiga la certificación ISO debe declararse ganador sienta un mal precedente para el desarrollo de los futuros estándares, así como para la competición y la innovación en general.

El mundo ya está repleto de ejemplos de estándares alternativos, incluso en el caso de los que sólo pretenden reunir principios de diseño similares. En el espacio de los formatos de documento, Open Document Format, PDF/A, UOF, HTML y Office Open XML de Ecma compiten de igual forma, independientemente de que uno o todos se ratifiquen finalmente como estándares ISO.

La coexistencia de varios estándares es habitual en la industria de TI actual; éstos, además, ofrecen distintas posibilidades. Por ejemplo, los formatos de imagen digital, como JPEG (hay al menos tres tipos de JPEG, es decir, JPEG, LPEG-LS y JPEG 2000), PNG y CGM (cada uno de los cuales es un estándar ISO), satisfacen diferentes necesidades del mercado. El correo electrónico es otro ejemplo. Existen los formatos X.400, SMTP, POP3 e IMAP; sin embargo, la gente envía correos sin pensar en ello y los usuarios implementan libremente un estándar, según sus requisitos y la forma en que los distintos estándares satisfacen mejor sus necesidades.

Recientemente, se han generado muchos comentarios de los que se desprende que Microsoft y otros miembros de Ecma TC45 deberían haberse incorporado al comité técnico de OASIS para desarrollar ODF, en lugar de crear otro estándar en Ecma. No obstante, Open XML y ODF presentan diferentes principios de diseño subyacentes: Ecma dio mucha importancia a la fidelidad de los documentos de Office heredados existentes, mientras que OASIS se opuso activamente a cualquier principio de diseño relativo a la compatibilidad con versiones anteriores de documentos de Office. Gary Edwards, presidente actual de ODF Foundation y miembro del comité técnico de OASIS que desarrolló ODF, declaró abiertamente que ni Microsoft ni su principio de diseño de compatibilidad con versiones anteriores hubieran sido acogidos en OASIS. Edwards afirmó en una reciente publicación en un blog:

"No es posible que alguien diga que el comité técnico de ODF actual de OASIS acogería a Microsoft y realizaría los cambios adaptadores necesarios en la especificación. De ninguna manera. La prueba de esta hostilidad puede contemplarse en los debates y los rechazos existentes de las propuestas de interoperabilidad específicas de Microsoft".

Siempre han existido estándares superpuestos debido a las ventajas de ofrecer a los consumidores la capacidad de elegir el estándar que se adapte mejor a sus necesidades y fomentar la innovación. Incluso en el dominio de los estándares de documento, existió una plétora de estándares como Open Document Architecture (ODA), DocBook, DSSSL, PDF, etc.; todos ellos son estándares ISO, y su existencia previa jamás supuso un obstáculo para la evolución de nuevos estándares de formato de documento o su coexistencia. Si este principio fuera válido y se aceptase en el campo de los estándares, ODF tampoco debería haberse convertido en un estándar. La innovación constituye el conductor de las nuevas tecnologías y, a medida que éstas ganan terreno, a menudo dan pie a la creación de nuevos estándares.

Mito 2: La especificación de Office Open XML contiene imperfecciones porque se desarrolló de forma aislada

Ecma International es una asociación sin ánimo de lucro de industrias de desarrolladores, proveedores y usuarios de tecnología que presentan trabajos para su aprobación como estándares ISO, IEC, ISO/IEC, y ETSI. Desde su fundación hace 46 años, Ecma ha desarrollado más de 370 estándares, dos tercios de los cuales se han aprobado por la Organización internacional de normalización/Comisión electrotécnica internacional (ISO/IEC).

A modo de "liaison de categoría A", Ecma International tiene una relación especial con ISO, lo que permite que las tres fases iniciales del desarrollo de estándares se produzca en la liaison; confía en la experiencia del comité técnico de ésta para realizar un borrador del estándar y debatir los méritos técnicos de diversos aspectos del estándar propuesto. Los miembros redactaron docenas de comentarios técnicos, que finalmente terminaron plasmados en centenares de páginas de información adicional de la especificación. Nuevamente, esto es muy parecido al proceso de especificación disponible de forma pública con el que se creó y se ratificó la especificación ODF en OASIS, posteriormente enviada a ISO para obtener una aprobación optimizada.

El estándar Office Open XML de Ecma se desarrolló en el transcurso de un año en Ecma International con contribuciones del TC45 (Comité técnico 45 de Ecma), que incluyó compañías de tecnología de la información (Apple, Intel, Novell, Microsoft, NextPage, Toshiba), instituciones gubernamentales acreditadas (la Biblioteca Británica, la Biblioteca del Congreso de Estados Unidos) y usuarios expertos de TI (BP, Statoil, Barclays Capital, Essilor). Aunque Microsoft contribuyó significativamente al desarrollo de Ecma 376, el borrador inicial recibió un desarrollo y un perfeccionamiento considerables mediante el trabajo del TC45 de Ecma, lo que permitió que la especificación creciera de 2.000 a 6.000 páginas (el estándar de Ecma actual).

El número y la duración de las reuniones que celebró el TC45 fueron comparables a las de OASIS en el transcurso del desarrollo de la especificación ODF; Office Open XML no se desarrolló de forma más "aislada" que ODF.

¿Por qué Microsoft no se dedicó simplemente a trabajar con la gente original de ODF para crear su especificación?

Hay al menos cuatro buenos motivos por los que ésta no fue una opción válida:

1. ODF se inició y se completó en gran medida como un formato XML que admitía específicamente OpenOffice con un ámbito ajustado respecto a dicho producto.
2. Hasta 2005 la especificación ODF no se ofreció como formato de documento ofimático XML, cuyo nombre se cambió en consecuencia a ODF.
3. Microsoft no tuvo ninguna oportunidad real de participar en todo este proceso, debido al ámbito original y al período de seis meses comprendido entre el cambio de nombre de la especificación a ODF y su aprobación posterior como estándar por parte de OASIS.
4. El ámbito de la especificación ODF no incluyó ni siquiera los requisitos básicos que necesitaba Microsoft para dar compatibilidad a un formato completamente abierto; por otra parte, el comité técnico de OASIS tampoco quiso incluir estos requisitos. Entre ellos, se encuentran:
   • Fórmulas de hoja de cálculo
   • Tablas en presentaciones
   • Características de accesibilidad
   • Compatibilidad con esquemas personalizados
   • Metadatos personalizados

Como punto de partida, debemos recordar que los estatutos del comité técnico de ODF de Oasis determinó que los esquemas OpenOffice de Sun constituían la base de todos los trabajos y esquemas, y el nombre del comité técnico (CT) no se cambió a "Open Document Format" o "ODF" hasta mucho después. El CT mantuvo un enfoque muy claro y limitado en la representación de las capacidades funcionales del producto StarOffice de Sun original.

Los requisitos de estos estatutos eran muy diferentes de los que tenía Microsoft en lo que respecta a proporcionar un formato de archivo basado en Open XML que permitiera asegurar la compatibilidad con versiones anteriores con formatos binarios y asegurara la interoperabilidad con orígenes de datos back-end en sistemas de línea de negocio, etc. Los objetivos de Microsoft simplemente estaban "fuera del ámbito".

La tabla que figura a continuación describe la escala de tiempo del trabajo de los estándares en relación con lo que ahora es el formato Open Document Format (ODF).

Es evidente que todas las tareas de normalización de lo que hoy se conoce como ODF se llevaron a cabo entre noviembre de 2002 y diciembre de 2004, en el ámbito de OpenOffice XML. Una vez completado este trabajo y no antes, OASIS tomó medidas para posicionar el formato como un formato de documento Office más generalizado al cambiar su nombre por ODF en enero de 2005.

Asimismo, esto es lo que dijo Gary Edwards, editor de ISO 29300 ODF, cuando respondió a este asunto en su blog:

"La pertenencia actual del CT de OASIS ODF está clara e inequívocamente reconocida en comparación con la interoperabilidad que está pidiendo el mercado. Nuestros actuales miembros del CT han contestado a los problemas de "compatibilidad, interoperabilidad y convergencia" descritos anteriormente con las siguientes palabras: "fuera de límites", "fuera de ámbito", "no es nuestro problema", "dejemos que los convertidores y los transformadores se ocupen de ello" y "hablen con Microsoft".

Si Microsoft se uniera hoy en día al comité técnico de ODF de OASIS, con la intención de adaptar ODF para satisfacer las necesidades de integración con la línea de negocio, las características de MS Office y los documentos heredados de su base monopolística, el CT haría frente exactamente a los mismos problemas que ya se han rechazado sumariamente respecto a los debates de compatibilidad, interoperabilidad y convergencia actuales".

¿Por qué no armonizar ODF y OXML?

Tal vez resulta tentador examinar ODF (ISO26300) y Open XML (ECMA-376), y preguntarse cuánto se solapan y, por consiguiente, si se podrían armonizar. Hay varios motivos por los cuales esta opción no es realista.

La historia nos ha demostrado que cuando intentamos crear algo demasiado generalizado para adaptarnos a muchos requisitos, terminamos con un resultado que no satisface del todo.

Asimismo, la organización Ecma fue muy clara en lo que respecta al motivo para tener una especificación independiente para los documentos y esto se puede ver en su respuesta oficial generada después del período de revisión de 30 días.

En la página 6, afirma que: 1) los dos formatos son fundamentalmente diferentes incluso en relación con los objetivos de diseño de bajo nivel (por ejemplo, los de la compatibilidad con documentos heredados y los niveles de conformidad), y 2) en consecuencia, difieren en gran medida en su estructura y arquitectura, lo que no puede corregirse fácilmente con la adición de características. Se pueden encontrar buenos ejemplos en el modelo de estilo de página explícito, el modelo de división de celdas de tabla, la compatibilidad total con las fórmulas de hoja de cálculo, entre otros. ODF no se diseñó para admitir los requisitos de Microsoft Office; esto es fruto de una decisión rapidísima de la primera reunión del comité de ODF en OASIS. Por otra parte, Gary Edwards (editor de ISO 29300) declaró recientemente que el comité de OASIS decidió hace poco no agregar a ODF características usadas por Microsoft Office.

Por último, el proceso de votación de ISO que se lleva a cabo actualmente se centra específicamente en determinar si ECMA-376 puede convertirse en un estándar ISO válido. Si alguna vez se ha tenido en cuenta la armonización, la forma aceptable de hacerlo consiste en consensuar un "SÍ" para la especificación ECMA-376; este voto positivo vería dicha especificación bajo el control de ISO (en paridad con ODF 1.0) y, por tanto, proporcionaría el mecanismo ideal para desarrollar esta investigación.

Mito 3: Los gobiernos de todo el mundo adoptan ODF y rechazan Office Open XML

Los recientes eventos en Estados Unidos, Dinamarca y Suiza demuestran que los gobiernos cada vez se inclinan más a rehusar nuevas legislaciones que dan "prioridad" o estipulan un formato de archivo específico y, en su lugar, permiten que el mercado elija los mejores formatos.

Por ejemplo, el estado de Massachusetts recientemente revisó su Enterprise Technical Reference Model (ETRM) para incluir Office Open XML, además de otros formatos como ODF, PDF y TXT, como estándar de formato de documento preferido. El gobierno de Dinamarca aprobó una directiva similar que reconoce los dos estándares (Office Open XML y ODF) en junio de 2007.

El gobierno federal suizo anunció en julio de 2007 que la adhesión a las normas recopiladas en SAGA.ch es obligatoria para sus ministerios, así como para los cantones, las ciudades y los municipios. La versión más reciente de SAGA.ch incluye tanto Open XML como ODF.

Asimismo, en los últimos meses, los gobiernos de seis estados de EE.UU. (Connecticut, Florida, Oregón, Texas, California y Minnesota) han desestimado leyes que favorecerían un solo estándar (ODF) en las decisiones sobre adquisiciones públicas.

A pesar del método equilibrado que la mayoría de los gobiernos siguen respecto a las leyes sobre adquisiciones, existe preocupación por el hecho de que algunos gobiernos puedan favorecer los estándares ISO en detrimento de otros estándares, con independencia del mérito técnico o la adopción del mercado. De este modo, resulta de gran importancia que Office Open XML tenga las mismas condiciones que ODF para lograr la aprobación ISO. En última instancia, un voto positivo a favor de Office Open XML coloca el estándar en el mismo nivel que otros formatos de documento existentes, como PDF/A y ODF, y permite que los gobiernos y otros clientes puedan tomar decisiones sobre adquisiciones basadas únicamente en los méritos de cada uno de ellos.

Mito 4: Open XML presenta conflictos con los derechos de propiedad intelectual (DPI)

De forma resumida, las preocupaciones específicas de DPI son:

• Las contribuciones a Ecma se realizaron bajo el código de conducta en materia de patentes de dicha organización y se alineaban con la directiva de DPI de ISO/IEC.
• Como miembro de Ecma, Microsoft ha facilitado información a ésta acerca de cualquier derecho de patente esencial que Microsoft pueda tener en relación con ECMA-376; esta declaración se proporcionó a JTC 1 junto con el documento de procedimientos rápidos.
• ISO ha informado a Ecma que Microsoft también ha facilitado un formulario de declaración de patente al secretariado central de ISO en relación con el otorgamiento de licencias de todos sus derechos de patentes esenciales que resultan necesarios para implementar DIS 29500.
• De conformidad con dicho formulario, Microsoft ha garantizado a ITTF que los derechos esenciales con respecto a DIS 29500 estarán disponibles para implementaciones totales o parciales bajo tres métodos diferentes (que podrá seleccionar el responsable de la implementación). Entre estas opciones, se incluyen la promesa de especificación abierta de Microsoft, el pacto de Microsoft y una licencia razonable y no discriminatoria (RAND) libre de regalías (royalties).

Los opositores de Open XML supuestamente han ideado "problemas" en torno a los derechos de propiedad intelectual cuando en realidad no existen, sin tener en cuenta el hecho de que ISO/IEC ya ha aprobado los términos de licencia propuestos de Microsoft. Asimismo, se niegan a reconocer que Microsoft trabajó con voces clave de la comunidad del código abierto, de quienes obtuvo la aprobación para formular su método de otorgamiento de licencias. Además, estos críticos olvidan a su conveniencia que el pacto de propiedad intelectual de Sun Microsystems es casi idéntico al de Microsoft. Inicialmente, es importante destacar que los términos de la directiva ISO/IEC acerca de DPI rigen cualquier debate sobre si Microsoft ha otorgado suficientes derechos a su propiedad intelectual en relación con los formatos Open XML. La directiva de DPI pertinente sólo requiere que Microsoft se comprometa al otorgamiento de licencias de patentes relevantes bajo términos "razonables y no discriminatorios". ISO/IEC cuenta con un nuevo formulario de divulgación obligatorio que se exigió usar a Microsoft para revelar sus términos de licencia y propiedad intelectual. En este momento, toda la información relevante se ha divulgado a ISO, quien se siente satisfecha de que los términos de licencia de Microsoft satisfagan la directiva acerca de los DPI de ISO/IEC. ISO ya ha determinado que las provisiones de propiedad intelectual aplicables a ECMA-376 cumplen sus requisitos de DPI al permitir que la especificación pase al proceso de votación de cinco meses.

Microsoft formuló dos mecanismos relacionados para cumplir las directivas de DPI pertinentes. El primero, el "pacto de Microsoft relativo a los esquemas de referencia XML de Microsoft Office 2003 y los formatos de archivo Office Open XML de Ecma" fue anunciado y secundado en octubre de 2005. Este pacto inicial de no demanda (CNS) estipuló que Microsoft "no tendría por objetivo ejecutar ninguno de sus derechos de patente necesarios para adecuarse a las especificaciones técnicas". El CNS recibió el respaldo de un notable defensor del código abierto, Larry Rosen, anterior director jurídico de Open Source Initiative y autor de "Open Source Licensing: Software Freedom and Intellectual Property Law", quien afirmó:

"Este pacto va mucho más lejos de lo que Microsoft ha hecho hasta ahora. Implica que tanto el software patentado como el de código abierto pueden competir en las implementaciones de estos importantes esquemas XML sin la amenaza de litigación de patentes por parte de Microsoft... Podemos participar en la construcción del estándar en ECMA, podemos leer y escribir archivos de Office 2003 en aplicaciones de código abierto y no tenemos que pagar regalías (royalties) a Microsoft por todo ello".

Tras trabajar con diversos miembros de la comunidad de OSS, Microsoft revisó su pacto y lanzó su promesa de especificación abierta (OSP) en el año 2006. La OSP se creó para proporcionar a todos los desarrolladores (independientemente de su modelo de desarrollo) un acceso más fácil y eficaz a toda una serie de tecnologías y propiedad intelectual de Microsoft, incluidos los formatos Open XML. La OSP ofrece acceso irrevocable a patentes libres de regalías (royalties) en plataformas propietarias y de OSS para implementar un número cada vez mayor de especificaciones técnicas que admiten la interoperabilidad, incluidas 38 especificaciones de servicio web, formatos de unidad de disco duro virtual, tecnologías contra correo no deseado y Open XML. La OSP recibió elogios de miembros de la comunidad del código abierto.

• Mark Webbink, subdirector jurídico de Red Hat Inc., afirmó: "Red Hat cree que el texto de la OSP da suficiente flexibilidad para implementar las especificaciones incluidas en el software con licencias libres y de código abierto. Recomendamos que los esfuerzos de Microsoft lleguen a los representantes de la comunidad del código abierto y soliciten sus comentarios acerca de este texto, y que Microsoft consienta realizar las modificaciones pertinentes como respuesta a nuestros comentarios".
• Larry Rosen declaró: "Considero que la puesta en escena de la OSP de Microsoft es un buen paso para reforzar la colaboración entre los proveedores de software y la comunidad del código abierto. Esta OSP permite a la comunidad del código abierto implementar estas especificaciones de estándar sin tener que pagar regalías (royalties) a Microsoft ni firmar un contrato de licencia. Me complace que esta OSP sea compatible con las licencias libres y de código abierto".

Bajo la OSP, Microsoft emitió un pacto de no demanda (CNS) para todos sus derechos de patente, que los desarrolladores infringirían irremediablemente al implementar la especificación Open XML, incluidas todas las partes opcionales.

Aquí puede encontrar una opinión legal y una revisión detallada, proporcionadas por Baker & McKenzie (Londres), del pacto de Microsoft relativo a los esquemas de referencia XML de Microsoft Office 2003 y los formatos de archivo Office Open XML de Ecma. A continuación, se incluyen algunos puntos clave de esta revisión:

• "...CNS es una declaración unilateral para el mundo acerca del futuro comportamiento de Microsoft hacia la aplicación de sus derechos de patente en el esquema. Aunque el pacto rige el futuro comportamiento de Microsoft, en realidad es de carácter retrospectivo y se aplica a los usos pasados del esquema que hayan podido quebrantar, de forma real o potencial, los términos de la licencia de patente previa".
• "Al declarar que el pacto es de carácter irrevocable, Microsoft ha protegido a los usuarios ante un cambio de políticas empresariales futuras".
• "Por consiguiente, el CNS resulta considerablemente más favorable para una persona que confíe en él que cualquier otra forma de licencia de patente, ya que no impone restricciones positivas en las actividades de los beneficiarios como condición de dicha confianza".
• "El CNS de Microsoft es similar a un pacto emitido por Sun Microsystems Inc., en septiembre de 2005, en lo que respecta a las patentes que posee en relación con la especificación de Open Document Format ('ODF') for Office Applications (OpenDocument) versión 1.0. "El CNS no afecta a los derechos de los usuarios para crear sus propias aplicaciones con las especificaciones de esquema. Por ejemplo, no hay restricciones en el CNS que prohíban a terceros incorporar el estándar a aplicaciones creadas y distribuidas en forma de código abierto, o para otras plataformas de sistemas operativos o hardware. Estas aplicaciones, desarrolladas por terceros, normalmente estarán sujetas a acuerdos legales independientes y los pactos que puedan imponer los desarrolladores de dichas aplicaciones, como el pacto de Sun en relación con ODF".
• "Estas restricciones se verán determinadas por el desarrollo y las prácticas de otorgamiento de licencias del desarrollador de terceros y no por Microsoft; esto será válido tanto para aplicaciones desarrolladas bajo el estándar ODF como para aplicaciones que incorporen el estándar del esquema Open XML".

Conformidad con la directiva de patentes ISO: IBM ha intentado distinguir entre la OSP aplicable a ECMA-376 y DIS 29500. Afirma que Microsoft sólo se ha comprometido con el documento de ECMA-376 y no con el de DIS 29500. Dicha declaración no es cierta. Microsoft hizo una declaración de patente y una declaración de licencia para ISO/IEC respecto a DIS 29500 en la que no sólo se comprometía al otorgamiento de licencias RAND-Z (libres de regalías) para DIS 29500, sino que fue más lejos e incluyó una cláusula que afirmaba que el CNS original para Open XML y la OSP eran alternativas disponibles a discreción del implementador, aplicables a DIS 29500.

De hecho. en términos del proceso ISO, ISO/IEC tiene un nuevo formulario de divulgación obligatorio que se solicitó usar a Microsoft, de modo que toda la información necesaria se ha divulgado a ISO, quien está satisfecha con los aspectos de DPI de la especificación. ISO ya ha determinado que las provisiones de propiedad intelectual aplicables a ECMA-376 cumplen sus requisitos al permitir que la especificación pase al proceso de votación de cinco meses.

Al igual que Sun hizo con ODF, Microsoft deja claro que no reivindicará sus patentes frente a software que implemente los requisitos (obligatorios u opcionales) del estándar, aunque dicho software no implemente completamente dicho estándar. Las promesas de Microsoft trascienden los requisitos de la directiva de patentes de Ecma o ISO/IEC.

Otro problema señalado radica en que el pacto de no demanda (CNS) de Microsoft no cubre las tecnologías externas. Esto no difiere del CNS de Sun para ODF (disponible aquí). En particular, tengamos en cuenta lo siguiente del CNS de Sun (con énfasis agregado):

Una comparación rápida con el CNS de Microsoft presentado anteriormente muestra que son prácticamente idénticos. Como práctica habitual, las licencias de tecnología se centran en las partes explícitas de lo que se detalla en las especificaciones y excluyen lo que a menudo se denomina "tecnologías capacitadoras". Si Microsoft incluyó derechos de patente en la tecnología capacitadora, a modo de ejemplo extremo, se podría rebatir que se necesitan patentes de sistema operativo y equipo para implementar casi todas las especificaciones de las tecnologías de información. Estas licencias de patente a tecnologías referenciadas nunca se dan con tanta amplitud para estándares de la industria específicos.

Disponibilidad de los formatos de archivo binario

En algunos casos, los clientes podrían querer tener acceso a los formatos de archivo Office binario para entender de forma más exhaustiva determinados aspectos técnicos. Microsoft ha previsto esto abiertamente mediante un acuerdo de licencia RAND (razonable y no discriminatorio). Asimismo, el uso de la licencia no se limita a "propósitos de referencia forenses y analíticos". El formato puede implementarse en aplicaciones competitivas y Microsoft proporciona la documentación a los competidores que la soliciten y acepten los términos de licencia. La licencia está libre de regalías (royalties). Las características clave de esto se incluyen a continuación:

Contratos de licencia de formato de archivo binario

• Microsoft usa un contrato de licencia de tipo "firmar y devolver". El contrato permite que Microsoft obtenga un contacto de soporte al cliente del desarrollador de una implementación y dirija a dicho contacto todas las llamadas de soporte que reciba Microsoft en relación con la implementación. Esta disposición permite a Microsoft proporcionar un mejor servicio a los clientes.
• El destinatario, una vez que haya firmado y devuelto el documento, obtiene una licencia de copyright libre de regalías (royalties) para usar los formatos como desee, sujeto a la publicación de una nota de copyright de Microsoft con su uso de los formatos.
• Microsoft proporciona un pacto de patente de no demanda.
• Microsoft proporciona el software tal como está, y renuncia a cualquier tipo de garantía.