ภาษาแสดงสิทธิ์ (Rights Expression LanguageหรือREL)คือภาษาที่เครื่องสามารถประมวลผลได้ ใช้สำหรับแสดงสิทธิ์ในทรัพย์สินทางปัญญา (เช่น ลิขสิทธิ์) และข้อกำหนดและเงื่อนไขอื่นๆ ในการใช้งานเนื้อหา REL สามารถใช้เป็นข้อความเดี่ยวๆ (เช่น เมตาเดตาที่ใช้สำหรับการค้นหา การติดตามความเข้ากันได้) หรือใช้ร่วมกับระบบ DRM ก็ได้

RELs สามารถแสดงได้ในภาษาเครื่อง (เช่นXML , RDF , RDF Schemaและ JSON) แม้ว่า RELs จะสามารถประมวลผลได้โดยตรง แต่ก็อาจพบได้ในรูปแบบเมตาเดตา ที่ฝังอยู่ ภายในเอกสารอื่นๆ เช่นอีบุ๊กไฟล์ภาพไฟล์เสียงหรือไฟล์วิดีโอ

REL ที่น่าสนใจ ได้แก่:

ซีซีอาร์แอล

สคีมา RDFที่ โครงการ Creative Commons ใช้ ในการแสดงใบอนุญาต^{[ 1 ] [ 2 ]}

คำศัพท์เดียวกันนี้ยังได้รับการนำไปใช้โดยโครงการ GNUเพื่อแสดงใบอนุญาตสาธารณะทั่วไป (GPL)ในรูปแบบที่เครื่องอ่านได้^{[ 3 ] [ 4 ]}

ภาษาสิทธิ์ดิจิทัลแบบเปิดของ W3C (ODRL)

กลุ่มงาน W3C Permissions and Obligations Expression (POE) ได้พัฒนาคำแนะนำ ODRL สำหรับการแสดงข้อความสิทธิ์และภาระผูกพันสำหรับเนื้อหาดิจิทัล^{[ 5 ]}

แบบจำลองข้อมูล W3C ODRL นำเสนอกรอบสำหรับแนวคิดพื้นฐาน เอนทิตี และความสัมพันธ์ที่ก่อให้เกิดพื้นฐานสำหรับความหมายของนิพจน์ ODRL จุดมุ่งหมายของแบบจำลองข้อมูล ODRL คือการสนับสนุนนิพจน์นโยบายที่ยืดหยุ่นโดยอนุญาตให้ผู้เขียนสามารถรวมรายละเอียดเชิงแสดงออกเกี่ยวกับข้อกำหนดและเงื่อนไขสำหรับการใช้งานสินทรัพย์ ฝ่ายที่เกี่ยวข้อง และภาระผูกพันได้มากหรือน้อยตามต้องการ^{[ 6 ]}

คำศัพท์และการแสดงออกของ W3C ODRL อธิบายถึงคำศัพท์ที่อาจใช้ในการแสดงออกของนโยบาย ODRL และวิธีการจัดลำดับคำศัพท์เหล่านั้น คำศัพท์เหล่านี้เป็นส่วนหนึ่งของออนโทโลยี ODRL และทำให้ความหมายเป็นทางการ ชุดคำศัพท์ที่หลากหลายในคำศัพท์นี้ให้การสนับสนุนชุมชนในการใช้ ODRL เป็นภาษาหลักในการแสดงกรณีการใช้งานทั่วไป^{[ 7 ]}

เอ็กซ์อาร์เอ็มแอล

XrML เริ่มต้นจากการทำงานที่ Xerox ในช่วงทศวรรษ 1990 ^{[ 8 ]}หลังจากผ่านการพัฒนาหลายเวอร์ชันและโครงการแยกต่างหาก ต่อมาได้กลายเป็นพื้นฐานของ REL สำหรับMPEG- 21 ^{[ 9 ]}

เมจีโอ-21

ส่วนที่ 5 ของมาตรฐาน MPEGนี้ประกอบด้วย REL ^{[ 10 ]}

METSRights

METSRights เป็นสคีมาส่วนขยายของมาตรฐานเมตาเดต้าบรรจุภัณฑ์METS ^{[ 11 ] [ 12 ]}

ไรท์สเอ็มแอล

