คู่มือนักพัฒนาซอฟต์แวร์โอเพ่นซอร์สใบอนุญาต

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

เมื่อในปี 1984 Richard Stallman เริ่มโครงการ GNU เพื่อสร้างระบบปฏิบัติการฟรี เขาได้ค้นพบแนวคิดที่ว่าซอฟต์แวร์ควรแบ่งปันกันระหว่างนักพัฒนา วิศวกร และผู้ใช้ และพวกเขาควรจะสามารถปรับปรุงได้ในลักษณะที่ร่วมมือกันในลักษณะเดียวกับที่วิทยาศาสตร์ทำกันโดยทั่วไป

ตัวเลือกนี้แตกต่างกับแนวคิดปกติของซอฟต์แวร์ลิขสิทธิ์ที่ได้รับเลือกโดยบริษัทซอฟต์แวร์และนักพัฒนาซอฟต์แวร์ส่วนใหญ่เพื่อแจกจ่ายและขายโปรแกรมของตน ทุกวันนี้ กว่าสามสิบปีต่อมา ซอฟต์แวร์โอเพ่นซอร์สยังคงเอาชนะภาคส่วนต่างๆ ในอุตสาหกรรมของเราอย่างช้าๆ: Linux, Android, Apache และ Git เป็นตัวอย่างของผลิตภัณฑ์โอเพ่นซอร์สชั้นนำในหมวดหมู่ดังกล่าว

โอเพ่นซอร์สหรือซอฟต์แวร์ฟรี?

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

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

คุณสมบัติทั่วไปของซอฟต์แวร์โอเพ่นซอร์ส

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

ก่อนอื่น: ฉันไม่ใช่ทนายความ และนี่ไม่ใช่คำแนะนำทางกฎหมาย ในกรณีที่มีข้อสงสัย โปรดดูข้อความที่แท้จริงของใบอนุญาตที่ฉันกำลังพูดถึง และปรึกษาที่ปรึกษากฎหมายของคุณ

ซอฟต์แวร์โอเพนซอร์ซทั้งหมดตาม Open Source Initiative ได้รับการเผยแพร่ภายใต้ใบอนุญาตที่ให้สิทธิ์บางอย่างแก่ผู้ใช้และนักพัฒนาซอฟต์แวร์ (ผู้ได้รับใบอนุญาต) รายการทั้งหมดสามารถดูได้ใน Open Source Definition แต่นี่เป็นข้อมูลสรุปพื้นฐาน:

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

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

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

Copyleft

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

ตามความแรงของ copyleft มีสองประเภท:

• Copyleft ที่รัดกุม: เมื่อผลงานที่ได้มาจากงานลิขสิทธิ์ที่เข้มงวดของลิขสิทธิ์อื่นๆ หรือเชื่อมโยงกับงานเหล่านี้ จะต้องมีใบอนุญาตลิขสิทธิ์ที่เข้มงวดต่อไป หรือแม้แต่ใบอนุญาตเดียวกันทุกประการ นั่นคืองานโอเพ่นซอร์สเหล่านั้นไม่สามารถปิดได้ในอนาคต
• copyleft ที่อ่อนแอ: เมื่อทำงานโดยใช้งานลิขสิทธิ์ที่อ่อนแอของ copyleft หรือเชื่อมโยงกับงานนั้น สามารถได้รับใบอนุญาตภายใต้ใบอนุญาตอื่นๆ แม้กระทั่งใบอนุญาตแบบโอเพนซอร์ส ในกรณีนี้ copyleft จะมีผลกับงานลิขสิทธิ์ copyleft ที่อ่อนแอเท่านั้น

นอกจากนี้ยังมีใบอนุญาตโอเพ่นซอร์สที่ไม่มีลิขสิทธิ์: พวกเขาไม่สนใจเกี่ยวกับการเปิดกว้างในอนาคตของซอฟต์แวร์ที่ได้รับ

การอนุญาต

ตามการอนุญาต ใบอนุญาตยังสามารถจัดประเภทใน:

• ใบอนุญาตที่เข้มงวด: เมื่อคุณไม่สามารถผสมผสานซอฟต์แวร์ที่ได้รับอนุญาตอย่างเข้มงวดกับโอเพ่นซอร์ส หรือแม้แต่กับซอฟต์แวร์ที่ได้รับอนุญาตมากกว่า
• ใบอนุญาตอนุญาต: เมื่อผลิตภัณฑ์มักจะผสมกับซอฟต์แวร์โอเพนซอร์ซหรือซอฟต์แวร์ที่มีใบอนุญาตโอเพนซอร์ซโดยสิ้นเชิง

โดยปกติแล้ว ใบอนุญาตลิขสิทธิ์ที่เข้มงวดก็เข้มงวดเช่นกัน และใบอนุญาตลิขสิทธิ์ที่อ่อนแอกว่าจะได้รับอนุญาตมากกว่า แต่ก็ไม่จำเป็นต้องเป็นอย่างนั้น

ความแตกต่างของใบอนุญาตโอเพ่นซอร์ส

มีใบอนุญาตโอเพ่นซอร์สมากมาย โครงการโอเพ่นซอร์สได้อนุมัติแล้วมากกว่า 80 รายการ บางอย่างซ้ำซากและถือได้ว่าเทียบเท่ากับอย่างอื่น ส่วนอื่น ๆ มีวัตถุประสงค์เฉพาะเพื่อผลประโยชน์ของผู้เผยแพร่ซอฟต์แวร์ (เช่นใบอนุญาต NASA) หรือสำหรับสภาพแวดล้อมหรือวัตถุประสงค์ที่กำหนด (เช่นใบอนุญาตชุมชนการศึกษาหรือใบอนุญาตแบบอักษรเปิด)

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

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

ปัญหาการผสมรหัสกับใบอนุญาตต่างกัน

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

ส่วนอื่นๆ นั้นมีข้อจำกัดมากกว่า ดังนั้นซอร์สโค้ดจึงสามารถรวมกับโค้ดที่ได้รับอนุญาตในลักษณะเดียวกันเท่านั้น และผลลัพธ์สุดท้ายต้องได้รับอนุญาตด้วยใบอนุญาตดั้งเดิมเดียวกัน ตัวอย่างของใบอนุญาตประเภทนี้คือใบอนุญาตสาธารณะทั่วไป (GPL)

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

ตัวอย่างหนึ่งของสถานการณ์นี้คือ ZFS ZFS เป็นระบบไฟล์ที่ล้ำสมัยและเป็นนวัตกรรมใหม่ที่รวมอยู่ใน OpenSolaris ในปี 2548 เป็นซอฟต์แวร์โอเพ่นซอร์สที่ได้รับอนุญาตภายใต้เงื่อนไขของ Common Development and Distribution License (CDDL) แม้ว่าจะเป็นรหัสโอเพนซอร์ซ แต่ก็ไม่สามารถรวมเข้ากับเคอร์เนล Linux ได้เนื่องจากซอร์สโค้ดของ Linux มีการแจกจ่ายภายใต้เงื่อนไขของ General Public License ซึ่งเป็นใบอนุญาตโอเพ่นซอร์สที่เข้มงวดอีกประการหนึ่ง ไบนารีของเคอร์เนล Linux ที่คอมไพล์ด้วยการสนับสนุน ZFS ไม่สามารถแจกจ่ายได้เนื่องจากข้อขัดแย้งของสิทธิ์การใช้งาน

