GCC ประกาศนโยบาย AI: ปฏิเสธโค้ดจาก LLM ที่เกิน ~15 บรรทัด ยกเว้น test case และบังคับแท็ก Assisted-by

หนึ่งในโครงการโอเพนซอร์สที่เก่าแก่และสำคัญที่สุดในโลกเพิ่งวางกฎเรื่อง AI อย่างเป็นทางการ — และกฎนั้นเข้มกว่าที่หลายคนคาด

29 กรกฎาคม 2026 David Edelsohn ส่งอีเมลหัวข้อ “GCC AI Policy Announcement” เข้าเมลลิงลิสต์ gcc@gcc.gnu.org แจ้งว่า GCC Steering Committee รับรองนโยบายที่ GCC AI Policy Working Group เสนอ ตอนนี้ตัวนโยบายถูก commit ขึ้นเว็บไซต์ GCC แล้วที่ gcc.gnu.org/ai-policy.html (ระบุ Last modified 2026-07-29, เผยแพร่ภายใต้ CC0 1.0)

ใจความสั้นที่สุด: GCC จะปฏิเสธ contribution ที่มีนัยสำคัญทางกฎหมายซึ่งมีเนื้อหาที่ LLM สร้าง หรือได้มาจากเนื้อหาที่ LLM สร้าง

เส้นแบ่งอยู่ที่ราว 15 บรรทัด

นโยบายไม่ได้ใช้คำว่า “โค้ดที่ AI เขียน” ลอย ๆ แต่ผูกกับนิยามที่ GNU Project ใช้มานานอยู่แล้วคือ “legally significant” ซึ่งใน GNU maintainer guidelines กำหนดไว้ว่าคือการมีส่วนร่วม “มากกว่าราว 15 บรรทัดของโค้ดและ/หรือข้อความ” ที่มีนัยสำคัญเชิงลิขสิทธิ์ — ต่ำกว่านั้นถือว่าไม่ significant สำหรับลิขสิทธิ์

นี่เป็นการเลือกที่ฉลาดกว่าที่เห็น เพราะแทนที่จะประดิษฐ์เกณฑ์ใหม่ที่ต้องมาเถียงกันว่าอะไรคือ “AI-generated พอที่จะนับ” GCC หยิบเส้นแบ่งเชิงลิขสิทธิ์ที่โครงการใช้ตัดสินเรื่อง copyright assignment มาสิบกว่าปีมาใช้ซ้ำ คำถามจึงกลายเป็นคำถามเดิมที่ maintainer ตอบเป็นอยู่แล้ว

ข้อควรรู้ที่ GNU ระบุไว้ด้วย: การเปลี่ยนแปลงซ้ำ ๆ เป็นชุด เช่นการเปลี่ยนชื่อสัญลักษณ์ในหลายที่ ไม่ถือว่า significant แม้จะแตะหลายไฟล์ แต่ในทางกลับกัน การแก้เล็ก ๆ หลายครั้งโดยคนเดียวกัน สะสมรวมกันได้ จนกลายเป็นส่วนที่มีนัยสำคัญ

สามข้อยกเว้น และสองข้อบังคับ

นโยบายไม่ได้เป็นการแบนแบบเหมารวม โครงสร้างจริงมีรายละเอียดที่นักพัฒนาควรอ่านให้ครบ:

สิ่งที่ยังทำได้:

• ส่วนที่ไม่ legally significant — maintainer มีอิสระที่จะรับ contribution ที่ LLM สร้างได้ ถ้าผ่านเงื่อนไขปกติของ contribution ทุกชิ้น และถูกติดป้ายไว้อย่างชัดเจน
• Test case — ข้อยกเว้นที่ชัดที่สุด maintainer มีอิสระที่จะรับ contribution ที่เป็น test case แม้จะ legally significant และแม้จะถูกสร้างโดย LLM ทั้งหมดหรือบางส่วน
• โค้ดที่นำเข้าจากโครงการอื่น — นโยบายไม่ครอบคลุมโค้ดที่ไม่ได้เป็นของ GCC โดยหลัก แต่ถูก import เข้ามาเพื่อความสะดวกหรือเป็น prerequisite (นโยบายยกตัวอย่าง libsanitizer)

สิ่งที่นโยบายไม่แตะเลย คือการใช้ AI ของนักพัฒนาในงานอื่น — research, การวิเคราะห์, การค้นหาและรายงานบั๊ก, การรีวิว patch และการดีบัก ทั้งหมดนี้ทำได้ ตราบใดที่ผลลัพธ์ไม่ถูกใส่เข้าไปใน contribution (มีวงเล็บกำกับว่า output ไม่ควรถูกส่งต่อแบบ verbatim โดยไม่พิจารณา และการรีวิวด้วย AI คือ “การสนับสนุนการรีวิวของมนุษย์ ไม่ใช่แทนที่”) เช่นเดียวกับ การใช้ส่วนตัว — screen reader, text-to-speech, การแปล, การช่วยสะกดคำและไวยากรณ์ — อยู่นอกขอบเขตนโยบาย ถ้าผู้ใช้ตรวจสอบผลลัพธ์เอง

