Carta aberta pedindo que o NHS England mantenha o código em aberto

 (keepthingsopen.com)
1 pontos por GN⁺ 2026-05-03 | 1 comentários | Compartilhar no WhatsApp
  • Reafirma o princípio de que código criado com recursos públicos deve ser público, em oposição à decisão da liderança técnica do NHS England de tornar privado o código-fonte dos repositórios
  • Exige que o NHS England retire a SDLC-8 red line e reafirme o compromisso com o Princípio 12 do NHS Service Standard, “Make new source code open”
  • Tornar o código aberto exige mais trabalho do que mantê-lo fechado, mas requer padrões de qualidade mais altos, descoberta e correção prévias de vulnerabilidades e a criação de barreiras para limitar danos
  • Código-fonte fechado pode levar a pular trabalhos de segurança necessários, depender de obscuridade em vez de defesa em profundidade, e a vantagem oferecida a atacantes suficientemente motivados parece ser muito pequena
  • Desde 1º de maio de 2026, 402 pessoas assinaram; os signatários podem enviar nome, e-mail e se contribuíram com software do setor público do Reino Unido, e em assinaturas anônimas os dados pessoais são apagados em até 24 horas após a verificação

Principais demandas da carta aberta

  • Opõe-se à decisão da liderança técnica do NHS England de ocultar o código-fonte de todos os repositórios e reafirma o princípio de que código criado com recursos públicos deve ser público
  • Afirma que esse princípio está presente nos UK Government Design Principles e no NHS Service Standard, e considera que isso está retrocedendo no momento
  • Exige que o NHS England retire a SDLC-8 red line e reafirme o compromisso com o Princípio 12 do NHS Service Standard, “Make new source code open”
  • Desde 1º de maio de 2026, 402 pessoas assinaram, e as assinaturas aparecem na página após revisão manual

A lógica de que open source cria padrões de qualidade mais rígidos

  • Publicar código como open source exige mais trabalho do que mantê-lo fechado
  • Considera-se que esse trabalho difícil em si é o ponto central
  • A abertura do código exige padrões de qualidade mais altos e requer processos para encontrar, corrigir e monitorar vulnerabilidades com antecedência
  • É preciso identificar riscos e criar barreiras para limitar os danos quando surgirem problemas
  • Isso é comparado ao sistema imunológico humano: a exposição a ameaças tornaria a superfície de ataque mais resistente
Publicidade

Críticas ao código-fonte fechado

  • Código-fonte fechado permite pular trabalhos de segurança necessários
  • A abordagem fechada é vista como dependente de obscuridade em vez de defesa em profundidade
  • Diante de atacantes suficientemente motivados, a vantagem oferecida pela obscuridade parece muito pequena

Forma de assinatura e tratamento de dados pessoais

  • Os signatários podem enviar nome, endereço de e-mail, se contribuíram com software do setor público do Reino Unido e, opcionalmente, cargo e organização
  • Contribuições para software do setor público do Reino Unido podem incluir contribuições técnicas e não técnicas, públicas e privadas
  • Se houver contribuição, um commit ou link de perfil já é suficiente, e essa informação não é tornada pública
  • Ao escolher assinatura anônima, a assinatura aparece como “Anonymous”, e cargo e organização podem ser exibidos junto, caso sejam informados
  • No caso de assinaturas anônimas, os dados pessoais são apagados em até 24 horas após a verificação
  • O endereço de e-mail é usado apenas quando é necessário contato relacionado à assinatura e não é divulgado
  • A base legal para o tratamento de dados pessoais é o consentimento, e é possível retirar esse consentimento
  • Contato sobre dados pode ser feito em signatures@keepthingsopen.com
  • Reclamações sobre tratamento de dados pessoais podem ser feitas ao Information Commissioner’s Office

Materiais de referência e links de apoio

Leituras relacionadas

