คุณต้องรวมคำบอกกล่าวการอนุญาตให้ใช้สิทธิกับไฟล์ต้นฉบับทุกไฟล์หรือไม่?


111

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

ดูเหมือนว่าจะเป็นการเสียเวลาและพื้นที่ไฟล์ ฉันวางแผนที่จะวาง@licenseและ@authorแท็กในโครงการของฉัน แต่ฉันไม่เห็นว่าทำไมฉันต้องแสดงรายการประกาศยักษ์ในแต่ละไฟล์ถ้าฉันไม่ต้องการให้รหัสของฉันเป็นโดเมนสาธารณะ

มีเหตุผลใดบ้างที่ฉันต้องการรวมการแจ้งเตือนดังกล่าวในโครงการของฉันหรือจะรวมการแจ้งเตือนไว้ในREADMEและ@licenseแท็กก็ดีพอ สิ่งนี้ส่งผลกระทบต่อกฎ "ใบอนุญาตส่วนใหญ่ที่ระบุไว้อย่างชัดเจน" หรือเป็นเพียง overkill เพื่อให้ผู้คนไม่เถียง?


10
ผู้แก้ไขของคุณควรอนุญาตให้คุณพับ / ซ่อนใบอนุญาตเป็น 1 บรรทัด
Pubby

1
ตามความเป็นจริงถ้ามีคนทำรหัสเหล็กให้เปลี่ยนชื่อตัวแปรและลบลิขสิทธิ์ศาลจะพิจารณาไฟล์ทั้งสองนี้เหมือนกันหรือไม่?
NoChance

5
@Emmad: ไม่ศาลจะไม่พูดว่าพวกเขาเหมือนกัน (แต่พวกเขาอาจจะ "เหมือนกันเป็นหลัก") ใช่ศาลจะบอกว่าเป็นการละเมิดลิขสิทธิ์
Andrew Dalke


คำตอบ:


39

ในความเข้าใจของฉันGPLv3แนะนำอย่างยิ่ง (หรืออย่างน้อยก็อาจต้องมีอย่างน้อยฉันจะเข้าใจข้อความวิธีการใช้ข้อกำหนดเหล่านี้กับโปรแกรมใหม่ของคุณหลังจากส่วนที่ 17) ประกาศลิขสิทธิ์ในไฟล์ต้นฉบับทุกไฟล์ มันบอกว่า

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

<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year>  <name of author>

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.

และโครงการของ GNU ที่เป็นเจ้าของ FSF เช่น GCC ก็มีประกาศในทุก ๆ ไฟล์

ฉันยังรู้จักโปรแกรม (ระบบ CAIA ของ J.Pitrat) ซึ่งถูกปฏิเสธในเว็บไซต์ชุมชนซอฟต์แวร์เสรีเพราะไม่มีการแจ้งเตือนดังกล่าวในทุกไฟล์

ผมไม่ได้เป็นทนายความแต่ผมเชื่อว่าการแจ้งดังกล่าวเป็นจริงผลบังคับใช้ในทุกไฟล์ที่มาของโปรแกรม GPLv3

(หากคุณใช้ใบอนุญาตอื่น ๆ โดยเฉพาะอย่างยิ่งผู้ที่ไม่ใช่ FSF โปรดอ่านอย่างละเอียดเกี่ยวกับวิธีการใช้ YMMV อย่างไรก็ตาม AFAIK การเขียนประกาศในทุก ๆ ไฟล์จะไม่เป็นอันตราย)


16
ไม่สามารถบังคับได้เนื่องจากมีระบบเช่นรูปภาพ Smalltalk ซึ่งไม่แสดงซอร์สโค้ดเป็นไฟล์ พวกเขาพูดว่า "ปลอดภัยที่สุด" และ "ควร" ไม่ใช่ "ต้อง" สิ่งที่พวกเขาแนะนำคือแนวทางที่เข้าใจง่ายโดยมีโอกาสน้อยมากที่คนจะทำผิดพลาด แต่ก็ไม่ใช่ "บังคับจริง ๆ "
Andrew Dalke

