Redis ใช้ไลเซนส์แบบ dual source-available

 (redis.com)
2 คะแนน โดย GN⁺ 2024-03-22 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ตั้งแต่ Redis 7.4 เป็นต้นไป Redis จะยุติการแจกจ่ายภายใต้ BSD 3-Clause และจากนี้จะเผยแพร่ Redis ภายใต้ RSALv2 หรือ SSPLv1 ทำให้ขอบเขตด้านไลเซนส์เปลี่ยนไปอย่างมาก
  • ซอร์สโค้ดยังคงเปิดให้ใช้งานฟรีต่อไปในชื่อ Redis Community Edition แต่ไลเซนส์ใหม่นี้ ไม่เข้าข่ายโอเพนซอร์สตามนิยามของ OSI
  • Redis มีแผนรวม Core และ Stack เข้าด้วยกัน เพื่อนำ search, JSON, vector, probabilistic data structures และโมเดลข้อมูลแบบ time series มาไว้ในแพ็กเกจฟรีชุดเดียว
  • การใช้งานภายในหรือส่วนตัว, client library, พาร์ตเนอร์ด้าน integration และลูกค้า Redis Enterprise เดิมจะไม่ได้รับผลกระทบ แต่ บริการ managed service ที่แข่งขันกันโดยตรง จะไม่สามารถใช้ซอร์สโค้ด Redis ใหม่ได้ฟรี
  • ตั้งแต่ Redis 8 เป็นต้นไป ฟีเจอร์ของ Redis Stack จะถูกรวมเข้ามาใน Redis โดยตรง และหลังจากนั้นจะเข้าสู่กระบวนการ ยุติอายุการใช้งานของ Redis Stack build แบบแยก

ขอบเขตการเปลี่ยนแปลงไลเซนส์ของ Redis

  • Redis จะเผยแพร่ Redis เวอร์ชันใหม่ทั้งหมดต่อจากนี้ภายใต้ ไลเซนส์แบบ source-available
  • ตั้งแต่ Redis 7.4 เป็นต้นไป ซอฟต์แวร์ Redis Core สามารถใช้งานได้ภายใต้ Redis Source Available License v2 หรือ Server Side Public License v1 อย่างใดอย่างหนึ่ง
  • จะไม่มีการแจกจ่ายภายใต้ไลเซนส์ BSD 3-Clause อีกต่อไป
  • ซอร์สโค้ด Redis จะยังคงเปิดให้ใช้งานฟรีในชื่อ Redis Community Edition ผ่านทาง Redis GitHub repository
  • ทั้ง RSALv2 และ SSPLv1 ไม่ใช่ไลเซนส์ที่ OSI รับรอง และแต่ละแบบมีข้อจำกัดในการใช้งาน

การรวม Redis Stack และการเปลี่ยนแปลงด้านผลิตภัณฑ์

  • รีลีสแบบ source-available ในอนาคตจะรวม Redis Core และ Redis Stack เข้าด้วยกัน
  • สิ่งที่จะถูกรวมได้แก่ search, JSON, vector, probabilistic data structures และโมเดลข้อมูลแบบ time series
  • จะเปิดให้ดาวน์โหลดเป็นแพ็กเกจฟรีชุดเดียว โดย Redis สามารถใช้เป็น
    • คีย์/แวลูสโตร์ ประสิทธิภาพสูง
    • document store
    • query engine
    • ฐานข้อมูลเวกเตอร์ แบบ latency ต่ำสำหรับแอปพลิเคชัน generative AI
  • ตั้งแต่ Redis 8 เป็นต้นไป data type ใหม่และ processing engine ที่เคยแจกจ่ายใน Redis Stack ภายใต้ RSALv2 หรือ SSPLv1 จะถูกรวมเป็นส่วนหนึ่งของตัวหลักโดยค่าเริ่มต้น
  • หลังการเปิดตัว Redis 8 จะไม่จำเป็นต้องมี Redis Stack build แบบแยกอีกต่อไป และจะเริ่มกระบวนการ ยุติอายุการใช้งานของ Redis Stack

เบื้องหลังการเปลี่ยนแปลงและจุดยืนของ Redis

  • Redis ระบุว่าได้ใช้ ไลเซนส์แบบคู่ กับโมดูล Redis ระดับสูงในดิสทริบิวชัน Redis Stack อยู่ก่อนแล้ว และตั้งแต่ Redis 6 เป็นต้นมา มากกว่า 50% ของการดาวน์โหลดจาก redis.io มาจาก Redis Stack
  • Redis มองว่าโครงสร้างที่ต้องดูแลหลายดิสทริบิวชันพร้อมกันขัดกับการผลักดันการพัฒนาในอนาคต
    • ดิสทริบิวชันโอเพนซอร์ส
    • ดิสทริบิวชันแบบ source-available
    • ซอฟต์แวร์เชิงพาณิชย์ที่ปรับแต่งมาสำหรับแพลตฟอร์ม on-premise และคลาวด์
  • Redis มองว่าผู้ให้บริการคลาวด์รายใหญ่กำลังนำการลงทุนของ Redis และชุมชนโอเพนซอร์สไปทำเป็นสินค้า
  • การเปลี่ยนแปลงครั้งนี้เป็นมาตรการเพื่อ กำกับการใช้งานเชิงพาณิชย์ เพื่อให้ยังลงทุนต่อเนื่องได้ทั้งในซอฟต์แวร์ฟรีที่มีฟีเจอร์ครบถ้วนและผลิตภัณฑ์ระดับองค์กร
  • จากการเปลี่ยนแปลงนี้ Redis จะไม่ถือเป็นโอเพนซอร์สตาม นิยามของ OSI อีกต่อไป

