ลิขสิทธิ์และไลเซนส์ของโค้ดที่ AI สร้าง

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

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

ทำไมเรื่องนี้ยังไม่แน่นอน

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

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

ในฐานะนักพัฒนา เราไม่จำเป็นต้องรู้คำตอบของทุกข้อ แต่ต้องรู้ว่ามี "ความไม่แน่นอน" อยู่ และทำงานในแบบที่ถ้าวันหนึ่งมีคนถามว่าโค้ดนี้มาจากไหน เราตอบได้

ความเสี่ยงที่จับต้องได้: โค้ดที่เหมือนต้นฉบับ

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

• ขอให้เขียนอัลกอริทึมหรือฟังก์ชันที่มีชื่อเสียงจากโปรเจกต์ใดโปรเจกต์หนึ่ง
• ขอโค้ดยาว ๆ ที่ "ทำแบบ library X" ซึ่ง AI อาจจำโค้ดต้นฉบับมาเกือบทั้งก้อน
• โค้ดที่ได้มีคอมเมนต์ลิขสิทธิ์ ชื่อผู้เขียน หรือข้อความไลเซนส์ติดมาด้วย
• มีชื่อตัวแปรหรือโครงสร้างเฉพาะตัวที่ดูไม่เข้ากับโปรเจกต์ของเรา

ถ้าโค้ดนั้นมาจากโปรเจกต์ที่ใช้ไลเซนส์แบบ copyleft เช่น GPL การนำไปใส่ในซอฟต์แวร์ปิดของลูกค้าอาจทำให้เกิดข้อผูกพันตามไลเซนส์ เช่น ต้องเปิดเผยซอร์สโค้ดเมื่อเผยแพร่ ส่วนไลเซนส์แบบ permissive อย่าง MIT หรือ BSD มักกำหนดให้คงข้อความลิขสิทธิ์และไลเซนส์ไว้ ถ้าเราลบทิ้งก็ถือว่าไม่ปฏิบัติตามเงื่อนไขเช่นกัน

สัญญาณที่ควรหยุดและตรวจสอบ

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

อ่านเงื่อนไขของผู้ให้บริการ AI

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

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

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

สัญญากับลูกค้าและนโยบายบริษัท

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

สิ่งที่บริษัทควรกำหนดเป็นนโยบาย (และควรร่างร่วมกับฝ่ายกฎหมาย)

1. เครื่องมือ AI ใดที่อนุญาตให้ใช้กับโค้ดของลูกค้า และต้องใช้แผนแบบไหน
2. ต้องแจ้งลูกค้าหรือขอความยินยอมก่อนใช้ AI หรือไม่ ในโปรเจกต์ประเภทใด
3. การบันทึกว่าส่วนไหนของโค้ดใช้ AI ช่วยในระดับใด
4. ขั้นตอนเมื่อพบโค้ดที่น่าสงสัยว่าเหมือนต้นฉบับ
5. การตรวจไลเซนส์ของ dependency ทุกตัวก่อนส่งมอบ

แนวปฏิบัติประจำวันสำหรับนักพัฒนา

นอกจากนโยบายระดับบริษัทแล้ว มีนิสัยการทำงานง่าย ๆ ที่ลดความเสี่ยงได้มาก

1. ให้ AI ช่วยในหน่วยเล็ก ขอเป็นฟังก์ชันหรือส่วนที่เรากำหนดโครงสร้างเอง แทนการขอ "ทั้งระบบ" ในครั้งเดียว นอกจากรีวิวง่ายแล้ว ยังทำให้งานมีส่วนสร้างสรรค์ของมนุษย์ชัดเจนขึ้น

2. ใช้ library จริงแทนการให้ AI เขียนเลียนแบบ ถ้าต้องการความสามารถที่มี library ดี ๆ อยู่แล้ว ติดตั้งผ่าน Composer หรือ npm พร้อมไลเซนส์ที่ชัดเจน ดีกว่าให้ AI เขียนโค้ดคล้าย ๆ ขึ้นมาใหม่

3. ตรวจไลเซนส์ของ dependency ทั้งที่ AI แนะนำและที่ทีมเลือกเอง Composer มีคำสั่งดูไลเซนส์ของแพ็กเกจที่ติดตั้งอยู่

# ดูไลเซนส์ของทุกแพ็กเกจในโปรเจกต์ PHP
composer licenses

# โปรเจกต์ JavaScript: ดูข้อมูลไลเซนส์ของแพ็กเกจที่สงสัยทีละตัว
npm view some-package license

4. บันทึกการใช้ AI ใน Pull Request ไม่ต้องละเอียดทุกบรรทัด แต่พอให้ย้อนดูได้ เช่น เพิ่มส่วนนี้ใน PR template

## การใช้ AI ใน PR นี้
- [ ] ไม่ได้ใช้ AI
- [ ] ใช้ AI ช่วยเขียนบางส่วน (ระบุไฟล์/ฟังก์ชัน): ...
- [ ] ตรวจแล้วว่าไม่มี header ลิขสิทธิ์หรือข้อความไลเซนส์ของโปรเจกต์อื่นติดมา
- [ ] dependency ใหม่ (ถ้ามี) ตรวจไลเซนส์แล้ว: ...

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

สรุป

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

ลองทำ

รัน composer licenses ในโปรเจกต์ที่คุณดูแลอยู่ แล้วจัดกลุ่มไลเซนส์ที่พบออกเป็น permissive, copyleft และ "ไม่แน่ใจ" จากนั้นเพิ่มส่วน "การใช้ AI ใน PR นี้" เข้าไปใน PR template ของทีม ลองใช้จริงสองสัปดาห์ แล้วเอาผลไปคุยกันว่าข้อไหนมีประโยชน์ ข้อไหนเป็นภาระเกินจำเป็น