สิ่งที่ถูกบังคับเพิ่ม อยู่ในหัวข้อ Transparency & Accountability และเป็นส่วนที่ผมคิดว่าสำคัญที่สุด:

1. commit message ของ contribution ที่มีเนื้อหาจาก LLM ต้องมีแท็ก Assisted-by:
2. contribution ทุกชิ้นต้องถูกส่งโดย มนุษย์ที่เข้าใจการเปลี่ยนแปลงและพร้อมตอบคำถามเกี่ยวกับมัน การตัดสินใจรับเข้าโครงการก็ต้องทำโดยมนุษย์ มีแต่มนุษย์เท่านั้นที่ให้แท็ก Signed-off-by: เพื่อรับรอง Developer Certificate of Origin ได้ และ LLM ห้าม commit โค้ดเข้า repository ของโครงการ

นโยบายเปิดด้วยหัวข้อ “Community First” ที่ขอให้ปฏิบัติต่อผู้ contribute ทุกคนด้วยความเคารพ ยอมรับตรง ๆ ว่า “มีความเห็นที่แตกต่างและยึดถืออย่างหนักแน่นเกี่ยวกับ LLM” และให้สันนิษฐานว่าทุกคน contribute ด้วยเจตนาดี — คนที่ยังไม่ได้ทำตามนโยบายควรได้รับการแนะนำ ไม่ใช่ถูกไล่

Steering Committee ระบุว่านโยบายนี้คาดว่าจะเปลี่ยนไปตามชุมชนหรือเมื่อจุดยืนของ GNU Project โดยรวมถูกปรับ และ อย่างช้าที่สุดจะถูกทบทวนช่วงต้นปี 2027 พร้อมขอบคุณ Jonathan Wakely ที่นำ working group และสมาชิกอีกเจ็ดคน (Carlos O’Donell, Sudakshina Das, Jason Merrill, Joel Sherrill, Sam James, Robin Dapp, Arthur Cohen)

ทำไมคอมไพเลอร์ถึงต้องเข้มกว่าโครงการอื่น

การอ่านนโยบายนี้เป็น “GCC ต่อต้าน AI” คือการอ่านผิด เหตุผลที่แท้จริงเขียนอยู่ในคำที่ใช้ — คำว่า legally significant ไม่ใช่คำเชิงคุณภาพโค้ด แต่เป็นคำเชิงลิขสิทธิ์

GCC อยู่ภายใต้ GNU Project ที่มีระบบ copyright assignment เป็นรากฐาน และพลังทางกฎหมายของ GPL มาจากการที่สายการถือสิทธิ์ของทุกบรรทัดต้องสาวกลับไปหาคนที่มีสิทธิ์มอบมันได้จริง เมื่อโค้ดมาจาก LLM ที่ฝึกบนคลังโค้ดที่มีสัญญาอนุญาตปะปนกัน คำถามว่า “ใครเป็นเจ้าของบรรทัดนี้ และเขามีสิทธิ์ยกให้ไหม” ยังไม่มีคำตอบที่ศาลไหนรับรอง — สำหรับโครงการที่ทั้งระบบวางอยู่บนคำตอบนั้น การรอไว้ก่อนคือท่าที่สมเหตุสมผล ไม่ใช่ความกลัวเทคโนโลยี

นี่อธิบายด้วยว่าทำไม test case จึงเป็นข้อยกเว้น — test case คือโค้ดที่มีคุณค่าจากการที่มันจับบั๊กได้ ไม่ใช่จากความคิดสร้างสรรค์ในตัวมัน และเป็นงานที่ LLM ทำได้ดีเป็นพิเศษ ขณะที่ความเสี่ยงเชิงลิขสิทธิ์ต่ำที่สุด GCC จึงเปิดประตูตรงที่ประโยชน์สูงและความเสี่ยงต่ำ แล้วปิดตรงที่กลับกัน

มุมมอง AI Curator

ผมคิดว่าส่วนที่จะส่งผลจริงในระยะยาวไม่ใช่ข้อห้าม แต่คือ แท็ก Assisted-by:

ข้อห้ามเรื่อง 15 บรรทัดนั้นบังคับใช้ยากมาก และในคอมเมนต์ใต้ข่าวที่ LWN ก็มีการเถียงกันเรื่องนี้อย่างหนัก — ในทางปฏิบัติไม่มีใครพิสูจน์ได้ว่า patch หนึ่งเกิดจาก LLM หรือจากนิ้วมนุษย์ มันจึงทำงานแบบเดียวกับกฎ DCO คือเป็นระบบเกียรติยศที่มีผลทางกฎหมายเมื่อมีคนโกหก ไม่ใช่ระบบตรวจจับ แต่ Assisted-by: ต่างออกไป เพราะมันสร้าง เมทาดาทาที่ค้นย้อนหลังได้ในประวัติ git ถ้าอีกสามปีมีคำพิพากษาที่เปลี่ยนสถานะลิขสิทธิ์ของโค้ดที่โมเดลสร้าง โครงการที่มีแท็กนี้จะ git log --grep หาสิ่งที่ต้องทบทวนได้ในนาทีเดียว ส่วนโครงการที่ไม่มีจะต้องเดาทั้ง repo นี่คือการซื้อประกันด้วยราคาถูกที่สุดเท่าที่จะทำได้ และเป็นสิ่งที่ทีมในไทยควรลอกไปใช้ทันทีไม่ว่าจะมีจุดยืนเรื่อง AI แบบไหน — มันไม่ได้ห้ามใครทำอะไรเลย แค่บันทึกไว้

จุดที่สองที่ผมคิดว่าถูกมองข้าม คือประโยคที่ว่า contribution ต้องส่งโดย “มนุษย์ที่เข้าใจการเปลี่ยนแปลงและพร้อมตอบคำถามเกี่ยวกับมัน” นี่คือคำตอบที่ตรงที่สุดต่อปัญหาที่ maintainer โอเพนซอร์สบ่นกันมาตลอดปี — ไม่ใช่ว่าโค้ดจาก AI แย่ แต่คือ ต้นทุนการรีวิวถูกโยนข้ามฝั่ง คนส่ง PR ใช้เวลาสามสิบวินาที ส่วน maintainer ที่เป็นอาสาสมัครต้องใช้เวลาหนึ่งชั่วโมงอ่าน แล้วพบว่าคนส่งตอบคำถามเกี่ยวกับโค้ดของตัวเองไม่ได้ ประโยคนี้ไม่ได้ห้าม AI มันเรียกเก็บต้นทุนคืนจากคนส่ง

สำหรับนักพัฒนาไทย ผลกระทบเชิงปฏิบัติมีสองชั้น ชั้นแรกตรงไปตรงมา: ถ้าคุณส่ง patch เข้า GCC — ซึ่งมีคนไทยทำอยู่จริงในสาย toolchain, embedded และ RISC-V — กฎนี้มีผลกับคุณแล้ววันนี้ และทางที่ปลอดภัยที่สุดคือใช้ LLM หา bug และเขียน test case ไม่ใช่เขียน patch ชั้นที่สองกว้างกว่า: GCC ไม่ใช่โครงการสุดท้ายที่จะออกกฎแบบนี้ และเมื่อโครงการระดับโครงสร้างพื้นฐานเริ่มถามว่า “โค้ดนี้มาจากไหน” คำถามเดียวกันจะไหลลงมาถึงสัญญาจ้างพัฒนาซอฟต์แวร์ในไทย บริษัทที่วันนี้ยังไม่มีคำตอบว่าโค้ดที่ทีมส่งมอบมีสัดส่วนจาก AI เท่าไร จะเป็นบริษัทที่ตอบข้อกำหนดใน RFP ปีหน้าไม่ได้

และผมอยากชี้จุดที่นโยบายนี้ทำได้ดีกว่าการถกเถียงส่วนใหญ่ในหัวข้อเดียวกัน: มันแยก คำถามเชิงลิขสิทธิ์ ออกจาก คำถามเชิงคุณภาพ อย่างสะอาด GCC ไม่ได้บอกว่าโค้ดจาก LLM ห่วย มันบอกว่าโครงการยังรับความเสี่ยงเรื่องที่มาของสิทธิ์ไม่ได้ — แล้วเปิดข้อยกเว้นตรงที่ความเสี่ยงนั้นต่ำ ใครที่กำลังร่างนโยบาย AI ให้ทีมตัวเองอยู่ ควรอ่านหน้านี้ก่อนเริ่มเขียน มันสั้นมาก และมันคิดมาแล้ว

แหล่งข่าว

• GNU Compiler Collection — AI Policy (ตัวนโยบายฉบับเต็ม)
• GCC AI Policy Announcement — David Edelsohn, gcc mailing list, 29 ก.ค. 2026
• GNU maintainer guidelines — นิยาม “Legally Significant”
• LWN.net — GCC steering committee announces AI policy