QEMU - กำหนดนโยบาย "ห้ามใช้เครื่องมือสร้างโค้ดด้วย AI"

 (github.com/qemu)
3 คะแนน โดย GN⁺ 2025-06-26 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ชุมชน QEMU ได้ปรับนโยบายล่าสุด โดยห้ามใช้เครื่องมือสร้างโค้ดด้วย AI (เช่น Copilot, ChatGPT เป็นต้น) และห้ามส่งโค้ดที่มาจากเครื่องมือดังกล่าว

define policy forbidding use of AI code generators

  • ช่วงหลังมานี้ความสนใจต่อการใช้ เครื่องมือสร้างโค้ดด้วย AI เพิ่มสูงขึ้นมาก แต่การตีความด้านไลเซนส์ของผลลัพธ์จากเครื่องมือเหล่านี้ยังไม่ได้รับการยอมรับอย่างกว้างขวางในอุตสาหกรรม
  • ผู้ให้บริการรายใหญ่ยืนยันว่า ไม่มีปัญหาและสามารถเลือกไลเซนส์ได้อย่างอิสระ แต่ฝ่ายเหล่านี้ก็มีผลประโยชน์ทับซ้อนอยู่
  • เนื่องจากเครื่องมือสร้างโค้ดด้วย AI ถูกสร้างขึ้นจากข้อมูลฝึกที่อยู่ภายใต้ไลเซนส์หลากหลายประเภท จึงยังไม่มีฉันทามติในอุตสาหกรรมเกี่ยวกับปัญหาไลเซนส์ของผลลัพธ์
  • QEMU กำหนดใน DCO (Developer Certificate of Origin) ว่าผู้มีส่วนร่วมต้องมีสิทธิอย่างชัดเจนในการนำโค้ดมามีส่วนร่วมภายใต้ไลเซนส์ของโครงการนั้น
    • ระบุไว้อย่างชัดเจนว่า ในกรณีของโค้ดที่ใช้เครื่องมือสร้างโค้ดด้วย AI เป็นเรื่องยากที่จะพิสูจน์การปฏิบัติตามข้อ b/c ของ DCO
    • ดังนั้นจึงนำนโยบายไม่อนุญาตให้มีการส่งโค้ดเข้าโครงการ QEMU หากมีการใช้เครื่องมือสร้างโค้ดด้วย AI อย่างชัดเจน หรือมีเหตุอันควรสงสัยว่าใช้มาใช้

