Volver a página de inicio

I. Introducción

Los Open Source Software (en adelante, «OSS») juegan un papel fundamental en el desarrollo de las Pymes (1) , y aún más, si se combinan con otros sistemas operativos como son las plataformas SAS y los Serverless Architecture. La principal razón radica en que les permite impulsar y consolidar su negocio minimizando los costes de inversión inicial, y eliminando la infraestructura de mantenimiento. Más allá de esa perspectiva, es una fuente de conocimiento y creación «cooperativo». Así lo entiende una de las principales consultoras estratégicas mundiales: MCKINSEY (2) . En concreto, a finales del año pasado anunciaron el lanzamiento de un ecosistema de OSS propio que alberga sus propios productos; incluyéndose aquí tecnologías de vanguardia en cuestiones de IA, IA generativa o cloud. Este OSS se denomina Vizro.

Si bien las ventajas de los OSS son indudables, no están exentos de hándicaps en relación tanto con la privacidad como la ciberseguridad. De hecho, al tratarse de códigos de dominio público, es más probable que los hackers encuentren más vulnerabilidades en comparación con los softwares cerrados. En este sentido (3) , en aplicación de los artículos 25 (diseño de medidas técnicas y organizativas para la salvaguarda de la privacidad) y 32 (seguridad del tratamiento) del Reglamento (UE) 2016/679 de 27 de abril de 2016 (LA LEY 6637/2016) relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos (en adelante, «RGPDP»), en relación con los OSS, es aconsejable implementar las siguientes prácticas:

• i) Pseudonimizacion o cifrar los datos personales siempre que sea posible.
• ii) La encriptación.
• iii) Revisar y analizar todos los sistemas o servicios de tratamiento de datos y seguridad antes de implantarlos.
• iv) Comprobar, valorar y evaluar periódicamente la eficacia de las medidas técnicas y organizativas para garantizar la seguridad.
• v) Finalmente, la configuración de un sistema o proceso para comprobar regularmente todos los programas informáticos, aplicaciones y servicios de tratamiento de datos en busca de nuevas actualizaciones, parches o simplemente para la implementación de las medidas de mantenimiento necesarias.

Estos esquemas, líneas de actuación, han sido implementados en la práctica por uno de los principales OSS: WORDPRESS. De la lectura de su guía de seguridad (4) , cabe subrayar: i) la encriptación por defecto, a través de SSL, sin que sea posible su desactivación; ii) la monitorización de la actividad sospechosa; iii) la implantación del Jetpack Scan para alertar de posibles riesgos de seguridad y, finalmente, iv) la existencia de un equipo dedicado en exclusividad a la salvaguarda de la privacidad y ciberseguridad.

A grandes rasgos, este era el esquema legal y las líneas principales de actuación hasta que la Unión Europea, en septiembre de 2022, publicó la primera versión de la Propuesta (5) de Reglamento del Parlamento Europeo y del Consejo relativo a los requisitos horizontales de ciberseguridad para los productos con elementos digitales y por el que se modifica el Reglamento (UE) 2019/1020 (LA LEY 11044/2019) (en adelante, «Reglamento de Ciberresilencia versión de 2022») causando una gran turbulencia en su «tablón de juego».

II. El Reglamento de Ciberresilencia: luces y sombras para el OSS

