권한 표현 언어

Rights Expression Language

REL(권리 표현 언어)은 지적 재산권(저작권 등) 및 콘텐츠에 대한 기타 사용 조건을 표현하기 위해 사용되는 기계 처리 가능한 언어입니다.REL은 스탠드아론 표현식(검색, 호환성 추적에 사용 가능한 메타데이터) 또는 DRM 시스템 내에서 사용할 수 있습니다.

REL은 머신 언어(XML, RDF, RDF Schema, JSON 등)로 표현할 수 있습니다.REL은 직접 처리될 수 있지만 eBook, 이미지, 오디오 또는 비디오 파일 등 다른 문서에 메타데이터로 포함되어 있는 경우에도 발생할 수 있습니다.

주목 REL

주목할 REL은 다음과 같습니다.

ccrel
Creative Commons 프로젝트에서 라이선스를 [1][2]표현하기 위해 사용하는 RDF 스키마입니다.
GNU 프로젝트에서는 General Public License(GPL)를 기계 판독 [3][4]가능한 형식으로 표현하기 위해서도 같은 어휘를 채용하고 있습니다.
W3C Open Digital Rights Language ODRL
W3C Permissions and Deligations Expression (POE) Working Group은 디지털 [5]콘텐츠에 대한 허가 및 의무 스테이트먼트를 표현하기 위한 ODRL 권장사항을 개발했습니다.
W3C ODRL 정보 모델은 ODRL 표현의 의미론의 기초가 되는 개념, 엔티티 및 관계를 위한 프레임워크를 제공합니다.ODRL 정보 모델의 목적은 작성자가 자산의 사용 조건, 당사자 및 [6]의무에 대한 세부 사항을 많거나 적게 포함할 수 있도록 함으로써 유연한 정책 표현을 지원하는 것입니다.
W3C ODRL Vocularies & Expression 에서는 ODRL 정책 표현에서 사용될 수 있는 용어와 그 시리얼화 방법에 대해 설명합니다.이 용어는 ODRL Ontology의 일부를 구성하며 의미론을 공식화합니다.어휘의 광범위한 용어 집합은 커뮤니티가 ODRL을 일반적인 사용 [7]사례를 표현하기 위한 주요 언어로 사용할 수 있도록 지원합니다.
XrML
XrML은 1990년대에 [8]Xerox에서 일하기 시작했다.여러 버전과 개별 프로젝트를 거친 후 MPEG-21용 [9]REL의 기반이 되었습니다.
MPEG-21
이 MPEG 표준의 파트5에는 [10]REL이 포함되어 있습니다.
METSRights(메트릭스)
METSRights는 METS 패키징 메타데이터 [11][12]표준의 확장 스키마입니다.

REL 사용

REL의 기능은 라이선스를 정의하고 관련 콘텐츠를 어떻게 사용할 수 있는지에 대해 암시하는 허가 또는 제한의 관점에서 이러한 라이선스를 설명하는 것입니다.

여기서 "라이센스"는 다음 중 하나를 의미합니다.

  • GFDL, Apache License 또는 Creative Commons CC-by-sa-3.0 등 "주요 라이선스"
  • 이것과 비슷하지만 그다지 잘 알려지지 않은 사전 정의된 라이센스.예를 들면, 독자 사양의 「shrinkwrap」라이선스가 있습니다.
  • 한 당사자로부터 다른 당사자에게 라이선스가 부여된 콘텐츠를 위해 개별 약관을 사용하여 작성된 특정 라이선스.

주지의 라이선스

잘 알려진 라이선스의 사용은 종종 모호하지 않은 단순성 때문에 선택됩니다. GFDL은 누가 사용하든 동일한 의미입니다.기존 라이선스를 사용함으로써 라이선스의 확산 문제도 회피할 수 있습니다.또한 이러한 라이선스를 사용하고 프로젝트가 어떤 세부사항을 수반하는지를 너무 많이 이해하지 않고 이를 준수하고 있는지 확인하는 것이 실용적입니다."GFDL은 이 프로젝트에 적합하다" 및 "이 프로젝트 내의 모든 리소스는 GFDL을 사용한다"는 것만 알면 됩니다.그런 의미에서 잘 알려진 라이선스는 라이선스의 세부사항을 모델링하기 위해 REL을 사용할 필요가 없는 방법입니다.그 이름만으로도 [13]충분합니다.

