Últimamente se está hablando bastante sobre la “Ley de Ciberresiliencia” (o “Cyber Resilience Act”, CRA), porque su redacción puede afectar negativamente al software libre. Véase, por ejemplo:

https://news.apache.org/foundation/entry/save-open-source-the-impending-tragedy-of-the-cyber-resilience-act

https://www.joomla.org/announcements/general-news/5891-open-letter-foss-cms-cyber-resilience-act.html

https://fsfe.org/news/2023/news-20230719-01.html

Así que al final yo me he liado la manta a la cabeza, he leído textos, he hecho mis análisis, y he redactado un texto de casi 3000 palabras explayándome en las razones de por qué la CRA es problemática.

Muy muy seguramente envíe este texto al Ministerio de Economía (perdón, de “Asuntos Económicos y Transformación Digital”) en una semana o así. Mientras tanto dejo el texto aquí por si alguien fuere capaz de detectar algún error flagrante (escribidme un correo electrónico o lo que sea), y si no, pues para referencia en posteridad. El escrito ha sido presentado el domingo 10 de septiembre en el registro electrónico general, con nº de registro de entrada REGAGE23e00060407370.

Hay un par de cartas abiertas y artículos de los que he tenido conocimiento después de enviar el escrito. Son:

https://moodle.com/news/an-open-letter-to-eu-legislators-from-moodle/

https://www.lawfaremedia.org/article/three-questions-on-software-liability

https://www.vrijschrift.org/serendipity/index.php?/archives/260-German-car-industry-explains-why-Cyber-Resilience-Act-will-harm-open-source-software.html

https://www.linuxfoundation.org/blog/understanding-the-cyber-resilience-act

https://newsroom.eclipse.org/news/announcements/cra-should-support-open-practices-open-source-and-development-european-open

https://berthub.eu/articles/posts/eu-cra-best-open-source-security/

https://www.debian.org/vote/2023/vote_002

https://berthub.eu/articles/posts/eu-cra-best-open-source-security/

https://blog.nlnetlabs.nl/open-source-software-vs-the-cyber-resilience-act/

Texto de la propuesta de ley a diciembre 2023: https://berthub.eu/cra/cra-coreper-en23.pdf

Off-topic, reflexiones sobre “post-open source”: https://www.theregister.com/2023/12/27/bruce_perens_post_open/


A/Att. Dª Carme Artigas Brugal

Secretaría de Estado de Digitalización e Inteligencia Artificial

Ministerio de Asuntos Económicos y Transformación Digital

Estimada Sra. Carme Artigas Brugal,

Le escribo con respecto a la propuesta legislativa europea conocida como Ley de Ciberresiliencia o Cyber Resilience Act (CRA).

Me presentaré. Soy Iván Sánchez Ortega, madrileño de nacimiento e informático de vocación. Profesionalmente estoy especializado en los ámbitos del software libre y de la geomática. Soy miembro de número de la fundación Open Source Geospatial (OSGeo), ex-miembro de la junta directiva de la fundación OpenStreetMap (OSMF), miembro del Grupo de Trabajo de Infraestructuras de Datos Espaciales de España (GT-IDEE), y miembro del Open Geospatial Consortium (OGC), entre otros.

Al igual que otras personas del ámbito del software libre, me inquieta la CRA en su redacción actual, y comparto muchas de sus preocupaciones. Tras haber leído los comunicados de (entre otros) la Apache Software Foundation, Github (Microsoft), Joomla, Free Software Foundation Europa, Open Source Initiative, y tras haber leído y analizado la propuesta legislativa, considero que estoy en posición de ofrecer una opinión formada.

El resultado de mi análisis es el siguiente: El legislador es ignorante de la naturaleza del objeto que está legislando. En particular, el legislador es ignorante de la naturaleza del software libre y de código abierto. El dar por supuesta la naturaleza incorrecta de la cosa que se está legislando tendría como consecuencia una enorme inseguridad jurídica si la CRA se aprobase en su forma actual.

De la redacción de la propuesta de CRA se puede deducir que el legislador entiende los programas de ordenador (o software) como objetos físicos, susceptiles de ser fabricados, comprados, vendidos y reparados. A lo largo del texto de la CRA se habla de «mercado», dando a entender que el software es una mercancía.

