NHS England से कोड को सार्वजनिक रूप से खुला रखने की अपील करता एक खुला पत्र

• NHS England की तकनीकी लीडरशिप द्वारा repository source code को private करने के फैसले का विरोध करते हुए, यह सिद्धांत फिर से दोहराया गया है कि public funding से बनाया गया code जनता के लिए खुला होना चाहिए
• NHS England से SDLC-8 red line वापस लेने और NHS Service Standard Principle 12 “Make new source code open” के प्रति अपनी प्रतिबद्धता दोबारा स्पष्ट करने की मांग की गई है
• open source के रूप में जारी करना, private बनाए रखने की तुलना में अधिक काम मांगता है, लेकिन इसके लिए ऊंचे quality standards, vulnerabilities की पहले से पहचान और सुधार, तथा नुकसान को सीमित करने वाली barriers बनाना जरूरी है
• private source ज़रूरी security work को छोड़ देने की ओर धकेल सकता है, defense in depth के बजाय obscurity पर निर्भर करता है, और पर्याप्त रूप से प्रेरित attacker के सामने इससे मिलने वाला लाभ बहुत छोटा दिखता है
• 1 मई 2026 के बाद से 402 लोगों ने हस्ताक्षर किए हैं, और हस्ताक्षरकर्ता नाम, ईमेल, UK public sector software में योगदान है या नहीं आदि जमा कर सकते हैं; anonymous हस्ताक्षरों के मामले में verification के 24 घंटे के भीतर personal data हटा दिया जाता है

---

खुले पत्र की मुख्य मांगें

• NHS England की तकनीकी लीडरशिप के सभी repositories ke source code ko chhipane ke faisle ka virodh kiya gaya hai, aur public funding se banaya gaya code janta ke liye khula hona chahiye, is siddhant ki phir se pushti ki gayi hai
• yah siddhant UK Government Design Principles aur NHS Service Standard mein shamil hai, aur mana gaya hai ki filhal isse peeche hatna ho raha hai
• NHS England se SDLC-8 red line wapas lene aur NHS Service Standard Principle 12 “Make new source code open” ke prati pratibaddhata ki punarpushti ki maang ki gayi hai
• 1 मई 2026 के बाद से 402 लोगों ने हस्ताक्षर किए हैं, और हस्ताक्षर manual review के बाद पेज पर दिखाए जाते हैं

यह तर्क कि open source अधिक सख्त quality standards बनाता है

• code को open source के रूप में जारी करना, उसे private रखने की तुलना में अधिक काम मांगता है
• इसे वही कठिन काम असली मुद्दा है के रूप में देखा गया है
• open source जारी करने के लिए ऊंचे quality standards, vulnerabilities को पहले से खोजने और ठीक करने, तथा monitoring की प्रक्रियाएं जरूरी होती हैं
• risks की पहचान करनी होती है, और समस्या होने पर नुकसान सीमित करने वाली barriers बनानी पड़ती हैं
• इसे मानव immune system से तुलना करते हुए कहा गया है कि threats के exposure से attack surface अधिक मजबूत होता है

private source पर आलोचना

• private source ज़रूरी security work को छोड़ देने की गुंजाइश देता है
• यह माना गया है कि private approach defense in depth के बजाय obscurity पर निर्भर करती है
• पर्याप्त रूप से प्रेरित attacker की मौजूदगी में obscurity से मिलने वाला लाभ बहुत छोटा दिखता है

हस्ताक्षर की प्रक्रिया और personal data handling

• हस्ताक्षरकर्ता नाम, ईमेल address, UK public sector software में योगदान है या नहीं, और वैकल्पिक रूप से role तथा organization जमा कर सकते हैं
• UK public sector software में योगदान में technical और non-technical, दोनों तरह के योगदान, तथा public और private दोनों तरह के योगदान शामिल हो सकते हैं
• यदि योगदान है, तो commit या profile link जैसा साधारण प्रमाण पर्याप्त है, और यह जानकारी public नहीं की जाती
• anonymous हस्ताक्षर चुनने पर हस्ताक्षर “Anonymous” के रूप में दिखाया जाता है, और यदि role तथा organization दी गई हो तो वे साथ दिख सकते हैं
• anonymous हस्ताक्षरों के मामले में verification के 24 घंटे के भीतर personal data हटा दिया जाता है
• ईमेल address का उपयोग केवल हस्ताक्षर से संबंधित संपर्क की जरूरत होने पर किया जाता है और इसे public नहीं किया जाता
• personal data processing का कानूनी आधार consent है, और consent वापस लिया जा सकता है
• data से संबंधित संपर्क [e-mail] पर किया जा सकता है
• personal data processing पर शिकायत Information Commissioner’s Office में दर्ज की जा सकती है

