โอเพนซอร์สคืออะไร? ใบอนุญาตและวิธีทำงานร่วมกันของชุมชน

บทนำ: ทำไมเรื่องโอเพนซอร์สถึงสำคัญกับคุณ

บทความนี้จะพาคุณเข้าใจโอเพนซอร์สแบบครบวงจรตั้งแต่ศูนย์ คุณจะได้เรียนรู้ว่า Open Source Software คืออะไรตามนิยามของ Open Source Initiative (OSI) ทำไมซอฟต์แวร์อย่าง Linux, Python, VS Code ถึงเติบโตได้เพราะชุมชน, ใบอนุญาตยอดนิยมอย่าง MIT, Apache 2.0, GPL ต่างกันอย่างไรในเชิงธุรกิจและกฎหมาย, และแนวปฏิบัติในการมีส่วนร่วม การเป็น Maintainer และการดูแลโปรเจกต์ให้ยั่งยืน เหมาะสำหรับนักพัฒนา นักศึกษา เจ้าของผลิตภัณฑ์ และทุกคนที่อยากใช้หรืออยากสร้างโอเพนซอร์สอย่างถูกวิธี

โอเพนซอร์สคืออะไร

Open Source Software คือซอฟต์แวร์ที่แจกจ่ายภายใต้เงื่อนไขที่ให้ผู้ใช้มีสิทธิใช้ ศึกษา แก้ไข และแจกจ่ายซอร์สโค้ดต่อได้ รวมถึงงานดัดแปลงจากซอร์สโค้ดนั้น ข้อกำหนดกลางคือต้องเข้าถึงซอร์สโค้ดในรูปแบบที่เหมาะสมต่อการแก้ไข ไม่ใช่แค่ไบนารีที่คอมไพล์แล้ว

คำนี้ถูกทำให้เป็นทางการในปี 1998 โดยผู้ก่อตั้ง Open Source Initiative เพื่อวางกรอบเชิงวิศวกรรมที่ต่างจากขบวนการ Free Software ของ Free Software Foundation ที่เริ่มตั้งแต่ปี 1985 แม้ทั้งสองขบวนการจะครอบคลุมซอฟต์แวร์ชุดเดียวกันเป็นส่วนใหญ่ก็ตาม

ตาม The Open Source Definition ที่ดูแลโดย OSI มีเกณฑ์ 10 ข้อที่ใบอนุญาตต้องผ่าน เช่น ต้องอนุญาตให้แจกจ่ายได้อย่างเสรี, ต้องมีซอร์สโค้ด, อนุญาตให้สร้างงานดัดแปลง, ห้ามเลือกปฏิบัติต่อบุคคลหรือสาขาอาชีพ, สิทธิในใบอนุญาตต้องติดไปกับซอฟต์แวร์โดยอัตโนมัติ และต้องเป็นกลางทางเทคโนโลยี

ตัวอย่างที่คุ้นเคยในชีวิตประจำวัน ได้แก่ Linux kernel, Apache HTTP Server, Python, LLVM, Kubernetes และ PostgreSQL ซึ่งแต่ละโครงการมีรูปแบบการบริหารที่วิวัฒนาการมานานหลายทศวรรษ

ประเภทของใบอนุญาต: จาก Permissive ถึง Copyleft

หัวใจของโอเพนซอร์สคือใบอนุญาต (License) ซึ่ง OSI รับรองไว้มากกว่า 80 ใบอนุญาต แบ่งเป็น 2 กลุ่มใหญ่เพื่อเข้าใจง่าย

1. Permissive License – ใจกว้าง ทำธุรกิจต่อง่าย

อนุญาตให้นำไปใช้ในงานปิด (proprietary) ได้โดยมีเงื่อนไขน้อยที่สุด มักขอแค่การระบุที่มา (attribution)

