ใบอนุญาตซอฟต์แวร์อนุญาต

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

สาธารณสมบัติ และรายการเทียบเท่า ใบอนุญาติ Copyleft (ใบอนุญาตคุ้มครอง) ใบอนุญาตที่ไม่ใช่เชิงพาณิชย์ ใบอนุญาตที่เป็นกรรมสิทธิ์ ความลับทางการค้า
คำอธิบาย ให้สิทธิ์ทั้งหมด ให้สิทธิ์การใช้งาน รวมถึงสิทธิ์ในการอนุญาตใหม่ (อนุญาตให้มีกรรมสิทธิ์ความเข้ากันได้ของใบอนุญาต ) ให้สิทธิ์การใช้งานห้ามการเป็นเจ้าของ ให้สิทธิ์สำหรับการใช้งานที่ไม่ใช่เชิงพาณิชย์เท่านั้น สามารถใช้ร่วมกับ copyleft การใช้ลิขสิทธิ์ แบบดั้งเดิม ; ไม่ต้องให้สิทธิ์ ไม่มีข้อมูลเปิดเผยต่อสาธารณะ
ซอฟต์แวร์ PD, CC0 BSD , MIT , Apache GPL , AGPL JRL , AFPL ซอฟต์แวร์ที่เป็นกรรมสิทธิ์ไม่มีใบอนุญาตสาธารณะ ซอฟต์แวร์ส่วนตัวภายใน
ผลงานสร้างสรรค์อื่นๆ PD, CC0 CC-BY CC-BY-SA CC-BY-NC ลิขสิทธิ์ไม่มีใบอนุญาตสาธารณะ ไม่ได้เผยแพร่

ใบอนุญาตซอฟต์แวร์ที่อนุญาตซึ่งบางครั้งเรียกว่า ใบอนุญาตแบบ BSDหรือใบอนุญาตแบบ BSD [1]คือใบอนุญาตซอฟต์แวร์ฟรี ซึ่งแทนที่จะใช้ การป้องกัน ลิขสิทธิ์มีข้อ จำกัด เพียงเล็กน้อยเกี่ยวกับวิธีการใช้ แก้ไข และแจกจ่ายซอฟต์แวร์ตามปกติ รวมถึง ข้อจำกัดความรับผิดชอบ การรับประกัน ตัวอย่าง ได้แก่GNU All-permissive License , MIT License , BSD licenses , Apple Public Source LicenseและApache License ในปี 2559 ใบอนุญาตซอฟต์แวร์ฟรีที่ได้รับความนิยมมากที่สุดคือใบอนุญาต MIT ที่อนุญาต[2] [3]

ตัวอย่าง

ต่อไปนี้เป็นข้อความทั้งหมดของGNU All-permissive License แบบ ง่าย :

ลิขสิทธิ์ <YEAR>, <AUTHORS>

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

คำจำกัดความ

Open Source Initiative กำหนด ใบอนุญาตซอฟต์แวร์ที่อนุญาตเป็น "ใบอนุญาตที่ไม่ลิขสิทธิ์ที่รับประกันเสรีภาพในการใช้ แก้ไข และแจกจ่ายซ้ำ" [6] เว็บไซต์ choosealicenseของGitHubอธิบายใบอนุญาต MIT ที่อนุญาตว่า "[ให้] ผู้คนทำทุกอย่างที่พวกเขาต้องการด้วยรหัสของคุณ ตราบใดที่พวกเขาให้ ที่ มากับคุณ และไม่ถือว่าคุณต้องรับผิด " [7]คณะนิติศาสตร์แคลิฟอร์เนียตะวันตก newmediarights.com ของ Newmediarights.com กำหนดไว้ดังนี้: "ใบอนุญาต 'BSD-like' เช่นใบอนุญาต BSD, MIT และ Apache นั้นอนุญาตอย่างมาก ซึ่งต้องการมากกว่าการระบุแหล่งที่มาของส่วนดั้งเดิมของรหัสลิขสิทธิ์ให้กับนักพัฒนาดั้งเดิมในของคุณเอง รหัสและ/หรือเอกสารประกอบ" [1]

เปรียบเทียบกับ copyleft

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

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

