SSPL(Server Side Public License) นั้นแย่

เหตุผลที่ SSPL แย่

• SSPL(Server Side Public License) เป็นไลเซนส์ที่แย่มากสำหรับผู้ใช้ทุกคน บริษัททุกแห่ง และโดยทั่วไปสำหรับชุมชน
• ผลิตภัณฑ์ที่ใช้ไลเซนส์ SSPL ไม่ใช่โอเพนซอร์ส และมีเป้าหมายเพื่อ กำจัดคู่แข่ง ด้านคลาวด์และบริการแบบจัดการ ทำให้ ราคาการโฮสต์ สูงขึ้น และ ทำลาย โอเพนซอร์ส
• จุดประสงค์ของ SSPL อาจใกล้เคียงกับการคืนเงินให้นักลงทุนมากกว่าการต่อสู้กับบริษัทขนาดใหญ่

SSPL คืออะไร

• SSPL เป็นไลเซนส์ที่ MongoDB, Inc นำมาใช้ในปี 2008 เพื่อจำกัดการใช้งาน MongoDB
• ผลิตภัณฑ์อย่าง Elasticsearch, Kibana และ Graylog ก็ใช้ไลเซนส์ SSPL แล้วเช่นกัน
• ตามข้อ 13 หากต้องการให้บริการผลิตภัณฑ์แก่ลูกค้าโดยตรง จะต้องเปิดเผย "ซอร์สโค้ดของบริการ" ต่อสาธารณะ

เหตุใด SSPL จึงแย่สำหรับทุกคน

• SSPL ถูกนำเสนอว่าเป็นทางออกที่ดีในการป้องกันบริษัทคลาวด์บางแห่งที่เอาเปรียบชุมชนโดยไม่ตอบแทน แต่ในความเป็นจริงมันเป็นภัยคุกคามต่อเสรีภาพและเป็นไลเซนส์ที่ใช้กำจัดคู่แข่ง
• ไลเซนส์นี้เป็นเพียงการนำผลิตภัณฑ์ที่เคยเป็นโอเพนซอร์สไปขังไว้ในผลิตภัณฑ์เชิงพาณิชย์ โดยซ่อนอยู่หลังจิตวิญญาณจอมปลอมของคำว่า 'ฟรี' ตอนนี้ซอฟต์แวร์แบบนี้อาจควรถูกเรียกว่า "Freemium"
• MongoDB, Elasticsearch, Kibana และ Graylog ไม่ใช่ผลิตภัณฑ์โอเพนซอร์สอีกต่อไป และบริษัทเหล่านี้สามารถตัดสินใจได้อย่างเบ็ดเสร็จว่าใครบ้างที่สามารถนำเสนอผลิตภัณฑ์ให้ลูกค้าได้ นี่คือการกำจัดคู่แข่ง
• พวกเขาสามารถให้บริการโซลูชันคลาวด์โฮสติ้งของตนเองได้โดยไม่ต้องมีคู่แข่ง และสามารถทำลายการแข่งขันกับนวัตกรรมได้ด้วยค่าธรรมเนียมที่ตนกำหนด โดยไม่ต้องเปิดเผยซอร์สโค้ด
• สำหรับเราในฐานะลูกค้า สิ่งนี้หมายความว่าเราไม่มีอำนาจเลือกผู้ให้บริการคลาวด์ได้อีกต่อไป
• ในทางกลไก ราคาการโฮสต์จะสูงขึ้น และทางเลือกเดียวของเราคือมีทีมเฉพาะทางเพื่อจัดการส่วนการโฮสต์บนโครงสร้างพื้นฐานของเราเอง ซึ่งก็คือสิ่งที่เราพยายามหลีกเลี่ยงมาตลอดหลายปีด้วยโซลูชันคลาวด์โฮสติ้ง

บริษัทที่ใช้ SSPL

• ผลิตภัณฑ์ MongoDB ใช้ไลเซนส์ SSPL มาตั้งแต่ปี 2018 โดยมี MongoDB, Inc อยู่เบื้องหลัง
• ผลิตภัณฑ์ Elasticsearch ใช้ไลเซนส์ SSPL มาตั้งแต่ปี 2021 โดยมี Elastic NV อยู่เบื้องหลัง
• ผลิตภัณฑ์ Graylog ใช้ไลเซนส์ SSPL มาตั้งแต่ปี 2020 โดยมี GrayLog, Inc. อยู่เบื้องหลัง

คำถามบางข้อที่เราควรถามตัวเอง

