ทำไมฉันต้องเก็บลิขสิทธิ์ซอฟต์แวร์โอเพนซอร์ซไว้ในรูท


10

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

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

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

โบนัส:ถ้าโดยทั่วไปแล้วเห็นด้วยว่าใบอนุญาตที่ตั้งขึ้นมานั้นต้องอยู่ในรูททำไม OSI ของ FSF ไม่อนุมัติใบอนุญาตที่คุณสามารถอ้างถึงด้วย URL และอะไรที่ทำให้คนไม่สามารถสร้างใบอนุญาตนั้นได้?


4
ปัญหาหนึ่งที่นึกถึงคือ URL นั้นสามารถเปลี่ยนแปลงหรือยกเลิกได้
Aaron Kurtzhals

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

9
คุณกำลังถามว่าทำไมต้องมีใบอนุญาตทั้งใบในรูทหรือทำไมต้องมีใบอนุญาตทั้งหมดในรูท
DougM

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

4
เหตุผลที่อยู่ที่รูทมักจะเป็นเรื่องง่ายที่จะหา เมื่อฉันดาวน์โหลดโครงการของคุณฉันจะค้นหารูทและสิ่งแรกที่ฉันเห็นคือใบอนุญาต ง่ายเหมือนที่
JohnL

คำตอบ:


24

จากคำถามที่พบบ่อยของ GPL (แต่คำแนะนำนี้ใช้ได้กับใบอนุญาตทั้งหมด):

เพราะเหตุใด GPL จึงต้องการรวมถึงสำเนาของ GPL กับสำเนาของทุกโปรแกรม

การแนบสำเนาของใบอนุญาตกับงานมีความสำคัญเพื่อให้ทุกคนที่ได้รับสำเนาของโปรแกรมสามารถรู้ว่าสิทธิของเขาคืออะไร

อาจเป็นการดึงดูดให้ใส่ URL ที่อ้างถึงสิทธิ์ใช้งานแทนที่จะเป็นสิทธิ์ใช้งานของตัวเอง แต่คุณไม่สามารถแน่ใจได้ว่า URL จะยังคงใช้งานได้ห้าปีหรือสิบปีนับจากนี้ ยี่สิบปีต่อจากนี้ URL ที่เรารู้จักในปัจจุบันอาจไม่มีอยู่อีกต่อไป

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

(เน้นที่เหมือง)

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

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

  1. สิ่งนี้ไม่ได้พูดถึงตัวระบุสิทธิ์ใช้งานที่ชัดเจนน้อยกว่า (วลี "สิทธิ์ใช้งาน BSD" เป็นสิ่งสำคัญ)

  2. สิ่งนี้ไม่ได้พูดคุยกับใบอนุญาตที่พบได้ทั่วไปน้อยกว่าหรือได้รับการปรับแต่ง ("GPL พร้อมข้อยกเว้นการเชื่อมโยง" อยู่ในใจ: การเชื่อมโยงข้อยกเว้นใด) ใบอนุญาตจะต้องพบได้บ่อยแค่ไหนก่อนที่จะมีเหตุผลที่จะคาดหวังว่าผู้ใช้จะพบว่าเชื่อถือได้โดยใช้ชื่อ?

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

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

เหตุใดฉันต้องเก็บใบอนุญาตไว้ในรูทโครงการ

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

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

การวางไลเซนส์ของคุณในรูทไดเร็กทอรีเป็นวิธีปฏิบัติที่มีประโยชน์เช่นกันเพราะมันสามารถแก้ปัญหาใบขับขี่ของโมดูลที่ได้รับใบอนุญาตแตกต่างจากที่ทำงานโดยรวม สมมติว่าโครงการของฉัน FooProj ใช้โมดูล BarMod แบบสแตนด์อะโลน FooProj อาจได้รับลิขสิทธิ์ GPL ในขณะที่โมดูลสแตนด์อโลนอาจได้รับอนุญาตจาก MIT เมื่อฉันเปิด FooProj ครั้งแรกฉันเห็นสำเนาของ GPL ในรูทและเข้าใจว่างานโดยรวมเป็นลิขสิทธิ์ของ GPL เมื่อฉันลงไปในโฟลเดอร์สำหรับ BarMod ฉันเห็นไฟล์ลิขสิทธิ์ใหม่ที่นั่นและฉันเข้าใจว่าเนื้อหาของโฟลเดอร์นี้เป็นลิขสิทธิ์ของ MIT แน่นอนว่านี่เป็นเพียงความช่วยเหลือที่มีประโยชน์เท่านั้น คุณควรระบุการให้สิทธิ์ใช้งานโมดูลของคุณอย่างชัดเจนในไฟล์ README, NOTICE หรือไฟล์ที่คล้ายกัน

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