ฉันเห็นด้วยและฉันพูดว่า "ซอร์สไฟล์" ตามวัตถุประสงค์ ที่จริงแล้วระบบของ CAIA นั้นคล้ายกับ Smalltalk: รูปภาพอยู่ในไฟล์ข้อมูลและ CAIA "ไฟล์ต้นฉบับ" ที่ฉันพูดถึงนั้นเป็นไฟล์ C ที่สร้างขึ้น อย่างไรก็ตาม GCC MELT ของฉัน (สาขาหนึ่งของ GCC ภายใต้ลิขสิทธิ์ FSF) ก็เป็นโปรแกรมที่กำหนดไว้และฉันก็ระมัดระวังที่จะสร้างความคิดเห็นเกี่ยวกับลิขสิทธิ์ในไฟล์ C ที่สร้างขึ้น (และฉันใส่ไว้ในรหัส C & MELT ที่เขียนด้วยมือ)
Basile Starynkevitch

จุดที่ถ่าย ฉันรู้แล้วตอนนี้วรรคหนึ่งเกี่ยวกับ MELT โดยทั่วไปจะเป็นการดีที่สุดที่ไฟล์ที่สร้างขึ้นจะมีประกาศลิขสิทธิ์เนื่องจากมันยากมากที่จะ "แนบ" ใบอนุญาตมิฉะนั้น เช่น "yacc" และ "lex" ถูก จำกัด ในสิ่งที่พวกเขาสามารถทำได้
Andrew Dalke

1
จากประสบการณ์ส่วนตัว: เพื่อให้โครงการได้รับการยอมรับในสะวันนาคุณต้องมีใบอนุญาตในทุกไฟล์
Mael

1
เพื่อชี้แจงตามคำถามที่พบบ่อยของ GPL, #LicenseCopyOnlyและ#NoticeInSourceFileในขณะที่เขียนนี้ไม่จำเป็นต้องรวมข้อความHow to Apply ...กับไฟล์ต้นฉบับทุกไฟล์ สังเกตว่าภาษาใช้ "ควร" และไม่ใช่ "ต้อง" อย่างไรก็ตามพวกเขาแนะนำอย่างยิ่งให้คุณปฏิบัติตามแนวทางนี้
ZeroKnight

37

ฉันเคยเห็นหลายโครงการที่พูดถึงใบอนุญาตในไฟล์ README หรือไฟล์ LICENSE หรือ COPYING เท่านั้น

ซอฟต์แวร์ของคุณอยู่ภายใต้ลิขสิทธิ์โดยอัตโนมัติตามที่ตกลงกันในกฎหมายระหว่างประเทศ (เว้นแต่คุณจะทำงานให้กับรัฐบาลสหรัฐฯหรือองค์กรอื่น ๆ ที่ไม่ได้มีลิขสิทธิ์)

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

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

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

ที่สามารถอยู่ในไฟล์ของตัวเองหรือเมื่อฉันใช้รหัสเป็นห้องสมุดฉันใส่ส่วนที่เกี่ยวข้องลงในไดเรกทอรีของตนเองและเพิ่ม "README" หรือ "LICENSE" ลงในไดเรกทอรีย่อยนั้น

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

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

ตัวอย่างเช่นเท็มเพลต Eclipse เริ่มต้นเพิ่มสิ่งที่ฉันคิดว่าเป็นเมทาดาทาที่ไร้ประโยชน์ก่อนแต่ละฟังก์ชันซึ่งฉันคิดว่าถูกควบคุมได้ดีกว่าโดยการควบคุมเวอร์ชัน แต่การปฏิบัตินั้นเป็นเรื่องปกติในร้านค้าหลายแห่ง


2
ตัวอย่างเช่นฉันไม่เห็นสิ่งที่เกี่ยวข้องกับการออกใบอนุญาตในไฟล์ต้นฉบับของ Rails เลย
Anton Barkovsky

3
และจากไฟล์ 200 ไฟล์ในไลบรารีมาตรฐาน Python ระดับบนสุดมีเพียง 34 คำเท่านั้นที่มีคำว่า "ลิขสิทธิ์" และมี 4 ไฟล์เท่านั้นที่มีไว้สำหรับ Python Software Foundation ซึ่งควบคุมลิขสิทธิ์ไปยัง Python
Andrew Dalke

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

13

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

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


21
ไม่ใช่เรื่องง่ายที่จะรวมรวมผ่านการคัดลอกวางส่วนต่าง ๆ ของไฟล์ต้นฉบับด้วยหรือไม่ ถ้าเช่นนั้นจะเป็นอย่างไร ข้อโต้แย้งนี้ไม่สอดคล้องกับฉัน
Travis Griggs

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

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

