ประวัติศาสตร์ซอฟต์แวร์โอเพนซอร์สและจุดเปลี่ยนสัญญาอนุญาต

ซอฟต์แวร์โอเพนซอร์สคืออะไรและมีที่มาอย่างไร

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

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

ซอฟต์แวร์ถูกแบ่งปันก่อนที่จะมีการวางจำหน่าย

ในช่วงทศวรรษ 1950 และ 1960 ซอฟต์แวร์จะมาพร้อมกับตัวเครื่อง IBM จัดส่งซอร์สโค้ดไปพร้อมกับระบบของตน และกลุ่มผู้ใช้งานอย่าง SHARE ซึ่งก่อตั้งขึ้นในปี 1955 ได้ส่งต่อโปรแกรมต่างๆ ผ่านทางเทปแม่เหล็ก มีสองปัจจัยที่ทำให้ยุคสมัยนี้สิ้นสุดลง ในปี 1969 IBM ประกาศว่าจะแยกราคาซอฟต์แวร์ออกจากฮาร์ดแวร์ ซึ่งเป็นการสร้างตลาดสำหรับซอฟต์แวร์โดยเฉพาะ จากนั้นกฎหมายก็ตามมาทัน โดย Computer Software Copyright Act of 1980 ได้ยืนยันว่าโปรแกรมคอมพิวเตอร์เป็นงานที่ได้รับความคุ้มครองลิขสิทธิ์ในสหรัฐอเมริกา หลังจากปี 1980 โค้ดที่คุณไม่ได้เขียนขึ้นเองจะถูกปิดเป็นค่าเริ่มต้น ดังนั้นการแบ่งปันโค้ดดังกล่าวจึงจำเป็นต้องได้รับอนุญาตเป็นลายลักษณ์อักษรจากผู้เขียน

Homebrew Computer Club และจดหมายเปิดผนึกถึงนักอดิเรก

Homebrew Computer Club จัดการประชุมครั้งแรกในเดือนมีนาคม 1975 ที่โรงรถแห่งหนึ่งใน Menlo Park รัฐแคลิฟอร์เนีย สมาชิกนำฮาร์ดแวร์และเทปกระดาษมาด้วย และการคัดลอกซอฟต์แวร์ถือเป็นส่วนหนึ่งของการประชุม Altair BASIC ซึ่งเขียนโดย Bill Gates และ Paul Allen ถูกส่งต่อกันไปทั่วห้องด้วยเทปที่คัดลอกมา ในเดือนกุมภาพันธ์ 1976 Gates ได้ตอบโต้ผ่านจดหมายข่าวของชมรมด้วย "จดหมายเปิดผนึกถึงนักอดิเรก" (An Open Letter to Hobbyists)

ดังที่นักอดิเรกส่วนใหญ่คงทราบกันดี พวกคุณส่วนใหญ่กำลังขโมยซอฟต์แวร์ของพวกเรา

เขาเขียนระบุว่ามีเจ้าของ Altair น้อยกว่า 1 ใน 10 คนที่จ่ายเงินซื้อ BASIC และเวลาที่ใช้ในการเขียนโปรแกรมนั้นมีมูลค่ามากกว่า 40,000 ดอลลาร์ ข้อโต้แย้งในยุคปัจจุบันทั้งหมดล้วนปรากฏอยู่ในจดหมายฉบับนั้นแล้ว การคัดลอกซอฟต์แวร์ไม่มีต้นทุนและเป็นประโยชน์ต่อทุกคนที่คัดลอกไป แต่การเขียนซอฟต์แวร์นั้นยังคงต้องแลกด้วยเวลาหนึ่งปีของชีวิตผู้เขียน สัญญาอนุญาตทุกฉบับที่อธิบายไว้ด้านล่างนี้คือความพยายามในการตอบโจทย์ข้อเท็จจริงทั้งสองประการนี้ไปพร้อมกัน

GNU ในปี 1983 และ GPL ในฐานะนวัตกรรมทางกฎหมาย

Richard Stallman ประกาศเปิดตัว GNU ในเดือนกันยายน 1983 บน Usenet ซึ่งเป็นเครือข่ายกลุ่มข่าวที่ผู้คนใช้งานก่อนยุคเว็บ GNU ย่อมาจาก "GNU's Not Unix" แผนการคือการสร้างระบบที่เข้ากันได้กับ Unix อย่างสมบูรณ์ ซึ่งทุกคนสามารถคัดลอกและแก้ไขได้

