Defendiendo los Estándares Abiertos: la FSFE refuta las falsedades que la BSA transmitió a la Comisión Europea

La Business Software Alliance (BSA) está presionando a la Comisión Europea para eliminar los últimos vestigios de apoyo a los Estándares Abiertos de la última versión de las recomendaciones de la UE en cuestión de interoperabilidad, el Marco Europeo de la Interoperabilidad.

La FSFE obtuvo una copia de una carta enviada a la Comisión por la BSA la semana pasada. En los párrafos siguientes vamos a analizar los argumentos de la BSA y explicar por qué sus alegaciones son falsas, y por qué los Estándares Abiertos son esenciales para la interoperabilidad y la libre competencia en el mercado europeo de software. Hemos compartido este análisis con la Comisión Europea.

1. El licenciamiento de patentes libre de royalties abre la participación y promueve la innovación
2. Los estándares que la BSA pone como ejemplo son irrelevantes para el área del software
3. El licenciamiento (F)RAND en estándares de software es injusto y discriminatorio
4. La BSA no es representativa ni siquiera de sus propios miembros, y mucho menos de la industria del software como un todo
5. L (F)RAND es incompatible con la mayoría de las licencias de Software Libre
6. La preferencia recomendada por los Estándares Abiertos es totalmente ajena a la posición en la negociación vis-a-vis entre la UE y China
7. Las especificaciones sin restricciones promoverán la libre competencia, la normalización y la interoperabilidad
8. Recomendaciones

El licenciamiento de patentes libre de royalties abre la participación y promueve la innovación

En su carta, la BSA argumenta que "[] Si la UE adopta una preferencia por especificaciones libres de patentes y/o royalties, eso perjudica a los incentivos con los que las empresas contribuyen a innovaciones punteras para la normalización - lo que deriva en especificaciones europeas menos innovadoras y productos europeos menos competitivos. []"

La verdad es que eso refleja un desconocimiento grave de los estándares, de su papel y de su funcionamiento.

1. Las condiciones de licenciamiento libres de royalties (Zero-royalty) no impiden que las tecnologías patentadas sean incluidas en los estándares. En cierto grado, se obliga al proponente a evitar la imposición de royalties sobre las implementaciones.
2. La plataforma de tecnología de mayor éxito en la Tierra, Internet, está basada en estándares que fueron puestos a disposición íntegramente en condiciones de licenciamiento zero-royalty. La verdad es que el W3C, la organización de normalización (SSO) que rige los estándares en la web ha adoptado por consenso una "política de derechos de propiedad intelectual" zero-royalty, donde los royalties sobre las tecnologías pueden ser aceptados sólo sobre unos fundamentos muy excepcionales. En vez de sofocar la actividad inventiva, como afirma la BSA, esto transformó internet en un foco de innovación. Verdaderamente, es la propia naturaleza de los estándares la que estabiliza una plataforma sobre la cual los competidores pueden crear soluciones innovadoras y interoperables1.
3. Contrariamente a lo que la BSA reclama, las políticas de licenciamiento de patentes zero-royalty abren la participación en la configuración de los estándares de software para el mayor número posible de participantes e implementadores del mercado. Como resultado, los estándares de software que salen de las organizaciones de normalización con políticas de licenciamiento de patentes zero-royalty, como el W3C, han tenido una amplia aceptación, como el patrón HTML, sólo por ser el ejemplo más notable.

Desde una perspectiva política más amplia, también es cuestionable que los innovadores, que ya están recibiendo un incentivo a través de una patente, necesiten ser más incentivados por tener esa patente incluida en un estándar. Una patente no es igual a tener derecho a un flujo de rentas garantizado.

Los estándares que la BSA pone como ejemplo son irrelevantes para el área del software

La BSA argumenta que "[] muchas de las especificaciones abiertas que en la actualidad están más ampliamente implantadas incorporan innovaciones patentadas que fueron inventadas por empresas comerciales... incluyendo el WiFi, el GSM y el MPEG."