ใบอนุญาตอนุญาตมีความ เข้ากันได้ ของใบอนุญาต ที่กว้างขวางกว่าใบอนุญาตลิขสิทธิ์ ซึ่งโดยทั่วไปแล้วไม่สามารถรวมและผสมกันได้อย่างอิสระ เนื่องจากข้อกำหนดส่วนต่างขัดแย้งกัน [12] [13] [14] [15] [16]

เปรียบเทียบกับสาธารณสมบัติ

Computer Associates Int'l v. Altaiใช้คำว่า "สาธารณสมบัติ" เพื่ออ้างถึงงานที่มีการแบ่งปันและเผยแพร่อย่างกว้างขวางภายใต้การอนุญาต มากกว่างานที่ตั้งใจให้เป็นสาธารณสมบัติ อย่างไรก็ตาม ใบอนุญาตที่อนุญาตนั้นไม่เทียบเท่ากับการปล่อยงานสู่ สาธารณสมบัติ

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

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

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

ความเข้ากันได้ของใบอนุญาตระหว่างซอฟต์แวร์โอเพ่นซอร์สทั่วไปและซอฟต์แวร์โอเพ่นซอร์ส (FOSS) ใบอนุญาตตาม David A. Wheeler (2007): ลูกศรเวกเตอร์แสดงถึงความเข้ากันได้แบบทิศทางเดียว ดังนั้นจึงเข้ากันได้ดีกว่าทางด้านซ้าย ("ใบอนุญาตอนุญาต") มากกว่าทางด้านขวา ด้าน ("ลิขสิทธิ์ลิขสิทธิ์") (20)

โดยทั่วไปใบอนุญาตอนุญาตมีความเข้ากันได้ ดี กับใบอนุญาตซอฟต์แวร์อื่น ๆ ส่วนใหญ่ในสถานการณ์ส่วนใหญ่ [12] [13]

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

ใบอนุญาตบางรายการไม่อนุญาตให้งานที่ได้รับมาเพิ่มข้อจำกัดที่ระบุว่าผู้จำหน่ายต่อไม่สามารถเพิ่มข้อจำกัดเพิ่มเติมได้ ตัวอย่างได้แก่CDDLและMsPL อย่างไรก็ตาม ข้อจำกัดดังกล่าวยังทำให้สิทธิ์ใช้งานไม่เข้ากันกับสิทธิ์ใช้งานซอฟต์แวร์ฟรีที่อนุญาต [ ต้องการการอ้างอิง ]

การรับและการรับเลี้ยงบุตรบุญธรรม

ในขณะที่มีการใช้งานตั้งแต่กลางทศวรรษ 1980 [21]ผู้เขียนหลายคนสังเกตเห็นการเพิ่มขึ้นของความนิยมของใบอนุญาตที่ได้รับอนุญาตในช่วงปี 2010 [22] [23] [24] [25]

ในปี 2015 ใบอนุญาต MITซึ่งเป็นใบอนุญาตอนุญาต เป็นใบอนุญาตซอฟต์แวร์ฟรีที่ได้รับความนิยมมากที่สุด รองลงมาคือGPLv2 [2] [3]

เงื่อนไขอื่นๆ

Berkeley มีสิ่งที่เราเรียกว่า "copycenter" ซึ่งก็คือ "นำมันไปที่ศูนย์คัดลอกและทำสำเนาได้มากเท่าที่คุณต้องการ"

ศูนย์คัดลอก

Copycenterเป็นคำที่ใช้อธิบายใบอนุญาต BSD ที่แก้ไขแล้ว ซึ่งเป็นสิทธิ์ใช้งานซอฟต์แวร์ฟรีที่อนุญาต คำนี้นำเสนอโดยนักวิทยาศาสตร์คอมพิวเตอร์และ ผู้มีส่วนร่วม ของBerkeley Software Distribution (BSD) Marshall Kirk McKusickในการประชุม BSD ในปี 2542 เป็นการเล่นคำเกี่ยวกับลิขสิทธิ์copyleft และ copy center [26] [27]

ใบอนุญาต Pushover

