OpenJDK ห้ามโค้ดที่ AI สร้าง กับนโยบายสวนทางของ GraalVM

OpenJDK คือโครงการโอเพนซอร์สที่เป็นฐานของภาษา Java ทั้งภาษา และมีนโยบายห้ามรับเนื้อหาที่สร้างด้วย generative AI เข้าโครงการ นโยบายนี้ลงวันที่ 9 เม.ย. 2026 และมีชื่อเต็มว่าเป็นฉบับชั่วคราว (OpenJDK) ในเดือน ส.ค. 2026 มันกลับมาเป็นที่ถกเถียงอีกครั้งจากการถูก เอาไปเทียบกับท่าทีของผู้บริหาร Oracle เอง ทั้งที่ตัวกฎไม่ได้เปลี่ยนอะไรเลย

นโยบายเขียนว่าอะไร

ข้อความหลักระบุว่าสิ่งที่ส่งเข้ามาในชุมชน OpenJDK ต้องไม่มีเนื้อหาที่ถูกสร้างขึ้นไม่ว่าบางส่วนหรือทั้งหมด โดยโมเดลภาษาขนาดใหญ่ โมเดล diffusion หรือระบบ deep learning ในลักษณะเดียวกัน (OpenJDK) วลี "ในชุมชน OpenJDK" เป็นวลีกำหนดขอบเขต ไม่ใช่คำประกอบ

คำว่าเนื้อหาในที่นี้กว้างกว่าที่หลายคนคิด เพราะครอบคลุมทั้งซอร์สโค้ด ข้อความ และรูปภาพ ที่อยู่ในคลังโค้ด ในคำขอรวมโค้ดบน GitHub ในอีเมล ในหน้าวิกิ และในระบบติดตามปัญหา แปลว่าคำอธิบายใต้ pull request ที่ให้ AI ช่วยเรียบเรียงก็อยู่ในขอบเขตนี้ด้วย ไม่ใช่แค่ตัวโค้ด (OpenJDK)

คำอธิบายประกอบของนโยบายปิดช่องที่คนมักถามไว้ด้วย คือการเอาโค้ดที่ AI เขียนร้อยบรรทัดมาแก้เองสิบบรรทัด ยังถือว่าผิดกฎอยู่ เพราะสิ่งที่ส่งเข้ามายังมีส่วนที่ AI สร้างปนอยู่ (InfoQ)

จุดที่พาดหัวทำให้เข้าใจผิด

พาดหัวที่แชร์กันเขียนว่า Oracle แบนโค้ดที่ AI เขียน ซึ่งกว้างกว่าตัวนโยบายจริงมาก เพราะนโยบายเดียวกันนี้ อนุญาตชัดเจนให้ใช้ generative AI เพื่อทำความเข้าใจโค้ด ไล่หาบั๊ก ตรวจงาน และทำวิจัยได้ตามปกติ สิ่งที่ห้ามคือการเอาผลลัพธ์ของมันส่งเข้าโครงการ ไม่ใช่การใช้เครื่องมือในการทำงาน (OpenJDK)

อีกจุดที่หายไปจากพาดหัวคือคำว่าชั่วคราว นโยบายระบุเองว่า Oracle ยังร่างฉบับเต็มเพื่อเสนอคณะกรรมการกำกับ ต่อไป การเขียนว่านี่คือคำตัดสินถาวรของ Oracle จึงเกินกว่าที่เอกสารรองรับ

เหตุผลสามข้อ และข้อที่สามคือข้อที่กระทบธุรกิจมากที่สุด

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

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

GraalVM ของ Oracle เลือกคนละทาง

