เปรียบเทียบสัญญาอนุญาต GPL, MIT และ Apache ต่างกันอย่างไร

GPL เทียบกับ MIT และ Apache: แต่ละสัญญาอนุญาตต้องการอะไรจากคุณ

GPL, MIT และ Apache 2.0 ตอบคำถามเดียวกันด้วยวิธีที่ต่างกัน นั่นคือ คุณมีภาระผูกพันอย่างไรต่อผู้อื่นเมื่อส่งต่อซอฟต์แวร์นั้นไป MIT ต้องการเพียงแค่ประกาศลิขสิทธิ์เท่านั้น Apache 2.0 ต้องการประกาศดังกล่าวบวกกับข้อตกลงเรื่องสิทธิบัตรกับทุกคนที่มีส่วนร่วมในโค้ด ส่วน GPL ต้องการให้คุณเผยแพร่ซอร์สโค้ดของสิ่งที่คุณสร้างขึ้นบนพื้นฐานของซอฟต์แวร์นั้น ภายใต้สัญญาอนุญาตฉบับเดียวกันกับที่คุณได้รับมา

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

เหตุผลที่ GPL ถือกำเนิดขึ้น: เครื่องพิมพ์ที่ไม่มีใครได้รับอนุญาตให้ซ่อมแซม

ในช่วงปี 1980 ห้องปฏิบัติการปัญญาประดิษฐ์ของ MIT ได้รับเครื่องพิมพ์เลเซอร์ Xerox 9700 มาใช้งาน ทางห้องปฏิบัติการเคยแก้ไขซอฟต์แวร์ของเครื่องพิมพ์รุ่นก่อนหน้าเพื่อให้แจ้งเตือนเมื่อกระดาษติด แต่สำหรับเครื่องพิมพ์รุ่นใหม่นี้ไม่มีซอร์สโค้ดให้ และคำขอซอร์สโค้ดก็ถูกปฏิเสธเนื่องจากข้อตกลงไม่เปิดเผยข้อมูล (nondisclosure agreement) Richard Stallman ซึ่งเป็นโปรแกรมเมอร์ในห้องปฏิบัติการขณะนั้น มองว่าการปฏิเสธดังกล่าวเป็นปัญหาเชิงโครงสร้างมากกว่าจะเป็นเพียงเหตุการณ์เฉพาะหน้า เขาจึงประกาศโครงการ GNU เมื่อวันที่ 27 กันยายน 1983

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

Stallman เขียนใบอนุญาตสำหรับ GNU Emacs เป็นอันดับแรก จากนั้นจึงนำมาปรับใช้ทั่วไปเป็น GPL version 1 เมื่อวันที่ 25 กุมภาพันธ์ 1989 ตามด้วย GPL version 2 ในเดือนมิถุนายน 1991 ซึ่งยังคงเป็นใบอนุญาตที่ใช้กับซอฟต์แวร์ระบบส่วนใหญ่ที่คุณใช้งานอยู่ ส่วน Lesser GPL ถูกสร้างขึ้นสำหรับไลบรารี เพื่อให้ไลบรารีแบบ copyleft สามารถถูกเชื่อมโยง (link) โดยโปรแกรมที่ใช้ใบอนุญาตอื่นใดก็ได้ โดยไม่ดึงโปรแกรมนั้นให้ต้องอยู่ภายใต้เงื่อนไขของ GPL

มีรายละเอียดหนึ่งที่กำหนดว่า GPL ส่งผลต่อผู้ที่ทำ self-host อย่างไร นั่นคือภาระผูกพันจะเกิดขึ้นเมื่อมีการแจกจ่าย (distribution) ไม่ใช่การใช้งาน (use) คุณสามารถแก้ไขโปรแกรม GPL, รันบนเซิร์ฟเวอร์ของคุณเอง, ให้บริการแก่สาธารณะด้วยโปรแกรมนั้น และไม่ต้องรับผิดชอบต่อใคร เพราะคุณไม่ได้ส่งมอบสำเนาโปรแกรมให้ผู้อื่น ช่องว่างนี้เองคือเหตุผลที่ AGPL ถือกำเนิดขึ้น

ธรรมเนียมปฏิบัติแบบเสรี: BSD และตามด้วย MIT

Berkeley เลือกเส้นทางที่แตกต่างออกไป กลุ่มวิจัย Computer Systems Research Group ได้เผยแพร่ผลงาน Unix ของตนภายใต้สัญญาอนุญาตที่ขอให้คงประกาศเรื่องลิขสิทธิ์ไว้และปฏิเสธการรับประกันความเสียหายทั้งหมด เวอร์ชันดั้งเดิมมี 4 ข้อ โดยข้อที่ 3 ซึ่งเป็นข้อกำหนดเรื่องการโฆษณา กำหนดให้ต้องมีการระบุถึงมหาวิทยาลัยในสื่อโฆษณาทุกชิ้นที่กล่าวถึงคุณสมบัติของซอฟต์แวร์ ซึ่งแนวทางนี้ไม่สามารถขยายผลได้ Stallman นับพบการระบุชื่ออ้างอิงแยกกันถึง 75 รายการใน NetBSD เวอร์ชันปี 1997 ต่อมา UC Berkeley ได้ยกเลิกข้อกำหนดดังกล่าวเมื่อวันที่ 22 July 1999 ผ่านจดหมายจาก William Hoskins แห่งสำนักงาน Office of Technology Licensing

