[{"data":1,"prerenderedAt":10},["ShallowReactive",2],{"article:es:es-su-proyecto-de-codigo-abierto-comercial-segun-el-cra-las-siete-pruebas-de-la-comision":3},{"locale":4,"slug":5,"title":6,"description":7,"published":8,"body":9},"es","es-su-proyecto-de-codigo-abierto-comercial-segun-el-cra-las-siete-pruebas-de-la-comision","¿Es su proyecto de código abierto «comercial» según el CRA? Las siete pruebas de la Comisión, con sus ejemplos","El CRA alcanza al software libre y de código abierto solo cuando se suministra en el marco de una actividad comercial, y el Reglamento deja «comercial» en manos de dos considerandos. Las orientaciones de la Comisión del 27 de julio de 2026, sección 3, las convierten en siete pruebas: un precio, una edición de pago u open core, monetizar otros servicios o datos personales, servicios de soporte, donaciones, patrocinio y la condición sin ánimo de lucro, con 22 ejemplos. Dónde acaban un mantenedor, una empresa open core y una fundación, y en qué le convierte una pull request.","2026-09-11","\nEl Cyber Resilience Act, Reglamento (UE) 2024\u002F2847, se aplica al software libre y de código abierto solo cuando se «comercializa», es decir, cuando se suministra «en el marco de una actividad comercial». [Los tres casos](\u002Farticles\u002Fdoes-the-cra-apply-to-open-source-software), un proyecto no monetizado, un producto construido sobre componentes de código abierto y el administrador de software de código abierto, salen del propio Reglamento. Lo que el Reglamento no hace es decir cuándo un proyecto que acepta dinero, ofrece soporte, tiene un nivel de pago o está financiado por una empresa cruza la línea. Los considerandos 15 y 18 marcan la dirección; las orientaciones de la Comisión del 27 de julio de 2026, C(2026) 5252, sección 3, apartados 42 a 89, dan las pruebas, y 22 ejemplos resueltos numerados del 13 al 34.\n\nEste artículo es esa sección. Está escrito para las tres personas que preguntan: el mantenedor con un enlace de donaciones, la empresa con una edición community y otra enterprise, y la fundación.\n\n## Primero, qué cuenta como código abierto\n\nEl artículo 3(48) define el software libre y de código abierto como «software cuyo código fuente se comparte abiertamente y que se pone a disposición bajo una licencia libre y de código abierto que otorga todos los derechos para hacerlo libremente accesible, utilizable, modificable y redistribuible». El apartado 44 lo lee como dos condiciones acumulativas: una licencia que otorga el conjunto completo de derechos, y un código fuente compartido abiertamente. El apartado 46 extrae la consecuencia para los modelos de código visible y solo para clientes: el software «cuyo código fuente solo se comparte (o se permite compartir) con clientes de pago o con un grupo limitado de usuarios no debe considerarse FOSS». Las orientaciones no nombran licencias. Nombran las dos condiciones.\n\n## Quién es responsable: los mantenedores, no los contribuidores\n\nAntes de preguntar si un proyecto es comercial, el apartado 48 pregunta si es usted quien lo suministra. Apartado 49: el software de código abierto está «bajo la responsabilidad» de las personas «que lo publican y ejercen el control principal sobre su desarrollo, sus versiones y sus decisiones de distribución (a menudo llamadas \"mantenedores\")». Los contribuidores, que «aportan código fuente pero no controlan las versiones, las hojas de ruta ni las decisiones de gobernanza», no son responsables, «aunque hayan aportado código», y «la mera existencia de permisos técnicos, como el acceso de commit, no es suficiente». El ejemplo 13 es la pull request: la persona que envía un parche que los mantenedores revisan y fusionan «es un \"contribuidor\" y no está sujeta al CRA».\n\nLos apartados 86 y 87 cierran el círculo para las empresas: un fabricante que integra un componente y contribuye a su mantenimiento no se hace responsable de ese componente, e integrar un componente en un producto monetizado «no tiene ningún efecto sobre la condición de ese componente FOSS con arreglo al CRA». Que el Reglamento se aplique a un componente «depende únicamente de si la persona física o jurídica que lo publica lo introduce en el mercado».\n\n## Las siete pruebas\n\n**1. Cobrar un precio por el software.** Apartado 51: cobrar por el software en sí, «por ejemplo cobrando un precio por los binarios precompilados», es introducirlo en el mercado, y quien cobra es fabricante.\n\n**2. Una edición de pago junto a una gratuita, open core incluido.** El apartado 52 las trata como dos productos. La versión de pago se introduce en el mercado; «la versión suministrada gratuitamente (o versión community) no está monetizada y, por tanto, no se considera introducida en el mercado». Eso vale «cuando la versión de pago es una versión comercial \"mejorada\", que amplía la base de código de la versión gratuita o la incorpora a un producto más amplio (por ejemplo, como en el modelo \"open core\")». El apartado 53 añade la trampa para las empresas: una persona jurídica que suministra la versión community es su administradora; una persona física queda fuera del Reglamento respecto de ella.\n\n**3. Monetizar otros servicios a través del software, o exigir datos personales.** Apartado 54: un proyecto se introduce en el mercado cuando quien lo publica «monetiza a través de él otros productos con elementos digitales o servicios», o «exige como condición de uso el tratamiento de datos personales por motivos distintos de la mejora exclusiva de la seguridad, la compatibilidad o la interoperabilidad del software». El ejemplo 14 es una app de mercado gratuita que gana comisiones o publicidad; el ejemplo 15 un cliente VPN gratuito que vende acceso a servidores adicionales; el ejemplo 16 una app de fitness gratuita cuyo uso está condicionado al tratamiento de datos para publicidad dirigida. Las tres están en el mercado.\n\n**4. Servicios de soporte.** Los apartados 55 a 57 trazan la línea sobre la que viven la mayoría de las empresas de código abierto. Ofrecer soporte de pago no hace «como tal» comercial el software: «el factor decisivo es si el acceso al propio FOSS, incluido su mantenimiento, está condicionado a una remuneración, y no la mera oferta de servicios profesionales en torno a un producto disponible libremente». El ejemplo 18, una herramienta de línea de comandos descargable libremente con consultoría de pago opcional, no está en el mercado. El ejemplo 17, un sistema operativo con una versión de pago «que incluye servicios de soporte, como asistencia técnica u optimización del rendimiento», sí lo está, y el apartado 57 lo dice «con independencia de que un software funcionalmente equivalente esté también disponible gratuitamente». Para los particulares, el apartado 58 añade la regla de recuperación de costes del considerando 15: vincular la asistencia al acceso sigue sin ser comercial «si el precio cobrado solo sirve para recuperar los costes reales», que «incluyen los gastos de subsistencia razonables de la persona».\n\n**5. Donaciones.** Apartado 61, del considerando 15: «aceptar donaciones sin intención de obtener beneficios no debe considerarse una actividad comercial», y un enlace de donaciones no es intención de lucro «aunque la cantidad recaudada mediante donaciones supere los meros costes», incluidas una compensación razonable de los contribuidores y los gastos de subsistencia. «Es poco probable, por tanto, que un FOSS sostenido únicamente mediante donaciones se considere introducido en el mercado.» El apartado 62 da la excepción: donaciones «equivalentes de facto a cobrar un precio», cuando «el acceso al FOSS, a funcionalidades esenciales o a las actualizaciones está condicionado en la práctica a hacer una donación». El ejemplo 21 proporciona versiones y actualizaciones de seguridad solo a los donantes: en el mercado. El ejemplo 22 publica el código fuente pero da «binarios precompilados, actualizaciones periódicas y correcciones de seguridad garantizadas solo a los donantes»: en el mercado.\n\n**6. Patrocinio y desarrollo financiado.** Apartados 63 a 65: subvenciones, recompensas por errores, patrocinios y trabajo de desarrollo pagado «no deben tenerse en cuenta al determinar la naturaleza comercial de esa actividad». El ejemplo 23 es una empresa que paga a un mantenedor individual para añadir una funcionalidad que luego se comparte abiertamente; el mantenedor no ha introducido nada en el mercado, y la empresa debe la diligencia debida del artículo 13(5) cuando integra el resultado.\n\n**7. Editores sin ánimo de lucro.** Apartado 66: una persona jurídica «constituida de manera que garantice que todos los ingresos tras los costes se destinan a objetivos sin ánimo de lucro» no introduce su software en el mercado, incluso cuando se monetiza directamente. El ejemplo 24 es un navegador «monetizado directamente mediante acuerdos con motores de búsqueda» cuyos ingresos tras los costes se destinan a objetivos sin ánimo de lucro: no está en el mercado, y quien lo publica es administrador.\n\nEl apartado 67 añade el caso para el que existe todo el régimen del administrador: el software «destinado a ser integrado por otros fabricantes en sus propios productos» no se introduce en el mercado a menos que quien lo publica también lo monetice; la persona jurídica que lo publica es administradora si presta apoyo sostenido. Los ejemplos 25 y 26 son una biblioteca de interfaz de usuario e implementaciones de referencia que una empresa publica sin cobrar.\n\n## Dónde acaba cada uno de los tres\n\nLos escenarios ilustrativos de la sección 3.5 proyectan las pruebas sobre formas reales, y tres de ellos cubren a la mayoría de los lectores.\n\n**El mantenedor individual con un enlace de donaciones** (ejemplos 27 y 34): no está en el mercado, sin obligaciones bajo el Reglamento, por muchas empresas que dependan del proyecto y por mucho que donen. Las empresas que lo integran deben la diligencia debida del artículo 13(5) y, conforme al artículo 13(6), deben al mantenedor los informes de las vulnerabilidades que encuentren y las correcciones que escriban.\n\n**La empresa con una edición community y una de pago** (ejemplos 29 y 30): fabricante de la edición de pago, con todo el Reglamento adherido, y administradora de la edición community que suministra gratis, con los deberes más ligeros del artículo 24 adheridos a esta. Los apartados 72 a 74 son explícitos en que una persona jurídica puede ser ambas cosas a la vez, proyecto por proyecto, y debe decidir «para cada FOSS concreto que publique» cuál es.\n\n**La fundación** (ejemplos 28, 32 y 33): administradora, ya esté financiada por subvenciones públicas, donaciones, proyectos en colaboración o cuotas de socios, siempre que esté constituida de modo que los ingresos tras los costes sirvan a objetivos sin ánimo de lucro y sostenga el software. Sus miembros y financiadores no son responsables del cumplimiento del software; los fabricantes que construyen sobre él deben la diligencia debida.\n\n## Qué escribir\n\nPara cada proyecto que publique, una página: si cumple las dos condiciones del artículo 3(48); quién ejerce el control principal sobre las versiones; cuál de las siete pruebas, en su caso, cumple, con el número del ejemplo al que se parece; y el papel resultante, fabricante, administrador o ninguno. Una empresa que publica varios proyectos escribe esa página varias veces, porque el apartado 74 dice que la respuesta es por proyecto. Un fabricante que integra componentes de código abierto no la escribe para ellos; registra en su lugar la diligencia debida del artículo 13(5) y las notificaciones aguas arriba del artículo 13(6), que es donde [los doce pasos](\u002Farticles\u002Fthe-cyber-resilience-act-for-a-small-software-manufacturer-in-twelve-steps) las colocan.\n\n## Fuentes\n\n- Reglamento (UE) 2024\u002F2847, artículo 3(14) y (48), artículo 13(5) y (6), artículo 24, considerandos 15, 18 y 19.\n- Comisión Europea, orientaciones de la Comisión sobre la aplicación del Reglamento (UE) 2024\u002F2847, C(2026) 5252 final de 27 de julio de 2026, anexo, sección 3, apartados 42 a 89 y ejemplos 13 a 34.\n\nEsto no es asesoramiento jurídico. La sección 3 son catorce páginas, y los 22 ejemplos son la parte que hay que leer; la mayoría de los proyectos se reconocerán en uno de ellos.\n",1789383977644]