Como he mencionado anteriormente, la publicación del Reglamento de Ciberresilencia versión 2022 causó un auténtico terremoto en el campo OSS de la Unión Europea. Contextualizando, el Reglamento de Ciberresilencia versión 2022 nace como consecuencia de la creciente preocupación de la Unión Europea hacia los cada vez más frecuentes ciberataques exitosos de los que son víctimas tanto lo hardwares como los softwares informáticos. En este sentido, con la base legal de garantizar un mercado interior común seguro —artículo 114 del Tratado de Funcionamiento de la Unión Europea (LA LEY 6/1957) (en adelante, «TFUE»)—, la Comisión Europea decidió reforzar el marco jurídico de los elementos digitales y, entre ellos, los OSS. Concretamente, procedió al establecimiento de normas para la fabricación, desarrollo y la introducción en el mercado de la Unión Europea de elementos digitales cuyo uso previsto o razonablemente previsible incluya una conexión de datos directa o indirecta, lógica o física, a un dispositivo o red de cara a garantizar su ciberseguridad. Particularmente, aquellos que estén destinados a ser comercializados en el mercado comunitario; entendiéndose por comercialización, todo suministro, ya sea remunerado o gratuito, de un producto con elementos digitales para su distribución o utilización en el mercado de la Unión en el curso de una actividad comercial (artículo 3 Reglamento de Ciberresilencia versión 2022). En contraposición con lo anterior, en cambio, no se verían afectados los softwares inacabados que no sean conformes con dicha normativa, siempre que dichos programas solo se comercialicen durante un período de tiempo limitado, requerido a efectos de ensayo, y que se indique con claridad, mediante una señal visible, que no son conformes con el citado Reglamento y que no se comercializarán con fines distintos de su ensayo (artículo 4 del Reglamento de Ciberresilencia).

En definitiva, según el Reglamento de Ciberresilencia versión 2022 la fabricación, desarrollo e introducción en el mercado de la Unión Europea de estos productos para su comercialización exigirá observar, resumidamente, los siguientes extremos:

• i) La implementación de unos requisitos esenciales de ciberseguridad en lo que respecta a su diseño, desarrollo, producción, suministro y mantenimiento. Esto implica que tendrán que ser introducidos libres de vulnerabilidades y con una protección segura.
• ii) Garantizar un soporte de seguridad y actualizaciones.
• iii) Los riesgos relativos a la ciberseguridad deberán documentarse y notificarse tanto a las autoridades competentes como a los usuarios.
• iv) Incluir unas instrucciones en un lenguaje claro y comprensible sobre cómo realizar un uso seguro de los mismos.
• v) Finalmente, obtener la evaluación de conformidad de la Unión Europea.
• vi) En el supuesto de incumplimiento, serán sancionados con penas pecuniarias.

Ante este esquema, evidentemente, era estimable una oleada de indignación por parte de los OSS al ver «atacados» los principios básicos que subyacen detrás de su desarrollo y trabajo. Más allá de hacer ruido en redes sociales, medios de comunicación o páginas webs, adoptaron medidas más formales dirigiendo diversas cartas de protesta a la Comisión Europea. Entre ellas, destaco la redactada por DRUPAL, JOOMLA!, TYPO3 y WORDPRESS (6) . En dicho escrito, cuestionaban los siguientes puntos:

• i) Principalmente, el relativo a la actividad comercial. Como he mencionado previamente, el eje central para aplicar esta regulación radica en que estén destinados a ser comercializados en el mercado comunitario; entendiéndose por comercialización, todo suministro, ya sea remunerado o gratuito, de un producto con elementos digitales para su distribución o utilización en el mercado de la Unión en el curso de una actividad comercial. Sin embargo, a su juicio, dicha definición es ambigua y no entiende la red de relaciones por las que se rige el OSS, por ejemplo: habitualmente en su tiempo libre es cuando estos informáticos emprenden actividades de mejora y desarrollo de los softwares OSS altruistamente para, posteriormente, implementarlos en su trabajo, beneficiándose entonces sus empresas de ese previo trabajo desinteresado o; cómo usualmente las asociaciones sin ánimo de lucro ligadas a proyectos OSS actúan como «vendedores oficiales del producto» sin previamente haber participado. En consecuencia, ¿están sujetos dichos supuestos a la normativa comunitaria? A su juicio, con esa regulación, a simple vista, estos supuestos sí que se verían afectados. En consecuencia, el Reglamento Ciberresilencia versión 2022 desincentiva su desarrollo en la Unión Europeo a efectos de evitar esa mayor burocracia de certificados y eventuales multas, desplazándose, en consecuencia, esa innovación hacia otras jurisdicciones más amables como la estadounidense o israelí. Operando todo ello, por tanto, en detrimento del mercado comunitario que, en principio, tiene como uno de sus ejes fundamentales promover la innovación y el desarrollo de la economía comunitaria.
• ii) La propuesta de prohibir la comercialización de «softwares inacabados» contradice, a su juicio, la realidad tanto del OSS o de cualquier otro tipo de software. En el campo informático, las primeras versiones juegan un papel vital para su desarrollo, innovación y seguridad; siendo siempre marcadas como tales antes de su lanzamiento definitivo y experimentando en el ínterin diversas pruebas. Sin embargo, paradójicamente, con esta regulación, se alcanzaría el resultado contrario al perseguido: concretamente, la publicación de softwares menos seguros al haber sido objeto de menos evaluaciones como consecuencia de la obligación de ser «marcados como acabados» en fases previas. Entrando, por ende, en conflicto con los valores de la Unión Europea de libertad, de movimiento y de construcción de un mercado común innovador.
• iii) Finalmente, y desde mi punto de vista, la más importante. El campo OSS está conformado principalmente por pequeñas y medianas empresas. La exigencia de requisitos de cumplimiento bastante estrictos, idénticos a los impuestos a las grandes empresas, supone una carga y barrera desproporcionada.