3
พิจารณาความเป็นไปได้ที่คุณเชื่อมโยงไปยังไซต์ระยะไกลสำหรับ site.com/foo/license.txt ที่คุณได้รับสิทธิ์ใช้งาน BSD แต่หลังจากนั้นจะได้รับการ relicensed ภายใต้ GPL v3 และนั่นคือ site.com/foo/license txt ตอนนี้มี แต่เวอร์ชันที่คุณดาวน์โหลดมีสิทธิ์แตกต่างกัน

ฉันได้ทำเครื่องหมายคำตอบนี้ให้ถูกต้องเนื่องจากดูเหมือนว่าจะมีการกำหนดภูมิปัญญาดั้งเดิมและกฎหมายเกี่ยวกับการออกใบอนุญาตของ OSS ที่กล่าวว่าความคิดนี้ทำให้ฉันเป็นหวาดระแวงบิตสำหรับโลกที่ถูกควบคุมและสำรองที่เราอาศัยอยู่ฉันไม่แน่ใจว่าความเสี่ยงของเนื้อหา URL ที่เป็นที่ยอมรับนั้นสูงกว่าความเสี่ยงของคนที่ลบส่วนของ ใบอนุญาตที่มีอยู่ในรูท และแม้ว่าจะมีความเสี่ยงสูงกว่าฉันก็สงสัยว่ามันยอดเยี่ยมมากที่จะบังคับให้ devs รวมใบอนุญาตแบบเต็มในซอฟต์แวร์ของพวกเขาซึ่งต่างจากพูดโดยอ้างถึงใบอนุญาตที่โฮสต์โดยภายนอกในความคิดเห็นของรหัส
samthebrand

FYI อาจเป็นสัญญาณของสิ่งต่าง ๆ ที่จะเกิดขึ้นสำหรับการให้สิทธิ์ใช้งาน OSS: Creative Commons 4.0อนุญาตให้ผู้ได้รับอนุญาตเชื่อมโยงไปยังหน้าแยกต่างหากที่มีข้อมูลการระบุแหล่งที่มา
samthebrand

6

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

มีใบอนุญาตอยู่ที่อนุญาต Apache 2.0 ตัวอย่างเช่น Apache 2.0 ต้องการเพียงไฟล์ต้นฉบับแต่ละไฟล์ที่มีส่วนหัวเล็ก ๆ ที่ชี้ไปยัง URL ตามกฎหมายของ Apache 2.0 License ไม่จำเป็นต้องทำซ้ำสิทธิ์การใช้งานแบบเต็มในแผนผังต้นไม้

จากใบอนุญาต Apache 2.0:

APPENDIX: How to apply the Apache License to your work

To apply the Apache License to your work, attach the following boilerplate
notice, with the fields enclosed by brackets "[]" replaced with your own 
identifying information. (Don't include the brackets!) The text should be  
enclosed in the appropriate comment syntax for the file format. We also 
recommend that a file or class name and description of purpose be included 
on the same "printed page" as the copyright notice for easier identification 
within third-party archives.

    Copyright [yyyy] [name of copyright owner]

    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
    You may obtain a copy of the License at

        http://www.apache.org/licenses/LICENSE-2.0

    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.

ฉันคิดว่าภาคผนวกไม่สมบูรณ์หรืออย่างน้อยก็ทำงานได้โดยมีข้อสันนิษฐานว่าคุณได้รวมสำเนาใบอนุญาตแล้ว จากข้อความ 2.0 เองเมื่อเผยแพร่งานที่มีลิขสิทธิ์ของ Apache:4.(a) You must give any other recipients of the Work or Derivative Works a copy of this License;
apsillers

3

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

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

กล่าวโดยย่อนี่คือสถานที่ที่มีประสิทธิภาพและใช้งานง่ายที่สุด


รูทโปรเจ็กต์เป็นที่แรกที่จะดู: มันคือด้านบนของทรี, รูทของลำดับชั้นของโฟลเดอร์ เอกสารระดับบนสุดควรไปที่นั่น: readme, license ฯลฯ ไฟล์เหล่านั้นสามารถสั่งให้ผู้อ่านขุดลึกลงไปในที่อื่น ๆ ในโครงการ แต่รูทเป็นที่แรกที่ฉันมองหา
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.