สิ่งที่เหลืออยู่คือสัญญาอนุญาต BSD แบบ 3 ข้อ ซึ่งยังคงข้อห้ามดั้งเดิมเรื่องการใช้ชื่อผู้มีส่วนร่วมเพื่อรับรองผลิตภัณฑ์ของคุณ และเวอร์ชัน 2 ข้อ ซึ่งตัดข้อห้ามนั้นออกไป เนื้อหาของสัญญาอนุญาต MIT เกิดขึ้นจาก MIT ในช่วงทศวรรษ 1980 โดยครอบคลุมถึง X Window System ซึ่งในทางปฏิบัติแล้วทำหน้าที่เช่นเดียวกับ BSD แบบ 2 ข้อ

แรงจูงใจของทั้งสองฝ่ายนั้นแตกต่างกัน มหาวิทยาลัยที่ได้รับเงินทุนจากภาครัฐต้องการให้ผลงานของตนถูกนำไปใช้ในทุกที่ รวมถึงในบริษัทต่างๆ ส่วนโครงการ GNU ต้องการสร้างพื้นที่ส่วนรวมที่ไม่สามารถถูกปิดกั้นได้ ทั้งสองจุดยืนมีความจริงใจและต่างก็มีจุดอ่อนในตัวเอง โค้ดแบบเสรี (permissive) สามารถถูกนำไปพัฒนาต่อแบบปิดและคุณจะไม่ได้รับอะไรตอบแทน ส่วนโค้ดแบบ copyleft มักถูกปฏิเสธโดยบริษัทที่ฝ่ายกฎหมายไม่ยอมรับเงื่อนไขดังกล่าว

มีบทเรียนที่สองจาก Berkeley ซึ่งเป็นประเด็นที่บทความนี้กล่าวถึงซ้ำๆ คือการที่ Unix System Laboratories ของ AT&T ได้ฟ้องร้อง Berkeley Software Design ในปี 1992 เกี่ยวกับโค้ด BSD และคดีความได้ข้อยุติในช่วงต้นปี 1994 เป็นเวลา 2 ปีที่ไม่มีใครมั่นใจได้ว่า BSD ปลอดภัยพอที่จะนำไปพัฒนาต่อหรือไม่ ทำให้การยอมรับใช้งานหยุดชะงักในขณะที่ Linux เติบโตขึ้น ความไม่แน่นอนทางกฎหมายหยุดยั้งการยอมรับใช้งานได้รวดเร็วกว่าการที่ซอฟต์แวร์ขาดฟีเจอร์เสียอีก

เหตุผลที่ Apache 2.0 เพิ่มการอนุญาตสิทธิบัตร (patent grant)

ใบอนุญาตฉบับแรกของ The Apache Group เป็นอนุพันธ์ของ BSD 4-clause ซึ่งมีปัญหาเรื่องการโฆษณาเช่นเดียวกัน ในปี 2000 เวอร์ชัน 1.1 ได้ตัดข้อกำหนดดังกล่าวออกไป ส่วนเวอร์ชัน 2.0 ซึ่งเผยแพร่ในเดือนมกราคม 2004 นั้นเป็นการเขียนขึ้นใหม่ทั้งหมดไม่ใช่เพียงแค่การแก้ไข (patch)

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

ส่วนที่เหลือของเวอร์ชัน 2.0 เป็นเรื่องของการบริหารจัดการ ซึ่งเป็นเหตุผลที่บริษัทต่างๆ ชื่นชอบ มีการกำหนดไฟล์ NOTICE ไว้ชัดเจน ทำให้การให้เครดิตมีจุดรวมอยู่ที่เดียวแทนที่จะกระจัดกระจายอยู่ทั่วทั้งโครงสร้างไฟล์ ใบอนุญาตสามารถนำไปใช้โดยการอ้างอิงแทนที่จะต้องคัดลอกลงในทุกไฟล์ซอร์สโค้ด การมีส่วนร่วมต่างๆ จะอยู่ภายใต้ข้อกำหนดที่ชัดเจน และมีการยกเว้นเรื่องเครื่องหมายการค้าไว้ การตรวจสอบทางกฎหมายสำหรับ dependency ที่ใช้ Apache 2.0 จะพบว่าทุกคำถามที่ต้องการทราบมีคำตอบอยู่ในตัวบทใบอนุญาตแล้ว การอนุมัติจึงกลายเป็นเรื่องปกติ ซึ่งนั่นคือความหมายส่วนใหญ่ของคำว่า "มาตรฐานสำหรับองค์กร" (corporate default)

สิ่งที่ GPLv3 เปลี่ยนแปลง และเหตุผลที่ Linux ยังคงใช้ GPLv2