1 comentários

 
GN⁺ 2026-05-03
Comentários do Hacker News

  • A reação à ameaça Mythos parece inteiramente teatro de segurança, e dá a impressão de que, no momento em que surgem transparência e abertura, tentam voltar atrás com qualquer desculpa esfarrapada
    Parece mais uma decisão tomada por não técnicos que pensam: “mesmo que haja 0,1% de chance de sermos criticados por não termos fechado o código-fonte e por não termos feito o suficiente quando uma vulnerabilidade for descoberta”
    A ganância e o egoísmo extremos de 2026 tornam esse tipo de decisão fácil, mesmo às custas do bem público, e vale sempre lembrar que o setor privado também não é exatamente melhor nesse aspecto

    • A única exceção seria se, após o fechamento, o código tivesse sofrido mudanças substanciais e os atacantes ou modelos de linguagem de grande porte não conseguissem ler essas mudanças
      Usando internamente modelos de linguagem de grande porte para encontrar bugs em código-fonte não divulgado, daria para ficar um passo à frente dos atacantes
      Também vimos recentemente casos como o desastre público da Copy.fail, em que uma vulnerabilidade encontrada por alguém usando modelos de linguagem de grande porte foi divulgada como zero-day sem uma correção clara, jogando a comunidade em confusão e pânico
      Num cenário em que modelos de linguagem de grande porte poderosos existem tanto com pesos abertos quanto fechados, especialmente para software usado em hospitais, faz menos sentido dizer que tudo deve ser open source sem exceção; é preciso equilíbrio

  • Se você está acompanhando este tópico por preocupação com a qualidade dos serviços digitais do NHS, seria ótimo também assinar a petição para impedir que fornecedores do NHS comprem overlays de acessibilidade, que na prática prejudicam a experiência de usuários com deficiência e desperdiçam dinheiro que poderia ir para melhorias em serviços essenciais: https://petition.parliament.uk/petitions/765480/

  • Não consigo assinar porque o verificador da Cloudflare diz que eu não sou humano

  • Há um vídeo que explica bem a situação: https://youtu.be/XNLUfqtgBUk
    Se essa área for a sua especialidade, seria ótimo assinar a carta aberta

  • Mesmo que o NHS concorde e tente colocar isso em prática, só para criar as diretrizes relevantes levaria pelo menos 1 ano
    Depois, se pedirem para a equipe técnica atual arrumar tudo, provavelmente vai mais 10 anos

  • Texto 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)

  • Nas últimas semanas conversei sobre isso com CISOs, CTOs, mantenedores e colegas, alguns deles em empresas da F50, e o plano básico deles é parar de contribuir e usar open source até que as equipes de segurança de aplicações consigam verificar e corrigir facilmente problemas em um dia
    Tradicionalmente, o tempo de resposta ponta a ponta era de uns 8 a 10 dias, mas agora não dá mais para sobreviver nesse ritmo
    Não vejo isso como a morte do open source, mas como um sinal de que a economia do open source virou uma tragédia dos comuns, já que não estão sendo fornecidos aos mantenedores os recursos operacionais sustentáveis de que precisam
    Também é um reconhecimento de que, por décadas, as organizações não priorizaram segurança nem dentro da engenharia nem no nível organizacional, mas, vendo o nível da conversa aqui no HN, isso parece exigir uma discussão separada
    Se as pessoas que gostam de open source realmente se importam, precisam parar de falar só em idealismo e gastar dinheiro, pensando em ir para open core ou em garantir financiamento e patrocínio formais
    Também é importante adotar licenças bem mais restritivas, ao mesmo tempo permitindo a comercialização pelos donos dos projetos. A maior parte dos projetos no estilo GNU, que dependem da boa vontade de algumas poucas pessoas com ideais parecidos, dificilmente vai sobreviver, e os contribuidores também precisam ser remunerados
    Quanto à pergunta “não dá para parar Linux/Kubernetes/Chrome (incluindo Edge)/quase todas as linguagens de programação/nginx etc., dá?”, a ideia é congelar todas as dependências e bibliotecas usadas daqui para frente e não divulgar o código-fonte até que seja possível corrigir vulnerabilidades ponta a ponta em 24 horas
    As equipes também estão considerando seriamente fazer forks internos de projetos e dependências essenciais e deixar de contribuir upstream, por medo de que contribuições upstream estejam contaminadas ou introduzam vulnerabilidades adicionais

    • Concordo com a visão do simonw de que, na verdade, o open source deveria se tornar ainda mais valioso
      “Um resultado interessante é que bibliotecas open source se tornam mais valiosas, porque o custo em tokens gasto com segurança pode ser compartilhado entre todos os usuários. Isso rebate diretamente a ideia de que bibliotecas open source perdem atratividade porque alternativas podem ser criadas de forma barata com vibe coding”
      Entendo o impulso de fazer um fork do código e trazê-lo para dentro de casa, mas é discutível o quanto isso é sustentável quando as equipes de engenharia passam a ter ainda mais código para manter e mitigar vulnerabilidades
      [0] https://simonwillison.net/2026/Apr/14/cybersecurity-proof-of...
    • Não entendi o que significa “parar de contribuir e usar open source”
      Afinal, não dá para parar Linux/Kubernetes/Chrome (incluindo Edge)/quase todas as linguagens de programação/nginx etc., então fiquei curioso