En este contexto, llegamos a la versión definitiva del futuro texto de Reglamento de Ciberresilencia, adoptado por Resolución legislativa del Parlamento Europeo, de 12 de marzo de 2024 (7) (en adelante, Reglamento de Ciberresilencia versión marzo 2024). A través de la creación de la figura jurídica del «open source steward» ha querido resolver así las críticas de la comunidad OSS (8) . Igualmente, excluyendo del campo de aplicación de dicha normativa a determinados agentes que participan en su desarrollo. Y, finalmente, estableciendo un pequeño matiz para las microempresas fabricantes de este sector para un supuesto concreto de multa pecuniaria ligada a una infracción.

En relación con los OSS, el Reglamento Ciberresliencia versión 2024 comienza su exposición con su definición en el considerando 18. Concretamente, se incluyen aquí aquellos softwares cuyo código fuente se comparte abiertamente y cuya licencia abarca todos los derechos para que el programa informático sea libremente accesible, utilizable, modificable y redistribuible. También, los OSS se desarrollan, mantienen y distribuyen abiertamente a través de plataformas en línea.

Como he mencionado anteriormente, en el desarrollo de los OSS entran varios agentes. Sin embargo, no todos entrarán en el ámbito de aplicación del Reglamento. Así pues, sólo estarán sujetos a dicha normativa los softwares OSS comercializados y, por tanto, suministrados para su distribución o uso en el transcurso de una actividad comercial. En cambio, las circunstancias en las que hayan sido desarrollados o cómo se haya producido su financiación no se tendrá en cuenta a la hora de determinar el carácter comercial o no de la actividad. En consecuencia y a efetos de facilitar la distinción entre la fase desarrollo vs suministro, el suministro de elementos digitales OSS que no sean monetizados por sus fabricantes no deberá de considerarse una actividad comercial. Igualmente, el suministro de productos con elementos OSS destinados a ser integrados por otros fabricantes en sus productos con elementos digitales sólo se considerará comercialización si dicho componente OSS es monetizado por su fabricante original. Finalmente, concluye en subrayar cómo el desarrollo de productos con elementos digitales de OSS por parte de organizaciones sin ánimo de lucro no debe considerarse una actividad comercial, siempre que la organización se haya establecido de tal manera que se garantice que todos los ingresos después de los costes se utilicen para alcanzar objetivos sin ánimo de lucro.

En relación a la figura jurídica del «open source steward» se arbitra en el considerando 19 del Reglamento Ciberresiencia versión 2024. Como he mencionado anteriormente, su nacimiento surge para lograr la «conciliación» de la Unión Europea con la comunidad OSS. Particularmente, se engloban aquí a aquellas personas jurídicas que prestan su apoyo de forma sostenida en el tiempo tanto en el desarrollo de este tipo de productos destinados a actividades comerciales como desempeñando un rol fundamental a efectos de garantizar su viabilidad. A estos «open source steward» se les dota de un régimen regulador flexible y adaptado. Así, por tanto, los puntos clave que presiden a los «open source steward» serían los siguientes:

