HashiCorp ประกาศใช้ Business Source License
(hashicorp.com)- HashiCorp เปลี่ยนไลเซนส์ซอร์สโค้ดของการออกผลิตภัณฑ์ในอนาคตจาก MPL 2.0 เป็น Business Source License v1.1 โดยมีเป้าหมายเพื่อเดินหน้าลงทุนในชุมชนและตัวผลิตภัณฑ์อย่างต่อเนื่อง
- บริษัทมองว่าโมเดลโอเพนซอร์สเดิมช่วยสร้างระบบนิเวศขนาดใหญ่ได้ แต่ปัญหาคือมีบางผู้ให้บริการที่ นำผลงานของชุมชนไปใช้เชิงพาณิชย์ โดยแทบไม่ได้มีส่วนร่วมกลับคืน
- BSL 1.1 เป็น ไลเซนส์แบบ source-available ที่อนุญาตให้คัดลอก แก้ไข แจกจ่ายต่อ ใช้งานแบบไม่เชิงพาณิชย์ และใช้งานเชิงพาณิชย์แบบมีเงื่อนไข ขณะที่ API, SDK และไลบรารีส่วนใหญ่ยังคงใช้ MPL 2.0
- ผู้ใช้ปลายทาง พาร์ตเนอร์ ลูกค้าองค์กร และลูกค้าผลิตภัณฑ์แบบคลาวด์ที่มีการจัดการ ส่วนใหญ่ยังใช้งานในรูปแบบเดิมได้ต่อไป แต่การให้บริการผลิตภัณฑ์ที่แข่งขันกับ HashiCorp จะเป็นข้อยกเว้น
- ผู้ให้บริการที่สร้างบริการแข่งขันบนผลิตภัณฑ์ชุมชนของ HashiCorp จะรวมรีลีสในอนาคต การแก้บั๊ก และแพตช์ความปลอดภัยได้ยากขึ้นอีกต่อไป
ขอบเขตของการเปลี่ยนแปลงไลเซนส์
- ไลเซนส์ซอร์สโค้ดของผลิตภัณฑ์ HashiCorp ทุกรุ่นที่จะออกในอนาคต จะเปลี่ยนจาก Mozilla Public License v2.0(MPL 2.0) เป็น Business Source License(BSL หรือ BUSL) v1.1
- HashiCorp API, SDK และไลบรารีอื่นเกือบทั้งหมดจะยังคงใช้ MPL 2.0
- ซอร์สโค้ดของผลิตภัณฑ์และอัปเดตต่าง ๆ จะยังคงเผยแพร่ต่อสาธารณะผ่าน GitHub repository และช่องทางแจกจ่ายของ HashiCorp
- HashiCorp ตั้งเป้าแบ่งปันซอร์สโค้ดอย่างกว้างขวางและเปิดให้ใช้งานฟรี โดยพยายามลดผลกระทบต่อชุมชน พาร์ตเนอร์ และลูกค้าให้น้อยที่สุด
โมเดลโอเพนซอร์สและภาระด้านการทำเชิงพาณิชย์
- เหตุผลที่ HashiCorp เปิดผลิตภัณฑ์เป็นโอเพนซอร์สตั้งแต่เริ่มก่อตั้งมี 3 ข้อ
- ผู้ปฏิบัติงานควรสามารถดาวน์โหลด ตรวจสอบซอร์สโค้ด และแก้ปัญหาด้วยตนเองได้อย่างอิสระ
- ควรสร้างระบบนิเวศและชุมชนรอบผลิตภัณฑ์เพื่อให้เกิดการผสานรวมได้อย่างกว้างขวาง
- ความโปร่งใส เป็นสิ่งสำคัญสำหรับผู้ใช้
- ตลอดเวลากว่า 10 ปี บริษัทได้ออกผลิตภัณฑ์และฟีเจอร์ใหม่ภายใต้ไลเซนส์โอเพนซอร์สแบบใช้ฟรี และได้ก่อให้เกิดชุมชนขนาดใหญ่ที่ประกอบด้วยผู้ใช้ ผู้มีส่วนร่วม พาร์ตเนอร์ และลูกค้า
- บริษัทลงทุนด้านวิจัยและพัฒนาผลิตภัณฑ์โอเพนซอร์สปีละ หลายสิบล้านดอลลาร์ โดยมีลูกค้าเชิงพาณิชย์ที่ทำงานร่วมกับ HashiCorp ในโครงสร้างพื้นฐานระดับ mission-critical ช่วยทำให้โมเดลนี้เกิดขึ้นได้
- บริษัททำงานอย่างใกล้ชิดกับผู้ให้บริการคลาวด์เพื่อสร้างการผสานรวมสำหรับผู้ใช้และลูกค้าร่วมกัน และยังทำงานร่วมกับพาร์ตเนอร์ด้านเทคโนโลยีอีกหลายร้อยราย
วิธีการใช้ BSL 1.1
- BSL 1.1 เป็นไลเซนส์แบบ source-available ที่อนุญาตให้คัดลอก แก้ไข แจกจ่ายต่อ ใช้งานแบบไม่เชิงพาณิชย์ และใช้งานเชิงพาณิชย์ภายใต้เงื่อนไขที่กำหนด
- ในช่วงไม่กี่ปีที่ผ่านมา Couchbase, Cockroach Labs, Sentry และ MariaDB ก็เลือกแนวทางคล้ายกัน โดย MariaDB เป็นผู้พัฒนาไลเซนส์นี้ในปี 2013
- ยังมีการยกตัวอย่างว่า Confluent, MongoDB, Elastic และ Redis Labs ก็เคยใช้ไลเซนส์ทางเลือกที่มีข้อจำกัดด้านการใช้งานเชิงพาณิชย์
- การใช้ BSL ของ HashiCorp มี สิทธิการใช้งานเพิ่มเติม รวมอยู่ด้วย เพื่อเปิดทางให้ใช้งานซอร์สโค้ดได้อย่างกว้างขวางและยืดหยุ่น
- ระหว่างพัฒนาแนวทางไลเซนส์ บริษัทได้ขอคำปรึกษาจากผู้เชี่ยวชาญด้านไลเซนส์ OSS และผู้มีส่วนเกี่ยวข้องในอุตสาหกรรม เพื่อให้สอดคล้องกับแนวปฏิบัติของอุตสาหกรรม
ผลกระทบต่อผู้ใช้ พาร์ตเนอร์ และลูกค้า
- ผู้ใช้ปลายทางยังคงสามารถคัดลอก แก้ไข และแจกจ่ายโค้ดต่อได้ทั้งเพื่อการใช้งานแบบไม่เชิงพาณิชย์และเชิงพาณิชย์ ยกเว้นกรณีที่นำไปใช้เพื่อให้บริการผลิตภัณฑ์ที่แข่งขันกับ HashiCorp
- พาร์ตเนอร์ยังสามารถสร้างการผสานรวมสำหรับลูกค้าร่วมกันได้ต่อไป
- บริษัทมีแผนทำงานอย่างใกล้ชิดกับผู้ให้บริการคลาวด์ต่อไป เพื่อคงการรองรับเชิงลึกสำหรับเทคโนโลยีของทั้งสองฝ่าย
- ลูกค้าผลิตภัณฑ์ HashiCorp แบบองค์กรและแบบคลาวด์ที่มีการจัดการจะไม่มีการเปลี่ยนแปลง
- ผู้ให้บริการที่นำผลิตภัณฑ์ชุมชนไปสร้างบริการที่แข่งขันกับ HashiCorp จะไม่สามารถรวมรีลีสในอนาคต การแก้บั๊ก และแพตช์ความปลอดภัยของผลิตภัณฑ์ HashiCorp ได้อีกต่อไป
คำชี้แจงเพิ่มเติม
- HashiCorp ระบุว่าคำมั่นสัญญาที่มีต่อชุมชน พาร์ตเนอร์ และลูกค้าไม่ได้เปลี่ยนแปลง
- มี frequently asked questions สำหรับคำถามเพิ่มเติม
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ข้อสรุปเดียวที่ได้จากเรื่องนี้คือ HashiCorp ไม่ใช่บริษัทโอเพนซอร์สอีกต่อไปแล้ว
การที่มี “ผู้ขายที่ใช้โมเดล OSS บริสุทธิ์และงานของชุมชนเพื่อเป้าหมายเชิงพาณิชย์ โดยไม่คืนผลงานที่มีนัยสำคัญกลับไป” นั้นสอดคล้องกับจิตวิญญาณโอเพนซอร์ส 100%
ถ้านั่นเป็นปัญหา ก็แค่เลือกใช้ไลเซนส์โอเพนซอร์สอย่าง AGPL ที่บังคับให้นักพัฒนาเปิดเผยโค้ดก็ได้
นี่เป็นแค่วิธีที่ HashiCorp พยายามทำให้โปรเจกต์โอเพนซอร์สเดิม มีแต่พวกเขาเท่านั้นที่นำไปทำเชิงพาณิชย์ได้ ซึ่งตัวมันเองก็ไม่เป็นไร แต่ถ้าอย่างนั้นก็ควรไปเป็นซอร์สปิดและยอมรับตรง ๆ ไม่ใช่พยายามเอาทั้งสองทาง
บล็อกโพสต์นี้ไม่ตรงไปตรงมา เราเคยพยายามส่งแพตช์แก้ไข upstream ให้ Terraform providers หลายครั้ง แต่ HashiCorp ไม่เคยรับเลย จึงต้องดูแล fork เอง
HashiCorp สูญเสีย DNA ของ OSS ไปนานแล้ว และการเคลื่อนไหวครั้งนี้ก็เหมือนตอกตะปูตัวสุดท้ายลงบนฝาโลง
โชคดีที่เมื่อเวลาผ่านไป ความรับผิดชอบส่วนใหญ่ของ Terraform providers ถูกส่งต่อให้พาร์ตเนอร์แล้ว จึงหวังว่าระบบนิเวศของ providers จะยังคงคึกคักและเปิดกว้างต่อไปได้
ผมเชื่อมั่นในโอเพนซอร์สอย่างลึกซึ้ง โปรเจกต์สุดท้ายที่ทำที่ Microsoft ก็เป็นงานทำให้ .NET เป็นโอเพนซอร์สและข้ามแพลตฟอร์ม CTO ของเราก็มีส่วนร่วมในการก่อตั้ง TypeScript และ Pulumi ก็เป็นโปรเจกต์โอเพนซอร์ส Apache เช่นกัน แต่ HashiCorp ดูเหมือนจะไม่ใช่แบบนั้นอีกต่อไปแล้ว
ถ้ามองภาพใหญ่ ยุคสมัยเปลี่ยนไปแล้ว และผมคิดว่าการเปิดเผยซอร์สควรเป็น ความสัมพันธ์ที่เป็นประโยชน์ร่วมกัน ระหว่างฝ่ายที่สร้างกับฝ่ายที่ใช้ ไม่ใช่ “ถ้าไม่ปล่อยทุกอย่างฟรีก็ไม่ใช่ของจริง”
ผู้ใช้ควรสามารถเข้าใจและขยายสิ่งที่กำลังรันอยู่ได้จากซอร์ส ส่วนผู้จัดการ/ผู้ดูแล/เจ้าของโปรเจกต์ก็ควรสามารถทำงานนั้นต่อไปได้
นี่ไม่ใช่จุดสมดุลที่ต้องไปให้ถึง แต่เป็นสมดุลที่ต้องรักษาไว้ท่ามกลางแรงตึง
ลองตรวจ Wikipedia แล้วพบว่า HashiCorp กำหนดเงื่อนไข IPO เมื่อวันที่ 29 พฤศจิกายน 2021
ยิ่งรู้สึกว่าสมมติฐานนี้น่าจะถูกขึ้นเรื่อย ๆ ยินดีรับข้อมูลเชิงประสบการณ์ทั้งที่เป็นตัวอย่างโต้แย้งหรือสนับสนุน
การไม่เป็นโอเพนซอร์สไม่ได้แปลว่าต้องห้ามดูซอร์ส และก็ไม่ได้แปลว่าต้องตัดคุณสมบัติทั้งหมดของไลเซนส์ที่ OSI อนุมัติออกไป
แน่นอนว่าถ้าเป็นซอฟต์แวร์เสรีก็คงดีกว่า แต่มันก็เหมือนกับการบอกว่าถ้าซอฟต์แวร์ทั้งหมดเป็นซอฟต์แวร์เสรีก็คงดีกว่า
ปัญหาเกิดขึ้นเมื่อพยายามแสร้งว่าไลเซนส์ที่ไม่มีทางได้รับการอนุมัติจาก OSI เป็นโอเพนซอร์ส HashiCorp ไม่ได้อ้างว่ายังเป็นโอเพนซอร์ส และตอนนี้เรียกว่า “ซอร์สเปิดให้ดูได้ (source-available)”
ค่อนข้างน่าผิดหวัง ส่วนตัวแทบไม่ได้ใช้มากนักนอกจาก Vault และเคยลอง Terraform แต่ไม่ได้สนุกกับมันหรือสร้างอะไรบนมัน เรื่องนี้ตรงข้ามกับสิ่งที่ผมเคยมองว่าเป็นจุดดีที่สุดของผลิตภัณฑ์ HashiCorp
ผมยังเคยมีส่วนร่วมกับ การจัดการใบรับรอง ซึ่งเป็นโค้ดบางส่วนที่ผมใช้มากที่สุดใน Vault ด้วย ตอนนี้ต้องกลับมาทบทวนแล้วว่าจะยังแนะนำลูกค้าให้ลองใช้บริการนั้นได้ไหม และจะกลับไปมีส่วนร่วมอีกไหม
รู้สึกเหมือนอนาคตที่เลวร้ายที่สุดของไลเซนส์ที่ไม่ใช่ตระกูล GPL กำลังปรากฏชัด ในยุคที่เงิน VC เริ่มแห้งลง
เป็นเรื่องน่าเสียดายสำหรับคนที่ตั้งใจเรียนรู้ OSS และการดำเนินงานของมันโดยเฉพาะ ด้วยความฝันว่าสักวันจะใช้ความรู้นั้นสร้างบริการ เป็นนายตัวเอง และยังคงตอบแทน OSS ที่พาตัวเองมาถึงจุดนี้
ผมมีประสบการณ์มากในการนำ Enterprise Vault ไปใช้งานและดูแลเพื่อจัดการ secret ของแอปพลิเคชันทั่วทั้งโครงสร้างพื้นฐานของบริษัท
ตลอดหลายปีที่นำ Vault มาใช้และเจรจาสัญญา ผมเห็น sales engineer พูดถึงฟีเจอร์ที่ “จำเป็น” สำหรับ use case อย่างไม่ถูกต้องหรือทำให้เข้าใจผิด และให้คำมั่นระยะยาวเรื่องฟีเจอร์ที่ทำไม่ได้จริง
พวกเขายังแนะนำรูปแบบ integration ที่ทำให้การย้ายออกจาก Vault แทบเป็นไปไม่ได้หรืออาจเสี่ยง และคอยดึงฟีเจอร์ที่เคยคิดว่าจะฟรีตลอดไปออกไปเรื่อย ๆ ตัวอย่างใหญ่ที่สุดคือการล็อกอิน Okta/MFA ซึ่งถ้าไม่มีสิ่งนี้ก็ยากจะผ่าน compliance อย่างจริงจัง และดูเหมือนว่า HashiCorp จะตระหนักว่าทีมที่พึ่งพา Vault อย่างหนักสุดท้ายก็ไม่มีทางเลือกนอกจากจ่ายเงินให้ฟีเจอร์นี้
โดยรวมแล้วดูเหมือน vendor lock-in อย่างแรง และทุกปีก็ต้องจ่ายมากขึ้นเพื่อฟีเจอร์เดิมหรือแม้แต่น้อยลง นโยบายราคาที่แม้แต่วิศวกรของพวกเขาเองยังอธิบายไม่ได้ก็เปลี่ยนไปมาแบบตามใจอยู่เรื่อย ๆ
ผมมองว่า Vault เองเป็นซอฟต์แวร์ที่ยอดเยี่ยม แต่เพราะสูญเสียความเชื่อมั่นใน HashiCorp แล้ว ส่วนตัวคงไม่พึ่งพามันในงานสำคัญ
ถ้าตีความตามตัวอักษร ก็ไม่ได้มีอะไรเปลี่ยน และนี่ไม่ใช่เรื่องน่าผิดหวัง แต่เป็นทางเลือกที่ฉลาด เป็นการปกป้องตัวเองจาก ผู้ให้บริการคลาวด์ ที่ใช้ประโยชน์จากน้ำใจของชุมชนโอเพนซอร์สซ้ำแล้วซ้ำเล่า
โปรเจกต์ OSS ที่บังคับให้ผู้มีส่วนร่วมโอนลิขสิทธิ์ให้ไม่ควรได้รับความไว้วางใจ และตั้งแต่แรกก็ไม่ควรรับการมีส่วนร่วมด้วยเจตนาดี
ไม่อย่างนั้น วันนี้อาจเป็น Apache 2.0 แต่พรุ่งนี้อาจถูกเปลี่ยนเป็นเชิงพาณิชย์ได้โดยไม่ต้องขออนุญาตใคร เพราะผู้ดูแลถือครองโค้ด 100%
โดยปกติแล้ว โปรเจกต์ OSS ที่มีองค์กรเชิงพาณิชย์หนุนหลังมักไม่ค่อยได้รับ contribution ในปริมาณที่มีนัยสำคัญจากผู้มีส่วนร่วมภายนอกนัก แต่ถึงอย่างนั้นก็ยังเป็นรายละเอียดสำคัญที่ควรพิจารณาใน OSS
การพูดทำนองว่า “โมเดลโอเพนซอร์สเชิงพาณิชย์ต้องวิวัฒนาการ เพื่อให้ระบบนิเวศยังคงมอบซอฟต์แวร์ที่เปิดกว้างและใช้งานได้ฟรีต่อไป” แล้วสื่อเป็นนัยว่า ไลเซนส์ที่ไม่ใช่โอเพนซอร์สอย่าง BUSL เป็นส่วนหนึ่งของวิวัฒนาการของโมเดลโอเพนซอร์ส ถือเป็นความสับสนอย่างร้ายแรงหรือเป็นการชี้นำผิดโดยเจตนา
เคยมีใครในระดับที่มีนัยสำคัญใช้ผลิตภัณฑ์ของ HashiCorp เพื่อแข่งขันกับ HashiCorp จริง ๆ หรือไม่?
[1]: https://www.pulumi.com/docs/concepts/vs/terraform/#:~:text=U...
Pulumi สามารถแปลง Terraform Provider ใด ๆ ให้ใช้ใน Pulumi ได้ จึงสามารถจัดการโครงสร้างพื้นฐานทั้งหมดที่ระบบนิเวศ Terraform Providers รองรับด้วยโปรแกรม Pulumi
บริษัทต่าง ๆ ทำมาตรการแบบนี้เพราะบริษัทอย่าง Amazon ใช้ ไลเซนส์เสรีและโอเพนซอร์ส ไปตั้งเวอร์ชัน self-hosted ของโปรเจกต์โอเพนซอร์สเอง
ctrl+fค้นหา “open source” จะเห็นว่าพวกเขาหยุดใช้คำนั้นตั้งแต่ตรงไหนHashiCorp อธิบายว่าการเปลี่ยนแปลงครั้งนี้มีไว้เพื่อคงไว้ซึ่ง ผลิตภัณฑ์ที่เปิดกว้างและใช้งานได้ฟรี ไม่ใช่เพื่อคงความเป็น “โอเพนซอร์ส”
ในแง่ที่พวกเขาไม่ได้บอกว่ายังเป็น “โอเพนซอร์ส” หลังเปลี่ยนไลเซนส์ ผมมองว่าซื่อสัตย์กว่าที่อื่น เห็นได้ชัดว่าพวกเขารู้ว่าจะเจอกระแสตีกลับหากเรียกแบบนั้น
น่าสนใจที่ @mitchellh ไม่เข้ามาร่วมวงสนทนา เมื่อก่อนเขาเคยสื่อสารโดยตรงบน HN และผมคิดว่าเขาน่าจะมีอิทธิพลขั้นสุดท้ายต่อการตัดสินใจนี้ด้วย
โดยรวมดูเหมือนเป็นทางเดินของผู้แพ้ ดูสิว่าเกิดอะไรกับ Elasticsearch สำหรับผมและคนส่วนใหญ่ ES ไม่มีอยู่อีกต่อไปแล้ว ย้ายไป OpenSearch อย่างสบายใจ และไม่หันกลับไปมอง kimchi ที่น่าสงสารเลย เพราะการกระทำของตัวเอง Elasticsearch จึงไม่เกี่ยวข้องอีกต่อไป
ความเคลื่อนไหวครั้งนี้ของ HashiCorp จะจุดชนวนความพยายามคล้าย ๆ กันในการ fork เวอร์ชันไลเซนส์โอเพนซอร์สสุดท้ายของ Terraform และเครื่องมืออื่น ๆ หรือไม่? ถ้าผู้สร้างกลายเป็นคนขี้งกและหวาดระแวง แล้วหันมาเป็นศัตรูกับ ชุมชนโอเพนซอร์ส ที่ช่วยกันสร้างขึ้นมา จะมีทางเลือกอื่นอะไรอีก
ผมผิดหวังอย่างยิ่งกับผู้นำของ HashiCorp MitchellH และ Armon Dadgar ควรปฏิบัติต่อชุมชนให้ดีกว่านี้
ผมเคยสัมภาษณ์กับ HashiCorp ในปี 2016 และสุดท้ายปฏิเสธเข้าทำงาน ซึ่งบางครั้งก็เคยเสียใจเล็กน้อยกับการตัดสินใจนั้น ตอนนี้ธาตุแท้ถูกเผยออกมาแล้ว ผมมั่นใจว่าเป็นทางเลือกที่ถูกต้อง
มีคำพูดเรื่องความไว้วางใจอยู่ใช่ไหม ความไว้วางใจใช้เวลาหลายปีกว่าจะสร้างขึ้น ใช้เวลาไม่กี่วินาทีในการทำลาย และใช้เวลาชั่วนิรันดร์ในการกู้คืน
น่าประหลาดใจที่คนที่เคยคิดว่าฉลาดจะโง่ได้ขนาดนี้
ไม่จำเป็นต้องดูหมิ่นคนที่ทำสิ่งต่าง ๆ ไว้มากมาย
ซอฟต์แวร์ของพวกเขาเคยเป็นโอเพนซอร์ส และของดี ๆ ก็คงถูก fork ต่อไป ดังนั้นไม่จำเป็นต้องเกลียด HashiCorp
ผมก็ไม่เห็นด้วยกับคำพูดที่ว่า “ความไว้วางใจใช้เวลาหลายปีกว่าจะสร้างขึ้น ใช้เวลาไม่กี่วินาทีในการทำลาย และใช้เวลาชั่วนิรันดร์ในการกู้คืน” มันก้าวร้าวเกินไป
HashiCorp สร้างสิ่งยอดเยี่ยมหลายอย่างและลองทำธุรกิจบนฐานโอเพนซอร์ส พวกเขาไม่ได้ผิดสัญญาหรือทำสิ่งผิดศีลธรรม นี่เป็นทางเลือกของพวกเขา
ดูเหมือนเป็น บทสรุปที่หลีกเลี่ยงไม่ได้ ของบริษัทโอเพนซอร์สทุกแห่งหลังจากเงินฟรีหมดลง สิ่งที่ขัดใจคือถ้อยคำค่อนข้างคลุมเครือ
HashiCorp มองผลิตภัณฑ์คู่แข่งว่าเป็น “ผลิตภัณฑ์หรือบริการที่เสนอให้ผู้ใช้หรือลูกค้านอกองค์กร ซึ่งมีฟังก์ชันซ้อนทับอย่างมีนัยสำคัญกับผลิตภัณฑ์และบริการเชิงพาณิชย์ของ HashiCorp”
ตัวอย่างเช่น สมมติว่าไม่มีบริการประเมินค่าใช้จ่าย เลยสร้างอะไรบางอย่างขึ้นมาแล้วมันโด่งดัง: https://github.com/infracost/infracost
สองปีต่อมา Terraform Cloud ทำตาม จะเกิดอะไรขึ้น? ต้องปิดธุรกิจหรือ?
แต่กับ ผลิตภัณฑ์แกนหลักของงาน ที่ใหญ่กว่าอย่างฐานข้อมูล จะเห็นการบิดเงื่อนไขที่แปลกกว่ามาก เช่น ทำให้ self-hosting ยากขึ้น หรือจำกัดฟีเจอร์จำเป็น
ดีกว่า closed source แต่ก็ไม่ใช่อุดมคติ ผมคิดมาสักพักแล้วว่าไลเซนส์น่าจะเป็นทางออกเชิงปฏิบัติในช่วงหนึ่ง แต่ต้องเป็นที่เข้าใจอย่างกว้างขวาง ยุติธรรม และชัดเจน
ถ้อยคำว่า “ผลิตภัณฑ์หรือบริการที่เสนอให้ผู้ใช้หรือลูกค้านอกองค์กรและมีฟังก์ชันซ้อนทับอย่างมีนัยสำคัญ” นั้นเจ็บปวด ตามตัวข้อความแล้ว (1) ไม่ชัดเจน และ (2) อำนาจเหนือความคลุมเครือนั้นเอนเอียงไปทางบริษัท เปิดทางให้บังคับใช้แบบเลือกปฏิบัติได้
ในสถานการณ์ที่ต้องลงนามในเอกสารทางกฎหมาย คำว่า “ไม่ต้องห่วง จะไม่มีใครตามเล่นงาน” ไม่น่าเชื่อถือ ผมมองว่าการสะสมสิทธิที่ตอนนี้ดูนุ่มนวลหรืออาจนำมาใช้ในอนาคตไว้ในสัญญาเป็นสัญญาณอันตรายใหญ่
อยากรู้ว่าคนอื่นมองไลเซนส์นี้เองอย่างไร
ประเด็น “อีก 2 ปี Terraform Cloud ทำตาม” นั้นดีมาก ขอบเขตของบริษัทเปลี่ยนแปลงได้
ตาม https://www.couchbase.com/blog/couchbase-adopts-bsl-license/ โดยทั่วไป BSL จะกำหนดวันเปลี่ยนแปลงไว้ในช่วง 1–4 ปี และเมื่อถึงเวลานั้น ไลเซนส์ BSL จะเปลี่ยนไปเป็น Change License ที่เป็นโอเพนซอร์ส เช่น GPL, AGPL, Apache เป็นต้น
ดังนั้นคำถามที่สำคัญที่สุดคือ Change License คืออะไร และต้องใช้เวลานานแค่ไหน
ถ้าหลัง 1 ปีเปลี่ยนเป็น MPL 2.0 ก็ยังโอเค แต่ถ้ายาวกว่านั้นมากและมีข้อจำกัดมากกว่า ก็ถือเป็นการเปลี่ยนท่าทีโดยสิ้นเชิง และเวอร์ชันโอเพนซอร์สจะห่างจากเวอร์ชันล่าสุดมากเกินไปจนแทบใช้งานจริงไม่ได้
แก้ไข: คือ MPL 2.0 หลัง 4 ปี
https://www.hashicorp.com/license-faq#What's-the-difference-...
เมื่อเกี่ยวข้องกับความปลอดภัย 4 ปีก็แทบเป็นแค่ “ความสนใจเชิงประวัติศาสตร์” เท่านั้น
4 ปี, MPL 2.0
ไม่รู้ว่าบริษัทอื่นเป็นอย่างไร แต่ผมมักถามตัวเองเสมอว่า ซอฟต์แวร์ของบริษัทเหล่านี้จะอยู่ตรงไหนในวันนี้ ถ้ามันเป็น ไลเซนส์ที่ไม่เสรี มาตั้งแต่ต้น
เรื่องนี้เป็นปฏิปักษ์ไม่ใช่แค่กับบริษัทยักษ์ใหญ่ที่อยาก “ขโมย” โค้ดไปทำเป็นบริการ แต่ยังรวมถึงผู้ใช้ปลายทาง คนตัวเล็ก ๆ และบริษัทเล็ก ๆ ด้วย
ถ้าคุณดำเนินงานและใช้ซอฟต์แวร์ของ HashiCorp ได้สำเร็จ แล้วถูกมองว่าเป็นคู่แข่ง HashiCorp ก็อาจตัดสินใจปิดกั้นคุณได้
เช่น https://github.com/hashicorp/vault/blob/main/go.mod#L25
ถ้าเริ่มด้วย BSL ตั้งแต่แรก ก็คงไม่น่าถูกนำไปใช้อย่างแพร่หลายขนาดนี้
หน้า CLA ของ HashiCorp เมื่อสองเดือนก่อน: https://web.archive.org/web/20230610041432/https://www.hashi...
ระบุไว้ว่า “เพื่อให้ HashiCorp สามารถสร้างธุรกิจที่ยั่งยืนได้ พร้อมทั้งทำให้โปรเจกต์ยังคงอยู่ภายใต้ไลเซนส์เสรีและโอเพนซอร์ส เช่น MPL2 เราจึงกำหนดให้ผู้ร่วมพัฒนาภายนอกลงนามใน Contributor License Agreement (CLA)”
และยังระบุว่า “HashiCorp ให้คำมั่นว่าจะใช้ไลเซนส์ซอฟต์แวร์เสรีและโอเพนซอร์ส (FOSS) อย่างแท้จริงกับซอฟต์แวร์ที่ไม่ใช่เชิงพาณิชย์ CLA ช่วยให้ HashiCorp ทำผลิตภัณฑ์เชิงพาณิชย์ได้อย่างปลอดภัย ขณะเดียวกันผู้ใช้ยังคงสิทธิทั้งหมดที่ไลเซนส์ FOSS มาตรฐานมอบให้ เช่น สิทธิในการใช้ในโปรเจกต์หรือธุรกิจของตนเอง การเผยแพร่ซอร์สที่แก้ไขซ้ำ และการ fork อย่างสมบูรณ์”
น่าผิดหวังที่ถ้อยคำที่ไม่ใช่ภาษากฎหมายบนหน้านั้นบอกเป็นนัยซ้ำ ๆ ว่าการลงนาม CLA ช่วยให้โปรเจกต์ของ HashiCorp คงความเป็นโอเพนซอร์สไว้ แต่ถ้อยคำในสัญญาจริงกลับไม่ได้รับประกันเรื่องนั้น
ควรมีใครสักคนลองท้าทายดู เมื่อสมมติฐานของ CLA คือกรณีที่ contribution ถูก relicensing เป็น non-FOSS ได้เปลี่ยนไป
CLA ส่วนใหญ่แห้งแล้งมาก แต่ HashiCorp ใส่คำประกาศหลายอย่างไว้ใน CLA ของตัวเอง จึงอาจทำให้ลำบากได้
เหตุผลเดียวที่เรียกร้องสิ่งนั้นคือการ relicensing และถ้าเป็น FOSS อยู่แล้ว เหตุผลเดียวที่จะ relicensing ก็คือเพื่อไปสู่ซอฟต์แวร์กรรมสิทธิ์
Linux ไม่กำหนดให้ต้องมี CLA สำหรับ contribution มีแต่พวกตัวตลกที่ทำทีเป็นโอเพนซอร์สพวกนี้เท่านั้นที่เรียกร้อง
บริษัท OSS ของเราใช้ Apache 2.0 และสร้างโดยมี Nomad เป็นแกนหลัก
เราเพิ่มบริการบางอย่างรอบ ๆ เพื่อให้บริการ orchestration สำหรับเกมเซิร์ฟเวอร์ ซึ่งอาจถูก HashiCorp เข้าใจผิดว่าเป็น “การให้บริการผลิตภัณฑ์คู่แข่ง” ได้
เพราะไลเซนส์จงใจทำให้คลุมเครือ เราจึงจะ freeze เวอร์ชัน Nomad ไว้ที่เวอร์ชัน MPL สุดท้าย
เราใช้ CockroachDB ด้วย และมันเป็น BSL แต่เราไม่ได้ให้บริการผลิตภัณฑ์ที่แข่งกับฝั่งนั้นเลย
เราน่าจะยังคงแนะนำผลิตภัณฑ์ของ HashiCorp อย่าง Nomad, Consul, Terraform, Packer ต่อไปสำหรับคนที่มาขอคำปรึกษา แต่การเปลี่ยนแปลงครั้งนี้ฟังดูน่าผิดหวัง
สำหรับคนที่สนใจ เราดูแล SBOM แบบง่าย ๆ ไว้ที่นี่: https://github.com/rivet-gg/rivet/blob/main/docs/infrastruct...
ผมเป็นหัวหน้าฝ่ายวิศวกรรมของ Nomad ไลเซนส์อยู่นอกเหนือการควบคุมของผม แต่มีผู้ใช้จำนวนมากที่กังวลว่า สักวันหนึ่งอาจถูกตีความว่าเป็นการแข่งขัน
ผมสัญญาไม่ได้ แต่จะพยายามทำทุกอย่างเท่าที่ทำได้เพื่อให้คุณมั่นใจว่า Nomad ยังเป็นเครื่องมือที่เหมาะกับงานของคุณ
โดยส่วนตัวคิดว่าไม่มีปัญหา ถ้าเป้าหมายสุดท้ายคือการเป็นแพลตฟอร์ม SaaS ก็อยากให้โปรเจกต์โอเพนซอร์สมากขึ้นเริ่มต้นด้วย Business Source License ตั้งแต่แรก
เห็นซ้ำแล้วซ้ำเล่าว่าบริษัทใหญ่ ๆ ใช้จิตวิญญาณโอเพนซอร์สในทางที่ผิดเพื่อผลประโยชน์ทางการเงินของตัวเอง ไม่คืนอะไรกลับมาเลย และทำตัวอย่างมุ่งร้าย
การใช้สิ่งที่เปิดเผยและทำให้เข้าถึงได้ ไม่ได้ถูกมองว่าเป็นการกระทำที่มุ่งร้าย และพวกเขาก็ยินดีจะแจกฟรีด้วย
ถ้าไม่ใช่แบบนั้น ก็ไม่ใช่โอเพนซอร์ส แน่นอนว่าซอฟต์แวร์ทุกตัวไม่จำเป็นต้องเป็นโอเพนซอร์ส ดังนั้นแบบนั้นก็ไม่เป็นไร
คนที่ใช้จิตวิญญาณโอเพนซอร์สในทางที่ผิดคือฝ่ายที่สร้างกฎเกณฑ์ตามอำเภอใจเกี่ยวกับการใช้งาน
ถึงอย่างนั้น การทำให้ชัดเจนตั้งแต่แรกก็น่าจะดีกว่า