ใบอนุญาต GitHub – เรากำลังพูดถึงอะไร ในการสร้างซอฟต์แวร์นั้น เราต้องไม่เพียงแค่เขียนมันเท่านั้น แต่ยังต้องตัดสินใจว่าผู้ใช้หรือนักพัฒนามีสิทธิ์ทำอะไรกับซอฟต์แวร์นั้นด้วย ถ้ามีคนสร้างโปรแกรมฟรีสำหรับทุกคน เขาก็กำลังทำความดีอยู่ แต่ใครก็ตามที่ใช้โปรแกรมนั้นจะต้องพิสูจน์ว่าเขาใช้อย่างไร ตัวอย่างเช่น หากบริษัทในกิจกรรมจะทำงานร่วมกับสำนักงานฟรีบางแห่ง (เช่น LibreOffice) บริษัทจะต้องสามารถพิสูจน์ให้ผู้ตรวจสอบทราบว่ามีสิทธิ์ทำเช่นนั้น ในการทำเช่นนี้การนำเสนอใบอนุญาตที่เหมาะสมก็เพียงพอแล้ว หากผู้พัฒนาลืมกำหนด แสดงว่าบริษัทอาจอยู่ในสถานะที่ยากลำบาก
ทำไมคุณต้องอนุญาตโครงการโอเพ่นซอร์สบน GitHub
เมื่อระบุใบอนุญาตที่จำเป็น ผู้พัฒนาสามารถระบุสิ่งต่อไปนี้ได้:
- เงื่อนไขการใช้ งานโปรแกรม พวกเขาอาจมีค่าธรรมเนียมหรืออนุญาตให้ใช้งานฟรีในบางกรณีหรือทั้งหมด
- บางครั้งโปรแกรมถูกสร้างขึ้นเพื่อพัฒนาโดยชุมชน ในกรณีนี้เป็นสิ่งสำคัญที่ทุกคนที่ต้องการทำความคุ้นเคยกับข้อความของโปรแกรม
- เมื่อมีข้อความของโปรแกรม บางคนอาจทำการเปลี่ยนแปลงเพื่อให้โปรแกรมทำงานได้และเชื่อถือได้มากที่สุด บางครั้งผู้เขียนสามารถอนุญาตให้ทุกคนทำเช่นนี้ได้ ในบางกรณีเขาเสนอให้ส่งการเปลี่ยนแปลงให้เขา และทำการปรับเปลี่ยนโครงการด้วยตัวเขาเอง
- คุณต้องตัดสินใจว่าบุคคลที่สามสามารถเปลี่ยนแปลงโครงการและเสนอในนามของพวกเขาได้หรือไม่ เมื่อทำเช่นนี้ คุณต้องระบุว่าผลิตภัณฑ์ของตนควรได้รับใบอนุญาตใด
การแก้ไขคำถามเหล่านี้และคำถามที่คล้ายกัน ผู้เขียนแอปพลิเคชันนั้นส่วนใหญ่กำหนดชะตากรรมในอนาคตของผลิตภัณฑ์ซอฟต์แวร์ที่เขาสร้างขึ้น
มีใบอนุญาตประเภทใดบ้าง
ใบอนุญาตคือข้อตกลงที่ฝ่ายหนึ่ง (ผู้อนุญาต) กำหนดกฎให้อีกฝ่ายหนึ่ง (ผู้รับใบอนุญาต) ใช้ผลิตภัณฑ์ที่เขาสร้างขึ้น ในทางปฏิบัติ เราไม่ได้พูดถึงการลงนามในเอกสารโดยคู่สัญญา แต่เกี่ยวกับข้อตกลงอัตโนมัติกับสิทธิ์และภาระผูกพันที่เกี่ยวข้องในการใช้งาน แทบไม่มีข้อ จำกัด ในการระบุสิทธิ์และภาระผูกพัน เงื่อนไขเดียวคือต้องปฏิบัติตามกฎหมาย การสร้างใบอนุญาตของคุณเองเป็นงานที่ซับซ้อน เนื่องจากต้องสอดคล้องกับระเบียบข้อบังคับอื่นๆ ตัวเลือกที่ดีที่สุดคือการเลือกและใช้หนึ่งในเอกสารมาตรฐานดังกล่าว ในทางปฏิบัติ เป็นเรื่องปกติที่จะใช้ multilicensing ในกรณีเช่นนี้ ส่วนใหญ่มักใช้ใบอนุญาตสองใบพร้อมกัน แม้ว่าผู้เขียนโปรแกรมจะมีสิทธิ์กำหนดกฎเกณฑ์ที่ผู้ใช้ต้องปฏิบัติตามอย่างอิสระ แต่ในทางปฏิบัติ มีการพัฒนาการใช้ใบอนุญาตหลายประเภท ซึ่งคุณสามารถเลือกประเภทที่เหมาะสมได้ในกรณีส่วนใหญ่ ต่อไปนี้คือตัวเลือกยอดนิยมที่ใช้กับ Git Hub ในกรณีส่วนใหญ่ ใบอนุญาตที่ใช้บ่อยที่สุดใน Git Hub คือ:
หากผู้เขียนปฏิเสธที่จะจัดทำเอกสาร ในกรณีนี้ ลิขสิทธิ์จะมีผลบังคับใช้ ซึ่งกฎหมายของประเทศของเขากำหนดไว้โดยปริยาย การไม่มีสิทธิ์ใช้งานในลักษณะนี้ไม่ได้หมายความว่าโปรแกรมจะทำอะไรได้บ้าง อันที่จริง สถานการณ์ดังกล่าวถือได้ว่าเป็นใบอนุญาตประเภทหนึ่ง
วิธีเลือกใบอนุญาต Github
ก่อนที่คุณจะเริ่มมองหาตัวเลือกที่เหมาะสม โปรแกรมเมอร์จำเป็นต้องกำหนดข้อกำหนดของเขา ซึ่งเขาจะดำเนินการออกใบอนุญาตเพิ่มเติม ต่อไป คุณควรทำความคุ้นเคยกับตัวเลือกทั่วไปที่ตรงกับคำขอ หลังจากนั้น คุณจะต้องศึกษาภาษากฎหมายอย่างรอบคอบและตัดสินใจขั้นสุดท้ายว่าใบอนุญาตควรเป็นอย่างไร ในการตัดสินใจเลือกอย่างมีข้อมูล คุณต้องเข้าใจว่าสิทธิ์และภาระผูกพันใดที่เกี่ยวข้องกับใบอนุญาตบางประเภท เพื่อเป็นทางเลือกที่ถูกต้อง คุณสามารถใช้บริการพิเศษที่เรียกว่าตัวเปรียบเทียบ นี่คือตัวอย่างบางส่วน:
- https://choosealicense.com/. ไซต์นี้มีคำถามชั้นนำสำหรับการเลือกตัวเลือกที่เหมาะสมและคำแนะนำโดยละเอียดเพื่อช่วยให้คุณเข้าใจคุณลักษณะการใช้งาน
- หน้า https://opensource.org/licenses มีไว้เพื่อตรวจสอบโซลูชันซอฟต์แวร์ฟรีต่างๆ
- เว็บไซต์ https://tldrlegal.com/ ถือเป็นสารานุกรมสำหรับตัวเลือกใบอนุญาตต่างๆ มีทั้งข้อกำหนดทางกฎหมายที่แม่นยำและความคิดเห็นโดยละเอียด
วิธีเพิ่มใบอนุญาตให้กับ Github
แม้จะมีตัวเลือกใบอนุญาตมากมายที่ได้รับการพิสูจน์แล้วว่ามีประสิทธิภาพและเชื่อถือได้ในทางปฏิบัติ นักพัฒนาซอฟต์แวร์อาจมีความคิดของตัวเองว่าใบอนุญาตสำหรับโปรแกรมที่เขาสร้างขึ้นควรเป็นอย่างไร ในกรณีนี้ บริการให้ความสามารถในการเพิ่มเวอร์ชันของคุณเองหรือปรับเปลี่ยนเวอร์ชันที่มีอยู่ ในการเพิ่มใบอนุญาตให้กับ Github คุณจะต้องทำตามขั้นตอนเหล่านี้:
- คุณต้องไปที่หน้าหลักของที่เก็บของคุณ
- คุณต้องคลิกที่ปุ่มเพื่อเพิ่มไฟล์ จากนั้นเลือก “สร้างไฟล์ใหม่”
- ถัดไป คุณต้องป้อนชื่อไฟล์ สำหรับใบอนุญาต อาจเป็นหนึ่งในสองตัวเลือก: LICENSE หรือ LICENCE.md ที่นี่จำเป็นต้องใช้ตัวพิมพ์ใหญ่
- ทางด้านขวาของช่องป้อนชื่อไฟล์ ให้คลิกเพื่อเลือกเทมเพลตใบอนุญาต
- ในเมนูทางด้านซ้ายของหน้า เลือกบรรทัด “เพิ่มใบอนุญาตให้กับโครงการของคุณ” ในกรณีนี้ ตัวแปรจะถูกเลือกจากเอกสารที่มีอยู่
- จากนั้นคลิกที่บรรทัด “ตรวจสอบและส่ง” จากนั้นป้อนรายละเอียดข้อตกลงของคุณ
- หลังจากนั้น มีความจำเป็นต้องชี้แจงว่ามีการเพิ่มเติมหรือเปลี่ยนแปลงอะไรบ้าง ถัดไป ระบุว่าเอกสารที่เลือกได้รับการแก้ไขหรือไม่ หรือเป็นเรื่องเกี่ยวกับการสร้างใบอนุญาตเวอร์ชันอื่น
หลังจากยืนยันการเปลี่ยนแปลงแล้ว ผู้พัฒนาจะดำเนินการตามขั้นตอนสำหรับการเปลี่ยนแปลงรายการใบอนุญาตในบริการ Git Hub
เลือกใบอนุญาต Github – ตัวอย่างใบอนุญาตยอดนิยมบน Git Hub
ต่อไปนี้เป็นตัวเลือกที่ได้รับความนิยมมากที่สุด ด้วยการทำความเข้าใจจุดแข็งและจุดอ่อนของพวกเขา โปรแกรมเมอร์จะสามารถค้นหาตัวเลือกที่เหมาะสมหรือเข้าใจวิธีการค้นหาอย่างมีประสิทธิภาพ
GPL
ใบอนุญาตนี้สามารถเรียกได้ว่าเป็นที่นิยมมากที่สุด เป็นแบบคลาสสิกสำหรับผู้ที่ผลิตซอฟต์แวร์ฟรี ข้อกำหนดหลักประการหนึ่งของเอกสารนี้คือ
อนุญาตให้บุคคลที่สามแก้ไขโปรแกรมได้อย่างอิสระแต่ในขณะเดียวกันก็มีสิทธิ์เผยแพร่ผลลัพธ์ภายใต้ใบอนุญาตเดียวกันเท่านั้น ใบอนุญาตนี้อาจมีเวอร์ชันต่างกัน ล่าสุดคือตัวที่สาม GPL ถูกใช้โดยนักพัฒนาโปรแกรมต่างๆ เช่น ระบบจัดการเนื้อหาเว็บของ Drupal, ระบบจัดการฐานข้อมูล MariaDB, โปรแกรมแก้ไขกราฟิกแบบเวกเตอร์ InkSkape และอื่นๆ เป็นที่น่าสนใจที่จะทราบว่า SQL ไม่เพียงใช้ GPL เท่านั้น แต่ยังใช้ใบอนุญาตเชิงพาณิชย์ด้วย
LGPL
ชื่อนี้แปลว่า “GNU GPL Lesser General Public License” สำหรับนักพัฒนาซอฟต์แวร์บางราย GPL ไม่เหมาะสม เนื่องจากเป็นการสร้างภาระหน้าที่ให้พวกเขาแจกจ่ายผลิตภัณฑ์ที่ดัดแปลงภายใต้ใบอนุญาตเดียวกัน คุณสมบัติของแอพพลิเคชั่นของตัวเลือกนี้สามารถแสดงให้เห็นได้ว่ากระบวนการออกใบอนุญาตการใช้ไลบรารีที่สร้างโดยโปรแกรมเมอร์เกิดขึ้นได้อย่างไร ในกรณีนี้ จะพิจารณาสามตัวเลือกต่อไปนี้:
- เมื่อไลบรารี่มีฟังก์ชันการทำงานใหม่ที่ห้องสมุดเชิงพาณิชย์อื่นไม่สามารถทำเช่นเดียวกันได้ GPL คือตัวเลือกที่ดีที่สุด
- นักพัฒนาในห้องสมุดฟรีได้ใช้มาตรฐานที่มีอยู่แล้ว ในบริเวณนี้ มีตัวเลือกทางการค้าที่มีฟังก์ชันคล้ายคลึงกัน สำหรับกรณีนี้จะสะดวกในการเลือก LGPL
- เมื่อพูดถึงมาตรฐานใหม่ที่แข่งขันกับมาตรฐานเชิงพาณิชย์ ใบอนุญาต Apache เป็นวิธีที่จะไป
มาตรฐานนี้
อนุญาตให้ใช้ห้องสมุดในเชิงพาณิชย์ได้ หากมีการแก้ไข ต้องใช้ข้อกำหนดและเงื่อนไขเดียวกันสำหรับการแจกจ่าย อย่างไรก็ตาม การใช้รหัสอย่างง่ายทำให้เงื่อนไขเปลี่ยนแปลงได้
Eclipse ใบอนุญาตสาธารณะ
เอกสารนี้
อนุญาตให้เผยแพร่ภายใต้ใบอนุญาตอื่นๆ รวมถึงใบอนุญาตเชิงพาณิชย์ เงื่อนไขหลักคือในงานดัดแปลง นวัตกรรมจะอยู่ในโมดูลแยกต่างหาก ใบอนุญาตนี้ได้รับความนิยมในการพัฒนาผลิตภัณฑ์ใน Java ตัวอย่างคือภาษาการเขียนโปรแกรม Clojure ซึ่งเป็นเฟรมเวิร์กสำหรับการทดสอบแอปพลิเคชันจาวา
ใบอนุญาตสาธารณะของ Mozilla
บางคนมองว่าเอกสารนี้เป็นการประนีประนอมระหว่าง GPL และใบอนุญาตเชิงพาณิชย์ MPL ต้องการ
การเข้าถึงไฟล์บางไฟล์แบบเปิด ผลิตภัณฑ์ซอฟต์แวร์อาจมีไฟล์บางไฟล์ภายใต้ใบอนุญาตนี้ และไฟล์อื่นๆ ที่ไม่มีไฟล์ดังกล่าว หลังจากการปรับเปลี่ยน อนุญาตให้ใส่ใบอนุญาตที่จำเป็น (เช่น อาจเป็นใบอนุญาตเชิงพาณิชย์) แต่ทำได้เฉพาะในเงื่อนไขที่ยังคงเปิดการเข้าถึงไฟล์ที่เผยแพร่ภายใต้ MPL ได้ ในกรณีนี้ ผู้ใช้ต้องได้รับข้อมูลเกี่ยวกับผู้สร้างซอฟต์แวร์ดั้งเดิม ตามเอกสารนี้ สำนักงาน LibreOffice เบราว์เซอร์ Mozilla และผลิตภัณฑ์ซอฟต์แวร์อื่น ๆ ได้รับการเผยแพร่
Apache License Github
AL เรียกว่าใบอนุญาตเสรีเสรี คุณลักษณะนี้เกิดจากการที่
ไม่มีข้อกำหนดในการปล่อยผลิตภัณฑ์อนุพันธ์ภายใต้เงื่อนไขเดิมเหมือนเมื่อก่อน เอกสารนี้ถูกใช้อย่างแข็งขันโดย Apache Software Foundation เมื่อใช้ อนุญาตสิ่งต่อไปนี้:
- ผลิตภัณฑ์ซอฟต์แวร์ได้รับอนุญาตให้นำไปใช้เพื่อวัตถุประสงค์ทางการค้าต่อไปได้
- อนุญาตให้แก้ไขแอปพลิเคชัน
- การแจกแจงครั้งต่อไปควรมีชื่อผู้แต่งต้นฉบับ
โดยการสร้างตัวเลือกสินค้าใหม่ ไม่มีภาระผูกพันสำหรับผู้ได้รับอนุญาตในการจัดเตรียมรหัสผลิตภัณฑ์ดั้งเดิม ใบอนุญาตดังกล่าวได้รับความนิยมอย่างมาก สิ่งนี้สามารถแสดงให้เห็นได้โดยการแสดงรายการผลิตภัณฑ์ซอฟต์แวร์ที่มีชื่อเสียงซึ่งเผยแพร่ภายใต้ลิขสิทธิ์ประเภทนี้: ระบบปฏิบัติการ Android, เฟรมเวิร์กที่สร้างแอปพลิเคชันระดับองค์กรใน Java และเว็บเซิร์ฟเวอร์ Apache https://youtu.be/wyZq-EazOmU
ใบอนุญาต MIT
บางคนถือว่าตัวเลือกลิขสิทธิ์ซอฟต์แวร์ฟรีนี้เป็นที่นิยมมากที่สุด ข้อได้เปรียบหลักบางส่วนถือว่าเข้ากันได้ดีกับใบอนุญาตฟรีหรือเชิงพาณิชย์ประเภทต่างๆ คุณลักษณะที่สำคัญที่สุดคือ
ความสามารถในการแก้ไขโค้ด รวมถึงการอนุญาตให้เผยแพร่ภายใต้ใบอนุญาตอื่นๆ โดยขึ้นอยู่กับตัวเลือกของผู้ทำการเปลี่ยนแปลง ผลิตภัณฑ์ซอฟต์แวร์ที่ใช้เอกสารนี้ ได้แก่ ไลบรารี JavaScript ชื่อ JQuiery โปรแกรมแก้ไขข้อความ Atom AngularJS เฟรมเวิร์กการพัฒนา JavaScript
หินใต้น้ำ
บางครั้งผู้เขียนในตอนแรกเลือกใบอนุญาตหนึ่งเวอร์ชันและต้องการเปลี่ยนในภายหลัง ถ้าเขาสร้างโปรแกรมเพียงอย่างเดียว การเปลี่ยนแปลงดังกล่าวก็ไม่ยาก อย่างไรก็ตาม ในกรณีที่มีผู้เข้าร่วมจำนวนมากในการพัฒนา การดำเนินการนี้จะไม่ทำงานหากไม่ได้รับความยินยอมจากพวกเขา ตัวอย่างเช่น ผู้สร้างลินุกซ์ แม้ว่าเขาจะสร้างพื้นฐานของระบบปฏิบัติการจริง ๆ ก็ตาม จะไม่สามารถเปลี่ยนแปลงใบอนุญาตได้หากไม่ได้รับความยินยอมจากโปรแกรมเมอร์ทุกคนที่มีส่วนร่วมในการพัฒนาต่อไป เมื่อเผยแพร่ภายใต้ MPL ผู้ที่ทำการเปลี่ยนแปลงโค้ดจะไม่สามารถเสนอไฟล์ภายใต้ MPL ภายใต้ใบอนุญาตอื่นได้ การใช้เอกสารใหม่จะอ้างถึงโมดูลโปรแกรมอื่น