• i) En un lenguaje sencillo, podemos definir al steward como «el guardián» del software OSS cuyo propósito principal radica en apoyar y sostener el OSS garantizando que sea seguro y funcional para su eventual uso comercial.
• ii) No son los fabricantes.
• iii) En cierta forma, actúan como «líderes de la comunidad» atrayendo desarrolladores y recursos para el desarrollo de estos productos.
• iv) El legislador comunitario les dota de un régimen jurídico diferente en comparación a los fabricantes. En consecuencia, será fundamental que no coloquen en el mercado comunitario los productos con elementos OSS cuyo desarrollan apoyan para que pueda aplicarse el mismo.

En relación a su régimen jurídico, podemos destacar lo siguiente:

• i) Principalmente, cómo no se les aplicarán sanciones pecuniarias por ninguna infracción ligada a la mencionada normativa. Así lo resalta el artículo 64.10.b) Reglamento Ciberresilencia versión 2024.
• ii) Estarán sujetos a un régimen jurídico especial de obligaciones descrito en el artículo 24, concretamente:
  • — Los «open source steward» deberán establecer y documentar de forma verificable una política de ciberseguridad, así como una gestión eficaz de las vulnerabilidades por parte de los desarrolladores de los productos OSS. Dicha política también promoverá la notificación voluntaria de vulnerabilidades, por parte de sus desarrolladores, y tendrá en cuenta siempre la naturaleza específica del concreto «open source steward» además de las circunstancias organizativas y jurídicas a las que esté sujeto. Particularmente, incluirá aspectos relacionados con la documentación de las vulnerabilidades, la respuesta a ellas y su subsanación, y promoverá el intercambio de información sobre las vulnerabilidades descubiertas en la comunidad de código abierto.
  • — Los «open source steward» cooperarán con las autoridades de vigilancia del mercado previa solicitud de aquellas.
  • — Un régimen propio de notificaciones al CSIRT, es decir,

Finalmente, como he mencionado anteriormente, la comunidad OSS puso el grito en el cielo porque estas reglas de juego se aplicarán a todos los fabricantes de OSS independiente de su tamaño; con la consiguiente, desigualdad de medios económicos y organizativos con los que cuentan. En relación a esta problemática, al menos desde mi punto de vista, la Unión Europea se ha puesto una «venda en los ojos» no atendiendo suficientemente sus peticiones. En concreto, la única peculiaridad prevista para ellos es la recogida en el artículo 64.10.a) del Reglamento Ciberresilencia versión 2024. Es decir, su exoneración de sanciones pecuniarias derivada de la infracción por parte de los fabricantes que se consideren microempresas o pequeñas empresas en relación con los incumplimientos de los plazos previstos en el artículo 14, apartado 2, letra a), o el artículo 14, apartado 4, letra a): a) la obligación de notificación de una vulnerabilidad en un plazo de veinticuatro horas y; b) la obligación de notificación de un incidente grave dentro también de un plazo de veinticuatro horas.

Indudablemente, en las dos versiones de Reglamento de Ciberresiliencia, la Unión Europea ha perseguido reforzar la ciberseguridad de los productos de OSS que se comercialicen dentro del marco comunitario, imponiendo a sus fabricantes una gran disparidad de requisitos técnicos y/o administrativos: certificación de conformidad con la Unión Europea, notificaciones, subsanación de incidentes, multas, etc. Igualmente, no se puede negar que la Unión Europea ha hecho suyo el principio de que «rectificar es de sabios». Efectivamente, ha atendido muchas de las reivindicaciones de la comunidad de la OSS, traduciéndose, en la creación de ese régimen jurídico particular para los «open source steward». No obstante, y, desafortunadamente, para mí, ha pasado por alto las peticiones de las microempresas o pequeñas empresas. En cierta forma, estoy a la expectativa de ver su reacción ante la entrada en vigor de esta normativa; es decir, si efectivamente será el detonante a que muchas de ellas se deslocalicen y/o comercialicen sus productos en otros mercados más amables con ellos como pueden ser Estados Unidos e Israel.

III. Las guías de la Israeli Privacy Protection Authority con relación al OSS

