- ประธานาธิบดี Joe Biden ลงนามใน SHARE IT Act เมื่อวันที่ 23 ธันวาคม ทำให้หน่วยงานรัฐบาลกลางสหรัฐฯ ต้องแชร์ซอร์สโค้ดแบบปรับแต่งเองให้กันและกัน เพื่อลดสัญญาพัฒนาที่ซ้ำซ้อน
- ประเด็นหลักคือการจัดทำรายการโค้ดแบบปรับแต่งเองของแต่ละหน่วยงานให้เปิดเผยและนำกลับมาใช้ซ้ำได้ เพื่อลดงบประมาณ ประมาณ 12,000 ล้านดอลลาร์ ที่รัฐบาลกลางคาดว่าใช้จ่ายกับการซื้อซอฟต์แวร์ในแต่ละปี
- ขอบเขตการบังคับใช้กฎหมายไม่รวม โค้ดลับ, ระบบความมั่นคงแห่งชาติ และโค้ดที่อาจก่อความเสี่ยงด้านข้อมูลส่วนบุคคลหากนำไปแชร์
- CIO ของหน่วยงานต้องจัดทำนโยบายการดำเนินการภายใน 180 วัน หลังมีผลบังคับใช้ ซึ่งรวมถึงการปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุด, การเปิดเผยเมทาดาทา และขั้นตอนการรายงานที่เป็นมาตรฐาน
- Atlassian และ GitLab Inc. สนับสนุนร่างกฎหมายนี้ และร่างกฎหมายผ่านสภาสูงและสภาผู้แทนราษฎรในเดือนธันวาคมโดยไม่มีการลงคะแนนแบบบันทึกชื่อ
ข้อบังคับการแชร์โค้ดของ SHARE IT Act
- Source Code Harmonization And Reuse in Information Technology Act หรือ SHARE IT Act กำหนดให้หน่วยงานรัฐบาลกลางแชร์ซอร์สโค้ดที่พัฒนาขึ้นแบบปรับแต่งเองกับหน่วยงานอื่น
- มุ่งลด การพัฒนาซ้ำซ้อน ซึ่งเกิดจากการทำสัญญาพัฒนาใหม่โดยไม่รู้ว่ามีโค้ดที่พัฒนาให้หน่วยงานอื่นอยู่แล้ว
- หน่วยงานต้องจัดทำรายการโค้ดแบบปรับแต่งเองให้เปิดเผยต่อสาธารณะ และทำให้หน่วยงานอื่นสามารถนำโค้ดนั้นไปใช้ได้
เป้าหมายการประหยัดงบประมาณและข้อยกเว้นการบังคับใช้
- ผู้สนับสนุนร่างกฎหมายประเมินว่ารัฐบาลกลางใช้จ่าย ประมาณ 12,000 ล้านดอลลาร์ ต่อปีในการซื้อซอฟต์แวร์
- SHARE IT Act เป็นกฎหมายที่มุ่งลดค่าใช้จ่ายนี้ผ่านการนำโค้ดแบบปรับแต่งเองกลับมาใช้ซ้ำ
- โค้ดต่อไปนี้ไม่อยู่ในขอบเขตการบังคับใช้ของกฎหมาย
- โค้ดลับ
- ระบบความมั่นคงแห่งชาติ
- โค้ดที่อาจก่อให้เกิดความเสี่ยงด้านข้อมูลส่วนบุคคลหากแชร์
หน้าที่ของ CIO หน่วยงานในการจัดทำนโยบายภายใน 180 วัน
- Chief Information Officer (CIO) ของหน่วยงานต้องจัดทำนโยบายการดำเนินการตาม SHARE IT Act ภายใน 180 วัน หลังจากกฎหมายมีผลบังคับใช้
- นโยบายต้องรวมขั้นตอนต่อไปนี้
- ขั้นตอนเพื่อรับประกันว่าโค้ดที่พัฒนาแบบปรับแต่งเองสอดคล้องกับ แนวทางปฏิบัติที่ดีที่สุด
- ขั้นตอนในการเปิดเผยเมทาดาทาของโค้ดแบบปรับแต่งเองต่อสาธารณะ
- ขั้นตอนการรายงาน ที่เป็นมาตรฐาน
เมทาดาทาที่ต้องเปิดเผย
- เมทาดาทาตามที่กฎหมายระบุรวมถึงข้อมูลที่ช่วยตรวจสอบสถานะการพัฒนาและการแชร์ของโค้ดแบบปรับแต่งเอง
- รายการที่รวมอยู่มีดังนี้
- โค้ดแบบปรับแต่งเองถูกพัฒนาตามสัญญาหรือไม่
- โค้ดถูกแชร์ใน repository แล้วหรือไม่
- หมายเลขสัญญา
- ไฮเปอร์ลิงก์ ไปยัง repository ที่โค้ดถูกแชร์ไว้
ความคืบหน้าทางนิติบัญญัติและการสนับสนุนจากอุตสาหกรรม
- ร่างกฎหมายได้รับการสนับสนุนในวุฒิสภาโดย Ted Cruz และ Gary Peters และในสภาผู้แทนราษฎรโดย Nicholas Langworthy และ William Timmons
- สภาสูงและสภาผู้แทนราษฎรผ่านร่างกฎหมายในเดือนธันวาคมโดยไม่มีการลงคะแนนเห็นชอบหรือคัดค้านแบบบันทึกชื่อ
- ตามประกาศการเสนอร่างในสภาผู้แทนราษฎรของ Langworthy เมื่อเดือนกันยายน Atlassian และ GitLab Inc. สนับสนุนร่างกฎหมายนี้
- Stan Shepard หัวหน้าฝ่ายกฎหมายของ Atlassian มองว่าการขยายความร่วมมือและการแชร์โค้ดแบบปรับแต่งเองจะส่งเสริมความเปิดกว้าง ประสิทธิภาพ และนวัตกรรมทั่วทั้งองค์กรของรัฐบาลกลาง
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ถ้าไม่มีประสบการณ์ในภาครัฐ อาจนึกไม่ออกว่าทำไมเรื่องนี้ถึงยากขนาดนี้ กองทัพแพ้ซอฟต์แวร์ภายในองค์กรเหมือนแพ้ยา และ IT ของกองทัพก็เป็นอีกโลกหนึ่งโดยสิ้นเชิง ที่ถูกผู้บุกรุกระดับรัฐชาติที่ได้รับการสนับสนุน ซึ่งเก่งที่สุดในโลก โจมตีทุกวัน
สตาร์ทอัพไม่ได้เจอเรื่องแบบนี้ และแม้แต่บริษัทใหญ่แบบ Facebook ก็เพียงแค่พอจะเจอระดับที่ใกล้เคียงกันในแง่ความสำคัญเท่านั้น ส่วนในภาคเอกชนที่ใกล้เคียงที่สุดก็คงเป็นสถาบันการเงินขนาดใหญ่ กองทัพสหรัฐฯ ยังเป็นนายจ้างรายเดียวที่ใหญ่ที่สุดบนโลก ขนาดเท่ากับ Walmart 4.5 แห่งรวมกัน
ดังนั้นกองทัพจึงเฝ้าระวังทุกอย่างหลายชั้น และล็อกดาวน์อย่างเข้มงวดด้วยรายการซอฟต์แวร์ที่ได้รับอนุมัติแยกตามชั้น คนที่เขียนหรือคุมดูแลนโยบายความปลอดภัยมีแนวโน้มจะไม่ใช่ผู้อำนวยการซอฟต์แวร์ที่ชำนาญ และเมื่อพวกเขาเห็น NPM หรือ Maven ก็จะมองว่าเป็นเวกเตอร์โจมตีแบบไม่จำกัดที่สร้างขึ้นโดยคนที่ไม่รู้เรื่องความปลอดภัย ซึ่งก็ไม่ได้ผิดเสียทีเดียว
ในฝั่งพลเรือนและผู้รับเหมา ความเป็นเจ้าของโค้ดก็ซับซ้อนเช่นกัน ถ้าสร้างด้วยเงินรัฐบาลก็ควรเป็นของรัฐบาล แต่ผู้รับเหมามองว่าต้องถือเป็นทรัพย์สินของตนเองที่แยกจากรัฐบาล เพื่อจะเรียกเก็บเงินซ้ำได้ เรื่องยิ่งซับซ้อนขึ้นถ้าผู้รับเหมาช่วงไม่สอดคล้องกับเป้าหมายทางการเงินของผู้รับเหมาหลัก ส่วนตัวผมคิดว่าแค่ส่งมอบให้รัฐบาลทั้งหมดก็พอ แต่ก็แปลกที่ผู้คนตั้งกำแพงเป็นชั้นๆ โครงสร้างพื้นฐานฝั่งรัฐบาลมีระดับการรับรองความปลอดภัยสูงกว่ามาก โดยรวมจึงมักมีข้อจำกัดน้อยกว่าด้วย
บางส่วนของกองทัพสหรัฐฯ อาจเผชิญภัยคุกคามและความประณีตด้านความปลอดภัยในระดับที่อธิบายไว้ แต่โดยรวมแล้วมีระบบเลกาซีจำนวนมากที่ยากจะผสานโซลูชันสมัยใหม่หรือแนวปฏิบัติที่ดีเข้าไป ระบบ เวิร์กโฟลว์ และระบบราชการที่ล้าสมัยเหล่านี้มักก่อให้เกิดความไร้ประสิทธิภาพและช่องโหว่มากกว่าความปลอดภัยที่ยอดเยี่ยม
การที่เราไม่ค่อยได้ยินว่ากองทัพสหรัฐฯ ถูกเจาะ ไม่ใช่เพราะไม่เกิดขึ้น แต่เพราะเมื่อเกิดแล้วจะถูกจัดเป็นความลับ การหลีกเลี่ยงความอับอายในที่สาธารณะเป็นการใช้งานอันดับหนึ่งของการจัดชั้นความลับ จึงทำให้เกิดความเชื่อว่าพวกเขาเก่ง ถ้าเป็นผม ผมจะให้ ความปลอดภัยของ Facebook อยู่เหนือกองทัพสหรัฐฯ ได้ทุกเมื่อ และคิดว่าช่องว่างก็ไม่ได้น้อย Facebook ยังเป็นผู้ประมวลผลการชำระเงินด้วย
เมื่อคิดถึงความสำคัญของ AWS แล้ว ก็ชัดเจนว่า Amazon น่าจะเผชิญภัยคุกคามคล้ายกัน
(A) บททั่วไป—กฎหมายนี้ไม่ใช้บังคับกับซอร์สโค้ดลับ หรือซอร์สโค้ดที่พัฒนาขึ้นเพื่อใช้เป็นหลักในระบบความมั่นคงแห่งชาติตามนิยามใน 40 U.S.C. 11103
(B) ความมั่นคงแห่งชาติ—การยกเว้นจากข้อกำหนดในมาตรา 3 ใช้กับซอร์สโค้ดลับ หรือซอร์สโค้ดต่อไปนี้: (i) โค้ดที่พัฒนาขึ้นเพื่อใช้เป็นหลักในระบบความมั่นคงแห่งชาติ หรือ (ii) โค้ดที่พัฒนาโดยหน่วยงานสมาชิกของประชาคมข่าวกรอง หรือส่วนหนึ่งของหน่วยงานนั้น ตามนิยามในมาตรา 3(4) ของกฎหมายความมั่นคงแห่งชาติ ค.ศ. 1947
ตอนนั้นเองที่ผมเข้าใจว่า ธุรกิจรับสัญญาจากรัฐบาล มีโครงสร้างอย่างไร และทำไมงานถึงลากยาวเกินจำเป็นไปหลายปี
มันเป็นเงินภาษีของเรา แล้วทำไมเราถึงไปสนับสนุนการดึงเงินออกจากกระเป๋าของทุกคน เพื่อทำให้ผู้มีอิทธิพลบางคนและฝ่ายขายบางกลุ่มในบริษัทนั้นรวยขึ้นอย่างมาก
ถ้าจุดยืนคือ “จะไม่มอบทุกอย่างให้รัฐบาล” วิธีที่สมเหตุสมผลน่าจะเป็นการให้สิทธิ์รัฐบาลใช้ผลงานส่งมอบตามที่ต้องการ ขณะเดียวกันก็อนุญาตให้ขายส่วนประกอบที่ไม่เป็นความลับและงานอนุพันธ์ของมันให้ภาคเอกชนได้อย่างเสรี
กฎหมายกำหนดให้ CIO ของหน่วยงานต้องจัดทำนโยบายภายใน 180 วันหลังมีผลบังคับใช้ โดยนโยบายนั้นต้องทำให้โค้ดที่พัฒนาแบบเฉพาะตรงตามแนวปฏิบัติที่ดีที่สุด และต้องกำหนดขั้นตอนสำหรับเปิดเผยเมทาดาทาของโค้ดเฉพาะ รวมถึงขั้นตอนการรายงานมาตรฐาน
ในกฎหมายใหม่นี้ เมทาดาทาประกอบด้วยข้อมูลว่าโค้ดเฉพาะนั้นพัฒนาภายใต้สัญญาหรือไม่ ถูกแชร์ใน repository หรือไม่ หมายเลขสัญญา และลิงก์ไปยัง repository ที่แชร์โค้ดนั้น
น่าเสียดายที่กฎหมายนี้ดูเหมือนจะไม่ได้บังคับให้หน่วยงานต้องทำให้โค้ดเป็นโอเพนซอร์สสาธารณะ แต่กำหนดเพียงให้ แชร์ระหว่างหน่วยงาน เท่านั้น สิ่งที่ต้องแชร์ต่อสาธารณะมีเพียง “เมทาดาทา” เท่านั้น ข้อความเต็มของร่างกฎหมายอยู่ที่ https://www.congress.gov/bill/118th-congress/house-bill/9566...
มีข้อยกเว้นอยู่บ้าง แต่ก็เคยมีเหตุผลว่า contractor รายอื่น ๆ ต้องยังคงมีความสามารถในการแก้ไข source code และไม่เปิดเผยในลักษณะเดียวกันด้วย คาดว่าอาจเป็นเพราะด้านกลาโหม
หากจะเก็บไว้ไม่เปิดเผยเพราะเรื่องเงิน เกณฑ์จะสูง แต่การเก็บไว้ไม่เปิดเผยด้วยเหตุผลอื่นใดนั้นทำได้เสมอ DOE Code เป็นโปรแกรมที่ติดตามซอฟต์แวร์โอเพนซอร์ส และโดยปกติจัดการผ่าน GitHub organization ส่วน OSTI เป็นหน่วยงานที่ติดตามทรัพย์สินทางปัญญาและงานวิจัยทั้งหมด
โมเดลการพัฒนาแบบโอเพนซอร์สก็เป็นประโยชน์ต่อ LLNL เช่นกัน และทำให้ได้ codebase ที่ดีกว่าการพัฒนาเพียงลำพังอย่างมาก
มีบางอย่างที่เปิดเผยอยู่แล้ว เช่น NASA IKOS: https://github.com/NASA-SW-VnV/ikos
โปรเจกต์นี้ได้รับความสนใจจากบุคคลภายนอกน้อยกว่าที่ควรจะได้รับมาก หากพัฒนาไปเป็น static analyzer แบบ sound ทั่วไปที่รองรับ multithreading ได้ ก็จะช่วยปรับปรุงโปรเจกต์อื่น ๆ ได้อีกมาก
เคยพยายามผลักดัน โมเดลโอเพนซอร์ส เต็มรูปแบบ ด้วยแนวคิดว่า “ถ้าเป็นงบประมาณสาธารณะ ผลลัพธ์ที่เกิดจากเงินนั้นก็ควรให้สาธารณะได้เห็น”: https://web.archive.org/web/20200920095030/http://oss4gov.or...
ตอนนั้นมองว่าค่าเริ่มต้นของซอฟต์แวร์ภาครัฐควรเป็นโอเพนซอร์ส เว้นแต่มีข้อยกเว้นที่ได้รับอนุมัติระดับรัฐมนตรี แต่ตอนนั้นยังเด็กและไร้เดียงสา
Ghidra เป็นตัวอย่างที่ดี และการที่ซอฟต์แวร์นี้เปิดให้ใช้ฟรีถือเป็นประโยชน์อย่างมากต่อชุมชนความปลอดภัย
เรากำลังสร้างซอฟต์แวร์โอเพนซอร์สและพยายามให้หน่วยงานรัฐนำไปใช้หรือใช้งาน แต่ระดับที่หน่วยงานเหล่านี้ดูเหมือนจะ แพ้โอเพนซอร์ส นั้นน่าทึ่งมาก
บางแห่งเลือกทำเองด้วยวิธี legacy อย่างการอัปโหลด CSV หรือ parser ที่พัง แทนที่จะใช้โค้ดของคนอื่น แล้วก็สร้างบั๊กและข้อบกพร่องที่คาดเดาได้ตามมาด้วย
แม้ตอนตอบ RFP ฝั่งโอเพนซอร์สก็ถูกตรวจสอบเข้มกว่าระบบปิด ต้องพิสูจน์ให้ได้ว่าการเปิดเผยนั้นเป็นเรื่องดี แต่ถ้าเป็นระบบปิด vendor แค่บอกว่า “ครับ สมบูรณ์แบบ” แล้วหน่วยงานก็ปล่อยผ่านได้ รู้สึกเหมือนหน่วยงานและพนักงานไม่อยากรับผิดชอบอะไรเลย ถึงอย่างนั้นผมก็ไม่เคยเห็นใครเสียงานราชการเพราะไร้ความสามารถ
ผมทำงานในภาครัฐและเจอมากับตัว วัฒนธรรมเป็นพิษรุนแรงและพังมาก รอดูว่า Elon กับทีมของ Trump จะเสนอการเปลี่ยนแปลงแบบไหน
กระทรวงกลาโหมสหรัฐฯ มี FAQ เกี่ยวกับซอฟต์แวร์โอเพนซอร์ส: http://dodcio.defense.gov/OpenSourceSoftwareFAQ.aspx และ https://github.com/risacher/DoD-OSS-FAQ
เวอร์ชันนี้ถูกเผยแพร่บน GitHub เพื่อเป็นการทดลองใช้เครื่องมือทำงานร่วมกันสำหรับการมีส่วนร่วมสาธารณะต่อเอกสารนโยบายของรัฐบาล และระบุว่าบุคลากรทหารและพลเรือน ผู้รับเหมา และประชาชนทั่วไปสามารถส่งข้อเสนอแก้ไขหรือเพิ่มเติมผ่าน pull request ได้
วิดีโอปี 2010: https://www.youtube.com/watch?v=WWt0YiXcEkE
Dan Risacher จากสำนักงาน DoD CIO และ David A. Wheeler ผู้เชี่ยวชาญด้านความปลอดภัยโอเพนซอร์ส อธิบายประวัติและผลกระทบของบันทึก DoD ฉบับล่าสุดที่ทำให้จุดยืนชัดเจนว่า กระทรวงกลาโหมมองโอเพนซอร์สเป็นรูปแบบหนึ่งของซอฟต์แวร์เชิงพาณิชย์ที่ใช้งานได้จริง
เอกสารปี 2024: https://openssf.org/press-release/2024/10/29/openssf-expands...
OpenSSF ของ Linux Foundation ระบุว่ายอมรับถึงความจำเป็นของการอบรมด้านความปลอดภัย และตามคำกล่าวของ David A. Wheeler ผู้อำนวยการด้านความปลอดภัยซัพพลายเชนโอเพนซอร์สของ OpenSSF มีผู้ลงทะเบียนใช้สื่อการเรียนรู้นี้แล้วมากกว่า 25,000 คนตั้งแต่เริ่มหลักสูตร
เจตนาดี แต่ในทางปฏิบัติไม่น่าจะเกิดอะไรมาก นอกจากคู่แข่งที่มีศักยภาพของผู้รับเหมารายที่ 1 จะไล่ตามช่องว่างให้ทัน หรือโจมตีโดยอ้างคุณภาพโค้ดของสัญญาเดิม การอ่านโค้ด ยากกว่าการเขียนโค้ด
ถ้าโจมตีโดยอ้างคุณภาพโค้ดของสัญญาเดิม นั่นก็คือ code review และไม่ทางใดก็ทางหนึ่งจะนำไปสู่การปรับปรุงคุณภาพโค้ด ผมไม่เห็นว่าปัญหาอยู่ตรงไหน
เป็นเรื่องที่ยอดเยี่ยม ผมจำได้ว่าเคยลำบากแม้กระทั่งกับการอ่านโค้ดภายในองค์กรเดียวกัน การเปลี่ยนแปลงแบบนี้น่าจะทำให้คนที่สร้าง mental model แบบ top-down ทำงานได้ง่ายขึ้น
โดยทั่วไป ทุกอย่างที่จ่ายด้วย เงินภาษี ควรถูกเปิดเผย Public Monies Public Goods ควรเป็นหลักการพื้นฐานอย่างเด็ดขาด
ถึงอย่างนั้นก็ยังหยุดผู้รับเหมาที่ไร้จริยธรรมจากการอ้างลิขสิทธิ์โค้ดและเก็บค่าไลเซนส์ไม่ได้ โค้ดส่วนใหญ่ของ DoE เป็นแบบนั้น และมีข้อยกเว้นอย่าง NWCHEM ผมสงสัยมาตลอดว่าทำไมถึงไม่กลายเป็นคดีความ อาจเป็นเพราะไม่มีใครใส่ใจมากนัก
ด้านหนึ่งก็เข้าใจได้ว่าพื้นที่อื่นเหมือนใช้ฟรีระบบข้อบัญญัติที่ผู้เสียภาษีในพื้นที่นั้นออกค่าใช้จ่ายให้ โดยเฉพาะถ้ากฎหมายนั้นใช้กับรัฐบาลท้องถิ่นของพื้นที่เป็นหลัก แต่อีกด้านหนึ่งก็รู้สึกแปลกที่ กฎหมายถูกจำกัดด้วยลิขสิทธิ์
เวลาคุณจ้างใครมาทำงานที่บ้าน ก็ควรคิดด้วยว่านอกจากผลงานสุดท้ายแล้ว คุณเป็นเจ้าของอะไรอย่างแน่ชัดบ้าง
เป็นทิศทางที่ยอดเยี่ยม เคยทำงานกับทีมรัฐบาลและเห็นว่ามีที่หนึ่งเสนอแนวทางแบบนี้เป็นแนวปฏิบัติที่แนะนำ: https://www.forgov.qld.gov.au/information-and-communication-...
อย่างไรก็ตาม ในหลายกรณียังจำเป็นต้องมีขั้นตอนทำให้คำแนะนำนั้นกลายเป็น ข้อกำหนดทางกฎหมาย เพื่อให้มีการปฏิบัติตามจริง โดยเฉพาะในบริการสาธารณะ เพราะมักมีคนที่ไม่เคยเข้าร่วมชุมชนโอเพนซอร์สมาก่อนอยู่มาก
อย่างที่หลายคนย้ำไว้ งบประมาณสาธารณะควรนำไปสู่ประโยชน์สาธารณะ และโอเพนซอร์สเป็นวิธีที่ดีในการเพิ่มประโยชน์นั้น
มีข้อความว่า “กฎหมายใหม่ไม่ใช้กับโค้ดลับ โค้ดของระบบความมั่นคงแห่งชาติ หรือโค้ดที่หากแชร์แล้วจะก่อให้เกิดความเสี่ยงต่อข้อมูลส่วนบุคคล”
โค้ดแบบไหนกันที่แชร์แล้วจะก่อให้เกิดความเสี่ยงต่อข้อมูลส่วนบุคคล? ฟังดูเหมือนหมายความว่าโค้ดกับข้อมูลถูกปะปนกันอย่างแย่มาก
ผู้รับเหมารัฐบาลยอมรับโดยนัยอย่างเต็มใจว่าโค้ดของตนคุณภาพแย่ และโดยมากพึ่งพา security through obscurity คณะกรรมการข้อมูลก็เคยตัดสินเข้าข้างพวกเขาอยู่หลายครั้ง
ลองคิดดูว่าจะเห็นอะไรได้บ้างจากสูตร Excel เป็นต้น