GraalVM เป็นโครงการของ Oracle Labs ซึ่งไม่ได้อยู่ใต้คณะกรรมการกำกับของ OpenJDK และเลือกวิธีตรงข้าม คืออนุญาตให้ใช้ AI ช่วยเขียนได้ แต่ย้ายภาระไปที่ผู้ส่งแทน เอกสารระบุว่าผู้ส่งที่เป็นมนุษย์ยังคงรับผิดชอบ การเปลี่ยนแปลงทั้งก้อนรวมถึงส่วนที่ AI ช่วยทำ และถ้าผู้ส่งอธิบาย ปกป้อง หรือดูแลการเปลี่ยนแปลงนั้นต่อไม่ได้ งานชิ้นนั้นอาจถูกปฏิเสธ (GraalVM) เอกสารฉบับนี้ปรับปรุงเมื่อ 14 เม.ย. 2026 ราวหนึ่งสัปดาห์หลังนโยบายของ OpenJDK

ความต่างที่แท้จริงจึงไม่ใช่เรื่องภาระด้านลิขสิทธิ์ เพราะทั้งสองโครงการยังบังคับสัญญาผู้ร่วมพัฒนาฉบับเดียวกัน ความต่างอยู่ที่วิธีจัดการความเสี่ยง ระหว่างการห้ามไว้ก่อน กับการอนุญาตแล้วผูกความรับผิดชอบไว้กับคน

ทำไมเรื่องเก่ากลับมาเป็นข่าว

The Register เผยแพร่บทความเมื่อ 3 ส.ค. 2026 ที่วางนโยบายนี้ไว้ข้างท่าทีของ Larry Ellison ประธานและ ประธานเจ้าหน้าที่ฝ่ายเทคโนโลยีของ Oracle ซึ่งเคยพูดที่งาน Oracle AI World เมื่อเดือน ต.ค. 2025 ว่า "The code that Oracle is writing, Oracle isn't writing. Our AI models are writing" (The Register) จากนั้นเรื่องขึ้น Hacker News เมื่อ 7 ส.ค. 2026 ด้วยคะแนนกว่า 350 และความเห็นกว่า 240 (HN)

มุมที่ว่า Oracle ย้อนแย้งกับตัวเองเป็นการตั้งข้อสังเกตของสื่อและผู้แสดงความเห็น ไม่ใช่ข้อเท็จจริงที่มีเอกสาร รองรับ สิ่งที่ยืนยันได้คือสองโครงการที่มีโครงสร้างการกำกับต่างกันออกกฎต่างกัน

เรื่องที่คนเข้าใจผิดบ่อย

หนึ่ง คนมักคิดว่านโยบายนี้เพิ่งออกในเดือน ส.ค. 2026 ความจริงคือมันลงวันที่ 9 เม.ย. 2026 และถูกหยิบมา เล่าซ้ำหลายรอบ สิ่งที่ใหม่ในเดือน ส.ค. คือความสนใจ ไม่ใช่ตัวกฎ

สอง คนมักคิดว่า Oracle ห้ามพนักงานและทุกคนใช้ AI เขียนโค้ด ความจริงคือขอบเขตอยู่ที่การส่งงานเข้าชุมชน OpenJDK เท่านั้น และการใช้ AI เพื่ออ่าน debug และตรวจงานได้รับอนุญาตอย่างชัดเจน

สาม มีการอ้างในกระทู้ว่ากฎนี้ไม่ผูกพันวิศวกรภายในของ Oracle เอง ข้ออ้างนี้ไม่มีเอกสารทางการรองรับ และตัวนโยบายเขียนครอบคลุมทุกคนที่ส่งงานเข้าชุมชน OpenJDK โดยไม่มีวรรคยกเว้น

สิ่งที่องค์กรไทยหยิบไปใช้ได้

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

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

คำถามที่ยังไม่มีคำตอบ

นโยบายฉบับเต็มที่ Oracle บอกว่ากำลังร่างเพื่อเสนอคณะกรรมการกำกับจะออกเมื่อไร และจะผ่อนหรือเข้มกว่าเดิม ยังไม่มีกำหนด

ยังไม่มีคำอธิบายจากฝ่ายใดว่าจะตรวจสอบการปฏิบัติตามกฎนี้อย่างไรในทางปฏิบัติ เพราะการแยกว่าโค้ดชิ้นไหน คนเขียนกับ AI เขียนยังไม่มีวิธีที่เชื่อถือได้ กฎจึงพึ่งการแจ้งตามความสัตย์จริงของผู้ส่งเป็นหลัก