[{"data":1,"prerenderedAt":10},["ShallowReactive",2],{"article:es:se-aplica-el-cra-al-software-de-codigo-abierto":3},{"locale":4,"slug":5,"title":6,"description":7,"published":8,"body":9},"es","se-aplica-el-cra-al-software-de-codigo-abierto","¿Se aplica el CRA al software de código abierto? Tres casos, y el régimen ligero de los administradores","El Reglamento de Ciberresiliencia alcanza al software libre y de código abierto solo cuando se suministra en el marco de una actividad comercial. Un proyecto no monetizado queda fuera. Una empresa que entrega un producto construido sobre componentes de código abierto es fabricante de ese producto. Y las fundaciones y empresas que sostienen productos de código abierto destinados a uso comercial son «administradores de software de código abierto» según el artículo 24: una política de ciberseguridad, cooperación con las autoridades y una obligación de notificación reducida, sin marcado CE ni documentación técnica. Los considerandos y el artículo, citados.","2026-09-11","\nLa pregunta llega de tres formas, y el Reglamento de Ciberresiliencia, Reglamento (UE) 2024\u002F2847, responde a cada una de manera distinta. Un mantenedor que publica una biblioteca en GitHub. Una empresa cuyo producto se construye sobre esa biblioteca. Una fundación que mantiene viva la biblioteca. Solo uno de los tres es fabricante, y uno de los otros tiene un régimen propio.\n\n## Caso uno: software de código abierto que no se monetiza\n\nConsiderando 18: «solo el software libre y de código abierto comercializado, y por tanto suministrado para su distribución o uso en el marco de una actividad comercial, debe entrar en el ámbito de aplicación del presente Reglamento». Y más concretamente: «el suministro de productos con elementos digitales que sean software libre y de código abierto y que no sean monetizados por sus fabricantes no debe considerarse una actividad comercial».\n\nEl considerando 20 añade que el alojamiento en un repositorio, un gestor de paquetes o una plataforma colaborativa «no constituye en sí mismo la comercialización», y el considerando 18 que la forma de financiar el desarrollo tampoco decide la cuestión.\n\nAsí que una biblioteca publicada bajo una licencia abierta, sin versión de pago, sin soporte de pago vinculado a ella ni acuerdo comercial en torno a su suministro, queda fuera de las obligaciones del fabricante. Su autor no tiene marcado CE que colocar, ni documentación técnica, ni obligación del artículo 14. El artículo 15 le permite notificar vulnerabilidades voluntariamente; nada lo exige.\n\n## Caso dos: un producto comercial construido sobre componentes de código abierto\n\nLa empresa que integra esa biblioteca en un producto que introduce en el mercado es fabricante de ese producto. La licencia del componente no cambia nada. [El anexo I](\u002Farticles\u002Fcra-annex-i-the-22-essential-requirements-as-a-checklist) se aplica a todo el producto, la [SBOM](\u002Farticles\u002Fdoes-the-cra-require-an-sbom) enumera el componente, y el artículo 13, apartado 5, exige al fabricante actuar con la diligencia debida al integrar componentes de terceros, incluidos los de código abierto, para que no comprometan la seguridad del producto.\n\nEl artículo 32, apartado 5, concede un alivio: un producto libre y de código abierto que encaje en una [categoría del anexo III](\u002Farticles\u002Fis-your-product-important-or-critical-under-the-cyber-resilience-act) puede seguir usando el procedimiento de autoevaluación, siempre que su documentación técnica se haga pública al introducirlo en el mercado. Eso es para los productos de código abierto que se comercializan por sí mismos, no para los componentes dentro de uno propietario.\n\nEl considerando 21 prevé programas voluntarios de certificación de seguridad para componentes de código abierto, de modo que la diligencia debida de un fabricante tenga en qué apoyarse. Aún no se ha establecido ninguno.\n\n## Caso tres: el administrador de software de código abierto\n\nEl artículo 3, punto 14, define al administrador como «una persona jurídica, distinta de un fabricante, que tiene como finalidad u objetivo prestar apoyo de forma sistemática y sostenida al desarrollo de productos con elementos digitales específicos que sean software libre y de código abierto y estén destinados a actividades comerciales, y que garantiza la viabilidad de dichos productos». El considerando 19 nombra el tipo: ciertas fundaciones, y entidades que desarrollan y publican software libre y de código abierto en un contexto empresarial, incluidas las entidades sin ánimo de lucro.\n\n«Destinados a actividades comerciales» es la bisagra. El considerando 19 dice que incluye la integración en servicios comerciales o en productos monetizados, y que la intención existe cuando los fabricantes que integran el componente contribuyen a su desarrollo con regularidad o lo financian con regularidad. Una fundación cuyo proyecto está incorporado en productos comerciales de todo el sector es administrador. Un proyecto de afición sin esa relación no lo es.\n\nEl artículo 24 da a los administradores un régimen que el propio Reglamento llama ligero:\n\n**Una política de ciberseguridad, documentada de forma verificable** (artículo 24, apartado 1), que fomente el desarrollo seguro y la gestión eficaz de vulnerabilidades por los desarrolladores del proyecto, incluidos documentar, abordar y corregir vulnerabilidades, compartir información sobre las vulnerabilidades descubiertas dentro de la comunidad y fomentar la notificación voluntaria del artículo 15.\n\n**Cooperación con las autoridades de vigilancia del mercado** a petición de estas (artículo 24, apartado 2), y facilitar esa política a una autoridad previa solicitud motivada.\n\n**Un artículo 14 reducido.** Artículo 24, apartado 3: la obligación de notificar vulnerabilidades explotadas activamente se aplica a los administradores «en la medida en que participen en el desarrollo» del producto; la obligación de notificar incidentes graves, y de informar a los usuarios, se aplica «en la medida en que los incidentes graves ... afecten a las redes y sistemas de información facilitados por los administradores de software de código abierto para el desarrollo de dichos productos». Los relojes son [los mismos 24 y 72 horas](\u002Farticles\u002Fcra-final-report-clock-does-not-start-when-you-become-aware), al [mismo CSIRT](\u002Farticles\u002Fwhich-csirt-do-you-report-to-under-cra-article-14) y a ENISA.\n\nLo que un administrador no tiene: obligaciones del anexo I para el producto, documentación técnica, evaluación de la conformidad, marcado CE, declaración de conformidad, período de soporte. El artículo 24 es todo. Y el artículo 64, apartado 10, letra b), dice que las multas administrativas del artículo 64 «no se aplicarán a» las infracciones del Reglamento cometidas por administradores de software de código abierto; las demás medidas correctoras de una autoridad de vigilancia del mercado se mantienen.\n\n## Qué decidir, y dejar por escrito\n\nQué caso es usted. Si publica código abierto y no monetiza nada a su alrededor, déjelo por escrito, con fecha, porque «no monetizado» es un hecho sobre su negocio que puede cambiar. Si entrega un producto construido sobre componentes de código abierto, está en el caso dos y los [doce pasos](\u002Farticles\u002Fthe-cyber-resilience-act-for-a-small-software-manufacturer-in-twelve-steps) se aplican por completo. Si sostiene un proyecto del que dependen productos comerciales, es administrador: redacte la política del artículo 24, apartado 1, nombre a la persona que responde a una autoridad y decida cómo se enteraría de una vulnerabilidad explotada activamente en el proyecto y cómo la notificaría.\n\nLas orientaciones de la Comisión del 27 de julio de 2026 convierten los dos considerandos en siete pruebas con 22 ejemplos resueltos: [dónde acaban un enlace de donaciones, un nivel de soporte de pago, una edición open core y una fundación](\u002Farticles\u002Fis-your-open-source-project-commercial-under-the-cra-the-commissions-seven-tests) es el artículo complementario de este.\n\n## Fuentes\n\n- Reglamento (UE) 2024\u002F2847, artículo 3, punto 14 (citado), artículo 13, apartado 5, artículo 15, artículo 24, apartados 1 a 3 (citados), artículo 32, apartado 5, artículo 64, apartado 10, letra b); considerandos 17 a 21 (citados). Leído en el texto del Diario Oficial en EUR-Lex el 11 de septiembre de 2026.\n\nEsto no es asesoramiento jurídico. Los considerandos son donde se traza la línea del código abierto, y están citados arriba para que pueda leerlos en lugar de adoptar nuestra lectura.\n",1789383975905]