โอเพนซอร์ส ไลเซนส์ และวัฒนธรรมชุมชน เข้าใจให้ครบก่อนใช้งาน

บทนำ: ทำไมต้องเข้าใจโอเพนซอร์สให้ลึกกว่าแค่โค้ดฟรี

ถ้าคุณเคยใช้ VS Code, React, Linux, หรือ Python คุณกำลังใช้โอเพนซอร์สอยู่ทุกวัน บทความนี้จะพาคุณไปไกลกว่าแค่การโหลดโค้ดฟรี คุณจะได้เข้าใจว่าโอเพนซอร์สคืออะไรตามนิยามของ Open Source Initiative, ไลเซนส์แต่ละแบบให้สิทธิและหน้าที่ต่างกันอย่างไร และชุมชนที่ดีทำงานกันอย่างไร เพื่อให้คุณเลือกใช้ มีส่วนร่วม และสร้างโปรเจกต์ได้อย่างมั่นใจ ไม่ติดปัญหาลิขสิทธิ์ในภายหลัง

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

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

ความต่างจากฟรีซอฟต์แวร์ของ Free Software Foundation ส่วนใหญ่อยู่ที่มุมมองและคุณค่า แต่ในทางกฎหมาย ไลเซนส์ส่วนใหญ่เป็นทั้งฟรีและโอเพนซอร์สในเวลาเดียวกัน

จุดแข็งของโมเดลนี้คือการพัฒนาแบบบาซาร์ที่ Eric S. Raymond อธิบายไว้ ยิ่งมีคนเห็นโค้ดมาก ยิ่งเจอบั๊กเร็ว โปรเจกต์ใหญ่จึงเติบโตด้วยการรีวิวจากทั่วโลก ไม่ใช่ทีมปิดเล็กๆ

ประเภทหลักของไลเซนส์โอเพนซอร์ส

แบ่งได้เป็น 2 กลุ่มใหญ่ตามที่ชุมชนนิยมใช้:

1. Permissive License กลุ่มผ่อนปรน

ให้อิสระสูง เอาไปใช้ในงานเชิงพาณิชย์หรือซอฟต์แวร์แบบปิดได้ ขอแค่ทำตามเงื่อนไขเล็กน้อย เช่น ใส่ข้อความลิขสิทธิ์เดิม

• จุดกำเนิดจากสถาบันการศึกษา เช่น BSD จาก UC Berkeley และ MIT License จาก MIT
• ข้อความสั้น อ่านง่าย มักไม่ถึง 1 หน้า
• ไม่มีภาระต้องเปิดซอร์สของงานใหม่

2. Copyleft License กลุ่มคุ้มครองให้เปิดต่อ

ต้องการให้งานดัดแปลงยังคงเป็นโอเพนซอร์สต่อไป ใช้กฎหมายลิขสิทธิ์กลับด้านเพื่อรักษาอิสรภาพ

• Strong Copyleft เช่น GPL ถ้าคุณนำโค้ด GPL ไปรวมในงานใหม่ งานใหม่ทั้งหมดต้องแจกจ่ายภายใต้ GPL ด้วย
• Weak Copyleft เช่น LGPL และ MPL ภาระ copyleft จำกัดเฉพาะไฟล์หรือไลบรารีที่ครอบด้วยไลเซนส์นั้น ไม่ลามไปทั้งโปรเจกต์

นอกจากเรื่องลิขสิทธิ์ ไลเซนส์ยุคใหม่ยังพูดถึงสิทธิบัตรอย่างชัดเจน เช่น Apache License 2.0 มีการให้สิทธิสิทธิบัตรจากผู้ร่วมพัฒนาโดยตรง และมีเงื่อนไขระงับสิทธิหากใครฟ้องคดีสิทธิบัตรเกี่ยวกับโค้ดนั้น

ประเภท	ตัวอย่าง	ใช้ในงานปิดได้ไหม	ต้องเปิดซอร์สงานต่อไหม	มีให้สิทธิสิทธิบัตรชัดไหม
Permissive	MIT, Apache-2.0, BSD 3-Clause	ได้	ไม่ต้อง	MIT/BSD แบบโดยนัย, Apache-2.0 แบบชัดแจ้ง
Weak Copyleft	LGPL, MPL-2.0	ได้แบบมีเงื่อนไข	เปิดเฉพาะส่วนที่เป็นไลเซนส์นั้น	มี
Strong Copyleft	GPL-2.0, GPL-3.0, AGPL-3.0	ไม่ได้ถ้าไม่ยอมเปิดซอร์ส	ต้องเปิดทั้งหมดภายใต้ไลเซนส์เดียวกัน	มี

