Este post ha sido redactado por Carlos Muñoz Ferrandis, doctorando en la Universidad de Alicante, investigador invitado en el Max Planck Institute for Innovation and Competition (Munich), e investigador asociado en la Universidad de Utrecht en el marco del grupo ‘Blockchain for Societies’.

Cuando uno identifica los tres personajes de esta historia, lo primero que se puede plantear, es:

  • ¿Bockchain y patentes esenciales? Ya lo que me faltaba por leer. No saben ya qué inventarse hoy en día. Que si disrupción por aquí, que si disrupción por allá, madre mía. Bueno, venga, vamos a echarle un ojo, como dirían los valencianos: ‘per si de cas’. Y como dirían los sibaritas cursis de lo anglosajón: ‘just in case’ (sin ofender, eh, ‘yust chil and rid, mai friend’).

Como iba diciendo, los tres personajes de esta historia son, en primer lugar, un consorcio de I+D cuyo objetivo es el de crear una infraestructura técnica – una ‘Red’ – basada en tecnología blockchain. Alastria, nació en 2017 y hoy cuenta con tres productos estrella basados en blockchain: la Red T, la Red B, y Alastria ID. Echadle un ojo vosotros aquí.

En segundo lugar, las patentes – o reivindicaciones – esenciales son aquellas cuya infracción es inherente a la utilización – i.e. implementación – del ‘estándar’ – i.e. norma técnica – en cuestión. Si yo implemento una norma técnica, como el 4G, por ejemplo, en uno de mis productos – i.e. un teléfono, estaré directamente infringiendo toda patente esencial para la implementación del 4G. El origen de dichas patentes esenciales surge de las contribuciones técnicas que hacen los miembros – o participantes – del organismo de normalización durante el proceso de desarrollo y creación de la norma técnica.

El tercer mosquetero, open source, como tal, es un modelo colectivo de desarrollo – e innovación – de software. Una o varias empresas publican su código fuente en una plataforma bajo unos términos de ‘uso’ ‘abiertos’. El código fuente se puede inspeccionar, utilizar, modificar y distribuir. Dependiendo de la licencia, que hay unas cuantas, el usuario tendrá más o menos prerrogativas a la hora de (re)distribuir dicho código fuente. Algunas licencias son más estrictas – e.g. GPL – y otras son más permisivas y/o más enfocadas a la subsiguiente explotación comercial del código derivado del original – e.g. Apache 2.0. Eso sí, independientemente de la licencia, todas ellas para calificarse como ‘open source’ han de satisfacer los requisitos esenciales de la ‘Open Source Initiative’.

Una vez hechas las presentaciones de los participantes en el mejunje de hoy, la pregunta es: “¿Por qué Alastria?”. Atentos.

Uno de lo mandamientos para toda institución cuyo objetivo es competir por asentar estándares técnicos en varios mercados, es tener una política de PI clara. La claridad en las políticas de PI es un elemento clave para dar seguridad jurídica e incentivar la participación de empresas tecnológicamente punteras.

En cuanto a la política de PI de Alastria, y más específicamente, en cuanto a las cláusulas relativas a las ‘reivindicaciones esenciales’ – véase cláusula 3 y sub-secciones del Anexo IV a los Estatutos de la asociación, hay ciertos puntos que no están claros, para un humilde observador – no se van a tocar todos:

Cláusula 3.2.1.:

“En el caso de que una Especificación aprobada formalmente se dirija a productos o procedimientos que infringirían una Reivindicación Esencial de una patente propiedad de un Asociado, por la presente, el Asociado otorga la licencia sobre dicha Reivindicación Esencial de forma no exclusiva a la Asociación y los demás Asociados en términos que sean razonables y no discriminatorios con respecto a entidades en una situación similar, que será́ libre de regalías (a menos que el Asociado licenciante titular de la patente indique lo contrario por escrito).”

La cláusula tiene un alcance cercado en lo que a los términos “Razonables” y “No Discriminatorios” se refiere, puesto que se centra en la asociación y asociados, y no en un acceso al público en general, es decir, a toda entidad que quiera implementar alguna norma establecida por la asociación y necesite la licencia de dichas patentes, puesto que las va a infringir si o si con su mera implementación.

Esto último tendría sentido en caso de que el consorcio no desarrollase las ‘implementaciones de referencia’ de sus ‘especificaciones’ por medio de un modelo open source, como parece ser el caso.

