Bear เปลี่ยนมาใช้ไลเซนส์แบบเปิดเผยซอร์สแล้ว
(herman.bearblog.dev)- โปรเจกต์ Bear เปลี่ยนจากไลเซนส์ MIT ไปเป็น Elastic License
- ไลเซนส์ MIT เดิมอนุญาตให้ใช้งานโค้ดและ fork ได้อย่างอิสระ แต่ไลเซนส์ใหม่ได้ จำกัดการนำไปให้บริการแบบโฮสต์
- โปรเจกต์โอเพนซอร์สหลายรายก็กำลังปรับใช้การเปลี่ยนไลเซนส์ลักษณะคล้ายกันเพื่อ ป้องกันการแข่งขันแบบใช้ฟรี
- ในยุค AI การ คัดลอกโค้ดและทำเป็นบริการ กลายเป็นเรื่องที่ทำได้ง่ายมาก
- ความเปิดเผยของโค้ดก็สำคัญ แต่หัวใจของ Bear คือ ชุมชนผู้ใช้และความตั้งใจในการดูแลต่อเนื่อง
เบื้องหลังการเปลี่ยนไลเซนส์แบบเปิดเผยซอร์สของ Bear
- ในช่วงแรก โปรเจกต์ Bear เปิดเผยซอร์สภายใต้ ไลเซนส์ MIT โดยมีเป้าหมายเพื่อให้เกิดการเรียนรู้และ การตรวจสอบได้ รวมถึงสร้างความเชื่อมั่นด้าน ความเป็นส่วนตัวและความปลอดภัย ให้กับผู้ใช้
- แต่เมื่อเวลาผ่านไป ก็มีกรณีของ บริการคู่แข่ง ที่สร้างขึ้นจากโค้ดของโปรเจกต์ Bear ปรากฏขึ้น
- แม้จะพัฒนาซอฟต์แวร์ของตัวเองด้วยความรัก แต่เมื่อซอร์สถูก คัดลอกได้ง่ายและย้อนกลับมาเป็นคู่แข่ง ก็ทำให้เกิดทั้งความรู้สึกสูญเสียและความกังวลทางเศรษฐกิจ
- แม้จะเชื่อในคุณค่าของโอเพนซอร์ส แต่ในทางปฏิบัติก็ต้องเผชิญกับความยากลำบากจริง
การตัดสินใจเปลี่ยนไลเซนส์
- จากเหตุการณ์ล่าสุด จึงตัดสินใจเปลี่ยนไลเซนส์จาก MIT License เป็น Elastic License (แนวทางคอปี้เลฟต์ที่นำมาใช้ใน Elastic Search)
- Elastic License คล้ายกับ MIT แต่ห้าม การนำซอฟต์แวร์ไปให้บริการแบบโฮสต์หรือบริการแบบจัดการ
- ดูรายละเอียดข้อกำหนดของไลเซนส์ได้ที่ GitHub link
แนวโน้มในระบบนิเวศโอเพนซอร์ส
- จากการสำรวจพบว่า โปรเจกต์โอเพนซอร์สจำนวนมาก ในช่วงไม่กี่ปีที่ผ่านมา กำลังมีแนวโน้มจำกัดไลเซนส์เพื่อป้องกัน “การแข่งขันแบบอาศัยของฟรี”
- ตัวอย่าง: Plausible, Fathom, Grafana, Snowplow, ScyllaDB, Sentry และอีกหลายโปรเจกต์ได้ตัดสินใจในทำนองเดียวกัน
ยุค AI และการแข่งขันที่รุนแรงขึ้น
- การมาถึงของ เครื่องมือเขียนโค้ดด้วย AI ทำให้สามารถ คัดลอกและทำเป็นบริการได้อย่างรวดเร็ว เช่น “fork รีโพซิทอรีนี้ เปลี่ยนชื่อ แล้ว deploy ลง EC2”
- การเปลี่ยนแปลงของสภาพแวดล้อมเช่นนี้ ทำให้ผู้สร้างต้นฉบับต้องแบกรับภาระและความเสี่ยงมากขึ้น
คุณค่าพิเศษของ Bear
- คุณค่าที่แท้จริงของแพลตฟอร์ม Bear ไม่ได้อยู่ที่ ตัวซอร์สเพียงอย่างเดียว แต่เกิดจาก ชุมชน ที่ใช้งานมัน และ ความรับผิดชอบระยะยาวของผู้ดูแล
- แม้ต่อจากนี้จะมีข้อจำกัดบางส่วนในระดับโค้ด ก็ยังยืนยันเจตนาที่จะ ดูแลรักษาแพลตฟอร์มอย่างจริงจัง ต่อไป
3 ความคิดเห็น
ดูเหมือนว่า GLPv3 และ AGPL จะไม่ได้ถูกใช้งานตามเจตนาของผู้สร้างไลเซนส์เหล่านี้
เพราะส่วนใหญ่ยอมให้ใช้แบบ dual license สุดท้ายเลยเห็นบ่อยมากว่ามันถูกใช้เป็นเครื่องมือบังคับการใช้งานเชิงพาณิชย์
ในความหมายนั้น ผมคิดว่า Apache กับ MIT เป็นไลเซนส์โอเพนซอร์สไม่กี่ตัวที่ยังทำงานได้ตามเจตนาแรกเริ่ม
(แต่ก็ไม่ได้คิดว่ามีไลเซนส์โอเพนซอร์สที่สมบูรณ์แบบไร้ที่ติอยู่จริง)
ความคิดเห็นบน Hacker News
เท่าที่ฉันเข้าใจ ฝั่ง 'Open Source' มีจุดยืนว่าถ้า Amazon เอาไปให้บริการบน AWS ไม่ได้ สิ่งนั้นก็ไม่ใช่โอเพนซอร์สที่แท้จริง และถ้าใครเถียงแบบนั้นก็จะไม่พอใจมาก
ฉันอยากให้ทุกคนยอมรับปรากฏการณ์ 'การแข่งขันแบบเกาะกินฟรี' ที่ผู้เขียนพูดถึงให้มากกว่านี้ สิ่งที่ Herman กำลังทำเป็นเรื่องที่เป็นประโยชน์กับทุกคน จึงอยากให้มีคำใหม่ที่อบอุ่นกว่า "source-available" และสะท้อนความเป็นโปรเจกต์ชุมชนได้ดีกว่า
ขอเสริมด้วยความเห็นที่สรุปความคิดของฉันได้ดีจากคอมเมนต์ด้านล่าง:
โครงสร้างตลาดแบบผู้ชนะกินรวบตามธรรมชาติไม่ได้ช่วยภารกิจของซอฟต์แวร์เสรีและโอเพนซอร์ส (FOSS) หากไม่ป้องกันไม่ให้บริษัทใหญ่ทำกำไรด้วยวิธีนี้ ก็จะยิ่งบ่อนทำลายพันธกิจของโอเพนซอร์สอย่างรุนแรง และระหว่างนั้นก็ทำให้ผู้ใช้ติดกับดักที่ผูกซอฟต์แวร์ผูกขาดของบริษัทยักษ์ใหญ่เข้ากับ FOSS
เดิมทีท่าทีของฝั่งโอเพนซอร์สคือสนับสนุนไลเซนส์อย่าง GPL → GPLv3 → AGPL ซึ่งป้องกันปัญหาแบบนี้ได้ชัดเจน
การที่ไลเซนส์แบบให้สิทธิเต็มที่อย่าง MIT/BSD/Apache ถูกใช้อย่างแพร่หลาย ดูเหมือนเป็นกระแสที่จงใจทำให้อุดมการณ์ซอฟต์แวร์เสรีอ่อนแรงลงตามผลประโยชน์ของภาคธุรกิจ
คนส่วนใหญ่ไม่ได้มีปัญหาอะไรกับซอฟต์แวร์ที่ไม่ใช่โอเพนซอร์สมากนัก
ปัญหาคือโปรเจกต์อย่าง Terraform ได้รับความนิยมและเติบโตเพราะเป็นโอเพนซอร์ส แต่พอผู้ดูแลเปลี่ยนไปใช้ไลเซนส์แบบปิด ก็เท่ากับฐานแห่งความสำเร็จเดิมหายไป
ยิ่งไปกว่านั้น กรณีที่ผู้มีส่วนร่วมเซ็น CLA (Contributor License Agreement) แล้วโค้ดของพวกเขายังถูกเปลี่ยนเป็นไลเซนส์ปิดได้ตามใจ ยิ่งน่าผิดหวังเป็นสองเท่า
ถ้าไม่สนใจโอเพนซอร์สก็แค่ไม่ต้องใช้ ตลอดมาคำว่าโอเพนซอร์สมีความหมายที่ชัดเจนและสม่ำเสมอ
แต่ละคนก็สร้างซอฟต์แวร์ได้อย่างเสรี และเลือกใช้ตามคุณค่าที่ตัวเองเชื่อได้ ไม่เห็นว่าต้องเป็นปัญหาอะไร
ใครจะใช้ไลเซนส์อะไรก็ได้ตามต้องการ แต่ก็ควรคิดว่าทำไมนักพัฒนาโอเพนซอร์สส่วนใหญ่ถึงเลือกไลเซนส์ผ่อนปรนอย่าง MIT
ในทางปฏิบัติ มีโอเพนซอร์สดี ๆ ในตลาดมากจนตัวเลือกกว้างมาก ถ้าใส่ข้อจำกัดในไลเซนส์ คนก็มักจะไปเลือกทางเลือกอื่นแทน
เพราะอย่างนั้น ถ้าใช้ไลเซนส์ตระกูล GPL โปรเจกต์ก็มักจะถูกใช้อย่างแพร่หลายได้ยาก แน่นอนว่ามีข้อยกเว้นอย่าง Linux หรือ WordPress ที่ประสบความสำเร็จมาก แต่ก็ไม่ได้เป็นปรากฏการณ์ทั่วไป
ถึงแม้ไลเซนส์ผ่อนปรนแบบ MIT จะทำรายได้ยากอยู่แล้ว แต่ถ้าไม่มีผู้ใช้เลยก็ยิ่งยากกว่า
จะมองว่าดีหรือไม่ดียังถกเถียงกันได้ แต่ในความเป็นจริงทุกคนก็ดูจะกำลังตัดสินใจอย่างมีเหตุผล โดยพื้นฐานแล้วซอฟต์แวร์ไม่ได้หายากขนาดนั้น
AGPL ก็ถูกสร้างมาเพื่อกรณีแบบนี้ไม่ใช่หรือ?
AGPL เป็นไลเซนส์โอเพนซอร์สที่ OSI รับรอง และมีข้อจำกัดเมื่อนำซอฟต์แวร์ไปให้บริการผ่านเครือข่าย
สงสัยว่าผู้ดูแลได้ลองดู Fair Source หรือยัง fair.io
ฉันคิดว่า Fair Source ดีกว่า 'source-available' และยังเป็นเส้นทางไปสู่โอเพนซอร์สเต็มรูปแบบภายใต้ DOSP(opensource.org/dosp) ด้วย จึงเป็นประโยชน์ทั้งกับผู้ใช้ฟรีและผู้จ่ายเงิน และเหมาะมากกับแพลตฟอร์มบล็อกอย่าง Bear
FCL(fcl.dev) Fair Source License ก็มีแนวคิดคล้ายกับ Bear Blog License และเข้ากับ Bear manifesto(herman.bearblog.dev/manifesto/) ได้ดี
ต่อให้ Bear PTY LTD หายไป Bear เองก็ยังคงอยู่ต่อได้ในโครงสร้างแบบนี้ (สามารถกำหนดผ่าน DOSP ได้)
อนึ่ง ฉันก็มีส่วนร่วมในการร่าง Fair Source ด้วย
ถึงอย่างนั้น คำว่า 'fair source' ก็ฟังดูใช้ได้ดี
ถ้าเป็นซอฟต์แวร์ที่เมื่อเวลาผ่านไปจะกลายเป็นโอเพนซอร์สแบบ Apache หรือ MIT ก็นับเป็น fair source ได้เลยหรือเปล่า หรือว่ามีเกณฑ์ที่ซับซ้อนกว่านั้น
บางคนดูจะไร้เดียงสาพอสมควร ถ้าเลือก MIT license ก็หมายความว่าใครจะเอาโค้ดฉันไปใช้อย่างไรก็ได้ พอภายหลังอยากหารายได้ก็เลยเปลี่ยนไปใช้ไลเซนส์ประหลาดเพื่อแก้ปัญหา
สุดท้ายตัวเลือกก็มีแค่ MIT/BSD, GPL, LGPL, AGPL และไลเซนส์อื่นนอกเหนือจากนี้ก็มีแต่สร้างปัญหาความเข้ากันได้โดยไม่จำเป็น
ฉันก็เห็นด้วยกับมุมมองนี้ ถ้าต้องการเปิดซอร์สแบบ 'ไม่มีเงื่อนไขจริง ๆ' ก็เลือก MIT ไปเลย
ในกรณีนี้ดูเหมือนจะไม่ได้เลือกเพราะเชื่อแบบนั้นอย่างชัดเจน แต่เหมือนพยายามจะเป็นทั้ง 'คนดี' และ 'นักธุรกิจ' ไปพร้อมกันแบบกำกวมมากกว่า
ฉันคิดว่า MPL (Mozilla Public License) ก็เป็นไลเซนส์ที่มีประโยชน์มากและถูกประเมินค่าต่ำไป
มันติดเชื้อน้อยกว่าไลเซนส์ตระกูล GPL ชัดเจน และมีข้อจำกัดมากกว่า MIT/BSD (หากแจกจ่ายเวอร์ชันที่แก้ไขแล้ว ต้องเปิดซอร์สส่วนที่แก้ไข)
MIT และ BSD ไม่ได้มีการรับประกันสิทธิด้านสิทธิบัตร ดังนั้นนี่จึงเป็นเหตุผลที่ควรเลือก Apache License
Guy (คนสร้าง) ดูเหมือนจะตั้งใจแค่สร้างโปรเจกต์ของตัวเองและให้ความสำคัญกับการเปิดซอร์ส
ฉันไม่คิดว่าเขามีเป้าหมายเชิงกลยุทธ์อย่างอื่นเป็นพิเศษ
ผู้ใช้ที่เชื่อว่าโปรเจกต์โอเพนซอร์สจะเป็นโอเพนซอร์สตลอดไปก็ไร้เดียงสาเหมือนกัน
ผู้เขียนมีสิทธิเปลี่ยนไลเซนส์อยู่แล้ว การตกใจกับเรื่องนี้ รวมถึงการเชื่อว่าการทำธุรกิจบนโอเพนซอร์สจะง่าย ล้วนเป็นความไร้เดียงสาทั้งนั้น
ถ้าต้องการปิดกั้นการใช้งานเชิงแข่งขันตั้งแต่ต้น โดยทั่วไปก็ต้องทำแบบนี้ การเลิกใช้คำว่าโอเพนซอร์สก็เป็นทางเลือกที่ถูกต้องแล้ว
แต่ในสถานการณ์ส่วนใหญ่ ฉันคิดว่า AGPL เป็นทางเลือกที่ดีกว่า ถ้าเป็น AGPL บริษัทใหญ่จะใช้โค้ดไม่ได้เพราะกฎภายในของตัวเอง จึงช่วยกันผู้เล่นรายใหญ่ไม่ให้เข้ามาได้
มันเป็นการทรยศต่อความหมายดั้งเดิมของโอเพนซอร์ส
"เปิดด้วย MIT แล้วตอนนี้มีคนเอาโค้ดฉันไปใช้ทำธุรกิจหาเงิน ฉันแปลกใจที่เขาไม่คาดคิดว่ามันจะออกมาแบบนี้"
ทำไมเรื่องแบบนี้ถึงเกิดซ้ำแล้วซ้ำเล่า? ฉันสงสัยว่าทำไมนักพัฒนาจำนวนมากถึงมองไม่เห็นผลลัพธ์ที่ชัดเจนขนาดนี้
MIT เคยเป็นค่าเริ่มต้นที่เลือกง่ายมากตอนสร้างโปรเจกต์ใหม่บน GitHub แค่เลือกจาก dropdown ก็ได้เลย เป็นค่าเริ่มต้นที่มีแรงเสียดทานต่ำ
ตอนที่โปรเจกต์ยังใหม่และยังไม่รู้ว่าจะเติบโตไปทางไหน ก็ยากจะจินตนาการว่ามันจะใหญ่พอจนต้องกังวลเรื่องไลเซนส์ในภายหลัง
เดิมที MIT license ก็อนุญาตให้โปรเจกต์ relicense ใหม่ได้ทุกเมื่ออยู่แล้ว
ผู้ดูแล Bear แค่เลือกไลเซนส์ผ่อนปรนในตอนแรก แล้วเมื่อสถานการณ์เปลี่ยนก็เปลี่ยนเป็นไลเซนส์ที่เข้มงวดขึ้น
สำหรับฉัน นี่เป็นการตัดสินใจที่มีเหตุผลมาก
ฉันคิดว่าเป็นเพราะฝั่ง BSD ชนะสงครามวัฒนธรรมโอเพนซอร์สเมื่อ 15~20 ปีก่อน
ถ้าฝั่งไลเซนส์ GNU เป็นผู้ชนะ สงสัยว่าวันนี้ระบบนิเวศจะต่างออกไปอย่างไร
ฉันเคยสนับสนุน Bear เพราะมันเป็นโอเพนซอร์ส แต่ถ้าไม่ใช่แล้วก็ไม่มีเหตุผลจะสนับสนุนต่อ เลยยกเลิกการสมัครไป
ถ้ามันกลับไปเป็น AGPL ได้ก็คงน่ายินดีมาก
Bear มีอิสระที่จะใช้ไลเซนส์ตามต้องการ และฉันก็มีอิสระที่จะตัดสินใจว่าจะใช้หรือไม่
จุดประสงค์ของไลเซนส์โอเพนซอร์สโดยพื้นฐานคือการแบ่งปัน ไม่ใช่ผลประโยชน์ทางการเงิน
การสนับสนุนเฉพาะโปรเจกต์โอเพนซอร์สก็เข้าใจได้อย่างยิ่ง
เมื่อถึงจุดที่ต้องสร้างรายได้ ไลเซนส์โอเพนซอร์สอาจไม่เหมาะสมอีกต่อไป
นักพัฒนาบางคนเข้าใจผิดว่าโอเพนซอร์สจะปกป้องรายได้ของตน และผู้ใช้บางคนก็เข้าใจผิดว่าโปรเจกต์จะคงเป็นโอเพนซอร์สตลอดไป
โมเดลอย่าง source-available หรือ shipped-with-source ก็เป็นไลเซนส์แบบปิด (proprietary) ชนิดหนึ่ง ไม่จำเป็นต้องเป็นโอเพนซอร์สเสมอไป
“ผู้ใช้ต้องไม่โฮสต์หรือให้บริการในรูปแบบ managed service ที่มอบฟังก์ชันหลักของซอฟต์แวร์”
ฉันไม่ใช่ทนาย แต่สงสัยว่าข้อจำกัดนี้ครอบคลุมถึงการติดตั้งแล้วรัน Bear เองเพื่อใช้ภายในบริษัทหรือใช้ส่วนตัวด้วยไหม
ถ้าแม้แต่แบบนั้นยังไม่ได้จริง ๆ ก็ไม่เข้าใจเลยว่าทำไมถึงเคยใช้ MIT license
ต้นฉบับ Bear Blog License
แต่ไม่สามารถนำไปให้คนอื่นหรือบริษัทอื่นใช้งานในรูปแบบบริการได้
ดูเพิ่มเติม: Elastic License FAQ
ฉันเข้าใจความรู้สึกหมดแรงนั้น แต่ไลเซนส์ใหม่ค่อนข้างกำกวม
พอบอกว่า "ห้ามให้ฟังก์ชันผ่านบริการโฮสต์/managed service" แบบนี้ ผู้ให้บริการ VPS ทั่วไป (ที่ติดตั้งผ่าน package manager) ก็เข้าข่ายถูกจำกัดด้วยหรือเปล่า?
ถ้ามีสคริปต์ตั้งค่าแบบ 1-click install จะนับอย่างไร หรือแค่ไม่พูดถึงในขั้นตอนให้บริการก็ถือว่าไม่ผิด? มันกำกวมมาก
รู้สึกเหมือนเป็น 'ละคร' ที่ว่าถ้าบุคคลที่สามเป็นคนให้สคริปต์ติดตั้ง แล้วในขั้นตอนให้บริการไม่พูดถึง ก็ทำได้หมด
กล่าวคือ ห้ามนำซอฟต์แวร์ไปให้ผู้อื่นใช้เป็นบริการ (ฟรี/เสียเงิน) แต่ถ้าใช้เองคนเดียวก็ไม่มีปัญหา
แก่นสำคัญคือควรมองว่าการให้บัญชีผู้ใช้นั่นแหละที่ถูกห้าม
การให้บริการโฮสต์แบบพร้อมใช้ก็ถูกห้ามเช่นกัน แต่ปัญหาไม่ได้อยู่ที่ฝ่ายที่ให้โฮสต์ แต่อยู่ที่ฝ่ายที่สร้างบัญชีผู้ใช้บนอินสแตนซ์โฮสต์นั้นแล้วขายต่อ
ถ้อยคำนี้มีไว้เพื่อกันบริษัทใหญ่อย่าง Amazon ไม่ให้เปิดอินสแตนซ์ฐานข้อมูลให้คนภายนอกแล้วแจกบัญชีบนระบบนั้น
ในทางกลับกัน การติดตั้งผ่าน package manager บน VM แบบธรรมดาทำได้
ถึงอย่างนั้น ไลเซนส์ลักษณะนี้ก็สับสนและไม่ชัดเจนมาก
ถ้าตั้งใจจะคงไว้เป็นโอเพนซอร์สและอยากให้คนใช้เยอะ แต่ไม่ต้องการให้คนอื่นโฮสต์ให้ ก็ไม่จำเป็นต้องแชร์โค้ดเลย ปล่อยเป็น 'All rights reserved' ไปก็พอ
ฉันเข้าใจแรงจูงใจและเจตนาที่อยากเปิดซอร์ส แต่ถ้ากังวลเรื่องการแข่งขัน ก็น่าจะพิจารณา AGPL แทน MIT ตั้งแต่แรก เลยสงสัยเหมือนกัน
AGPL สุดท้ายแล้วคนอื่นก็ยังเอาโค้ดไปขายเชิงพาณิชย์ต่อแบบแทบไม่แก้ได้ไม่ใช่หรือ?
AGPL แค่บังคับให้ต้องเปิดซอร์สส่วนที่แก้ไขเท่านั้น
ดูเหมือนว่าปัญหาในที่นี้คือมีคนเอา Bearblog ไปให้บริการเชิงพาณิชย์แทบจะทั้งดุ้น หรือแค่เปลี่ยนชื่อเล็กน้อยเท่านั้น
อาจเป็นเพราะตอนแรกเขาไม่ได้คิดว่าการแข่งขันเป็นปัญหา แต่พอเวลาผ่านไปจึงเห็นว่าเป็นปัญหาแล้วค่อยเปลี่ยนไลเซนส์
โดยส่วนตัวฉันคิดว่าวิธีนี้ (เปิดซอร์ส + จำกัดการโฮสต์ ฯลฯ) เป็นโมเดลไลเซนส์ที่ดีที่สุด
ฉันยังดูและแก้โค้ดได้ตามใจชอบ ขณะเดียวกันโปรเจกต์และผู้ดูแลก็รักษาฐานของตัวเองไว้ได้โดยไม่ต้องแบกรับการแข่งขันเกินควร
ถ้าเริ่มแบบนี้ตั้งแต่แรก ก็จะป้องกันปัญหาการเปลี่ยนกะทันหันในภายหลังจนเกิดดราม่า หรือกรณีที่ฟอร์กแซงต้นฉบับได้ด้วย
ถึงอย่างนั้น ฉันก็ไม่คิดว่า Bear จะเป็นโปรเจกต์ที่ใหญ่พอจะสร้างแรงสั่นสะเทือนขนาดนั้น
ฉันเองก็ยังใช้ mataroa.blog เป็นครั้งคราวอยู่เหมือนกัน และหวังว่าผู้ดูแล Bear จะยังรู้สึกเติมเต็มกับโปรเจกต์ของตัวเอง
จริง ๆ แล้วโปรเจ็กต์โอเพนซอร์สแทบจะมีเพียงความสนใจและการมีส่วนร่วมของผู้ใช้เท่านั้นที่เป็นทรัพยากรหลัก
หากยังไม่ได้ตั้งหลักได้อย่างมั่นคง แล้วใครก็ได้ โดยเฉพาะบริษัทใหญ่ มา fork ไปและผูกขาดความสนใจเอาไว้เสียเอง ก็จะกลายเป็นว่าเราทำเพื่อประโยชน์ของคนอื่นล้วน ๆ
แต่เดิมไลเซนส์เหล่านี้ก็มีไว้เพื่อเสรีภาพของผู้ใช้ ไม่ใช่เพื่อผู้พัฒนาอยู่แล้วตั้งแต่ต้น
ทราบไหมว่า
wingetซึ่งเป็นตัวจัดการแพ็กเกจ CLI ของ Windows ก็เป็นกรณีที่ Microsoft fork โปรเจ็กต์ของคนอื่นไปทั้งดุ้น แล้วเปลี่ยนแค่ชื่อก่อนนำออกมาเปิดตัวยังมีบทความที่เขียนโดยผู้สร้างโปรเจ็กต์ต้นฉบับ
appgetด้วยThe Day AppGet Died.
หากคุณเป็นคนที่ไม่ต้องการทำเพื่อประโยชน์ของคนอื่นอย่างเดียว และเห็นคุณค่าในเวลาของตัวเอง (โดยเฉพาะบริษัทใหญ่หรือคนที่เก่งด้านไวรัล) ก็ควรพิจารณาอีกครั้งว่าจะเลือกใช้ไลเซนส์โอเพนซอร์สหรือไม่
ถึงจะเป็นการอาสาเหมือนกัน แต่การได้รับความเคารพต่อการมีส่วนร่วม กับการถูกเมินเฉยอย่างสิ้นเชิงนั้นต่างกันมาก
ลองดูทางเลือกอื่น ๆ แบบที่มีคนเสนอไว้ในคอมเมนต์บน Hacker News ครับ