Sin embargo, los programas de ordenador son objeto de Propiedad Intelectual, tal y como establece la Ley de Propiedad Intelectual (LPI) española (BOE 22/04/1996). (Recordemos que la LPI española transpone varias directivas europeas y por tanto está armonizada con las LLPI de otros países miembros de la Unión Europea.) Resulta, por tanto, sorprendente la ausencia de referencias a la Propiedad Intelectual en las bases jurídicas de la CRA. Un reglamento que legisle los programas de ordenador debería estar armonizado con la legislación de Propiedad Intelectual.

El objeto de mercadería, por tanto, no es el software en sí, sino los derechos de explotación del software. Aunque en la CRA se dan por supuestas las figuras jurídicas del fabricante, del distribuidor y del importador (véase CRA, art. 3), cuando hablamos de programas de ordenador debemos referirnos a las figuras jurídicas del autor (propietario inalienable de derechos morales) y del titular de derechos de explotación (al que podemos llamar, literalmente, explotador). Esta discordancia entre figuras jurídicas es harto problemática.

Es más problemática la escuetísima definición que la CRA hace sobre software libre o de código abierto, que se encuentra únicamente en el punto 10 del preámbulo. La redacción de la CRA induce a pensar que el legislador hace equivaler “no comercial” con “código abierto”. Creo, por tanto, necesario el ahondar en la naturaleza del software libre.

Las personas que, como yo, nos consideramos activistas del software libre (y asimismo de la cultura libre) somos de la opinión de que la legislación de Propiedad Intelectual, de naturaleza restrictiva, en última instancia opera en contra del desarrollo de las artes y las ciencias, y a favor de la concentración de capital económico. Si bien la idea teórica expuesta en los preámbulos legislativos es que una mayor “protección” debe inducir a un mayor atractivo para crear más y mejor arte y ciencia, nuestro entendimiento del status quo es que esa “protección” se aplica, en la aplastante mayoría de las ocasiones, no en nombre de los autores sino en beneficio de los propietarios de los derechos de explotación (para ejemplo, baste con observar las actuales huelgas de guionistas y actores en EEUU).

Escribo “protección” entre comillas porque, a efectos prácticos, se trata de limitaciones. El problema no es la limitación del software el sí, sino las limitaciones artificiales que el software impone a todo lo que le rodea, amparadas en la excusa de la Propiedad Intelectual. Creemos que las libertades del usuario deben primar por encima de la libertad para imponer restricciones que ostenta el propietario de los derechos de explotación.

Es necesario entender (aunque no necesariamente compartir) esta postura política para poder entender la naturaleza del software libre.

El software libre tiene un carácter marcadamente emancipativo. En síntesis, el objetivo del software libre es que el usuario pueda emanciparse digitalmente, es hacer que el usuario deje de estar sujeto a las restricciones artificiales impuestas, es hacer que deje de depender del propietario de los derechos de explotación. Cualquier emancipación, incluída esta, conlleva también una toma de responsabilidades.

La manera en la que el software libre desbarata el status quo de depender del propietario de los derechos de explotación es, paradójicamente, mediante el ejercicio de los derechos de Propiedad Intelectual. Como dice Javier de la Cueva en su Manual del Ciberactivista:

El [código jurídico] propone licencias de propiedad intelectual en las que se evidencie de antemano la posibilidad legal de reutilización de la información, sin necesidad de petición de permiso alguno.

Cuando se crea un programa de ordenador, el autor es el poseedor único de todos los derechos morales y de explotación sobre ese programa. Si el autor decide que ese programa sea software libre, éste impone un contrato de licencia que, en esencia, dice «usted puede explotar este programa si y sólo si usted (a) respeta mis derechos morales (b) asume toda responsabilidad y (c) las copias que distribuyere de este programa las distribuya bajo esta misma licencia». Un programa bajo esta licencia nunca podrá ser usado de manera limitante, puesto que todo usuario podrá ejercer siempre todos los derechos de explotación.

Llevando la idea al conjunto, se crea un corpus de programas de ordenador que son irrestringibles y emancipativos, disponibles para todos, disfrutable por todos y responsabilidad de todos. Este corpus puede definirse como un procomún, un bien de provecho común y titularidad compartida.

Para entender mejor el concepto de “procomún” podemos referirnos a las palabras de Antonio Lafuente en una entrevista de 2012:

[El procomún es] lo que es de todos y de nadie al mismo tiempo. En el castellano antiguo más que describir una cosa, da cuenta de una actividad que se hace en provecho de todos. El procomún, los commons, en todo caso, no es definible, porque evoca la existencia de bienes muy heterogéneos que van desde los viejos pastos comunales a los nuevos mundos de la biodiversidad, el folclore o la gastronomía. […] ¿Por qué tanto ronroneo sobre la cultura popular, la privacidad o la seguridad? La respuesta es simple: disponemos de tecnologías que permiten convertir estos saberes en recursos y, a continuación, mercadear con ellos.

