- Liquibase ได้เปลี่ยนจากไลเซนส์โอเพนซอร์สเดิมไปเป็น Functional Source License(FSL)
- แม้ FSL จะ ไม่ใช่ไลเซนส์โอเพนซอร์สอย่างเป็นทางการตามเกณฑ์ของ Open Source Initiative (OSI) แต่ก็มีการตั้งข้อสังเกตว่ายังมีการแนะนำโครงการนี้ว่าเป็นโอเพนซอร์สอยู่ใน README เป็นต้น
- ในชุมชนมีทั้งความเห็นว่า FSL ขัดกับเกณฑ์โอเพนซอร์สอย่างเป็นทางการ และความเห็นตรงข้ามที่มองว่า FSL ตรงตามข้อกำหนดของโอเพนซอร์ส
- ภายในโครงการกำลัง ดำเนินการแก้ไขข้อความที่กล่าวถึงโอเพนซอร์สใน README
- มีข้อชี้ว่า FSL อาจขัดกับบางข้อของ OSI Open Source Definition (นิยามโอเพนซอร์ส) จากเงื่อนไขอย่างการจำกัดการใช้งานเชิงแข่งขัน
ภาพรวมของประเด็น
- ไลเซนส์ของโครงการ Liquibase เพิ่งถูกเปลี่ยนเป็น Functional Source License(FSL)
- แต่ใน README.md และเอกสารทางการอื่น ๆ ยังมีการ อธิบาย Liquibase ว่าเป็นโครงการโอเพนซอร์ส อยู่ จึงทำให้เกิดความสับสนและความเห็นต่างในชุมชน
รายงานของประเด็นและข้อถกเถียง
- ผู้เปิด issue ชี้ว่าปัญหาคือแม้ Liquibase จะย้ายไปใช้ FSL แล้ว แต่ก็ยังระบุว่าเป็นโอเพนซอร์สอยู่
- ตัว Liquibase เองก็เคย ระบุไว้ว่า FSL ไม่ใช่ไลเซนส์โอเพนซอร์ส
- มีการเรียกร้องให้ แก้ README และเอกสารอื่น ๆ เพื่อไม่ให้ใช้คำว่าโอเพนซอร์สในเอกสารของโครงการอีกต่อไป
ความเห็นจากชุมชนและผู้เกี่ยวข้อง
- ผู้ร่วมอภิปรายบางส่วนอ้างว่า FSL ผ่านเกณฑ์ของไลเซนส์โอเพนซอร์สที่ OSI รับรอง และมองว่าหาก FSL ผ่านการตรวจทานอย่างเป็นทางการจนได้รับการรับรองจาก OSI ก็จะไม่มีปัญหา
- ในทางกลับกัน ผู้ร่วมอภิปรายอีกส่วนหนึ่งเน้นว่า จากเงื่อนไขอย่าง “วัตถุประสงค์ที่อนุญาต” ใน FSL ทำให้ ขัดกับหลายข้อของ Open Source Definition ของ OSI (ข้อ 1, 3, 5, 6)
- ยังมีความเห็นที่เน้นการแยกระหว่าง “Fair Source” กับ “โอเพนซอร์สที่แท้จริง” โดยเห็นว่า FSL ควรถูกจัดอยู่ในกลุ่ม Fair Source
กระบวนการแก้ไข issue และการปรับเอกสาร
- ผู้มีส่วนร่วมของโครงการได้ตอบสนองต่อการทักท้วงนี้ด้วยการ แก้ไข README.md และทยอยลบข้อความที่กล่าวถึงโอเพนซอร์ส
- อย่างไรก็ตาม ยังมีคำว่า ‘open source’, ‘oss’ หลงเหลืออยู่ตามจุดต่าง ๆ ของ repository จึง มีแผนจะตรวจสอบและจัดการเพิ่มเติม
นิยามโอเพนซอร์สและปัญหาของ FSL (Functional Source License)
- Richard Fontana และบุคคลสำคัญในสายโอเพนซอร์สระบุชัดว่า FSL ละเมิดนิยามโอเพนซอร์สของ OSI จากเงื่อนไขอย่างการห้ามใช้งานเชิงแข่งขัน
- นิยามโอเพนซอร์สมีข้อกำหนดเรื่อง “ห้ามเลือกปฏิบัติต่อสาขาอาชีพ บุคคล หรือองค์กร” และการห้ามใช้เพื่อวัตถุประสงค์เชิงแข่งขันก็ขัดกับหลักนี้
- FSL มีกำหนดจะเปลี่ยนเป็น MIT หรือ Apache License หลังผ่านไป 2 ปี ทำให้กลายเป็นโอเพนซอร์สเต็มรูปแบบ แต่ก่อนถึงเวลานั้น ยังคงมีเงื่อนไขจำกัดอยู่
บทสรุปและสถานการณ์ปัจจุบัน
- issue นี้ช่วยกระตุ้นทั้ง ความต้องการความโปร่งใสจากชุมชนต่อการแก้ไขคำอธิบายโอเพนซอร์สของ Liquibase และการถกเถียงถึงแก่นแท้ของคำว่าโอเพนซอร์ส
- งานแก้ไข README และเอกสารทางการได้เริ่มขึ้นแล้ว และ เกณฑ์การแยกระหว่าง Fair Source กับโอเพนซอร์ส ก็ถูกหยิบยกมาถกเถียงผ่านกรณีจริงนี้
- ไม่ว่า OSI จะรับรองหรือไม่ เงื่อนไขที่แท้จริงของไลเซนส์ก็ ยังมีความหมายอย่างมากในชุมชนโอเพนซอร์สนานาชาติ
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เริ่มหาทางเลือกไว้เผื่อไม่สามารถใช้เวอร์ชัน 4.x ได้อีกต่อไป
เข้าใจได้ว่ามีคนอยากสร้างรายได้จากซอฟต์แวร์ที่มีประโยชน์ด้วยการเปลี่ยนจากไลเซนส์ OSS ไปเป็นแบบเสียเงิน
แต่คิดว่าการเปลี่ยนไลเซนส์จากโอเพนซอร์สเป็นเหมือนกลยุทธ์ล่อให้ใช้แล้วค่อยเปลี่ยนเงื่อนไขภายหลัง
การตัดสินใจแบบนี้ทำลายความเชื่อมั่นทันที และยังทำให้สูญเสียฐานผู้ใช้ที่อาจยังสร้างรายได้ไม่ได้ตอนนี้แต่มีศักยภาพในระยะยาว
นึกว่าคงได้บทเรียนสำคัญจากกรณีของ Elastic และ TerraForm ไปแล้ว
แม้แต่ Flyway ก็อาจเดินตามเส้นทางคล้ายกันได้ทุกเมื่อ เลยรู้สึกเชื่อถือน้อยลง
ถ้าไม่มี fork ออกมา ก็อาจต้องพิจารณาสร้าง migration library ที่เหมาะกับการใช้งานจริงของเราเองไปเลย
ที่ใช้ Liquibase ก็เพราะสะดวกเท่านั้น ไม่ได้ถึงขั้นไม่มีอะไรทดแทนได้เด็ดขาด
มองว่า EventstoreDB (ตอนนี้คือ KurrentDB) และ NATS ก็ถูกตั้งคำถามเรื่องความน่าเชื่อถือของบริการเช่นกัน
EventstoreDB เปลี่ยนไลเซนส์ไปแล้ว ส่วน NATS ก็แค่ยกเลิกแผนเพราะผู้ใช้ต่อต้าน
ตอนนี้รู้สึกว่าพฤติกรรมแบบนี้กลายเป็นกลยุทธ์ทางธุรกิจไปแล้ว
ข้อดีใหญ่ที่สุดของโอเพนซอร์สคือสามารถ fork เวอร์ชันก่อนหน้าไปใช้ได้เสมอ
มองว่าโดยแก่นแล้วมันไม่ได้ต่างจากการขึ้นราคาสินค้าเท่าไรนัก
แม้จะรองรับเฉพาะ Postgres แต่ก็มีโปรเจกต์ pgroll ที่ยกระดับงานอัตโนมัติไปอีกขั้น
นอกจาก Flyway (Apache license) ก็ยังมีไลเซนส์ที่เป็นโอเพนซอร์สอยู่พอสมควร เช่น Atlas (Apache), Sqitch (MIT)
สงสัยว่าการเปลี่ยนไลเซนส์ของ Elastic นั้นล้มเหลวจริงไหมในมุมของบริษัท
แม้ราคาหุ้นจะตกอยู่ช่วงหนึ่ง แต่ตัวบริษัทก็ยังแข็งแรงดี
เท่าที่รู้ นักพัฒนาในสาย search และ RAG ที่ผมรู้จักก็ยังใช้ Elasticsearch ของ Elastic NV กันอยู่ทั้งหมด (ไม่ได้ใช้โอเพนซอร์ส fork หรือทางเลือกอื่น)
โดยเฉพาะถ้ามองเฉพาะกลุ่มลูกค้าหลักที่ Elastic ให้ความสำคัญที่สุดอย่างลูกค้าแบบเสียเงิน ดูเหมือนว่าจะไม่ใช่การทำลายความเชื่อมั่น แต่กลับให้ผลตรงกันข้าม
รายได้จริงก็เติบโตเป็นสองเท่าเมื่อเทียบกับปี 2020
ยังมีคนบอกว่านี่ยังเป็นโอเพนซอร์สอยู่ แต่ทาง Liquibase ก็ระบุเองชัดเจนว่า FSL ไม่ใช่ไลเซนส์โอเพนซอร์ส
ดูประกาศในบล็อกทางการของ Liquibase
น่าเสียดายที่ช่วงนี้มีหลายโปรเจกต์ที่แค่เปิดซอร์สแต่พยายามสร้างภาพว่าเป็นโอเพนซอร์ส
ถ้า Liquibase เลือก Apache แทน copyleft แบบเข้มอย่าง GNU AGPL ก็ควรคาดไว้ตั้งแต่แรกแล้วว่าบริษัทอื่นจะสร้างงานดัดแปลงแบบซอร์สปิดได้
สุดท้ายก็เป็นทางเลือกที่ Liquibase เลือกเอง จึงคิดว่าความรับผิดชอบก็อยู่ที่ Liquibase เช่นกัน
ดูเหมือนจะเป็นโครงสร้างที่เปลี่ยนกลับเป็น Apache อัตโนมัติหลังผ่านไประยะหนึ่ง
จะดีกว่าหรือไม่ก็ยังไม่แน่ใจ
จริง ๆ แล้วบริษัทต่าง ๆ ก็สามารถบรรลุเป้าหมายของตัวเองได้แม้ใช้ไลเซนส์อย่าง AGPL
Redis ก็เปลี่ยนไปใช้และเสียงตอบรับจากชุมชนก็เป็นบวก
ไม่คิดว่าผู้ใช้จะไม่พอใจหาก Liquibase เลือกใช้ AGPL แบบ dual license
น่าจะเรียกว่า "โอเพนซอร์สแบบดีเลย์ 2 ปี" หรือ "จะเป็นโอเพนซอร์สในอีก 2 ปี" มากกว่า
เอาเข้าจริงมันเหมือน "ค่อยโอเพนซอร์สตอนที่ไม่ค่อยมีประโยชน์แล้ว"
ถ้าเป็นแบบนี้ แก่นแท้ก็เหมือนแค่สร้างภาพว่าตนเคารพเสรีภาพที่แท้จริง ทั้งที่ในทางปฏิบัติไม่ใช่
ก็ไม่บ่อยนักที่เวอร์ชันเก่าจะไร้ค่าเร็วขนาดนั้น
ผมไม่มองว่านี่คือการไม่เคารพเสรีภาพของผม
เป้าหมายคือการจำกัดบางอย่างกับองค์กร ไม่ใช่กับคน
สำหรับสาย enterprise แก่นสำคัญของโอเพนซอร์สไม่ใช่ "เสรีภาพ" แต่คือความน่าเชื่อถือและความโปร่งใส
แค่เปิดซอร์สก็ได้รับข้อดีของ FOSS ได้แล้วโดยไม่ติดปัญหากฎหมายหรือการหารายได้
บนโลกออนไลน์มีแนวโน้มจะเชื่อมั่นในโมเดลโอเพนซอร์สมากเกินไปแบบไม่ลืมหูลืมตา
มองว่านโยบายผสมแบบ 2 ปีก็สมเหตุสมผลพอ และถ้าไม่ต้องการไลเซนส์ใหม่ก็ใช้เวอร์ชันเก่าได้
delayed open source มีความหมายสองชั้น คล้ายคำว่า 'late' ในภาษาอังกฤษ
#source-washing
ถ้ายังไม่คุ้นกับไลเซนส์ใหม่นี้ ลองดู ลิงก์อธิบาย FSL แบบละเอียด
เพิ่มบริบทเกี่ยวกับ FSL: เป็นไลเซนส์ที่ Sentry สร้างขึ้น โดยเหตุผลที่ต้องมีไลเซนส์นี้และปัญหาที่พยายามแก้สามารถดูได้ใน บล็อกของ Sentry
โดยส่วนตัว ไลเซนส์ซอร์สปิดแบบเดียวที่พอยอมรับได้คือ BuSL "Business Source License"
เมื่อครบ 4 ปีจะกลายเป็นโอเพนซอร์สโดยอัตโนมัติ และก่อนหน้านั้นก็ยังเปิดซอร์สอยู่
ยังช่วยป้องกันการแตกแขนงของไลเซนส์โดยไม่จำเป็นด้วย
ลองดู วิกิของ Business Source License เพิ่มเติมได้
สงสัยว่าระยะเวลา 2 ปีจะสั้นเกินไปหรือเปล่า
ในมุมขององค์กรใหญ่ ซอฟต์แวร์อายุ 5 ปีก็ยังใช้งานกันได้ดี และสำหรับผม Redis เวอร์ชันปี 2012 หรือ Postgres เวอร์ชันปี 2020 ก็ยังโอเคมาก
เคยรวบรวมประวัติของเคสแบบนี้และรายชื่อบริษัทไว้
สรุปไว้ใน โพสต์บล็อกที่เกี่ยวข้อง ถ้าใครรู้เพิ่มเติมก็ช่วยแชร์ได้
ฟีเจอร์ Pro ทำให้ไวยากรณ์ของเวอร์ชันชุมชนพังบ่อย เลยรู้สึกว่าไม่มีความโปร่งใสเลย
แน่นอนว่าการทำงานก็ควรได้รับค่าตอบแทนที่เหมาะสม แต่การบอกว่า "เราเคยเป็นโอเพนซอร์ส แล้วค่อย ๆ ไม่ใช่อีกต่อไป" กำลังกลายเป็นเรื่องที่พบได้บ่อยเกินไป
การเปลี่ยนแบบนี้มักเกิดขึ้นอย่างเงียบ ๆ เหมือนหวังว่าไม่มีใครสังเกตเห็น
เลยสงสัยว่าความเสียหายจริงหรือปัญหาหลักมันคืออะไร
กลับกัน ผมชอบการแยกแยะระหว่างพื้นที่แข่งขันกับพื้นที่ที่ไม่แข่งขัน
บรรยากาศในคอมเมนต์ดูแปลก ๆ อยู่บ้าง
ส่วนใหญ่ดูเหมือนเห็นแค่คำว่า "base" แล้วก็แนะนำบริการที่ไม่เกี่ยวกันเลย หรือไม่ก็ยืนยันว่าแค่เปิดซอร์สก็ถือเป็นโอเพนซอร์สแล้ว
ไม่รู้มาก่อนเลยว่า Liquibase เปลี่ยนไลเซนส์แล้ว
จริง ๆ แล้วแทบทุกเว็บเฟรมเวิร์กก็มีทางเลือก และยังมีทางเลือกที่ไม่ผูกกับเฟรมเวิร์กอย่าง Alembic กับ Flyway อีกมาก
ณ จุดนี้มันดูแปลก ๆ ไปหน่อย
ประเด็นนี้อาจก่อปัญหาให้โปรเจกต์ OSS อย่าง Keycloak ได้ด้วย
ตามนโยบายของ CNCF ไม่สามารถใช้ไลเซนส์ที่ไม่ใช่โอเพนซอร์สได้ ดังนั้น Keycloak จึงใช้ Liquibase ไม่ได้
Debian, Fedora และดิสโทรอื่น ๆ ก็มีเงื่อนไขเรื่องไลเซนส์ OSS เช่นกัน เลยสงสัยว่าโปรเจกต์ที่พึ่งพา Liquibase จะยังถูกรวมอยู่ในดิสโทรเหล่านี้ได้หรือไม่
รายละเอียดใน issue ของ Keycloak
แต่ยังใส่ไว้ใน repository แยกต่างหากหรือ custom repo อย่าง rpm fusion non-free ได้