การขยายใบอนุญาต

จากวิกิพีเดีย สารานุกรมเสรี
ข้ามไปที่การนำทาง ข้ามไปที่การค้นหา

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

ผลกระทบ

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

ความเข้ากันได้ของใบอนุญาต

การเพิ่มจำนวนใบอนุญาตเป็นปัญหาโดยเฉพาะอย่างยิ่งเมื่อใบอนุญาตมี ความสัมพันธ์ที่ เข้ากันได้ กับใบอนุญาตที่จำกัดหรือซับซ้อน กับใบอนุญาตอื่นๆ ดังนั้นบางคนจึงถือว่าความเข้ากันได้กับ GNU General Public License (GPL) ที่ ใช้กันอย่างแพร่หลายเป็นคุณลักษณะที่สำคัญ เช่น David A. Wheeler [2] [3]เช่นเดียวกับFree Software Foundation (FSF) ซึ่งดูแลรายการใบอนุญาตที่ เข้ากันได้กับ GPL [4]ในทางกลับกัน บางคนแนะนำPermissive licensesแทนที่จะเป็นcopyleft licenses [ 5]เนื่องจากความเข้ากันได้ดีกว่ากับใบอนุญาตที่มากกว่า [6] [7]ดิตัวอย่างเช่น มูลนิธิ Apacheวิพากษ์วิจารณ์ข้อเท็จจริงที่ว่าแม้ว่าใบอนุญาต Apacheจะเข้ากันได้กับ GPLv3 copyleft แต่ GPLv3 ไม่เข้ากันกับใบอนุญาต Apache ที่อนุญาต — ซอฟต์แวร์ Apache สามารถรวมอยู่ในซอฟต์แวร์ GPLv3 ได้ แต่ไม่สามารถรวมไว้ในซอฟต์แวร์ GPLv3 ได้ [8]อีกตัวอย่างหนึ่งที่เกี่ยวข้องGPLv2นั้นไม่สามารถทำงานร่วมกับGPLv3ได้ [9] 2550 ที่ปล่อย GPLv3 ถูกวิพากษ์วิจารณ์จากผู้เขียนหลายคนสำหรับการเพิ่มใบอนุญาตที่เข้ากันไม่ได้ในระบบนิเวศ FOSS [10] [11] [12] [13] [14] [15] [16]

ใบอนุญาตโต๊ะเครื่องแป้ง

ใบอนุญาตโต๊ะเครื่องแป้งคือใบอนุญาตที่เขียนขึ้นโดยบริษัทหรือบุคคลที่ไม่มีเหตุผลอื่นนอกจากการเขียนใบอนุญาตของตนเอง (" กลุ่มอาการ NIH ") [17]หากมีการสร้างใบอนุญาตใหม่ซึ่งไม่มีการปรับปรุงหรือความแตกต่างอย่างชัดเจนจากใบอนุญาต FOSS อื่นๆ ที่มักใช้กันทั่วไป มักถูกวิพากษ์วิจารณ์ว่าเป็นใบอนุญาตแบบไร้สาระ ในปี 2008 ผู้คนจำนวนมากสร้างใบอนุญาตใหม่แบบกำหนดเองสำหรับโปรแกรมที่เพิ่งเปิดตัวใหม่ โดยไม่ทราบข้อกำหนดสำหรับสิทธิ์ใช้งาน FOSS และโดยไม่ทราบว่าการใช้สิทธิ์ใช้งานที่ไม่เป็นมาตรฐานจะทำให้โปรแกรมนั้นแทบไม่มีประโยชน์สำหรับผู้อื่น [18]

วิธีการแก้ปัญหา

จุดยืนของ GitHub

ในเดือนกรกฎาคม 2013 GitHub ได้ เริ่มวิซาร์ดการเลือกใบอนุญาตชื่อchoosealicense [19] หน้าแรกของ choosealicenseของ GitHub เสนอตัวเลือกอย่างรวดเร็วเพียงสามใบอนุญาต: ใบอนุญาตMIT , ใบ อนุญาต Apacheและ ใบอนุญาตสาธารณะทั่วไป ของGNU มีการเสนอใบอนุญาตเพิ่มเติมบางส่วนในหน้าย่อยและผ่านลิงก์ (20)ติดตามในปี 2558 ประมาณ 77% ของโปรเจ็กต์ที่ได้รับอนุญาตทั้งหมดบน GitHub ได้รับอนุญาตภายใต้อย่างน้อยหนึ่งในสามใบอนุญาต (21)