संदर्भ सामग्री और support links

• NHS Goes To War Against Open Source
• NHS England rushes to hide software over AI hacking fears
• NHS Service Standard — Principle 12: Make new source code open
• NHS England quietly removes open source policy web pages (Digital Health)
• Don’t be afraid to code in the open: how to do it securely (GOV.UK)
• Does Mythos mean shutting down your open source repos? (shkspr.mobi)
• Discourse is not going closed source (Discourse)
• View on GitHub
• Sign
• Email [e-mail]
• source MIT licence के तहत उपलब्ध है

[GN⁺]

Hacker News की टिप्पणियाँ

• Mythos खतरे के प्रति प्रतिक्रिया पूरी तरह दिखावटी कदम जैसी लगती है, और जैसे ही पारदर्शिता व openness आती है, किसी भी कमजोर बहाने से उसे वापस लेने की कोशिश दिखती है
  यह ज़्यादा उस फैसले जैसा है जो कोई गैर-तकनीकी व्यक्ति इस सोच के साथ लेता है कि “अगर हमने इसे closed source में नहीं बदला और कोई vulnerability मिली, तो भले ही 0.1% संभावना हो कि हमें पर्याप्त न करने के लिए दोष दिया जाएगा”
  2026 की चरम लालच और स्वार्थ ऐसी बातों को सार्वजनिक हित की कीमत पर भी आसान बना देते हैं, और यह हमेशा याद रखना चाहिए कि private sector भी इस मामले में कोई खास बेहतर नहीं है

  • एकमात्र अपवाद तब होगा जब बंद किए जाने के बाद कोड में काफी बड़े बदलाव हुए हों, और हमलावर या large language models उन बदलावों को पढ़ न सकें
    अगर अंदरूनी तौर पर large language models का उपयोग करके source code को public किए बिना private रूप में bug ढूँढ़े जाएँ, तो हमलावरों से एक कदम आगे रहा जा सकता है
    हाल की Copy.fail public disaster की तरह, हमने यह भी देखा है कि large language models इस्तेमाल करने वाले किसी व्यक्ति द्वारा खोजी गई vulnerability बिना किसी साफ fix के zero-day के रूप में public हो गई, जिससे community में भ्रम और घबराहट फैल गई
    जब powerful large language models public weights और closed weights दोनों रूपों में मौजूद हैं, तब खासकर अस्पतालों में इस्तेमाल होने वाले software के लिए हर चीज़ को बिना शर्त open source बना देना पहले जितना उचित नहीं रह गया है, और संतुलन ज़रूरी है

• अगर आप NHS digital services की quality को लेकर चिंतित हैं और इसी वजह से यह thread देख रहे हैं, तो कृपया उस petition पर भी हस्ताक्षर करें जो NHS providers को accessibility overlays खरीदने से रोकना चाहती है, क्योंकि वे वास्तव में disabled users के अनुभव को नुकसान पहुँचाती हैं और core services सुधारने में लगने वाला पैसा बर्बाद करती हैं: https://petition.parliament.uk/petitions/765480/

• Cloudflare verifier मुझे इंसान नहीं मान रहा, इसलिए मैं हस्ताक्षर नहीं कर पा रहा हूँ

  • आप email भेज सकते हैं या यहाँ signature pull request भेज सकते हैं: https://github.com/tvararu/keepthingsopen.com

• इस स्थिति को आसानी से समझाने वाला एक वीडियो है: https://youtu.be/XNLUfqtgBUk
  अगर यह आपका विशेषज्ञता वाला क्षेत्र है, तो कृपया open letter पर ज़रूर हस्ताक्षर करें