ความขัดแย้งประเภทนี้จะสามารถแก้ไขได้ก็ต่อเมื่อเจ้าของโปรแกรมโอเพนซอร์ซรายใดรายหนึ่งตกลงที่จะเปลี่ยนใบอนุญาต หรือเพิ่มเงื่อนไขข้อยกเว้นในใบอนุญาตซอฟต์แวร์ ตัวอย่างเช่น: โปรแกรมลิขสิทธิ์ GPL จำนวนมากเชื่อมโยงกับไลบรารี OpenSSL การแจกจ่ายไลบรารี OpenSSL ได้รับอนุญาตโดยกำหนดให้วลีปรากฏในสื่อโฆษณาและการแจกจ่ายซ้ำใดๆ เงื่อนไขพิเศษเหล่านี้เข้ากันไม่ได้กับ GPL และด้วยเหตุนี้ผู้พัฒนาผลิตภัณฑ์ GPL ที่ใช้ OpenSSL จึงได้รวมข้อยกเว้นไว้ในใบอนุญาตของพวกเขาโดยเฉพาะซึ่งอนุญาตให้เชื่อมโยงกับ OpenSSL

คุณสมบัติที่แตกต่างของใบอนุญาตโอเพ่นซอร์ส

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

ใบอนุญาตสาธารณะทั่วไปของ GNU (GPL)

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

ลักษณะที่แตกต่าง:

• copyleft ที่แข็งแกร่ง
• ใบอนุญาตที่เข้มงวดมาก
• โดยทั่วไปเรียกว่าใบอนุญาต 'ไวรัส' หากคุณเชื่อมโยงรหัสของคุณกับรหัสอื่นที่ได้รับอนุญาตภายใต้ GPL และต้องการเผยแพร่ผลลัพธ์ ผลิตภัณฑ์ทั้งหมดจะต้องได้รับอนุญาตจาก GPL
• นอกจากนี้ยังเป็นใบอนุญาต 'โอบรับ' ด้วย: หากคุณกำลังพัฒนาซอฟต์แวร์และต้องการอนุญาตให้ใช้สิทธิ์ภายใต้ GPL คุณสามารถเชื่อมโยงหรือรวมซอฟต์แวร์โอเพนซอร์ซอื่น ๆ ได้ตราบใดที่ซอฟต์แวร์นี้มีใบอนุญาตที่เข้ากันได้กับ GPL ไม่ต้องการภาระผูกพันใด ๆ ที่ GPL กำหนด

โดยปกติ ข้อความใบอนุญาตที่ใช้แล้วจะมีข้อความที่ระบุว่าซอฟต์แวร์เผยแพร่ภายใต้เงื่อนไขของ GPL เวอร์ชัน N (หรือเวอร์ชันที่ใหม่กว่า)

ปัจจุบันมีใบอนุญาต GPL ใช้งานอยู่สองเวอร์ชัน: v2 และ v3 เวอร์ชัน 3 เปิดตัวในปี 2550 เพื่อแก้ไขปัญหาบางอย่างที่เกิดขึ้นตั้งแต่เปิดตัวเวอร์ชัน 2 ในปี 2534

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

ใบอนุญาต MIT

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

ใบอนุญาตนี้เป็นที่นิยมอย่างมาก และถูกใช้โดยหลายโครงการเช่น X Window System, Ruby on Rails, jQuery หรือ Node.js

เข้ากันได้กับ GPL คุณจึงสามารถผสมโค้ดที่ได้รับใบอนุญาต MIT ลงในซอฟต์แวร์ GPL ได้

Apache License 2.0

Apache License ถูกสร้างขึ้นโดย Apache Software Foundation (ASF) เป็นใบอนุญาตสำหรับ Apache HTTP Server

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