จุดยืนของ Google

ตั้งแต่ปี 2549 Google Codeยอมรับเฉพาะโครงการที่ได้รับอนุญาตภายใต้ใบอนุญาตเจ็ดรายการต่อไปนี้: [22]

หนึ่งปีให้หลัง ประมาณปี 2008 GNU General Public License 3.0 ถูกเพิ่มเข้ามา และแนะนำอย่างยิ่งร่วมกับใบอนุญาต Apache ที่อนุญาต[23] ที่ยกเว้นอย่างชัดเจนคือAGPLv3เพื่อลดการแพร่กระจายของใบอนุญาต [24]

ในปี 2010 Google ได้ยกเลิกข้อจำกัดเหล่านี้ และประกาศว่าจะอนุญาตให้โครงการต่างๆ ใช้ใบอนุญาตใดๆ ที่ได้รับการอนุมัติจาก OSI (ดูจุดยืนของ OSIด้านล่าง) [25]แต่ด้วยข้อจำกัดที่ว่า โครงการ สาธารณสมบัติจะได้รับอนุญาตเป็นกรณีเดียวเท่านั้น

จุดยืนของ OSI

Open Source Initiative (OSI) รักษารายการใบอนุญาตที่ได้รับอนุมัติ [26]ในช่วงต้นของประวัติศาสตร์ OSI มีส่วนสนับสนุนในการเพิ่มจำนวนใบอนุญาตโดยการอนุมัติใบอนุญาตที่ไร้สาระและไม่สามารถใช้ซ้ำได้ ในปี พ.ศ. 2547 ได้มีการเริ่มโครงการ OSI License Proliferation [27]ได้จัดทำรายงาน License Proliferation Report ในปี พ.ศ. 2550 [28]รายงานได้กำหนดประเภทของใบอนุญาต:

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

กลุ่มใบอนุญาต "ยอดนิยม" ประกอบด้วยใบอนุญาตเก้ารายการ: Apache License 2.0 , ใบอนุญาต BSD ใหม่ , GPLv2 , LGPLv2 , ใบอนุญาต MIT , Mozilla Public License 1.1 , Common Development and Distribution License , Common Public License , Eclipse Public License

จุดยืนของ FSF

Richard Stallmanอดีตประธานมูลนิธิซอฟต์แวร์เสรีและBradley M. Kuhnอดีตกรรมการบริหาร ได้โต้เถียงกับการเพิ่มจำนวนใบอนุญาตตั้งแต่ปี 2000 เมื่อพวกเขาก่อตั้งรายการใบอนุญาต FSF ซึ่งกระตุ้นให้นักพัฒนาอนุญาตซอฟต์แวร์ของตนภายใต้ ลิขสิทธิ์ ซอฟต์แวร์ฟรีที่เข้ากันได้กับ GPL (s) แม้ว่าใบอนุญาตซอฟต์แวร์ฟรีที่เข้ากันไม่ได้ของ GPL หลายรายการจะแสดงรายการพร้อมความคิดเห็นที่ระบุว่าไม่มีปัญหาในการใช้และ/หรือทำงานกับซอฟต์แวร์ที่อยู่ภายใต้ใบอนุญาตที่เป็นปัญหาในขณะเดียวกันก็กระตุ้นให้ผู้อ่านรายการไม่ใช้สิ่งเหล่านั้น ใบอนุญาตในซอฟต์แวร์ที่พวกเขาเขียน [29]

Ciarán O'Riordanแห่งFSF Europeให้เหตุผลว่าสิ่งสำคัญที่ FSF สามารถทำได้เพื่อป้องกันการเพิ่มจำนวนใบอนุญาตคือการลดเหตุผลในการออกใบอนุญาตใหม่ตั้งแต่แรก ในบทบรรณาธิการเรื่องHow GPLv3 จัดการกับการเพิ่มจำนวนใบอนุญาต [30]โดยทั่วไปFSF Europeแนะนำให้ใช้ GNU GPL อย่างสม่ำเสมอให้มากที่สุด และหากเป็นไปไม่ได้ ให้ใช้ใบอนุญาตที่เข้ากันได้กับ GPL