TiVo ได้จัดส่งเครื่องบันทึกวิดีโอที่รัน Linux และเผยแพร่ซอร์สโค้ดของเคอร์เนลตามที่ GPLv2 กำหนดไว้อย่างเคร่งครัด อย่างไรก็ตาม ฮาร์ดแวร์จะตรวจสอบลายเซ็นดิจิทัล (cryptographic signature) ในระหว่างการบูต และปฏิเสธที่จะรันเคอร์เนลที่ระบบไม่รู้จัก คุณสามารถอ่านซอร์สโค้ด แก้ไข และคอมไพล์ใหม่ได้ แต่คุณไม่สามารถรันโค้ดนั้นบนอุปกรณ์เดิมที่มาพร้อมกับเครื่องได้ ซึ่งถือว่าเป็นการปฏิบัติตามตัวอักษรของสัญญาอนุญาตแต่ขัดต่อเจตนารมณ์ดั้งเดิม พฤติกรรมนี้จึงถูกเรียกว่า tivoisation

GPL เวอร์ชัน 3 ซึ่งเผยแพร่เมื่อวันที่ 29 มิถุนายน 2007 ได้แก้ไขปัญหานี้โดยตรง เมื่อคุณส่งมอบไฟล์ไบนารีที่อยู่ในอุปกรณ์สำหรับผู้บริโภค คุณจะต้องจัดเตรียม "ข้อมูลการติดตั้ง" (Installation Information) ซึ่งได้แก่ กุญแจหรือคำแนะนำที่จำเป็นสำหรับการติดตั้งเวอร์ชันที่แก้ไขแล้วและทำให้มันทำงานได้ นอกจากนี้ เวอร์ชัน 3 ยังได้เพิ่มการอนุญาตให้ใช้สิทธิบัตร (patent grant) อย่างชัดเจน ซึ่งเป็นข้อกำหนดที่เขียนขึ้นเพื่อตอบโต้ข้อตกลงด้านสิทธิบัตรระหว่าง Microsoft และ Novell ในเดือนพฤศจิกายน 2006 รวมถึงการรองรับความเข้ากันได้ทางเดียวกับ Apache 2.0

Linux ไม่ได้เปลี่ยนตาม เคอร์เนลยังคงเป็น GPL เวอร์ชัน 2 เท่านั้น โดยไม่มีเงื่อนไข "หรือเวอร์ชันที่ใหม่กว่า" (or any later version) และไฟล์ COPYING ก็ระบุไว้เช่นนั้น Linus Torvalds ได้คัดค้านข้อกำหนดต่อต้าน tivoisation สำหรับฮาร์ดแวร์ที่ต้องใช้ลายเซ็นอย่างเปิดเผย อุปสรรคในทางปฏิบัติมีมากกว่าความเห็นที่ไม่ตรงกัน เนื่องจากเคอร์เนลมีผู้ถือลิขสิทธิ์หลายพันคน จึงไม่มีใครสามารถรวบรวมการอนุญาตที่จำเป็นสำหรับการเปลี่ยนสัญญาอนุญาตได้ แม้ว่าทุกคนจะต้องการก็ตาม ข้อเท็จจริงเพียงประการเดียวนี้คือการปกป้องที่แข็งแกร่งที่สุดที่โครงการหนึ่งจะมีได้ และเป็นสิ่งที่ควรจดจำเมื่อคุณพิจารณาโครงการที่ถูกถือครองโดยบริษัทเดียว

สัญญาอนุญาตอีกฉบับในปี 2007 มีความสำคัญต่อคุณมากกว่า นั่นคือ GNU Affero GPL เวอร์ชัน 3 ซึ่งเผยแพร่ในเดือนพฤศจิกายนปีเดียวกัน โดยขยายภาระผูกพันด้านซอร์สโค้ดไปยังผู้ที่โต้ตอบกับโปรแกรมผ่านเครือข่าย หากคุณรันบริการ AGPL ที่แก้ไขแล้วให้สาธารณชนใช้งาน คุณมีหน้าที่ต้องเปิดเผยซอร์สโค้ดให้ผู้ใช้เหล่านั้น นั่นคือเหตุผลที่ซอฟต์แวร์เว็บแบบ self-hosted จำนวนมากใช้สัญญาอนุญาต AGPL ตัวอย่างหนึ่งคือ Nextcloud และหากคุณกำลังเปรียบเทียบ ทางเลือกแบบ self-hosted แทน Nextcloud บรรทัดที่ระบุสัญญาอนุญาตใน repository ของแต่ละตัวเลือกจะบอกคุณเกี่ยวกับอนาคตในอีก 5 ปีข้างหน้าได้มากกว่ารายการฟีเจอร์เสียอีก

คุณสามารถรวมสัญญาอนุญาตแบบใดได้บ้าง?

ความเข้ากันได้มีทิศทางเดียว คือจากแบบอนุญาต (permissive) ไปสู่แบบคัดลอกซ้าย (copyleft)