ความยืดหยุ่นของนโยบายและการจัดการข้อยกเว้น

  • ปัจจุบันยังอยู่ในช่วงเริ่มต้นของการพัฒนาซอฟต์แวร์แบบมี AI ช่วยเหลือ จึงมีโอกาสสูงที่ประเด็นทางกฎหมายจะได้รับการคลี่คลายในอนาคต
  • คาดว่าเมื่อเครื่องมือพัฒนามากขึ้น ในอนาคตบางเครื่องมืออาจสามารถใช้งานกับโครงการโอเพนซอร์สได้อย่างปลอดภัย
  • ขณะนี้จะใช้นโยบายที่เข้มงวดและปลอดภัยเป็นลำดับแรก และอาจผ่อนคลายในภายหลังหากจำเป็น
  • คำขอยกเว้นจะถูกพิจารณาเป็นรายกรณีเพื่อตัดสินว่าจะอนุญาตหรือไม่

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-06-26
ความคิดเห็นจาก Hacker News
  • โอเพนซอร์สและฟรีซอฟต์แวร์กำลังรู้สึกเปราะบางเป็นพิเศษ หากโค้ดที่สร้างด้วย AI ถูกมองว่าเป็นงานละเมิดลิขสิทธิ์ หรือถูกตัดสินว่าเป็นสาธารณสมบัติ หากต้องมีการแยกแยะระหว่างการแก้ไขโดย AI กับการแก้ไขโดยมนุษย์ โปรเจ็กต์ก็อาจติดหล่มปัญหากฎหมายไปอีกหลายปี และก็ไม่มีงบพอจะสู้คดีได้ หากโค้ดที่ AI สร้างขึ้นถูกมนุษย์นำไปแก้ไขต่อหรือผนวกรวมเข้ากับโค้ดเดิมในอนาคต ก็ยังมีประเด็นว่าการแก้ไขโดยมนุษย์ในภายหลังจะถูกมองว่าเป็นงานดัดแปลงที่อยู่นอกขอบเขต fair use หรือไม่ หากท้ายที่สุดโค้ดที่สร้างโดย AI ถูกตัดสินว่าเป็นสาธารณสมบัติ โปรเจ็กต์ที่มีเพียงบางส่วนของซอร์สโค้ดเท่านั้นที่อยู่ภายใต้ไลเซนส์โอเพนซอร์ส/ฟรีซอฟต์แวร์ ก็จะสูญเสียเครื่องมือสำคัญในการรับมือกับบริษัทที่ใช้งานไลเซนส์อย่างไม่เหมาะสมอย่างรวดเร็ว กลายเป็นภาระหนักที่ต้องพิสูจน์ให้ได้ด้วยว่าผู้ละเมิดไลเซนส์ใช้โค้ดที่มนุษย์เขียนซึ่งมีไลเซนส์กำกับอยู่จริง ในทางกลับกัน ซอฟต์แวร์ปิดกลับได้รับผลกระทบน้อยกว่าในสถานการณ์แบบนี้ เพราะถ้าจะอ้างว่าโค้ดที่ AI สร้างขึ้นเป็นการคัดลอกโดยไม่ได้รับอนุญาต สุดท้ายก็ต้องมีใครสักคนแกะไบนารีของตนมาเทียบกับโค้ดต้นฉบับ และในโค้ดซอฟต์แวร์ปิดเองก็มักมีโค้ดสาธารณสมบัติปะปนอยู่แล้ว
    • คิดว่าสถานการณ์นี้กลับให้ผลดีต่อไลเซนส์ MIT
    • ในมุมของนักพัฒนาที่มีประสบการณ์ เข้าใจได้มากว่าทำไมหลายคนไม่อยากให้ "นักพัฒนา" ที่ไม่มีความรู้ ส่งโค้ดจาก AI มา contribute แบบสุ่ม การให้มนุษย์ตรวจทีละบรรทัดสำหรับโค้ดจาก AI นั้น ต่อให้ไม่พูดถึงปัญหากฎหมายก็ยังเป็นงานที่กินกำลังคนไปอีกหลายปี อย่างแรก แทบไม่มีแนวโน้มว่าจะมีวิธีใช้งานได้จริงในการพิสูจน์ว่าโค้ดใดถูกสร้างด้วย AI อย่างที่สอง ซอฟต์แวร์ที่พัฒนาโดยมนุษย์ล้วน 100% ต่อจากนี้ย่อมแข่งขันสู้โปรเจ็กต์ที่มี AI ช่วยหรือ AI เขียนไม่ได้อยู่แล้ว ข้อยกเว้นเดียวคือต้องเกิดการล่มสลายระดับวันสิ้นโลกที่มนุษย์ไม่สามารถผลิตเซมิคอนดักเตอร์หรือไฟฟ้าในปริมาณมากได้อีก อย่างที่สาม ต่อให้โปรเจ็กต์ใดสามารถกัน contribution จากโค้ด AI ได้ทั้งหมดจริง ๆ (แม้จะยังไม่ชัดว่าทำได้อย่างไร และแม้จะเหลือเพียงคนส่วนน้อยที่ต่อต้าน AI มาช่วย contribute) สุดท้ายก็จะมีใครสักคนคัดลอกโค้ดนั้นไป ลบเฉพาะส่วนที่เสี่ยงทางกฎหมาย แล้วตั้งโปรเจ็กต์ใหม่ขึ้นมาแทน หากเป็นไลเซนส์ที่อนุญาตให้ fork ก็อาจถูก fork ตรง ๆ หรืออาจนิยมคัดลอกแล้วจัดระเบียบใหม่มากกว่า โอเพนซอร์สยังมีทางไปอีกไกล และซอฟต์แวร์แห่งอนาคตจะเพิ่มขึ้นแบบระเบิดในเชิงปริมาณ แม้ 99% อาจจะคุณภาพแย่ แต่ก็รู้สึกว่าจะมีซอฟต์แวร์ที่มีคุณค่าจริง ๆ เพิ่มขึ้นมากด้วย
    • แบ่งปันลิงก์เกี่ยวกับประเด็นลิขสิทธิ์ AI โดยอ้างถึง บทความล่าสุดจาก news.artnet.com เกี่ยวกับ AI art และจุดยืนของสำนักงานลิขสิทธิ์สหรัฐ และ วิกิคำตัดสินคดีลิงเซลฟี่ พร้อมบอกว่าการถกเถียงนี้ได้เดินมาถึงจุดที่ย้อนกลับไม่ได้แล้ว
    • หากซอฟต์แวร์ใดเป็นโอเพนซอร์สแบบเปิดกว้างจริง ๆ ในความหมายว่า "จะทำอะไรก็ได้กับโค้ดนี้ เราไม่สนใจ" ก็ไม่มีอะไรต้องกังวลจาก AI เลย
  • ให้ความรู้สึกว่าเป็นจุดยืนที่แข็งกร้าวกว่า policy ของ LLVM อย่างชัดเจน รายละเอียดดูได้ที่ นโยบายนักพัฒนา LLVM ฉันเป็นนักพัฒนาแก่ ๆ คนหนึ่ง และไม่ต้องการอย่างยิ่งที่จะ review โค้ดที่ทั้งผู้เขียนไม่เข้าใจและฉันเองก็ไม่เข้าใจ
    • มันน่าหงุดหงิดมากเมื่อผู้เขียนยังไม่เข้าใจโค้ดของตัวเอง แต่ฉันต้องมา review ให้ จริง ๆ แล้วเคยมีคนมาขอให้ฉันช่วยงานบางอย่างพร้อมถ่ายทอดคำอธิบายที่ AI ให้เขามา แล้วพูดว่า “เขาบอกว่าทำแบบนี้ได้” ซึ่งฉันคิดว่าพูดตรง ๆ ไปเลยว่า “ช่วยทำอันนี้ให้หน่อย” ยังจะดีกว่าเสียอีก มันถึงขั้นรู้สึกเหมือนโดนดูถูก
    • ฉันเริ่มเพิ่ม DCO (Developer Certificate of Origin) ให้กับทุกโปรเจ็กต์โอเพนซอร์สที่ดูแลอยู่ และตั้งใจจะใส่นโยบาย contribution ของโค้ดจาก LLM ต่อไปนี้ไว้ใน CONTRIBUTING.md

    LLM-Generated Contribution Policy
    ไลบรารี Color เป็นไลบรารีที่เต็มไปด้วยคณิตศาสตร์ซับซ้อนและการตัดสินใจที่ละเอียดอ่อน ทุก issue หรือ PR ต้องเขียนขึ้นบนพื้นฐานความเข้าใจอย่างลึกซึ้งของผู้ส่งเอง และโดยเฉพาะ PR นั้น นักพัฒนาต้องรับรอง DCO สำหรับแต่ละ commit หากใช้ความช่วยเหลือจาก LLM ในการทำ PR ต้องระบุให้ชัดใน commit message และใน PR หากตรวจพบการใช้ LLM โดยไม่มีหลักฐานยืนยัน PR จะถูกปฏิเสธ การส่งสิ่งที่ LLM สร้างขึ้นมาโดยไม่ผ่านการ review จะถูกปฏิเสธทันที

    ใน SECURITY.md ก็จะมี LLM-Generated Security Report Policy เช่นกัน โดยมีแผนจะไม่รับรายงานด้านความปลอดภัยที่ LLM สร้างขึ้นโดยเด็ดขาด

    ในฐานะคนที่รับผิดชอบโปรเจ็กต์คนเดียว ฉันพยายามหาสมดุล แต่โดยส่วนตัวแล้วไม่ชอบ contribution โค้ดจาก LLM
    • ฉันใช้ GitHub Copilot กับโปรเจ็กต์ส่วนตัว แต่จะไม่ใช้มันในทางอื่นนอกจากเป็น “autocomplete อัจฉริยะ” ถ้ามันเสนอสิ่งที่คล้ายกับโค้ดที่ฉันกำลังจะพิมพ์มากพอ ฉันถึงจะยอมรับ ด้วยวิธีนี้ฉันจึงเข้าใจโค้ดของตัวเอง 100% และหลีกเลี่ยงทั้งบั๊กจากความผิดพลาดและข้อถกเถียงเรื่องลิขสิทธิ์ได้ การใช้ Copilot แบบนี้ช่วยให้พัฒนาได้เร็วขึ้น ไม่ใช่เพราะฉันพิมพ์ช้า แต่เพราะมักวอกแวกหรือเบื่อ Copilot ช่วยให้ข้ามไปสู่ช่วงคิดหรือดีบักถัดไปได้เร็วขึ้น
      ฉันนึกแทบไม่ออกเลยว่าจะมีคนส่ง PR ทั้งที่ยังไม่เข้าใจโค้ดของตัวเองได้อย่างไร จึงแอบไม่พอใจนิดหน่อยที่เพราะคนแบบนั้น ฉันซึ่งใช้ LLM แค่ระดับ autocomplete กลับอาจโดนจำกัดไปด้วย
      ฉันอยากสั่ง Copilot ให้ทำงานรีแฟกเตอร์อัตโนมัติบ้าง แต่พอลองแล้วส่วนใหญ่มันพังเละ และมักสร้างบล็อกใหม่ทั้งก้อน ทำให้ช้ากว่าทำเองด้วยมือเสียอีก
      ที่น่าสนใจคือ ถ้าฉันกำลังพิมพ์บั๊กอยู่ Copilot ก็มักเติมบั๊กนั้นต่อให้เสร็จเลย มัน autocomplete แม้แต่ความผิดพลาดด้านบริบทที่ชัดเจน เช่น พิมพ์ชื่อตัวแปรผิด
    • เวลาจะใช้ LLM กับงานเขียนโค้ด จะเป็นคำสั่งประมาณว่า “แปลง YAML นี้เป็น struct แล้วดึงแพตเทิร์นที่ซ้ำออกมาเป็นตัวแปร” เรื่องแบบนี้ก็ทำด้วยเครื่องมือเชิงกำหนดได้ แต่ AI ทำได้สะอาดใน 30 วินาที และก็ทดสอบได้ง่ายด้วยว่าผลลัพธ์เหมือนอินพุตเดิม
      งานระดับ high-level ที่ฉันทำ ฉันไม่มีทางยกให้ AI เด็ดขาด แต่ถ้าเป็นงานซ้ำ ๆ และความสำคัญต่ำ AI ก็รับไปช่วยเพิ่มความเร็วได้ เช่น ถ้าให้ Claude Code รับไฟล์ CSV ผล benchmark ฐานข้อมูล แล้วเชื่อมกับกราฟหลายแบบและการวิเคราะห์ outlier มันก็ทำงานที่เชิงแนวคิดง่าย แต่เสียเวลามากกับการหาไลบรารีหรือเซ็ตอัป ให้เสร็จได้อย่างรวดเร็ว
    • เข้าใจดีมากกับความรู้สึกที่ว่า ถ้าผู้เขียนไม่เข้าใจโค้ดของตัวเองก็ไม่อยาก review แต่ถ้ามีมนุษย์ที่ชำนาญคอยกำกับอย่างถูกต้อง เครื่องมือ AI ก็สามารถสร้างโค้ดระดับสูงมากได้ และในช่วงไม่กี่เดือนมานี้มันก็เก่งขึ้นเรื่อย ๆ ถึงขั้นสร้างผลลัพธ์จากคำสั่งภาษาธรรมชาติได้บ่อยแล้ว
      ฉันกำลังคิดอยู่เหมือนกันว่า “ความเข้าใจ” โค้ดหมายถึงอะไร โปรเจ็กต์หนึ่งที่ฉันทำคือใส่ storage backend ใหม่ทั้งหมดให้กับระบบ orchestration ของ VM เดิม ในฐานะคนที่ไม่รู้โค้ดเดิม ฉันก็หาเวลามานั่ง implement เองยาก แต่กำลังสร้าง test cluster และรันหลากหลายสถานการณ์ จนเข้าใจภาพรวมดีพอทั้งในมุมการออกแบบและการทดสอบ
      ฉันเองก็เป็นผู้ดูแลโอเพนซอร์ส จึงนึกภาพออกว่าการมี PR แบบ LLM “slop” คุณภาพต่ำไหลเข้ามามันเครียดแค่ไหน สุดท้ายไม่ว่าผู้เขียนจะเข้าใจโค้ดหรือไม่ ผู้ดูแลก็ต้อง review อยู่ดี
      ต่อไปคงต้องหาวิธีใช้เครื่องมือเหล่านี้อย่างเหมาะสม และส่งสัญญาณให้คนอื่นเห็นถึงระดับคุณภาพของโค้ดที่ส่งมา บทเรียนจากบั๊กละเอียดอ่อนที่พบในพอร์ต ZFS บน Linux ยุคแรกคือ การทดสอบอย่างเข้มงวดสำคัญมากพอ ๆ กับการที่มนุษย์ review และเขียนทีละบรรทัด
  • สิ่งที่ฉันเคยคาดการณ์ไว้ในบล็อก “yes i will judge you for using AI” กำลังเกิดขึ้นจริง โอเพนซอร์สแต่เดิมพึ่งพาสัญญาณแฝงเรื่องความสามารถของผู้ร่วมพัฒนา (competency markers) อย่างมาก แต่ LLM ทำให้คนที่ไม่มีประสบการณ์เลยก็ปล่อยโค้ดที่ดูเหมือนคนเก่งได้ สำหรับคนมีประสบการณ์ นี่เป็นความสับสนที่หนักมาก ต่อจากนี้ social proof ที่ไม่เกี่ยวกับ PR โดยตรง เช่น การประชุมออนไลน์หรือพบเจอตัวจริง น่าจะยิ่งจำเป็นมากขึ้นสำหรับการเข้าสู่โปรเจ็กต์ใหญ่
    • ในบริษัทก็เจอเหมือนกัน เพื่อนร่วมงานใช้ LLM สร้างคอมเมนต์ review โค้ด ซึ่งทำให้ดูเหมือนระดับสูงมากจนฉันเผลอเชื่อไปพักหนึ่ง สุดท้ายต้องเสียเวลามหาศาลในการตรวจว่าคอมเมนต์นั้นถูกหรือไม่ และพลังงานที่ฉันใช้จริง ๆ ก็มากกว่าความพยายามที่คนคัดลอกวางลงไปเสียอีก
    • ขอให้แชร์ลิงก์บล็อก
  • เป็น policy ที่ลงนามโดยคนฝั่ง RedHat เป็นหลัก RedHat จริงจังและมีแนวคิดแบบองค์กรสูงมาก ความกังวลของ RedHat น่าจะไม่ใช่แค่ว่า “ใครมีลิขสิทธิ์ในสิ่งที่ AI สร้าง” แต่เป็นกรณีที่ซอร์สจากโปรเจ็กต์อื่นที่ AI ดึงมาในขั้นตอนฝึก โผล่ออกมาแบบไม่ตั้งใจ ไฮเปอร์ไวเซอร์ส่วนใหญ่เป็นซอร์สปิด และมีบริษัทที่ชอบฟ้องร้องอยู่มาก
    • ถ้าความเสี่ยงคือ AI อาจคาย “โค้ดจากโปรเจ็กต์อื่น” ออกมาตรง ๆ ฉันคิดว่านั่นแทบเป็นปัญหาที่ใช้ได้กับโค้ดเกือบทั้งหมดที่ AI สร้างขึ้น
    • โมเดลภาษามักมีความเสี่ยงสูงที่จะสร้างข้อผิดพลาดทางตรรกะแบบละเอียดอ่อนได้ง่ายกว่าเดิม และอาจล้ำเข้าไปถึงขอบเขตความปลอดภัยของไฮเปอร์ไวเซอร์ด้วย ผู้ใช้ที่พึ่ง AI ช่วยมาก ๆ มักไม่พร้อมจะจับความผิดพลาดลักษณะนี้ จึงยิ่งอันตราย
  • สังเกตว่าคนจาก RedHat ที่ถูก IBM ซื้อไปแล้วเป็นผู้ลงนามใน policy นี้เป็นหลัก IBM เป็นบริษัทที่สร้าง Watson และเคยชนะเกม Jeopardy! ในปี 2011 จึงอดสงสัยไม่ได้ว่ากระแสพูดเรื่องการพัฒนาซอฟต์แวร์ด้วย AI ที่ว่า “เพิ่งเริ่มต้นเท่านั้น” เป็นเรื่องจริง หรือเป็นอีกฉากหนึ่งของการเข้าซื้อแล้วทำลายแบบ IBM กันแน่
    ในทางกลับกัน Dotnet Runtime กำลังรับ AI อย่างจริงจัง แม้คนนอกอาจหัวเราะ แต่ก็ควรสังเกตว่ามีวิศวกรชั้นยอดอย่าง Stephen Toub และ David Fowler สนับสนุนอยู่
    สำหรับองค์กรต่าง ๆ อยากแนะนำว่า เมื่อ IBM มาเสนอขายบริการ AI ครั้งหน้า ให้มองหาพาร์ตเนอร์ที่มีวิสัยทัศน์อนาคตกว่านี้จริง ๆ
    ในฐานะคนจาก North Carolina ก็หวังว่า IBM และ RedHat จะหาทิศทางที่ถูกต้องเจอ
  • สงสัยว่ามันมีแรงจูงใจทางกฎหมายจริงหรือไม่ บางโปรเจ็กต์ดูเหมือนแค่เหนื่อยกับการ review โค้ดขยะจาก AI มากกว่า
    • QEMU เป็นซอฟต์แวร์ที่สำคัญอย่างยิ่งในอุตสาหกรรม ใช้ใน VM เดสก์ท็อป คลาวด์ build server sandbox ด้านความปลอดภัย สภาพแวดล้อมข้ามแพลตฟอร์ม และอีกสารพัด ความเสี่ยงทางกฎหมายเพียงเล็กน้อยก็อาจส่งผลรุนแรงต่อทั้งอุตสาหกรรมได้
    • policy นี้ชัดเจนและจำกัดขอบเขต ดูเหมือนจะเน้นว่าทำให้ความเป็นเจ้าของลิขสิทธิ์ของโค้ดที่สร้างเชิงอัลกอริทึมปลอดภัยไม่ได้ จึงตั้งใจใช้คำว่า “เชิงอัลกอริทึม” ด้วย policy ปัจจุบันก็ดูมีเจตนาแบบนั้น และการเริ่มต้นด้วยประโยคประมาณว่า “เราเริ่มแบบเข้มงวดและปลอดภัยที่สุดในวันนี้ แล้วค่อยผ่อนคลายภายหลัง” ก็ดูสมเหตุสมผลตั้งแต่ต้น มันอาจเป็นการปฏิเสธ “slop จำนวนมาก” ด้วยก็จริง แต่ยุทธศาสตร์หลักคือจัดการความเสี่ยงทางกฎหมายและความเป็นเจ้าของก่อน รู้สึกว่าดีกว่า policy ของ curl มาก
    • เตือนให้ระวังโดยยกตัวอย่างกรณีที่ Monsanto บังคับใช้สิทธิในเมล็ดพันธุ์อย่างเอาเป็นเอาตาย
    • พูดตรง ๆ ว่ายังไม่แน่ใจว่า AI จะเปลี่ยนคุณภาพของโค้ดระดับกลางอย่างไร แต่ความจริงมนุษย์เองก็ปล่อยโค้ดไร้ประโยชน์ออกมาบ่อย หาก commit มีมากเกินไปและจัดการยาก ก็คงต้องคิดว่าควรมีทีม triage เฉพาะโปรเจ็กต์หรือไม่ เชื่อว่าส่วนใหญ่แล้ว contribution ต่าง ๆ มาจากเจตนาดี
      เข้าใจคนที่หลีกเลี่ยง AI เพราะความเสี่ยงทางกฎหมาย แต่ก็สงสัยเหมือนกันว่าบางคนกังวลเกินไปหรือเปล่า คนที่คิดว่าตัวเองทำให้ความเป็นไปได้บางอย่างเป็นศูนย์ได้จริง ๆ คงยังคิดไม่รอบพอ
    • ถ้าแนวโน้มนี้เดินต่อไป โอเพนซอร์สอาจพังได้ การคัดลอกวางโค้ดทำได้ง่ายเกินไป และการตรวจรวมถึงการปฏิเสธก็กินเวลามากเกินไป ต่อไปน่าจะมีโปรเจ็กต์มากขึ้นที่กลายเป็นโมเดลแบบ Android คือใคร ๆ ก็โหลดซอร์สได้ แต่คนนอกแทบไม่มีทาง contribute จริง ๆ
  • หวังว่าควรแยกให้ได้ระหว่างการใช้ LLM ใน IDE แบบเครื่องมือ autocomplete อัจฉริยะ กับการให้คำสั่งระดับสูงแล้วปล่อยให้มันสร้างโค้ดจำนวนมากทั้งก้อน ยอมรับว่ามันมีพื้นที่สีเทา แต่ก็อยากให้ใช้ระดับ autocomplete อย่าง Copilot ได้โดยไม่มีความเสี่ยงเรื่องลิขสิทธิ์ เช่น เวลาเขียนชุด case statement แล้ว Copilot จับแพตเทิร์นและช่วยลดการพิมพ์ไปได้มาก
    • ไปไกลกว่านั้นก็ฝันถึงอนาคตที่ AI เป็นเหมือนแว่นตา AI ซึ่งเป็นส่วนหนึ่งของความคิดและร่างกายของฉัน เหมือนแว่นสายตาทั่วไปที่ช่วยเรื่องการมองเห็น แว่นอัจฉริยะก็อาจช่วยเสริมการคิดได้
      สมองของฉันเองก็เรียนรู้จากโค้ดซอร์สปิดมาเยอะเหมือนกัน จึงแขวะว่าการถกเถียงเรื่องลิขสิทธิ์ AI เป็นแนวคิด NIMBY แบบตะวันตก หากยังเอาแต่ปฏิเสธเทคโนโลยีเจ๋ง ๆ ด้วยข้ออ้างทางกฎหมายแบบ “ถ้าเกิดว่า” อารยธรรมตะวันตกอาจเสื่อมถอยเองได้
  • เข้าใจว่าทำไมนโยบายแบบนี้ถึงเกิดขึ้น แต่คิดว่าเป็นความผิดพลาด เรื่องกฎหมายเกี่ยวกับ AI กับลิขสิทธิ์ยังไม่ชัด และแทบไม่มีการออกกฎหมายโดยตรง
    นอกเหนือจากการห้าม contribution จาก AI แล้ว กลับคิดว่าควรมีการกำหนดพื้นที่ชัดเจนด้วยว่า “ส่วนนี้ใช้ AI ได้” เช่น การเซ็ตอัป CI ของ QEMU ไม่ใช่พื้นที่แกนหลักด้านความปลอดภัย การ contribute สำหรับ test case หรือ environment ใหม่ ๆ ที่น่าสนใจ อาจเปิดให้ใช้ AI ได้ภายใต้เงื่อนไขบางอย่างก็ยังได้
    • คิดว่าถ้าไม่ใช้นโยบายนี้จะมีความเสี่ยงอะไรบ้าง บางทีโค้ดอาจช้าลงนิดหน่อยแต่ดีขึ้น และสำหรับโปรเจ็กต์สำคัญอย่าง QEMU ต่อให้ต้องแลกกับความเร็วก็ยังคุ้ม ผู้เขียน policy ดูไม่ได้ต่อต้าน GenAI เสียทีเดียว แต่เห็นว่าสิ่งนี้ถ้าเดินหน้าแล้วจะย้อนกลับไม่ได้ จึงเลือกแนวทางระมัดระวัง
    • วิธีแก้ที่ง่ายที่สุดก็คือ “รอจนกว่าสถานะทางกฎหมายจะชัดเจน” QEMU มีโค้ดแทบทั้งหมดอยู่ภายใต้ GPL 2.0 ถ้านำโค้ด GenAI เข้ามาผิดพลาด แล้วภายหลังมีคำพิพากษาว่า “ต้องปฏิบัติตามไลเซนส์ของโค้ดต้นทางเดิม” ก็จะสร้างภาระทั้งการ rollback โค้ดที่เกี่ยวข้องและผลกระทบต่อ downstream ทั้งหมด ต่อให้ติดป้ายว่า “ส่วนนี้ AI ห้ามนำกลับใช้” ก็ยังเหลือปัญหาว่าท้ายที่สุดอาจต้องเขียนใหม่ทั้งหมดอยู่ดี
      ดังนั้น “ตอนนี้ยังไม่รับไปก่อน” จึงเป็นตัวเลือกที่ซับซ้อนน้อยกว่าและดราม่าน้อยกว่าสำหรับทุกฝ่าย
      แนบลิงก์อ้างอิง ไลเซนส์ QEMU และ รายการไลเซนส์ที่ไม่เสรี
    • ปัญหานี้คงไม่ใช่ข้อถกเถียงทางกฎหมายที่ลากยาวหลายสิบปี เพราะตอนนี้มีคดีที่เกี่ยวข้องหลายสิบคดีขึ้นศาลแล้ว และน่าจะมีบรรทัดฐานออกมาในอีกไม่กี่ปี QEMU เติบโตมาอย่างยอดเยี่ยมตลอด 22 ปีโดยไม่ต้องพึ่ง AI ดังนั้นรออีกไม่กี่ปีก็ไม่ได้แย่อะไรเลย
    • แนะนำให้อ่านทั้งถ้อยคำและเจตนาแฝงของ policy นี้ให้ดี ทุกการกระทำย่อมมีความเสี่ยงทางกฎหมาย แต่บริษัทระดับโลกจำนวนมากก็ยังยอมรับมัน QEMU ไม่ได้แปลกประหลาดอะไร แค่อ่านได้ว่าพวกเขาไม่อยากใช้โค้ดจาก LLM จริง ๆ และใช้เหตุผลแบบ “ไปถามทนายมาแล้ว → มีความเสี่ยงทางกฎหมาย → ใช้ไม่ได้” เป็นข้ออ้างเพื่อปิดการถกเถียง รูปแบบนี้เกิดขึ้นในบริษัทเหมือนกันเป๊ะ
    • วงการคอมพิวเตอร์มีธรรมเนียมเก่าแก่เรื่อง “ไม่ลอกโค้ด” ต่อให้เป็นโค้ดสั้นมาก หรือแม้จะเข้าข่าย ‘fair use’ ทางกฎหมาย ก็ยังมีวัฒนธรรมไม่คัดลอกโค้ดต้นฉบับกันอยู่
  • เหตุผลที่ว่า “เริ่มเข้มงวดและปลอดภัยก่อน แล้วค่อยผ่อนคลาย” ฟังดูสมเหตุสมผลมาก
    แต่ก็สงสัยเหมือนกันว่ามีวิธีไหนที่จะแยกโค้ดที่ AI สร้างออกจากโค้ดที่มนุษย์ไปคัดลอกจากที่อื่นมาได้จริง ๆ หรือไม่ โอเพนซอร์สเปิดให้ใครก็ได้ contribute อยู่แล้ว และมนุษย์เองก็ได้รับอิทธิพลจากซอร์สอื่นในโค้ดที่เขียนเหมือนกัน
    ในมุมมองตอนนี้ ฉันคิดว่าโค้ดที่ AI สร้างขึ้นยังไม่ใช่สิ่งที่มีอัตลักษณ์อิสระในตัวเอง แต่ใกล้เคียงกับเครื่องมือในมือมนุษย์มากกว่า
    • เปรียบว่า “โค้ดที่ AI สร้างก็เหมือนเลื่อยไฟฟ้ากำลังสูงในมือมนุษย์” เป็นเครื่องมือทรงพลัง และอาจอันตรายมากขึ้นเป็นอันดับรองจากมนุษย์เอง
      รู้สึกว่าคงไม่จำเป็นต้องลากอุปมานี้ให้ยาวกว่านี้แล้ว
  • policy แบบนี้ดูเหมือนบังคับใช้จริงแทบไม่ได้เลย เพราะ Zed, Cursor, VS Code และ editor อื่น ๆ ต่างก็มี autocomplete ที่ขับเคลื่อนด้วย AI และเป็นไปไม่ได้เลยที่จะแยกโค้ดที่ฉันพิมพ์เองออกจากโค้ดที่มาจาก hint ของ AI
    มันเหมือนกับฉันวาดรูปคนก้างปลาง่าย ๆ แล้วมีคนบอกว่า “รูปนี้อาจลอกมาจากรูปคนก้างปลาของคนอื่น คุณเลยไม่มีสิทธิ์ส่งมัน”
    จุดประสงค์จริงของ policy นี้ สุดท้ายแล้วน่าจะเป็นการปูทางไว้มากกว่าว่า ถ้าวันหนึ่งมีใครส่งของที่ปนโค้ด AI มา ก็จะได้พูดว่า “เราห้ามไม่ได้จริง ๆ” คนร่าง policy เองก็คงไม่ใช่ว่าไม่รู้ว่ามันไม่มีความหมายเชิงปฏิบัติ
    • policy แบบนี้มีลักษณะของการสร้างเกราะป้องกันความรับผิดไว้ล่วงหน้าว่า “ถ้ามีโค้ดน่าสงสัยตาม policy หลุดเข้ามา เราก็ทำอะไรไม่ได้” และใน commit message หรือ patch ก็ยังมีท่าทีแบบ “ปัญหาไลเซนส์ของเครื่องมือสร้างโค้ดยังไม่ถูกวางหลักทางกฎหมาย” อยู่ด้วย
      นอกจากประเด็นกฎหมายแล้ว เวลาใช้โค้ด AI ก็ยังมีปัญหาอื่น ๆ อีกหลายอย่างอย่างชัดเจน
    • Neovim ไม่ได้บังคับใช้ AI ต้องตั้งค่าเองถึงจะทำงาน ถ้า editor ไหนทำให้ปิด AI ไม่ได้ ก็ควรถือว่า editor นั้นมีปัญหาร้ายแรงในตัวมันเอง