• การใช้ Apache License ผู้เขียนซอฟต์แวร์ให้สิทธิ์การใช้งานสิทธิบัตรแก่ผู้ใช้หรือผู้จัดจำหน่ายรหัส ใบอนุญาตสิทธิบัตรนี้ใช้กับสิทธิบัตรใด ๆ ที่ได้รับอนุญาตจากผู้เขียนซอฟต์แวร์คนใดคนหนึ่งจะถูกละเมิดโดยชิ้นส่วนของรหัสที่สร้างขึ้น
• Apache License กำหนดให้ชิ้นส่วนที่ไม่ได้แก้ไขในงานที่ได้รับต้องเก็บใบอนุญาตไว้
• ในทุกไฟล์ที่ได้รับอนุญาต ต้องสงวนลิขสิทธิ์ต้นฉบับ สิทธิบัตร เครื่องหมายการค้า หรือประกาศแสดงที่มา
• ในการเปลี่ยนแปลงไฟล์ที่ได้รับอนุญาตทุกครั้ง จะต้องมีการแจ้งเตือนว่ามีการเปลี่ยนแปลงในไฟล์
• หากซอฟต์แวร์ที่ได้รับอนุญาตจาก Apache มีไฟล์ประกาศ ไฟล์นี้และเนื้อหาของไฟล์จะต้องได้รับการเก็บรักษาไว้ในงานที่ได้รับทั้งหมด
• หากใครตั้งใจส่งการสนับสนุนสำหรับซอฟต์แวร์ที่ได้รับอนุญาตจาก Apache ให้กับผู้เขียน การสนับสนุนนี้จะถูกนำมาใช้โดยอัตโนมัติภายใต้สัญญาอนุญาต Apache

ใบอนุญาตนี้น่าสนใจเนื่องจากใบอนุญาตสิทธิบัตรอัตโนมัติและข้อเกี่ยวกับการส่งผลงาน

มันเข้ากันได้กับ GPL ดังนั้นคุณจึงสามารถผสมรหัสลิขสิทธิ์ Apache เข้ากับซอฟต์แวร์ GPL ได้

ใบอนุญาต BSD

มีใบอนุญาต BSD ที่แตกต่างกัน 3 แบบ ทั้งหมดนี้เป็นใบอนุญาตที่อนุญาตอย่างมากโดยไม่มีลิขสิทธิ์

ใบอนุญาต BSD 2 ข้อ (หรือใบอนุญาต BSD แบบง่าย) เทียบเท่ากับใบอนุญาต MIT ที่ได้อธิบายไว้ก่อนหน้านี้โดยสิ้นเชิง

สิทธิ์ใช้งาน BSD 3 ข้อ (หรือสิทธิ์ใช้งาน BSD ใหม่) เพิ่มหนึ่งประโยค โดยระบุว่าไม่อนุญาตให้ใช้ชื่อผู้ถือลิขสิทธิ์หรือชื่อผู้มีส่วนร่วมเพื่อรับรองหรือส่งเสริมผลิตภัณฑ์ที่ได้รับจากซอฟต์แวร์โดยไม่ได้รับอนุญาตเป็นลายลักษณ์อักษรล่วงหน้า เวอร์ชันนี้เข้ากันได้กับ GPL ทำให้คุณสามารถผสมโค้ดลิขสิทธิ์ 3-clause-BSD เข้ากับซอฟต์แวร์ GPL

ใบอนุญาต BSD 4 ข้อ (หรือสิทธิ์ใช้งาน BSD ดั้งเดิม) เพิ่มข้ออื่น โดยระบุว่าสื่อโฆษณาทั้งหมดที่กล่าวถึงคุณสมบัติหรือการใช้ซอฟต์แวร์ต้องแสดงการยอมรับว่าผลิตภัณฑ์มีซอฟต์แวร์ที่พัฒนาโดยผู้ถือลิขสิทธิ์ ใบอนุญาต BSD แบบ 4 ข้อนี้เข้ากันไม่ได้กับ GPL รหัสที่มีใบอนุญาตนี้ไม่สามารถให้สิทธิ์ใหม่ตามข้อกำหนดของ GPL ได้ เนื่องจากวรรคที่สี่จะเพิ่มข้อกำหนดที่ไม่จำเป็นใน GPL

GNU Lesser General Public License (LGPL)

LGPL ถูกสร้างขึ้นโดย FSF โดยเป็นการดัดแปลงของ GPL โดยมี copyleft ที่อ่อนแอกว่า ทำให้สามารถเชื่อมโยงซอฟต์แวร์ที่ได้รับอนุญาตของ LGPL กับซอฟต์แวร์อื่นๆ ได้ ในที่มาของคำว่า LGPL ย่อมาจาก "Library General Public License" แต่หลังจากนั้นก็ใช้ชื่อปัจจุบันว่า "Lesser General Public License" แทนความเห็นของ FSF ที่ระบุว่าซอฟต์แวร์ทั้งหมดควรเป็นอิสระ และด้วยเหตุนี้ LGPL จึงไม่ควร ใช้กันทั่วไป