• MIT License: สั้น กระชับ ได้รับความนิยมสูงสุด อนุญาตเกือบทุกอย่างขอแค่คงข้อความลิขสิทธิ์ไว้ ตัวอย่างเช่น React, VS Code
• Apache License 2.0: คล้าย MIT แต่เพิ่มเรื่องการให้สิทธิสิทธิบัตร (patent grant) อย่างชัดเจน และมีข้อกำหนดเรื่องการระบุการเปลี่ยนแปลง เหมาะกับองค์กรใหญ่ ตัวอย่างเช่น Android AOSP, Kubernetes
• BSD 2-clause / 3-clause: คล้าย MIT แต่มีเวอร์ชันที่ห้ามใช้ชื่อโครงการมาโฆษณาโดยไม่ได้รับอนุญาต

ข้อดีคือองค์กรเอาไปต่อยอดเป็นผลิตภัณฑ์ปิดได้ง่าย แต่ข้อเสียคือการปรับปรุงอาจไม่กลับมาที่ชุมชน

2. Copyleft License – ปกป้องให้เปิดต่อไป

กำหนดว่าหากคุณแจกจ่ายงานดัดแปลงในรูปแบบไบนารี คุณต้องแจกจ่ายซอร์สโค้ดภายใต้ใบอนุญาตเดียวกันด้วย คุณสมบัตินี้เรียกว่า copyleft

• GNU General Public License (GPL) v2 / v3: เข้มสุด หากลิงก์หรือรวมโค้ด GPL แล้วแจกจ่าย งานของคุณก็ต้องเป็น GPL ด้วย Linux kernel ใช้ GPL v2
• Lesser GPL (LGPL): ผ่อนปรนสำหรับไลบรารี อนุญาตให้โปรแกรมปิดลิงก์กับไลบรารี LGPL ได้
• Affero GPL (AGPL): เพิ่มเงื่อนไขสำหรับงานบนเครือข่าย หากคุณรัน AGPL เป็นบริการบนเซิร์ฟเวอร์และให้ผู้ใช้ภายนอกใช้งาน คุณต้องเปิดซอร์สโค้ดด้วย เพื่อปิดช่องโหว่ SaaS ของ GPL ปกติ

การเลือกระหว่าง Permissive vs Copyleft จึงเป็นการเลือกระหว่างการเข้าถึงสูงสุดกับการรับประกันว่าโค้ดจะยังคงเปิดตลอดไป

ตารางเปรียบเทียบเร็ว

ใบอนุญาต	ประเภท	งานปิดใช้ได้ไหม	ต้องเปิดซอร์สงานดัดแปลงไหม	มี Patent Grant	เหมาะกับ
MIT	Permissive	ได้	ไม่ต้อง	ไม่ชัด	ไลบรารีเล็ก เครื่องมือทั่วไป
Apache 2.0	Permissive	ได้	ไม่ต้อง	มี	โครงการองค์กร ต้องการคุ้มครองสิทธิบัตร
GPL v3	Strong Copyleft	ไม่ได้หากแจกจ่าย	ต้องเปิด	มี	ต้องการให้ชุมชนได้ประโยชน์กลับคืนทั้งหมด
AGPL v3	Strong Copyleft แบบเครือข่าย	ไม่ได้	ต้องเปิดแม้รันเป็นบริการ	มี	บริการบนคลาวด์ที่ไม่อยากให้ปิดซอร์ส

ข้อควรระวัง: ประเภท Source-available อย่าง Business Source License (BSL), Elastic License 2.0, Server Side Public License (SSPL) ให้ดูซอร์สโค้ดได้ แต่มีข้อจำกัดทางการค้า จึงไม่ถือเป็นโอเพนซอร์สตามนิยาม OSI

วิธีเลือกใบอนุญาตให้โปรเจกต์ของคุณ