Así como a las palabras de Stefano Rodotá en “Tecnopolítica: la democracia y las nuevas tecnologías de la comunicación” (ISBN 9500371901):

Los bienes comunes son de «titularidad difusa», pertenecen a todos y a ninguno, en el sentido de que todos deben poder acceder a ellos y nadie puede alardear de tener pretensiones exclusivas sobre ellos. Deben administrarse partiendo del principio de solidaridad. Incorporan la dimensión de futuro y, en consecuencia, deben gobernarse también en el interés de las generaciones venideras. En este sentido son propiamente un «patrimonio de la humanidad» y cada cual debe estar en condiciones de defenderlos incluso tutelando un bien alejado del lugar en el que vive.

Si bien se supone que el jurista y el legislador deberían con estas descripciones tener una idea del concepto filosófico de procomún, conviene ilustrar el concepto de “el software libre es un procomún del conocimiento” mediante una sencillísima alegoría: la jurisprudencia es un procomún del conocimiento.

Las normas (como las leyes, reglamentos, dictámenes, disposiciones, bando o incluso las resoluciones administrativas o judiciales) son una obra intelectual - nacen del ingenio y la creatividad del jurista, en base a un problema a resolver o una situación a mejorar. De igual manera, un programa de ordenador nace del ingenio y la creatividad del programador, en base a un problema a resolver o una situación a mejorar. Una ley se puede copiar; se puede analizar; se hace valer mediante su interpretación y ejecución. Y de igual manera, un programa de ordenador se puede copiar; se puede analizar; se hace valer mediante su interpretación y ejecución.

El jurista sabe, inconscientemente, que puede aprovechar cualquier parte del corpus jurídico, y asimismo sabe que cuando aporte a ese corpus, cualquier otro jurista podrá aprovechar esa aportación. Y este corpus, este procomún, no se “protege” mediante la limitación, sino que se da por hecho que el mantenimiento de este procomún es algo necesario para el funcionamiento de una sociedad ilustrada, por lo que su mantenimiento recae sobre El Estado.

Cabría plantear la idea de un “mercado” de jurisprudencia, donde cada conjunto de normas e instrucciones tuviera un precio, y donde cada jurista ingresara más o menos dinero dependiendo de cuántas copias de sus normas se distribuyen y/o se hacen valer. Puesto que el jurista está acostumbrado a la idea de un procomún jurídico, la idea de un mercado jurídico resulta ridícula.

Con esto debería quedar demostrado que un procomún no es un mercado. Las estructuras de incentivos y de responsabilidades de un procomún son muy distintas de las estructuras de incentivos y responsabilidades de un mercado. La idea de la no mercantilidad del procomún la remarca Mayo Fuster en “Procomún digital y cultura libre. ¿Hacia un cambio de época?” (ISBN 8498886414):

Los procomunes digitales se definen como los recursos de información y de conocimiento que se crean, se poseen y se comparten de forma colectiva entre una comunidad y que tienden a no ser exclusivos, es decir, que (generalmente de forma libre) están a disposición de terceros y terceras. Por lo tanto, se orientan a favorecer el uso y la reutilización, en lugar del intercambio de una mercancía.

Mi lectura y análisis de la CRA me permite imaginar el concepto que el legislador tiene sobre el software libre y de fuentes abiertas: es un mero añadido al mercado de programas de ordenador que, de algún modo arcano que no entra a analizar, reduce los costes y promueve la innovación y la investigación.

Yo puedo comprender por qué el legislador opina de esta manera. El software libre y de código abierto se ha popularizado durante la última década como una manera de reducir los costes del desarrollo de programas de ordenador. Esto se ha hecho pervirtiendo el espíritu de las licencias de software libre (en particular, la exoneración de responsabilidad) para invertir el contrato social existente. Si bien hace un par de décadas se podía esperar del usuario de software libre que asumiera la responsabilidad de sus acciones, hoy en día el contrato social aparente es que el usuario de software libre cree tener la capacidad y la autoridad para exigir al autor la responsabilidad de corregir el programa.