• บริษัทที่ไม่ใช้งานโอเพนซอร์สอีกต่อไป จะไปเรียกร้องให้คนอื่น "ตอบแทนชุมชน" ได้อย่างไร?
• บริษัทที่ไม่เปิดเผยซอร์สโค้ดของบริการคลาวด์ของตัวเอง จะไปเรียกร้องให้คนอื่นเปิดเผยซอร์สโค้ดได้อย่างไร?
• บริษัทที่ใช้ไลเซนส์ไม่ใช่โอเพนซอร์ส แต่ประกาศว่าโอเพนซอร์สเป็นส่วนหนึ่งของ DNA ของตน จะทำเช่นนั้นได้อย่างไร?
• จากพนักงานกว่า 3,000 คน มีสักกี่คนที่แบ่งปันงานและซอร์สโค้ดของตนกับชุมชน? (สปอยเลอร์: น้อยกว่ามาก)
• นี่คือบริษัทเทคโนโลยีที่ต้องการแบ่งปันกับชุมชน หรือเป็นบริษัทขายของที่ต้องการเพิ่มผลตอบแทนให้นักลงทุน?

ข้ออ้างที่ผิดเกี่ยวกับ SSPL

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

คำแนะนำสำหรับโครงการโอเพนซอร์ส

• แม้ SSPL อาจดูเหมือนทางออกที่ดีในตอนแรก แต่ขอแนะนำว่าอย่าทำพลาดเช่นนั้น
• หากมีปัญหากับผู้ให้บริการคลาวด์บางราย เราไม่อาจเพิกเฉยได้ และเราทุกคนต้องร่วมกันต่อสู้ การออกไปสู้นอกโลกโอเพนซอร์สไม่ใช่วิธีที่ดี
• หากต้องการความสามารถในการทำกำไร ให้ใช้ไลเซนส์ระดับเอ็นเตอร์ไพรส์และการสนับสนุนระดับพรีเมียม: "ถ้าคุณต้องการการสนับสนุน เรามีทีมที่ดีที่สุดสำหรับเรื่องนี้"
• ใช้ไลเซนส์แบบ copyleft เพื่อให้บริษัทสามารถตอบแทนชุมชนได้: "หากคุณแก้ไขโค้ดของเรา โปรดแบ่งปันกับชุมชน"
• หากยังเลือกไลเซนส์ SSPL อยู่.. คุณจะ:
  • สูญเสียผู้มีส่วนร่วมอิสระจำนวนมากและผู้มีส่วนร่วมที่เป็นพนักงานบริษัทใหญ่
  • ทรยศต่อผู้มีส่วนร่วมที่พยายามปรับปรุงซอฟต์แวร์โอเพนซอร์ส
  • ออกจากโลกโอเพนซอร์สไปพัฒนาซอฟต์แวร์แบบ Freemium
  • ทำให้ผลิตภัณฑ์ของคุณเชื่อมโยงกับภาพลักษณ์เชิงลบอย่างมาก
  • สูญเสียประโยชน์จากผู้เล่นหลากหลายจำนวนมากที่ช่วยโปรโมตผลิตภัณฑ์ของคุณทั่วโลก ทำให้ความจำเป็นของการสนับสนุนระดับพรีเมียมเพิ่มขึ้น

[aer0700]

เป็นโอเพนซอร์สจึงเลือกใช้ได้ แต่ก็เป็นโอเพนซอร์สจึงมีบางครั้งที่ถูกตัดออกจากตัวเลือกเช่นกัน
น่าจะเป็นไลเซนส์ที่ออกมาเพราะ AWS เอา MongoDB ไปทำเป็น DynamoDB ซึ่งสำหรับคนที่ชอบโอเพนซอร์สพอมาเห็นก็อาจจะรู้สึกคาใจได้เหมือนกัน

[coremaker]

ถ้าเทียบกับ AGPL ด้วยก็น่าจะน่าสนใจดีนะครับ
https://sktelecom.github.io/guide/use/obligation/agpl-3.0/

[xguru]

ตามชื่อโดเมนและชื่อเว็บไซต์ SSPL is BAD เว็บไซต์นี้ถูกสร้างขึ้นด้วยเจตนาที่ชัดเจน
และก็มีการเหมารวมเกินจริงอยู่พอสมควร โปรดอ่านควบคู่ไปกับความคิดเห็นใน Hacker News ด้านล่าง

ความคิดเห็นใน Hacker News