ไลเซนส์ยอดนิยมที่ควรรู้จักจริงๆ

MIT License เรียบง่ายที่สุด ประมาณ 20 บรรทัด ให้ทำอะไรก็ได้ ขอแค่เก็บข้อความลิขสิทธิ์ไว้ นิยมในไลบรารี JavaScript และโปรเจกต์เริ่มต้นเพราะเข้ากับธุรกิจง่าย

Apache License 2.0 คล้าย MIT แต่รอบคอบกว่า มีบทให้สิทธิสิทธิบัตรและมีเงื่อนไข patent retaliation ป้องกันการฟ้องกันเอง ใช้กันมากในองค์กรใหญ่ เช่น Apache Software Foundation และโปรเจกต์ Cloud Native

BSD 2-Clause / 3-Clause ใกล้เคียง MIT แต่ 3-Clause ห้ามใช้ชื่อองค์กรหรือผู้พัฒนาเดิมมาโฆษณาโดยไม่ได้รับอนุญาต

GNU GPL v2 / v3 เป็นหัวใจของ Linux kernel (v2) และเครื่องมือ GNU จำนวนมาก (v3) ต้องการให้แจกจ่ายซอร์สโค้ดเสมอ และ GPL v3 เพิ่มเรื่องสิทธิบัตรและความเข้ากันได้กับอุปกรณ์ที่ล็อกไม่ให้แก้ซอฟต์แวร์

AGPL-3.0 เข้มกว่า GPL ตรงที่ถ้าคุณรันซอฟต์แวร์เป็นบริการบนเซิร์ฟเวอร์ให้คนอื่นใช้ผ่านเน็ตเวิร์ก ต้องเปิดซอร์สด้วย แก้ช่องโหว่ที่คนเอา GPL ไปรันเป็น SaaS แล้วไม่แจกซอร์ส

Mozilla Public License 2.0 เป็นตัวอย่าง weak copyleft ที่สมดุล เปิดเฉพาะไฟล์ที่แก้ แต่ไฟล์ใหม่แยกออกมาไม่ต้องเปิด

ปัจจุบันรายการที่ OSI รับรองอย่างเป็นทางการมีหลายสิบไลเซนส์ สามารถตรวจสอบแบบเป็นทางการได้ผ่าน API ใหม่ของ OSI ที่ opensource.org/api/license

แนวปฏิบัติชุมชนที่ทำให้โปรเจกต์อยู่รอด

โค้ดที่ดีอย่างเดียวไม่พอ ชุมชนที่แข็งแรงต้องมีโครงสร้าง:

• CONTRIBUTING.md บอกวิธีติดตั้ง รันเทสต์ สไตล์โค้ด และวิธีส่ง Pull Request ที่ชัดเจน โปรเจกต์ที่มีคู่มือนี้มักได้คอนทริบิวชันเพิ่มขึ้นอย่างเห็นได้ชัด
• Code of Conduct เช่น Contributor Covenant เพื่อกำหนดมารยาท การสื่อสารอย่างมืออาชีพ และการจัดการความขัดแย้ง
• Issue Template และ PR Template ช่วยให้บั๊กรีพอร์ตมีข้อมูลพอที่จะแก้ได้จริง ไม่ใช่แค่บอกว่าใช้ไม่ได้
• การรีวิวโค้ดแบบเปิด ทุกการเปลี่ยนแปลงต้องผ่านการรีวิว มี CI รันเทสต์อัตโนมัติ และมีการสนทนาอย่างสุภาพ
• บทบาทที่ชัด Maintainer, Reviewer, Triager, Contributor คนใหม่เริ่มจาก good first issue แล้วค่อยขยับบทบาท
• การสื่อสาร ใช้ GitHub Discussions, mailing list หรือ Slack/Discord ที่โปร่งใส ตัดสินใจสำคัญบันทึกไว้ใน ADR หรือ meeting notes

