2.1. Los tipos de (redes) blockchain ¹⁵

En la práctica, tradicionalmente, las redes descentralizadas de nodos en las que se estructuran las diferentes blockchains pueden ser técnicamente divididas en dos tipos, las denominadas como “sin permiso” (permissionless net) o las denominadas como “permisionadas” (permissioned).

Las permissionless net, no exige ningún tipo de permiso para poder participar como nodo validador (minero). Para evitar el fraude, se aplica un sistema proof-of-work por el que el nodo, antes de incorporar un nuevo bloque, deberá resolver un conjunto de problemas criptográficos.

En el caso de las redes permissioned sólo un número limitado de nodos pueden acceder a la red como nodos validadores y esto en función de los requisitos que se establezca. Dicho de otra manera, en este caso se establecen jerarquías entre nodos en base a criterios de confianza. Así, la incorporación de un nuevo bloque dependerá de que este supere bien una proof of authority o bien una proof-of-stake.

Sobre esta base estructural derivada del acceso a los nodos validadores vamos a encontrar dos grandes tipos de cadenas de bloques las blockchains “abiertas” (open) y las “cerradas” (closed). Las redes abiertas, son aquellas que, por regla general, tendrán una estructura “sin permiso” (i.e., Bitcoin). Las redes cerradas, por su parte, tendrán una estructura “permissioned” y se dividen, por el momento, en dos grandes categorías, los consorcios (i.e., Hyperledger o, tradicionalmente, R3) y las redes privadas, también llamadas redes de empresa (i.e., Mediachain).

A esta clasificación “clásica” ha de añadirse una nueva tipología de blockchains, que son las denominadas blockchains “publicas permisionadas”. Estas blockchains estarían a medio camino entre las blockchains abiertas “permissionless” y los consorcios (permissioned blockchain). De hecho, se ha dicho que estas blockchain “combina el permiso de los consorcios privados con un modelo de gobierno descentralizado, tratando de lograr las mejores propiedades de ambos modelos”¹⁶.Un ejemplo de este tipo de redes lo encontramos en la blockchain española Alastria¹⁷ o la European Blockchain Services Infrastructure (EBSI).¹⁸

2.2. Tokenización

Este anglicismo, ya comúnmente adoptado, proviene del término token, que podría traducirse al castellano como “elemento simbólico”, no siendo, como tal, novedoso en el tráfico jurídico¹⁹.

No obstante, en el contexto que estamos estudiando, por token se entenderá la representación virtual y criptográfica bienes o derechos existentes en el mundo real. Generalmente se habla de “token de activos”, habiéndose popularizado este término debido a su impacto en los mercados financieros (especialmente por la polémica suscitadas por las “ICOs”²⁰). En definitiva, tokenizar no es sino crear una ficción jurídica que permite desarrollar una especie de “mundo paralelo” virtual idéntico al real. No olvidemos que la blockchain ha sido definida, por algún autor, como “un libro digital incorruptible de transacciones económicas que puede programarse para registrar no solo transacciones financieras, sino virtualmente todo lo que tiene valor”²¹. La autenticidad y existencia en el mundo real de lo que vemos en este mundo paralelo, en esta representación, vendrá garantizada por técnicas criptográficas y de consenso (esto es, por la blockchain).

Por consiguiente, si, por ejemplo, tokenizamos el título de propiedad sobre un coche, el titular del token se entenderá como el propietario de este bien, pudiendo realizar transacciones con el activo tokenizado de manera virtual (por ejemplo, un contrato de arrendamiento o una venta mediante un smart contract).

2.3. Los smart contracts

Los smart contracts pueden definirse como programas autónomos que ejecutan mecánicamente las exigencias previamente inscritas en una blockchain según las instrucciones dadas por los contratantes y que por la propia naturaleza de la blockchain van a revestir una serie de características como la autentificación, inalterabilidad, transparencia y trazabilidad.

El término smart contract si bien es comúnmente entendido como “contrato”, no siempre revestirá jurídicamente este carácter. Recordemos que los smart contracts son programas (líneas de código) por lo que para que podamos hablar de contrato tendremos que analizar si se cumplen todas las condiciones para poder considerarlo como tal²².