Esta es una tentativa de crear una falsa dicotomía entre las empresas "comerciales" que inventan una tecnología patentada, en contraste con las "no-comerciales" que no son invenciones patentadas. En realidad, un gran banco de riqueza de modernas tecnologías no patentadas con origen en empresas comerciales constituyen estándares aplicados a nivel mundial (como HTML5), aunque sigan proporcionando a sus creadores una renta. No hay forma de hacer la división, sea a nivel económico o ideológico, entre tecnologías de hardware y software que son patentadas, y aquellas que no lo son. Sin embargo, la divisibilidad de la BSA implica que hay una diferencia entre los métodos de negocio convencionales y aceptados, a los que asocian con las patentes, y las organizaciones no-eficientes y no-comerciales, que ellos asocian con la tecnología libre de patentes. Dada la creciente presencia del Software Libre en el mercado europeo de servicios de TI, tal afirmación es claramente falsa.

Las normas que la BSA cita como ejemplos (con excepción de MPEG 2) están relacionadas con tecnologías basadas en hardware. La economía del mercado de hardware es muy diferente a la del mercado de software. Mientras que la entrada en el mercado de hardware requiere inversiones muy sustanciales, las empresas de software pueden iniciar su actividad con pequeñas cantidades de capital. Exigir a estos iniciantes en el software el pago de royalties para la implementación de estándares de software elevaría significativamente las barreras para entrar en el mercado, reduciría la innovación y dificultaría la libre competencia, y también aumentaría los precios para los consumidores (incluyendo las organizaciones del sector público).

Para el software, sin embargo, está claro que permitir la inclusión de patentes en los estándares de software bajo las condiciones (F)RAND va a aumentar indebidamente e innecesariamente las barreras para entrar en el mercado europeo de software, haciendo que la economía de las TIC de Europa sea menos competitiva.

El licenciamiento (F)RAND en estándares de software es injusto y discriminatorio

La BSA argumenta que "[] Los requerimientos de que una especificación abierta sea "libremente implementable" y capaz de ser compartida y reutilizada son ambiguas, y sugieren que el estándar debe estar libre de derechos de propiedad intelectual (IPR)."

La BSA también argumenta que "[La FRAND garantiza que] los implementadores de un estándar puedan utilizar las innovaciones en términos justos. Esto permite que los inventores cobren una tasa razonable cuando las tecnologías son incorporadas a las especificaciones[.]" En los estándares de software, las condiciones (F)RAND, de hecho, discriminan al Software Libre y a cualquier modelo de negocio basado en él. Las licencias de Software Libre más ampliamente utilizadas no permiten la imposición de condiciones adicionales a los posteriores receptores. Sin embargo, las (F)RAND exigirían que tales condiciones fueran impuestas, generalmente bajo la forma de royalties, interpretándose que las políticas de licenciamiento (F)RAND son incompatibles con el Software Libre. Cuando hablamos de estándares de software, se interpreta que el enfoque de las (F)RAND no es razonable ni no-discriminatorio.

Por otro lado, el "zero-royalty" no excluye las implementaciones privativas (ni siquiera las fuertemente patentadas). En realidad, "Zero-royalty" significa que, si ciertas tecnologías están comprometidas por un estándar, éstas deberán estar a disposición de todos sin exigir royalties. Sin embargo, las implementaciones pueden ser distribuidas bajo cualquier licencia e incluir cualquier tecnología, siempre que la norma sea respetada.

El estándar HTML libre de royalties, por ejemplo, fue implementado en una infinidad de navegadores, tanto en Software Libre como privativo. Esto demuestra claramente que un estándar de software libre de royalties puede permitir la adopción generalizada, e impulsar la innovación a través de la libre competencia.

La BSA no es representativa ni siquiera de sus propios miembros, y mucho menos de la industria del software como un todo

La BSA argumenta que "El Marco Europeo de la Interoperabilidad (EIF) puede ser leído con la interpretación de que las empresas europeas y extranjeras más innovadoras no son invitadas a participar en procesos de normalización si tienen patentes propias en tecnologías relevantes y buscan compensaciones por sus invenciones si esas patentes son integradas en el estándar."