ภาษาการแสดงออกเชิงสิทธิของ IPTC สำหรับสื่อข่าว โดยอิงตาม ODRL

หน้าที่ของ REL คือการกำหนดใบอนุญาต และอธิบายใบอนุญาตเหล่านั้นในแง่ของสิทธิ์หรือข้อจำกัดที่ส่งผลต่อวิธีการใช้งานเนื้อหาที่เกี่ยวข้อง

คำว่า "ใบอนุญาต" ในที่นี้ อาจหมายถึงอย่างใดอย่างหนึ่งดังต่อไปนี้:

• ใบอนุญาตที่เป็นที่รู้จักกันดี เช่นGFDL , ใบอนุญาต Apacheหรือ ใบอนุญาต Creative Commonsเช่นCC BY-SA 4.0เป็นต้น
• ใบอนุญาตที่กำหนดไว้ล่วงหน้าซึ่งมีลักษณะคล้ายกับเหล่านี้ แต่ไม่เป็นที่รู้จักกันดีนัก ตัวอย่างเช่น ใบอนุญาตแบบ " ห่อหุ้ม " ที่เป็นกรรมสิทธิ์
• สัญญาอนุญาตเฉพาะที่สร้างขึ้นพร้อมข้อกำหนดและเงื่อนไขเฉพาะ สำหรับเนื้อหาที่ได้รับอนุญาตจากฝ่ายหนึ่งไปยังอีกฝ่ายหนึ่ง

การใช้ใบอนุญาตที่เป็นที่รู้จักกันดีมักถูกเลือกเนื่องจากมีความเรียบง่ายและไม่คลุมเครือ เช่นGFDLมีความหมายเหมือนกันไม่ว่าใครจะเป็นผู้ใช้งาน การใช้ใบอนุญาตที่มีอยู่แล้วยังช่วยหลีกเลี่ยงปัญหาการแพร่กระจายของใบอนุญาตนอกจากนี้ยังใช้งานได้จริงในการใช้ใบอนุญาตดังกล่าว และตรวจสอบว่าโครงการปฏิบัติตามใบอนุญาตนั้นหรือไม่ โดยไม่ต้องเข้าใจรายละเอียดมากนัก เพียงแค่รู้ว่า "GFDL เป็นที่ยอมรับสำหรับโครงการนี้" และ "ทรัพยากรทั้งหมดภายในโครงการนี้ใช้ GFDL" ก็เพียงพอแล้ว ในแง่นั้น ใบอนุญาตที่เป็นที่รู้จักกันดีจึงเป็นวิธีหนึ่งในการหลีกเลี่ยงความจำเป็นต้องใช้ REL เพื่อจำลองรายละเอียดของใบอนุญาต เพียงแค่ชื่อก็เพียงพอแล้ว^{[ 13 ]}

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

ผลิตภัณฑ์ บิลออฟเมทส์ซอฟต์แวร์ (SBOM) บางรายการเช่นSoftware Package Data Exchange (SPDX) ไม่ได้ใช้ REL แต่จำกัดใบอนุญาตที่เป็นไปได้ไว้เฉพาะชุดใบอนุญาตที่เป็นที่รู้จักกันดี ซึ่งแสดงผ่านคำศัพท์ควบคุม เฉพาะที่ ของSPDX ID [ ^{14 ] ใบ}อนุญาตแต่ละใบจะถูกระบุด้วยชื่อเต็ม เช่น " Mozilla Public License 2.0" และตัวระบุแบบย่อ ในที่นี้คือ "MPL-2.0" ใบอนุญาตสามารถรวมกันได้โดยใช้ตัวดำเนินการบูลีนแบบง่ายๆAND, OR, และการจัดกลุ่ม( ... )อย่างไรก็ตาม ยังคงต้องมีการแทรกแซงจากมนุษย์เพื่อตรวจสอบใบอนุญาตเหล่านี้ว่ายอมรับได้หรือไม่ และตรวจสอบผลกระทบเมื่อรวมกัน ผลิตภัณฑ์ SBOM ที่ไม่มี REL ไม่สามารถทำเช่นนี้ได้ด้วยตนเอง

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

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