คุณสามารถเชื่อมโยงรหัสที่มาปิดกับไลบรารีหรือซอฟต์แวร์ LGPL และแจกจ่ายผลลัพธ์สุดท้ายได้ตราบเท่าที่:

• คุณระบุซอร์สโค้ดของส่วน LGPLed พร้อมการแก้ไขทั้งหมดที่คุณได้ทำไว้
• ผู้ใช้ที่มีความรู้เพียงพอสามารถแทนที่ส่วน LGPLed ของโปรแกรมด้วยเวอร์ชันที่แก้ไขได้ ซึ่งสามารถทำได้โดยแจกจ่ายส่วน LGPLed ของโปรแกรมเป็นไลบรารีไดนามิก (DLL ใน Windows, .so ใน Linux/Unix) หรือระบุโค้ดอ็อบเจ็กต์ของส่วนที่ไม่ใช่ LGPLed ของโปรแกรม

LGPL v3 เข้ากันได้กับ GPLv3 ดังนั้นคุณจึงสามารถป้อนรหัส LGPLv3 ลงในซอฟต์แวร์ GPL ได้

ใบอนุญาตศิลปกรรม

ใบอนุญาตศิลปะในเวอร์ชันปัจจุบัน 2.0 เป็นใบอนุญาตโอเพนซอร์ซที่อนุญาตโดยไม่มีลิขสิทธิ์ที่คล้ายกับใบอนุญาต MIT

ข้อแตกต่างที่สำคัญระหว่างใบอนุญาต MIT และใบอนุญาตศิลปะคือ ใบอนุญาตแบบหลังกำหนดให้ต้องระบุการดัดแปลงใดๆ ที่ทำกับโค้ดอย่างชัดเจน

ใบอนุญาตนี้ใช้เฉพาะในชุมชน Perl เท่านั้น

Artistic License 2.0 ปัจจุบันเข้ากันได้กับ GPL: คุณสามารถผสมโค้ด Artistic-Licensed ลงในซอฟต์แวร์ GPL ได้

ใบอนุญาตสาธารณะของ Microsoft (MS-PL)

Microsoft Public License สร้างขึ้นในปี 2008 โดยบริษัทนี้โดยเป็นหนึ่งในใบอนุญาตโอเพนซอร์ซที่สร้างโดย Shared Source Initiative

เป็นใบอนุญาตลิขสิทธิ์ที่เข้มงวดและอ่อนแอ: อนุญาตให้สร้างและแจกจ่ายโปรแกรมโอเพ่นซอร์สด้วยรหัส MS-PLed แต่ต้องใช้ MS-PL เป็นใบอนุญาตของงานที่ได้รับหากมีการแจกจ่ายในซอร์สโค้ด

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

MS-PL เข้ากันไม่ได้กับ GPL

ใบอนุญาตสาธารณะ Eclipse (EPL)

Eclipse Public License คือใบอนุญาตที่สร้างโดย Eclipse Foundation สำหรับสภาพแวดล้อมการพัฒนาแบบบูรณาการ เป็นใบอนุญาตที่จำกัดและอ่อนแอ ซึ่งคล้ายกับ LGPL ในหลาย ๆ ด้าน นอกจากนี้ยังรวมถึงข้อสำหรับการอนุญาตสิทธิบัตรอัตโนมัติ

EPL เข้ากันไม่ได้กับ GPL

ใบอนุญาตสาธารณะของ Mozilla (MPL)

Mozilla Public License เวอร์ชัน 2.0 เป็นลิขสิทธิ์ที่ไม่ปลอดภัยซึ่งสร้างโดย Mozilla Foundation สำหรับผลิตภัณฑ์ของตน