Hemos de subrayar que cuando hablamos de smart contracts estamos hablando de programas informáticos, escritos en un determinado lenguaje de programación (i.e. Solidity, JavaScript o Python) que siguen, al menos hasta el momento, la estructura I-T-E (if/then/ else), esto es, si se cumple esta circunstancia (if), entonces se ejecuta esta accion (then); de no cumplirse, se ejecuta otra accion tambien prevista (else).²³

Estas características, si bien, por un lado, otorgan seguridad sobre los posibles efectos de la ejecución del contrato e, incluso, en el contenido de este último; por otro, generan, ciertas cuestiones de singular importancia en su implementación en el tráfico teniendo en cuenta la práctica contractual habitual, especialmente, en el ámbito internacional (ver infra 3.3).

2.4. Los oráculos

Podemos definirlos, de una manera muy básica, como las fuentes de información (de entrada y de salida) relativas a una cadena de bloques. Aunque, generalmente, cuando se habla de oráculos se hace referencia a las fuentes externas que aportan o suministran información del “mundo real” a la blockchain²⁴ (que hemos denominado oráculos de entrada), podemos encontrar también los llamados outbound oracles que permiten enviar datos desde el smart contract a receptores exteriores (que, en nuestra clasificación se identificarían como oráculos de salida).

La importancia de los oráculos (oracles) de “entrada” radica en la necesidad de la interacción entre el smart contract y el mundo exterior a la hora de su ejecución. Estos oráculos van a responder, por tanto, pues a la necesidad de verificación de que ciertos hechos o actos han tenido lugar o que ciertos datos o aspectos determinados en la cadena de bloques existen en el mundo real. Esta verificación, que se producirá, generalmente, también de manera automatizada, tendrá como consecuencia que continúe a ejecución de las instrucciones establecidas en el smart contract, siguiendo la estructura que hemos explicado en el apartado anterior (ITE, si se cumple esta circunstancia -if-, entonces se ejecuta esta accion -then-; de no cumplirse, se ejecuta otra accion tambien prevista -else).²⁵

Decimos que estos oráculos actúan de manera “automatizada” porque, generalmente, no dependerán de la intervención humana directa para la verificación de la información estipulada. Así, encontraremos los llamados oráculos de hardware (hardware oracles) que serán generalmente sensores integrados en objetos físicos tangibles (i.e. etiquetas RFID) y los llamados oráculos de software (software oracles), que serán programas de ordenador que recogerán o darán constancia de datos del mundo real (i.e. la realización de una transferencia bancaria o los datos meteorológicos). Junto a estas dos formas básicas, existen otros tipos de oráculos más complejos, como son los llamados oráculos de consenso (consensus oracles) en los que encontramos una estructura descentralizada, en la que se agregan varios oráculos a fin de ofrecer una mayor exactitud y seguridad (un ejemplo, sería el protocolo InterPlanetary File System -IPFS-²⁶).

3.1. Consideraciones previas

En primer lugar, y antes de comenzar el análisis de la potencial implementación de la blockchain para la protección del diseño, hemos de partir de unas ciertas premisas que, aunque ya son conocidas, son relevantes a efectos del estudio de esta materia:

- La protección de diseño no es uniforme a nivel internacional, existiendo tanto protecciones nacionales, como regionales (i.e. diseño comunitario) e internacionales.

- Pueden ser objeto de protección una amplia diversidad de categorías de diseños tanto bidimensionales como tridimensionales.

- Cabe la posibilidad de la protección del diseño no registrado (i.e. diseño comunitario no registrado).

- El diseño puede ser objeto de licencias exclusivas y no exclusivas.

- Existen límites a los derechos de exclusiva concedidos por el diseño, entre los que destacan el agotamiento del derecho de distribución, el derecho de uso previo y las excepciones relativas a los actos de reproducción realizados con fines de cita o docentes.

- El registro del diseño puede ser objeto de renuncia, caducidad o nulidad.

- El diseño puede ser objeto de protección por otras figuras de propiedad intelectual e industrial. En este caso será especialmente interesante la protección por derecho de autor, en el caso de las llamadas obras de arte aplicadas.

Por otro lado, hemos de tener presente que:

- Por medio de blockchain se pueden “representar” perfectamente activos (bienes y derechos) inmateriales vinculados a la propiedad intelectual e industrial. Así, se ha señalado, respecto al derecho de autor, pueden ser representados por tokens criptográficos tanto las obras, como la propiedad de los metadatos, los términos de las licencias y las remuneraciones (royalties)²⁷.

- Existen desarrollos en blockchain cada vez más avanzados tanto a nivel de registro de derechos de propiedad intelectual como de remuneración de los derechos.

- Tanto la blockchain como los smart contracts suponen soluciones técnicas que se caracterizan por su autentificación, inalterabilidad, transparencia y trazabilidad.

- Existe un desarrollo exponencial de ciertas tecnologías extremadamente útiles (i.e. internet of things -IoT- e inteligencia artificial) que facilitan la ejecución de los smart contracts (tanto en forma de oráculos que aportan datos o información a la cadena de bloques como en la propia ejecución de las instrucciones del smart contract).

- Existen iniciativas a nivel internacional para el impulso del establecimiento de ciertos estándares específicos sobre las cadenas de bloques orientadas a la propiedad intelectual²⁸.

Por consiguiente, de lo expuesto anteriormente, parece obvio deducir que la aplicación de la blockchain al diseño no sólo es posible, sino que, especialmente en algunos aspectos (i.e. evitar las falsificaciones o simplificar las transacciones) puede plantearse como deseable. No obstante, como tampoco pasará desapercibido, ciertas características de la blockchain (y, por ende, de los smart contracts) van a conllevar importantes escollos en su implementación debido a las características inherentes a la configuración de la protección legal del diseño.

Es por esto por lo que, haciendo un ejercicio que podríamos llamar design blockchain by design (nunca dicho), analizaremos de forma somera ante qué retos nos encontraremos respecto a la implementación de la blockchain en este ámbito.

3.2. Aspectos relativos al registro y protección del diseño industrial por la blockchain: la lucha contra la falsificación

Uno de los aspectos que en los últimos años ha tenido un interés creciente es la aplicación de la blockchain en el registro y, por consiguiente, la trazabilidad de los activos de propiedad intelectual. Desde luego, teniendo en cuenta las características propias de la blockchain (no olvidemos que todas las operaciones de la cadena de bloques quedan garantizadas y registradas en un libro mayor distribuido que no puede ser alterado y que es transparente) no cabe duda de que se trata de una herramienta idónea para este tipo de funciones.

De hecho, como mencionamos en la introducción, desde ciertas organizaciones supranacionales (UE, OMPI) se están impulsando proyectos en este sentido. Entre estas iniciativas nos parece especialmente reseñable el llamado Anti-Counterfeiting Blockathon Forum, impulsado desde la Unión Europea. Este foro se enmarca en la estrategia de la UE para crear un ecosistema de blockchain (EBSI/CEF) y deriva del “Blockathon 2018”, organizado conjuntamente por la Comisión Europea y la Oficina de Propiedad Intelectual de la Unión Europea²⁹.

La pretensión subyacente en este tipo de iniciativas es crear un registro de autenticidad seguro y “compartido” que permita facilitar la detección de elementos falsificados y que pueda ser utilizado por cualquier persona interesada (desde las oficinas de propiedad intelectual y los productores a los consumidores, pasando por los “intermediarios” -i.e. empresas de transporte, prestadores de servicios de la sociedad de la información).

Hemos de tener presente que, en la actualidad, si bien es cierto que existen ya herramientas y soluciones utilizadas para identificar las falsificaciones, estas se encuentran dispersas, no aparecen sincronizadas y no son accesibles a todos los actores que intervienen en el comercio de los bienes protegidos por el diseño industrial.

Por otro lado, no hay que olvidar que en la actualidad nos encontramos con una maraña de disposiciones y procedimientos legislativos y reglamentarios, normas y principios que ordenan una amplia gama de prácticas de registro transnacionales y transjurisdiccionales. La implementación de redes de blockchain permitiría una simultaneidad en el intercambio de información y datos entre las autoridades administrativas y jurisdiccionales, proporcionando una mejora sustancial en la detección de fraudes y en la coordinación jurisdiccional. No obstante, estamos con Herian³⁰, en su afirmación de que, al menos por el momento, una descentralización total del sistema (como la buscada in fine , al menos su espíritu clásico, por la blockchain) no sería posible ya que sería necesario un alto grado de control centralizado de los registros dentro de cada jurisdicción, especialmente en los procedimientos de entrada registral, y además sería necesario, mantener prácticas de auditoría sólidas y razonables respecto a la actividad empresarial.

