จดหมายเปิดผนึกเรียกร้องให้ NHS England เปิดเผยโค้ดต่อสาธารณะต่อไป
(keepthingsopen.com)- คัดค้านการตัดสินใจของฝ่ายผู้นำด้านเทคโนโลยีของ NHS England ที่จะทำให้ซอร์สโค้ดในรีโพซิทอรีเป็นแบบไม่เปิดเผย และยืนยันหลักการว่า โค้ดที่สร้างด้วยเงินทุนสาธารณะ ควรเปิดเผยต่อประชาชน
- เรียกร้องให้ NHS England ถอน SDLC-8 red line และยืนยันคำมั่นต่อ NHS Service Standard Principle 12 “Make new source code open” อีกครั้ง
- การเผยแพร่โอเพนซอร์สต้องใช้ความพยายามมากกว่าการเก็บไว้แบบปิด แต่จำเป็นต่อการกำหนดมาตรฐานคุณภาพที่สูงขึ้น การค้นหาและแก้ไขช่องโหว่ล่วงหน้า และการวาง กำแพงป้องกัน เพื่อลดความเสียหาย
- ซอร์สแบบปิดอาจทำให้มีการข้ามงานด้านความปลอดภัยที่จำเป็น และพึ่งพา ความคลุมเครือ แทนการป้องกันเชิงลึก โดยข้อได้เปรียบที่มอบให้กับผู้โจมตีที่มีแรงจูงใจเพียงพอดูจะมีน้อยมาก
- หลังวันที่ 1 พฤษภาคม 2026 มีผู้ลงนามแล้ว 402 คน โดยผู้ลงนามสามารถส่งชื่อ อีเมล และข้อมูลว่าเคยมีส่วนร่วมกับซอฟต์แวร์ภาครัฐของสหราชอาณาจักรหรือไม่ ส่วนการลงนามแบบไม่ระบุตัวตนจะลบข้อมูลส่วนบุคคลภายใน 24 ชั่วโมงหลังการตรวจสอบ
ข้อเรียกร้องหลักของจดหมายเปิดผนึก
- คัดค้านการตัดสินใจของฝ่ายผู้นำด้านเทคโนโลยีของ NHS England ที่จะซ่อนซอร์สโค้ดของทุกรีโพซิทอรี และยืนยันหลักการว่า โค้ดที่สร้างด้วยเงินทุนสาธารณะ ควรเปิดเผยต่อสาธารณะ
- หลักการนี้มีอยู่ใน UK Government Design Principles และ NHS Service Standard และมองว่าขณะนี้กำลังถอยหลังจากหลักการดังกล่าว
- เรียกร้องให้ NHS England ถอน SDLC-8 red line และยืนยันคำมั่นต่อ NHS Service Standard Principle 12 “Make new source code open” อีกครั้ง
- หลังวันที่ 1 พฤษภาคม 2026 มีผู้ลงนามแล้ว 402 คน และรายชื่อจะถูกแสดงบนหน้าหลังการตรวจสอบด้วยตนเอง
เหตุผลที่ว่าโอเพนซอร์สสร้างมาตรฐานคุณภาพที่เข้มงวดกว่า
- การเปิดเผยโค้ดเป็นโอเพนซอร์สต้องใช้ความพยายามมากกว่าการเก็บไว้แบบปิด
- มองว่า งานที่ยากนี้เองคือหัวใจสำคัญ
- การเปิดเผยแบบโอเพนซอร์สต้องการมาตรฐานคุณภาพที่สูงกว่า และต้องมีกระบวนการค้นหา แก้ไข และเฝ้าระวังช่องโหว่ล่วงหน้า
- ต้องระบุความเสี่ยงและจัดวาง กำแพงป้องกัน เพื่อจำกัดความเสียหายเมื่อเกิดปัญหา
- มีการเปรียบเทียบกับระบบภูมิคุ้มกันของมนุษย์ โดยมองว่าการเผชิญกับภัยคุกคามช่วยทำให้พื้นผิวการโจมตีแข็งแกร่งขึ้น
คำวิจารณ์ต่อซอร์สแบบปิด
- ซอร์สแบบปิดทำให้สามารถข้ามงานด้านความปลอดภัยที่จำเป็นได้
- มองว่าวิธีแบบปิดพึ่งพา ความคลุมเครือ แทนการป้องกันเชิงลึก
- เมื่อมีผู้โจมตีที่มีแรงจูงใจเพียงพอ ข้อได้เปรียบจากความคลุมเครือดูจะน้อยมาก
วิธีลงนามและการจัดการข้อมูลส่วนบุคคล
- ผู้ลงนามสามารถส่งชื่อ ที่อยู่อีเมล ข้อมูลว่าเคยมีส่วนร่วมกับซอฟต์แวร์ภาครัฐของสหราชอาณาจักรหรือไม่ รวมถึงบทบาทและองค์กรซึ่งเป็นข้อมูลทางเลือก
- การมีส่วนร่วมกับซอฟต์แวร์ภาครัฐของสหราชอาณาจักรอาจรวมทั้งการมีส่วนร่วมด้านเทคนิคและไม่ใช่ด้านเทคนิค ทั้งแบบเปิดเผยและไม่เปิดเผย
- หากมีส่วนร่วมอยู่แล้ว เพียงลิงก์ commit หรือโปรไฟล์ก็เพียงพอ และข้อมูลดังกล่าวจะไม่ถูกเปิดเผย
- หากเลือกลงนามแบบไม่ระบุตัวตน รายชื่อจะแสดงเป็น “Anonymous” และอาจแสดงบทบาทกับองค์กรด้วยหากให้ข้อมูลไว้
- สำหรับการลงนามแบบไม่ระบุตัวตน ข้อมูลส่วนบุคคลจะถูกลบภายใน 24 ชั่วโมง หลังการตรวจสอบ
- ที่อยู่อีเมลจะใช้เฉพาะเมื่อจำเป็นต้องติดต่อเกี่ยวกับการลงนาม และจะไม่ถูกเปิดเผย
- ฐานกฎหมายของการประมวลผลข้อมูลส่วนบุคคลคือ ความยินยอม และสามารถถอนความยินยอมได้
- การติดต่อเกี่ยวกับข้อมูลสามารถทำได้ที่ signatures@keepthingsopen.com
- สามารถยื่นข้อร้องเรียนเกี่ยวกับการประมวลผลข้อมูลส่วนบุคคลได้ที่ Information Commissioner’s Office
เอกสารอ้างอิงและลิงก์สนับสนุน
- 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 signatures@keepthingsopen.com
- ซอร์สเผยแพร่ภายใต้ MIT licence
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
การตอบสนองต่อภัยคุกคาม Mythos ดูเหมือนจะเป็นเพียง มาตรการสร้างภาพ ทั้งหมด และทันทีที่มีความโปร่งใสและความเปิดกว้างเกิดขึ้น ก็เผยให้เห็นท่าทีที่พร้อมจะหาข้ออ้างหละหลวมอะไรก็ได้เพื่อย้อนกลับไปปิดอีกครั้ง
มันใกล้เคียงกับการตัดสินใจของคนที่ไม่ใช่สายเทคนิคซึ่งเชื่อว่า “ถ้าไม่เปลี่ยนกลับไปเป็นซอร์สปิด แล้วมีโอกาสแม้แค่ 0.1% ที่จะถูกตำหนิว่าเมื่อพบช่องโหว่แล้วทำได้ไม่มากพอ”
ต้องจำไว้เสมอว่าความโลภและความเห็นแก่ตัวสุดโต่งในปี 2026 ทำให้ตัดสินใจแบบนั้นได้ง่าย แม้ต้องแลกด้วยต้นทุนต่อประโยชน์สาธารณะ และภาคเอกชนเองก็ไม่ได้ดีกว่าในแง่นี้นัก
ภายในองค์กรอาจใช้โมเดลภาษาขนาดใหญ่ค้นหาบั๊กแบบปิด โดยไม่เปิดเผยซอร์สโค้ด เพื่อชิงแก้ปัญหาก่อนผู้โจมตีหนึ่งก้าว
เราเพิ่งเห็นกรณีอย่างหายนะสาธารณะของ Copy.fail ที่ใครบางคนใช้โมเดลภาษาขนาดใหญ่ค้นพบช่องโหว่ แล้วเผยแพร่ออกมาเป็น zero-day โดยไม่มีการแก้ไขที่ชัดเจน ทำให้ชุมชนสับสนและตื่นตระหนก
ในสถานการณ์ที่มีโมเดลภาษาขนาดใหญ่ทรงพลังทั้งแบบเปิดน้ำหนักและปิดน้ำหนัก โดยเฉพาะกับซอฟต์แวร์ที่ใช้ในโรงพยาบาล การทำให้ทุกอย่างเป็นโอเพนซอร์สทั้งหมดโดยไม่มีเงื่อนไขจึงสมเหตุสมผลน้อยลง และต้องมีความสมดุล
ถ้าคุณกำลังดูเธรดนี้เพราะกังวลเรื่องคุณภาพของบริการดิจิทัล NHS อยากให้ช่วยลงชื่อในคำร้องเพื่อป้องกันไม่ให้ผู้ให้บริการของ NHS ซื้อ accessibility overlay ที่ทำลายประสบการณ์ผู้ใช้ของคนพิการจริง ๆ และทำให้เงินที่จะใช้ปรับปรุงบริการหลักต้องสูญเปล่าด้วย: https://petition.parliament.uk/petitions/765480/
ตัวตรวจสอบของ Cloudflare บอกว่าฉันไม่ใช่มนุษย์ เลยลงชื่อไม่ได้
มีวิดีโอที่อธิบายสถานการณ์นี้ได้เข้าใจง่าย: https://youtu.be/XNLUfqtgBUk
ถ้าสาขานี้เป็นความเชี่ยวชาญของคุณ อยากให้ช่วยลงชื่อใน จดหมายเปิดผนึก นี้ด้วย
ต่อให้ NHS เห็นด้วยและพยายามจะทำจริง แค่จัดทำ แนวทางปฏิบัติ ที่เกี่ยวข้องก็น่าจะใช้เวลาอย่างน้อย 1 ปี
จากนั้นถ้าขอให้ทีมเทคโนโลยีปัจจุบันจัดการให้เรียบร้อย ก็คงต้องใช้อีก 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, ผู้ดูแลโครงการ และเพื่อนร่วมงาน บางคนอยู่ในบริษัท F50 และแผนพื้นฐานของพวกเขาคือ หยุดการมีส่วนร่วมและการใช้งานโอเพนซอร์ส จนกว่าทีมความปลอดภัยแอปพลิเคชันจะสามารถตรวจสอบและแก้ปัญหาได้ง่ายภายในหนึ่งวัน
โดยปกติเวลาตอบสนองแบบ end-to-end อยู่ราว 8–10 วัน แต่ตอนนี้ความเร็วระดับนั้นอยู่ไม่ไหวแล้ว
ฉันไม่คิดว่านี่คือความตายของโอเพนซอร์ส แต่มันแสดงให้เห็นว่าเศรษฐศาสตร์ของโอเพนซอร์สได้กลายเป็น โศกนาฏกรรมของทรัพยากรส่วนรวม เมื่อไม่มีการจัดสรรทรัพยากรการปฏิบัติงานที่ยั่งยืนให้ผู้ดูแลโครงการ
และมันยังเป็นการยอมรับด้วยว่าองค์กรต่าง ๆ ไม่ได้ให้ความสำคัญกับความปลอดภัยทั้งในระดับงานวิศวกรรมภายในและระดับองค์กรมาเป็นเวลาหลายทศวรรษ แต่เมื่อดูระดับการสนทนาใน HN ที่นี่แล้ว เรื่องนั้นคงต้องแยกไปคุยอีกหัวข้อ
ถ้าคนที่ชอบโอเพนซอร์สใส่ใจจริง ก็ไม่ควรพูดแต่อุดมคติ แต่ต้องยอมจ่ายเงิน และคิดเรื่องการไปทาง open core หรือจัดหาเงินทุนและสปอนเซอร์อย่างเป็นทางการ
การใช้ไลเซนส์ที่เข้มงวดกว่านี้มาก โดยยังเปิดทางให้เจ้าของโครงการทำเชิงพาณิชย์ได้ ก็เป็นเรื่องสำคัญเช่นกัน โครงการแนว GNU ส่วนใหญ่ที่พึ่งพาเจตนาดีของคนไม่กี่คนที่มีอุดมการณ์คล้ายกันน่าจะอยู่รอดได้ยาก และผู้มีส่วนร่วมก็ควรได้รับค่าตอบแทน
สำหรับคำถามว่า “แล้วจะหยุด Linux/Kubernetes/Chrome(รวม Edge)/ภาษาโปรแกรมแทบทั้งหมด/nginx ฯลฯ ได้จริงหรือ” ความหมายคือ จะตรึง dependency และไลบรารีทั้งหมดที่ใช้อยู่ในอนาคต และจะไม่เปิดเผยซอร์สโค้ดจนกว่าการแก้ช่องโหว่แบบ end-to-end จะทำได้ภายใน 24 ชั่วโมง
ทีมต่าง ๆ ก็กำลังพิจารณาอย่างจริงจังที่จะ fork โปรเจ็กต์หลักและ dependency มาใช้ภายในองค์กร และไม่ส่งโค้ดกลับ upstream เพราะกลัวว่าการมีส่วนร่วมกับ upstream จะปนเปื้อนหรือทำให้เกิดช่องโหว่เพิ่มเติม
“ผลลัพธ์ที่น่าสนใจคือไลบรารีโอเพนซอร์สจะมีคุณค่ามากขึ้น เพราะต้นทุนโทเคนที่ใช้กับงานความปลอดภัยสามารถแชร์ร่วมกันกับผู้ใช้ทุกคนได้ นี่เป็นการโต้แย้งโดยตรงต่อแนวคิดที่ว่าเราสามารถใช้ vibe coding สร้างของทดแทนไลบรารีโอเพนซอร์สได้ราคาถูก จนทำให้ความน่าสนใจของโครงการโอเพนซอร์สดั้งเดิมลดลง”
ฉันเข้าใจแรงสะท้อนอัตโนมัติที่จะ fork โค้ดเข้ามาไว้ภายใน แต่ก็สงสัยว่ามันจะยั่งยืนแค่ไหน ในเมื่อจะยิ่งเพิ่มปริมาณโค้ดที่ทีมวิศวกรรมต้องดูแลและบรรเทาช่องโหว่เอง
[0] https://simonwillison.net/2026/Apr/14/cybersecurity-proof-of...
ก็คงหยุดใช้ Linux/Kubernetes/Chrome(รวม Edge)/ภาษาโปรแกรมแทบทั้งหมด/nginx ฯลฯ ไม่ได้อยู่แล้ว เลยสงสัยว่าหมายถึงอะไร