เราสามารถพิจารณาใบอนุญาตนี้ว่าคล้ายกับ LGPL แต่ด้วยความแตกต่างหลักที่ MPL ยังอนุญาตให้ลิงก์แบบสแตติกของโค้ด MPLed ในซอฟต์แวร์โอเพนซอร์ส

MPL ในเวอร์ชันปัจจุบัน 2.0 เข้ากันได้กับ GPL ซึ่งไม่เป็นความจริงสำหรับ MPL เวอร์ชันก่อนหน้า

ใบอนุญาตการพัฒนาและการจัดจำหน่ายทั่วไป (CDDL)

CDDL เป็นลิขสิทธิ์ที่อ่อนแอและอนุญาตซึ่งสร้างโดย Sun (ปัจจุบันคือ Oracle) โดยอิงจาก MPL เวอร์ชัน 1.1 โดยพื้นฐานแล้วมันมีคุณสมบัติเหมือนกับ MPL เงื่อนไขของมันถูกชี้แจงแต่ไม่ได้เปลี่ยนแปลงอย่างมีนัยสำคัญ

CDDL เป็นใบอนุญาตโอเพ่นซอร์สที่ Sun (ปัจจุบันคือ Oracle) เลือกใช้สำหรับผลิตภัณฑ์ต่างๆ ของบริษัท เช่น OpenSolaris หรือ NetBeans เป็นต้น

เนื่องจากใบอนุญาตนี้อิงตาม MPLv1.1 ใบอนุญาตนี้จึงเข้ากันไม่ได้กับ GPL ดังนั้นคุณจึงไม่สามารถผสมแหล่งที่มาที่ได้รับอนุญาตจาก CDDL ลงในซอฟต์แวร์ลิขสิทธิ์ GPL ได้ หลายคนบอกว่านี่เป็นความตั้งใจ ดังนั้นจึงไม่สามารถแนะนำซอร์สโค้ด OpenSolaris ลงในเคอร์เนลของ Linux ได้

ใบอนุญาตสาธารณะทั่วไปของ GNU Affero (AGPL)

AGPL เป็นเวอร์ชันของ GPL ที่มี copyleft ที่แข็งแกร่งและเข้มงวดยิ่งขึ้น จำเป็นต้องจัดเตรียมซอร์สโค้ดของแอปพลิเคชันไม่เฉพาะกับผู้ที่ได้รับสำเนาของซอฟต์แวร์เท่านั้น แต่ยังรวมถึงผู้ที่ใช้ซอฟต์แวร์นี้ผ่านเครือข่ายคอมพิวเตอร์ด้วย

ใบอนุญาตนี้สร้างโดย FSF เพื่อให้นักพัฒนามีวิธีหลีกเลี่ยงการปิดซอฟต์แวร์โอเพนซอร์ซในทางปฏิบัติเมื่อดำเนินการในเซิร์ฟเวอร์เครือข่ายหรือในระบบคลาวด์ เนื่องจาก GPL ไม่สามารถบังคับให้ผู้ให้บริการให้ซอร์สโค้ดแก่ผู้ใช้ . ในกรณีนี้ซอฟต์แวร์จะไม่ถูกแจกจ่าย

AGPLv3 เข้ากันได้กับ GPL3 คุณสามารถใส่รหัส AGPLv3 ลงในรหัส GPLv3 ได้ ตราบใดที่ผลลัพธ์สุดท้ายได้รับอนุญาตภายใต้ AGPLv3

ใบอนุญาต ISC

ใบอนุญาต ISC เป็นใบอนุญาตซอฟต์แวร์ฟรีที่อนุญาตซึ่งเขียนโดย Internet Software Consortium (ISC) ใช้งานได้จริงเทียบเท่ากับใบอนุญาต BSD และ MIT 2 ข้อ หลังจากลบบางภาษาที่ถือว่าไม่จำเป็นออก