Que Israel es uno de los principales estandartes en el campo del desarrollo tecnológico resulta innegable; igualmente, su potencial en relación a los softwares de OSS (9) . Si bien es cierto que la existencia de este tipo de softwares se remonta a hace décadas, en los últimos años se está produciendo un incremento significativo de empresas de OSS en torno a las cuales se ha generado miles de millones de dólares. Concretamente, ha florecido un gran número de startups de OSS en Israel, detrás de las cuales se esconden en muchas ocasiones empresas de gran tamaño que han optado por participar o invertir en este tipo de proyectos; entre ellas, destacan Elastic y Redis Labs. Los principales objetivos perseguidos por estas startups de OSS pasan por la creación, innovación y desarrollo de este tipo de softwares enfocados en cuestiones relativas a la ciberseguridad y de Low-Code Development Tools.

En dicho contexto no es extraño que la Israeli Privacy Protection Authority o, en castellano, la Autoridad Israelí de Protección de la Privacidad decidiera emitir unas guías en cuanto a su utilización (10) : concretamente, en abril de este año. Coincidiendo, por tanto, en cierta forma, con el Reglamento de Ciberresilencia versión 2024. La idea general que subyace detrás de todas sus conclusiones es la siguiente: si bien resalta la relevancia del OSS como sistema de creación cooperativa de softwares su implementación no puede estar desligada de mitigar los riesgos que su implementación puede conllevar para la privacidad de los usuarios.

Como regla general, el artículo 17 de la Ley 5741-1981 de privacidad israelí (11) (en adelante, «PPL») consagra el principio de que los dueños de bases de datos (siguiendo la terminología de dicha regulación, en la Unión Europea, en cambio, los encargados de los datos), deben garantizar su seguridad en aras a proteger la privacidad de sus usuarios. Como apunta expresamente en su guía la Israeli Privacy Protection Authority, las bases de datos ligadas a softwares OSS que manejen información personal estarán igualmente obligados a observar dicho cumplimiento. Ahora bien, teniendo en cuenta sus singularidades, según la citada guía deberán de observar a su vez unas indicaciones específicas:

• i) En concreto, remite al artículo 5 del Protection of Privacy Regulations (Data Security) 5777-2017 (en adelante, «PPL Data Security») (12) . Este precepto establece el mandato de que los «propietarios de las bases de datos» o, según la terminología de la Unión Europea, los Encargados del Tratamiento de los datos están obligados a mantener un documento actualizado donde se especifique la base de datos como también la arquitectura e inventario del sistema. Estos documentos deben identificar claramente todos los sistemas informáticos que contengan datos personales y mapear las estructuras de bases de datos utilizadas en ellas. Según esta guía, para las OSS, deberán describir detalladamente el software de OSS incorporado o utilizado en dichos sistemas, incluidas las condiciones de licencia aplicables a los mismos.
• ii) La segunda recomendación pasa por requerir a los «los propietarios de las bases de datos» a mantener adecuadamente los sistemas de base de datos asegurando la aplicación de actualizaciones frecuentes del software. En este sentido, expresamente se prohíbe el uso de software de OSS que no sea adecuadamente mantenido y actualizado. Apuntan en concreto cómo softwares de bases de datos populares como MySQL o Mongo DP que están disponibles a través de licencias OSS son mantenidos por organizaciones comerciales.
• iii) La siguiente recomendación hace hincapié en la obligación de «los propietarios de bases» de garantizar que éstas no se conecten a redes públicas sin tomar las precauciones de seguridad adecuadas. A tal fin, deberán adoptar precauciones adecuadas para garantizar que el software de OSS incluido en sus sistemas no contenga malware.
• iv) Antes de contratar a un proveedor de servicios externo, los «propietarios de bases de datos» deben evaluar los riesgos que plantea el uso de OSS por parte de dicho proveedor de servicios. Es decir, en el supuesto de que una empresa decida contratar este tipo de softwares, el encargado del tratamiento debería de efectuar esa evaluación de riesgos asociados a su utilización.
• v) «Los propietarios de bases de datos» deberán evaluar los riesgos que plantea el software de OSS de desarrollar o conceder licencias de sistemas basados en él. En cierta forma, esto guarda relación con lo dispuesto en la Unión Europea, es decir, en evaluar su impacto en ciberseguridad y/o privacidad antes de proceder a su desarrollo o comercialización, pero sin hacerlo obligatorio y sujeto a certificaciones de conformidad como las certificaciones de conformidad de la UE previstas en el Reglamento Ciberresilencia versión 2024.
• vi) Las entidades deberían designar a un «responsable del programa de código abierto», que será responsable de garantizar el mantenimiento y la seguridad continuos del software de OSS utilizado por la entidad. En este sentido, resulta interesante la propuesta de nombrar a una persona que tenga por finalidad concreta salvaguardar la ciberseguridad y privacidad ligada a los OSS.
• vii) Finalmente, se anima a los «propietarios de bases de datos» a proporcionar a sus desarrolladores formación sobre los riesgos de seguridad específicos que pueden derivarse de la utilización, desarrollo o creación de softwares OSS.

