ใบอนุญาตโอเพนซอร์สทั้งหมดไม่เหมือนกัน บางส่วนบังคับให้ผู้จัดหาซอฟต์แวร์ต้องให้ใบอนุญาตสิทธิบัตรแก่ผู้ใช้และผู้พัฒนาซอฟต์แวร์ สิทธิ์การใช้งานอื่น ๆ จะบังคับให้นักพัฒนาที่ใช้ผลิตภัณฑ์หรือไลบรารีที่ได้รับอนุญาตต้องเสนอซอร์สโค้ดของผลิตภัณฑ์หรือไลบรารีนี้ภายใต้เงื่อนไขเดียวกัน คนอื่น ๆ ก็เพียงแค่ให้รหัสโดยไม่มีการรับประกันใด ๆ หรือข้อกังวลใด ๆ ในบทความนี้ฉันจะพยายามเน้นความแตกต่างที่สำคัญระหว่างใบอนุญาตโอเพนซอร์สที่มีการใช้งานมากที่สุดจากมุมมองของผู้ใช้ซอฟต์แวร์และของนักพัฒนาซอฟต์แวร์
เมื่อในปี 1984 Richard Stallman ได้เริ่มโครงการ GNU เพื่อสร้างระบบปฏิบัติการฟรีเขาได้ค้นพบแนวคิดที่ว่าควรใช้ซอฟต์แวร์ร่วมกันระหว่างนักพัฒนาวิศวกรและผู้ใช้ และพวกเขาควรจะสามารถปรับปรุงได้โดยร่วมมือกันในลักษณะเดียวกับที่วิทยาศาสตร์มักจะทำ
ตัวเลือกนี้ตรงข้ามกับแนวคิดปกติของซอฟต์แวร์ลิขสิทธิ์ที่เลือกโดย บริษัท ซอฟต์แวร์และนักพัฒนาซอฟต์แวร์ส่วนใหญ่เพื่อแจกจ่ายและขายโปรแกรมของตน วันนี้กว่าสามสิบปีต่อมาซอฟต์แวร์โอเพนซอร์สยังคงเอาชนะภาคส่วนต่างๆในอุตสาหกรรมของเราได้อย่างช้าๆ: Linux, Android, Apache และ Git เป็นตัวอย่างผลิตภัณฑ์โอเพนซอร์สชั้นนำในหมวดหมู่ของพวกเขา
ในบทความนี้ฉันจะใช้คำว่า 'โอเพนซอร์ส' และ 'ฟรี' เป็นคำพ้องความหมายในขณะที่อ้างถึงซอฟต์แวร์หรือใบอนุญาต ในความคิดของฉันทั้งสองคำแสดงความคิดเดียวกัน “ โอเพ่นซอร์ส” แสดงออกในทางปฏิบัติและทางเทคนิคและการใช้“ ฟรี” ให้ความสำคัญกับความหมายเชิงปรัชญาและการเมืองของแนวคิด
น่าเสียดายที่คำว่า“ ฟรี” ในภาษาอังกฤษนอกจากจะเป็นคำคุณศัพท์ที่เกี่ยวข้องกับ“ เสรีภาพ” แล้วยังหมายถึง“ โดยไม่ต้องเสียค่าใช้จ่าย” อีกด้วย นี่คือเหตุผลที่ฉันมักจะพูดว่า 'โอเพนซอร์ส'
ฉันคิดว่าคุณมีความคิดโดยประมาณว่าซอฟต์แวร์โอเพนซอร์สคืออะไร แต่ในขณะที่เรากำลังจะพูดถึงรายละเอียดของใบอนุญาตต่างๆก่อนอื่นเราต้องพูดถึงคุณสมบัติเฉพาะที่กำหนดซอฟต์แวร์โอเพนซอร์ส
ก่อนอื่น: ฉันไม่ใช่ทนายความและนี่ไม่ใช่คำแนะนำทางกฎหมาย ในกรณีที่มีข้อสงสัยโปรดอ้างอิงข้อความจริงของใบอนุญาตที่ฉันกำลังพูดถึงและที่ปรึกษากฎหมายของคุณ
ซอฟต์แวร์โอเพนซอร์สทั้งหมดตาม Open Source Initiative ได้รับการแจกจ่ายภายใต้ใบอนุญาตที่ให้สิทธิ์แก่ผู้ใช้และผู้พัฒนา (ผู้ได้รับอนุญาต) สามารถดูรายชื่อทั้งหมดได้ในไฟล์ นิยามโอเพนซอร์ส แต่นี่คือบทสรุปพื้นฐาน:
แต่คุณต้องจำไว้ว่าใบอนุญาตซอฟต์แวร์พูดเฉพาะเกี่ยวกับการใช้หรือแจกจ่ายสิทธิ์ที่ได้รับจากเจ้าของลิขสิทธิ์เท่านั้น ใบอนุญาตโอเพนซอร์สอาจอนุญาตให้คุณแจกจ่ายซอฟต์แวร์หรือผลงานที่ได้รับมาใหม่ได้อย่างอิสระ แต่การอนุญาตนั้นอาจถูก จำกัด ในบางประเทศที่ห้ามส่งออกซอฟต์แวร์การเข้ารหัส ในทำนองเดียวกันใบอนุญาตโอเพนซอร์สอนุญาตให้คุณใช้ซอฟต์แวร์เพื่อวัตถุประสงค์ใด ๆ แต่ไม่ได้หมายความว่าอนุญาตให้คุณแฮ็กเข้าธนาคารโดยใช้ซอฟต์แวร์ที่ได้รับอนุญาตแบบโอเพนซอร์ส สิทธิบัตรซอฟต์แวร์เป็นอีกตัวอย่างหนึ่งของสิ่งนี้: ใบอนุญาตโอเพนซอร์สบางใบอนุญาตให้ใช้สิทธิบัตรได้อย่างอิสระ แต่ไม่ใช่ทั้งหมด
ดังนั้นเราสามารถใช้ซอฟต์แวร์โอเพนซอร์สในการพัฒนาผลิตภัณฑ์หรือโครงการได้หรือไม่? โดยทั่วไปจะขึ้นอยู่กับใบอนุญาตของซอฟต์แวร์ที่ใช้และใบอนุญาตที่ตั้งใจไว้สำหรับผลิตภัณฑ์ขั้นสุดท้าย ใบอนุญาตต่างๆยังมีความสำคัญเมื่อคุณต้องการเผยแพร่รหัสของคุณเองเป็นโอเพนซอร์สและคุณกำลังตัดสินใจว่าควรใช้ใบอนุญาตใด
แนวคิดที่น่าสนใจอย่างหนึ่งเกี่ยวกับใบอนุญาตโอเพนซอร์สคือสิ่งที่มักเรียกว่า copyleft ซึ่งตรงกันข้ามกับลิขสิทธิ์ ในกรณีที่มีการใช้ลิขสิทธิ์เพื่อปกป้องทรัพย์สินทางปัญญา (รวมถึงซอฟต์แวร์) จากการถูกคัดลอกหรือแจกจ่ายจะมีการใช้ copyleft เพื่อให้แน่ใจว่าทรัพย์สินทางปัญญาและซอฟต์แวร์แบบโอเพนซอร์สสามารถคัดลอกหรือแจกจ่ายเป็นโอเพนซอร์สได้
ตามความแข็งแรงของมันมีสองประเภทของ copyleft:
นอกจากนี้ยังมีใบอนุญาตโอเพนซอร์สที่ไม่มี copyleft พวกเขาไม่สนใจเกี่ยวกับการเปิดกว้างของซอฟต์แวร์ที่ได้รับในอนาคต
ตามการอนุญาตใบอนุญาตยังสามารถแบ่งได้ใน:
โดยปกติแล้วใบอนุญาต copyleft ที่เข้มงวดจะเข้มงวดเช่นกันและใบอนุญาต copyleft ที่อ่อนแอจะได้รับอนุญาตมากกว่า แต่ไม่จำเป็นต้องเป็นเช่นนั้น
มีใบอนุญาตโอเพนซอร์สมากมาย Open Source Initiative ได้อนุมัติแล้วมากกว่า 80 รายการ บางอย่างซ้ำซ้อนและอาจถือได้ว่าเทียบเท่ากับคนอื่น ๆ อื่น ๆ มีความเฉพาะเจาะจงสำหรับผลประโยชน์ของผู้เผยแพร่ซอฟต์แวร์ (เช่นใบอนุญาต NASA) หรือสำหรับสภาพแวดล้อมหรือวัตถุประสงค์ที่กำหนด (เช่นใบอนุญาตชุมชนการศึกษาหรือใบอนุญาตแบบอักษรเปิด)
การเพิ่มจำนวนใบอนุญาตนี้เป็นไปตามข้อกำหนดเฉพาะในใบอนุญาตที่เพิ่มคุณสมบัติโอเพ่นซอร์สพื้นฐานอนุญาตหรือไม่อนุญาตการใช้งานอื่น ๆ ตัวอย่างของเงื่อนไขเพิ่มเติมเหล่านี้ ได้แก่ :
ตามสิ่งที่เราได้กล่าวไปแล้วก่อนหน้านี้ใบอนุญาตบางรายการอนุญาตให้ผู้ใช้รวมรหัสกับซอร์สโค้ดที่ได้รับอนุญาตต่างกัน (อาจมีเงื่อนไขเพิ่มเติม) กรณีนี้จะอนุญาตให้ผสมซอฟต์แวร์ลิขสิทธิ์โอเพนซอร์สประเภทนี้กับซอฟต์แวร์ปิด ตัวอย่างของใบอนุญาตประเภทนี้คือ MIT License
อื่น ๆ มีข้อ จำกัด มากกว่าดังนั้นซอร์สโค้ดจึงสามารถใช้ร่วมกับรหัสที่ได้รับอนุญาตในลักษณะเดียวกันเท่านั้นและผลลัพธ์สุดท้ายจะต้องได้รับอนุญาตด้วยใบอนุญาตดั้งเดิมเดียวกัน ตัวอย่างของใบอนุญาตประเภทนี้คือ General Public License (GPL)
บางทีคุณอาจต้องการรวมรหัสที่ได้รับอนุญาตกับใบอนุญาตโอเพนซอร์สที่มีข้อ จำกัด สองแบบ การใช้อิสระโอเพนซอร์สเพื่อใช้ซอฟต์แวร์ตามที่คุณต้องการคุณสามารถทำได้ แต่โปรแกรมสุดท้ายไม่สามารถแจกจ่ายซ้ำได้เนื่องจากควรแจกจ่ายภายใต้ใบอนุญาตสองใบที่ไม่สามารถใช้ร่วมกันได้
ตัวอย่างหนึ่งของสถานการณ์นี้คือ ZFS ZFS เป็นระบบไฟล์ขั้นสูงและเป็นนวัตกรรมใหม่ที่รวมอยู่ใน OpenSolaris ในปี 2548 เป็นซอฟต์แวร์โอเพ่นซอร์สที่ได้รับอนุญาตภายใต้เงื่อนไขของ Common Development and Distribution License (CDDL) แม้ว่าจะเป็นรหัสโอเพ่นซอร์ส แต่ก็ไม่สามารถรวมเข้ากับเคอร์เนล Linux ได้เนื่องจากซอร์สโค้ดของ ลินุกซ์ เผยแพร่ภายใต้เงื่อนไขของ General Public License ซึ่งเป็นสัญญาอนุญาตแบบโอเพนซอร์สที่มีข้อ จำกัด อื่น ๆ ไบนารีของเคอร์เนลลินุกซ์ที่คอมไพล์ด้วยการสนับสนุน ZFS ไม่สามารถแจกจ่ายได้เนื่องจากข้อขัดแย้งของใบอนุญาต
ความขัดแย้งประเภทนี้จะแก้ไขได้ก็ต่อเมื่อเจ้าของโปรแกรมโอเพนซอร์สทั้งหมดเห็นด้วยกับการเปลี่ยนใบอนุญาตหรือเพิ่มเงื่อนไขข้อยกเว้นในใบอนุญาตซอฟต์แวร์ ตัวอย่างเช่นโปรแกรมลิขสิทธิ์ GPL จำนวนมากเชื่อมโยงกับไลบรารี OpenSSL การแจกจ่ายไลบรารี OpenSSL ได้รับอนุญาตโดยต้องมีวลีปรากฏในสื่อโฆษณาและการแจกจ่ายซ้ำใด ๆ เงื่อนไขพิเศษเหล่านี้เข้ากันไม่ได้กับ GPL และเนื่องจากผู้พัฒนาผลิตภัณฑ์ GPL ที่ใช้ OpenSSL ได้รวมข้อยกเว้นไว้ในใบอนุญาตโดยเฉพาะที่อนุญาตให้เชื่อมโยงกับ OpenSSL
ตอนนี้ฉันจะพยายามวิเคราะห์ใบอนุญาตโอเพนซอร์สที่เป็นที่นิยมมากที่สุดโดยกล่าวถึงคุณสมบัติที่แตกต่างพร้อมคำแนะนำเล็กน้อยเกี่ยวกับเวลาที่ควรใช้หรือไม่ ฉันได้เรียงลำดับจากมากไปใช้น้อยตาม คลังความรู้ Black Duck .
ก๊าซหุงต้ม เป็นใบอนุญาตโอเพนซอร์สที่ได้รับความนิยมมากที่สุด FSF สร้างขึ้นเพื่อเป็นใบอนุญาตสำหรับโครงการ GNU และยังเป็นใบอนุญาตของเคอร์เนล Linux
ลักษณะที่แตกต่าง:
โดยปกติข้อความใบอนุญาตที่ใช้จะมีข้อความที่ระบุว่ามีการแจกจ่ายซอฟต์แวร์ภายใต้เงื่อนไขของ GPL เวอร์ชัน N (หรือเวอร์ชันที่ใหม่กว่า)
ปัจจุบันมีสิทธิ์การใช้งาน GPL อยู่สองเวอร์ชัน: v2 และ v3 เวอร์ชัน 3 ได้รับการเผยแพร่ในปี 2550 เพื่อแก้ไขปัญหาบางอย่างที่เกิดขึ้นตั้งแต่รุ่น 2 ในปี 1991
GPL v3 มีข้อกำหนดและเงื่อนไขพิเศษบางประการการจัดการกับกฎระเบียบความเข้ากันได้กับใบอนุญาตโอเพนซอร์สอื่น ๆ การออกใบอนุญาตสิทธิบัตรการกำหนดเงื่อนไขในการใช้ซอฟต์แวร์ที่ได้รับอนุญาตจาก GPL เป็นเฟิร์มแวร์ในอุปกรณ์และคำนึงถึงแนวคิดในการจัดการสิทธิ์ดิจิทัล
ใบอนุญาตโอเพนซอร์สมักเรียกว่า ใบอนุญาต MIT a.k.a. ใบอนุญาต X11 เป็นสิทธิ์การใช้งานแบบ non-copyleft ที่อนุญาตอย่างมากซึ่งช่วยให้ทุกคนสามารถใช้รหัสที่ได้รับอนุญาตโดยทั่วไปสำหรับสิ่งที่คุณต้องการตราบเท่าที่คุณเก็บข้อความลิขสิทธิ์ไว้และทราบว่าซอฟต์แวร์นั้นมาโดยไม่มีการรับประกันใด ๆ
ใบอนุญาตนี้ได้รับความนิยมอย่างมากและถูกใช้โดยหลายโครงการเช่น X Window System, Ruby on Rails, jQuery หรือ Node.js
เข้ากันได้กับ GPL ดังนั้นคุณจึงสามารถผสมรหัสที่ได้รับอนุญาตจาก MIT ลงในซอฟต์แวร์ GPL
ใบอนุญาต Apache ถูกสร้างขึ้นโดย Apache Software Foundation (ASF) เพื่อเป็นใบอนุญาตสำหรับ Apache HTTP Server
เช่นเดียวกับ MIT License เป็นใบอนุญาตแบบ non-copyleft ที่อนุญาตให้ใช้ซอฟต์แวร์เพื่อวัตถุประสงค์ใด ๆ แจกจ่ายแก้ไขและแจกจ่ายผลงานที่ได้รับมาโดยไม่ต้องกังวลเรื่องค่าลิขสิทธิ์ ความแตกต่างหลักเมื่อเทียบกับใบอนุญาต MIT คือ:
ใบอนุญาตนี้น่าสนใจเนื่องจากใบอนุญาตสิทธิบัตรอัตโนมัติและข้อเกี่ยวกับการส่งเงินบริจาค
มันเข้ากันได้กับ GPL ดังนั้นคุณจึงสามารถผสมรหัสลิขสิทธิ์ Apache ลงในซอฟต์แวร์ GPL ได้
มีใบอนุญาต BSD ที่แตกต่างกัน 3 ใบ ทั้งหมดนี้เป็นใบอนุญาตที่อนุญาตอย่างมากโดยไม่มี copyleft
ใบอนุญาต BSD 2 ข้อ (หรือ Simplified BSD License) เทียบเท่ากับ MIT License ที่ได้อธิบายไว้ก่อนหน้านี้
ใบอนุญาต BSD 3 ข้อ (หรือใบอนุญาต BSD ใหม่) เพิ่มหนึ่งประโยคโดยระบุว่าไม่สามารถใช้ชื่อของผู้ถือลิขสิทธิ์หรือชื่อของผู้มีส่วนร่วมในการรับรองหรือส่งเสริมผลิตภัณฑ์ที่ได้รับจากซอฟต์แวร์โดยไม่ได้รับอนุญาตเป็นลายลักษณ์อักษรล่วงหน้า เวอร์ชันนี้เข้ากันได้กับ GPL ช่วยให้คุณสามารถผสมรหัสที่ได้รับอนุญาต 3-clause-BSD ลงในซอฟต์แวร์ GPL
ใบอนุญาต BSD 4 ข้อ (หรือสิทธิ์การใช้งาน BSD ดั้งเดิม) เพิ่มข้ออื่นโดยระบุว่าสื่อโฆษณาทั้งหมดที่กล่าวถึงคุณสมบัติหรือการใช้ซอฟต์แวร์จะต้องแสดงการยอมรับว่าผลิตภัณฑ์มีซอฟต์แวร์ที่พัฒนาโดยผู้ถือลิขสิทธิ์ ใบอนุญาต BSD 4 ข้อนี้เข้ากันไม่ได้กับ GPL รหัสที่มีใบอนุญาตนี้ไม่สามารถเปลี่ยนใหม่ได้ตามข้อกำหนดของ GPL เนื่องจากข้อที่สี่เพิ่มข้อกำหนดที่ไม่จำเป็นใน GPL
LGPL ถูกสร้างขึ้นโดย FSF โดยเป็นการดัดแปลง GPL ด้วย copyleft ที่อ่อนกว่าทำให้สามารถเชื่อมโยงซอฟต์แวร์ที่ได้รับอนุญาตจาก LGPL กับซอฟต์แวร์อื่น ๆ ในต้นกำเนิด LGPL ย่อมาจาก 'Library General Public License' แต่หลังจากนั้นใช้ชื่อปัจจุบันว่า 'Lesser General Public License' ตามความเห็นของ FSF ที่ระบุว่าซอฟต์แวร์ทั้งหมดควรเป็นแบบฟรีและด้วยเหตุนี้ LGPL จึงไม่ควรเป็น ใช้โดยทั่วไป
คุณสามารถเชื่อมโยงซอร์สโค้ดกับไลบรารี LGPL หรือซอฟต์แวร์และแจกจ่ายผลลัพธ์สุดท้ายได้ตราบเท่าที่:
LGPL v3 เข้ากันได้กับ GPLv3 ดังนั้นคุณสามารถป้อนรหัส LGPLv3 ลงในซอฟต์แวร์ GPL ได้
ใบอนุญาตศิลปะ ในเวอร์ชันปัจจุบัน 2.0 เป็นใบอนุญาตโอเพนซอร์สที่อนุญาตโดยไม่มี copyleft คล้ายกับใบอนุญาต MIT
ข้อแตกต่างที่สำคัญระหว่างใบอนุญาต MIT และใบอนุญาตศิลปะคือข้อหลังกำหนดให้การแก้ไขใด ๆ ที่ทำกับรหัสต้องระบุไว้อย่างชัดเจน
ใบอนุญาตนี้เกือบจะใช้เฉพาะในชุมชน Perl
Artistic License 2.0 ปัจจุบันเข้ากันได้กับ GPL: คุณสามารถผสมรหัส Artistic-Licensed กับซอฟต์แวร์ GPL
ใบอนุญาตสาธารณะของ Microsoft ก่อตั้งขึ้นในปี 2008 โดย บริษัท นี้เป็นหนึ่งในใบอนุญาตโอเพนซอร์สที่สร้างโดย Shared Source Initiative
เป็นใบอนุญาตที่เข้มงวดและอ่อนแอ: อนุญาตให้สร้างและแจกจ่ายโปรแกรมปิดที่มาพร้อมรหัส MS-PLed แต่จำเป็นต้องใช้ MS-PL เป็นใบอนุญาตของงานที่ได้รับหากมีการแจกจ่ายในซอร์สโค้ด
โดยส่วนตัวแล้วฉันคิดว่าใบอนุญาตนี้ค่อนข้างวิปริตและขัดกับเจตนารมณ์ของโอเพ่นซอร์สที่อนุญาตให้ปิดโค้ดเพื่อที่ผู้ถือลิขสิทธิ์จะไม่สนใจว่าคุณสามารถทำอะไรกับซอฟต์แวร์ได้ แต่คุณทำไม่ได้ แบ่งปันรหัสเพื่อผสมกับซอร์สโค้ด copyleft อื่น ๆ ในอีกทางหนึ่งเจ้าของลิขสิทธิ์สนใจในสิ่งที่คุณทำได้และเขาไม่ต้องการให้คุณใช้โค้ดด้วยเหตุผลเช่นการปรับปรุง Linux
MS-PL เข้ากันไม่ได้กับ GPL
สิทธิ์การใช้งานสาธารณะ Eclipse เป็นไลเซนส์ที่สร้างขึ้นโดย Eclipse Foundation สำหรับสภาพแวดล้อมการพัฒนาแบบบูรณาการ เป็นสัญญาอนุญาตที่เข้มงวดและอ่อนแอคล้ายกับ LGPL ในหลาย ๆ ด้าน นอกจากนี้ยังรวมถึงอนุประโยคสำหรับการให้ใบอนุญาตสิทธิบัตรอัตโนมัติ
EPL เข้ากันไม่ได้กับ GPL
Mozilla Public License เวอร์ชัน 2.0 เป็นสิทธิ์การใช้งานที่อ่อนแอซึ่งได้รับอนุญาตซึ่งสร้างขึ้นโดย Mozilla Foundation สำหรับผลิตภัณฑ์
เราสามารถพิจารณาสิทธิ์การใช้งานนี้คล้ายกับ LGPL แต่ด้วยความแตกต่างที่สำคัญที่ MPL ยังอนุญาตให้มีการเชื่อมโยงโค้ด MPLed แบบคงที่เข้ากับซอฟต์แวร์ปิด
MPL ในเวอร์ชันปัจจุบัน 2.0 เข้ากันได้กับ GPL สิ่งนี้ไม่เป็นความจริงสำหรับ MPL เวอร์ชันก่อนหน้า
CDDL เป็นสิทธิ์การใช้งานที่อ่อนแอและได้รับอนุญาตซึ่งสร้างโดย Sun (ปัจจุบันคือ Oracle) โดยใช้ MPL เวอร์ชัน 1.1 โดยทั่วไปมีคุณสมบัติเช่นเดียวกับ MPL มีการชี้แจงข้อกำหนด แต่ไม่มีการเปลี่ยนแปลงอย่างมีนัยสำคัญ
CDDL เป็นใบอนุญาตโอเพนซอร์สที่ Sun (ปัจจุบันเป็น Oracle) เลือกสำหรับผลิตภัณฑ์หลายประเภทเช่น OpenSolaris หรือ NetBeans เป็นต้น
เนื่องจากใบอนุญาตนี้เป็นไปตาม MPLv1.1 ใบอนุญาตนี้จึงไม่สามารถใช้งานร่วมกับ GPL ได้ดังนั้นคุณจึงไม่สามารถผสมแหล่งที่ได้รับอนุญาตจาก CDDL เข้ากับซอฟต์แวร์ลิขสิทธิ์ GPL ได้ หลายคนบอกว่านี่เป็นความตั้งใจดังนั้นซอร์สโค้ด OpenSolaris จึงไม่สามารถนำไปใช้ในเคอร์เนล Linux ได้
AGPL เป็นรุ่นของ GPL ที่มี copyleft ที่แข็งแกร่งและเข้มงวดมากขึ้น มีหน้าที่ต้องให้ซอร์สโค้ดของแอปพลิเคชันไม่เพียง แต่กับผู้ที่ได้รับสำเนาซอฟต์แวร์เท่านั้น แต่ยังรวมถึงผู้ที่ใช้ซอฟต์แวร์นี้ผ่านเครือข่ายคอมพิวเตอร์ด้วย
ใบอนุญาตนี้สร้างขึ้นโดย FSF เพื่อให้ไฟล์ นักพัฒนา วิธีการหลีกเลี่ยงการปิดซอฟต์แวร์โอเพนซอร์สในทางปฏิบัติเมื่อดำเนินการในเซิร์ฟเวอร์เครือข่ายหรือในระบบคลาวด์เนื่องจาก GPL ไม่สามารถบังคับให้ผู้ให้บริการให้ซอร์สโค้ดแก่ผู้ใช้ ในกรณีนี้จะไม่มีการแจกจ่ายซอฟต์แวร์
AGPLv3 เข้ากันได้กับ GPL3 คุณสามารถใส่รหัส AGPLv3 ลงในรหัส GPLv3 ได้ตราบเท่าที่ผลลัพธ์สุดท้ายได้รับอนุญาตภายใต้ AGPLv3
ใบอนุญาต ISC เป็นใบอนุญาตซอฟต์แวร์เสรีที่ได้รับอนุญาตซึ่งเขียนโดย Internet Software Consortium (ISC) ฟังก์ชันนี้เทียบเท่ากับสิทธิ์การใช้งาน BSD และ MIT 2 ข้อหลังจากลบบางภาษาที่คิดว่าไม่จำเป็นออกไป
เริ่มแรกใช้สำหรับการเปิดตัวซอฟต์แวร์ของ ISC เองนับตั้งแต่นั้นมาได้กลายเป็นใบอนุญาตที่ต้องการของ OpenBSD (ตั้งแต่เดือนมิถุนายน 2546) รวมถึงโครงการอื่น ๆ
เข้ากันได้กับ GPL: คุณสามารถผสมรหัสที่ได้รับอนุญาตจาก ISC ลงในซอฟต์แวร์ GPL
ใบอนุญาตซึ่งกันและกันของ Microsoft ก่อตั้งขึ้นในปี 2008 โดย บริษัท นี้เป็นหนึ่งในใบอนุญาตโอเพนซอร์สที่สร้างโดย Shared Source Initiative
คล้ายกับ MS-PL ที่อธิบายไว้ก่อนหน้านี้ แต่มี copyleft ที่แข็งแกร่งกว่าเล็กน้อยคล้ายกับเงื่อนไขของ LGPL, CDDL และ EPL กำหนดว่าหากคุณผสมรหัสของคุณกับซอร์สโค้ดที่ได้รับอนุญาต MS-RL และต้องการเผยแพร่ผลลัพธ์ขั้นสุดท้ายอย่างน้อยส่วนที่ได้รับอนุญาต MS-RL ดั้งเดิมจะต้องได้รับใบอนุญาตจากใบอนุญาตนี้ต่อไป
เข้ากันไม่ได้กับ GPL
ตามวิกิพีเดีย 'งานที่เป็นสาธารณสมบัติคือผู้ที่สิทธิ์ในทรัพย์สินทางปัญญาหมดอายุถูกริบหรือไม่สามารถใช้งานได้' การอุทิศงานให้เป็นสาธารณสมบัติผู้เขียนสละสิทธิ์ทั้งหมดภายใต้กฎหมายลิขสิทธิ์
มีโครงการซอฟต์แวร์หลายโครงการภายใต้โดเมนสาธารณะตัวอย่างเช่น SQLite ไลบรารีที่ใช้เอ็นจิ้นฐานข้อมูล SQL แบบฝังได้และเรียบง่ายซึ่งรวมอยู่ในโครงการอื่น ๆ เช่นโครงการ Mozilla Android เป็นต้น
มีหลายวิธีในการอุทิศซอฟต์แวร์ให้เป็นสาธารณสมบัติ ครีเอทีฟคอมมอนส์ได้สร้างไฟล์ CC0 การอุทิศโดเมนสาธารณะ ซึ่งเป็นวิธีสากลในการมอบงานให้เป็นสาธารณสมบัติ FSF แนะนำให้ใช้ข้อความนี้เพื่ออุทิศซอฟต์แวร์ให้เป็นสาธารณสมบัติ
งานภายใต้โดเมนสาธารณะเข้ากันได้กับใบอนุญาตโอเพนซอร์สหรือแบบปิดและสามารถผสมกับซอฟต์แวร์อื่น ๆ ได้
มีซอฟต์แวร์โอเพนซอร์สบางตัวที่ได้รับอนุญาตเป็นสองเท่าหรือสามเท่า ซึ่งหมายความว่าผู้ที่ได้รับซอฟต์แวร์ลิขสิทธิ์หลายตัวนี้สามารถเลือกได้ว่าต้องการเผยแพร่ใบอนุญาตใด เนื่องจากทุกใบอนุญาตให้สิทธิ์ที่แตกต่างกันและกำหนดภาระหน้าที่ที่แตกต่างกันจึงต้องมีการเลือกเพื่อเลือกใบอนุญาตที่ตรงกับความต้องการมากที่สุด
นี่เป็นกรณีปกติสำหรับห้องสมุดบางแห่ง ตัวอย่างเช่น NSS เป็นไลบรารีที่สร้างโดย Mozilla ซึ่งใช้การสนับสนุน SSL / TLS ท่ามกลางคุณสมบัติอื่น ๆ ที่เกี่ยวข้องกับความปลอดภัย ได้รับอนุญาตแบบสามเท่าภายใต้ใบอนุญาต MPL, GPL และ LGPL
ผู้คนจำนวนมากเผยแพร่โค้ดในแพลตฟอร์มเป็น GitHub โดยไม่มีใบอนุญาตเป็นลายลักษณ์อักษร ไม่ควรมีใครใช้รหัสนั้น เราไม่รู้เลยว่าเรามีสิทธิ์อะไรบ้างในการใช้งาน หากคุณใช้มันคุณอาจถูกฟ้องร้องได้ เหมือนกับว่าคนเหล่านี้แกล้งเราโดยพูดว่า“ เฮ้ดูสิว่าฉันทำอะไรลงไป! เจ๋งใช่มั้ย แต่คุณใช้ไม่ได้ฉันแค่อยากจะแสดงให้คุณเห็น!”
โปรดอย่าเป็นหนึ่งในนั้น หากคุณอัปโหลดรหัสของคุณไปยัง GitHub หรือไซต์สาธารณะที่คล้ายกันให้อนุญาตให้ผู้อื่นใช้และปรับปรุง ถ้าคุณไม่อยากคิดมากนี่คือคำแนะนำของฉัน:
หากคุณสนใจเกี่ยวกับการแชร์การแก้ไขและไม่ต้องการให้ใช้โค้ดของคุณในการพัฒนาแบบปิด (ไม่ว่าจะในผลิตภัณฑ์ซอฟต์แวร์แบบปิดหรือในอุปกรณ์ฮาร์ดแวร์แบบปิด) ให้ใช้ GPL v3
หลังจากนี้คุณอาจเบื่อหน่ายกับคำพูดพล่อยๆที่เกือบจะไร้สาระเหล่านี้ แต่คุณรู้อะไรไหม? จำเป็น เนื่องจากหากไม่มีใบอนุญาตคุณจึงไม่มีสิทธิ์ในการใช้หรือแจกจ่ายรหัสใด ๆ