ในการพัฒนาซอฟต์แวร์โอเพนซอร์ส เป็นเรื่องปกติที่โครงการต่างๆ จะสร้างใบอนุญาตของตนเองภายใต้ชื่อโครงการของตนเอง แต่รายละเอียดของใบอนุญาตนี้จะเป็นการคัดลอกมาจากใบอนุญาตที่เป็นที่รู้จักกันดี หรือแม้กระทั่งเป็นการอ้างอิงถึงใบอนุญาตดังกล่าว^{[ 15 ]} REL ควรสนับสนุนสิ่งนี้ โดยจัดหาวิธีการกำหนดใบอนุญาตโดยการจำแนกประเภทย่อยของใบอนุญาตที่มีอยู่ และอาจเปลี่ยนแปลงพฤติกรรมของใบอนุญาตเหล่านั้น ใบอนุญาตเหล่านี้จำนวนมากเป็นเพียงใบอนุญาตเพื่อความสวยงามเท่านั้นแม้ว่าโครงการอื่นๆ ที่ขึ้นอยู่กับใบอนุญาตเหล่านี้จะต้องสามารถทำงานร่วมกับใบ อนุญาตเหล่านั้นได้ ^{[ 16 ]}

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

ตัวอย่างเช่น อาจเป็นสัญญาจำกัดเวลาสำหรับการรับชมกีฬาทางทีวีเป็นเวลาหนึ่งเดือน โดยชำระเงินผ่านสัญญาต่อเนื่อง และรับชมได้เฉพาะภายในบ้านเท่านั้น ห้ามนำไปฉายในบาร์สาธารณะ

REL อาจใช้โมเดล Entity–attribute–value ได้อย่างสะดวก เช่นเดียวกับRDFเพื่อจัดโครงสร้างคำอธิบายของโมเดลสิทธิ์ โมเดลดังกล่าว^{[ 17 ]}แสดงออกมาในรูปของรายการ:

เอนทิตี้

สิ่งที่เป็นรูปธรรม หรือประเภทที่เป็นรูปธรรม เช่น:

• งาน/ทรัพย์สิน

สินค้าที่ได้รับอนุญาต

• ใบอนุญาต

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

หรืออาจเป็นตัวอย่างของใบอนุญาตเฉพาะอย่าง เช่น สิทธิ์ในการเล่นเนื้อหาที่ผู้ใช้รายหนึ่งซื้อไว้

• ผู้ใช้งานปลายทาง/ฝ่ายต่างๆ

วิธีการระบุตัวตนผู้ใช้ปลายทาง เมื่อการอนุญาตเป็นสัญญาเฉพาะกับบุคคลหรือหน่วยงานใดหน่วยงานหนึ่ง รวมถึงผู้ให้การอนุญาตด้วย

• เขตอำนาจศาล

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

คุณลักษณะ

"คุณสมบัติ" หรือแง่มุมต่างๆ ของแต่ละหน่วยงานเหล่านี้ เช่น สำหรับใบอนุญาต:

• ข้อจำกัด

การกระทำที่ได้รับอนุญาตหรือถูกห้าม

REL บางรายการ^{[ 17 ]}แยกข้อจำกัดเหล่านี้ออกเป็นกลุ่ม เนื่องจากค่าที่เป็นไปได้สำหรับแต่ละกลุ่มโดยทั่วไปเป็นเซตที่ไม่ทับซ้อนกัน (การกระทำที่บางครั้งอาจถูกห้ามนั้นแทบจะไม่เป็นข้อบังคับ)

• สิทธิ์อนุญาต
• ข้อห้าม
• ข้อกำหนด/ภาระผูกพัน (หรือหน้าที่)

ค่านิยม

ค่าสำหรับคุณสมบัติเหล่านี้ มาจากคำศัพท์ที่กำหนดไว้ล่วงหน้า เช่นเสรีภาพทั้งสี่ :

• การใช้ผลงาน
• การศึกษาและปรับปรุงงาน
• การแจกจ่ายสำเนาซ้ำ
• การแจกจ่ายสำเนาที่แก้ไขแล้วซ้ำ
• พิมพ์ไฟล์สินทรัพย์

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

จากนั้นจึงสามารถสร้างข้อความโดยใช้ REL (ซึ่งจะอยู่นอกเหนือขอบเขตของ REL) ได้ เช่น:

<cc:License rdf:about= "http://example.org/licenses/distribution/" > <cc:licenseClass rdf:resource= "https://creativecommons.org/license/" /> <dc:title>ใบอนุญาตการเผยแพร่ที่ได้รับ อนุญาต ของ FooCo </dc:title><cc:permits rdf:resource= "https://creativecommons.org/ns#Distribution" /> </cc:License>

นี่เป็นการกำหนดใบอนุญาตแบบนามธรรมฉบับใหม่ ซึ่งอนุญาตให้เผยแพร่สำเนาได้ ผลงานต่างๆ สามารถใช้ใบอนุญาตนี้ได้โดยการอ้างอิงถึงใบอนุญาตนี้

<p>เว็บเพจนี้ได้รับอนุญาตภายใต้<a rel="license" href="http://example.org/licenses/distribution/"> ใบอนุญาตการ เผยแพร่ที่ได้รับอนุญาตของ FooCo </a>

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

ตัวอย่าง W3C ODRL ด้านล่างนี้แสดงข้อตกลง (ใบอนุญาต) จากฝ่ายผู้มอบหมายสำหรับสินทรัพย์ที่ผู้รับมอบหมาย (ผู้ใช้) รายหนึ่งสามารถแสดงผลได้ และอีกรายหนึ่งสามารถพิมพ์สินทรัพย์นั้นได้

{ "@context" : { "odrl" : "http://www.w3.org/ns/odrl/2/" }, "@type" : "odrl:Agreement" , "@id" : "http://example.com/policy:4444" , "target" : "http://example.com/asset:5555" , "assigner" : "http://example.com/MyPix:55" , "permission" : [{ "assignee" : "http://example.com/guest:0001" , "action" : "odrl:display" }], "permission" : [{ "assignee" : "http://example.com/guest:0002" , "action" : "odrl:print" }] }

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

แนวทางที่ง่ายที่สุดคือการรวมเนื้อหาภายใต้ใบอนุญาตที่เป็นที่รู้จักกันดีเท่านั้น อย่างไรก็ตาม วิธีนี้ค่อนข้างเข้มงวด และใบอนุญาตที่เข้ากันได้หลายฉบับอาจอนุญาตให้รวมเนื้อหาได้แต่เป็นการยากที่จะตัดสินว่าได้รับอนุญาตหรือไม่ และควรออกใบอนุญาตให้กับเนื้อหาที่ได้มาอย่างไร^{[ 18 ]}อาจยังมีรายละเอียดปลีกย่อยเมื่อมีข้อกำหนดที่ทับซ้อนกันหรือ ปัญหา Copyleftโดยเฉพาะอย่างยิ่ง Creative Commons 'attribution-sharealike' และ 'attribution-noncommercial-sharealike' นั้นไม่เข้ากัน^{[ i ] [ 18 ] [ 19 ] [ 20 ]}

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

แม้ว่าใบอนุญาตที่แตกต่างกันจะถูกกำหนดไว้แต่เดิมผ่าน REL ที่แตกต่างกัน แต่ก็อาจเป็นไปได้ที่จะเข้ารหัสใบอนุญาตใหม่พร้อมกันใน REL ที่ใช้ร่วมกันอีกอันหนึ่ง ทำให้สามารถเปรียบเทียบกันได้GPLเพิ่งถูกแสดงออกมาในccRELซึ่งให้ข้อได้เปรียบนี้^{[ 3 ] [ 4 ] [ ii ]}

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

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

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

ปัญหาที่ไม่ชัดเจนนักในการเปรียบเทียบ REL คือเมื่อ REL เหล่านั้นมีเกณฑ์พื้นฐานที่แตกต่างกัน^{[ 21 ] [ 22 ]}เกณฑ์พื้นฐานกำหนดเงื่อนไขโดยนัยของใบอนุญาตเมื่อไม่มีข้อความที่ระบุอย่างชัดเจนรวมอยู่ด้วย REL บางประเภทใช้แนวทาง "ทุกสิ่งที่ไม่ได้รับอนุญาตถือเป็นสิ่งต้องห้าม" ในขณะที่บางประเภท (เช่น ccREL) ใช้อนุสัญญาเบิร์นเป็นเกณฑ์พื้นฐาน