De la lectura de la guía de la Israeli Privacy Protection Authority resulta evidente la mayor flexibilidad de Israel hacia los softwares OSS y sus garantías de ciberseguridad y privacidad. Lejos de exigir certificaciones de conformidad previas a su comercialización, aboga por reforzar la concienciación de los desarrolladores de este tipo de softwares hacia las cuestiones de privacidad. Particularmente, aconsejando impulsar su formación al respecto, con la configuración de un «responsable del programa de código abierto», es decir, de un profesional específicamente encaminado a garantizar el mantenimiento y la seguridad continua de este tipo de softwares o, finalmente, llevando a cabo esa evaluación de impacto con carácter previo a su comercialización. En este sentido, resulta más dinámica y desprovista de la burocracia europea que no diferencia el tipo de desarrollador que se esconde detrás de cada software OSS y, en consecuencia, enfrenta a las mismas reglas de juego a un freelance o microempresa que a empresas de gran tamaño. Sin embargo, su hándicap descansa precisamente en dicha ventaja: es decir, si prescindir de altos grados de burocracia se traducirá o no en mayores exposiciones a ciberataques que pongan en peligro a la privacidad de sus usuarios.

IV. Conclusiones

Indudablemente, la actitud de la Unión Europea y de Israel con respecto al software OSS y la privacidad y/o ciberseguridad son la noche y el día. Frente a la burocracia comunitaria, Israel ha apostado por la flexibilidad; flexibilidad que es vital por las propias particularidades del sector OSS —intervención de diversos agentes, componente altruista, cooperativo, innovación constante, etc.—. Y que, igualmente, choca frontalmente con los trámites administrativos descritos en el Reglamento de Ciberresilencia. Si bien en su última versión, la de 2024, el legislador comunitario ha rectificado atendiendo algunas de las reivindicaciones del sector a través, principalmente, de la creación de la figura jurídica de los «open source steward», en cambio, ha dejado de lado a otros intervinientes en el proceso, concretamente: los freelances o microempresas, con el consiguiente «riesgo de fuga» que esto puede acarrar hacia otras jurisdicciones más amigables. Evidentemente, la creación de un estatuto específico para los «open source steward» ha resultado acertada al tener en cuenta su rol concreto en proceso de desarrollo de los softwares OSS. Sin embargo, en el otro lado de la moneda, la no configuración de un régimen propio para las microempresas más allá del matiz de la exoneración de sanción por la no notificación de incidentes en el plazo de veinticuatro horas, al menos, desde mi punto de vista, resulta desalentadora. Perfectamente, para dichos supuestos concretos podría haberse apostado por esquemas más flexibles como el israelí; a través, por ejemplo, de la designación de un «responsable del OSS» o la exigencia de una evaluación sin necesidad de una certificación.

Mientras tanto queda por ver cómo se desarrollará la implementación del Reglamento de Ciberresilencia por parte del sector de la OSS en la Unión Europea, particularmente: respecto a la llevanza a la práctica del estatuto «open source steward» y si, efectivamente, se traducirá en una deslocalización de sus agentes de menor tamaño hacia otras jurisdicciones más flexibles como la israelí. Asimismo, verificar si la mayor flexibilidad israelí implicará o no mayores riesgos para la ciberseguridad y si, en el medio plazo, optaran o no por desarrollar alguna normativa similar a la comunitaria en materia de Ciberresilencia.

