CRA y código abierto: diferencias entre colaboradores, fabricantes y administradores de software de código abierto

Qué es

Estado al 25 de octubre de 2026. El CRA trata el software de código abierto en función del suministro del producto y del papel de la entidad. Volver a consultar el reglamento, sus correcciones de errores y las orientaciones de la Comisión sobre código abierto cuando cambien la financiación, la distribución o la responsabilidad. Las orientaciones utilizadas aquí se actualizaron el 15 de octubre de 2026.

La Comisión explica que el software de código abierto suministrado comercialmente en el mercado puede quedar sujeto al CRA. También distingue a quienes contribuyen a software ajeno a su responsabilidad y una categoría separada de administradores de software de código abierto. Una licencia de código abierto no resuelve por sí sola esa clasificación. Orientaciones de la Comisión sobre código abierto.

Por qué importa

El considerando 18 separa la financiación del desarrollo del suministro comercial. Las contribuciones de fabricantes, el apoyo financiero y las publicaciones periódicas no convierten por sí solos una actividad de código abierto en comercial. El software que su fabricante no monetiza no debería considerarse suministrado comercialmente por esos motivos. A la inversa, que la descarga sea gratuita no es concluyente: el considerando 15 aborda la monetización mediante otros servicios y los cobros por soporte que superan la recuperación de los costes reales. El análisis se refiere a las condiciones reales, no solo a la licencia del repositorio. Reglamento, considerandos 15 y 18.

Las fechas también difieren. La obligación de notificación de los fabricantes conforme al artículo 14 se aplica desde el 11 de septiembre de 2026. Las obligaciones de los administradores de software de código abierto conforme al artículo 24, incluidas las notificaciones, se aplican desde el 11 de diciembre de 2027. La página de la Comisión sobre notificaciones señala expresamente esta distinción.

Cómo aplicarlo

• Identificar la responsabilidad sobre cada producto. El considerando 18 excluye a las personas físicas y jurídicas que se limitan a aportar código fuente a productos de código abierto ajenos a su responsabilidad. Esa redacción no debería ampliarse hasta convertirla en una exención general para cualquier persona denominada responsable de mantenimiento.
• Examinar el papel de fabricante. El artículo 3(13) se refiere a la entidad que desarrolla o encarga el desarrollo de un producto y lo comercializa bajo su propio nombre o marca. Cuando un producto de código abierto incluido en el ámbito de aplicación se introduce comercialmente en el mercado, la Comisión indica que se aplican las obligaciones del fabricante. La mayoría de los requisitos más amplios del CRA se aplican desde el 11 de diciembre de 2027 conforme al artículo 71; la obligación de notificar tiene la fecha anterior.
• Comprobar por separado la definición de administrador de software de código abierto. El artículo 3(14) identifica a una persona jurídica distinta de un fabricante que apoya de manera sistemática y sostenida el desarrollo de determinados productos de código abierto destinados a actividades comerciales y garantiza su viabilidad. La denominación de un proyecto o una donación no bastan por sí solas para establecer todos esos elementos.
• Leer las obligaciones adaptadas a esta figura. El artículo 24 exige una política de ciberseguridad documentada que apoye el desarrollo seguro y la gestión de vulnerabilidades, así como cooperación con las autoridades de vigilancia del mercado. Su alcance de notificación está delimitado: la notificación de vulnerabilidades depende de la participación del administrador de software de código abierto en el desarrollo del producto; la notificación de incidentes graves y las obligaciones de información al usuario a las que se hace referencia conciernen a incidentes que afecten a las redes y los sistemas de información que ese administrador proporciona para dicho desarrollo. No es una obligación ilimitada de notificar todos los incidentes de quienes utilicen posteriormente el software. Estas distinciones proceden de los artículos 3 y 24.
• Mantener revisable la base de la clasificación. Como propuesta organizativa, registrar la entidad responsable, la titularidad del producto, las condiciones de distribución, la monetización y la infraestructura proporcionada. Adjuntar las disposiciones utilizadas e identificar los hechos sin resolver para una revisión cualificada.

Trampas

Una exención de multas administrativas no exime de las obligaciones del administrador de software de código abierto. La Comisión indica que estos administradores quedan fuera de las multas administrativas del CRA. Leer el artículo 64(10) junto con la corrección de errores del 2 de julio de 2025, que corrige el intervalo de apartados de esa exención. No extenderla a un fabricante solo porque su producto utilice una licencia de código abierto.

Por último, la condición de un proyecto del que proceden los componentes no determina las obligaciones de un fabricante que los integra en otro producto. Evaluar por separado a los actores y los productos en lugar de asignar una sola condición a toda la cadena de dependencias.