Si, en cambio, la implementación – o partes – de la norma técnica ya está publicada en un repositorio con licencia open source para todos, ¿Qué sentido tiene tener dos políticas de PI distintas? ¿Quiere decir esto que, por un lado, se aplica una política de PI a la especificación técnica, y por otro, la licencia open source a la implementación referente a dicha especificación? ¿Cómo se regulan las posibles fricciones entre la licencia de open source y la licencia de la reivindicación esencial? Escenario práctico:

  1. X, declara ser propietario de una patente que integra reivindicaciones esenciales a una especificación, y quiere negociar licencias en los términos estipulados en la cláusula 3.2.1.
  2. X se da cuenta de que varias empresas infringen sus patentes mediante uso del código open source disponible para desarrollar implementaciones de la especificación.
  3. Con lo cual a X le surge la duda puesto que, por un lado, tiene la opción y prerrogativa de licenciar sus patentes, sin embargo, por otro, se ve que ya las está licenciando mediante la licencia Apache 2.0 para la implementación Yª de la especificación Y.
  4. ¿Qué puede hacer al respecto? Si pretende demandar por infracción, no solo se le suspenden las licencias de otros miembros (cláusula 3.4.1. se activa), sino que encima corre el riesgo de que se le tache en el seno del organismo de ‘paria’.
  5. A efectos prácticos, esto puede provocar que toda la cláusula 3, dirigida a las licencias de reivindicaciones esenciales, acabe ‘desactivada’ por las licencias de open source. Esto debería aclararse.

Aprovechando el cometido de la cláusula 3.2.3. ‘a efectos aclaratorios’, podrían incluirse aquí alguna aclaración que otra.

Cláusula 3.2.5.:

“Cualquier transferencia de una patente que incluya una Reivindicación Esencial incluirá́ una disposición por la cual la obligación de licencia esté disponible para la Asociación y los Asociados con respecto a la Especificación después de la transferencia, y dicha disposición se incluirá́ en los acuerdos de transferencia posteriores. De esta manera, se pretende que la obligación sea una reserva o gravamen sobre dicha patente”.

Esta cláusula establece la irrevocabilidad de la licencia de las reivindicaciones esenciales en el marco de la especificación. Esto es la práctica corriente en los contextos de organismos formales de normalización, como ETSI y más allá, establecido por jurisprudencia como la alemana, en lo que a la transferencia del compromiso (F)RAND se refiere. Sin embargo, en el seno de un consorcio privado este mecanismo se puede poner en duda por algún potencial adquirente de las patentes que incluyan reivindicaciones esenciales de alguno de los asociados. Es más, puede actuar como factor de rechazo, ya que, en compañías habituadas a negociar sus carteras de patentes, puede dar algún dolor de cabeza que otro.

Y más aún, con lo dicho anteriormente sobre la falta de claridad en la relación entre las licencias de open source y las de las reivindicaciones esenciales en términos RAND, ya que, por ejemplo, la licencia Apache 2.0 – utilizada por Alastria, ya integra de por si la ‘irrevocabilidad’ de la licencia de la patente.

Cláusula 3.3.4.:

La exclusión voluntaria para una Especificación libre de regalías, identificada como tal con antelación, puede incluir una “opción inferior” en la que el titular de la patente acepta conceder la licencia sobre la base de condiciones razonables y no discriminatorias (RAND), incluyendo regalías”.

En esta cláusula aparecen conceptos no definidos que pueden crear inseguridad jurídica. La ‘especificación libre de regalías’ nos hace pensar que hay especificaciones que no lo están, eso de primeras, sin embargo, en ningún lado se estipula si hay regímenes distintos aplicables a ambas y su razón – no estaría mal definirlo en la cláusula 8, por ejemplo.

En segundo lugar, aparece el concepto de ‘opción inferior’. Dicho concepto no está nada claro, puesto que parece dar una opción al titular de la patente de licenciar en términos RAND, cuando esta opción ya se da en la cláusula 3.2.1. ¿Cuál es la diferencia entre los dos escenarios?

Hipótesis 1: Si yo, como titular de patente con reivindicaciones esenciales, decido excluir mi patente voluntariamente, no tengo ya porqué comprometerme en ningún término RAND – que en parte es lo que busco mediante la exclusión voluntaria. Y más aun, cuando no se me deja claro si, en caso de excluir mi patente y acogerme a la ‘opción inferior’ se me aplicará, por ende, la cláusula 3.2.5 de irrevocabilidad, lo cual puede ser crítico para mí, ya que si excluyo mi patente es porque no me beneficia licenciarla en el marco jurídico que propone dicha política de PI.