เริ่มแรกใช้สำหรับการเปิดตัวซอฟต์แวร์ของ ISC เอง นับแต่นั้นมาก็กลายเป็นใบอนุญาตที่ต้องการของ OpenBSD (เริ่มตั้งแต่เดือนมิถุนายน พ.ศ. 2546) ท่ามกลางโครงการอื่นๆ

เข้ากันได้กับ GPL: คุณสามารถผสมรหัสที่ได้รับอนุญาตจาก ISC ลงในซอฟต์แวร์ GPL ได้

สิทธิ์การใช้งานซึ่งกันและกันของ Microsoft (MS-RL)

Microsoft Reciprocal License สร้างขึ้นในปี 2008 โดยบริษัทนี้โดยเป็นหนึ่งในใบอนุญาตโอเพนซอร์สที่สร้างโดย Shared Source Initiative

คล้ายกับ MS-PL ที่อธิบายก่อนหน้านี้ แต่มี copyleft ที่ชัดเจนกว่าเล็กน้อย ซึ่งคล้ายกับเงื่อนไขของ LGPL, CDDL และ EPL มันกำหนดว่าถ้าคุณผสมรหัสของคุณกับซอร์สโค้ดที่ได้รับอนุญาตของ MS-RL และต้องการเผยแพร่ผลลัพธ์สุดท้าย อย่างน้อยส่วนดั้งเดิมที่ได้รับอนุญาตของ MS-RL จะต้องได้รับอนุญาตต่อไปด้วยใบอนุญาตนี้

มันเข้ากันไม่ได้กับ GPL

สาธารณสมบัติ (CC0)

ตามวิกิพีเดีย “งานที่เป็นสาธารณสมบัติคืองานที่สิทธิ์ในทรัพย์สินทางปัญญาหมดอายุ ถูกริบ หรือไม่สามารถใช้ได้” การอุทิศงานให้กับสาธารณสมบัติ ผู้เขียนสละสิทธิ์ทั้งหมดภายใต้กฎหมายลิขสิทธิ์

มีโครงการซอฟต์แวร์หลายโครงการภายใต้สาธารณสมบัติ เช่น SQLite ไลบรารีที่ใช้เอ็นจินฐานข้อมูล SQL แบบฝังและเรียบง่าย ซึ่งรวมอยู่ในโปรเจ็กต์อื่นๆ หลายโครงการ เช่น โปรเจ็กต์ Mozilla, Android เป็นต้น

มีหลายวิธีในการอุทิศซอฟต์แวร์ให้กับสาธารณสมบัติ Creative Commons ได้สร้าง CC0 Public Domain Dedication ซึ่งเป็นวิธีสากลในการมอบงานให้เป็นสาธารณสมบัติ FSF แนะนำให้ใช้ข้อความนี้เพื่ออุทิศซอฟต์แวร์ให้กับสาธารณสมบัติ

งานภายใต้สาธารณสมบัติเข้ากันได้กับใบอนุญาตโอเพนซอร์ซหรือโอเพ่นซอร์ส และสามารถนำไปผสมกับซอฟต์แวร์อื่นๆ ได้

หลายใบอนุญาต

มีซอฟต์แวร์โอเพนซอร์ซบางตัวที่ได้รับอนุญาตสองหรือสามเท่า ซึ่งหมายความว่าบุคคลที่ได้รับซอฟต์แวร์ที่มีใบอนุญาตหลายใบนี้สามารถเลือกได้ว่าต้องการแจกจ่ายซอฟต์แวร์ใดภายใต้ใบอนุญาตใด เนื่องจากใบอนุญาตแต่ละใบให้การอนุญาตที่แตกต่างกันและกำหนดภาระผูกพันที่แตกต่างกัน จึงต้องมีการเลือกสรรเพื่อเลือกใบอนุญาตที่ตรงกับความต้องการมากที่สุด

นี่เป็นกรณีปกติสำหรับห้องสมุดบางแห่ง ตัวอย่างเช่น NSS คือไลบรารีที่สร้างโดย Mozilla ซึ่งใช้การรองรับ SSL/TLS รวมถึงคุณลักษณะอื่นๆ ที่เกี่ยวข้องกับความปลอดภัย ได้รับอนุญาตสามเท่าภายใต้ใบอนุญาต MPL, GPL และ LGPL