อื่นๆ

ในปี 2548 Intel ได้ถอนใบอนุญาต Intel Open Source โดยสมัครใจ จาก รายการ OSIของใบอนุญาตโอเพนซอร์ส และได้หยุดใช้หรือแนะนำใบอนุญาตนี้เพื่อลดการแพร่กระจายของใบอนุญาต [31]

กลุ่ม 451 ได้สร้างรายงานการเพิ่มจำนวนขึ้นในเดือนมิถุนายน พ.ศ. 2552 ชื่อ The Myth of Open Source License Proliferation [32]กระดาษปี 2009 จากคณะนิติศาสตร์มหาวิทยาลัยวอชิงตันเรื่องOpen Source License Proliferation: Helpful Diversity or Hopeless Confusion? เรียกร้องให้มีวิธีแก้ปัญหาสามประการ: "A Wizzier Wizzard" (สำหรับการเลือกใบอนุญาต), "แนวทางปฏิบัติที่ดีที่สุดและใบอนุญาตเดิม" , "บริการทางกฎหมายเพิ่มเติมสำหรับแฮกเกอร์ " [33]OpenSource Software Collaboration Counseling (OSSCC) แนะนำโดยยึดตามใบอนุญาต OSI ที่แนะนำ 9 ฉบับ ใบอนุญาต 5 ฉบับ ได้แก่ Apache License 2.0 ใบอนุญาต BSD ใหม่ CDDL ใบอนุญาต MIT และ MPL ในระดับหนึ่ง เนื่องจากสนับสนุนการทำงานร่วมกัน ให้สิทธิบัตร ใช้และเสนอการคุ้มครองสิทธิบัตร GPL ที่ขาดหายไปอย่างเห็นได้ชัดคือ "ไม่สามารถใช้ใบอนุญาตนี้ในงานอื่นภายใต้ใบอนุญาตอื่นได้" [34]

ดูเพิ่มเติม