La BSA además reivindica que "Los inversores reconocen que existe un vínculo importante entre el DPI y la normalización - y también reconocen que los estándares basados en las FRAND son altamente flexibles y pueden ser implementados en una amplia gama de soluciones de código abierto y privativo".

Contrariamente a lo alegado por la BSA para representar una posición unificada del sector del software, acordémonos de que la ECIS, que está formada por importantes miembros de la industria (algunos de los cuales también son miembros de la BSA) dice lo contrario3. A pesar de tener una grande cartera de patentes, los miembros de la ECIS quieren estándares para que la interoperabilidad del software permanezca sin las cargas de funcionar bajo los requisitos de royalties de las patentes []. Para citar sólo un ejemplo, Google ha contribuido enormemente a los estándares zero-royalty, ofreciendo una alternativa para MPEG patrocinada por la industria.

Las (F)RAND son incompatibles con la mayoría de las licencias de Software Libre

La BSA afirma que "la mayoría de las licencias de las OSS son totalmente compatibles con el licenciamiento basado en las FRAND."

Desde un punto de vista razonable (bien sea basado en la cantidad de código disponible, en la importancia del mismo o en ambas cosas) las licencias de Software Libre u open souce más relevantes son:

1. La GNU GPL y LGPL
2. La Mozilla Public License
3. La Apache Public License
4. La BSD/MIT y otras licencias ultra-permisivas
5. La EUPL

Todas ellas, con la única excepción discutible pero incierta de la categoría ultra-permisiva, son claramente incompatibles con un régimen de patentes con royalties. En consonancia con las estadísticas publicadas por Black Duck Software, más del 85% de los proyectos de Software Libre son distribuidos bajo licencias que son incompatibles con los regímenes de patentes con royalties. Está demostrado que la GNU General Public License (GPL) es, de lejos, la licencia de Software Libre más ampliamente utilizada, por ser usada por casi la mitad de todos los proyectos. Incluir las tecnologías patentadas en productos de Software Libre, cuando es posible, exige que los implementadores mezclen partes privativas con Software Libre de forma inapropiada. En esos casos, el código resultante es necesariamente software privativo5.

La preferencia recomendada por los Estándares Abiertos es totalmente ajena a la posición en la negociación vis-a-vis entre la UE y China

La BSA afirma que "[la] ambigüedad de la preferencia propuesta por el EIF, sin ninguna duda, compromete la capacidad de la Comisión para mantener su firme defensa de los titulares de derechos de propiedad intelectual de Europa [contra las amenazas de China]."

Las alegaciones de que una recomendación para expresar preferencia por especificaciones abiertas va a debilitar la posición en la negociación vis-a-vis entre la UE y China son claramente falsas. Las recomendaciones relativas a la utilización de especificaciones de software abiertas en el sector público no tienen influencia alguna sobre la posición de la Comisión. Además de eso, merece la pena repetir que las normas "zero royalty" no están enfrentadas con la "defensa robusta" de las patentes, del copyright y de las marcas comerciales.

Nótese que en los Estados Unidos, preocupaciones semejantes fueron sometidas a la US Trade Representative en la preparación para el informe 2010 US Special 301 sobre los obstáculos al comercio. La US Trade Representative optó por no incluir estas preocupaciones en el informe, demostrando claramente que el gobierno de los Estados Unidos considera que esto no es un problema. Aunque tales alegaciones pueden ser hechas como esfuerzos para influenciar políticas públicas, hay una marcada ausencia de tentativas para suprimir esas preferencias por medios jurídicos - presumiblemente porque aquellos que hacen estas afirmaciones saben muy bien que ellos, de hecho, no tienen respaldo.

Las especificaciones sin restricciones promoverán la libre competencia, la normalización y la interoperabilidad