1. ถามเป้าหมายก่อน: อยากให้คนใช้เยอะที่สุดแม้จะเป็นบริษัทปิดหรือไม่ หรืออยากให้การปรับปรุงกลับมาที่ชุมชน
2. ดูระบบนิเวศ: หากคุณสร้างปลั๊กอินให้ WordPress (GPL) หรือไลบรารีให้ Apache project คุณอาจต้องเข้ากับใบอนุญาตหลัก
3. ปรึกษาฝ่ายกฎหมาย: โดยเฉพาะเรื่องสิทธิบัตรและการใช้งานในผลิตภัณฑ์เชิงพาณิชย์ Apache 2.0 มักปลอดภัยกว่า MIT ในองค์กรใหญ่เพราะมี patent clause
4. ใส่ไฟล์ LICENSE และ SPDX Identifier: เพิ่มไฟล์ LICENSE ที่รากโปรเจกต์ และใส่ SPDX-License-Identifier: MIT ในแต่ละไฟล์เพื่อเครื่องมือสแกน เช่น GitHub Dependabot และ OpenSSF Scorecard ตรวจเจอ
5. อย่าสร้างใบอนุญาตเอง: ใช้ใบอนุญาตที่ผ่านการรับรองโดย OSI เพื่อลดความเสี่ยงการตีความ

แนวปฏิบัติของชุมชน: ทำให้โปรเจกต์อยู่ได้นานกว่าตัวคุณ

ซอฟต์แวร์จะยั่งยืนเพราะคน ไม่ใช่แค่โค้ด แนวปฏิบัติดีที่โครงการใหญ่ใช้ร่วมกัน ได้แก่

บทบาทที่ชัดเจน

• User / Contributor: คนใช้และคนส่งแพตช์
• Maintainer / Reviewer: ผู้มีสิทธิ์รีวิวและรวมโค้ด (merge) ดูแล roadmap และบรรยากาศชุมชน
• Community Manager / Triager: จัดการ issue, ตอบคำถาม, จัดลำดับความสำคัญ

การมีบทบาทเหล่านี้ระบุไว้ใน GOVERNANCE.md หรือ CONTRIBUTING.md ช่วยลดความสับสนและทำให้ผู้ร่วมใหม่รู้ว่าต้องคุยกับใคร

เวิร์กโฟลว์การมีส่วนร่วม

• ใช้แพลตฟอร์มเปิด: GitHub / GitLab issues, pull requests, discussions, continuous integration (CI) ทุกอย่างควรค้นหาได้
• กฎการ Contribute: ต้องมี README ที่อธิบายวิธีติดตั้งและทดสอบ, CONTRIBUTING ที่บอกวิธีตั้ง branch, เขียน commit message, และรัน test, และ CODE_OF_CONDUCT เพื่อสร้างพื้นที่ปลอดภัย
• Code Review ที่โปร่งใส: รีวิวอย่างมีเมตตา เน้นที่โค้ดไม่ใช่คน ใช้ checklist เรื่อง security, performance, docs
• การตัดสินใจ: โครงการอย่าง Kubernetes ใช้โมเดล open governance ที่ให้สมาชิกเสนอ proposal (KEP, RFC) แล้วอภิปรายในที่สาธารณะก่อนตัดสินใจ ไม่ใช่ตัดสินใจหลังไมค์

การสร้างวัฒนธรรมต้อนรับ

• Documentation is feature: เขียนให้มือใหม่รันได้ใน 5 นาที
• Good first issue: ติดป้ายงานเล็กให้คนใหม่เริ่ม
• Mentorship และ Office Hours: Python Software Foundation ทำโครงการ outreach เพื่อให้ผู้ร่วมใหม่รู้สึกมีคุณค่า
• ให้เครดิต: ใช้ CONTRIBUTORS, release notes, contributor spotlight เพื่อยอมรับแรงงาน

ความปลอดภัยและกฎหมายที่ต้องรู้

เมื่อแอปหนึ่งพึ่งพาไลบรารีโอเพนซอร์สหลายร้อยตัว กราฟ dependency จะซับซ้อน ปัญหาที่ต้องจัดการ ได้แก่