8

ไม่มีการประชุมลับมหาอำนาจในบังเกอร์ใต้ดินที่ระบุว่าคุณต้องใส่อะไรลงในไฟล์ต้นฉบับแต่ละไฟล์

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

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


6

ฉันเกือบโพสต์คำถามที่คล้ายกันอย่างน่าทึ่ง น้อยกว่าเกี่ยวกับความรำคาญและเพิ่มเติมเกี่ยวกับเทคนิค TL: DR: ฉันเชื่อว่าคำตอบนั้นเป็นเรื่องของลำดับความสำคัญของผู้เขียน บางทีเจตนาอาจจะแม่นยำกว่าลำดับความสำคัญ ...

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

# This file is covered by the LICENSING file in the root of this project.

หรือบรรทัดที่ดูเท่กว่านี้:

* @license OMGBBQ <http://goodlics.com/bbq>

"แต่เดี๋ยวก่อน!" คุณอุทาน "คุณเพิ่งพูดว่าไฟล์ถูกแยกออกจากโครงการ! และ goodlics.com จะเปลี่ยนเส้นทางไปยังผู้บุกรุกโดเมน! หยุดการไปที่ trixy!" คุณพูดถูกแล้วฉันพูดถูก แต่นั่นอาจไม่เป็นไรและหยุดตะโกนใส่ฉัน นี่คือเหตุผลที่ไม่ใช่ทนายความของฉัน:

  • เกือบทุกประเทศเห็นด้วยกับ [รู้สึก] อนุสัญญาเบิร์นซึ่ง AFAIK หมายความว่าถ้าคุณสร้างบางสิ่งคุณมีลิขสิทธิ์ในช่วงเวลานั้น คุณไม่ต้องการบรรทัด (c) หรืออึเช่นนั้น แต่เนื้อหานั้น (รวมถึง VCS ของบุคคลที่สามอย่าง GitHub) ช่วยให้คุณพิสูจน์ได้ง่ายขึ้นว่าคุณสร้างขึ้นและเมื่อคุณสร้างมันขึ้นมา
  • ดังนั้นหากคุณโพสต์รหัส 1337 ออนไลน์ที่คุณสร้างขึ้นคุณมีลิขสิทธิ์ ไม่มีใครได้รับอนุญาตให้คัดลอก ฉันรู้ว่ามันหายากและน่าตกใจ แต่ฉันได้ยินมาว่าบางครั้งผู้คนทำผิดกฎหมาย ยังคงเป็นไปได้
  • ที่น่ากลัวnyancat-bcminer-algo.qbasicไฟล์ที่คุณเขียนและโพสต์บน LiveJournal จะเชื่อหรือไม่ว่าไม่เป็นสาธารณสมบัติ ไม่ใช่ถ้าคุณบอกว่าเป็นสาธารณสมบัติ โดยค่าเริ่มต้นมันเป็นของคุณและของคุณคนเดียว มัน ... พรีเชียส (อย่างน้อย 25-50 ปีขึ้นไปเว้นแต่ว่าคุณเป็น Disney)
  • ผู้คนสื่อสารความตั้งใจนี้ตามอัตภาพ (ให้สิทธิบางส่วนหรือทั้งหมดไม่ใช่ของคุณและของคุณคนเดียว) ผ่านทางตัวแทน แต่คุณต้องประกาศเจตนานั้น เป็นการยกเลิกการเข้าร่วม (Haha ได้รับหรือไม่เลือกที่จะยกเลิกการเป็นเจ้าของลิขสิทธิ์ของคุณหรือไม่น่ากลัว) ออกตั๋วของคุณเราเกือบจะถึงแล้ว!
  • หากไม่เป็นไรว่าไฟล์ที่ไม่มีผู้ใช้ดังกล่าวข้างต้นเป็นโดเมนส่วนตัว - นั่นคือไม่สามารถคัดลอกได้อย่างถูกกฎหมายตามกฎหมายดังนั้นการใช้การอ้างอิงที่อาจเสียหาย อย่างไรก็ตามหากไม่เป็นไรฉันคิดว่าคุณต้องรวมข้อความลิขสิทธิ์ในไฟล์ต้นฉบับทุกไฟล์ วิธีการที่ไฟล์คนเดียวที่ยังคงมั่นใจว่าจะได้รับใบอนุญาตแบบที่คุณ prioriti-- ตั้งใจ ใช่ดีกว่า