La discordancia entre la exoneración jurídica de responsabilidad y el sentimiento de responsabilidad social se ve acuciada por la nomenclatura del asunto en el idioma anglosajón. Se usa la expresión “free software”, que también puede traducirse literalmente como “programas gratis”; esto induce a pensar, erróneamente, que el software libre se comporta de igual manera que el software del mercado, solo que gratis, a coste cero. En esta línea, y como respuesta a la CRA, la Open Source Initiative recientemente ha publicado un escrito titulado «El lenguaje regulatorio no puede ser el mismo para todo el software».

La redacción de la CRA parece caer en este craso error de interpretar “free” como “gratis”. Esto se deduce de la redacción del punto 10 de la propuesta, que mezcla «los programas informáticos libres y de código abierto» con los «programas desarrollados o suministrados al margen de una actividad comercial».

Si pasamos por alto el hecho de que la CRA no especifica claramente qué es «al margen de una actividad comercial», podríamos suponer que la CRA afecta únicamente programas del mercado, y no a programas del procomún.

Por desgracia, esta suposición está en contra del espíritu de la CRA, que en mi interpretación persigue mejorar la seguridad de todos los programas de ordenador en uso, y no sólo de aquellos disponibles en el mercado. De hecho, en el informe de evaluación de impacto (“Impact Assessment Report”) de la CRA se nombra explícitamente log4j, que no pertenece al mercado sino al procomún; y sin embargo log4j es un componente de productos disponibles en el mercado. Cabe preguntarse, pues: ¿Se aplica la CRA a log4j? ¿Sí se aplica, pero únicamente cuando pasa a ser parte de un producto del mercado? Si ese es el caso, ¿acarrearía el autor original alguna responsabilidad?

El asunto de la responsabilidad es el que más preocupa. Recordemos que el software libre se fundamenta jurídicamente en contratos de licencia de explotación que en esencia dicen «usted puede explotar este programa si y sólo si usted […] asume toda responsabilidad». ¿Puede la CRA anteponerse a esta exoneración de responsabilidad?

Leyendo el texto de la Licencia Pública de la Unión Europea (o EUPL), punto 7 párrafo 3 de su versión 1.2, se entiende que la respuesta es negativa:

Esta exclusión de garantía forma parte esencial de la licencia y es condición para la cesión de cualquier derecho con respecto a la obra.

No obstante, el punto 8 de la EUPL parece decir algo contradictorio:

No obstante, el licenciante será responsable, de acuerdo con las normas legales que regulen la responsabilidad por los daños causados por productos, en la medida en que dichas normas sean aplicables a la obra.

Puesto que la CRA pretende regular «productos con elementos digitales», estaría dentro de esta excepción de la EUPL. Dado que la EUPL nació (entre otras causas) por la problemática jurídica de interpretar licencias de software libre enmarcadas en la legislación estadounidense, cabe esperar que la interpretación que los juzgados europeos hicieren sobre otras licencias de software libre (véase apéndice de la EUPL) apliquen esta excepción a otras licencias.

La responsabilidad que, por tanto, la CRA impone sobre el autor original del programa de ordenador es excesiva, tanto en la opinión de entidades expertas en software libre como en mi opinión personal. Por poner un ejemplo que me atañe particularmente: yo soy el coautor de diversos programas de ordenador que se usan de manera rutinaria en el Instituto Geográfico Nacional (IGN), la Agencia Estatal de Meterología (AEMet), entre otros muchos organismos europeos involucrados en tareas cartográficas. Los programas de los que soy coautor se explotan a veces directamente, a veces indirectamente (como componentes en programas más complejos), pero en todo caso esta explotación se realiza a través de licencias de software libre, sin que haya por mi parte decisión alguna ni conocimiento previo. En el hipotético (pero posible) caso de que mis programas tengan defectos de seguridad (puesto que algunos de ellos gestionan credenciales de acceso a servicios cartográficos), y si esto causare un hipotético daño en una infraestructura operada por el IGN (o AEMet aut cetera), mi interpretación es que se me puede considerar responsable de ese daño.

Puedo conjeturar un método para garantizar mi seguridad jurídica, y es el utilizar licencias de software libre que explícitamente exoneren las responsabilidades relativas a la CRA, sin que quepa interpretación contraria por parte de la justicia europea, y redactadas de tal manera que la posibilidad de esa exoneración de responsabilidad sea condición necesaria para la cesión de derechos; o alternativamente enmendar licencias existentes al mismo efecto. De tal manera, si fuese imposible exonerar esta responsabilidad, se estarían ejerciendo los derechos de explotación de los programas de manera ilícita.

