Carta abierta para pedir a NHS England que mantenga el código público

 (keepthingsopen.com)
1 puntos por GN⁺ 2026-05-03 | 1 comentarios | Compartir por WhatsApp
  • Se opone a la decisión del liderazgo tecnológico de NHS England de hacer privados los repositorios de código fuente, y reafirma el principio de que el código creado con fondos públicos debe estar disponible para el público
  • Se exige a NHS England retirar la línea roja SDLC-8 y reafirmar su compromiso con el Principio 12 del NHS Service Standard: “Make new source code open”
  • Publicar como código abierto requiere más trabajo que mantener el código cerrado, pero exige estándares de calidad más altos, detección y corrección temprana de vulnerabilidades, y la creación de barreras para limitar los daños
  • El código cerrado puede hacer que se omitan tareas de seguridad necesarias y depender de la oscuridad en lugar de una defensa en profundidad; la ventaja que eso ofrece frente a atacantes suficientemente motivados parece muy pequeña
  • Desde el 1 de mayo de 2026 han firmado 402 personas; los firmantes pueden enviar su nombre, correo electrónico y si han contribuido al software del sector público del Reino Unido, y en las firmas anónimas los datos personales se eliminan dentro de las 24 horas posteriores a la verificación

Exigencias clave de la carta abierta

  • Se opone a la decisión del liderazgo tecnológico de NHS England de ocultar el código fuente de todos los repositorios, y reafirma el principio de que el código creado con fondos públicos debe estar disponible para el público
  • Considera que este principio está reflejado en los UK Government Design Principles y en el NHS Service Standard, y que actualmente se está retrocediendo en él
  • Se exige a NHS England retirar la línea roja SDLC-8 y reafirmar su compromiso con el Principio 12 del NHS Service Standard: “Make new source code open”
  • Desde el 1 de mayo de 2026 han firmado 402 personas, y las firmas se muestran en la página tras una revisión manual

La lógica de que el código abierto impone estándares de calidad más estrictos

  • Publicar el código como open source requiere más trabajo que mantenerlo privado
  • Se considera que ese trabajo difícil es precisamente lo importante
  • Abrir el código exige estándares de calidad más altos y procesos para encontrar, corregir y monitorear vulnerabilidades de forma anticipada
  • Es necesario identificar riesgos y establecer barreras para limitar los daños cuando surjan problemas
  • Se compara esto con el sistema inmunológico humano: la exposición a amenazas fortalece más la superficie de ataque

Críticas al código cerrado

  • El código cerrado puede permitir que se omitan tareas de seguridad necesarias
  • Se considera que el enfoque cerrado depende de la oscuridad en lugar de una defensa en profundidad
  • Cuando hay atacantes suficientemente motivados, la ventaja que aporta la oscuridad parece muy pequeña

Forma de firma y tratamiento de datos personales

  • Los firmantes pueden enviar su nombre, dirección de correo electrónico, si han contribuido al software del sector público del Reino Unido, y opcionalmente su cargo y organización
  • Las contribuciones al software del sector público del Reino Unido pueden incluir aportes técnicos y no técnicos, tanto públicos como privados
  • Si hubo contribuciones, basta con algo como un commit o un enlace de perfil, y esa información no se hace pública
  • Si se elige una firma anónima, la firma aparecerá como “Anonymous”, y si se proporcionan cargo y organización, pueden mostrarse junto con ella
  • En el caso de las firmas anónimas, los datos personales se eliminan dentro de las 24 horas posteriores a la verificación
  • La dirección de correo electrónico solo se usa si es necesario contactar por temas relacionados con la firma, y no se publica
  • La base legal para el tratamiento de datos personales es el consentimiento, y este puede retirarse
  • Los temas relacionados con datos pueden enviarse a signatures@keepthingsopen.com
  • Las quejas sobre el tratamiento de datos personales pueden presentarse ante la Information Commissioner’s Office