• มีทั้งความเห็นคัดค้าน SSPL ในเชิงหลักการ และความเข้าใจต่อภูมิหลังของมันไปพร้อมกัน อีกทั้งยังมีคำวิจารณ์ว่าการอธิบายมาตรา 13 มีเจตนาเชิงหวือหวา มากกว่าจะเป็นการวิเคราะห์อย่างเป็นกลาง

  • MongoDB และ Elastic ไม่ได้คาดคิดว่า AWS จะนำผลิตภัณฑ์ของตนไปรีแพ็กเกจเป็นบริการและกลายเป็นคู่แข่ง ใบอนุญาต Apache ที่ Elasticsearch ใช้อยู่เปิดทางให้ทำเช่นนั้นได้ แต่ก็มีความเห็นว่าในเชิงจริยธรรมควรจะป้องกันไว้
  • มีข้อสังเกตว่า AWS อาจสร้างความสัมพันธ์แบบ 'win-win' ผ่านสัญญา OEM หรือพาร์ตเนอร์ชิปได้ แต่เมื่อไม่ทำเช่นนั้น จึงกระตุ้นให้เกิดการปิดกั้นในรูปแบบที่ไม่น่าพอใจอย่าง SSPL
  • แม้จะมีความไม่พอใจว่า SSPL ถูกสร้างขึ้นมาเพื่อเอาใจนักลงทุน แต่ก็มีความเห็นว่า ต่อให้เป็นซอฟต์แวร์โอเพนซอร์ส บริษัทก็ไม่ได้มีเป้าหมายแบบไม่แสวงหากำไรอยู่แล้ว จึงไม่เข้าใจว่าทำไมคนถึงตำหนิ Elastic หรือ MongoDB แต่ไม่ตำหนิ AWS

• มีข้อโต้แย้งว่า SSPL เป็นผลเสียต่อผู้ใช้ เพราะมันส่งเสริมการผูกขาดและลดการมีส่วนร่วมของชุมชน ซึ่งท้ายที่สุดจะกระทบผู้ใช้ทุกคน

• ผู้คนย่อมต้องการหารายได้เป็นเรื่องธรรมดา และเราก็เลือกได้ว่าจะไม่ใช้โครงการที่ใช้ SSPL อีกทั้งยังมีมุมมองว่า ซอฟต์แวร์ที่เผยแพร่ภายใต้ใบอนุญาต SSPL ก็ยังดีกว่าไม่มีซอฟต์แวร์นั้นเลย

• มีความเห็นว่าระบบนิเวศปัจจุบันต่างจากเมื่อ 10 ปีก่อนมาก และต้องการหนทางที่ทำให้บริษัทขนาดเล็กอยู่รอดและเติบโตในการแข่งขันได้ ใบอนุญาตอย่าง BSL (Business Source License) อาจไม่สมบูรณ์แบบ แต่ก็อาจมองได้ว่าเป็นความพยายามในการหาทางสายกลางที่เหมาะสม

• มีความเห็นว่า การวิจารณ์ SSPL โดยไม่กล่าวถึง AGPL เป็นเรื่องแปลก พร้อมทั้งชี้ไปที่คนที่อยากใช้ free software แต่ไม่อยากมีส่วนร่วมตอบแทน

• มีความเห็นว่าไม่ควรเอนเอียงไปฝ่ายใดฝ่ายหนึ่ง และควรพิจารณาเป็นกรณีไป SSPL อาจเป็นผลดีต่อบางบริษัทที่พยายามอยู่รอดท่ามกลางยักษ์ใหญ่คลาวด์ แต่ก็อาจเป็นผลเสียต่อบางบริษัทที่พยายามเอาเปรียบผู้มีส่วนร่วม

• มีการกล่าวว่าการนำเสนอผลิตภัณฑ์ MongoDB, Elasticsearch, Graylog ให้ลูกค้าโดยตรงนั้นเป็นสิ่งต้องห้าม คำว่า 'โดยตรง' ใน SSPL เปิดช่องให้เกิดข้อถกเถียงทางกฎหมาย และเป็นจุดที่ทำให้ผู้คนกังวล

• FSL (Functional Source License) เป็นใบอนุญาตทางเลือกที่ดี ซึ่งจะเปลี่ยนเป็น Apache 2.0 หรือ MIT โดยอัตโนมัติหลัง 2 ปี มีความเรียบง่าย เปิดเผยซอร์ส และให้แนวทางที่สมเหตุสมผลเพื่อให้บริษัท SaaS ดำเนินงานได้

• มีการแก้ไขข้อมูลที่ผิดว่ามีการนำ SSPL มาใช้ในปี 2008 โดยความจริงแล้วเริ่มใช้ในปี 2018

• มีคำวิจารณ์ต่อมุมมองแบบมิติเดียวเกี่ยวกับอนาคตของลิขสิทธิ์.