Me consta también que varias entidades de sofware libre están considerando la posibilidad de ejercer acciones (tanto jurídicas como pragmáticas) para limitar la publicación de programas de ordenador en la Unión Europea como respuesta a la CRA, precisamente con el fin de reducir la responsabilidad jurídica de los autores de programas.

Sea como fuere, la CRA en su forma actual se podría enfrentar a una respuesta coordinada que traería como consecuencia la privación del uso, dentro del contexto de la Unión Europea, de multitud de programas. Las consecuencias de esta respuesta a la CRA serían obviamente nefastas para el desarrollo de los países de la unión.

Es sabido que Europa está luchando por su soberanía digital. Esta soberanía está íntimamente ligada a una emancipación digital de Europa (e incluso pueden considerarse soberanía y emancipación como la misma cosa). Pero para conseguir esta emancipación, Europa debe también definir y aceptar sus responsabilidades.


Expuesto todo lo anterior, ante usted comparezco y como mejor proceda en derecho ruego que se traspongan a la propuesta de Ley de Ciberresiliencia las siguientes

RECOMENDACIONES

  1. Debe atenderse la naturaleza jurídica de los programas de ordenador, incluyéndose la legislación de Propiedad Intelectual y las figuras jurídicas que se ésta se desprenden.

  2. Debe atenderse la especial naturaleza jurídica y filosófica del software libre, sus características emancipativas y su calidad de procomún.

  3. Deben promoverse, y no castigarse, el desarrollo y la mejora de programas de ordenador dentro del procomún de software libre; por tanto, debe limitarse la responsabilidad de los autores de software libre.

  4. Debe excluirse de la definición de procomún de software libre a aquellos programas que dependan o tengan como requisito o componente programas que no pertenezcan a dicho procomún, o que dependan de algún elemento electrónico (hardware) que esté sujeto a restricciones prácticas o jurídicas (como por ejemplo patentes).

  5. Deben garantizarse las cláusulas de exoneración de responsabilidad existentes en las licencias de software libre, debiendo recaer la responsabilidad sobre la persona que ejercita los derechos de explotación de los programas; debe asimismo clarificarse la situación en la que sean varias personas las que ejerzan los derechos de explotación de manera simultánea, así como las situaciones en las que los derechos de explotación se sublicencien sucesiva y repetidamente.

  6. Debe clarificarse si (o bajo qué condiciones) la responsabilidad recae sobre la figura jurídica del autor (propietario de los derechos morales del programa), o sobre la figura jurídica del propietario de los derechos de explotación; en particular debe atenderse la suposición que se hace en el artículo 97.4 de la LPI.

  7. Caso de que se mantengan las referencias a “actividad comercial” relativa a los programas de ordenador, debe clarificarse con suma precisión en qué consiste y en qué no consiste tal actividad, debiendo estar su definición alineada con las diversas modalidades existentes de contratos de cesión de derechos de explotación de programas de ordenador; debe clarificarse en particular si (o bajo qué condiciones) un intercambio monetario no vinculado directamente a un contrato de cesión de derechos (p. ej. donaciones a autores) constituye (o no) una actividad comercial.

  8. Deben establecerse mecanismos no punitivos para alcanzar los objetivos de la CRA; dichos mecanismos pueden consistir en asignar a entidades de la Unión Europea labores relativas al procomún del sotware libre como puedan ser:

    8.1. Autoría, mantenimiento, publicación y/o distribución de programas.

    8.2. Gestión proactiva de descubrimiento y divulgación de vulnerabilidades.

    8.3. Tramitación proactiva del marcado CE.

    8.4. Elaboración, traducción y publicación de documentación técnica.

    8.5. Gestión de las nomenclaturas de materiales (listado de dependencias o “bill of materials”)

  9. Deben establecerse mecanismos para garantizar la seguridad de los productos con elementos digitales que se introduzcan al mercado, una vez transcurridos cinco años desde dicha inroducción; dichos mecanismos pueden consistir en el depósito de los programas de ordenador relativos al producto, incluídos su código fuente, más las instrucciones y herramientas necesarias para integrar los programas en el producto final, procediéndose al embargo de los derechos de explotación de dichos programas a favor del procomún transcurrido este tiempo, facilitándose de tal manera que sean los propios usuarios de los productos los que puedan tomar la responsbilidad de garantizar su propia seguridad.

OTROSÍ RUEGO

Que se facilite copia de la presente a cualesquiera personas involucradas en la redacción de la CRA.