• भले ही NHS सहमत हो जाए और इसे लागू करना चाहे, संबंधित guidance बनाने में ही कम-से-कम 1 साल लग जाएगा
  उसके बाद मौजूदा tech team से इसे व्यवस्थित करने को कहेंगे, तो शायद 10 साल और लग जाएँ

• संबंधित लेख: 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)

• पिछले कुछ हफ्तों में मैंने इस विषय पर CISO, CTO, maintainers और साथियों से बात की है, जिनमें कुछ F50 कंपनियों से हैं, और उनकी default plan यह है कि जब तक application security teams एक दिन के भीतर समस्याओं को आसानी से verify और fix नहीं कर सकतीं, तब तक open source contribution और usage रोक दिया जाए
  पारंपरिक रूप से end-to-end response time लगभग 8–10 दिन का रहा है, लेकिन अब उस रफ्तार से काम नहीं चल सकता
  मैं इसे open source की मौत नहीं मानता, लेकिन यह दिखाता है कि maintainers को sustainable operating resources न मिलने से open source की अर्थव्यवस्था tragedy of the commons में बदल गई है
  यह इस बात की स्वीकारोक्ति भी है कि संगठनों ने दशकों तक engineering के भीतर और organizational स्तर पर security को प्राथमिकता नहीं दी, लेकिन यहाँ HN पर बातचीत की गुणवत्ता देखकर लगता है कि वह अलग चर्चा का विषय है
  अगर open source पसंद करने वाले लोग सच में इसकी परवाह करते हैं, तो उन्हें सिर्फ आदर्शवाद की बातें नहीं करनी चाहिए बल्कि पैसा लगाना चाहिए, और open core अपनाने या औपचारिक funding व sponsorship की व्यवस्था करने के तरीके सोचने चाहिए
  project owners को commercialization की अनुमति देते हुए कहीं अधिक restrictive licenses लाना भी महत्वपूर्ण है. समान विचारधारा वाले कुछ व्यक्तियों की goodwill पर टिके ज़्यादातर GNU-style projects का बचना मुश्किल है, और contributors को भी भुगतान मिलना चाहिए
  “क्या Linux/Kubernetes/Chrome(Edge सहित)/लगभग सभी programming languages/nginx वगैरह को बंद किया जा सकता है?” इस सवाल पर, मतलब यह है कि आगे उपयोग होने वाली सभी dependencies और libraries को freeze कर दिया जाए, और जब तक end-to-end vulnerability fixes 24 घंटे के भीतर संभव न हों, source code को public न किया जाए
  टीमें core projects और dependencies को internal use के लिए fork करने, और upstream contribution दूषित हो चुकी है या नई vulnerabilities ला सकती है इस डर से upstream में योगदान न करने जैसे विकल्पों पर भी गंभीरता से विचार कर रही हैं

  • simonw के दृष्टिकोण की तरह मैं भी इससे सहमत हूँ कि open source को और अधिक मूल्यवान होना चाहिए
    “दिलचस्प परिणाम यह है कि open source libraries अधिक मूल्यवान हो जाती हैं, क्योंकि security पर खर्च किए गए token costs को सभी users के साथ साझा किया जा सकता है. यह उस विचार का सीधा खंडन है कि vibe coding के जरिए open source library alternatives को सस्ते में बनाया जा सकता है, जिससे मौजूदा open source projects का आकर्षण कम हो जाएगा”
    कोड को fork करके अंदर ले आने की स्वाभाविक प्रतिक्रिया समझ में आती है, लेकिन जब engineering teams को और ज़्यादा कोड manage करना पड़े और vulnerabilities को mitigate करना पड़े, तब यह कितना sustainable होगा, इस पर संदेह है
    [0] https://simonwillison.net/2026/Apr/14/cybersecurity-proof-of...
  • “open source contribution और usage रोक दिया जाए” से आपका मतलब क्या है, यह समझ नहीं आया
    Linux/Kubernetes/Chrome(Edge सहित)/लगभग सभी programming languages/nginx वगैरह को तो बंद नहीं किया जा सकता, इसलिए जिज्ञासा है