การให้เหตุผลนี้ทำให้สมมติฐานสองข้อมีความสำคัญและอาจไม่ถูกต้อง:

  • การอ้างอิงใบอนุญาต "ที่เสีย" จะกลับมาใช้กับพฤติกรรมเริ่มต้น (มีลิขสิทธิ์) ซึ่งอาจไม่ใช่ข้อสันนิษฐานที่ถูกต้อง
  • ไซต์ที่คุณโพสต์ไว้ไม่มีนโยบายการโพสต์ (เช่น StackExchange) ที่ทำให้ทุกโดเมนสาธารณะ

ขอบคุณสำหรับการขี่ลิงสายการบินสมอง

ข้อความปฏิเสธความรับผิดชอบ: นี่เป็นเหตุผลที่ดีสำหรับฉันที่ฉัน 90% แน่ใจว่าฉันผิด 100%


6

มีความแตกต่างระหว่างการเป็นใบอนุญาตและคำนำ

ในบางส่วนของโครงการของฉันฉันใช้ใบอนุญาตสาธารณะทั่วไป Version 3.0 GNU GPL ทำให้จำเป็นต้องมีการเริ่มนำทุกไฟล์ซอร์สโค้ด:

คำนำและคำแนะนำเป็นส่วนสำคัญของ GNU GPL และอาจไม่ถูกละเว้น

ที่มา: http://www.gnu.org/licenses/gpl-faq.html#GPLOmitPreamble

ดังนั้นนี่คือสิ่งที่ฉันทำ:

1. เพิ่ม License.txt

ในการปฏิบัติตามกฎฉันวางLICENSE.txt ลงในรูทของที่เก็บโครงการของฉัน ข้อเสนอแนะนี้ยังได้รับจาก GitHub (ดูที่ " ใบอนุญาตมีชีวิตอยู่ที่ไหน" )

2. เพิ่มคำนำโดยใช้ auto fold

ต่อไปฉันรวมคำนำ GPL ไว้ด้านบนของซอร์สโค้ดไฟล์ทุกไฟล์แต่จะทำให้มันแทบจะไม่รบกวนฉันซ่อนมันไว้ใน IDE IDE ส่วนใหญ่มีคุณสมบัติในการพับบล็อคโค้ดโดยอัตโนมัติ NetBeans มีการสนับสนุนCustom Code Foldingและ WebStorm รองรับการพับข้อคิดเห็นเช่นกัน

ดังนั้นนี่คือลักษณะ:

//<editor-fold desc="Preamble">
/*
 * Company Name
 * Copyright (C) 2016 Company Name
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 *
 * ...
 */
//</editor-fold>

console.log('Here is my licensed JavaScript code.');

ฉันคิดว่านี่เป็นข้อตกลงที่ดีมากระหว่างความสะดวกสบายและความปลอดภัยตามกฎหมาย

หากคุณมีโครงการจำนวนมากที่คุณต้องการเพิ่มใบอนุญาตhttp://www.addalicense.com/อาจเป็นประโยชน์

โปรดทราบ: คำแนะนำของฉันอ้างถึง GPLv3 ประเภทใบอนุญาตอื่น ๆ อาจไม่ต้องมีการเริ่มนำ


7
« GNU GPL ทำให้จำเป็นต้องมีการเริ่มนำทุกไฟล์ซอร์สโค้ด: »ไม่ ส่วนที่คุณยกมานั้นป้องกันไม่ให้คุณนำคำนำออกจากLICENSEไฟล์นั่นคือคุณไม่สามารถแก้ไขข้อความของ GPL ได้โดยการวางไว้
Andrea Lazzarotto

6

มีอีกวิธีการปฏิบัติที่ยังไม่ได้กล่าวถึงที่นี่

SPDX-License-Identifierแท็ก https://spdx.org/using-spdx

การใช้ "แผ่นสำเร็จรูปทางกฎหมาย" ของคุณในทุกส่วนหัวของไฟล์ต้นฉบับจะลดลงเหลือเพียงสองบรรทัด:

/* SPDX-License-Identifier: (GPLv3-or-later AND LGPL-2.0-only) WITH bison-exception */
/* Copyright © 1234 Project Author */

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.