ไม่มีสิทธิ์รีไลเซนส์โปรเจกต์นี้
(github.com/chardet)- Mark Pilgrim ผู้เขียนดั้งเดิมของ
chardetชี้ว่ามีการ ละเมิดไลเซนส์ LGPL ของโปรเจกต์ และเรียกร้องให้ถอนการ เปลี่ยนไปใช้ไลเซนส์ MIT ในเวอร์ชัน 7.0.0 ล่าสุด - เขาระบุว่า ถึงแม้ผู้ดูแลจะอ้างว่าเป็น “การเขียนใหม่ทั้งหมด” แต่ก็ยังเป็น งานดัดแปลงที่เขียนขึ้นโดยมีการเข้าถึงโค้ดต้นฉบับโดยตรง จึง ต้องคง LGPL ไว้
- นักพัฒนาหลายคนถกกันว่า การเขียนใหม่โดยมี AI ช่วย นั้นเป็น “คลีนรูมอิมพลีเมนเทชัน (clean room implementation)” จริงหรือไม่ และ LLM ได้เรียนรู้จากโค้ดต้นฉบับหรือไม่
- บางส่วนกล่าวถึงความเป็นไปได้ของ ความเข้ากันได้ของ API และ fair use แต่คนส่วนใหญ่กังวลเรื่อง ความเป็นไปได้ของการละเมิดลิขสิทธิ์ และ ความไม่แน่นอนทางกฎหมายของการสร้างโค้ดด้วย AI
- การถกเถียงครั้งนี้ถูกจับตาในฐานะกรณีตัวอย่างสำคัญเกี่ยวกับ ความรับผิดด้านลิขสิทธิ์ของโค้ดที่ AI สร้าง, ขั้นตอนการเปลี่ยนไลเซนส์ของโปรเจกต์โอเพนซอร์ส, และ ขอบเขตอำนาจของผู้ดูแลโปรเจกต์
การตั้งประเด็นของ Mark Pilgrim
- Mark Pilgrim ระบุชัดว่าตนเป็น ผู้เขียนดั้งเดิม ของ
chardetและโปรเจกต์นี้เผยแพร่มาภายใต้ ไลเซนส์ LGPL- เขาชี้ว่าคำอ้างของผู้ดูแลในเวอร์ชัน 7.0.0 ว่า “มีสิทธิ์รีไลเซนส์” นั้นไม่ถูกต้อง
- เขาเน้นว่าโค้ดภายใต้ LGPL แม้จะถูกแก้ไข ก็ยังต้องเผยแพร่ภายใต้ ไลเซนส์เดิม และคำอ้างว่าเป็น “การเขียนใหม่ทั้งหมด” นั้น ไม่มีฐานทางกฎหมาย
- เขาระบุว่าการ “เพิ่มตัวสร้างโค้ด” ไม่ได้ก่อให้เกิดสิทธิใหม่ใด ๆ
- Pilgrim เรียกร้องให้ นำโปรเจกต์กลับไปใช้ไลเซนส์ LGPL เดิม
ปฏิกิริยาแรกเริ่มจากชุมชน
- ผู้ใช้รายหนึ่งถามว่ามี fork ของเวอร์ชันก่อนการเขียนใหม่ด้วย AI หรือไม่ และมีผู้ใช้รายอื่นส่ง ลิงก์เวอร์ชัน 6.0.0 ให้
- บางคนเห็นด้วยว่า “ในทางกฎหมาย Mark ถูกต้อง” และยอมรับว่า อาจมีการละเมิด LGPL
- ผู้ใช้อีกรายมองว่า “การเขียนใหม่ผ่าน AI เป็น trade-off ที่หลีกเลี่ยงไม่ได้” โดยพูดจาก มุมมองเชิงปฏิบัติ
การถกเถียงทางกฎหมาย: API, ลิขสิทธิ์, fair use
- ผู้ใช้รายหนึ่งอ้างคดี Google LLC v. Oracle America, Inc. เพื่อกล่าวว่า API ก็เป็นสิ่งที่ได้รับความคุ้มครองด้านลิขสิทธิ์
- เขาอธิบายว่าการเขียนใหม่เพื่อให้เข้ากันได้กับ API อาจ ผิดกฎหมาย หากไม่เข้าเงื่อนไข fair use
- ขณะที่ผู้ใช้อีกรายโต้แย้งว่า ในกรณีของ Google ศาลยอมรับว่าเป็น fair use
- การสนทนาขยายไปสู่ ความชอบด้วยกฎหมายของการเขียนใหม่เพื่อความเข้ากันได้ของ API และ สถานะลิขสิทธิ์ของโค้ดที่ AI สร้าง
ข้อถกเถียงเรื่องการสร้างโค้ดด้วย AI และคลีนรูมอิมพลีเมนเทชัน
- บางคนชี้ว่า หาก “AI อาจได้เรียนรู้จากโค้ดต้นฉบับ” ก็จะ ไม่อาจถือเป็นคลีนรูมอิมพลีเมนเทชันได้
- การที่ LLM ได้เรียนรู้จากโค้ด
chardetหรือไม่นั้น อาจเป็น ประเด็นสำคัญในการตัดสินทางกฎหมาย
- การที่ LLM ได้เรียนรู้จากโค้ด
- ผู้ใช้อีกบางรายแย้งว่า “หาก AI สร้างโค้ดโดยอิงแค่ input/output ก็อาจเป็นไปได้”
- แต่ก็มีการโต้กลับว่า “ถ้าเป็นเช่นนั้น ไลเซนส์ก็คงหมดความหมาย”
- ความไม่ชัดเจนของความรับผิดด้านลิขสิทธิ์ ของโค้ด AI และ ความยากในการตรวจสอบการปฏิบัติตามไลเซนส์ กลายเป็นประเด็นหลัก
ความเข้ากันได้ของไลเซนส์และการถกเรื่อง GPL
- บางส่วนอ้างว่าไลเซนส์ MIT ไม่เข้ากันกับ GPL แต่มีผู้ใช้รายอื่นอ้าง เอกสารทางการของ FSF เพื่ออธิบายว่า MIT (Expat) เข้ากันได้กับ GPL
- อย่างไรก็ตาม คนส่วนใหญ่เห็นตรงกันว่า การรีไลเซนส์โค้ด LGPL ให้เป็น MIT ก็ยังถือว่าละเมิดอยู่ดี
- ผู้ใช้อีกคนชี้ว่า “จะคงชื่อเสียงและรีโพซิทอรีที่สร้างบนฐานโค้ด LGPL ไว้ แต่ทิ้งข้อผูกพันตามสัญญาไม่ได้”
ข้อมูลฝึกของ AI และปัญหาความน่าเชื่อถือ
- มีผู้ใช้หลายคนตั้งคำถามว่า “เชื่อได้หรือไม่ว่า Claude ไม่ได้เรียนรู้จากโค้ด LGPL”
- การติดตามย้อนกลับข้อมูลฝึกของโมเดล AI ที่ทำได้ยาก ถูกพูดถึงในฐานะความเสี่ยงทางกฎหมาย
- บางส่วนเห็นว่า “ถ้าโค้ดจาก AI มีความเป็นไปได้ที่จะลอกมา ก็ไม่ควรใช้งานตั้งแต่แรก”
- มีการยกสถิติจากงานวิจัยว่า โค้ดจาก AI ราว 2~5% อาจเป็นการคัดลอกโค้ดที่มีอยู่เดิม
อัตลักษณ์ของโปรเจกต์และอำนาจของผู้ดูแล
- บางส่วนมองว่า “หากลบโค้ดจากผู้ร่วมพัฒนาเดิมออกทั้งหมดแล้ว เวอร์ชันใหม่ก็อาจเป็นงานอิสระได้”
- แต่ก็มีเสียงโต้แย้งว่า “การใช้ชื่อและชื่อเสียงเดิมต่อไปนั้นไม่เหมาะสม”
- ยังมีความเห็นว่า “ลิขสิทธิ์คุ้มครองการแสดงออก ไม่ได้คุ้มครองชื่อ”
- มีผู้เห็นว่า หากผู้ดูแล ลบโค้ดเดิมทั้งหมดจริง ก็อาจไม่เป็นการละเมิดทางกฎหมาย แต่ ไม่มีการแสดงหลักฐานชัดเจน
มุมมองโดยรวมของชุมชน
- ผู้ใช้หลายคนกล่าวถึงการให้ความเคารพต่อผลงานของทั้ง Mark Pilgrim และ Dan Blanchard พร้อมยอมรับว่าต้องมองปัญหาที่ซับซ้อนของ AI, ลิขสิทธิ์, และธรรมาภิบาลโอเพนซอร์ส
- การถกเถียงขยายไปสู่ ความรับผิดทางกฎหมายของการสร้างโค้ดด้วย AI, ความชอบธรรมของการเปลี่ยนไลเซนส์โปรเจกต์, และ ขอบเขตอำนาจของผู้ดูแลโอเพนซอร์ส
- บางส่วนยังเสนอว่า “ลอง fork
v7.0.0แล้วเปลี่ยนกลับเป็น LGPL กันเถอะ”
สรุปประเด็นสำคัญ
- ความชอบด้วยกฎหมายของการเปลี่ยนจาก LGPL → MIT: คนส่วนใหญ่มองว่าทำไม่ได้หากไม่มีความยินยอมจากผู้สร้างดั้งเดิม
- สถานะลิขสิทธิ์ของการเขียนใหม่ด้วย AI: อาจถูกมองเป็นงานดัดแปลงได้ ขึ้นอยู่กับว่ามีการสัมผัสข้อมูลฝึกจากต้นฉบับหรือไม่
- เป็นคลีนรูมอิมพลีเมนเทชันหรือไม่: ต้องพิสูจน์ว่า AI ไม่ได้อ้างอิงโค้ดต้นฉบับ
- ปัญหาการใช้ชื่อและชื่อเสียงของโปรเจกต์: การเผยแพร่ซ้ำด้วยชื่อเดิมก่อให้เกิดข้อถกเถียงทั้งทางกฎหมายและจริยธรรม
- ความน่าเชื่อถือของโค้ด AI: มีความเสี่ยงเรื่องการลอกและความมั่นคงของซัพพลายเชน
ประเด็นนี้เป็นกรณีตัวอย่างสำคัญเกี่ยวกับ ลิขสิทธิ์ของโค้ดที่ AI สร้างและการปฏิบัติตามไลเซนส์โอเพนซอร์ส และอาจส่งผลต่อ โครงสร้างความรับผิดทางกฎหมายของเครื่องมือพัฒนา AI ในอนาคต
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
คิดว่า Pilgrim เข้าใจแนวคิด ลิขสิทธิ์ (clean room) ผิดไป
คำกล่าวอ้างว่าเป็น “การเขียนใหม่ทั้งหมด” ไม่ได้สำคัญนัก ในทางกฎหมาย การทำ implementation แบบอิสระนั้นเป็นไปได้
Clean room เป็นเพียงกลไกเชิงกระบวนการเพื่อทำให้คดีความง่ายขึ้น ไม่ใช่ข้อกำหนดทางกฎหมายว่าต้องไม่เคยเห็นโค้ดต้นฉบับเลย
ในทางปฏิบัติ Linux ก็รู้โครงสร้างภายในของ Unix แต่ก็ถูกพัฒนาขึ้นมาอย่างอิสระ
ความคล้ายต่ำของ JPlag ดูเป็น หลักฐานที่น่าเชื่อถือว่ามิใช่การลอกเลียน
ข้ออ้างว่า “ถ้ารู้จัก codebase แล้ว การเขียนใหม่ก็ยังละเมิดลิขสิทธิ์” นั้นไม่ถูกต้องทั้งหมด
ความรู้ภายในเป็นเรื่องของ สิทธิบัตร ไม่ใช่ลิขสิทธิ์
อย่างไรก็ตาม ถ้าเอาโค้ดต้นฉบับมาวางข้าง ๆ แล้วแค่เปลี่ยนถ้อยคำ แบบนั้นถือว่าละเมิด
ถ้า AI ดูโค้ดต้นฉบับแล้วสร้างโค้ดที่คล้ายกัน ก็มีโอกาสสูงที่จะถูกมองว่าเป็น การคัดลอกแบบขนาน โดยพฤตินัย
แต่ถ้าไม่ได้ดูต้นฉบับและเขียนขึ้นใหม่ทั้งหมดก็ทำได้ เพียงแต่ป้องกันตัวทางกฎหมายได้ยาก จึงควรมองเป็นความเสี่ยงในมุมของบริษัท
สิทธิบัตรอาจถูกละเมิดได้แม้จะประดิษฐ์ขึ้นอย่างอิสระ แต่ลิขสิทธิ์มีแกนสำคัญอยู่ที่ ความเป็นอิสระของการสร้างสรรค์
อย่างไรก็ดี ถ้าคุณสร้างผลงานที่ออกมาเหมือนกับสิ่งที่เคยเห็นมาแล้ว ก็ยากที่จะโน้มน้าวคณะลูกขุน
สุดท้ายถ้ามีความคล้ายกัน ก็มีแนวโน้มสูงที่จะถูกตัดสินว่าละเมิดตามเกณฑ์ น้ำหนักพยานหลักฐาน (preponderance of evidence)
แต่ถ้าไม่เคยรู้จักงานต้นฉบับเลย ก็จะถูกยอมรับว่าเป็นงานสร้างสรรค์อิสระ
ตัวไอเดียไม่ถูกคุ้มครอง แต่รูปแบบการแสดงออกถูกคุ้มครอง
ถ้า LLM เคยเห็นโค้ดต้นฉบับระหว่างกระบวนการฝึก ก็เป็นพื้นที่สีเทาทางกฎหมาย
ประเด็นสำคัญคือมีการละเมิด LGPL หรือไม่
ถ้าโค้ดใหม่อิงจากต้นฉบับ ก็จะถูกมองว่าเป็นงานดัดแปลงและต้องคง LGPL ไว้
ต่อให้กล่าวอ้างว่าเป็น “การเขียนใหม่ทั้งหมด” หากเคยสัมผัสโค้ดต้นฉบับมาก่อน ก็อาจถือเป็น การละเมิดไลเซนส์ ได้
Clean room เป็นเพียงกระบวนการเพื่อใช้ป้องกันคดี และ ภาระการพิสูจน์อยู่ที่โจทก์
Linux และเครื่องมือ GNU ก็รู้จัก Unix แต่ก็ยังชอบด้วยกฎหมาย
เคยเห็นกรณีที่น่าสนใจระหว่างงานที่ปรึกษา
วิศวกรของบริษัท SaaS แห่งหนึ่งใช้ Claude Code ย้อนวิศวกรรมแอปของบริษัทตนเองจนสร้าง แบ็กเอนด์ที่เข้ากันได้กับ API ได้ภายในหนึ่งสัปดาห์
มีคนถามว่า “ถ้าคู่แข่งทำแบบนี้จะป้องกันอย่างไร?”
ถ้าตัวโค้ดเองคือแกนหลักของธุรกิจ ก็แปลว่าอยู่ในสถานะเสี่ยงอยู่แล้ว
แทนที่จะกังวลเรื่องการแข่งขัน สิ่งสำคัญกว่าคือการสร้างผลิตภัณฑ์ที่ดีกว่า
ตอนนี้เราอยู่ในยุคที่คำพูดอย่าง “มาสร้าง Slack หรือ Drive ใหม่กัน” ไม่ได้ฟังดูเหนือจริงอีกต่อไป
API เป็นอินเทอร์เฟซที่เปิดเผยต่อสาธารณะ จึงไม่ใช่สิ่งที่ได้รับความคุ้มครอง
เช่นเดียวกับกรณีการย้อนวิศวกรรมของ IBM BIOS หรือ DOS การทำ implementation อิสระนั้นถูกกฎหมาย
ผู้ดูแลเป็น ผู้รับมอบความไว้วางใจ (trustee) ไม่ใช่เจ้าของ
จึงไม่ควรเปลี่ยนไลเซนส์ของผู้สร้างต้นฉบับตามอำเภอใจ
หากเป็นโค้ดที่สร้างใหม่ทั้งหมด ก็ควรเริ่มโปรเจ็กต์ใหม่ด้วยชื่อใหม่
คำพูดทำนอง “ก็แค่ตรึงเวอร์ชันเดิมไว้” นั้น ขัดกับจิตวิญญาณของชุมชน
ในคอมเมนต์ปี 2021 ก็มีการพูดไว้แล้วว่า “chardet ใช้ LGPL จึง relicense ไม่ได้”
ถ้ารู้เรื่องนี้อยู่แล้วแต่ยังเดินหน้า rewrite ก็ถือเป็น การตัดสินใจที่หุนหัน และเป็น การไม่ให้เกียรติ ผู้สร้างต้นฉบับ
ถ้า AI เขียนโดยอยู่ในสภาพที่ได้เห็นโค้ดต้นฉบับแล้ว นั่นก็ไม่ใช่ implementation แบบ clean room
ถ้ามีทีม AI สองชุด ชุดหนึ่งทำสเปก อีกชุดหนึ่งทำ implementation จะถือว่าใช้ได้ไหม?
แม้จะเดินตามแนวปฏิบัติในยุค IBM แต่ถ้าโมเดลเคยถูกฝึกด้วยต้นฉบับอยู่แล้ว ก็ยังเป็นปัญหา
แต่ต้องตรวจสอบให้แน่ใจว่าสเปกนั้น ไม่มีองค์ประกอบเชิงการแสดงออก ปะปนอยู่
ในสถานการณ์ที่ต้นฉบับอยู่ในข้อมูลฝึกนั้น การเปรียบเทียบเองก็แทบไม่มีความหมาย
คล้ายกับมุกที่ว่า “ถ้าก๊อปวิกิพีเดียแล้วเปลี่ยนไม่กี่คำ จะถือว่าโอเคไหม?”
สุดท้ายแล้ว การหลบเลี่ยงโดยเจตนา ทำไม่ได้จริง
เราอยู่ในยุคที่เชื่อใจได้ยากถึงขั้นต้องตรึงเวอร์ชันของ dependencies
แต่กฎหมายให้ความสำคัญกับ การพิจารณาโดยรวม
ศาลตัดสินตามเกณฑ์ “น้ำหนักพยานหลักฐาน” และการเปลี่ยนคำเพียงเล็กน้อยไม่ได้ทำให้กลายเป็นงานใหม่
ถ้าต้นฉบับเป็นองค์ประกอบจำเป็น ก็มีแนวโน้มสูงที่จะถูกตัดสินว่าเป็นงานดัดแปลง
และถ้าต้นฉบับอยู่ในข้อมูลฝึก ก็มีการคาดการณ์ว่าคดี ละเมิดลิขสิทธิ์ จะเกิดขึ้นอย่างหลีกเลี่ยงไม่ได้
อีกด้านหนึ่ง การที่ Mark Pilgrim กลับมาปรากฏตัวอีกครั้งก็น่าสนใจ
ใน หน้าวิกิพีเดียของเขา มีเกร็ดเรื่อง “การหายไปจากอินเทอร์เน็ต” อยู่
หนังสือ Python ของเขาก็ยังคงแนะนำได้อยู่
มีคนประหลาดใจว่า “ถ้า AI ถูกฝึกด้วยโค้ด GPL งั้นโค้ดจาก AI ทั้งหมดก็ ปนเปื้อน GPL (taint) หมดไม่ใช่หรือ?”
กระบวนการ clean room ในสหรัฐฯ เป็นเพียง กลยุทธ์เพื่อลดเวลาการฟ้องร้อง