Por otro lado, y al hilo de lo anterior, en el diseño de la blockchain para la protección del diseño industrial sería necesario tomar en consideración una serie de elementos que pueden considerarse clave para la propia existencia de la protección del diseño y que no son sino las diferentes vicisitudes que pueden acontecer y que están previstas por la ley.

Así, en primer lugar, hemos de tener en cuenta que el diseño, tiene una protección provisional desde el momento de la solicitud, protección que se verá confirmada si finalmente el diseño queda registrado. En el caso de establecerse que la solicitud quedara registrada por medio de una blockchain habría de programarse el carácter diferenciado entre esta y el registro definitivo, pudiéndose distinguir, por tanto, también a la hora de comenzar a realizar negocios en el tráfico antes del registro definitivo del diseño. El problema respecto a esta última cuestión radicará, como veremos en el apartado siguiente, en las dificultades existentes, al menos por el momento, a la hora de “revertir” o incluso “detener” la ejecución de un smart contract debido sus propias características de programación (ver infra 3.3).

Habremos de tener en cuenta además tres posibles circunstancias que pueden afectar el registro de un diseño y, por tanto, también los contratos potenciales de explotación sobre el mismo (licencias) que, como sabemos, deben ser también inscritos registralmente en el registro correspondiente. Estas circunstancias son: la nulidad, la caducidad y la renuncia. Si bien, estas situaciones a nivel puramente registral en la cadena de bloques (esto es, a nivel de la anotación del acaecimiento de estas circunstancias) no revisten, a nuestro entender, mayor problema, cosa distinta sucederá con la coordinación de los efectos de estas situaciones en los contratos (licencias) concluidos en base a la existencia del derecho de exclusiva sobre el diseño (ver infra 3.3.).

Decimos que no supondrá un problema mayor a nivel registral y ya que bastará con la introducción de esta nueva información en la cadena de bloques (nulidad, renuncia o caducidad), lo que tendrá programado como consecuencia inmediata el cese de la protección otorgada. Teniendo en cuenta que, en este contexto, la blockchain se concibe como un registro “compartido” por todos los actores interesados, estas circunstancias podrán ser, por tanto, conocidas por cualquiera de ellos.

Más compleja nos parece la integración de la figura del diseño no registrado en la cadena de bloques, al depender su protección de elementos externos a una realidad registral.

En todo caso, el éxito de este tipo de iniciativas, como se deduce fácilmente de lo anterior, es la integración en la misma “infraestructura” de la blockchain de todos estos actores que mencionábamos. Para una consecución óptima de este tipo de proyectos se necesitará, por tanto, la integración en la construcción de la parte estructural de la cadena de bloques, por lo menos, tanto de las autoridades administrativas como de las jurisdiccionales encargadas tanto del registro como de la determinación de la existencia de circunstancias que determinan la finalización de la existencia de dicho derecho exclusivo. Es, por consiguiente, necesaria una concienciación y coordinación entre estas instituciones para que este tipo de iniciativas logren el resultado esperado.

3.3. Explotación y comercialización del diseño industrial por medio de la blockchain

La integración de la blockchain en estas actividades pasa por la configuración de las licencias de explotación y uso por medio de smart contracts. La concesión de licencias por medio de estos protocolos automatizados como vimos en el apartado anterior (que denominaramos smart licences), ya ha sido experimentada, especialmente en el ámbito de las obras musicales. Las ventajas de los smart contracts son indudables debido a sus características inherentes ya que implican tanto una eficacia en su ejecución y una economía en los costes de intermediación significativas (recordemos que son autoejecutables, transparentes y trazables).

En este caso, las smart licences plasmarán un contrato entre las partes, esto es, el acuerdo de licencia, debiendo reflejar las condiciones en las que la misma se ha concedido. Esta circunstancia nos lleva a plantearnos una serie de reflexiones, muchas de ellas comunes a cualquier tipo de smart contract, que es necesario tener presente a la hora de configurar estas smart licences.