• โค้ด MIT และ BSD สามารถนำไปรวมกับอะไรก็ได้ รวมถึงผลิตภัณฑ์แบบปิด
• โค้ด Apache 2.0 สามารถรวมเข้ากับโปรเจกต์ GPLv3 ได้ โดยผลงานที่รวมกันนั้นจะมีสถานะเป็น GPLv3
• โค้ด Apache 2.0 ไม่สามารถรวมเข้ากับโปรเจกต์ที่เป็น GPLv2 เพียงอย่างเดียวได้ เนื่องจากเงื่อนไขการสิ้นสุดสิทธิบัตรและการชดเชยค่าเสียหายเป็นเงื่อนไขเพิ่มเติมที่ GPLv2 ไม่อนุญาตให้เพิ่มเข้าไป ทั้ง FSF และ ASF ต่างเผยแพร่ข้อสรุปนี้ตรงกัน
• คุณไม่สามารถเปลี่ยนโค้ด GPL ให้เป็นสัญญาอนุญาตแบบอนุญาตได้ มีเพียงเจ้าของลิขสิทธิ์เท่านั้นที่ทำได้ ซึ่งจะนำคุณกลับไปสู่คำถามเดิมว่าใครคือเจ้าของลิขสิทธิ์เหล่านั้น

ยุคแห่งการเปลี่ยนสัญญาอนุญาต: SSPL, BUSL และสิ่งที่สัญญาเหล่านี้ไม่ใช่

จุดเริ่มต้นมาจากเหตุผลเชิงพาณิชย์ บริษัทที่เป็นเจ้าของลิขสิทธิ์ผลิตภัณฑ์แห่งหนึ่งพบว่าผู้ให้บริการคลาวด์นำผลิตภัณฑ์นั้นไปขายเป็นบริการแบบจัดการ (managed service) ในสเกลใหญ่โดยแทบไม่ได้มีส่วนร่วมพัฒนาคืนให้แก่โครงการ บริษัทจึงเปลี่ยนสัญญาอนุญาตเพื่อหยุดยั้งการกระทำดังกล่าว Redis Labs เป็นรายแรกที่เริ่มดำเนินการอย่างชัดเจนในเดือนสิงหาคม 2018 โดยการเพิ่ม Commons Clause ครอบทับบน Apache 2.0 สำหรับโมดูลหลายตัวของตน จากนั้น MongoDB ได้ดำเนินการตามในวันที่ 16 ตุลาคม 2018 โดยเปลี่ยนจาก AGPLv3 ไปใช้ Server Side Public License

SSPL คือ AGPL ที่มีการเขียนส่วนหนึ่งขึ้นใหม่ หากคุณนำโปรแกรมไปให้บริการแก่บุคคลที่สาม คุณต้องเปิดเผยซอร์สโค้ดของทุกสิ่งที่ใช้ในการให้บริการนั้น รวมถึงซอฟต์แวร์จัดการและซอฟต์แวร์ orchestration ที่เกี่ยวข้องด้วย ข้อกำหนดนี้ไม่มีขอบเขตที่ชัดเจนและยังไม่เคยมีการทดสอบในชั้นศาล OSI ไม่เคยรับรองสัญญาอนุญาตนี้ และ MongoDB ได้ถอนคำร้องขอการรับรองไปในเดือนมีนาคม 2019 Debian ได้ประกาศไว้ตั้งแต่เดือนธันวาคม 2018 แล้วว่าซอฟต์แวร์ภายใต้ SSPL ไม่สามารถรวมอยู่ในคลังซอฟต์แวร์ของตนได้ และ Fedora ได้ตัดสินในเดือนมกราคม 2019 ว่าสัญญาอนุญาตนี้ไม่ใช่ซอฟต์แวร์เสรี ส่งผลให้ Red Hat ถอด MongoDB ออกจาก Fedora และ Red Hat Enterprise Linux นี่คือผลลัพธ์เชิงกลไกของการเปลี่ยนสัญญาอนุญาต: ผู้จัดทำแพ็กเกจซอฟต์แวร์จะหยุดบรรจุซอฟต์แวร์นั้นลงในคลัง ทำให้การอัปเกรดของคุณต้องมาจาก repository ของผู้จำหน่ายตามกำหนดการของผู้จำหน่ายเอง

Business Source License เป็นกลไกที่แตกต่างออกไป สัญญาอนุญาตนี้มาจากผู้ก่อตั้ง MariaDB โดยเวอร์ชัน 1.1 เริ่มใช้ในปี 2017 สัญญาอนุญาตนี้ไม่ใช่ copyleft และไม่ใช่ open source ซอร์สโค้ดเปิดเผยต่อสาธารณะและใช้งานได้ฟรีหากไม่ใช่เพื่อการผลิต (production) การใช้งานเพื่อการผลิตจะได้รับอนุญาตก็ต่อเมื่อเป็นไปตาม Additional Use Grant ของผู้จำหน่าย ซึ่งโดยปกติแล้วจะไม่อนุญาตให้รันบริการโฮสต์ที่เป็นคู่แข่ง ทุกรุ่นที่ปล่อยออกมาจะเปลี่ยนเป็นสัญญาอนุญาต open source จริงโดยอัตโนมัติเมื่อถึงวันที่กำหนด ซึ่งต้องไม่เกินสี่ปีหลังจากที่ปล่อยรุ่นนั้นออกมา สัญญาอนุญาตที่จะเปลี่ยนไปใช้นั้นต้องเป็น GPL เวอร์ชัน 2.0 หรือเวอร์ชันที่ใหม่กว่า หรือสัญญาอนุญาตที่เข้ากันได้กับสัญญาอนุญาตดังกล่าว HashiCorp ได้เปลี่ยน Terraform และผลิตภัณฑ์อื่นๆ ของตนไปใช้ BUSL 1.1 ในวันที่ 10 สิงหาคม 2023 ส่วน Outline ก็ใช้สัญญาอนุญาตนี้เช่นกัน ซึ่งเป็นสิ่งที่ควรทราบหากคุณกำลังเลือก ทางเลือก Notion ที่โฮสต์เองได้: การรันเพื่อใช้งานภายในทีมของคุณนั้นได้รับอนุญาต แต่การสร้างบริการบนซอฟต์แวร์นี้ไม่ได้รับอนุญาต

