ประเภทและข้อผิดพลาดในการเลือกสัญญาอนุญาต
ข้อผิดพลาดที่พบบ่อยที่สุดในวงการโอเพนซอร์สไม่ใช่เรื่องของโค้ด แต่เป็นเรื่องของข้อความทางกฎหมายที่แนบมากับซอร์สโค้ดทุกโปรเจกต์ สัญญาอนุญาต (License) คือสัญญาที่ผู้สร้างกำหนดสิทธิ์และหน้าที่ของผู้ที่นำซอฟต์แวร์ไปใช้ คัดลอก ดัดแปลง หรือเผยแพร่ต่อ แม้ซอฟต์แวร์จะถูกเปิดให้ดาวน์โหลดฟรี แต่ไม่ได้หมายความว่าผู้ใช้จะทำอะไรกับมันก็ได้โดยไม่มีเงื่อนไข
โปรเจกต์โอเพนซอร์สส่วนใหญ่ใช้สัญญาอนุญาตมาตรฐานที่ได้รับการยอมรับในระดับสากล เช่น MIT, BSD, Apache 2.0, GPLv3, Mozilla Public License 2.0 หรือ ISC แต่ละสัญญามีจุดประสงค์และข้อจำกัดต่างกัน การทำความเข้าใจความแตกต่างเหล่านี้ช่วยให้นักพัฒนาหลีกเลี่ยงข้อพิพาททางกฎหมายที่อาจเกิดขึ้นในภายหลัง โดยเฉพาะอย่างยิ่งเมื่อต้องนำไลบรารีหลายตัวมาประกอบกันในโปรเจกต์เดียว
Permissive กับ Copyleft ต่างกันอย่างไร
สัญญาอนุญาตโอเพนซอร์สแบ่งออกเป็นสองกลุ่มหลักที่นักพัฒนาควรจำแนกให้ได้ กลุ่มแรกคือ Permissive License เช่น MIT, BSD และ Apache 2.0 ซึ่งอนุญาตให้นำซอร์สโค้ดไปใช้ในโครงการเชิงพาณิชย์ได้อย่างอิสระ แม้แต่ในซอฟต์แวร์ปิด (Proprietary) ก็ตาม ข้อกำหนดหลักมักจำกัดอยู่ที่การคงไว้ซึ่งข้อความลิขสิทธิ์และคำปฏิเสธความรับผิดในไฟล์ต้นฉบับ
กลุ่มที่สองคือ Copyleft License อย่าง GPLv3 ซึ่งมีข้อกำหนดเข้มงวดกว่า โดยกำหนดให้งานที่ดัดแปลงหรือเผยแพร่ต่อต้องเปิดเผยซอร์สโค้ดภายใต้สัญญาเดียวกัน หากนักพัฒนานำไลบรารี GPL ไปใช้ในซอฟต์แวร์ปิด ผลลัพธ์ทั้งหมดอาจต้องถูกเปิดเผยซอร์สโค้ดด้วย ข้อผิดพลาดที่พบบ่อยคือการมองว่าโอเพนซอร์สเหมือนกันหมด และนำไลบรารีที่มีสัญญาต่างกันมาใช้ร่วมกันโดยไม่ตรวจสอบความเข้ากันได้
กรณีศึกษา: AGPL กับบริการ SaaS
สัญญา AGPLv3 มีข้อกำหนดที่ขยายขอบเขตของ Copyleft ไปยังการให้บริการผ่านเครือข่าย หากบริษัทนำซอฟต์แวร์ภายใต้ AGPL ไปให้บริการบนเซิร์ฟเวอร์ ผู้ใช้บริการต้องสามารถเข้าถึงซอร์สโค้ดที่ดัดแปลงแล้วได้ บริษัทหลายแห่งที่เปิดให้บริการ SaaS จึงมักหลีกเลี่ยงการใช้ไลบรารี AGPL ในส่วนที่เผยต่อผู้ใช้ เพราะไม่ต้องการเปิดเผยการปรับแต่งทางธุรกิจ ในทางกลับกัน AGPL เป็นตัวเลือกที่ดีสำหรับโปรเจกต์ที่ต้องการป้องกันไม่ให้บริษัทขนาดใหญ่นำไปใช้โดยไม่คืนค่าให้ชุมชน
| สัญญาอนุญาต | ประเภท | ใช้ในเชิงพาณิชย์ได้ | ต้องเปิดเผยซอร์สโค้ด |
|---|---|---|---|
| MIT | Permissive | ได้ | ไม่จำเป็น |
| BSD-3-Clause | Permissive | ได้ | ไม่จำเป็น |
| Apache 2.0 | Permissive | ได้ | ไม่จำเป็น (ต้องระบุการเปลี่ยนแปลง) |
| GPLv3 | Copyleft | ได้ | จำเป็นเมื่อเผยแพร่ |
| LGPLv3 | Weak Copyleft | ได้ | เฉพาะส่วนที่แก้ไข |
| AGPLv3 | Network Copyleft | ได้ | จำเป็นแม้ใช้บนเซิร์ฟเวอร์ |
หน้าที่ที่ผู้ใช้มักละเลยเมื่อนำไปใช้งาน
แม้สัญญาอนุญาตส่วนใหญ่จะอนุญาตให้ใช้งานได้อย่างเสรี แต่เกือบทุกสัญญากำหนดหน้าที่บางประการที่ผู้ใช้ต้องปฏิบัติตาม การละเลยหน้าที่เหล่านี้ถือเป็นการละเมิดสัญญาและอาจนำไปสู่การฟ้องร้องได้ ข้อผิดพลาดที่พบบ่อยมีอยู่สามประการหลัก ซึ่งเกิดขึ้นซ้ำแล้วซ้ำเล่าในโปรเจกต์ทั้งขนาดเล็กและขนาดใหญ่
การระบุแหล่งที่มาและการคงไว้ซึ่งข้อความลิขสิทธิ์
สัญญาอนุญาตแทบทุกฉบับกำหนดให้ผู้ใช้คงไว้ซึ่งข้อความลิขสิทธิ์ (Copyright Notice) และคำปฏิเสธความรับผิด (Disclaimer) ในการเผยแพร่ทุกครั้ง หมายความว่าเมื่อนำไลบรารีไปจัดจำหน่ายหรือเผยแพร่ ไฟล์ต้นฉบับที่มีข้อความ Copyright (c) [ปี] [ผู้สร้าง] ต้องติดมาด้วย ข้อผิดพลาดที่พบบ่อยในแอปพลิเคชันมือถือคือการลบไฟล์ LICENSE หรือ NOTICE ออกจากบิลด์เพื่อลดขนาดไฟล์ ซึ่งทำให้ผู้ใช้แอปไม่สามารถตรวจสอบสัญญาอนุญาตของไลบรารีที่ใช้ได้ การแก้ปัญหานี้ทำได้ง่ายๆ ด้วยการแสดงหน้า “Open Source Licenses” ในแอป ซึ่งเป็นมาตรฐานที่แอปส่วนใหญ่ปฏิบัติตามอยู่แล้ว
การเปิดเผยการเปลี่ยนแปลง
Apache License 2.0 มีข้อกำหนดเฉพาะที่สัญญาอื่นไม่มี นั่นคือผู้ใช้ที่ดัดแปลงไฟล์ต้นฉบับต้องระบุในเอกสารประกอบว่ามีการเปลี่ยนแปลง หากนักพัฒนานำโค้ดจากโปรเจกต์ Apache มาแก้ไขแล้วเผยแพร่โดยไม่ระบุ ถือว่าละเมิดข้อกำหนดทันที ข้อกำหนดนี้ออกแบบมาเพื่อให้ผู้ใช้งานปลายทางสามารถตรวจสอบได้ว่าฟีเจอร์ที่ใช้งานถูกพัฒนาโดยชุมชนต้นฉบับหรือโดยผู้ดัดแปลง ข้อดีของข้อกำหนดนี้คือช่วยให้เกิดความโปร่งใสในการพัฒนา และทำให้ผู้ใช้สามารถติดตามที่มาของฟีเจอร์ต่างๆ ได้
การเปิดเผยซอร์สโค้ดเมื่อใช้สัญญา Copyleft
การใช้ไลบรารี GPL หรือ LGPL ในซอฟต์แวร์เชิงพาณิชย์มักทำให้เกิดความสับสน LGPL อนุญาตให้เชื่อมต่อ (Link) กับซอฟต์แวร์ปิดได้ แต่หากมีการแก้ไขไลบรารี LGPL ส่วนที่แก้ไขต้องเปิดเผยซอร์สโค้ด การนำไลบรารี LGPL ไปคอมไพล์รวมเป็นไฟล์เดียวกัน (Static Linking) กับซอฟต์แวร์ปิดอาจถูกตีความ