Material de referencia y enlaces de apoyo

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-05-03
Comentarios de Hacker News

  • Toda la respuesta a la amenaza de Mythos parece medidas para aparentar, y da la impresión de que en cuanto surgen transparencia y apertura intentan revertirlas usando cualquier pretexto flojo
    Se parece más a una decisión tomada por alguien no técnico que cree que “aunque no lo pasemos a código cerrado, existe aunque sea un 0.1% de probabilidad de que nos culpen por no haber hecho lo suficiente cuando se descubra una vulnerabilidad”
    Hay que tener siempre presente que la codicia y el egoísmo extremos de 2026 hacen que ese tipo de decisiones sean fáciles incluso a costa del bien público, y que el sector privado tampoco es especialmente mejor en ese sentido

    • La única excepción sería si después del cierre hubo cambios significativos en el código y ni los atacantes ni los modelos de lenguaje a gran escala pudieron leer esos cambios
      Si internamente usas modelos de lenguaje a gran escala para encontrar bugs de forma privada sin publicar el código fuente, puedes adelantarte a los atacantes
      También vimos recientemente, como en el desastre público de Copy.fail, casos donde una vulnerabilidad encontrada por alguien usando un modelo de lenguaje a gran escala se divulgó como zero-day sin una corrección clara, dejando a la comunidad en confusión y pánico
      En una situación donde ya existen modelos de lenguaje potentes tanto con pesos abiertos como cerrados, hacer que todo sea obligatoriamente open source ya no parece tan razonable, especialmente para software usado en hospitales; hace falta equilibrio

  • Si estás viendo este hilo porque te preocupa la calidad de los servicios digitales del NHS, agradecería que también firmaras la petición para impedir que los proveedores del NHS compren overlays de accesibilidad, que en la práctica dañan la experiencia de usuarios con discapacidad y desperdician dinero que podría usarse para mejorar servicios clave: https://petition.parliament.uk/petitions/765480/

  • No puedo firmar porque el verificador de Cloudflare dice que no soy humano

  • Hay un video que explica esta situación de forma sencilla: https://youtu.be/XNLUfqtgBUk
    Si esta área es tu especialidad, ojalá puedas firmar la carta abierta

  • Incluso si el NHS estuviera de acuerdo e intentara implementarlo, solo crear las directrices relacionadas tomaría al menos un año
    Después, si le piden al equipo técnico actual que lo ordene, probablemente les tome otros 10 años

  • Artículo relacionado: NHS Goes to War Against Open Source
    https://shkspr.mobi/blog/2026/05/nhs-goes-to-war-against-ope... (https://news.ycombinator.com/item?id=47973710)

  • En las últimas semanas hablé de este tema con CISOs, CTOs, mantenedores y colegas; algunos pertenecen a empresas F50, y su plan base es detener las contribuciones y el uso de open source hasta que los equipos de seguridad de aplicaciones puedan verificar y corregir problemas fácilmente en un día
    Tradicionalmente, el tiempo de respuesta de punta a punta era de unos 8 a 10 días, pero ahora ya no se puede sobrevivir con esa velocidad
    No lo veo como la muerte del open source, pero sí muestra que, sin recursos operativos sostenibles para los mantenedores, la economía del open source se convirtió en una tragedia de los comunes
    También es un reconocimiento de que durante décadas las organizaciones no priorizaron la seguridad ni dentro de ingeniería ni a nivel organizacional, aunque viendo el nivel de la conversación aquí en HN, eso parece requerir otra discusión aparte
    Si a quienes aman el open source de verdad les importa, no deberían quedarse en el idealismo: tienen que gastar dinero, pensar en moverse hacia open core o en asegurar financiamiento y patrocinio formales
    También es importante introducir licencias mucho más restrictivas que sigan permitiendo la comercialización por parte de los dueños del proyecto. La mayoría de los proyectos tipo GNU que dependen de la buena voluntad de unas pocas personas con ideas afines difícilmente sobrevivirán, y a los contribuidores también hay que pagarles
    Respecto a la pregunta de “¿pero no se puede dejar de usar Linux/Kubernetes/Chrome (incluido Edge)/casi todos los lenguajes de programación/nginx, no?”, lo que quieren decir es congelar todas las dependencias y bibliotecas que usen en adelante, y no publicar el código fuente hasta que sea posible corregir vulnerabilidades de punta a punta en menos de 24 horas
    Los equipos también están considerando seriamente hacer forks internos de proyectos y dependencias críticas, y no contribuir upstream por miedo a que las contribuciones upstream estén contaminadas o introduzcan vulnerabilidades adicionales

    • Coincido con la postura de simonw de que, al contrario, el open source debería volverse más valioso
      “Un resultado interesante es que las bibliotecas open source se vuelven más valiosas, porque el costo en tokens gastado en seguridad puede compartirse entre todos los usuarios. Esto contradice directamente la idea de que el atractivo de los proyectos open source existentes disminuye porque se pueden crear reemplazos baratos mediante vibe coding”
      Entiendo el impulso reflejo de hacer fork del código y llevárselo internamente, pero me pregunto qué tan sostenible será eso cuando significa más código que los equipos de ingeniería tendrán que mantener y cuyas vulnerabilidades deberán mitigar
      [0] https://simonwillison.net/2026/Apr/14/cybersecurity-proof-of...
    • No me queda claro qué significa exactamente “detener las contribuciones y el uso de open source”
      Me intriga porque no es como que puedan dejar de usar Linux/Kubernetes/Chrome (incluido Edge)/casi todos los lenguajes de programación/nginx, etc.