หลักการสำคัญที่ Apache Software Foundation ย้ำเสมอคือ community over code ชุมชนมาก่อนโค้ด ถ้าชุมชนดี โค้ดจะดีตามมาเอง

ขั้นตอนมีส่วนร่วมแบบมืออาชีพ สำหรับมือใหม่

1. อ่าน README, LICENSE และ CONTRIBUTING ก่อนเสมอ ดูว่าโปรเจกต์ใช้ไลเซนส์อะไร มี CLA หรือ DCO ให้เซ็นไหม
2. หา issue ติดป้าย good first issue หรือ help wanted ลองทำในเครื่องตัวเองให้ผ่านเทสต์
3. Fork แล้วสร้าง branch แยก อธิบายการแก้ไขแบบกระชับใน commit message
4. ส่ง Pull Request เล็ก เน้นแก้เรื่องเดียว ใส่รายละเอียดว่าทดสอบอย่างไร มีผลกระทบอะไร
5. ตอบคอมเมนต์รีวิวอย่างสุภาพ แก้ไขตามคำแนะนำ ไม่ถือเป็นเรื่องส่วนตัว
6. เมื่อ PR รวมแล้ว ช่วยดูแลต่อ เช่น ตอบ issue อื่น รีวิว PR ของคนอื่น เป็นการสร้างความไว้วางใจ

สำหรับฝั่ง Maintainer ควรตอบ issue ภายในไม่กี่วัน ขอบคุณผู้มีส่วนร่วมสม่ำเสมอ และทำ release note ที่ชัดเจน เพื่อให้ผู้ใช้รู้ว่าเปลี่ยนอะไรและต้องอัปเดตอย่างไร

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

• ความเข้ากันได้ของไลเซนส์ MIT เข้ากันได้กับเกือบทุกไลเซนส์ แต่ GPL ไม่เข้ากันกับโค้ดที่เป็น Apache-2.0 แบบบางกรณีหากไม่ระวังเรื่อง GPL v2 vs Apache-2.0 การรวมโค้ดต่างไลเซนส์โดยไม่ตรวจสอบทำให้แจกจ่ายต่อไม่ได้
• ไม่มีการรับประกัน ไลเซนส์โอเพนซอร์สเกือบทั้งหมดบอกว่าให้ตามสภาพ ไม่รับประกันความเหมาะสมหรือความปลอดภัย ต้องประเมินเอง
• เครื่องหมายการค้าไม่รวมอยู่ในไลเซนส์ คุณใช้โค้ดได้ แต่ไม่ได้สิทธิใช้โลโก้หรือชื่อแบรนด์โดยอัตโนมัติ เช่น คุณ fork Firefox ได้ แต่ใช้ชื่อ Firefox ต่อไม่ได้ถ้าไม่ได้รับอนุญาต
• SBOM และเครื่องมือสแกน โปรเจกต์สมัยใหม่ควรมี Software Bill of Materials และใช้เครื่องมืออย่าง SPDX identifiers เพื่อระบุไลเซนส์ในทุกไฟล์ ทำให้ตรวจสอบอัตโนมัติง่าย
• อย่าสร้างไลเซนส์เอง ถ้าไม่มีเหตุผลเฉพาะทางจริงๆ เลือกจากรายการที่ OSI รับรองจะปลอดภัยกว่า ไลเซนส์ที่ทำเองมักมีช่องโหว่และไม่มีใครกล้าใช้

สรุป

โอเพนซอร์สไม่ใช่แค่โค้ดฟรี แต่คือระบบนิเวศที่ผูกด้วยกฎหมายและความไว้วางใจ เลือกไลเซนส์แบบ permissive ถ้าต้องการให้คนเอาไปใช้กว้างสุด เลือก weak หรือ strong copyleft ถ้าต้องการให้การเปิดกว้างคงอยู่ต่อไป และไม่ว่าจะเลือกแบบไหน การลงทุนใน CONTRIBUTING, Code of Conduct และการรีวิวที่สุภาพ จะเป็นตัวกำหนดว่าโปรเจกต์ของคุณจะมีคนอยู่ต่อหรือแค่โคลนแล้วทิ้ง

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

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

• Open-source license - Wikipedia
• OSI Approved Licenses - Introducing the new API
• OSI - The Open Source Definition
• Apache Software Foundation - How Apache Projects Work
• GitHub Docs - Licensing a repository