สัญญาอนุญาตทั้งสองแบบไม่ได้มีความไม่ซื่อตรง ทั้งสองระบุไว้อย่างชัดเจนว่าเป็น source available ทั้งคู่ไม่ใช่ open source ตามนิยามของ OSI และความแตกต่างนี้ส่งผลกระทบต่อตัวคุณมากกว่าผู้ให้บริการคลาวด์ที่เป็นเป้าหมายหลักของสัญญาอนุญาตเหล่านี้

OpenSearch: ต้นทุนที่ผู้ดูแลระบบต้องจ่ายจากการแยกโครงการ (fork) เพราะเรื่องลิขสิทธิ์

เมื่อวันที่ 14 มกราคม 2021 Elastic ประกาศว่า Elasticsearch และ Kibana จะเปลี่ยนจากสัญญาอนุญาต Apache 2.0 ไปใช้ SSPL หรือ Elastic License โดยเริ่มตั้งแต่รุ่น 7.11 เป็นต้นไป รุ่น 7.10.2 จึงเป็นรุ่นสุดท้ายที่ใช้ Apache 2.0 ประมาณหนึ่งสัปดาห์หลังจากนั้น AWS ประกาศว่าจะสร้างและดูแลโครงการ fork ของทั้งสองซอฟต์แวร์ที่ยังคงใช้ Apache 2.0 ต่อไป โครงการนี้ถูกตั้งชื่อว่า OpenSearch ในวันที่ 12 เมษายน 2021 และเปลี่ยนชื่อ Kibana เป็น OpenSearch Dashboards โดย OpenSearch 1.0 เปิดให้ใช้งานทั่วไปในวันที่ 12 กรกฎาคม 2021 ซึ่งพัฒนาต่อยอดมาจาก Elasticsearch 7.10.2 และ Kibana 7.10.2

ลองพิจารณาต้นทุนที่ผู้ดูแลคลัสเตอร์ต้องแบกรับ ชื่อแพ็กเกจและที่เก็บซอร์สโค้ด (repository) เปลี่ยนไป การอ้างอิงถึง Kibana ในคู่มือการปฏิบัติงาน (runbook) ทั้งหมดต้องเปลี่ยนเป็น OpenSearch Dashboards ชื่อปลั๊กอินต่างๆ ถูกย้ายตำแหน่ง จากนั้นผลกระทบก็ลามไปถึงโค้ดของแอปพลิเคชัน โดยตั้งแต่รุ่น 7.13 ของไลบรารี client อย่างเป็นทางการของ Elastic ตัว client จะตรวจสอบว่ากำลังเชื่อมต่อกับอะไร และจะปฏิเสธการทำงานหากไม่ใช่ Elasticsearch โดยแจ้งว่าเซิร์ฟเวอร์เป็นผลิตภัณฑ์ที่ไม่รู้จัก การตัดสินใจเรื่องลิขสิทธิ์ของบริษัทที่คุณไม่ได้ทำงานด้วย กลายเป็นข้อผิดพลาดในการเรียกใช้งานภายในแอปพลิเคชันของคุณเอง

เรื่องราวหลังจากนั้นพลิกผันอีกสองครั้ง ในวันที่ 29 สิงหาคม 2024 Elastic ประกาศว่าจะเพิ่ม AGPLv3 เป็นทางเลือกที่สามของสัญญาอนุญาต และใน FAQ เรื่องลิขสิทธิ์ระบุว่าการเพิ่มนี้จะมีผลในเดือนกันยายน 2024 ทำให้ปัจจุบัน Elasticsearch กลับมาเป็นโอเพนซอร์สที่ได้รับการรับรองจาก OSI อีกครั้ง ต่อมาในวันที่ 16 กันยายน 2024 AWS ได้โอนย้าย OpenSearch ไปอยู่ภายใต้การดูแลของ OpenSearch Software Foundation ซึ่งบริหารโดย Linux Foundation ทำให้โครงการ fork นี้มีหน่วยงานกลางที่ไม่ได้ขึ้นตรงกับบริษัทใดบริษัทหนึ่งเป็นผู้ดูแล ห้าปีหลังจากการแยกตัว ทั้งสองโครงการต่างเป็นโอเพนซอร์สและได้รับการดูแลอย่างต่อเนื่อง โดย OpenSearch เดินทางมาถึงซีรีส์ 3.x แล้ว ณ เดือนตุลาคม 2026

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

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