Hipótesis 2: Si me acojo a la ‘opción inferior’ y esto quiere decir que no se me aplica la cláusula 3.2.5. de irrevocabilidad, entonces esto me incitaría a escoger siempre la ‘opción inferior’ y no la vía de la 3.2.1. Cabría aclarar estos aspectos.

Esta cláusula pudo diseñarse con miras a regular la situación en la que ciertas Especificaciones, por intereses estratégicos, no incorporen opción de cargar regalías. Sin embargo, dado que se puede dar el caso en el que la única opción tecnológica disponible sea la de un miembro que quiera cargar regalías, entonces se le ofrece una ‘excepción’, en aras de llegar a un acuerdo y no bloquear el proceso entero de la especificación debido a la negativa del miembro a la licencia gratuita de sus reivindicaciones.

Lo primero que habría que sugerir aquí es implantar un mecanismo – protocolo – de declaración de patente esencial, como el de ETSI, por ejemplo. Esto evitaría malentendidos y sobretodo, fomentaría la transparencia, ese término tan idílico e ideal que no se sabe, como los Reyes Magos, si existe o no de verdad, en el seno de los organismos de estandarización – y que viene ‘recomendado’, por cierto, en las Directrices C11/1 sobre la aplicabilidad del artículo 101 del Tratado de Funcionamiento de la Unión Europea a los acuerdos de cooperación horizontal– párr. 282. Esto es relevante si dicho consorcio pretende a futuro que sus ‘especificaciones’ o ‘implementaciones’ sean adoptadas por organismos formales internacionales.

Cláusula 3.3.6.:

“Ninguna reivindicación puede ser excluida en relación con una Especificación en particular después de que dicha Especificación haya sido aprobada formalmente como definitiva y el Asociado afectado sea consciente de ello”.

Esta cláusula nos da a entender, en cierto modo, que se impone un mecanismo de declaración ex-ante de las reivindicaciones que sean esenciales para la implementación de la especificación. Es decir, si no te pronuncias sobre tu patente, pierdes la opción de excluirla de toda licencia. Lo cual es razonable en aras de evitar comportamientos de mala fe, ex-post, y abusivos – i.e. ‘emboscadas de patente’ como en el caso COMP/38.636 “Rambus”.

Recomendaciones:

1. Relación entre política de PI y licencias open source:

Muy importante aclarar la relación entre la política de PI del consorcio y las licencias de open source utilizadas para las implementaciones de referencia de las especificaciones, cuando el ‘modus innovandi’ del consorcio se basa en open source, como es el caso de Alastria, y bien lo estipula su punto 3 del Anexo VI de los Estatutos. Otro caso similar es el de ETSI con su proyecto de implementación de referencia del estándar NFV, el proyecto OSM, entorno al cual comentarios se han hecho ya – e.g. aquí.

2. Cláusulas dedicadas a los derechos de autor en la política de PI:

Es importante mencionar los derechos de autor que se puedan ostentar con respecto al código contribuido. Se puede pensar que no hace falta dicha mención puesto que ya se licencia con las licencias de open source. No obstante, algunas empresas pueden no querer contribuirlo, o querer monetizarlo (quien sabe, el software cada día es más valioso y el derecho de autor es una manera de protegerlo, nos guste o no). Más allá, no se puede permitir hacer una ‘diferencia’ de facto de tratamiento de los derechos de PI, tratando unos – las patentes – en la política de PI, y otros – copyright – en las licencias de open source, que, para más inri, además, integran licencias de patentes – explícitas o discutiblemente implícitas. Esto puede ser un quebradero de cabeza a futuro.

3. Claridad:

Política de PI más alineada con organismos formales, por si en su día quieren ascender al limbo normativo de los estándares formales, necesitan aportar seguridad jurídica, y no solo calidad técnica. Hay que tener en cuenta en todo momento las bases para una buena política de ‘compliance’ en el ámbito de la estandarización: consenso, transparencia, proceso diligente y abierto.

Se trata de crear un nexo entre dos mundos, el de los estándares y el de open source. Es decir, hacer frente a un nuevo modelo de estandarización en el que los conceptos, tradicionalmente separados, de especificación e implementación, se confunden y pueden ser uno solo.

Dejar respuesta

Please enter your comment!
Please enter your name here

Time limit is exhausted. Please reload CAPTCHA.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.