จะเลือกใช้แพ็กเกจโอเพนซอร์สสำหรับซอฟต์แวร์ธุรกิจอย่างไร? คำแนะนำในการลดความเสี่ยงด้านใบอนุญาตและสถาปัตยกรรมตั้งแต่ MIT, BSD จนถึง Apache 2.0

ในฐานะวิศวกรซอฟต์แวร์หรือสถาปนิก เรามักจะให้ความสำคัญกับประสิทธิภาพระหว่างการพัฒนา เมื่อเราเห็นแพ็กเกจโอเพนซอร์สที่ทรงพลังบน GitHub ซึ่งมีดาวจำนวนมากและมีเอกสารที่สวยงาม นิ้วของเรามักจะพิมพ์ pnpm add หรือ npm install โดยสัญชาตญาณ

แต่คุณเคยคิดไหมว่าเครื่องมือที่ดู “ฟรี” และ “เสรี” เหล่านี้อาจซ่อนระเบิดเวลาที่ทำให้บริษัทของคุณเสี่ยงต่อการละเมิดสิทธิบัตรได้?

ในการพัฒนาซอฟต์แวร์เชิงพาณิชย์ นอกเหนือจากความสามารถทางเทคนิคแล้ว เราควรทำความเข้าใจความหมายและเงื่อนไขเบื้องหลังโปรโตคอลโอเพนซอร์ส (ใบอนุญาต) เหล่านี้อย่างไร?

ทำความเข้าใจขอบเขตของ “เป็นมิตรต่อธุรกิจ”

ในโลกโอเพนซอร์ส ของ “ฟรี” ไม่ได้สร้างมาเหมือนกันทุกประการ โดยทั่วไปเราแบ่งใบอนุญาตทั่วไปออกเป็นสองค่ายหลัก:

1. เป็นมิตรกับธุรกิจอย่างมาก (Permissive Licenses)

จิตวิญญาณหลักของใบอนุญาตประเภทนี้คือ: “เอาไปใช้ได้เลย แค่ต้องระบุว่าฉันเป็นคนเขียน และถ้ามีอะไรผิดพลาดก็อย่ามาตามหาฉัน” สำหรับบริษัทที่พัฒนาผลิตภัณฑ์เพื่อการขาย สิ่งเหล่านี้ก็เหมือน “ใบปลิวแจกฟรี” ตามท้องถนน คุณสามารถนำไปเป็นที่รองกล่องข้าวมื้อเที่ยง พับเป็นเครื่องบินกระดาษ หรือแม้แต่นำไปทำแพ็กเกจใหม่เป็นผลิตภัณฑ์อันยอดเยี่ยมของคุณได้เลย

ใบอนุญาต	คำอธิบาย
MIT	ง่ายที่สุด ให้อิสระสูงสุด (เช่น React, Vue)
BSD (2/3-Clause)	เหมือนพี่น้องของ MIT แต่เน้นให้ความสำคัญกับการยกเว้นความรับผิดตามกฎหมายมากกว่า
Apache 2.0	ตัวเลือกแรกสำหรับธุรกิจ เนื่องจากมีการคุ้มครองเพิ่มเติมสำหรับการให้สิทธิบัตร (patent license)

2. การใช้เชิงพาณิชย์ต้องระมัดระวัง (Copyleft Licenses)

ใบอนุญาตเหล่านี้มี “การแพร่กระจาย” ที่มีชื่อเสียงที่สุดคือตระกูล GPL

มันเหมือนกับการเข้าร่วม “คำสาบานด้วยเลือด” ตราบใดที่คุณอ้างอิงหรือแก้ไขโค้ดประเภทนี้ในโค้ดเบสของคุณ ตามกฎอ้างอิงแล้ว ผลิตภัณฑ์ทั้งหมดของคุณอาจต้องใช้นามสกุลของพวกเขา ซึ่งหมายความว่า คุณจะถูกบังคับให้เปิดเผยซอร์สโค้ดเหล่านั้น

“กับดักสิทธิบัตร” ของใบอนุญาตที่เรียบง่ายที่สุด: ทำไม MIT และ BSD จึงมีความปลอดภัยไม่เพียงพอ?

หลายคนคิดว่า “ใบอนุญาต MIT มีความเสรีมาก ย่อมปลอดภัยแน่นอนสำหรับการใช้งานเชิงพาณิชย์ใช่ไหม?” อย่างไรก็ตาม