이 경우에도 REL은 이러한 라이선스에 도움이 될 수 있습니다.사용 중인 라이선스를 기계로 식별할 수 있는 방법을 제공하므로 "Apache License" 또는 "Apache 2.0 License" 사이에 명명 문제와 모호성이 발생하지 않습니다.이러한 라이선스의 작성자는 내부 세부사항을 기술하는 수단도 요구한다.

사전 정의된 라이선스

이는 사용 전에 정의되며 많은 라이센스 인스턴스에 적용할 수 있다는 점에서 잘 알려진 라이센스와 유사합니다.그 차이는 잘 알려져 있지 않기 때문에 사용자가 항상 처음 접하게 되기 때문에 각각이 무엇을 수반하는지도 설명할 필요가 있다는 것입니다.REL은 이를 위한 수단을 제공합니다.

현재 프로젝트 내에서 라이선스가 부여된 콘텐츠를 사용하려면 "프로젝트 내에서 라이선스가 프로젝트에 필요한 조건을 금지하거나 프로젝트가 허용할 수 없는 조건을 요구하는 리소스가 있습니까?"라는 문구를 평가해야 합니다.여기에는 프로젝트 사본을 나중에 배포하는 데 필요한 기능이나 일부 프로젝트에서 허용되지 않을 수 있는 시작 화면에 대한 인증 조건이 포함될 수 있습니다.

오픈 소스 소프트웨어 개발에서는 프로젝트명이 자신의 라이선스를 작성하는 것이 일반적이지만, 이 라이선스의 자세한 내용은 잘 알려진 라이선스의 보일러 플레이트 복사본이거나 이 [14]라이선스에 대한 참조이기도 합니다.REL은 이를 지원해야 하며, 기존 면허를 세분화하고 그 행동을 변경함으로써 면허를 정의할 수 있는 수단을 제공해야 한다.이러한 라이선스의 대부분은 허영 라이선스에 지나지 않습니다.다만, 다른 의존적인 프로젝트도 여전히 그들과 [15]함께 작업할 수 있어야 합니다.

특정 라이선스

이것들은, 필요에 따라서 특정의 컨텐츠 또는 특정의 최종 유저에 대해서 작성되는 라이센스입니다.이는 일반적으로 유효기간과 같은 특정 용도 조건을 첨부하기 위한 것입니다.이러한 라이선스는 표준 보일러 플레이트에 근거할 수 있지만, 각각의 라이선스는 고유합니다.이름을 부르는 것은 안정된 하나의 이름이 없기 때문에 통하지 않는다.따라서 REL을 사용하여 각각의 속성을 개개의 속성으로 표현할 필요가 있습니다.

예를 들어, 진행 중인 계약에 의해 지불된 대로 한 달 동안 TV 스포츠를 시청하는 시간 제한 계약과 공공 술집에서는 보여주지 않는 집에서 시청하는 시간 제한 계약이 포함될 수 있습니다.

REL의 구조

REL은 RDF와 같이 Entity-Attribute-Value 모델을 편리하게 사용하여 권리 모델에 대한 설명을 구성할 수 있습니다.이러한 모델은[16] 다음과 같은 목록으로 표현됩니다.

엔티티
구체적인 "물건" 또는 "클래스". 예:
  • 작업/자산
라이센스가 부여된 항목입니다.
  • 라이선스
라이선스, 특히 이것이 "잘 알려진" 라이선스일 경우(많은 Works가 GFDL과 같은 동등한 추상 라이선스를 사용한다)
또는 특정 라이선스의 인스턴스(예: 한 사용자가 구입한 콘텐츠 재생 권한)입니다.
  • 최종 사용자/파티
라이선스가 1명의 개인 또는 단체와 특정 계약을 체결한 경우 및 라이선싱 당사자를 식별하는 수단.
명시적인 언급은 거의 없지만, IP법에 현지 법적 차이가 있는 경우 중요한 한정자입니다.
특성
'재산' 또는 각 사업체의 측면(라이선스의 경우)
  • 제약
허용 또는 금지된 작업
일부 REL은[16] 각각의 가능한 값이 일반적으로 분리된 집합이기 때문에 이러한 제약조건을 그룹으로 구분한다(가끔 금지될 수 있는 조치는 거의 강제적이지 않다).
  • 권한
  • 금지 사항
  • 요건/요구사항(또는 의무)
