ความขัดแย้งระหว่าง AWS และ Elastic รอบ Elasticsearch
(blog.opsnow.com)หลังจากได้เห็นบทความล่าสุดเกี่ยวกับการที่ Elasticsearch เลิกเป็นโอเพนซอร์ส ประกาศใช้ SSPL และ AWS ระบุว่าจะ fork แยกต่างหากเพื่อคงชุมชนโอเพนซอร์สภายใต้ Apache License 2.0 ไว้ ผมจึงลองสรุปความขัดแย้งระหว่างทั้งสองฝ่ายที่เกิดขึ้นมาตั้งแต่อดีต
หากมีส่วนใดที่ยังไม่ครบถ้วนหรือผิดพลาด สามารถคอมเมนต์มาได้และจะนำไปปรับปรุงต่อไป
10 ความคิดเห็น
โดยส่วนตัวแล้วผมยังไม่ค่อยเข้าใจว่าทำไม OSI ถึงยกเลิกการรับรอง SSPL ว่าเป็นไลเซนส์โอเพนซอร์สครับ มันเป็นไลเซนส์ที่ทำให้ชัดเจนขึ้นจาก AGPL อีกหน่อย และผมเข้าใจว่ามันหมายถึงให้ผู้ให้บริการ SaaS เปิดเผยซอร์สทั้งหมด แต่ผมยังไม่ค่อยเข้าใจว่าทำไม OSI ถึงตีความว่านี่เป็นการ "จำกัด" SaaS ครับ
แม้จะดูแถลงการณ์ของ OSI 1 ก็เห็นว่าเป็นการจี้เจตนาของ Elastic ที่นำ SSPL มาใช้ มากกว่าจะอธิบายว่าข้อไหนของ SSPL ที่ "จำกัด" การใช้งานครับ พออ่านเนื้อหาแล้วก็ยังไม่แน่ใจว่ามันมี "ข้อจำกัด" เมื่อเทียบกับ AGPL หรือเปล่า หรือว่าผมกำลังตีความไลเซนส์ผิดอยู่...
ผู้ที่ถอนเรื่องเกี่ยวกับไลเซนส์คือ MongoDB ครับ ไม่ใช่ว่า OSI เป็นฝ่ายปฏิเสธ แน่นอนว่าในฝั่ง OSI เองก็มีท่าทีว่าประเด็นที่ยังเป็นข้อถกเถียงนั้นยากจะยอมรับว่าเป็นโอเพนซอร์สได้ แต่ MongoDB ได้มองสถานการณ์นี้ออกล่วงหน้าและถอนคำขอไปเอง
ขอบคุณที่ช่วยแก้ไขครับ/ค่ะ ผม/ฉันอธิบายได้ไม่ค่อยแม่นยำนักจริง ๆ ถึงอย่างนั้นก็เป็นความจริงที่ MongoDB เป็นฝ่ายถอนก่อน แต่ถึงดูโพสต์ของ OSI ที่ลิงก์ไว้ ก็เห็นได้ชัดว่า OSI ไม่มีความตั้งใจจะยอมรับ SSPL เวอร์ชันปัจจุบันอยู่แล้ว...ดังนั้นลำดับก่อนหลังจึงดูไม่น่าใช่ประเด็นที่สำคัญนัก
เห็นด้วยครับ ^^
ผมก็มีข้อสงสัยอยู่เหมือนกันเลยกำลังค้นหาอยู่ แล้วก็เลยลองแนบลิงก์นี้ไว้ครับ
https://ceart.kr/component/file/…
คัดมา
ก่อนอื่น ความแตกต่างระหว่าง SSPL กับ AGPL มีดังนี้ AGPL เดิมนั้น แม้ซอฟต์แวร์จะไม่ได้ถูกแจกจ่ายและทำงานอยู่ฝั่งเซิร์ฟเวอร์ ก็เช่นเดียวกับ GPL ที่ผู้ให้บริการต้องเปิดเผยซอร์สโค้ดทั้งหมดของส่วนที่แก้ไขและส่วนที่เพิ่มเติมให้กับซอฟต์แวร์นั้น โดยจำกัดอยู่เพียงตัวเซิร์ฟเวอร์เองเท่านั้น ในทางกลับกัน
SSPL กำหนดเงื่อนไขว่า นอกจากโค้ดดังกล่าวแล้ว เมื่อให้บริการในรูปแบบ As-a-Service จะต้องเปิดเผยโค้ดของซอฟต์แวร์ทั้งหมดที่ผู้ให้บริการ As-a-Service ใช้งานด้วย ไม่ว่าจะเป็นซอฟต์แวร์สำหรับการจัดการ ส่วนติดต่อผู้ใช้ API ซอฟต์แวร์อัตโนมัติ ซอฟต์แวร์มอนิเตอร์ ซอฟต์แวร์สำรองข้อมูลและจัดเก็บข้อมูล เป็นต้น กล่าวอีกนัยหนึ่งคือ เมื่อผู้ให้บริการคลาวด์นำ MongoDB ไปให้บริการในรูปแบบบริการ ก็มีเงื่อนไขว่าต้องเปิดเผยซอร์สโค้ดของซอฟต์แวร์ทั้งหมดที่ตนสร้างขึ้นเพื่อรักษาความได้เปรียบในการแข่งขันของบริการตัวเองด้วย
ผมกะว่าจะลองหาข้อมูลเกี่ยวกับ MongoDB กับ Redis ด้วยเหมือนกัน... แต่ที่นี่อธิบายไว้ดีอยู่แล้วนี่นา!
เพิ่มเติม ถ้าดูไฟล์ PDF ก็มีคำอธิบายด้วยว่าส่วนไหนที่ไม่สอดคล้องกับ OSI โดยบอกว่าเป็นเรื่องการจำกัดเสรีภาพและข้อจำกัดต่อผลงานแยกต่างหาก
โอ้...โดยรวมแล้วเป็น PDF ที่เขียนได้ยอดเยี่ยมมากเลยนะครับ ขอบคุณสำหรับลิงก์ครับ
พอมาดูแบบนี้ก็เข้าใจความแตกต่างจาก AGPL และเหตุผลที่ไม่ยอมรับ SSPL ได้อยู่หรอก แต่ก็อดคิดไม่ได้ว่า OSI อาจจะเอนเอียงไปทางความเป็น permissive อยู่พอสมควรหรือเปล่า
สรุปประวัติทั้งหมดได้เป็นระเบียบดีมาก เลยอ่านได้สบาย ขอบคุณครับ!
ดูบทความที่เกี่ยวข้อง
https://th.news.hada.io/topic?id=3620 - AWS ประกาศแยก fork แบบโอเพนซอร์สของ Elasticsearch และ Kibana
https://th.news.hada.io/topic?id=3606 - Elastic เปลี่ยนไลเซนส์เพื่อไม่ให้ AWS ใช้งานได้