V. Bibliografía

• 1. BOUT STÉPHANE, HILLEN BRAND PHILIPP and HENNING, SOLLER. SaaS, open source, and serverless: A winning combination to build and scale new businesses. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/saas-open-source-and-serverless-a-winning-combination-to-build-and-scale-new-businesses, 28 de abril de 2021.
• 2. COMISIÓN EUROPEA. Propuesta de REGLAMENTO DEL PARLAMENTO EUROPEO Y DEL CONSEJO relativo a los requisitos horizontales de ciberseguridad para los productos con elementos digitales y por el que se modifica el Reglamento (UE) 2019/1020 (LA LEY 11044/2019). https://eur-lex.europa.eu/legal-content/ES/TXT/PDF/?uri=CELEX:52022PC0454. 15 de septiembre de 2022.
• 3. DAWS, RYAN. Open source wins concessions in new EU cyber law. https://www.developer-tech.com/news/2024/jan/15/open-source-wins-concessions-new-eu-cyber-law/ 15 de enero de 2024.
• 4. DRUPAL, JOOMLA!, TYPO3 y WORDPRESS. Open Letter on the Significance of Free and Open Source Software in the EU’s Proposed Cyber Resilience Act. https://wordpress.org/news/files/2023/08/Open_Letter_on_the_Significance_of_Free_and_Open_Source_Software_in_the_EU_s_Proposed_Cyber_Resilience_Act.pdf . 25 julio 2023.
• 5. INBAR, ITAY & SULKIN-LEVY LIOR. The emergence of israelí open source. https://www.greenfield-growth.com/blog-posts/the-emergence-of-israeli-open-source. 19 de enero de 2023.
• 6. ISRAEL PRIVACY PROTECTION AUTHORITY. . https://www.gov.il/he/pages/open_source_code . 8 de abril de 2024.
• 7. ISRAEL PRIVACY PROTECTION AUTHORITY. Protection of Privacy Law, https://www.gov.il/BlobFolder/legalinfo/legislation/en/ProtectionofPrivacyLaw57411981unofficialtranslatio.pdf .
• 8. MCKINSEY & COMPANY. McKinsey launches an open-source ecosystem for digital and AI projects. https://www.mckinsey.com/about-us/new-at-mckinsey-blog/mckinsey-launches-an-open-source-ecosystem . 26 de septiembre de 2023.
• 9. PARLAMENTO EUROPEO. Resolución legislativa del Parlamento Europeo, de 12 de marzo de 2024, sobre la propuesta de reglamento del Parlamento Europeo y del Consejo relativo a los requisitos horizontales de ciberseguridad para los productos con elementos digitales y por el que se modifica el Reglamento (UE) 2019/1020 (LA LEY 11044/2019) (COM(2022)0454 — C9-0308/2022 — 2022/0272(COD)). https://www.europarl.europa.eu/doceo/document/TA-9-2024-0130_ES.html . 12 de marzo de 2024.
• 10. THE PRIVACY PROTECTION AUTHORITY OF ISRAEL. Protection of privacy regulations (data security) 5777-2017. Publicado el 8 de mayo de 2017 en https://www.gov.il/en/departments/legalInfo/data_security_regulation .
• 11. VAZÃO, ANA PAULA, SANTOS LEONEL, COSTA ROGÉRIO LUIS DE C. y RABADÃO, CARLOS. Implementing and evaluating a GDPR (LA LEY 6637/2016)-compliant open-source SIEM solution. Journal of Information Security and Applications 75 (2023) 103509. https://www.sciencedirect.com/science/article/pii/S2214212623000935 .
• 12. WORDPRESS. Back to support. Account. Keep Your Site Safe and Secure. https://wordpress.com/support/security/#:~:text=Encryption%2C%20by%20Default,Strong%20encryption%20is&text=We%20encrypt%20(serve%20over%20SSL,of%20your%20WordPress.com%20site.