“ลิขสิทธิ์ (Copyright)” ตีความไม่เหมือน “สิทธิบัตร (Patent)”

ใบอนุญาต MIT และ BSD นั้นสั้นมาก โดยหลักๆ เป็นการให้สิทธิ์ในการคัดลอกข้อความโค้ด แต่ในช่องโหว่ทางกฎหมาย ผู้เขียนเดิมสามารถอ้างได้ว่า:

“ฉันอนุญาตให้คุณคัดลอกข้อความโค้ด แต่ฉันไม่ได้บอกว่าคุณสามารถใช้สิทธิบัตรทางเทคนิคที่อยู่ในโค้ดได้ฟรีนะ!”

ในทางตรงกันข้าม Apache 2.0 มาพร้อมกับ “ของขวัญแห่งข้อตกลงสงบศึก” มีกลไกการป้องกันที่แข็งแกร่งที่สุดในรหัสด้วยรูปแบบในตัว:

รายการ	เนื้อหา
มอบสิทธิบัตรอย่างชัดแจ้ง	เมื่อผู้เขียนเริ่มปล่อยโค้ด พวกเขาจะลงนามและให้คำมั่นว่าสิทธิบัตรเทคโนโลยีเหล่านั้นจะมอบให้คุณด้วย
เงื่อนไขการตอบโต้ด้านสิทธิบัตร (อาวุธนิวเคลียร์)	หากผู้ใดใช้โค้ดนี้เพื่อฟ้องเรียกร้องสิทธิบัตรกับผู้เขียนแรกเริ่ม ผู้นั้นจะสูญเสียการเข้าถึงสิทธิบัตรสำหรับซอฟต์แวร์นั้นโดยอัตโนมัติ ซึ่งจะนำไปสู่การกำหนด “การหยุดยิงด้านสิทธิบัตร” อย่างเงียบๆ ระหว่างผู้ใช้ และบริษัทรายใหญ่ (เช่น Google, Amazon) จึงชื่นชอบกันเป็นอย่างมาก

รายการ

เนื้อหา

มอบสิทธิบัตรอย่างชัดแจ้ง

เมื่อผู้เขียนเริ่มปล่อยโค้ด พวกเขาจะลงนามและให้คำมั่นว่าสิทธิบัตรเทคโนโลยีเหล่านั้นจะมอบให้คุณด้วย

เงื่อนไขการตอบโต้ด้านสิทธิบัตร (อาวุธนิวเคลียร์)

หากผู้ใดใช้โค้ดนี้เพื่อฟ้องเรียกร้องสิทธิบัตรกับผู้เขียนแรกเริ่ม ผู้นั้นจะสูญเสียการเข้าถึงสิทธิบัตรสำหรับซอฟต์แวร์นั้นโดยอัตโนมัติ ซึ่งจะนำไปสู่การกำหนด “การหยุดยิงด้านสิทธิบัตร” อย่างเงียบๆ ระหว่างผู้ใช้ และบริษัทรายใหญ่ (เช่น Google, Amazon) จึงชื่นชอบกันเป็นอย่างมาก

เมื่อยักษ์ใหญ่คลาวด์เปิดประชันกับผู้สร้างโอเพนซอร์ส

คุณอาจเคยได้ยินข่าวเกี่ยวกับ MongoDB หรือ Elasticsearch เปลี่ยนแปลงสิทธิการใช้งาน นั่นเป็นเพราะบริษัทบนคลาวด์ขนาดใหญ่ (เช่น AWS) มีทักษะดีเยี่ยมในการ “ขึ้นรถไฟฟรี”

เหล่าผู้นำคลาวด์ใช้แพ็กเกจโอเพนซอร์สไปสร้างโฮสต์บริการและทำเงินมหาศาล ทั้งยังแทบไม่ตอบแทนผู้เขียนเลย จึงทำให้ผู้เขียนดั้งเดิมได้ตอบโต้ผ่านข้อเรียกร้องต่างๆ เช่น SSPL:

คุณสามารถใช้งานได้ แต่หากคุณขายซอฟต์แวร์นี้ให้เป็นบริการส่วนหนึ่ง (SaaS) คุณยังคงต้องเปิดเผยซอร์สโค้ดของโครงสร้างระบบคลาวด์ทั้งหมดของคุณด้วย