La BSA afirma que "la preferencia propuesta por la EIF por las especificaciones libres de PI va a minar... la normalización, la competitividad y la interoperabilidad, a largo plazo."

Nosotros somos incapaces de determinar lo que la BSA entiende por especificaciones "libres de PI", aunque creemos que tal formulación sugiere un conocimiento insuficiente del proceso de normalización por parte de la BSA.

La alegación de que la actual formulación de la EIF podría perjudicar a la interoperabilidad es simplemente inaceptable. Ella fluye de hipótesis no comprobadas que hemos demostrado que son falsas en la exposición anterior. Actualmente, los efectos de bloqueo resultantes de la utilización de programas y formatos de archivo privativos muchas veces impiden que las administraciones públicas escojan libremente sus soluciones de TI. En vez de eso, ellos permanecen atados a un determinado proveedor. Las dificultades del Municipio de Brighton y del cantón suizo de Solothurn (por citar sólo dos ejemplos de los últimos meses), junto con incontables otras entidades públicas, en la migración de una solución de TI para otra, ilustra como el aprisionamiento tecnológico causado por estándares de software cubiertos por patentes, vinculan a los usuarios con soluciones precarias, con un gran coste para los contribuyentes.

Por otro lado, los estándares de software que pueden ser implementados sin restricciones permiten muchas implementaciones concurrentes para interactuar unas con las otras. En este escenario, los lucros de los monopolios para un número muy limitado de grandes competidores son sustituidos por un mercado vibrante e innovador impulsado por una competencia feroz. Eso tiene como resultado mejores soluciones y servicios a precios más bajos.

Recomendaciones

En vista de las consideraciones expuestas, instamos a la Comisión a promover la interoperabilidad y la libre competencia en el mercado europeo de software, en vez de dar a la empresas dominantes un impulso adicional para mantener su control sobre el mercado. Con esta finalidad, pedimos a la Comisión que no apruebe las políticas de licenciamiento (F)RAND para los estándares de software. En vez de eso, instamos a la Comisión a mantener la recomendación de que las especificaciones puedan ser consideradas abiertas sólo si pueden ser implementadas y compartidas bajo diferentes modelos de licenciamiento de software, incluyendo el Software Libre 6 licenciado bajo la GNU GPL.

Pedimos también a la Comisión que incluya en la revisión del Marco Europeo de la Interoperabilidad una robusta recomendación para que los organismos públicos se beneficien de las ventajas del software basado en Estándares Abiertos 7 en términos de elección, libre competencia, libertad de aprisionamiento tecnológico y acceso a largo plazo a los datos.

Notas a pie de página

1. Ver por ej. Rishab Aiyer Ghosh, Philipp Schmidt (2006): Documento de Política de la Universidad de las Naciones Unidas, Número 1, 2006: "Los estándares abiertos, definidos consistentemente, pueden tener el excepcional efecto económico de permitir que se formen monopolios "naturales" en una tecnología dada, al tiempo que se asegura una libre competencia completa entre los proveedores de tal tecnología." [énfasis añadido]
2. El MPEG está diseñado específicamente para usar de manera explícita tecnologías patentadas, aún cuando son en gran medida substituibles (probablemente) por alternativas no patentadas que son menospreciadas. Esto es concebible debido a la necesidad de extraer el máximo lucro posible con la utilización de su peculiar aplicación de ciertos principios matemáticos, antepuesta a la necesidad de crear una plataforma común y normalizada para fines de interoperabilidad.
   Además de eso, la mayoría de los estándares MPEG fueron establecidos en una época en que los códecs fueron hechos en hardware tanto porque el ancho de banda disponible era limitado como porque el hardware genérico no era lo suficientemente potente.
3. Vea la reacción de la ECIS ante la carta de la BSA, del 13 octubre de 2010
4. Para una exposición sobre soluciones híbridas en protocolos de red, vea la respuesta de la FSFE y el Samba Team al artículo 18.
5. Vea la definición de Software Libre de la FSFE
6. Como definimos en las definiciones de la FSFE de un estándar abierto