ในคู่มือของFree Software Foundationในเรื่องความเข้ากันได้และการออกใบอนุญาตใหม่Richard Stallmanให้คำจำกัดความของ Permissive License ว่า "pushover licenses" โดยเปรียบเทียบกับคนที่ "ไม่สามารถปฏิเสธได้" เพราะถูกมองว่าเป็นการให้สิทธิ์ในการ "ปฏิเสธ" อิสระแก่ผู้อื่น” [28]มูลนิธิแนะนำใบอนุญาตแบบผลักดันเฉพาะสำหรับโปรแกรมขนาดเล็ก โค้ดที่ต่ำกว่า 300 บรรทัด โดยที่ "ประโยชน์ที่ได้รับจาก copyleft มักจะน้อยเกินไปที่จะแสดงให้เห็นถึงความไม่สะดวกในการทำให้แน่ใจว่าสำเนาของใบอนุญาตจะมาพร้อมกับซอฟต์แวร์เสมอ" [29]

ดูเพิ่มเติมที่

อ้างอิง

  1. ^ a b c สิทธิสื่อใหม่ (2008-09-12) "คู่มือการออกใบอนุญาตโอเพ่นซอร์ส" . โรงเรียนกฎหมายแคลิฟอร์เนียตะวันตก
  2. ^ a b "ใบอนุญาต 20 อันดับแรก" . ซอฟต์แวร์เป็ดดำ 19 พฤศจิกายน 2558 เก็บถาวรจากต้นฉบับเมื่อ 19 กรกฎาคม 2559 . สืบค้นเมื่อ19 พฤศจิกายน 2558 . 1. ใบอนุญาต MIT 24% 2. GNU General Public License (GPL) 2.0 23% 3. Apache License 16% 4. GNU General Public License (GPL) 3.0 9% 5. BSD License 2.0 (3-clause, ใหม่หรือแก้ไข) ใบอนุญาต 6%, 6. GNU Lesser General Public License (LGPL) 2.1 5%, 7. Artistic License (Perl) 4%, 8. GNU Lesser General Public License (LGPL) 3.0 2%, 9. Microsoft Public ใบอนุญาต 2%, 10. ใบอนุญาตสาธารณะ Eclipse (EPL) 2%
  3. ↑ เป็ บัล เตอร์, เบ็น (2015-03-09). "การใช้ใบอนุญาตโอเพ่นซอร์สบน GitHub.com" . github.com . สืบค้นเมื่อ2015-11-21 . "1 MIT 44.69%, 2 อื่นๆ 15.68%, 3 GPLv2 12.96%, 4 Apache 11.19%, 5 GPLv3 8.88%, 6 BSD 3-clause 4.53%, 7 Unlicense 1.87%, 8 BSD 2-clause 1.70%, 9 LGPLv3 1.30 %, 10 AGPLv3 1.05%
  4. ^ Free Software Foundation, ใบอนุญาตต่างๆ และข้อคิดเห็นเกี่ยวกับพวกเขา, GNU All-permissive License
  5. ^ ข้อมูลสำหรับผู้ดูแลซอฟต์แวร์ GNU คำชี้แจงสิทธิ์การใช้งานสำหรับไฟล์อื่นๆ
  6. ^ อนุญาตบน opensource.org ใบอนุญาต "อนุญาต" เป็นเพียงใบอนุญาตโอเพ่นซอร์สที่ไม่สงวนลิขสิทธิ์ - ใบอนุญาตที่รับประกันเสรีภาพในการใช้ แก้ไข และแจกจ่ายซ้ำ แต่อนุญาตอนุพันธ์ที่เป็นกรรมสิทธิ์ "
  7. ^ การเลือกใบอนุญาตโอเพนซอร์ซไม่จำเป็นต้องน่ากลัวใน choosealicense.com "ข้อใดต่อไปนี้อธิบายสถานการณ์ของคุณได้ดีที่สุด – ฉันต้องการให้มันเรียบง่ายและอนุญาต"
  8. ^ "Copyleft คืออะไร" . จีเอ็นยู สืบค้นเมื่อ21 เมษายน 2011 .
  9. ^ "หมวดหมู่ซอฟต์แวร์ฟรีและไม่ฟรี" . gnu.org
  10. อมาเดโอ, รอน (21 กรกฎาคม 2018). "ด้ามจับเหล็กของ Google บน Android: ควบคุมโอเพ่นซอร์สได้ทุกวิถีทางที่จำเป็น " อาส เทคนิค .
  11. ^ ด้วยเหตุนี้ โปรเจ็กต์ FreeBSDจึงสนับสนุนใบอนุญาตแบบอนุญาตสำหรับบริษัทและกรณีการใช้งานเชิงพาณิชย์: พวกเขากล่าวว่าพวกเขาวางเพียง "ข้อจำกัดขั้นต่ำสำหรับพฤติกรรมในอนาคต"และโต้แย้งว่าใบอนุญาตลิขสิทธิ์เป็น "ระเบิดเวลาทางกฎหมาย " ดู Montague, Bruce (2013-11-13) "เหตุใดคุณจึงควรใช้ใบอนุญาตรูปแบบ BSD สำหรับโครงการโอเพ่นซอร์สของคุณ " ฟรีบีเอสดี สืบค้นเมื่อ2015-11-28 . 9. ข้อดีและข้อเสียของ GPL [.. ] 12. บทสรุป
    ตรงกันข้ามกับ GPL ซึ่งได้รับการออกแบบมาเพื่อป้องกันการนำรหัสโอเพนซอร์ซไปใช้เชิงพาณิชย์ในเชิงพาณิชย์ ใบอนุญาต BSD กำหนดข้อจำกัดเล็กน้อยเกี่ยวกับพฤติกรรมในอนาคต ซึ่งช่วยให้โค้ด BSD ยังคงเป็นโอเพ่นซอร์สหรือรวมเข้ากับโซลูชันเชิงพาณิชย์ได้ เมื่อความต้องการของโครงการหรือบริษัทเปลี่ยนไป กล่าวอีกนัยหนึ่ง ใบอนุญาต BSD ไม่กลายเป็นระเบิดเวลาทางกฎหมายในทุกจุดในกระบวนการพัฒนา

    นอกจากนี้ เนื่องจากใบอนุญาต BSD ไม่ได้มาพร้อมกับความซับซ้อนทางกฎหมายของใบอนุญาต GPL หรือ LGPL จึงช่วยให้นักพัฒนาและบริษัทต่างๆ ใช้เวลาในการสร้างและส่งเสริมโค้ดที่ดี แทนที่จะกังวลว่าโค้ดดังกล่าวจะละเมิดใบอนุญาตหรือไม่
  12. ^ a b "ความเข้ากันได้ ของใบอนุญาต" ใบอนุญาต สาธารณะของสหภาพยุโรป joinup.ec.europa.eu เก็บถาวรจากต้นฉบับเมื่อ 2015-06-17 . สืบค้นเมื่อ2015-05-30 . ใบอนุญาตสำหรับแจกจ่ายซอฟต์แวร์ฟรีหรือโอเพ่นซอร์ส (FOSS) แบ่งออกเป็นสองประเภท: อนุญาตและลิขสิทธิ์ ใบอนุญาตอนุญาต (BSD, MIT, X11, Apache, Zope) โดยทั่วไปจะเข้ากันได้และทำงานร่วมกันได้กับใบอนุญาตอื่นๆ ส่วนใหญ่ ทนทานต่อการผสาน รวม หรือปรับปรุงรหัสที่ครอบคลุม และแจกจ่ายซ้ำภายใต้ใบอนุญาตหลายฉบับ (รวมถึงที่ไม่มีสิทธิ์ใช้งานหรือ "กรรมสิทธิ์" ”).
  13. อรรถเป็น Hanwell มาร์คัส ดี. (2014-01-28). "ฉันควรใช้ใบอนุญาตหรือไม่ Copyleft หรืออะไรที่อยู่ตรงกลาง?" . โอเพ่นซอร์ส. คอม สืบค้นเมื่อ2015-05-30 . ใบอนุญาตแบบอนุญาตทำให้สิ่งต่าง ๆ ง่ายขึ้น เหตุผลหนึ่งที่โลกธุรกิจ และนักพัฒนาจำนวนมากขึ้นเรื่อยๆ [...] ชื่นชอบใบอนุญาตแบบอนุญาตคือความเรียบง่ายของการนำกลับมาใช้ใหม่ ใบอนุญาตมักจะเกี่ยวข้องกับซอร์สโค้ดที่ได้รับอนุญาตเท่านั้น และไม่พยายามอนุมานเงื่อนไขใดๆ กับองค์ประกอบอื่นใด และด้วยเหตุนี้จึงไม่จำเป็นต้องกำหนดสิ่งที่ถือเป็นงานที่ได้รับ ฉันยังไม่เคยเห็นแผนภูมิความเข้ากันได้ของใบอนุญาตสำหรับใบอนุญาตที่อนุญาต ดูเหมือนว่าพวกเขาจะเข้ากันได้ทั้งหมด
  14. ^ "คำถามที่พบบ่อยเกี่ยวกับใบอนุญาต GNU – GPLv3 เข้ากันได้กับ GPLv2 หรือไม่" . gnu.org . สืบค้นเมื่อ2014-06-03 . ไม่ ข้อกำหนดบางอย่างใน GPLv3 เช่น ข้อกำหนดในการให้ข้อมูลการติดตั้ง ไม่มีอยู่ใน GPLv2 ด้วยเหตุนี้ ใบอนุญาตจึงไม่เข้ากัน: หากคุณพยายามรวมรหัสที่เผยแพร่ภายใต้ใบอนุญาตทั้งสองนี้ คุณจะละเมิดส่วนที่ 6 ของ GPLv2 อย่างไรก็ตาม หากรหัสถูกเผยแพร่ภายใต้ GPL "เวอร์ชัน 2 หรือใหม่กว่า" โค้ดดังกล่าวจะเข้ากันได้กับ GPLv3 เนื่องจาก GPLv3 เป็นหนึ่งในตัวเลือกที่อนุญาต
  15. แลนดลีย์, ร็อบ. "CELF 2013 ทอยบ็อกซ์ ทอล์ค" . landley.net . ดึงข้อมูลเมื่อ2013-08-21 . GPLv3 ทำลาย "" GPL" ให้เป็นส้อมที่เข้ากันไม่ได้ซึ่งไม่สามารถแชร์รหัสได้
  16. ^ "การตีความ การบังคับใช้ และการเปลี่ยนแปลง GNU GPL ตามที่ใช้กับการรวม Linux และ ZFS " fsf.org _ สืบค้นเมื่อ2020-06-08 .
  17. ^ แบบฟอร์มสำนักงานลิขสิทธิ์ของสหรัฐอเมริกา CO ; ดูเพิ่มเติมที่ Ashton-Tate v. Fox
  18. ^ "นโยบายลิขสิทธิ์ OpenBSD" . โครงการOpenBSD สืบค้นเมื่อ2020-06-09 . ในเขตอำนาจศาลบางแห่ง อาจเป็นข้อสงสัยว่าการนำงานของตนเองไปเป็นสาธารณสมบัติโดยสมัครใจเป็นไปได้หรือไม่ ด้วยเหตุผลดังกล่าว ในการทำให้โค้ดจำนวนมากปลอดจากลิขสิทธิ์ ขอแนะนำให้ระบุลิขสิทธิ์และวางไว้ภายใต้ใบอนุญาต ISC หรือ BSD แทนที่จะพยายามเผยแพร่เป็นสาธารณสมบัติ
  19. ^ ฮิป, ดี. ริชาร์ด. "เหตุใด SQLite จึงประสบความสำเร็จในฐานะฐานข้อมูล" . บันทึกการเปลี่ยนแปลง ในขณะนั้น ฉันไม่ได้ตระหนักเลย ว่าใช้ชีวิตทั้งชีวิตในสหรัฐอเมริกา ซึ่งก็คือ ภายใต้กฎหมายของอังกฤษ ซึ่งสาธารณสมบัติเป็นสิ่งที่ได้รับการยอมรับ ฉันไม่ได้ตระหนักว่ามีเขตอำนาจศาลมากมายในโลกที่ยากหรือเป็นไปไม่ได้ที่ใครจะให้งานของตนเป็นสาธารณสมบัติ ฉันไม่รู้ นั่นเป็นภาวะแทรกซ้อน
  20. ^ สไลด์ใบอนุญาต Free-Libre / Open Source Software (FLOSS)โดย David A. Wheeler เมื่อวันที่ 4 ตุลาคม 2564
  21. ^ ฮาฟฟ์, กอร์ดอน. "ประวัติศาสตร์อันลึกลับของใบอนุญาต MIT" . โอเพ่นซอร์ส. คอม สืบค้นเมื่อ2020-06-08 . [มี] ข้อโต้แย้งที่ดีที่จะทำให้ใบอนุญาต MIT หรือที่เรียกว่า X Consortium หรือ X11 License ในขณะนั้นตกผลึกด้วย X11 ในปี 1987 และนั่นเป็นวันที่ดีที่สุดที่จะใช้ คุณสามารถโต้แย้งได้ว่ามันถูกสร้างขึ้นในปี 1985 โดยมีการปรับเปลี่ยนที่เป็นไปได้ในอีกสองสามปีข้างหน้า
  22. Vaughan-Nichols, Steven J. "การล่มสลายของ GPL และการเพิ่มขึ้นของใบอนุญาตโอเพนซอร์สที่อนุญาต " zdnet.com ครับ สืบค้นเมื่อ2015-11-28 . GPL ยังคงเป็นใบอนุญาตโอเพ่นซอร์สที่ได้รับความนิยมมากที่สุดในโลก แต่มีการใช้งานลดลง ในขณะที่ใบอนุญาตแบบอนุญาตมีแฟน ๆ เพิ่มขึ้น และนักพัฒนาบางคนเลือกที่จะเผยแพร่โค้ดโดยไม่มีใบอนุญาตใดๆ เลย
  23. ↑ โรนาเชอร์, อาร์มิน ( 2013-07-23 ). "การออกใบอนุญาตในโลกโพสต์ลิขสิทธิ์" . lucumr.pocoo.org . สืบค้นเมื่อ2015-11-18 .
  24. ^ แอสเล็ตต์, แมทธิว (2011-06-06). "แนวโน้มสู่การออกใบอนุญาต" . the451group.com. เก็บถาวรจากต้นฉบับเมื่อ 2015-10-13 . สืบค้นเมื่อ2015-11-28 .
  25. ^ รหัสของคุณจำเป็นต้องมีใบอนุญาตหรือไม่? โพสต์เมื่อ 02 พฤษภาคม 2013 โดย Jason Hibbets "ถาม: มีบริษัทพัฒนาซอฟต์แวร์ที่ชอบใช้ใบอนุญาตโอเพนซอร์ซมากกว่าบริษัทอื่นหรือไม่ แนวโน้มในชุมชนเป็นอย่างไร ตอบ: เราเห็นแนวโน้มบางอย่างที่ห่างไกลจากลิขสิทธิ์ลิขสิทธิ์-โดยส่วนใหญ่ไปทาง ใบอนุญาติ"
  26. ^ a b "เพิ่มความคิดเห็นของ Kirk เกี่ยวกับ "copycenter"; ดีเกินกว่าจะพลาดได้ " ฐานข้อมูลโชค ลาภ FreeBSD ย้อน หลัง (6) สืบค้นเมื่อ2020-06-08 .
  27. ^ เรย์มอนด์ เอริค เอส. " ศูนย์คัดลอก" ไฟล์ศัพท์แสง
  28. สตอลแมน, ริชาร์ด (2016-02-08). "ความเข้ากันได้ของใบอนุญาตและการต่ออายุใบอนุญาต" . มูลนิธิซอฟต์แวร์ฟรี สืบค้นเมื่อ2019-09-29 . โดยทั่วไป ใบอนุญาตที่หละหลวม ( modified BSD , X11 , Expat , Apache , Pythonฯลฯ) จะทำงานร่วมกันได้ นั่นเป็นเพราะพวกเขาไม่มีข้อกำหนดเกี่ยวกับโค้ดอื่นๆ ที่เพิ่มลงในโปรแกรม พวกเขายังอนุญาตให้นำโปรแกรมทั้งหมด (อาจมีการเปลี่ยนแปลง) ลงในผลิตภัณฑ์ซอฟต์แวร์ที่เป็นกรรมสิทธิ์ ดังนั้นเราจึงเรียกมันว่า "สิทธิ์ใช้งานแบบผลักดัน" เพราะพวกเขาไม่สามารถพูดว่า "ไม่" เมื่อผู้ใช้รายหนึ่งพยายามปฏิเสธเสรีภาพของผู้อื่น
  29. ^ วิธีเลือกใบอนุญาตสำหรับงานของคุณเอง – Free Software Foundation

ลิงค์ภายนอก