[
  {
    "label": "Elasticsearch to OpenSearch 1.0",
    "gap_to_stable_fork": 179
  },
  {
    "label": "Terraform to OpenTofu 1.6.0",
    "gap_to_stable_fork": 153
  },
  {
    "label": "Redis to Valkey 7.2.5",
    "gap_to_stable_fork": 27
  }
]

ระยะเวลาแต่ละช่วงนับตั้งแต่วันที่ผู้จำหน่ายประกาศต่อสาธารณะจนถึงรุ่นเสถียรแรกของโครงการ fork โดยใช้ข้อมูลวันที่ด้านล่าง OpenSearch 1.0 ใช้เวลา 179 วัน เนื่องจากต้องมีการเปลี่ยนชื่อและสร้างใหม่โดยไม่มีโครงการ fork อื่นให้คัดลอก OpenTofu ใช้เวลา 153 วัน ส่วน Valkey ใช้เวลา 27 วัน เพราะเป็นการ fork จาก Redis 7.2.4 โดยยังคงรักษาโปรโตคอลและรูปแบบข้อมูลบนดิสก์ให้เหมือนเดิม สิ่งที่น่าสนใจคือแนวโน้มในปัจจุบัน: โครงการ fork ที่น่าเชื่อถือสามารถเกิดขึ้นได้ภายในเวลาไม่กี่สัปดาห์ โดยมีมูลนิธิและผู้ดูแลที่ได้รับค่าจ้างสนับสนุนตั้งแต่วันแรก

Valkey และ OpenTofu: รูปแบบเดียวกัน แต่รวดเร็วกว่า

Redis Ltd ได้เปลี่ยนสิทธิ์การใช้งาน Redis จาก BSD 3-clause ไปเป็นทางเลือกระหว่าง RSALv2 หรือ SSPLv1 เมื่อวันที่ 20 มีนาคม 2024 แปดวันหลังจากนั้น Linux Foundation ได้ประกาศเปิดตัว Valkey ซึ่งเป็นการ fork มาจาก Redis 7.2.4 และยังคงใช้สิทธิ์ BSD 3-clause ตามเดิม Valkey 7.2.5 ถูกปล่อยออกมาเมื่อวันที่ 16 เมษายน 2024 โดยใช้โปรโตคอลและไฟล์ข้อมูลชุดเดียวกัน ดังนั้นสำหรับผู้ดูแลระบบส่วนใหญ่ การย้ายระบบจึงเป็นเพียงการเปลี่ยนชื่อแพ็กเกจเท่านั้น ต่อมา Redis ได้เพิ่ม AGPLv3 เป็นทางเลือกที่สามใน Redis 8 เมื่อเดือนพฤษภาคม 2025 ซึ่งทำให้กลับมาเป็นโอเพนซอร์สตามนิยามของ OSI อีกครั้ง ในขณะที่ Valkey ยังคงดำเนินงานภายใต้การกำกับดูแลของตนเอง รูปแบบเหตุการณ์นี้มีความคล้ายคลึงกับ Elasticsearch อย่างมาก

Terraform มีเส้นทางที่คล้ายกันแต่มีบทสรุปเพิ่มเติมอีกหนึ่งตอน OpenTofu ได้ fork เวอร์ชันสุดท้ายที่ใช้สิทธิ์ Mozilla Public License 2.0 ออกมา โดยเข้าร่วมกับ Linux Foundation ในเดือนกันยายน 2023 และปล่อยเวอร์ชัน 1.6.0 เมื่อวันที่ 10 มกราคม 2024 ต่อมาในวันที่ 3 เมษายน 2024 ฝ่ายกฎหมายของ HashiCorp ได้ส่งหนังสือแจ้งเตือนให้ยุติการกระทำ (cease and desist) โดยอ้างว่ามีการคัดลอกโค้ดจาก Terraform เวอร์ชันที่ใช้สิทธิ์ BUSL เข้าไปในโปรเจกต์ fork นี้ OpenTofu ได้เผยแพร่คำชี้แจงโดยละเอียดเมื่อวันที่ 11 เมษายน 2024 เพื่อปฏิเสธข้อกล่าวหาดังกล่าว และสืบย้อนโค้ดที่เป็นประเด็นกลับไปยังประวัติการใช้สิทธิ์ MPL ซึ่งทั้งสองโปรเจกต์มีร่วมกัน หลังจากนั้นไม่มีความเคลื่อนไหวใดๆ ต่อสาธารณะอีก ความเสี่ยงที่แท้จริงจากเหตุการณ์นี้คือสิ่งที่ควรจดจำ: เพียงแค่ข้อกล่าวหาก็สามารถทำให้การยอมรับเทคโนโลยีหยุดชะงักไปได้นานถึงหนึ่งไตรมาส ซึ่งเป็นผลกระทบแบบเดียวกับที่คดีความของ Berkeley เคยเกิดขึ้นเมื่อสามสิบปีก่อน