En primer lugar, como cualquier contrato debe ser producto del acuerdo de voluntades entre las partes, esto es, debe reflejar lo que se ha estipulado entre ellas. Teniendo en cuenta que la smart licence, como tal, estará escrita en un lenguaje informático determinado (i.e. Solidity o Python), salvo que los contratantes sean capaces de “leer” este código será pertinente, sino necesario, la existencia de un contrato en lenguaje humano en el cual se establezcan de manera completamente clara las estipulaciones acordadas, debiendo realizarse la “traducción” a código-máquina de manera fidedigna.

Estas estipulaciones, además deberán estar consensuadas de manera transparente. Recordemos que los smart contrats responden esencialmente al esquema I-T-E, en el cual las consecuencias de las acciones deben estar predeterminadas de manera exacta. Es ya casi lugar común afirmar que los smart contracts no pueden conocer, debido que no son protocolos de programación, de ambigüedades ni de conceptos indeterminados (tales como la buena fe o la diligencia debida). Por consiguiente, el nivel de detalle y precisión en las condiciones contractuales debe ser extremado. Vemos, por tanto, que estamos ante un sistema que adolece de una rigidez que contrasta con la realidad contractual.

Por otro lado, en esta “traducción” al lenguaje de programación del smart contract no deberían existir discrepancias entre lo acordado entre las partes y el código del primero. Tengamos en cuenta que los smart contracts (smart licences en nuestro caso) se caracterizan porque son autoejecutables e inmutabilidad, con lo cual, una vez que empieza la ejecución del mismo, en principio, no pueden ser alterado³¹.

Esta característica supone un importante problema de implementación, si tenemos en cuenta que pueden darse circunstancias en las que sea necesaria una rectificación del código y, por ende, una alteración en ciertas condiciones del contrato.

Entre estas situaciones encontramos desde la existencia de discrepancias entre lo acordado entre las partes y lo programado en la smart licence hasta la necesidad de la coordinación entre la smart licence y las circunstancias registrales del diseño (i.e. nulidad, caducidad, renuncia).

Respecto a la primera de las cuestiones planteadas, existen ciertas soluciones preventivas que deben ser tenidas en cuenta a la hora de utilizar una smart licence. En primer lugar, aunque parezca obvio, a nivel “usuario” será necesario una colaboración estrecha entre programadores y juristas encargados de la concepción de la smart licence para que haya una perfecta sincronización entre el texto del contrato en lenguaje natural y su plasmación en el protocolo de la smart licence. En segundo lugar, desde una perspectiva comercial internacional sería recomendable la existencia de “estándares” que permitieran la contratación por smart contracts con mayores garantías y una comprensión uniforme sobre ciertos aspectos. De hecho, esta es una de las cuestiones más discutidas en la actualidad ya que son necesarios a la hora de adaptar las múltiples configuraciones de los smart contracts³² a la realidad comercial. Por último, y hasta que exista una mayor estandarización, sería recomendable, especialmente en el caso de pluralidad de licencias, el establecimiento entre las partes de un data meaning agreement en el cual se determinen claramente el significado de ciertos aspectos del código desarrollado en la smart licence para evitar conflictos posteriores.

Respecto a la cuestión de las posibles vicisitudes que sufra el derecho exclusivo sobre el diseño e incluso sobre la misma existencia de este derecho exclusivo licenciado en la smart licence, hemos de recordar que la blockchain verifica y certifica la existencia o realidad de los datos (informaciones) que son introducidos en el sistema, pero no analiza la naturaleza o la licitud de estos datos.

No olvidemos que en la blockchain los activos del mundo exterior están tokenizados y los nodos validadores de la cadena de bloques certifican la veracidad información que les ha sido transmitida. No obstante, si no existe un control en la entrada (oráculo) respecto los datos verificados por la cadena podremos encontrarnos con smart contracts que contienen datos imprecisos (o incluso ilícitos).

Por consiguiente, y, también, de manera preventiva, será necesaria una coordinación entre la realidad registral y las smart licences. Hasta la creación de la o las blockchains asociadas a la realidad registral que mencionábamos en el apartado precedente (3.2.), se habrá de tener en cuenta el establecimiento de oráculos que permitan verificar la existencia del registro (bastaría con un software de monitoreo) y la previsión a la hora de programar la smart licence de los efectos de la extinción del derecho.