โปรดเลือกใบอนุญาต

ผู้คนจำนวนมากเผยแพร่รหัสในแพลตฟอร์มเป็น GitHub โดยไม่มีใบอนุญาตเป็นลายลักษณ์อักษร ไม่มีใครควรใช้รหัสนั้น เราไม่รู้ว่าเรามีสิทธิ์ใช้งานอะไรบ้าง ถ้าใช้ก็ฟ้องได้ เหมือนกับว่าคนพวกนี้ล้อเราว่า "นี่ ดูที่ฉันทำสิ! เจ๋งใช่มั้ย แต่เจ้าใช้ไม่ได้ ข้าแค่อยากให้เจ้าดูเท่านั้น!”

โปรดอย่าเป็นหนึ่งในนั้น หากคุณอัปโหลดรหัสของคุณไปที่ GitHub หรือไซต์สาธารณะที่คล้ายกัน ให้ผู้อื่นสามารถใช้และปรับปรุงโค้ดได้ หากคุณไม่อยากคิดมาก นี่คือคำแนะนำของฉัน:

• ถ้าคุณต้องการให้มันเรียบง่ายและอนุญาต ให้ทุกคนทำในสิ่งที่พวกเขาต้องการด้วยรหัสของคุณตราบเท่าที่พวกเขาให้ที่มากับคุณและไม่ต้องรับผิดต่อคุณ ให้ใช้ใบอนุญาต MIT
• หากคุณต้องการให้มันอนุญาต ให้ทุกคนทำในสิ่งที่พวกเขาต้องการด้วยรหัสของคุณ แต่ให้ระบุสิทธิ์อย่างชาญฉลาดภายใต้กฎหมายลิขสิทธิ์และให้สิทธิ์เหล่านั้น พร้อมกับการให้สิทธิ์ในสิทธิบัตรอย่างชัดเจนจากผู้ร่วมให้ข้อมูลแก่ผู้ใช้ ให้ใช้ Apache 2.0 License .

• หากคุณสนใจเกี่ยวกับการแก้ไขการแชร์ และคุณไม่ต้องการให้โค้ดของคุณถูกใช้ในการพัฒนาแบบปิด (ทั้งในผลิตภัณฑ์ซอฟต์แวร์แบบปิดหรือในอุปกรณ์ฮาร์ดแวร์แบบปิด) ให้ใช้ GPL v3

  • หากคุณไม่สนใจความเป็นไปได้ที่ซอฟต์แวร์ของคุณจะถูกนำมาใช้ในอุปกรณ์ปิด ให้ใช้ GPL v2 แต่โปรดใช้ประโยค "หรือเวอร์ชันที่ใหม่กว่า" เพื่อให้โค้ดของคุณสามารถนำมาใช้ในโครงการ GPLv3 ได้
  • หากคุณไม่สนใจความเป็นไปได้ที่ซอฟต์แวร์ของคุณจะถูกนำมาใช้ในซอฟต์แวร์แบบปิด ตราบใดที่ซอฟต์แวร์ของคุณหรือส่วนที่ใช้ซอฟต์แวร์ยังคงเป็นโอเพ่นซอร์สภายใต้เงื่อนไขเดียวกัน ให้ใช้ LGPL v3
  • หากคุณต้องการให้ทุกคนที่ใช้ซอฟต์แวร์ของคุณผ่านเครือข่ายมีสิทธิ์รับซอร์สโค้ด ให้ใช้ AGPL v3

หลังจากทั้งหมดนี้ คุณอาจเหนื่อยกับการพูดพล่อยๆ กึ่งกฎหมายที่เกือบจะไร้สาระเหล่านี้แล้ว แต่คุณรู้อะไรไหม? มันจำเป็น เพราะหากไม่มีใบอนุญาต คุณไม่มีสิทธิ์ใช้หรือแจกจ่ายรหัสใดๆ