ไม่ใช่ทุกการ fork ที่เริ่มต้นจากเรื่องสิทธิ์การใช้งาน Forgejo fork มาจาก Gitea ในปี 2022 หลังจากที่การพัฒนา Gitea ถูกย้ายไปอยู่ภายใต้บริษัท ซึ่งเป็นข้อพิพาทด้านการกำกับดูแลมากกว่าเรื่องสิทธิ์การใช้งาน Forgejo ยังคงใช้สิทธิ์ MIT ตลอดซีรีส์เวอร์ชัน 8 จากนั้นจึงเปลี่ยนสิทธิ์เป็น GPLv3 หรือใหม่กว่าตั้งแต่เวอร์ชัน 9.0 ในปี 2024 เพื่อป้องกันไม่ให้ผลงานถูกดึงกลับไปใช้ในผลิตภัณฑ์ที่ควบคุมเชิงพาณิชย์ หากคุณกำลังพิจารณา ตัวเลือก Git server สำหรับ self-host คู่กรณีนี้เป็นตัวอย่างที่ชัดเจนที่สุดของ codebase เดียวกันแต่มีปรัชญาที่แตกต่างกันสองแบบ

การทดสอบที่ต้องทำก่อนเริ่มใช้งานสิ่งใดก็ตาม

สี่คำถามที่ควรพิจารณาก่อนการติดตั้งครั้งแรก แทนที่จะทำหลังจากนั้น

1. ใครเป็นผู้ถือลิขสิทธิ์? การเปลี่ยนสัญญาอนุญาต (relicensing) จำเป็นต้องได้รับอนุญาตจากผู้ถือลิขสิทธิ์ทุกคน ดังนั้นโครงการที่มีผู้ร่วมพัฒนาอิสระหลายร้อยคนและไม่มีการโอนสิทธิ์ให้ใครคนใดคนหนึ่ง จึงไม่สามารถเปลี่ยนสัญญาอนุญาตได้ในทางปฏิบัติ ในขณะที่โครงการที่บริษัทเดียวเป็นเจ้าของทั้งหมดสามารถเปลี่ยนสัญญาอนุญาตได้ในการประชุมคณะกรรมการ
2. มีการทำ CLA หรือไม่ และให้สิทธิ์อะไรบ้าง? ข้อตกลงใบอนุญาตผู้ร่วมพัฒนา (Contributor Licence Agreement) ที่อนุญาตให้บริษัทเปลี่ยนสัญญาอนุญาตผลงานของคุณภายใต้เงื่อนไขใดก็ได้ คือกลไกสำคัญเบื้องหลังการเปลี่ยนสัญญาอนุญาตทั้งหมดที่กล่าวมา ส่วน DCO (Developer Certificate of Origin) ซึ่งเป็นบรรทัดการลงชื่อรับรองที่ Linux kernel นำมาใช้ในปี 2004 นั้น ไม่ได้โอนสิทธิ์ใดๆ ทั้งสิ้น CLA ที่ถือโดยมูลนิธิมีความปลอดภัยมากกว่า CLA ที่ถือโดยบริษัท เนื่องจากบริษัทสามารถถูกขายกิจการได้
3. ใครเป็นเจ้าของเครื่องหมายการค้า? Elastic ยังคงถือสิทธิ์ในชื่อ Elasticsearch ดังนั้นโครงการ fork จึงต้องเปลี่ยนชื่อตัวเอง และ runbook ทุกฉบับที่กล่าวถึง Kibana ก็ต้องถูกเขียนขึ้นใหม่ทั้งหมด
4. การเปลี่ยนสัญญาอนุญาตจะส่งผลกระทบต่อคุณอย่างไร? ให้ประเมินรูปแบบข้อมูล, ไลบรารีฝั่งไคลเอนต์, การตั้งค่าที่คุณต้องเขียนใหม่ และตรวจสอบว่ามีโครงการ fork ที่เข้ากันได้อยู่แล้วหรือไม่

คำสั่งสองคำสั่งนี้สามารถตอบคำถามบางส่วนได้ภายในไม่กี่วินาที

head -n 12 /usr/share/doc/bash/copyright
git log --oneline -- LICENSE COPYING LICENSE.md

แพ็กเกจ Debian และ Ubuntu ทุกตัวจะติดตั้งไฟล์ไว้ที่ /usr/share/doc/<package>/copyright ซึ่งจะบันทึกสัญญาอนุญาตของเวอร์ชันที่คุณติดตั้งไว้ ไม่ใช่สัญญาอนุญาตที่โครงการใช้อยู่ในปัจจุบัน สำหรับ bash บน Ubuntu 24.04 ไฟล์ดังกล่าวจะระบุว่าเป็น GNU General Public License version 3 ให้รันคำสั่งที่สองภายใน source checkout เพื่อดูประวัติของไฟล์สัญญาอนุญาตนั้น หากมีการ commit ในช่วงสองปีที่ผ่านมา คุณควรตรวจสอบก่อนที่จะสร้างสิ่งใดบนโครงการนั้น หากคำสั่งไม่แสดงผลลัพธ์ใดๆ แสดงว่า repository ตั้งชื่อไฟล์สัญญาอนุญาตเป็นอย่างอื่น ให้ลองแสดงรายการไฟล์ใน root directory เพื่อตรวจสอบ

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

FAQ

ใบอนุญาต MIT เหมือนกับใบอนุญาต BSD หรือไม่