นี่เป็นการขัดขวางไม่ให้เหล่าบริษัทยักษ์ใหญ่สามารถรีเซลฟีเจอร์เวอร์ชันล่าสุดออกไปอีกทั้งยังได้กดดันบังคับให้บริษัทผู้ใช้งานกลับไปเป็นลูกค้าของโปรเฟสชันนัลระดับ (SaaS) ของผู้ริเริ่มอย่างเดิม

กลยุทธ์การป้องกันของสถาปนิก: การสร้าง “Firewall”

ในฐานะของสถาปนิก คุณควรจะทำอย่างไรหากความจำเป็นบังคับให้คุณใช้แพ็กเกจโอเพนซอร์สที่มีความเสี่ยงสูงด้านคดีละเมิดสิทธิบัตรบ้าง?

ไม่เพียงแค่คุณควรรู้ให้ชัดเจนในวิธีการคัดเลือกเท่านั้น แต่ยังต้องรู้กลยุทธ์สร้าง “Firewall” และป้องกันตัวอีกด้วย ขั้นตอนปฏิบัติส่วนใหญ่มักเป็นการนำเอา รูปแบบโปรแกรมออกแบบโครงสร้าง Adapter Pattern

กล่าวง่ายๆ คุณอย่าทำการเรียกดึงรหัสคำสั่งต่างๆ ในซอร์สโค้ดโดยตรงของซอฟต์แวร์ ขั้นแรกให้คัดแยกข้อกำหนดในชั้นอินเทอร์เฟสเชิงนามธรรมเสียก่อน เป็นเสมือนเจาะรูเสียบปลั๊กไฟฟ้าบนผนัง แม้เบื้องหลังของกระแสไฟฟ้าไม่ว่าจะเป็นกำลังไฟฟ้าที่จากค่าย A หรือค่าย B นั้น การประมวลผลและการใช้สอยในระดับผู้ใช้หรือตรรกะระบบไฟฟ้า ยังคงไร้ซึ่งที่มาเพื่อใช้งานอย่างราบรื่นร่องรอยให้รับรู้เหมือนกันต่อไป

ผ่านการใช้รูปแบบสลับการพิงตัวเองเพื่อสร้างอิสระ (DIP) ระบบตรรกะและการทำงานจากความจำเป็นใช้ของซอร์สโค้ดแพ็กเกจ จะไม่พึ่งพิงส่วนไหน หากกรณีพิพาทเกี่ยวกับค่าใช้งานแพ็กเกจปรากฏ คุณจะมั่นใจได้ในการเปลี่ยนการเชื่อมต่อได้ไวอย่างอิสระด้วยการจัดทำ (Adapter) ในระบบตัวใหม่ทั้งหมดเท่านั้น โดยมันให้ความสามารถที่จะช่วยคุณหลบภัยพ้นปัญหาได้ฉับไว

สรุป: โครงสร้างอาคารที่แข็งแกร่งจำต้องมีฐานเสาเข็มที่มั่นคง

การพิจารณาตัดสินใจรับใช้ใบรับรองโอเพนซอร์สอย่างชัดเจนให้สอดคล้องนับได้ว่าเป็นการวางรากฐานตัวเลือกอย่างมั่นคงได้ก่อน คุณย่อมสร้างความอุ่นใจสำหรับการออกแบบซอฟต์แวร์ก่อโครงสร้างตัวใหญ่

ฉะนั้นในวินาทีครั้งถัดไปที่คุณพบเห็นแพ็กเกจตัวใหม่ โปรดใช้เวลาจำกัดเพียงเล็กน้อย เข้าตรวจสอบเอกสารอนุญาต LICENSE พิจารณาวิเคราะห์รวมถึงอ่านข้อมูลประเภทและความเสี่ยงสิทธิบัตรโดยสืบค้นมาทั้งหมดก่อนจะกระทำสิ่งตามๆ เพื่อวิเคราะห์ประมวลให้สมกับการเตรียมการความตื่นตัวปกป้องพร้อมกับโครงสร้างเชิงรุกอย่างที่ “สถาปนิกซอฟต์แวร์” เป็น เราถึงสามารถเดินทางและมั่นใจได้ต่อการแก้ไขและจัดทำสร้างวงการซอฟต์แวร์ให้อยู่ยืนต่อเนื่องในรูปแบบที่ไม่มีขีดจำกัดได้อย่างแท้จริง.