Debian เปิดโหวตว่าจะรับโค้ดที่ AI ช่วยเขียนหรือไม่ — 4 ข้อเสนอ ตั้งแต่ห้ามเด็ดขาดถึงอนุญาตแบบมีเงื่อนไข
หนึ่งในดิสโทรที่เก่าแก่และเป็นฐานของแทบทุกอย่างในโลกลินุกซ์ กำลังจะตัดสินใจเรื่องที่โครงการโอเพนซอร์สอื่นเลี่ยงมาตลอด — Debian เปิดช่วงอภิปราย General Resolution เมื่อวันที่ 24 กรกฎาคม 2026 ว่าโครงการควรอนุญาตให้ contribution ที่สร้างหรือช่วยสร้างด้วย LLM เข้ามาในแพ็กเกจ เอกสาร และเว็บของ Debian หรือไม่
ที่ต้องจับตาคือมันไม่ใช่คำถามใช่/ไม่ใช่ แต่มี ข้อเสนอ 4 ฉบับแข่งกัน ที่วางจุดยืนไล่ตั้งแต่ห้ามเด็ดขาดไปจนถึงอนุญาตแบบมีกรอบ และผลของมันจะกลายเป็นแม่แบบให้โครงการโอเพนซอร์สอื่นอ้างอิงต่อ
สี่ข้อเสนอบนโต๊ะ
A — ห้าม (Matthias Geiger) ไม่อนุญาตให้ contribution ที่เขียนโดยใช้หรือได้รับความช่วยเหลือจาก LLM หรือเครื่องมือ generative AI เข้าสู่ Debian โดยตรง เหตุผลที่ยกมาครอบคลุมทั้งความเสถียร ความคลุมเครือด้านลิขสิทธิ์ คุณภาพงานที่ต่ำ ภาระที่ตกกับอาสาสมัครที่ต้องมารีวิว และประเด็นเชิงจริยธรรมต่อบริษัท AI
B — อนุญาตแบบมีเงื่อนไข (Lucas Nussbaum) รับได้ แต่ต้องมีเงื่อนไข: เปิดเผยการใช้เครื่องมือ ตรวจความเข้ากันได้ทางกฎหมาย ผู้ส่งงานต้องรับผิดชอบผลงานตัวเอง และห้ามป้อนข้อมูลอ่อนไหวของโครงการเข้าเครื่องมือ AI ถ้อยคำสำคัญคือ “เมื่อส่วนสำคัญของ contribution ถูกสร้างหรือได้รับความช่วยเหลืออย่างมีนัยสำคัญจากเครื่องมือ ผู้ contribute ควรเปิดเผยการใช้เครื่องมือนั้นให้ผู้รับเห็นอย่างชัดเจน”
C — ไม่สนับสนุน แต่ยอมรับว่าห้ามจริงไม่ได้ (Ian Jackson) ขอให้ผู้ contribute หลีกเลี่ยง LLM และแสดงจุดยืนไม่สนับสนุน โดยยอมรับตามจริงว่าการแบนเบ็ดเสร็จบังคับใช้ไม่ได้ ข้อนี้เข้มที่สุดในเรื่องหนึ่ง — ห้ามใช้ AI ช่วยเขียนข้อความที่มนุษย์สื่อสารกับมนุษย์ ทั้ง bug report อีเมล และบล็อกโพสต์ พร้อมบังคับเปิดเผยทุกกรณีที่ใช้
D — รับได้ ความรับผิดชอบอยู่ที่ผู้ส่ง (Pierre-Elliott Bécue) ยอมรับงานที่ AI ช่วยสำหรับงานเฉพาะของ Debian โดยผลักภาระไปที่ผู้ส่ง: ต้องเข้าใจงานที่ตัวเองส่ง ต้องสอดคล้องกับ DFSG ต้องเปิดเผยการใช้ AI “ในที่ที่เหมาะสม (commit message, changelog, …)” และเลี่ยง AI บนคลาวด์เมื่อทำงานกับข้อมูลอ่อนไหว
จุดร่วมที่น่าสนใจกว่าจุดต่าง
อ่านทั้งสี่ข้อจบแล้วจะเห็นว่าข้อเสนอที่ไม่ได้ห้ามเด็ดขาด — B, C และ D — เห็นตรงกันหมดในเรื่องเดียว: ต้องเปิดเผย ต่างกันแค่เปิดเผยที่ไหนและเข้มแค่ไหน
นั่นแปลว่าคำถามที่ Debian กำลังตัดสินจริง ๆ อาจไม่ใช่ “ห้ามหรือไม่ห้าม” แต่คือ “การเปิดเผยจะกลายเป็นบรรทัดฐานในรูปแบบไหน” และถ้าโครงการขนาดนี้สร้างธรรมเนียมว่า commit ที่ AI ช่วยต้องมี trailer บอกไว้ ธรรมเนียมนั้นจะไหลลงไปทั้งระบบนิเวศ เพราะ maintainer ของ Debian จำนวนมากก็เป็น upstream ของโปรเจกต์อื่นด้วย
อีกจุดร่วมคือเรื่อง ข้อมูลอ่อนไหว — ทั้ง B และ D ห้ามป้อนข้อมูลภายในโครงการเข้าเครื่องมือ AI บนคลาวด์ ซึ่งเป็นข้อกังวลด้านปฏิบัติการมากกว่าอุดมการณ์ และเป็นข้อที่องค์กรทั่วไปน่าจะลอกไปใช้ได้ทันทีโดยไม่ต้องรอผลโหวต
ส่วนข้อ A ที่ยกเรื่อง ความคลุมเครือด้านลิขสิทธิ์ ขึ้นมา คือประเด็นที่ Debian แบกหนักกว่าคนอื่นจริง ๆ เพราะทั้งดิสโทรตั้งอยู่บน DFSG และการตรวจสอบที่มาของโค้ดอย่างเคร่งครัด โค้ดที่ไม่รู้ที่มาแน่ชัดจึงเป็นปัญหาเชิงโครงสร้าง ไม่ใช่แค่เรื่องรสนิยม
มุมมอง AI Curator
สิ่งที่ทำให้เรื่องนี้สำคัญกว่าดราม่าโอเพนซอร์สทั่วไปคือ Debian เป็นโครงการที่ตัดสินใจแล้วมีผลผูกพันจริง และมีกระบวนการโหวตที่เป็นทางการ ต่างจากโครงการส่วนใหญ่ที่เรื่อง AI จบลงด้วยการทะเลาะกันใน issue tracker แล้วเงียบไป ผลของ GR นี้จะกลายเป็นเอกสารอ้างอิงที่คนหยิบไปใช้ต่ออีกหลายปี
ความเห็นตรง ๆ: ข้อ A ในทางปฏิบัติบังคับใช้ไม่ได้ และ Ian Jackson พูดเรื่องนี้ไว้ตรงที่สุดในข้อ C ของเขาเอง วันนี้ IDE ส่วนใหญ่มี autocomplete ที่ขับด้วยโมเดลติดมาโดยปริยาย เส้นแบ่งระหว่าง “เขียนเอง” กับ “AI ช่วย” เลือนจนตรวจไม่ได้ กฎที่ตรวจไม่ได้จะจบลงที่การลงโทษเฉพาะคนซื่อสัตย์ที่ยอมบอก ส่วนคนที่ไม่บอกก็ผ่านไปได้ — ผลลัพธ์แย่กว่าไม่มีกฎ
แต่ข้อกังวลของฝั่ง A ไม่ใช่เรื่องเพ้อฝัน ปัญหาจริงที่โครงการโอเพนซอร์สหลายแห่งเจอในช่วงหนึ่งถึงสองปีมานี้คือ PR คุณภาพต่ำที่ผลิตได้เร็วกว่าที่อาสาสมัครจะรีวิวไหว ต้นทุนการสร้าง contribution ลดลงเกือบเป็นศูนย์ ขณะที่ต้นทุนการรีวิวยังเท่าเดิม นี่คือความไม่สมมาตรที่ทำลายโครงการที่พึ่งอาสาสมัครได้จริง และไม่มีข้อเสนอไหนในสี่ข้อนี้แก้ได้โดยตรง เพราะการ “เปิดเผย” ไม่ได้ลดจำนวน PR ที่ต้องรีวิว
สำหรับนักพัฒนาไทย ประเด็นที่ควรเอากลับบ้านมีสองข้อ หนึ่ง — ถ้าคุณส่ง patch ขึ้น upstream ของโครงการโอเพนซอร์ส เริ่มมีวินัยเปิดเผยการใช้ AI ตั้งแต่วันนี้เลย ไม่ต้องรอผลโหวต เพราะทิศทางชัดแล้วว่าจะเป็นบรรทัดฐาน และการถูกจับได้ทีหลังว่าปิดบังนั้นเสียหายกว่ามาก สอง — องค์กรที่มีนโยบายเรื่องนี้อยู่แล้วควรอ่านข้อ B และ D เป็นแม่แบบ เพราะเขียนไว้รัดกุมกว่านโยบายภายในที่หลายบริษัทร่างเองมาก โดยเฉพาะประโยคที่ผูก “การเปิดเผย” เข้ากับ “ความรับผิดชอบของผู้ส่งงาน” — ซึ่งเป็นหัวใจที่นโยบายส่วนใหญ่ลืมใส่
สุดท้าย มีความย้อนแย้งที่น่าคิดอยู่ในข้อ C: ห้ามใช้ AI ช่วยเขียนข้อความที่มนุษย์ส่งถึงมนุษย์ ฟังดูเข้มงวด แต่สำหรับชุมชนที่ผู้ contribute จำนวนมากไม่ได้ใช้ภาษาอังกฤษเป็นภาษาแม่ — รวมถึงคนไทย — กฎข้อนี้กระทบเรามากที่สุด เพราะเครื่องมือที่หลายคนใช้ขัดเกลาอีเมลภาษาอังกฤษก่อนส่งขึ้น mailing list ก็คือ LLM นั่นเอง กฎที่ตั้งใจปกป้องคุณภาพการสื่อสาร อาจกลายเป็นกำแพงกันคนที่ภาษาอังกฤษไม่แข็งออกจากวงสนทนาไปโดยไม่ตั้งใจ
แหล่งข่าว
อ่านเพิ่มในหมวด ธุรกิจและกฎหมาย
Anthropic ขยายลายน้ำข้อความไปยัง Claude รุ่นเก่าอีก 4 รุ่น แต่บน Opus 4.6 และ Sonnet 4.6 แค่ปรับ temperature ลายน้ำก็ไม่ทำงาน
อีเมลถึงลูกค้า API ตามรายงานของ The Decoder ระบุว่า Anthropic จะใส่ลายน้ำให้ Mythos 5, Opus 4.7, Opus 4.6 และ Sonnet 4.6 แต่สองรุ่นหลังทำงานเฉพาะเมื่อพารามิเตอร์สุ่มเป็นค่าเริ่มต้น ขณะที่หน้าเอกสารทางการยังไม่แสดงการรองรับและไม่พูดถึงเงื่อนไขนี้
OpenAI จะนำเซสชัน Daybreak Blue ไปเทรนโมเดลตั้งแต่ 29 พ.ย. แม้ปิดการแชร์ข้อมูลไว้ ก่อนส่งอีเมลขอโทษและสัญญาว่าจะมีตัวเลือกแยก
OpenAI แจ้งสมาชิก Trusted Access ว่าจะใช้ข้อมูลเซสชัน Daybreak Blue เทรนโมเดลตั้งแต่ 29 พ.ย. แม้เคยปิดการแชร์ไว้ หลังถูกต้าน อีเมลฉบับที่สองขอโทษและสัญญาว่าจะมีตัวเลือกไม่เข้าร่วมแยกต่างหาก แต่เซสชันที่ถูกตั้งธงยังอาจถูกใช้เพื่อความปลอดภัย
OpenAI รื้อ Model Spec เป็น 5 คุณค่าหลัก — เลิกเรียกว่า the assistant ตัดกฎสไตล์ส่วนใหญ่ และสั่งให้ถือผลข้างเคียงเป็นของจริงแม้อยู่ใน eval
Model Spec ฉบับ 29 ต.ค. จัดโครงใหม่เป็น 5 คุณค่า เพิ่มหมวดการใช้บริบทและความจำ และหลักการรองรับการกำกับโดยมนุษย์ ขณะที่กฎสไตล์ส่วนใหญ่ รวมถึงหัวข้อ Markdown ถูกนำออก OpenAI ยังยอมรับว่าโมเดลที่ใช้งานจริงยังไม่ตรงตามเอกสารทั้งหมด