Esta última cuestión relativa a los efectos de la extinción del derecho, nos lleva a analizar un aspecto de suma importancia para la propia implementación general de los smart contracts (y, por ende, de las smart licences): ¿qué hacer cuando existe una alteración de las condiciones estipuladas inicialmente? Imaginemos, por ejemplo, un reparto de una remuneración debida por la explotación diseño industrial entre varios titulares de derechos o donde exista una remuneración variable, cuya “smart licence” contenga un error o una imprecisión o pensemos que se haya declarado la nulidad del registro del diseño o que haya un desacuerdo entre las partes o simplemente una modificación de las condiciones contractuales… ¿Cómo alteramos los efectos programados para su autoejecución si partimos del principio de que este tipo de “contratos” son inmutables? Si bien ya existen ciertas soluciones técnicas (i.e. la operación selfdestruct en Etherem³³), estas siguen siendo poco aplicadas y, además, el empleo de las mismas suscita no pocos interrogantes (¿Quién autoriza la programación de una función de “autodestrucción” del smart contract… una de las partes, las dos por consenso, un oráculo, el juez? ¿qué consecuencias tiene esta “autodestrucción”? ¿Qué pasa si estamos hablando de una modificación parcial y no total que supone una alteración de ciertas condiciones estipuladas? ¿qué pasa cuando la licencia sobre el derecho está estipulada en un smart contract que formaliza, además, otras relaciones entre las partes y cuyas cláusulas se va a ver alteradas por la extinción del derecho exclusivo?).

Vemos, por tanto, que es necesario avanzar todavía en el establecimiento determinadas soluciones tanto técnicas como jurídicas para poder dar una respuesta a estos interrogantes.

3.4. Conflictos relativos a los diseños industriales y su compatibilidad con la blockchain

Last but not least, nos encontramos con la necesidad de plantearnos la manera en la que se podrían implementar ciertos aspectos inherentes a la protección por el diseño industrial en el caso de la implementación de manera generalizada de las blockchains para el registro del derechos de propiedad industrial y las smart licences.

En primer lugar, un determinado bien protegido por un diseño industrial puede tener una pluralidad de protecciones por parte de otros derechos de propiedad intelectual e industrial (i.e. marca, derecho de autor). Por otro lado, este mismo diseño puede entrar en conflicto con otros signos de propiedad intelectual e industrial. El segundo de los supuestos planteado podría dar lugar, potencial, a situaciones de modificación o anulación de los derechos exclusivos, generando los problemas que hemos analizado en el apartado anterior respecto a la modificación o anulación de una smart licence. No obstante, en el primero de los supuestos planteados, esto es, la acumulación de protecciones estamos ante un caso diferente.

En este caso, se habrá de tener presente la existencia de otros derechos exclusivos sobre el mismo objeto a la hora de “diseñar” el smart contract pertinente. Aquí, sin ánimo de ser exhaustivos, nos encontramos con la dificultad de plasmar la complejidad que llevan aparejados este tipo de contratos y la simplicidad del lenguaje máquina. En todo caso, sería fundamental una excelente sincronización entre la smart licence y los pertinentes registros afectados a fin de poder garantizar la seguridad jurídica, así como el establecimiento de remuneraciones diferenciadas para cada tipo de derecho protegido para poder implementar de una manera más simple las consecuencias de la extinción de cada uno de estos derechos.

Por otro lado, otro de los verdaderos retos en la implementación de la blockchain es el reconocimiento legislativo de ciertos límites a los derechos exclusivos. Dentro de estas situaciones encontramos, por ejemplo, el agotamiento del derecho, el derecho de uso anterior del diseño o la excepción de cita o ilustración para la enseñanza.

Dos son los aspectos relevantes en este caso: por un lado, la falta de uniformidad tanto en la configuración de la legislación sobre el diseño así como en la interpretación jurisprudencial de los límites³⁴, lo que hace que sea complicado el establecimiento de soluciones estandarizadas para este caso y la necesidad del establecimiento de mecanismos que permitan detectar de manera automatizada aquellos los usos autorizados legalmente sobre los que no es necesaria, por consiguiente, ningún tipo de licencia o autorización.