อ้างอิง

  1. ↑ a b OSI and License Proliferation บน fossbazar.com โดย Martin Michlmayr "ใบอนุญาตที่แตกต่างกันมากเกินไปทำให้ยากสำหรับผู้อนุญาตในการเลือก: เป็นการยากที่จะเลือกใบอนุญาตที่ดีสำหรับโครงการเนื่องจากมีจำนวนมาก ใบอนุญาตบางรายการเล่นร่วมกันได้ไม่ดี : โอเพ่นซอร์สไลเซนส์บางตัวไม่สามารถทำงานร่วมกับโอเพ่นซอร์สอื่น ๆ ได้ดี ทำให้ยากต่อการรวมโค้ดจากโปรเจกต์อื่น ๆ ไลเซนส์มากเกินไปทำให้ยากที่จะเข้าใจสิ่งที่คุณตกลงในการแจกจ่ายหลายใบอนุญาต: เนื่องจาก FOSS โดยทั่วไปแล้ว แอปพลิเคชันจะมีรหัสที่มีใบอนุญาตต่างกัน และผู้คนใช้แอปพลิเคชันจำนวนมาก ซึ่งแต่ละใบอนุญาตมีใบอนุญาตหนึ่งใบหรือหลายใบ เป็นการยากที่จะดูว่าภาระผูกพันของคุณคืออะไร" (วันที่ 21 สิงหาคม 2551)
  2. ^ สไลด์ใบอนุญาต Free-Libre / Open Source Software (FLOSS)โดย David A. Wheeler เมื่อวันที่ 27 กันยายน 2550
  3. ^ "ทำให้ซอฟต์แวร์โอเพ่นซอร์สของคุณเข้ากันได้กับ GPL หรืออย่างอื่น " www.dwheeler.com .
  4. ^ รายการใบอนุญาต เก็บถาวร 2000-08-15 ที่ Wayback Machineของ gnu.org
  5. โลร็องต์, ฟิลิปป์ (24 กันยายน 2551) "ปัญหา GPLv3 และความเข้ากันได้" (PDF ) งาน European Open Source Lawyers Event 2008 มหาวิทยาลัยนามูร์ – เบลเยียม หน้า 7. เก็บถาวรจากต้นฉบับ(PDF)เมื่อวันที่ 4 มีนาคม 2559 . สืบค้นเมื่อ30 พฤษภาคม 2558 . Copyleft เป็นสาเหตุหลักของปัญหาความเข้ากันได้
  6. Hanwell, Marcus D. (28 มกราคม 2014). "ฉันควรใช้ใบอนุญาตหรือไม่ Copyleft หรืออะไรที่อยู่ตรงกลาง?" . โอเพ่นซอร์ส. คอม สืบค้นเมื่อ30 พฤษภาคม 2558 . ใบอนุญาตแบบอนุญาตทำให้สิ่งต่าง ๆ ง่ายขึ้น เหตุผลหนึ่งที่โลกธุรกิจ และนักพัฒนาจำนวนมากขึ้นเรื่อยๆ [...] ชื่นชอบใบอนุญาตแบบอนุญาตคือความเรียบง่ายของการนำกลับมาใช้ใหม่ ใบอนุญาตมักจะเกี่ยวข้องกับซอร์สโค้ดที่ได้รับอนุญาตเท่านั้น และไม่พยายามอนุมานเงื่อนไขใดๆ กับองค์ประกอบอื่นใด และด้วยเหตุนี้จึงไม่จำเป็นต้องกำหนดสิ่งที่ถือเป็นงานที่ได้รับ ฉันยังไม่เคยเห็นแผนภูมิความเข้ากันได้ของใบอนุญาตสำหรับใบอนุญาตที่อนุญาต ดูเหมือนว่าพวกเขาจะเข้ากันได้ทั้งหมด
  7. ^ "ความเข้ากันได้ของใบอนุญาตและการทำงานร่วมกัน" . ซอฟต์แวร์โอเพ่นซอร์ส - พัฒนา แบ่งปัน และนำซอฟต์แวร์โอเพ่นซอร์สมาใช้ซ้ำสำหรับการบริหารภาครัฐ joinup.ec.europa.eu เก็บถาวรจากต้นฉบับเมื่อ 17 มิถุนายน 2558 . สืบค้นเมื่อ30 พฤษภาคม 2558 . ใบอนุญาตสำหรับแจกจ่ายซอฟต์แวร์ฟรีหรือโอเพ่นซอร์ส (FOSS) แบ่งออกเป็นสองประเภท: อนุญาตและลิขสิทธิ์ ใบอนุญาตอนุญาต (BSD, MIT, X11, Apache, Zope) โดยทั่วไปจะเข้ากันได้และทำงานร่วมกันได้กับใบอนุญาตอื่นๆ ส่วนใหญ่ ซึ่งทนต่อการผสาน รวม หรือปรับปรุงรหัสที่ครอบคลุม และแจกจ่ายซ้ำภายใต้ใบอนุญาตจำนวนมาก ”).
  8. ^ มูลนิธิ Apache (30 พฤษภาคม 2558) "ความเข้ากันได้ ของGPL" สืบค้นเมื่อ30 พฤษภาคม 2558 . ซอฟต์แวร์ Apache 2 จึงสามารถรวมไว้ในโปรเจ็กต์ GPLv3 ได้ เนื่องจากใบอนุญาต GPLv3 ยอมรับซอฟต์แวร์ของเราในการทำงานของ GPLv3 อย่างไรก็ตาม ไม่สามารถรวมซอฟต์แวร์ GPLv3 ในโครงการ Apache ได้ ใบอนุญาตไม่เข้ากันในทิศทางเดียวเท่านั้น และเป็นผลมาจากปรัชญาการออกใบอนุญาตของ ASF และการตีความกฎหมายลิขสิทธิ์ของผู้เขียน GPLv3
  9. ^ "คำถามที่พบบ่อยเกี่ยวกับใบอนุญาต GNU – GPLv3 เข้ากันได้กับ GPLv2 หรือไม่" . gnu.org . สืบค้นเมื่อ3 มิถุนายน 2014 . ไม่ ข้อกำหนดบางอย่างใน GPLv3 เช่น ข้อกำหนดในการให้ข้อมูลการติดตั้ง ไม่มีอยู่ใน GPLv2 ด้วยเหตุนี้ ใบอนุญาตจึงไม่เข้ากัน: หากคุณพยายามรวมรหัสที่เผยแพร่ภายใต้ใบอนุญาตทั้งสองนี้ คุณจะละเมิดส่วนที่ 6 ของ GPLv2 อย่างไรก็ตาม หากมีการเผยแพร่โค้ดภายใต้ GPL "เวอร์ชัน 2 หรือใหม่กว่า" โค้ดดังกล่าวจะเข้ากันได้กับ GPLv3 เนื่องจาก GPLv3 เป็นหนึ่งในตัวเลือกที่อนุญาต
  10. แลนดลีย์, ร็อบ. "CELF 2013 ทอยบ็อกซ์ ทอล์ค" . landley.net . สืบค้นเมื่อ21 สิงหาคม 2013 . GPLv3 ทำลาย "" GPL" ให้เป็นส้อมที่เข้ากันไม่ได้ซึ่งไม่สามารถแชร์รหัสได้
  11. ^ Asay, Clark D. "Michigan Telecommunications and Technology Law Review Volume 14 - Issue 22008 The General Public License Version 3.0: Making or Breaking the Foss Movement" . law.umich.edu. ในท้ายที่สุด GPLv3 ถือเป็นการเพิ่มจำนวนใบอนุญาต
  12. นิโคไล เบซรูคอฟ (2000). "ข้อดีเปรียบเทียบของใบอนุญาต GPL, BSD และ Artistic (คำติชมของ Viral Nature ของ GPL v.2 - หรือ In Defense of Dual Licensing Idea) " เก็บถาวรจากต้นฉบับเมื่อวันที่ 22 ธันวาคม พ.ศ. 2544 ทรัพย์สินไวรัสช่วยกระตุ้นการเพิ่มจำนวนใบอนุญาตและก่อให้เกิด "ฝันร้ายที่บังคับใช้โดย GPL" ซึ่งเป็นสถานการณ์ที่ใบอนุญาตอื่นๆ จำนวนมากไม่สอดคล้องกับ GPL อย่างมีเหตุผล และทำให้ชีวิตโดยไม่จำเป็นสำหรับนักพัฒนาที่ทำงานใน สภาพแวดล้อม Linux (KDE เป็นตัวอย่างที่ดีในที่นี้ Python เป็นตัวอย่างที่ไม่ค่อยมีใครรู้จัก) ฉันคิดว่าความพยายามเล็กน้อยในการตีความ GPL ว่าเป็น "ข้อความศักดิ์สิทธิ์" เป็นการสนทนาที่ไม่ก่อให้เกิดผลซึ่งไม่ได้นำเราไปทุกที่ และพวกเขามีส่วนโดยตรงในการขยายพันธุ์ที่แตกต่างกัน "
  13. ^ Byfield, Bruce (22 พฤศจิกายน 2554) "7 เหตุผลที่ซอฟต์แวร์ฟรีสูญเสียอิทธิพล: หน้า 2 " ดาต้าเมท. com สืบค้นเมื่อ23 สิงหาคม 2013 . ในขณะนั้น การตัดสินใจดูสมเหตุสมผลเมื่อเผชิญกับการหยุดชะงัก แต่ตอนนี้ GPLv2 ใช้สำหรับซอฟต์แวร์ฟรี 42.5% และ GPLv3 น้อยกว่า 6.5% ตามข้อมูลของ Black Duck Software
  14. James EJ Bottomley, Mauro Carvalho Chehab, Thomas Gleixner, Christoph Hellwig, Dave Jones, Greg Kroah-Hartman, Tony Luck, Andrew Morton, Trond Myklebust, David Woodhouse (15 กันยายน 2549) "ตำแหน่งของนักพัฒนาเคอร์เนลใน GPLv3 - อันตรายและปัญหากับ GPLv3 " LWN.net . สืบค้นเมื่อ11 มีนาคม 2558 . [...] เนื่องจาก FSF เสนอให้เปลี่ยนโครงการทั้งหมดเป็น GPLv3 และใช้แรงกดดันกับทุกโครงการที่ได้รับอนุญาตของ GPL เพื่อย้าย เราคาดว่าการเปิดตัว GPLv3 จะเป็นการ สื่อถึงความเป็น บอลข่านของจักรวาลโอเพ่นซอร์สทั้งหมดที่เราพึ่งพา{{cite web}}: CS1 maint: ใช้พารามิเตอร์ผู้เขียน ( ลิงค์ )
  15. ↑ Ronacher , Armin (23 กรกฎาคม 2013). "การออกใบอนุญาตในโลกโพสต์ลิขสิทธิ์" . lucumr.pocoo.org . สืบค้นเมื่อ18 พฤศจิกายน 2558 .License Compatibility Clusterfuck - เมื่อ GPL มีส่วนเกี่ยวข้อง ความซับซ้อนของการอนุญาตจะกลายเป็นปริศนาที่ไม่สนุก มีหลายสิ่งที่ต้องพิจารณาและการโต้ตอบมากมายที่ต้องพิจารณา และความเข้ากันไม่ได้ของ GPL นั้นยังคงเป็นปัญหาที่ส่งผลกระทบอย่างแข็งขันต่อผู้คนเป็นสิ่งที่หลายคนลืมไป ตัวอย่างเช่น อาจมีบางคนคิดว่าความไม่ลงรอยกันของ GPLv2 กับ Apache Software License 2.0 ควรจะเป็นเรื่องในอดีตที่ทุกอย่างอัปเกรดเป็น GPLv3 แต่ปรากฎว่ามีคนจำนวนมากพอที่ติดอยู่กับ GPLv2 เท่านั้นหรือไม่เห็นด้วยกับ GPLv3 ที่โครงการลิขสิทธิ์ Apache บางโครงการจำเป็นต้องย้าย ตัวอย่างเช่น Bootstrap ของ Twitter กำลังย้ายจาก ASL2.0 ไปยัง MIT อย่างแม่นยำเพราะบางคนยังต้องการความเข้ากันได้ของ GPLv2 ในบรรดาโครงการที่ได้รับผลกระทบ ได้แก่ Drupal, WordPress, Joomla, MoinMoin Wiki และอื่นๆ และถึงแม้กรณีดังกล่าวจะแสดงให้เห็นว่าผู้คนไม่ได้สนใจเรื่องใบอนุญาตมากนักอีกต่อไป เนื่องจาก Joomla 3 ได้รวม bootstrap ไว้ด้วยกัน แม้ว่าจะไม่ใช่ใบอนุญาตในลักษณะที่เข้ากันได้ (GPLv2 กับ ASL 2.0) กรณีดั้งเดิมอื่น ๆ ของสิ่งต่าง ๆ ที่ไม่เข้ากันกับ GPL คือโครงการ OpenSSL ซึ่งมีใบอนุญาตใช้งานไม่ได้กับ GPL ใบอนุญาตนั้นยังคงเข้ากันไม่ได้กับ GPLv3 การทดสอบทั้งหมดมีความน่าสนใจเป็นพิเศษ เนื่องจากบางกลุ่มที่ไม่ค่อยดีนักได้เริ่มทำการหลอกล่อด้วยใบอนุญาต GPL กรณีดั้งเดิมอื่น ๆ ของสิ่งต่าง ๆ ที่ไม่เข้ากันกับ GPL คือโครงการ OpenSSL ซึ่งมีใบอนุญาตใช้งานไม่ได้กับ GPL ใบอนุญาตนั้นยังคงเข้ากันไม่ได้กับ GPLv3 การทดสอบทั้งหมดมีความน่าสนใจเป็นพิเศษ เนื่องจากบางกลุ่มที่ไม่ค่อยดีนักได้เริ่มทำการหลอกล่อด้วยใบอนุญาต GPL กรณีดั้งเดิมอื่น ๆ ของสิ่งต่าง ๆ ที่ไม่เข้ากันกับ GPL คือโครงการ OpenSSL ซึ่งมีใบอนุญาตใช้งานไม่ได้กับ GPL ใบอนุญาตนั้นยังคงเข้ากันไม่ได้กับ GPLv3 การทดสอบทั้งหมดมีความน่าสนใจเป็นพิเศษ เนื่องจากบางกลุ่มที่ไม่ค่อยดีนักได้เริ่มทำการหลอกล่อด้วยใบอนุญาต GPL
  16. ^ คุณแน่ใจหรือว่าต้องการใช้ GPL? โดย อาร์มิน โรนาเชอร์ (2009)
  17. ^ การแบ่งปันซอฟต์แวร์ทางการแพทย์: สิทธิ์ใช้งาน FOSS ในยาบน freesoftwaremagazine.com โดย Fred Trotter (2007-06-14)
  18. ^ "บล็อกของ David A. Wheeler" . dwheeler.com .
  19. ^ ในที่สุด GitHub ก็ใช้ใบอนุญาตโอเพ่นซอร์สอย่างจริงจังใน Infoworld โดย Simon Phipps ในเดือนกรกฎาคม 2013
  20. ^ การเลือกใบอนุญาตโอเพ่นซอร์สไม่จำเป็นต้องน่ากลัว - ข้อใดต่อไปนี้อธิบายสถานการณ์ของคุณได้ดีที่สุด บน choosealicense.com (เข้าถึง 2015-11-29)
  21. ^ การใช้ใบอนุญาตโอเพ่นซอร์สบน GitHub.comเมื่อวันที่ 9 มีนาคม 2558 โดย Ben Balter บน github.com "MIT 44.69%, [...]GPLv2 12.96%, Apache 11.19%, GPLv3 8.88%"
  22. เอ็ด เบอร์เน็ตต์ (2 พฤศจิกายน 2549) "Google ปฏิเสธไม่ให้มีการขยายใบอนุญาต " เก็บถาวรจากต้นฉบับเมื่อ 24 กุมภาพันธ์ 2550 . สืบค้นเมื่อ11 กันยายน 2010 .
  23. เกร็ก สไตน์ (28 พฤษภาคม 2552). "ยืนหยัดต่อต้านการแพร่ขยายใบอนุญาต" . เก็บถาวรจากต้นฉบับเมื่อ 1 มิถุนายน 2551 . สืบค้นเมื่อ11 กันยายน 2010 .
  24. ^ การเพิ่มจำนวนใบอนุญาต - Less is More, One is Bestเมื่อวันที่ 27 มกราคม 2009 โดย Ernest M. Park "Chris DiBona จาก Google ได้รับความเดือดร้อนจากสลิงและลูกศรของชุมชน OSS เมื่อเขาปฏิเสธใบอนุญาต AGPLv3 สำหรับพื้นที่เก็บข้อมูล Google Code โดยอ้างว่ามีการเพิ่มจำนวนใบอนุญาตเป็น สาเหตุหนึ่ง”
  25. ^ คริส ดิโบนา (10 กันยายน 2010) "License Evolution and Hosting Projects on Code.Google.Com" . สืบค้นเมื่อ11 กันยายน 2010 .
  26. ^ OSI Approved Licensesบน opensource.org
  27. ^ โครงการขยายใบอนุญาตบน opensource.com (2004)
  28. ^ รายงานการขยายสิทธิ์ใช้ งานที่ เก็บถาวร 2012-12-12 ที่ Wayback Machineบน opensource.com (2007)
  29. ^ รายการใบอนุญาตเวอร์ชันเก่าที่สุดที่เก็บถาวรแสดงถึงตำแหน่งนี้ แบรดลีย์ เอ็ม. คุน (15 สิงหาคม 2543) "ใบอนุญาตต่างๆ และความคิดเห็นเกี่ยวกับพวกเขา" . มูลนิธิซอฟต์แวร์ฟรี น. 37–39. เก็บถาวรจากต้นฉบับเมื่อ 15 สิงหาคม 2000 . สืบค้นเมื่อ29 พฤศจิกายน 2558 .
  30. ^ วิธีที่ GPLv3 จัดการกับการเพิ่มจำนวนใบอนุญาตบน linuxdevices.com
  31. ^ Marson, Ingrid (31 มีนาคม 2548) "Intel หยุดใช้ใบอนุญาตโอเพ่นซอร์ส" . cnet.com . ซี เน็ต. สืบค้นเมื่อ6 ตุลาคม 2014 .
  32. ^ The Myth of Open Source License Proliferationบน the451group.com
  33. ^ การเพิ่มใบอนุญาตโอเพ่นซอร์ส: ความหลากหลายที่เป็นประโยชน์หรือความสับสนที่สิ้นหวัง? on law.washington.edu โดย Robert W. Gomulkiewicz เมื่อ 2009
  34. ^ ความเข้ากันได้ของ ใบอนุญาตบน osscc.net

ลิงค์ภายนอก