가치
사전 정의된 어휘에서 이러한 속성에 대한 값(예: 네 가지 자유:
  • 작업 사용
  • 작업 검토 및 수정
  • 복사본 재배포
  • 수정된 복사본 재배포
  • 자산을 인쇄하다

REL은 이들 3개의 그룹 각각에 대해 멤버세트와 이들 그룹 간에 허용되는 관계를 정의합니다.위의 예에서는 라이센스, 권한 및 복사본 재배포에 대한 개념이 있을 수 있습니다.또한 관계가 있을 수 있으며, 라이선스는 금지사항을 명시할 수 있으며, 별도로 복사본을 재배포할 수 있는 허가를 받을 수 있습니다.

그 후, 다음과 같이 REL 를 사용해 스테이트먼트를 작성할 수 있습니다(이러한 스테이트먼트는 REL 그 자체의 외부에 있습니다).

<cc: License rdf:about="http://example.org/licenses/distribution/"> <cc:license Class rdf:resource="https://creativecommons.org/license/"/> <dc:disc>FooCo의 배포 허가 라이센스 </dc:title> <cc:syslog rdf:resource="https://creativecommons.org/ns#Distribution"/> </cc:라이선스 >

이것은 복사본을 다시 배포할 수 있는 새로운 추상 라이선스를 정의합니다.저작물은 이를 참조함으로써 본 라이선스를 사용할 수 있다.

<p> 이 웹 페이지는,<a rel="displicate" href="http://example.org/licenses/distribution/">FooCo의 유통 허가 라이센스</a>에 근거해 라이센스를 취득하고 있습니다.

이 가상의 "배포 허용" 라이선스는 Creative Commons REL을 사용하여 표현되었지만 Creative Commons 라이선스는 아닙니다.「라이선스」, 「허가」, 「배포」의 개념만을 사용하고 있습니다.이 프로젝트에 의해 정의된 크리에이티브 커먼스의 라이선스는 아니지만, 이러한 용어의 정확한 공통점을 공유하고 있습니다.「유통」은, 그 용어의 의미와 법적 정의가 정확하게 일치합니다.

다음 W3C ODRL의 예는 한 명의 양수자(사용자)가 자산을 인쇄하기 위해 표시할 수 있는 자산에 대한 양수자의 계약(라이센스)을 나타내고 있습니다. 

{     "@filength": {     '오들': "http://www.w3.org/ns/odrl/2/"     },     "@type": "odrl: 계약",     "@id": "http://example.com/policy:4444",     "타깃": "http://example.com/asset:5555",      "더 많은": "http://example.com/MyPix:55",     '허가': [{         수신자: "http://example.com/guest:0001",         '액션': "odrl: 표시"     }],     '허가': [{         수신자: "http://example.com/guest:0002",         '액션': "odrl:프린트"     }] }


라이선스 간 인터워킹

매시업과 협업 프로젝트에 대한 관심이 높아짐에 따라 콘텐츠와 이를 지원할 수 있는 라이센스 기술에 대한 수요가 증가하고 있습니다.

가장 간단한 방법은 동일한 잘 알려진 라이센스로만 콘텐츠를 결합하는 것입니다.그러나 이는 지나치게 제한적이며 호환되는 많은 라이선스로 인해 콘텐츠를 결합할 수 있습니다.그러나 이를 판단하고, 허용 여부를 판단하고, 그 결과로 얻은 [17]콘텐츠의 라이선스를 어떻게 취득해야 하는지 판단하기는 어렵다.요건이 중복되거나 카피레프트에 문제가 있는 경우에도 여전히 미묘한 문제가 있을 수 있습니다.특히 크리에이티브 커먼스의 '속성-공유 유사'와 '속성-비상업적-공유 유사'는 [note 1][17][18][19]양립할 수 없다.

관련된 모든 라이선스가 동일한 REL을 통해 표현될 수 있다면 라이선스의 결합은 더 간단하다.이 경우 적어도 "배포"의 동일한 정의에 적용한다면 허가 또는 금지가 적용되는 시기를 보다 쉽게 알 수 있습니다.이에 대한 명백한 예로는 Creative Commons 라이선스를 들 수 있습니다.이 라이선스의 패밀리는 모두 동일한 REL로 정의됩니다.

서로 다른 라이선스가 서로 다른 REL을 통해 처음 정의되었더라도, 다른 공유 REL에서 라이선스를 동시에 재인코딩하여 비교할 수 있게 할 수 있습니다.GPL은 최근 ccREL로 표현되어 이러한 [3][4][note 2]이점을 제공하고 있습니다.

라이선스 간 인터워킹의 어려움

상충하는 요건(상기)의 문제 외에 라이선스를 비교하는 데 있어서도 기술적인 문제가 있다.라이선스가 다른 경우에도 같은 REL을 사용할 수 있으면 이들 대부분은 완화됩니다.

의미론

스키마(REL 등)간의 시멘틱 변환의 일반적인 문제는 용어의 의미가 동일한지 확인하는 것입니다.시멘틱 웹은 의미를 설명하기 위해 OWL과 같은 온톨로지 도구를 사용하기 시작했지만, REL에 대한 최신 기술은 이보다 덜 발전했습니다.단순한 처리와 그렇지 않으면 비용이 많이 드는 소송의 가능성은 REL의 의미론이 단순히 추론자를 통해 그렇게 되는 것이 아니라 명확하게 동일해야 한다는 것을 의미합니다.

일반적인 문제는 클래스, 속성 및 인스턴스의 동등성을 입증하는 것입니다.REL의 경우 가장 큰 문제는 인스턴스, 즉 "배포", "공유 유사" 등의 정확한 정의입니다.클래스와 속성은 보통 단순한 개념이며 매우 유사합니다.그러나 모든 REL이 모든 클래스를 지원하는 것은 아닙니다.일부 REL은 개발된 시장의 요구에 따라 관할권을 무시하거나 최종 사용자를 무시하는 경우도 있습니다.

암묵적인 전제 조건

REL을 비교할 때 눈에 잘 띄지 않는 문제는 REL의 [20][21]기준선이 다른 경우입니다.기준선은 명시적인 문구가 포함되지 않을 때 라이선스에 의해 암시되는 조건을 정의한다.일부 REL은 "Everything not permitting is forbidden" 접근방식을 채택하고 있으며, 다른 REL(ccREL 등)은 Berne Convention을 기준으로 사용합니다.

레퍼런스

  1. ^ Creative Commons #비판 참조
  2. ^ GNU 라이선스를 위한 RDF 도입의 제안에도 불구하고 GPL은 단순히 RDF가 아닌 ccREL(및 RDF)로 표현되기 때문에 이점이 발생한다는 점에 유의하십시오.라이선스를 비교하기 위해서는 데이터 모델뿐만 아니라 REL 어휘를 공유해야 합니다.
  1. ^ "ccREL: The Creative Commons Rights Expression Language" (PDF). Creative Commons. 3 March 2008.
  2. ^ "10: ccREL: The Creative Commons Rights Expression Language" (PDF). The Digital Public Domain: Foundations for an Open Culture. 2012.
  3. ^ a b "Introducing RDF for GNU Licenses". Free Software Foundation.
  4. ^ a b "GPL in RDF" (RDF). Free Software Foundation. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  5. ^ "W3C Permissions and Obligations Expression (POE) Working Group".
  6. ^ "W3C ODRL Information Model".
  7. ^ "W3C ODRL Vocabulary & Expression".
  8. ^ XrML.org
  9. ^ "The MPEG-21 Rights Expression Language" (PDF). Rightscom. Archived from the original (PDF) on November 8, 2006.
  10. ^ MPEG. "Part 5: Rights Expression Language". Archived from the original on 2009-07-05.
  11. ^ Nancy J. Hoebelheinrich (Stanford University Libraries). "METSRights Schema". Library of Congress.
  12. ^ "METSRights examples". Library of Congress.
  13. ^ Ed Burnette (2006-11-02). "Google says no to license proliferation". ZDNet. Archived from the original on 2007-02-24.
  14. ^ 오픈 소스 소프트웨어의 GPL 호환성을 확보합니다. 또는 Ether.,휠러 (2014)
  15. ^ David A. Wheeler (20 August 2008). "FLOSS License Proliferation: Still a problem".
  16. ^ a b "Can I combine two different Creative Commons licensed works? Can I combine a Creative Commons licensed work with another non-CC licensed work?". FAQ. Creative Commons. Retrieved 16 Sep 2009.
  17. ^ "Creative Commons — Attribution-ShareAlike 3.0 Unported — CC BY-SA 3.0".
  18. ^ "Creative Commons — Attribution-NonCommercial-ShareAlike 3.0 Unported — CC BY-NC-SA 3.0".
  19. ^ "ccREL: The Creative Commons Rights Expression Language". W3C Member Submission. 1 May 2008.
  20. ^ Nathan Yergler. "How to negate cc:permits, cc:prohibits, cc:requires?". cc-metadata mailing list.