ในทางปฏิบัติ MIT มีความคล้ายคลึงกับใบอนุญาต BSD แบบ 2 ข้อ คือให้คงประกาศเรื่องลิขสิทธิ์และข้อจำกัดความรับผิดชอบไว้ จากนั้นคุณสามารถทำอะไรก็ได้ รวมถึงการนำไปสร้างเป็นผลิตภัณฑ์แบบปิด ส่วนใบอนุญาต BSD แบบ 3 ข้อได้เพิ่มเงื่อนไขอีกหนึ่งประการ คือการห้ามนำชื่อของผู้สนับสนุนไปใช้เพื่อรับรองผลิตภัณฑ์ของคุณโดยไม่ได้รับอนุญาต สำหรับใบอนุญาตเวอร์ชัน 4 ข้อแบบเก่าเคยมีข้อกำหนดให้ต้องระบุชื่อผู้สนับสนุนในสื่อโฆษณาด้วย แต่ทาง UC Berkeley ได้ยกเลิกข้อกำหนดดังกล่าวไปเมื่อวันที่ 22 กรกฎาคม 1999 ดังนั้นจึงแทบไม่มีซอฟต์แวร์ในปัจจุบันที่ใช้ใบอนุญาตเวอร์ชันนี้แล้ว

ฉันสามารถนำโค้ด Apache 2.0 ไปรวมในโปรเจกต์ GPLv2 ได้หรือไม่

ไม่ได้ เนื่องจาก Apache 2.0 มีเงื่อนไขเพิ่มเติมที่ GPLv2 ไม่อนุญาต โดยเฉพาะข้อกำหนดเรื่องการสิ้นสุดสิทธิบัตร (patent termination clause) ดังนั้นผลงานที่รวมกันจึงไม่สามารถปฏิบัติตามเงื่อนไขของทั้งสองใบอนุญาตได้พร้อมกัน ทั้ง FSF และ ASF ต่างยืนยันข้อสรุปนี้ ในทางกลับกัน หากนำโค้ด Apache 2.0 ไปรวมในโปรเจกต์ GPLv3 จะสามารถทำได้และผลลัพธ์จะเป็น GPLv3 นี่คือเหตุผลว่าทำไมโค้ด Apache 2.0 จึงไม่สามารถนำไปรวมใน Linux kernel ซึ่งใช้เฉพาะ GPL เวอร์ชัน 2 เท่านั้น

SSPL ถือเป็นใบอนุญาตแบบ open source หรือไม่

ไม่ถือเป็น open source และคำตอบนี้มีผลกระทบในทางปฏิบัติ โดย OSI ไม่เคยให้การรับรองใบอนุญาตนี้ และ MongoDB ได้ถอนใบสมัครออกไปในเดือนมีนาคม 2019 ทาง Debian ระบุในเดือนธันวาคม 2018 ว่าซอฟต์แวร์ที่ใช้ SSPL ไม่ควรอยู่ในคลังซอฟต์แวร์ของตน และ Fedora ได้ตัดสินในเดือนมกราคม 2019 ว่าใบอนุญาตนี้ไม่ถือเป็นซอฟต์แวร์เสรี ส่งผลให้ Red Hat ถอด MongoDB ออกจาก Fedora และ Red Hat Enterprise Linux สำหรับคุณนั่นหมายความว่าแพ็กเกจที่ดิสทริบิวชันของคุณเคยดูแล จะต้องมาจาก repository ของผู้จำหน่ายโดยตรง ซึ่งขึ้นอยู่กับตารางเวลาการสนับสนุนของผู้จำหน่ายนั้นๆ ส่วน Business Source License ก็ถือเป็นซอฟต์แวร์ที่เปิดเผยซอร์สโค้ด (source available) ไม่ใช่ open source แม้ว่าแต่ละเวอร์ชันจะเปลี่ยนเป็นใบอนุญาตแบบ open source ภายใน 4 ปีก็ตาม

การเปลี่ยนแปลงใบอนุญาตมีผลกับเวอร์ชันที่ฉันใช้งานอยู่หรือไม่

ไม่มีผล ใบอนุญาตที่ให้มาพร้อมกับซอฟต์แวร์เวอร์ชันหนึ่งๆ ไม่สามารถถูกเพิกถอนจากสำเนาที่เผยแพร่ออกไปแล้วได้ ซึ่งเป็นเหตุผลว่าทำไมการทำ fork จึงเป็นไปได้ ตัวอย่างเช่น OpenSearch ถูกสร้างขึ้นจาก Elasticsearch 7.10.2 ซึ่งเป็นเวอร์ชันสุดท้ายที่ Elastic เผยแพร่ภายใต้ Apache 2.0 สิ่งที่คุณจะเสียไปคืออนาคต เพราะการแก้ไขช่องโหว่ความปลอดภัยในครั้งถัดไปจะมาพร้อมกับเงื่อนไขใหม่ การล็อกเวอร์ชันสุดท้ายที่ใช้ใบอนุญาตแบบเสรีอาจช่วยซื้อเวลาให้คุณได้เพียงไม่กี่เดือน แต่ไม่ใช่แผนการระยะยาวที่ยั่งยืน