• Supply Chain Security: ตรวจสอบช่องโหว่ด้วยเครื่องมืออย่าง npm audit, pip-audit, Dependabot, และใช้ OpenSSF (Open Source Security Foundation) และกรอบงาน NIST Secure Software Development Framework เพื่อจัดการความเสี่ยง
• License Compliance: ใช้เครื่องมือ SBOM (Software Bill of Materials) เช่น SPDX, CycloneDX เพื่อรู้ว่าโปรเจกต์คุณใช้ใบอนุญาตอะไรบ้าง การละเมิด GPL โดยไม่เปิดซอร์สอาจนำไปสู่ข้อพิพาททางกฎหมาย
• การบำรุงรักษา: โครงการที่ไม่มี maintainer มากพออาจกลายเป็น abandonware ประเมินความเสี่ยงจากจำนวน maintainer, ความถี่ release, และ OpenSSF Scorecard ก่อนนำมาใช้ในระบบสำคัญ

ข้อควรระวังและคำถามที่พบบ่อย

• โอเพนซอร์ส = ฟรีไม่ต้องจ่ายเสมอไปหรือไม่? ไม่เสมอไป โอเพนซอร์สหมายถึงเสรีภาพด้านซอร์สโค้ด ไม่ใช่ราคา บริษัทสามารถขายการสนับสนุนหรือโฮสติ้งได้
• เอาภาพ/ฟอนต์/โมเดล AI มาใช้ ถือว่าโอเพนซอร์สไหม? นิยาม OSI ออกแบบสำหรับซอฟต์แวร์ งานศิลป์และโมเดลต้องดูใบอนุญาตเฉพาะ เช่น CC BY-SA หรือ OpenRAIL
• เปลี่ยนใบอนุญาตทีหลังได้ไหม? ได้หากคุณเป็นเจ้าของลิขสิทธิ์ทั้งหมดหรือได้รับความยินยอมจากผู้ร่วมทุกคน มิฉะนั้นโค้ดเก่ายังอยู่ภายใต้ใบอนุญาตเดิม
• ใช้โค้ด MIT ในโปรเจกต์ GPL ได้ไหม? ได้ เพราะ MIT เข้ากันได้กับ GPL แต่ทางกลับกันไม่ได้ หากคุณรวมโค้ด GPL เข้าไป โปรเจกต์ต้องกลายเป็น GPL

สรุป

โอเพนซอร์สไม่ใช่แค่การอัปโหลดโค้ดขึ้น GitHub แต่คือระบบสิทธิที่ออกแบบด้วยใบอนุญาตและระบบคนที่ออกแบบด้วยธรรมาภิบาล หากคุณอยากใช้โอเพนซอร์สให้ปลอดภัย ให้เริ่มจากการเข้าใจ Open Source Definition ของ OSI เลือกใบอนุญาตระหว่าง Permissive อย่าง MIT/Apache 2.0 กับ Copyleft อย่าง GPL/AGPL ให้ตรงกับเป้าหมายธุรกิจและอุดมการณ์ จากนั้นลงทุนกับเอกสาร เวิร์กโฟลว์ที่โปร่งใส และวัฒนธรรมที่ต้อนรับคนใหม่ เมื่อโค้ดเปิดและคนเปิด นวัตกรรมจะเดินต่อได้ด้วยตัวเอง นั่นคือพลังที่ทำให้ Linux ไปจนถึง Python ครองโลกซอฟต์แวร์มาจนถึงทุกวันนี้

แหล่งข้อมูลอ้างอิง

• Open Source Definition โดย Open Source Initiative
• รายการใบอนุญาตที่ OSI รับรอง
• IEEE Technology Navigator: Open Source Software
• Best Practices for Open Source Governance - Zilliz
• Open Source Licensing for Startups - Promise Legal