ผลกระทบต่อผู้ใช้และพาร์ตเนอร์

  • ผู้ใช้ปลายทางที่ใช้ Redis เวอร์ชันโอเพนซอร์สเดิมหรือรีลีสแบบ dual-license ใหม่เพื่อ การใช้งานภายในหรือส่วนตัว จะไม่ได้รับผลกระทบ
  • พาร์ตเนอร์ที่สร้าง client library หรือ integration อื่น ๆ ที่เชื่อมกับ Redis ก็จะไม่มีอะไรเปลี่ยนแปลง
  • client library ของ Redis ทั้งหมดที่ Redis รับผิดชอบจะยังคงใช้ ไลเซนส์โอเพนซอร์ส ต่อไป
  • ลูกค้า Redis Enterprise เดิมจะไม่ได้รับผลกระทบ เพราะได้รับเทคโนโลยีภายใต้เงื่อนไขไลเซนส์ที่เจรจาไว้ต่างหาก
  • พาร์ตเนอร์ด้าน integration และ managed service ที่ใช้ Redis Community Edition หรือ Enterprise ในลักษณะที่ไม่แข่งขันโดยตรง ยังสามารถสร้าง ดำเนินงาน และให้บริการโซลูชันต่อไปได้ผ่านความร่วมมือกับ Redis
  • Partner Program จะเปิดให้เข้าถึงเทคโนโลยี ฟีเจอร์ และรีลีสของ Redis แบบพิเศษในอนาคต

ข้อจำกัดกับบริการคลาวด์และผลิตภัณฑ์ที่แข่งขันกัน

  • ภายใต้ไลเซนส์ใหม่ ผู้ให้บริการคลาวด์ ที่ให้บริการ Redis แบบโฮสต์จะไม่สามารถใช้ซอร์สโค้ด Redis ได้ฟรี
  • ตัวอย่างเช่น ผู้ให้บริการคลาวด์จะสามารถให้บริการ Redis 7.4 ได้ก็ต่อเมื่อมีการตกลงเงื่อนไขไลเซนส์กับ Redis ซึ่งเป็นผู้ดูแลโค้ด
  • “competitive offering” ตามนิยามของ Redis หมายถึงผลิตภัณฑ์ที่พัฒนาต่อยอดจาก codebase ของ Redis, มีฟีเจอร์ทับซ้อนกับผลิตภัณฑ์เชิงพาณิชย์ของ Redis อย่างมาก และนำไปขายให้บุคคลที่สาม
    • รวมถึงการขายผ่านสัญญาซัพพอร์ตแบบมีค่าใช้จ่าย
    • ตัวอย่างคือการโฮสต์หรือฝัง Redis ลงในโซลูชันที่ขายแข่งขันกับ Redis Enterprise Software หรือ Redis Cloud
  • โซลูชันที่ใช้ Redis แต่ไม่ได้แข่งขันกับตัว Redis โดยตรงจะไม่ได้รับผลกระทบ
  • กรณีสอบถามการใช้งานเฉพาะ Redis แนะนำให้ติดต่อ redis_licensing@redis.com

เงื่อนไขของ RSALv2 และ SSPLv1

  • RSALv2 เป็นไลเซนส์ลักษณะ permissive แบบไม่ใช่ copyleft โดยอนุญาตให้ใช้ คัดลอก แจกจ่าย ให้บริการ และสร้างงานดัดแปลงจากซอฟต์แวร์ได้
  • ข้อจำกัดหลักของ RSALv2 มี 2 ข้อ
    • ห้ามนำซอฟต์แวร์ไปทำเชิงพาณิชย์หรือให้บริการแก่ผู้อื่นในรูปแบบ managed service
    • ห้ามลบหรือปกปิดไลเซนส์ ลิขสิทธิ์ หรือประกาศอื่น ๆ
  • SSPLv1 มีพื้นฐานจาก AGPL และหากนำไปให้บริการเป็น service จะต้องเปิดเผยซอร์สโค้ดของทั้งบริการภายใต้ SSPL
    • รวมถึงซอฟต์แวร์สำหรับการจัดการ, user interface, API, ซอฟต์แวร์อัตโนมัติ, monitoring, backup, storage และ hosting software
    • MongoDB เป็นผู้ออกไลเซนส์นี้
  • เวอร์ชันดัดแปลงของซอฟต์แวร์ที่ใช้ไลเซนส์ SSPL ไม่สามารถนำไปแจกจ่ายซ้ำภายใต้ไลเซนส์อื่นได้
  • หากเลือกใช้ RSALv2 ในระบบไลเซนส์คู่ ก็สามารถแก้ไขและแจกจ่ายซ้ำได้ภายในขอบเขตที่ปฏิบัติตามข้อจำกัดของ RSALv2 เช่น ไม่ให้ฟังก์ชันดังกล่าวเป็นบริการแก่บุคคลที่สาม

เวอร์ชัน BSD เดิมและแพตช์ความปลอดภัย

  • การเปลี่ยนแปลงไลเซนส์ ไม่มีผลย้อนหลัง
  • ซอร์สโค้ดและรีลีสทั้งหมดก่อนการเปลี่ยนแปลงจะยังคงอยู่ภายใต้ไลเซนส์ BSD 3-Clause
  • ผู้ใช้ยังสามารถใช้งานเวอร์ชัน BSD เดิมต่อไปได้ไม่มีกำหนด ตราบใดที่ปฏิบัติตามเงื่อนไขของไลเซนส์ดังกล่าว
  • Redis วางแผนจะให้ security update และการแก้ไขบั๊กสำคัญสำหรับรีลีสเหล่านั้นต่อไปตาม นโยบายความปลอดภัย ที่ใช้อยู่ จนกว่า Redis Community Edition จะเปิดให้ใช้งาน
  • การ backport แพตช์ความปลอดภัยสำคัญสำหรับเวอร์ชัน BSD 3-Clause เดิมจะมีให้จนก่อน Redis Community Edition 9.0 ออก และหลังจากนั้นแพตช์จะเผยแพร่ภายใต้ไลเซนส์คู่แบบใหม่