Unix เสรี! เริ่มตั้งแต่เทศกาลขอบคุณพระเจ้านี้ ผมจะเขียนระบบซอฟต์แวร์ที่เข้ากันได้กับ Unix อย่างสมบูรณ์ในชื่อ GNU (ย่อมาจาก Gnu's Not Unix) และแจกจ่ายให้ฟรีแก่ทุกคนที่สามารถใช้งานได้

Free Software Foundation (FSF) ก่อตั้งขึ้นตามมาในปี 1985 นิยามของซอฟต์แวร์เสรี (Free Software Definition) ระบุถึงเสรีภาพ 4 ประการ โดยเริ่มนับจากศูนย์ ได้แก่ การรันโปรแกรมเพื่อวัตถุประสงค์ใดก็ได้, การศึกษาและแก้ไขโปรแกรม, การแจกจ่ายสำเนา และการแจกจ่ายเวอร์ชันที่คุณแก้ไขแล้ว เสรีภาพข้อที่ 1 จำเป็นต้องมี source code เพราะไม่มีใครสามารถศึกษาไฟล์ binary ได้อย่างเป็นรูปธรรม คำว่า "เสรี" (Free) ในที่นี้หมายถึงเสรีภาพ ไม่ใช่ราคา FSF ใช้คำนิยามว่าเสรีเหมือนเสรีภาพในการพูด ไม่ใช่เสรีเหมือนเบียร์ฟรี

แถลงการณ์ไม่ใช่สิ่งประดิษฐ์ที่แท้จริง แต่เป็นใบอนุญาต GNU General Public License (GPL) ใช้กฎหมายลิขสิทธิ์เพื่อบังคับให้เกิดการแบ่งปันแทนที่จะป้องกัน คุณจะได้รับเสรีภาพทั้ง 4 ประการโดยมีเงื่อนไขว่า ใครก็ตามที่คุณส่งต่อซอฟต์แวร์ให้จะต้องได้รับเสรีภาพเหล่านั้นด้วย พร้อมกับ source code Stallman เรียกสิ่งนี้ว่า copyleft มันถูกเผยแพร่ครั้งแรกพร้อมกับ GNU Emacs ในปี 1985 กลายเป็น GPL เวอร์ชัน 1 ในปี 1989 และเวอร์ชัน 2 ในเดือนมิถุนายน 1991

GPL ทำงานได้เพราะมันตั้งอยู่บนกฎหมายลิขสิทธิ์ ไม่ใช่การต่อต้านกฎหมาย หากไม่มีใบอนุญาต คุณจะไม่มีสิทธิ์แจกจ่ายโค้ดของผู้อื่นเลย GPL มอบสิทธิ์นั้นและกำหนดเงื่อนไขกำกับไว้ ดังนั้นผู้จำหน่ายที่นำโค้ด GPL ที่แก้ไขแล้วไปใส่ไว้ใน router และปฏิเสธที่จะส่งมอบ source code จึงไม่ได้เป็นเพียงการผิดสัญญา แต่เป็นการละเมิดลิขสิทธิ์ ซึ่งเจ้าของลิขสิทธิ์สามารถนำเรื่องขึ้นฟ้องร้องต่อศาลได้ นี่คือเหตุผลที่การบังคับใช้กฎหมายสามารถทำได้จริง ตั้งแต่กรณี gpl-violations.org ของ Harald Welte ในช่วงปี 2000 ไปจนถึงคดีที่ Software Freedom Conservancy ฟ้องร้อง Vizio ในปี 2021 ซึ่งโต้แย้งว่าบุคคลที่ซื้อโทรทัศน์ไปก็มีสิทธิ์เรียกร้อง source code ได้เช่นกัน

Linux เติมเต็มระบบปฏิบัติการ

ภายในปี 1991 โครงการ GNU มีทั้งคอมไพเลอร์, ไลบรารีภาษา C, เชลล์ และเครื่องมือส่วนใหญ่พร้อมใช้งานแล้ว แต่ยังขาดเคอร์เนลที่ทำงานได้จริง เนื่องจาก Hurd ซึ่งเป็นเคอร์เนลของ GNU เองนั้นใช้เวลาพัฒนาเกินกำหนดไปมาก ในเดือนสิงหาคม 1991 นักศึกษาคนหนึ่งในเฮลซิงกิได้โพสต์ข้อความลงในกลุ่มข่าว comp.os.minix ว่า:

ผมกำลังทำระบบปฏิบัติการ (ฟรี) (เป็นแค่งานอดิเรก จะไม่ใหญ่โตและเป็นมืออาชีพเหมือน GNU) สำหรับเครื่อง 386(486) AT clones

Linux 0.01 ปรากฏขึ้นในเดือนกันยายน 1991 ภายใต้สัญญาอนุญาตที่ Linus Torvalds เขียนขึ้นเอง ซึ่งห้ามไม่ให้มีการจำหน่าย ต่อมาเขาได้เปลี่ยนมาใช้ GPLv2 ในช่วงต้นปี 1992 และกล่าวในภายหลังว่านั่นคือหนึ่งในการตัดสินใจที่ดีที่สุดของเขา สัญญาอนุญาตนี้เองที่ทำให้การมีส่วนร่วมจากภาคธุรกิจมีความปลอดภัย บริษัทต่างๆ สามารถส่งวิศวกรมาพัฒนาเคอร์เนลได้โดยมั่นใจว่าคู่แข่งจะไม่สามารถนำการปรับปรุงเหล่านั้นไปเป็นกรรมสิทธิ์ส่วนตัวได้

ระบบปฏิบัติการ Unix แบบฟรีมีอยู่แล้วที่ Berkeley เหตุผลที่ Linux กลายเป็น Unix แบบฟรีที่เป็นมาตรฐานแทนที่จะเป็น BSD (Berkeley Software Distribution) ส่วนหนึ่งมาจากคดีความทางกฎหมาย โดย Unix System Laboratories ได้ฟ้องร้อง Berkeley Software Design ในปี 1992 และคดีดำเนินไปจนถึงต้นปี 1994 ตลอดระยะเวลา 2 ปีนั้น ระบบ BSD มีความเสี่ยงทางกฎหมายในขณะที่ Linux ไม่มีเลย และนั่นคือช่วงเวลาที่ผู้ใช้งานเริ่มหันมาใช้ Linux ทาง FSF ได้ขอให้ผู้คนเรียกชื่อระบบรวมว่า GNU/Linux เนื่องจาก Linux เป็นเพียงเคอร์เนลและเครื่องมือส่วนใหญ่ที่ล้อมรอบนั้นเป็นของ GNU อย่างไรก็ตาม คนส่วนใหญ่เรียกเพียงว่า Linux ซึ่งทั้งสองชื่อต่างก็หมายถึงชุดซอฟต์แวร์เดียวกัน

1998: การรีแบรนด์โอเพนซอร์ส และความแตกแยกที่ไม่มีวันสมาน

ในเดือนมกราคม 1998 Netscape ประกาศว่าจะเผยแพร่ซอร์สโค้ดของเบราว์เซอร์ตนเอง นี่เป็นบริษัทที่ใหญ่ที่สุดเท่าที่เคยทำเช่นนี้ และมันได้เผยให้เห็นปัญหาในทางปฏิบัติ คำว่า "free software" ในภาษาอังกฤษอ่านแล้วสื่อถึง "ซอฟต์แวร์ที่ไม่มีค่าใช้จ่าย" ซึ่งเป็นสิ่งที่ผู้บริหารเข้าใจเช่นนั้นจริงๆ กลุ่มบุคคลได้พบปะกันที่ Palo Alto ในเดือนกุมภาพันธ์ 1998 เพื่อหาคำเรียกที่ดีกว่า และ Christine Peterson ได้เสนอคำว่า "open source" ภายในเวลาไม่กี่สัปดาห์ Eric Raymond และ Bruce Perens ได้ก่อตั้ง Open Source Initiative (OSI) ขึ้นมา โดยได้นำ Open Source Definition มาใช้ ซึ่งดัดแปลงมาจาก Debian Free Software Guidelines ที่ Perens ได้เขียนไว้ในปี 1997

Open Source Definition มีเกณฑ์อยู่ 10 ข้อ สองข้อในนั้นเป็นตัวตัดสินข้อโต้แย้งสมัยใหม่ส่วนใหญ่ คือซอร์สโค้ดต้องเข้าถึงได้ และใบอนุญาตต้องไม่จำกัดว่าใครสามารถใช้โปรแกรมได้บ้าง หรือใช้ทำอะไร ใบอนุญาตที่ระบุว่า "คุณไม่สามารถให้บริการนี้ในเชิงพาณิชย์ได้" ถือว่าไม่ผ่านเกณฑ์ ไม่ว่าใบอนุญาตนั้นจะอนุญาตให้ทำอะไรได้บ้างก็ตาม โปรดจำประโยคนี้ไว้ให้ดี เพราะนี่คือเส้นแบ่งที่ใบอนุญาตแบบ source-available ในปัจจุบันก้าวข้ามไป

ความแตกแยกที่เกิดขึ้นในปี 1998 นั้นเป็นเรื่องของเหตุผล ไม่ใช่เรื่องของใบอนุญาตที่ยอมรับได้ ข้อโต้แย้งของ FSF เป็นเรื่องจริยธรรม: ผู้ใช้ที่ไม่สามารถแก้ไขโปรแกรมได้ ย่อมไม่สามารถควบคุมคอมพิวเตอร์ของตนเองได้ ส่วนข้อโต้แย้งของ OSI ซึ่งนำเสนอต่อภาคธุรกิจผ่านบทความ "The Cathedral and the Bazaar" ของ Raymond เป็นเรื่องของประโยชน์ใช้สอย: การพัฒนาแบบเปิดทำให้ได้ซอฟต์แวร์ที่มีคุณภาพดีกว่า และบริษัทสามารถใช้ประโยชน์จากจุดนั้นได้ คำตอบของ Stallman ในบทความ "Why Open Source Misses the Point of Free Software" ยังคงเผยแพร่อยู่บน gnu.org และเขาไม่เคยยอมรับคำเรียกใหม่นี้เลย ส่วน Perens ผู้ซึ่งมีส่วนร่วมในการสร้างคำนี้ขึ้นมา ได้ลาออกจากคณะกรรมการ OSI ในปี 1999 โดยกล่าวว่าขบวนการนี้ได้เบี่ยงเบนออกห่างจากซอฟต์แวร์เสรีไปแล้ว

การระบุให้ชัดเจนว่าช่องว่างในทางปฏิบัตินั้นเล็กน้อยเพียงใดเป็นเรื่องที่คุ้มค่า รายชื่อใบอนุญาตเสรีของ FSF และรายชื่อใบอนุญาตที่ได้รับการรับรองของ OSI เห็นพ้องกันในเกือบทุกประการ รวมถึง GPL, MIT, Apache 2.0 และ BSD นักเขียนที่ต้องการสื่อความหมายทั้งสองอย่างพร้อมกันจึงใช้คำว่า FOSS (free and open source software) หรือ FLOSS (free/libre and open source software)

บริษัทต่างๆ เรียนรู้วิธีการส่งมอบโค้ดได้อย่างไร

การนำหุ้นของ Red Hat เข้าจดทะเบียนในตลาดหลักทรัพย์เมื่อปี 1999 แสดงให้เห็นว่าผลกำไรไม่ได้มาจากการขายซอฟต์แวร์เป็นชุด แต่มาจากการสนับสนุนและการจัดทำแพ็กเกจ IBM ทุ่มงบประมาณ 1 พันล้านดอลลาร์ให้กับ Linux ในปี 2001 ประธานเจ้าหน้าที่บริหารของ Microsoft เคยเรียก Linux ว่าเป็น "มะเร็ง" ในปี 2001 แต่บริษัทเดียวกันนี้กลับเข้าร่วมเป็นสมาชิกแพลทินัมของ Linux Foundation ในปี 2016 จากนั้นได้เข้าซื้อกิจการ GitHub ในปี 2018 ด้วยมูลค่าหุ้น 7.5 พันล้านดอลลาร์ และ IBM ได้เข้าซื้อ Red Hat ในปี 2019 ด้วยมูลค่า 3.4 หมื่นล้านดอลลาร์ สิ่งเหล่านี้ไม่ใช่การเปลี่ยนใจในเรื่องลิขสิทธิ์ แต่เป็นการเปลี่ยนจุดที่ผลกำไรไปรวมตัวอยู่ เมื่อระบบปฏิบัติการกลายเป็นต้นทุนที่แชร์ร่วมกัน การจ่ายเงินเพื่อดูแลระบบของตนเองจึงมีค่าใช้จ่ายสูง และผู้จำหน่ายทุกรายต่างต้องการแข่งขันกันที่เลเยอร์เหนือระบบปฏิบัติการขึ้นไปมากกว่า

การที่บริษัทเข้าถือครองกรรมสิทธิ์ก็ส่งผลในทางกลับกันด้วย เมื่อ Oracle เข้าซื้อ Sun ในปี 2010 บริษัทได้รับสิทธิ์ใน MySQL และ OpenOffice.org ซึ่งส่งผลให้ชุมชนผู้พัฒนาทั้งสองแห่งแยกตัวออกไป MariaDB เติบโตขึ้นจาก MySQL และ LibreOffice ถูกแยกออกมา (fork) จาก OpenOffice.org ในเดือนกันยายน 2010 การแยกโปรเจกต์คือการลงคะแนนเสียงเพียงอย่างเดียวที่ชุมชนผู้ใช้งานมีสิทธิ์ทำได้จริง และลิขสิทธิ์คือสิ่งที่ทำให้การลงคะแนนเสียงนั้นเกิดขึ้นได้

เหตุผลที่แอปพลิเคชันที่คุณ self-host บางตัวในปัจจุบันมีเวอร์ชัน fork

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

• MongoDB เปลี่ยนไปใช้ Server Side Public License (SSPL) ในเดือนตุลาคม 2018 โดย SSPL ระบุว่าหากคุณให้บริการซอฟต์แวร์นั้นแก่ผู้อื่นในรูปแบบบริการ คุณต้องเผยแพร่ซอร์สโค้ดของทุกสิ่งที่ใช้ในการให้บริการนั้น ทั้งนี้ OSI ไม่ยอมรับว่า SSPL เป็นสัญญาอนุญาตแบบ open source และ MongoDB ได้ถอนเรื่องออกจากการพิจารณาในปี 2019
• Redis เพิ่มข้อจำกัดการใช้งานในบางโมดูลในปี 2018 และ 2019 จากนั้นจึงเปลี่ยนเซิร์ฟเวอร์หลักไปใช้สัญญาอนุญาตแบบ dual source-available ในเวอร์ชัน 7.4 เมื่อเดือนมีนาคม 2024 ไม่กี่วันหลังจากนั้นได้มีการ fork เวอร์ชันสุดท้ายที่ใช้สัญญาอนุญาต BSD ออกมาในชื่อ Valkey ภายใต้การดูแลของ Linux Foundation โดยได้รับการสนับสนุนจาก Amazon, Google และ Oracle รวมถึงรายอื่นๆ ในเดือนพฤษภาคม 2025 Redis ได้เพิ่ม Affero General Public License version 3 (AGPLv3) ซึ่งได้รับการรับรองจาก OSI เป็นทางเลือกที่สามสำหรับ Redis 8
• Elastic เปลี่ยน Elasticsearch และ Kibana ออกจากสัญญาอนุญาต Apache 2.0 ในเดือนมกราคม 2021 ไปเป็นสัญญาอนุญาตแบบ dual SSPL และ Elastic License ส่งผลให้ Amazon ทำการ fork ออกมาเป็น OpenSearch ต่อมา Elastic ได้เพิ่ม AGPLv3 เป็นทางเลือกที่สามในเดือนสิงหาคม 2024 และ OpenSearch ได้ถูกโอนย้ายไปอยู่ภายใต้ Linux Foundation ในเดือนกันยายน 2024 ในนาม OpenSearch Software Foundation
• HashiCorp เปลี่ยน Terraform และเครื่องมืออื่นๆ ไปใช้ Business Source License (BUSL) ในเดือนสิงหาคม 2023 โดย BUSL ไม่ถือเป็นสัญญาอนุญาตแบบ open source ในช่วงที่ยังมีผลบังคับใช้ เนื่องจากห้ามการนำไปใช้ในเชิงพาณิชย์เพื่อแข่งขัน แต่ละเวอร์ชันจะเปลี่ยนเป็นสัญญาอนุญาตแบบเปิดในวันที่กำหนดไว้ ซึ่งสำหรับ Terraform คือ 4 ปีหลังจากนั้น OpenTofu ถูก fork ออกมาภายในเวลาไม่กี่สัปดาห์และปัจจุบันอยู่ภายใต้การดูแลของ Linux Foundation เช่นกัน

ทั้งสองฝ่ายต่างมีเหตุผลที่สมเหตุสมผลและไม่มีฝ่ายใดที่มีเจตนาไม่สุจริต บริษัทที่ต้องแบกรับภาระค่าจ้างพนักงานจำนวนมากในขณะที่บริษัทขนาดใหญ่กว่านำผลงานไปขายต่อย่อมประสบปัญหาที่ความปรารถนาดีเพียงอย่างเดียวแก้ไขไม่ได้ ในขณะที่ผู้ใช้งานที่สร้างระบบบนพื้นฐานของสัญญาอนุญาต Apache 2.0 แล้วต้องตื่นมาพบกับข้อกำหนดใหม่ก็ประสบปัญหาเช่นกันโดยที่ไม่มีใครสอบถามความสมัครใจ สังเกตสิ่งที่เกิดขึ้นในสองกรณีหลังจากนั้น เมื่อการ fork เริ่มเป็นที่ยอมรับ ทั้ง Elastic และ Redis ต่างก็นำสัญญาอนุญาตแบบ copyleft ที่เข้มงวดกลับมาใช้ใหม่ สัญญาอนุญาตแบบ copyleft ตอบโจทย์ข้อร้องเรียนเดิมได้ เนื่องจาก AGPLv3 กำหนดให้ผู้ให้บริการต้องเผยแพร่การเปลี่ยนแปลงที่ตนนำไปใช้งานจริง ณ เดือนสิงหาคม 2026 ทั้งสองโครงการและทั้งสองเวอร์ชัน fork ยังคงมีการใช้งานอยู่ ซึ่งเป็นผลลัพธ์ที่สัญญาอนุญาตเหล่านี้ถูกออกแบบมาให้รองรับได้

ใครบ้างที่มีสิทธิ์เปลี่ยนแปลงใบอนุญาต

โครงการจะสามารถเปลี่ยนใบอนุญาตได้ก็ต่อเมื่อมีฝ่ายเดียวที่เป็นเจ้าของลิขสิทธิ์ทั้งหมดของโครงการนั้น บริษัทต่างๆ จะได้มาซึ่งอำนาจควบคุมดังกล่าวด้วยวิธีใดวิธีหนึ่งใน 2 วิธี คือ การโอนลิขสิทธิ์ (copyright assignment) ซึ่งเป็นการส่งมอบความเป็นเจ้าของของผลงานที่ร่วมพัฒนาแต่ละส่วนให้กับบริษัท หรือการทำข้อตกลงใบอนุญาตสำหรับผู้ร่วมพัฒนา (Contributor Licence Agreement หรือ CLA) ซึ่งยังคงให้คุณเป็นเจ้าของผลงาน แต่ให้สิทธิ์แก่บริษัทมากพอที่จะนำผลงานของคุณไปเปลี่ยนใบอนุญาตได้ โดยปกติแล้วทั้งสองวิธีนี้จะดำเนินการผ่านการคลิกลิงก์ที่บอทโพสต์ไว้ใน pull request แรกของคุณ

Linux ไม่มี CLA ผลงานที่ร่วมพัฒนาจะถูกส่งเข้ามาภายใต้ใบอนุญาต GPLv2 พร้อมกับ Developer Certificate of Origin และลิขสิทธิ์จะกระจายอยู่กับผู้คนและบริษัทนับพันราย ไม่มีใครสามารถเปลี่ยนใบอนุญาตของ Linux ได้ เนื่องจากไม่มีใครสามารถรวบรวมลายเซ็นจากทุกคนได้ครบถ้วน การคุ้มครองในลักษณะเดียวกันนี้มีผลกับทุกโครงการที่มีผู้ถือลิขสิทธิ์อิสระจำนวนมาก และเป็นการคุ้มครองที่แข็งแกร่งกว่าคำสัญญา เพราะเป็นข้อเท็จจริงที่ระบุว่าใครเป็นเจ้าของสิ่งใด

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

สิ่งที่มูลนิธิมอบให้คุณอย่างแท้จริง

มูลนิธิทำหน้าที่ถือครองสินทรัพย์และกำหนดกฎเกณฑ์ในการตัดสินใจ Apache Software Foundation, Linux Foundation, Cloud Native Computing Foundation ที่อยู่ภายใต้ และ Software Freedom Conservancy ต่างก็ทำหน้าที่นี้ในรูปแบบที่แตกต่างกันไป มูลนิธิไม่ได้มีความเป็นกลางโดยธรรมชาติ สมาชิกต้องจ่ายเงินเพื่อซื้อที่นั่ง และคนส่วนใหญ่ที่ทำงานเต็มเวลากับโครงการขนาดใหญ่ของมูลนิธิมักได้รับเงินเดือนจากบริษัทที่เป็นสมาชิก สิ่งที่คุณได้รับนั้นมีขอบเขตจำกัดแต่ก็มีคุณค่ามหาศาล นั่นคือเครื่องหมายการค้าและกระบวนการ release ไม่ได้เป็นของเวนเดอร์รายใดรายหนึ่ง ดังนั้นจึงไม่มีบริษัทใดบริษัทหนึ่งสามารถยึดโครงการไปเป็นของส่วนตัวได้

เครื่องหมายการค้าคือส่วนที่ผู้คนมักมองข้าม โค้ดมีสัญญาอนุญาตกำกับ แต่ชื่อเป็นเครื่องหมายการค้า และเครื่องหมายการค้าไม่ได้รับความคุ้มครองภายใต้สัญญาอนุญาตของโค้ด คุณสามารถ fork โค้ดได้เสมอ แต่โดยปกติแล้วคุณไม่สามารถใช้ชื่อเดิมได้ นี่คือเหตุผลที่โครงการ fork ในเรื่องนี้ถูกเรียกว่า Valkey, OpenSearch, OpenTofu และ Forgejo

ปัญหาของผู้ดูแลโครงการ

โครงสร้างพื้นฐานสมัยใหม่ตั้งอยู่บนโครงการที่มีผู้ดูแลเพียงหนึ่งหรือสองคนที่ไม่ได้ค่าตอบแทน และความล้มเหลวคือสิ่งที่ทำให้เห็นปัญหานี้ชัดเจน บั๊ก Heartbleed ใน OpenSSL เมื่อปี 2014 ส่งผลกระทบต่อไลบรารีที่แบกรับปริมาณการรับส่งข้อมูลที่เข้ารหัสส่วนใหญ่ของเว็บ ซึ่งดูแลโดยคนเพียงไม่กี่คนโดยแทบไม่มีงบประมาณสนับสนุน ส่วน Log4Shell ในเดือนธันวาคม 2021 ทำให้ทีมตอบสนองต่อเหตุการณ์ทั่วโลกต้องหันไปพึ่งพาทีมอาสาสมัครกลุ่มเล็กๆ ในโครงการ Apache Log4j

ช่องโหว่ backdoor ใน XZ Utils ที่พบในเดือนมีนาคม 2024 เป็นตัวอย่างที่ชัดเจนที่สุด เนื่องจากการโจมตีมุ่งเป้าไปที่ตัวผู้ดูแลแทนที่จะเป็นตัวโค้ด มีบัญชีหนึ่งใช้เวลาประมาณสองปีในการสร้างผลงานที่มีประโยชน์จริงให้กับไลบรารีบีบอัดข้อมูลที่ใช้กันทั่วทั้ง Linux distributions บัญชีอื่นๆ กดดันผู้ดูแลหลักที่เหนื่อยล้าให้ยอมรับความช่วยเหลือ จากนั้นผู้ดูแลร่วมคนใหม่จึงฝัง backdoor ไว้ในไฟล์ release archives โดยมุ่งเป้าไปที่ระบบที่ SSH (secure shell) daemon มีการเชื่อมโยงกับ liblzma นักพัฒนาคนหนึ่งพบช่องโหว่นี้ขณะตรวจสอบว่าเหตุใดการล็อกอินจึงใช้เวลานานกว่าปกติประมาณครึ่งวินาที ซึ่งนั่นเป็นเรื่องของโชค และทุกคนที่เกี่ยวข้องต่างก็ยอมรับในที่สาธารณะเช่นนั้น

เงินทุนเริ่มหลั่งไหลเข้ามา เช่น GitHub Sponsors ตั้งแต่ปี 2019, Open Collective, Sovereign Tech Fund ของเยอรมนีตั้งแต่ปี 2022 และโครงการ Alpha-Omega ของ OpenSSF อย่างไรก็ตาม เงินทุนเหล่านี้กระจายตัวไม่ทั่วถึงและมักจะไปถึงโครงการที่มีชื่อเสียงอยู่แล้ว นอกจากนี้ กฎระเบียบต่างๆ ก็กำลังตามมาเช่นกัน Cyber Resilience Act ของสหภาพยุโรปมีผลบังคับใช้ในเดือนธันวาคม 2024 โดยหน้าที่ส่วนใหญ่จะมีผลตั้งแต่เดือนธันวาคม 2027 ร่างกฎหมายฉบับแรกๆ อาจทำให้เกิดความรับผิดชอบในฐานะผู้ผลิตต่ออาสาสมัครที่ไม่ได้ค่าตอบแทน ดังนั้นข้อความฉบับสุดท้ายจึงสร้างหมวดหมู่ที่เบากว่าเรียกว่า "open source software steward" หลังจากมีการล็อบบี้อย่างยาวนานโดยมูลนิธิและผู้จัดจำหน่ายต่างๆ

ประวัติศาสตร์ของโอเพนซอร์สมีความหมายอย่างไรต่อซอฟต์แวร์บน VPS ของคุณ

แอปพลิเคชันทุกตัวในคู่มือการทำ self-hosting ของเราล้วนเป็นผลลัพธ์ที่สืบเนื่องมาจากการตัดสินใจเหล่านี้ Nextcloud เกิดขึ้นได้เพราะการ fork: ในปี 2016 ผู้ก่อตั้ง ownCloud และทีมงานส่วนใหญ่ได้ลาออกและเริ่มต้นโครงการใหม่ภายใต้สัญญาอนุญาต AGPLv3 และทั้งสองผลิตภัณฑ์ก็ได้ดำเนินงานแบบคู่ขนานกันมาตั้งแต่นั้น ประวัติศาสตร์ดังกล่าวคือเบื้องหลังของ ทางเลือก Nextcloud ที่น่าพิจารณา และ ทางเลือก Dropbox แบบ self-hosted ที่แข่งขันกับทั้งสองโครงการ

รูปแบบเดียวกันนี้เกิดขึ้นกับการโฮสต์ Git ตัว Gitea เองเริ่มต้นในปี 2016 ในฐานะ fork ของ Gogs ในช่วงปลายปี 2022 เครื่องหมายการค้าและโดเมนของโครงการถูกโอนไปยังบริษัทแห่งหนึ่ง ทำให้ Codeberg ทำการ fork Forgejo ออกมาในเดือนธันวาคมปีเดียวกัน และ Forgejo ได้เปลี่ยนจาก MIT มาเป็น GPLv3 ในเวอร์ชัน 9 เมื่อปี 2024 ทั้งสองโครงการถูกกล่าวถึงใน ตัวเลือก Git server แบบ self-hosted และความแตกต่างของสัญญาอนุญาตเป็นเหตุผลสำคัญที่ทำให้ทั้งสองโครงการแยกตัวออกจากกันเรื่อยมา ในขณะเดียวกัน ซอฟต์แวร์เสรีส่วนใหญ่ถูกพัฒนาบน GitHub ซึ่งเป็นแพลตฟอร์มปิดที่ Microsoft เป็นเจ้าของ นี่เป็นข้อถกเถียงเก่าแก่ที่มีเหตุผลสนับสนุนทั้งสองฝั่ง: ดูเพิ่มเติมที่ GitHub คืออะไรกันแน่

ก่อนที่คุณจะนำโปรเจกต์ใดมาติดตั้งบนเซิร์ฟเวอร์ การตรวจสอบ 4 ประการนี้ใช้เวลาเพียง 10 นาทีแต่คุ้มค่า:

• อ่านไฟล์ LICENSE ใน repository ไม่ใช่หน้าการตลาด หน้าเว็บมักจะระบุว่า "open source" นานหลังจากที่ไฟล์สัญญาอนุญาตไม่ได้ระบุเช่นนั้นแล้ว
• ตรวจสอบว่ามี CLA หรือการโอนสิทธิ์ลิขสิทธิ์ (copyright assignment) หรือไม่ หากมี เจ้าของเพียงรายเดียวสามารถเปลี่ยนแปลงเงื่อนไขของ release ในอนาคตได้
• ค้นหาว่าใครเป็นผู้ถือลิขสิทธิ์: บริษัทเดียว, ผู้ร่วมพัฒนาจำนวนมาก หรือมูลนิธิ
• นับจำนวนผู้ดูแลโครงการ (maintainer) ที่ยังทำงานอยู่ โครงการที่มีผู้ดูแลเพียงคนเดียวถือเป็นความเสี่ยงต่อตัวบุคคลนั้นพอๆ กับตัวคุณ

สิ่งเหล่านี้ไม่ได้หมายความว่าให้หลีกเลี่ยงซอฟต์แวร์จากผู้จำหน่ายรายเดียว ซอฟต์แวร์เหล่านั้นจำนวนมากมีคุณภาพดีเยี่ยม และการได้รับค่าตอบแทนมักเป็นเหตุผลที่ทำให้ซอฟต์แวร์เหล่านั้นยังคงได้รับการดูแล สิ่งเหล่านี้บอกให้คุณทราบว่าคุณกำลังเผชิญกับความเสี่ยงใด เมื่อคุณกำลังตัดสินใจว่า อะไรที่คุ้มค่าแก่การทำ self-hosting ให้ใส่เรื่องสัญญาอนุญาตไว้ในการเปรียบเทียบควบคู่ไปกับความต้องการหน่วยความจำ

คุณสามารถอ่านประวัติศาสตร์ส่วนหนึ่งได้จากเครื่องตรงหน้าคุณ แพ็กเกจทุกตัวบนระบบ Debian หรือ Ubuntu จะมาพร้อมกับเงื่อนไขของตนเอง:

ls /usr/share/doc | wc -l
head -n 20 /usr/share/doc/bash/copyright

ตัวเลขแรกคือจำนวนแพ็กเกจที่ติดตั้งอยู่ซึ่งมีไฟล์ลิขสิทธิ์ (copyright file) โดยปกติจะมีอยู่หลายร้อยรายการบน VPS ขนาดเล็ก คำสั่งที่สองจะแสดงส่วนหัวของไฟล์สำหรับ bash ซึ่งระบุถึง GNU General Public License เวอร์ชัน 3 หากไฟล์หายไป หมายความว่าแพ็กเกจนั้นไม่ได้ถูกสร้างขึ้นตามนโยบายของ Debian ซึ่งเป็นเรื่องที่พบได้ยากและควรตรวจสอบให้ถี่ถ้วนก่อนที่คุณจะเชื่อถือมัน

FAQ

ซอฟต์แวร์เสรี (Free software) กับโอเพนซอร์ส (Open source) ต่างกันอย่างไร?

ทั้งสองคำครอบคลุมชุดสัญญาอนุญาตที่เกือบจะเหมือนกัน แต่มีความเห็นต่างกันในประเด็นความสำคัญของสัญญาอนุญาตเหล่านั้น "Free software" เป็นคำที่เก่าแก่กว่า ซึ่งริเริ่มโดย Free Software Foundation ในปี 1985 โดยมีเหตุผลหลักในเชิงจริยธรรมว่า ผู้ใช้ที่ไม่สามารถแก้ไขโปรแกรมได้ย่อมไม่สามารถควบคุมคอมพิวเตอร์ของตนเองได้ ส่วนคำว่า "Open source" ถูกบัญญัติขึ้นในเดือนกุมภาพันธ์ 1998 เพื่อให้คำอธิบายเกี่ยวกับสัญญาอนุญาตชุดเดียวกันนี้แก่บริษัทต่างๆ ได้ง่ายขึ้น โดยเน้นเหตุผลในเชิงปฏิบัติ สัญญาอนุญาตอย่าง GPL, MIT, BSD และ Apache 2.0 ต่างก็อยู่ในรายการอย่างเป็นทางการของทั้งสองฝ่าย ผู้เขียนที่ต้องการสื่อถึงทั้งสองแนวคิดมักใช้คำว่า FOSS หรือ FLOSS

ซอฟต์แวร์แบบ source-available เหมือนกับโอเพนซอร์สหรือไม่?

ไม่เหมือนกัน Source-available หมายความว่าคุณสามารถอ่านซอร์สโค้ดได้ แต่โอเพนซอร์สตามนิยามของ Open Source Definition ยังหมายความว่าสัญญาอนุญาตต้องไม่จำกัดว่าใครสามารถใช้ซอฟต์แวร์นั้น หรือใช้เพื่อวัตถุประสงค์ใด ทั้ง SSPL และ Business Source License ต่างก็มีการจำกัดการใช้งานเชิงพาณิชย์ที่เป็นคู่แข่ง ดังนั้นทั้งสองจึงไม่ใช่โอเพนซอร์สตามนิยามดังกล่าว แม้ว่าจะมีการเปิดเผยซอร์สโค้ดก็ตาม หากคุณทำเพียงแค่ self-host เพื่อใช้งานส่วนตัว ข้อจำกัดเหล่านี้อาจไม่ส่งผลกระทบต่อคุณ แต่หากคุณต้องการสร้างผลิตภัณฑ์บนซอฟต์แวร์นั้น ควรตรวจสอบข้อความในสัญญาอนุญาตให้ละเอียดก่อน

บริษัทสามารถเพิกถอนสัญญาอนุญาตโอเพนซอร์สที่ให้ไว้แล้วได้หรือไม่?

ไม่ได้สำหรับโค้ดที่เผยแพร่ออกไปแล้ว เวอร์ชันนั้นจะยังคงอยู่ภายใต้สัญญาอนุญาตเดิมที่มาพร้อมกับซอฟต์แวร์ ซึ่งเป็นเหตุผลว่าทำไมโปรเจกต์ fork อย่าง Valkey และ OpenTofu จึงสามารถเริ่มต้นจาก commit ล่าสุดที่ใช้สัญญาอนุญาตแบบเสรีได้ สิ่งที่บริษัทสามารถทำได้คือการกำหนดเงื่อนไขใหม่สำหรับเวอร์ชันในอนาคต ซึ่งจะทำได้ก็ต่อเมื่อบริษัทนั้นถือครองลิขสิทธิ์ของทั้งโปรเจกต์ผ่านการโอนสิทธิ์หรือข้อตกลง contributor licence agreement เท่านั้น โปรเจกต์ที่มีผู้ถือครองลิขสิทธิ์อิสระจำนวนมาก เช่น Linux จะไม่สามารถถูกเปลี่ยนสัญญาอนุญาตโดยใครคนใดคนหนึ่งได้

ฉันควรพิจารณาสัญญาอนุญาตแบบใดสำหรับซอฟต์แวร์ที่นำมา self-host?

สำหรับซอฟต์แวร์ที่คุณรันด้วยตนเองและไม่ได้นำไปขายต่อ สัญญาอนุญาตใดๆ ที่ได้รับการรับรองจาก OSI เช่น GPL, AGPL, MIT หรือ Apache 2.0 ก็เพียงพอต่อความต้องการของคุณ สิ่งที่ควรตรวจสอบมากกว่าคือใครเป็นผู้ถือครองลิขสิทธิ์ เพราะนั่นจะเป็นตัวตัดสินว่าเงื่อนไขต่างๆ จะถูกเปลี่ยนแปลงในภายหลังหรือไม่ โปรเจกต์ที่ดูแลโดยมูลนิธิหรือโดยผู้ร่วมพัฒนาอิสระจำนวนมากจะไม่สามารถถูกเปลี่ยนสัญญาอนุญาตเพื่อเอาเปรียบผู้ใช้ได้ ในขณะที่โปรเจกต์จากผู้จำหน่ายรายเดียวที่มีข้อตกลง contributor licence agreement อาจทำได้ ทั้งสองแบบอาจเป็นซอฟต์แวร์ที่ดี แต่มีเพียงแบบเดียวเท่านั้นที่สามารถเปลี่ยนกฎเกณฑ์ได้ด้วยตัวเอง