ชื่อ การมีส่วนร่วม และเงื่อนไขการผสมโค้ด

  • Redis 7.2 และรีลีสก่อนหน้านั้นจะยังคงถูกเรียกว่า Redis OSS
  • ตั้งแต่ Redis 7.4 เป็นต้นไป เวอร์ชันที่เปิดเผยสู่สาธารณะและให้ใช้ฟรีจะถูกเรียกว่า Redis Community Edition
  • จะไม่สามารถใช้คำว่า “Redis” หรือ “for Redis” ในชื่อผลิตภัณฑ์ได้อีก แต่ยังสามารถระบุในคำอธิบายผลิตภัณฑ์ได้ว่าเข้ากันได้กับ Redis หรืออิงจาก legacy-Redis
  • ยังคงรับ contribution จากชุมชนต่อไป แต่การพิจารณา contribution จำเป็นต้องยอมรับ Contributor License Agreement
  • โค้ดภายใต้ RSALv2 หรือ SSPLv1 และโค้ดภายใต้ไลเซนส์อื่นสามารถใช้งานร่วมกันได้ ตราบใดที่แต่ละคอมโพเนนต์ยังคงรักษาไลเซนส์ของตัวเอง และไม่ผสมกับโค้ด strong copyleft อย่าง GPL
  • องค์กรสามารถโฮสต์ Redis เป็นบริการภายในองค์กรได้ ซึ่งคำว่าองค์กรนี้รวมถึงบริษัทในเครือและบริษัทย่อยด้วย

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-03-22
ความเห็นจาก Hacker News

  • เรื่องนี้น่าจะมีโอกาสสูงที่จะทำให้ Redis Labs พังเหมือนที่ Hashicorp กำลังเสียแรงส่งและหาคนมาซื้อกิจการอยู่ และก็คงไม่ได้ช่วยหยุดคนที่อยากลอกแบบ Redis Labs ด้วย
    คนที่เจ็บจริงคือสตาร์ตอัปเล็ก ๆ ที่แค่อยากใช้ Redis cache โดยไม่ต้องปวดหัวเรื่องกฎหมาย. AWS สามารถ fork Redis ได้ และถ้ายังปล่อย fork นั้นภายใต้ไลเซนส์แบบ permissive อีก ฝั่ง Redis Labs เองอาจกลายเป็นตัวเลือกที่แย่กว่าในแง่ไลเซนส์เสียด้วยซ้ำ
    มันเป็นทางเลือกที่ยาก แต่ผมคิดว่าควรจะเก็บโค้ดไว้แบบปิดไปเลย หรือไม่ก็ยึด Apache หรือ MIT ต่อไปจะดีกว่า. การเปลี่ยนไลเซนส์กลางทางนี่แย่มาก และดูเหมือนถูกกำหนดมาให้ย้อนศรเสียมากกว่า
    โอเพนซอร์สคือการทำให้ผู้ใช้เป็นเจ้าของซอฟต์แวร์ได้. ถ้าพยายามเลี่ยงสิ่งนี้ด้วยลูกเล่นทางกฎหมายเพื่อหารายได้ คนที่เจ็บจะไม่ใช่ทีมในบริษัทยักษ์ใหญ่ แต่เป็นผู้ใช้. Redis เป็นโปรเจกต์โอเพนซอร์สแบบ permissive มาโดยตลอด และนั่นเองคือเหตุผลที่มันประสบความสำเร็จ. ถ้าเปลี่ยนเงื่อนไขนั้น สมการต่อจากนี้ก็เปลี่ยนไป และเป็นสัญญาณถึงผลลัพธ์ที่ไม่ดีสำหรับทุกฝ่ายที่เกี่ยวข้อง

    • เรื่องนี้ในระยะยาวดูเหมือนจะเกือบทำลายความคิดที่ว่า บริษัทสามารถเป็นผู้ดูแลความต้องการของผู้ใช้โอเพนซอร์สได้อย่างดี ไปเลย
      เราควรมองความต่างระหว่าง ซอฟต์แวร์ที่มูลนิธิเป็นเจ้าของ แบบ PostgreSQL กับโอเพนซอร์สที่บริษัทเป็นเจ้าของให้ชัดขึ้น. เมื่อโฟกัสอยู่ที่ “การเพิ่มมูลค่าสูงสุดให้ผู้ถือหุ้น” เป้าหมายในการปกป้องเสรีภาพของผู้ใช้ก็เลี่ยงไม่ได้ที่จะถูกดันไปไว้ข้างหลัง
      ในมุมของชุมชน Redis คงจะดีกว่ามากถ้า Antirez แยกความสัมพันธ์ด้านการจ้างงานออกจากความเป็นเจ้าของโปรเจกต์ แล้วมอบส่วนหลังให้กับองค์กรไม่แสวงกำไรดูแล. รูปแบบอย่าง Apache Redis น่าจะดีกับชุมชนมากกว่า และ Redis Labs เองก็ยังสามารถสร้างส่วนขยายแบบ proprietary กับธุรกิจคลาวด์รอบ ๆ มันได้
    • พอเวลาผ่านไป ผมก็เริ่มเห็นด้วยกับมุมมองนี้ และสรุปได้ว่า: ถ้าเป้าหมายคือ กำไร ก็อย่าโอเพนซอร์สผลิตภัณฑ์หลัก
      เราเห็นซ้ำแล้วซ้ำอีกว่าเมื่อบริษัทปล่อยซอฟต์แวร์หลักออกมาภายใต้ไลเซนส์แบบ permissive คู่แข่งที่ใหญ่กว่าก็จะเข้ามาขายโซลูชันที่แจกจ่ายซอฟต์แวร์นั้นต่อ
      ถ้าเป้าหมายหลักของบริษัทคือกำไร นี่คือภัยคุกคามต่อการอยู่รอด. แต่ถ้าเป้าหมายของบริษัทคือทำหน้าที่เป็นผู้ดูแลแบบไม่แสวงกำไรเพื่อให้ซอฟต์แวร์ดำรงอยู่ต่อไป นี่ถือเป็นความสำเร็จครั้งใหญ่
      ตรรกะนี้ไม่จำเป็นต้องใช้กับซอฟต์แวร์เสริมที่ไม่ใช่ผลิตภัณฑ์หลัก เช่นเครื่องมือมีประโยชน์ที่สร้างขึ้นระหว่างการพัฒนา ซึ่งไม่ได้เป็นสิ่งที่นำไปขายโดยตรงเพื่อหารายได้
    • โอเพนซอร์สมีปัญหาแบบ “พวกคุณเป็นคนสร้าง แล้วเราเอาไปขาย ขอบคุณนะ” อยู่
      การเปลี่ยนไลเซนส์ครั้งนี้ก็เพื่อจัดการปัญหานั้นโดยตรง กล่าวคือเพื่อไม่ให้ บริษัทยักษ์ใหญ่คลาวด์ มาเกาะกินฟรี
      สำหรับผม มันฟังดูเหมือน AGPL ที่ดีกว่า. ผมไม่สนใจนัยเชิงปรัชญาหรือรายชื่อไลเซนส์ที่ OSI รับรองนัก และสุดท้ายมันก็มีข้อจำกัดน้อยกว่า AGPL มาก. มีซอร์สโค้ด, รันในเครื่องตัวเองได้, และใช้กับโปรเจกต์ส่วนตัวกับโปรเจกต์เชิงพาณิชย์, ที่ทำงาน, bare metal, VM, Docker, k8s, Azure ได้ในแบบเดียวกัน
      เรื่องที่ Microsoft ต้องแบ่งส่วนหนึ่งของ premium ที่ตัวเองได้อยู่แล้วนั้นไม่เกี่ยวอะไรกับผม. ตรงกันข้าม ผมว่าการหาธุรกิจโมเดลที่ยั่งยืนได้นี่น่าปรบมือให้ด้วยซ้ำ
    • คำพูดที่ว่า “โอเพนซอร์สคือความเป็นเจ้าของซอฟต์แวร์ของผู้ใช้” นั้นไม่ถูกต้อง
      นักพัฒนา OSS เป็นผู้ถือครองลิขสิทธิ์. นอกจากกรณี public domain แล้ว คนเดียวที่เปลี่ยนไลเซนส์และเงื่อนไขได้ก็คือผู้เขียน. ผู้ใช้เพียงได้รับไลเซนส์ที่อนุญาตให้ทำสิ่งต่าง ๆ กับซอฟต์แวร์และโค้ดได้ ไม่ได้ได้สิทธิความเป็นเจ้าของ
    • คำว่า “เลี่ยงด้วยลูกเล่นทางกฎหมายเพื่อหารายได้” ทำให้นึกถึง enshittification
      เห็นด้วยเต็มที่ และรู้สึกเหมือนเป็นอีกหนึ่งตัวอย่างที่เสริมข้อถกเถียงของ Cory Doctorow

  • ตอนนี้ก็น่าจะมีการ fork กันไปแล้ว ดูแล้วก็เศร้านิดหน่อยที่เห็นบริษัทตัดขาดตัวเองจาก ชุมชนนักพัฒนา ของตัวเอง
    เข้าใจนะว่าทำไมถึงทำแบบนี้ แต่ไม่คิดว่าในระยะยาวมันจะเวิร์ก
    ผู้ใช้ Redis ส่วนใหญ่ไม่เคยจ่ายเงินให้บริษัทที่อยู่เบื้องหลังเลยสักบาท ผมก็เหมือนกัน เข้าใจว่าทำไปเพื่อหารายได้ แต่การกระทำของผมคงไม่เปลี่ยน ผมก็จะใช้ fork ต่อไป และผู้ใช้ Redis ส่วนใหญ่รายอื่น ๆ, ผู้ร่วมพัฒนาจากภายนอก, รวมถึงผู้ให้บริการคลาวด์ทั้งหมดที่เคยให้ Redis แบบเชิงพาณิชย์ ก็น่าจะทำแบบเดียวกัน และเมื่อเวลาผ่านไป พนักงาน Redis ปัจจุบันจำนวนไม่น้อยก็อาจย้ายไปฝั่งนั้นด้วย
    เพราะมีทั้งผู้ใช้เชิงพาณิชย์และผู้ให้บริการคลาวด์จำนวนมาก เลยไม่น่านานนักกว่าคนกลุ่มนี้จะรวมตัวกันได้ ที่จริงก็ดูแทบจะหลีกเลี่ยงไม่ได้อยู่แล้ว เพราะมีผู้ใช้ที่จ่ายเงินอยู่มากพอ
    ก็มีตัวอย่างคล้ายกันมาก่อนแล้วใน Terraform, Elasticsearch, Red Hat ฯลฯ การทำให้ผู้ใช้เป้าหมายและลูกค้าที่อาจเป็นลูกค้าในอนาคตจำนวนมากต้องไปพึ่งพาโอเพนซอร์ส fork ดูเป็นทิศทางที่ผิดในเชิงกลยุทธ์ธุรกิจ
    ตอนที่ Oracle เข้าครอบครองโปรเจกต์โอเพนซอร์สของ Sun อย่าง mysql, hudson, openoffice เป็นต้น ก็สูญเสียการควบคุมไปเกือบทั้งหมดอย่างรวดเร็ว ความพยายามจะโน้มน้าวให้คนไปใช้ผลิตภัณฑ์ปิดของ Oracle ก็แทบไม่ประสบผล แม้แต่ Java เองสุดท้ายก็ยังต้องถอยอยู่บ้าง และทุกวันนี้ศูนย์กลางก็คือ openjdk ยกเว้นธนาคารไม่กี่แห่ง แทบไม่มีใครใช้ Oracle JDK แล้ว เพราะมันไม่จำเป็น และ Oracle เองก็เลิกแสร้งว่ามันมีข้อดีมานานแล้ว การพัฒนาทั้งหมดเกิดขึ้นใน OpenJDK และก็มีหลายบริษัทที่ให้บริการ certified build
    ส่วนตัวผมทำที่ปรึกษา Elasticsearch และ Opensearch อยู่ และลูกค้าส่วนใหญ่ช่วงหลังตั้ง Opensearch เป็นค่าเริ่มต้นไปแล้ว มันก็ไหลไปทางนั้นเอง ทุกคนเลือกตัวเลือกที่ฟรีและเป็นโอเพนซอร์ส
    สรุปมีอยู่ข้อเดียว คือจะมี Redis fork ที่ผู้ใช้ Redis ส่วนใหญ่ในปัจจุบันจะหันไปใช้

    • Microsoft เพิ่งออก ตัวแทนที่ใช้แทนกันได้แทบจะทันที มาเมื่อ 3 วันก่อน[1] โดยอ้างว่าทำงานร่วมกับ Redis client ส่วนใหญ่ได้ อย่างน้อยสำหรับผู้ใช้ Azure ก็น่าจะเป็นความเปลี่ยนแปลงครั้งใหญ่พอสมควร
      [1] https://www.microsoft.com/en-us/research/blog/introducing-ga...
    • ถ้ามองแบบ มุมมองสไตล์ Broadcom กลยุทธ์ระยะยาวนี้อาจใช้ได้ คือไม่ได้มุ่งจับผู้ใช้จำนวนมาก แต่เล็งลูกค้าจำนวนน้อยที่ยอมจ่ายแพงมากและสร้างระบบของตัวเองอยู่บนผลิตภัณฑ์นี้
      ในมุมขององค์กร อาจยอมรับการขึ้นราคาเพื่อหลีกเลี่ยงการย้ายออกทั้งหมด หรืออย่างน้อยก็ในช่วงที่กำลัง migrate ระยะสั้น
      ถ้าจะกันไม่ให้ลูกค้าหนีในระยะสั้น ผู้ให้บริการก็อาจ “ซื้อเวลา” ด้วยการตั้งราคาต่ำไว้ก่อน แล้วค่อยขึ้นราคาเมื่อโปรเจกต์เริ่มแตกต่างจาก fork มากพอจนย้ายออกได้ยากขึ้นมาก
      ไม่ว่าทางไหน ในระยะยาวก็อาจทำเงินก้อนใหญ่จากลูกค้าองค์กรไม่กี่รายได้ มากกว่าจะต้องคอยรองรับบริษัทจำนวนมากหลากหลายขนาด ถึงจะไม่ชอบนัก แต่ก็ดูเหมือนอาจใช้ได้จริง
    • มี fork ที่เริ่มแล้วอยู่แล้ว: https://codeberg.org/redict/redict
    • ในระยะยาว FOSS อาจถูกมองว่าเป็นเพียงกระแสช่วงหนึ่งของอุตสาหกรรม และอาจไม่เกิดซ้ำอีก โดยวงการอาจกลับไปลงเอยกับ รุ่นทดลองใช้และเดโม ที่ไม่มีฟีเจอร์ครบทั้งใน free tier หรือในซอร์สโค้ด
    • มองแบบประชดหน่อย Oracle เองก็ไม่จำเป็นต้องทำให้ MySQL กลายเป็นแหล่งรายได้หลักอยู่แล้ว เพราะมีทางเลือกที่แพงกว่ามากอยู่ก่อนแล้ว
      แค่ทำให้ชุมชน MySQL แตกออก ลดแรงจูงใจในการใช้งานและการพัฒนาจากภายนอก และทำให้โปรเจกต์โดยรวมช้าลง ก็อาจให้ผลตอบแทนจากการลงทุนที่ดีได้แล้ว

  • แรงขับใหญ่ของโปรเจกต์พวกนี้ก็คือ รายได้จากการโฮสต์ อยู่ดี และนั่นแหละคือเหตุผลที่เกิดการเปลี่ยนไลเซนส์
    ดูจากแนวโน้มแล้ว โอเพนซอร์สที่เข้ากับบริษัทเจ้าของโปรเจกต์จริง ๆ ดูจะเหลือแค่พวกไลบรารีเท่านั้น ถ้าเป็นโปรแกรม เช่น ซอฟต์แวร์ฝั่งเซิร์ฟเวอร์อย่างฐานข้อมูล ก็น่าจะต้องเป็นแบบ source-available หรือไม่ก็อยู่ภายใต้องค์กรประเภท foundation มันยาก และผมก็ไม่รู้ว่าคำตอบคืออะไร
    อยากเห็นโมเดลที่ทำให้ไลเซนส์โอเพนซอร์สแบบ permissive กลับมาใช้ได้อีกครั้งกับโปรแกรมที่ซับซ้อน แต่ตอนนี้ยังไม่เห็นวิธีที่ใช้ได้จริง อาจจะเป็นการบังคับใช้สิทธิในเครื่องหมายการค้า ควบคู่กับโอเพนซอร์สโค้ด และให้เฉพาะ build ที่มีไลเซนส์เท่านั้น
    ไม่ว่าอย่างไร ต่อจากนี้เราก็คงยังได้เห็นการเกิดขึ้นและการล่มสลายของซอฟต์แวร์โอเพนซอร์สยอดนิยม หรือไม่ก็การเปลี่ยนไลเซนส์ต่อไป แรงจูงใจให้ทั้งนักพัฒนาและบริษัทเริ่มต้นแบบโอเพนซอร์สนั้นสูงมาก และแรงกดดันให้เปลี่ยนในภายหลังก็มากไม่แพ้กัน
    อย่างน้อยผมก็อยากยอมรับว่า Redis ได้มอบคุณค่าให้โลกมากกว่าสิ่งที่มันดึงกลับไปอย่างมหาศาล ช่องว่างนั้นใหญ่แบบท่วมท้นจริง ๆ
    น่าสนใจว่าจะมี fork ออกมาเร็วแค่ไหนและจะสำเร็จไหม รวมถึงอีก 5 ปีข้างหน้าเส้นโค้งการเติบโตของรายได้ของบริษัท Redis จะเป็นอย่างไร

    • ท้ายที่สุดแล้วมันก็คือโครงสร้างที่ผู้ให้บริการคลาวด์รายยักษ์มากินส่วนแบ่งของบริษัทอย่าง Redis ใช่ไหม
      เรื่องไลเซนส์ผมอาจไม่ได้รู้มาก แต่ผมเห็นด้วยมากกับภาพที่บริษัทขนาดกลางถึงเล็กซึ่งสร้าง เทคโนโลยีพื้นฐาน ถูกยักษ์คลาวด์ที่มีอำนาจตลาดสูงทำให้กลายเป็นสินค้าโภคภัณฑ์แล้วเอาไปขายต่อในราคาสูง เสียอีกที่แปลกใจว่าทำไมกว่าจะเกิดเรื่องนี้ถึงใช้เวลานานขนาดนี้
      ถ้าทั้งภาคธุรกิจและโอเพนซอร์สต่างก็ต้องการ ecosystem ที่แข็งแรง ผมก็สงสัยว่ามีทางเลือกอื่นนอกจากการเปลี่ยนไลเซนส์ไหม
    • ผมไม่ได้มองว่า foundation เป็นทางแก้ปัญหาแบบวิเศษอะไร
      มีหลายกรณีที่บริษัทเดียวตัดสินใจ “fork” ออกไปอยู่นอก foundation ในทางปฏิบัติ และสุดท้ายชุมชนก็เจอผลลัพธ์แบบเดิมอยู่ดี
    • ถ้าพูดถึง “ไลเซนส์โอเพนซอร์สแบบ permissive สำหรับโปรแกรมที่ซับซ้อน” หมายถึง AGPL3 อะไรทำนองนั้นหรือ?
      https://spdx.org/licenses/AGPL-3.0-or-later.html
    • น่าจะช่วยได้ถ้ายอมรับว่านักพัฒนาก็ไม่ได้ต่างจากคนทำวิชาชีพอื่นเท่าไร คือคาดหวังค่าตอบแทนจากงานของตัวเอง แต่กลับไม่อยากจ่ายสักบาทให้คนที่สร้าง เครื่องมือทำงาน ของพวกเขาเอง ทัศนคติแบบนี้คงอยู่ต่อไปไม่ได้
      คนที่สร้างเครื่องมือทำงานก็ต้องจ่ายบิลเหมือนกัน
      ในความหมายหนึ่ง ความฝันของ FOSS ที่ล้มเหลว นักพัฒนาเองก็มีส่วนต้องรับผิดชอบด้วย
      เรากำลังค่อย ๆ ย้อนกลับไปสู่ยุค public domain และ shareware
    • การ “ให้เฉพาะ build ที่มีไลเซนส์บนโค้ดโอเพนซอร์ส” นั้นไม่ใช่โอเพนซอร์ส

  • หลายคนพูดมาตลอดว่าโมเดลทำเงินจากโอเพนซอร์สคือ บริการซัพพอร์ต ตัวอย่างเช่น ถ้าบริษัทไหนใช้ Postgres ก็จะมีผู้เชี่ยวชาญช่วยดูแลการติดตั้งแบบ on-premises และช่วยดับปัญหาเมื่อระบบล่ม
    แต่ในยุค “คลาวด์” บริษัทต่าง ๆ ก็แค่ใช้บริการแบบ managed service ที่ Amazon, Microsoft, Google และรายอื่น ๆ ให้มา โอกาสทางการเงินของผู้ดูแลโครงการและคนรอบข้างจึงแทบหายไปหมด ไม่มีใครอยากทุ่มทำงานหนักให้ OSS แล้วเห็น AWS ทำเงินไปหลายล้านดอลลาร์โดยไม่ตอบแทนอะไรกลับมาเลย

    • เปิดเผยข้อมูล: ฉันทำงานที่ Amazon แต่ไม่ได้เกี่ยวข้องโดยตรงกับบริการคลาวด์ที่เกี่ยวกับ Redis ฉันใกล้ชิดกับฝ่าย open source program office และให้ความสำคัญมากกับคนที่ทำงานหนักซึ่งจำเป็นต่อการทำงานร่วมกันในโครงการโอเพนซอร์ส
      Madelyn Olson ทำงานหนักมาหลายปีในขณะที่เป็นพนักงานของ AWS จนได้รับความไว้วางใจจากนักพัฒนาแกนหลักของ Redis คนอื่น ๆ และกลายเป็นผู้ดูแลหลัก เธอและนักพัฒนาจาก AWS คนอื่น ๆ มีส่วนร่วมกับ Redis core engine อย่างมาก พูดได้ว่าพวกเขาเองก็ทำงานอย่างหนักเพื่อชุมชน Redis เช่นกัน
      อ่านเพิ่มเติมเกี่ยวกับผลงานที่เกี่ยวข้องได้ที่นี่: https://aws.amazon.com/blogs/opensource/behind-the-scenes-on...

  • โครงการโอเพนซอร์สควรทดลองใช้ SSPL ให้มากขึ้น หรือใช้แนวทางแบบ Llama 2 ที่จำกัดขนาดบริษัทที่สามารถใช้งานได้ฟรี ตัวอย่างเช่น เป็นโอเพนซอร์ส แต่ไม่ครอบคลุมถึงบริษัทคลาวด์ยักษ์ใหญ่ระดับหลายพันล้านดอลลาร์
    ตอนที่นักพัฒนาอิสระเข้ามามีส่วนร่วม พวกเขาไม่ได้ตั้งใจจะเปิดทางให้ AWS มาเกาะกินฟรี
    เหตุผลใหญ่ที่สุดที่โครงการต่าง ๆ ถูกผลักให้ไปสู่ไลเซนส์ที่เข้มงวดขึ้นก็คือ AWS สิ่งที่ AWS ควรทำอย่างถูกต้องคือเคารพงานของผู้เขียนต้นฉบับหรือบริษัทต้นทาง และช่วยส่งเสริมผลิตภัณฑ์ที่นักพัฒนาต้นทางสนับสนุน แต่ AWS กลับเห็นผลิตภัณฑ์ OSS ประสบความสำเร็จแล้วก็สร้างสินค้ามาแข่ง ด้วยการผสานรวมที่แน่นกว่าและพลังด้านการตลาด ผู้ขายภายนอกจึงแทบไม่มีทางชนะ
    ยิ่งไปกว่านั้น Amazon และ AWS เป็นผู้ได้รับประโยชน์รายใหญ่จากโอเพนซอร์ส อาจจะใหญ่ที่สุดด้วยซ้ำ แต่แทบไม่ตอบแทนอะไรกลับคืนมาเลย Google, Microsoft แม้กระทั่ง Oracle ก็ยังมีส่วนร่วมกับโอเพนซอร์สมากกว่า Amazon

    • SSPL กับ AGPL ก็พอรับได้ แต่มีเงื่อนไขว่าต้องไม่มี CLA ที่บังคับให้ฉันโอนสิทธิ์ของตัวเองให้คนอื่น
      ฉันไม่เคยมีส่วนร่วมกับโครงการที่มี CLA และถ้านายจ้างไม่จ่ายเงินให้ ก็ไม่ได้คิดจะทำในอนาคตด้วย
    • ก่อนหน้านี้ฉันเคยเสนอ FOSS license ที่ห้ามไม่ให้ AI เขียนโค้ด ได้รับเสียงตอบรับด้านลบมาก เพราะมันใส่ข้อจำกัดจึงไม่ใช่ FOSS เช่นเดียวกับ SSPL
      แต่เพื่อให้ FOSS อยู่รอดได้ในระยะยาว เราอาจจำเป็นต้องมีข้อจำกัดบางอย่างเพื่อปกป้องตัวเองจากบริษัทยักษ์ใหญ่ที่เอาเปรียบนักพัฒนา FOSS อย่างเป็นระบบ
    • แต่อย่าลืมว่า AWS ก็เป็นหนึ่งในเหตุผลใหญ่ที่ทำให้หลายโครงการ OSS กลายเป็นที่นิยม
      Redis, Mongo, ES, ชุดผลิตภัณฑ์ HashiCorp และทั้งระบบนิเวศบิ๊กดาต้าล้วนเป็นที่รู้จักกว้างขวางขึ้นผ่านการให้บริการของ AWS ยังมีฐานข้อมูลที่ไม่ค่อยมีคนรู้จักอีกมากที่พัฒนามาหลายปี แต่คนยังไม่รู้จักเพราะ AWS หรือผู้ให้บริการคลาวด์รายใหญ่รายอื่นไม่ได้ช่วยผลักดัน
      อีกทั้งเมื่อมีไลเซนส์เสรี การใช้งานและความนิยมก็เพิ่มขึ้น ทำให้หลายโครงการได้รับการมีส่วนร่วม เช่น รายงานบั๊ก, PR และแพตช์ ฉันไม่ค่อยอยากมีส่วนร่วมกับสิ่งที่ใช้ไลเซนส์ตระกูล SSPL หรือ BSL เพราะไม่อยากเสียเวลาไปกับสิ่งที่ภายหลังจะใช้อย่างเสรีไม่ได้
    • กำลังลืมไปว่า Redis เติบโตมาได้ก็เพราะมันเป็น ทั้งฟรีและเปิดกว้าง
      ถ้า Redis เปิดตัวมาตั้งแต่แรกพร้อมข้อจำกัดแบบเดียวกับ Llama 2 มันคงล้มเหลวตั้งแต่ต้น ผู้ใช้หลักคือภาคธุรกิจ และเหตุผลสำคัญที่ Llama 2 ได้รับความนิยมก็คือมันเป็น LLM คุณภาพสูงที่เปิดให้บุคคลทั่วไปใช้เพื่อการใช้งานส่วนตัวได้ตั้งแต่เนิ่น ๆ
      คีย์แวลูสโตร์ที่เข้ากันได้กับ RESP ไม่ใช่อะไรที่พิเศษมาก Microsoft เพิ่งออก garnet ซึ่งเป็น implementation ของตัวเองภายใต้ MIT license มาด้วยซ้ำ คุณค่าของ Redis คือการเป็นซอฟต์แวร์ฟรีและโอเพนซอร์สมาโดยตลอด รวมถึงชุมชนที่ค้ำจุนสิ่งนั้นไว้ ตอนนี้เท่ากับว่าทิ้งเหตุผลที่ใหญ่ที่สุดในการใช้ Redis ไปแล้ว
    • บางกรณี AWS ก็สนับสนุนฝั่งนักพัฒนาต้นทางเหมือนกัน managed Grafana และ Prometheus ทำร่วมกับ Grafana Labs
      แต่เท่าที่ฉันรู้ นั่นแทบจะเป็นกรณีเดียว ส่วน MongoDB, Redis, Memcached, MySQL, PgSQL และแทบทุกกรณีอื่นไม่เป็นแบบนั้น

  • Redis Inc. กำลังย้ายโครงการ https://github.com/redis/redis/ จาก 3-clause BSD license ไปเป็น dual license ภายใต้ไลเซนส์สองตัวที่ไม่ได้รับการรับรองจาก OSI
    ก่อนหน้านี้เคยบอกไว้ว่า “Redis core license ได้รับอนุญาตภายใต้ 3-Clause-BSD และจะเป็นเช่นนั้นตลอดไป” (https://redis.com/blog/redis-labs-modules-license-changes/)

    • นี่คือผลลัพธ์เมื่อบริษัทที่นำโอเพนซอร์สไปใช้ ไม่ใช่คนที่พัฒนาโครงการโอเพนซอร์ส ถูกควบคุมโดยซีอีโอสาย MBA

  • หากกังวลเรื่องการสิ้นสุดการซัพพอร์ต Redis 7.4 จะเป็นรีลีสแรกภายใต้ไลเซนส์ใหม่ และ 7.2 จะเป็นรีลีสสุดท้ายภายใต้ไลเซนส์เดิม
    Redis รองรับรีลีสเพิ่มเติม 2 ชุดในช่วงเวลาใดเวลาหนึ่ง: latest major.(minor-1), (major-1).(last-minor)
    โดยคร่าว ๆ หมายความว่าเมื่อ 8.0 ออกมา การซัพพอร์ต 6.2 จะสิ้นสุด และเมื่อ 7.6 หรือ 8.0 ออกมา การซัพพอร์ต 7.2 ก็จะสิ้นสุด
    เมื่อดูจากรีลีสที่ผ่านมา คาดว่า 8.0 น่าจะออกมาราวเดือนมีนาคม~พฤษภาคม 2025 ดังนั้นหากพึ่งพา Redis ภายใต้ ไลเซนส์ 3BSD ก็ควรวางแผนให้สอดคล้องกับเรื่องนี้
    Ubuntu แพ็กเกจ redis ไว้ในคลัง universe ดังนั้นการอัปเกรดด้านความปลอดภัยจะมีให้เฉพาะลูกค้า Ubuntu Pro เท่านั้น ดังนั้นสำหรับ Ubuntu 20.04 การอัปเกรด redis จะหยุดในเดือนเมษายน 2024 ยกเว้นผู้ใช้ ESM ของ Ubuntu Pro
    Debian 11/12 ใช้ Redis 6.0/7.0 จึงมีหน้าที่ต้อง backport แพตช์ของ 7.2 หาก 7.2 ไม่ได้รับอัปเดตความปลอดภัยและมีให้เฉพาะบน branch 7.4 ก็ยังไม่แน่ชัดว่าจะเป็นอย่างไร
    แม้วิธีใช้งานโดยตรงของคุณจะเข้ากับไลเซนส์ใหม่ได้ คุณก็อาจได้รับผลกระทบทางอ้อมได้เช่นกัน เพราะมีความเป็นไปได้สูงที่ดิสทริบิวชันจะถอด redis ออกจากคลังทางการในรีลีสถัดไป จึงควรคำนึงถึงเรื่องนี้ในรอบการอัปเกรดดิสทริบิวชันครั้งถัดไป
    (ฉันดูแล https://endoflife.date/redis อยู่ ดังนั้นถ้าใครทราบชัดเจนว่าการสิ้นสุดการซัพพอร์ตและการซัพพอร์ตจะได้รับผลอย่างไร ก็พร้อมจะ merge PR)

  • อย่างน้อยไลเซนส์ใหม่อย่าง SSPL ก็น่าจะไม่ใช่โอเพนซอร์ส เพราะมี ข้อจำกัดด้านการใช้งาน: https://opensource.stackexchange.com/questions/7522/sspl-and... https://opensource.org/blog/the-sspl-is-not-an-open-source-l...

    • SSPL ไม่ใช่โอเพนซอร์สอย่างแน่นอน และขัดกับข้อ 6
      https://opensource.org/definition-annotated#6
      นี่คือแก่นสำคัญของโอเพนซอร์ส และในบางแง่ก็รวมถึงซอฟต์แวร์เสรีด้วย ไลเซนส์แบบ copyleft มีข้อจำกัด แต่ตราบใดที่คุณปฏิบัติตามข้อจำกัดนั้น คุณก็สามารถสร้างสิ่งที่ต้องการด้วยซอฟต์แวร์นั้นได้ ส่วนไลเซนส์ SSPL, FSL, BUSL นั้นปิดกั้นการแข่งขันในเชิงพาณิชย์บางรูปแบบไปเลย
      ที่โมเดลธุรกิจส่วนใหญ่ไม่อยากใช้ copyleft ไม่ได้หมายความว่ามันไม่ใช่โอเพนซอร์ส แค่ไม่เหมาะกับโมเดลธุรกิจนั้นเท่านั้น
    • ไม่ใช่แค่ “อาจจะ” แต่มันเป็น ไลเซนส์ที่ไม่เสรี อย่างชัดเจน
    • คิดว่าเราควรมีคำเรียกใหม่สำหรับสิ่งเหล่านี้
      ไลเซนส์ใหม่อย่าง SSPL, BSL, FSL กำลังได้รับความนิยมมากขึ้น และก็มีเหตุผลของมัน เมื่อ 20 ปีก่อนยังไม่มีสถานการณ์ที่ AWS นำ FOSS ไปขายต่อทั่วโลก เงื่อนไขในตอนนั้นจึงต่างจากตอนนี้มาก
      เพราะมีข้อจำกัด มันจึงไม่ใช่ “โอเพนซอร์ส” แต่คำที่ใกล้ที่สุดอย่าง “source available” ก็สะท้อนความจริงได้ไม่ดีนัก เพราะมันให้ความหมายใกล้เคียงกับแค่ว่าซอร์สโค้ดมีอยู่ที่ไหนสักแห่งในเชิงเทคนิค
      ElasticSearch, Sentry และอื่น ๆ ยังพัฒนาแบบเปิดสาธารณะอยู่ คนที่ไม่เกี่ยวกับโครงการก็ยังส่ง PR ได้ และถ้าไม่ได้ตั้งใจจะแข่งขันกับบริษัทเบื้องหลังโครงการอย่างเปิดเผย ใคร ๆ ก็ทำสิ่งที่ต้องการได้

  • ขณะเดียวกัน Microsoft ก็เปิดตัว Garnet: https://github.com/microsoft/garnet
    จังหวะเวลาเหมาะเจาะมาก

    • ในวงสนทนา HN เกี่ยวกับ Garnet มีคนหนึ่งบอกว่าจะไม่ไปยุ่งกับ MS เด็ดขาด
      ตรรกะของเขาคือ MS จะใช้กลยุทธ์ล่อก่อนแล้วค่อยเปลี่ยนไลเซนส์เมื่อถึงเวลาที่ต้องการ ดังนั้น Redis ที่จะคงไลเซนส์โอเพนซอร์สไว้เสมอจึงดีกว่า เป็นการคาดการณ์ที่ยอดเยี่ยมมาก
    • ดูเหมือน Microsoft และ Azure จะเห็นด้วยกับการเปลี่ยนแปลงนี้เต็มที่: https://azure.microsoft.com/en-us/blog/redis-license-update-...
    • สงสัยว่านี่เป็นผลิตภัณฑ์เพื่อการวิจัยหรือสำหรับใช้งานใน production
    • ไม่เข้าใจว่าทำไมซอฟต์แวร์ที่สำคัญขนาดนี้ถึงเขียนด้วยภาษาอย่าง C# หรือ Java ที่ต้องติดตั้งทั้ง runtime และ VM เต็มชุด

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

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