Språk för rättighetsuttryck - Rights Expression Language

A Rights Expression Language eller REL är ett maskinbehandlingsbart språk som används för att uttrycka immateriella rättigheter (t.ex. upphovsrätt) och andra villkor för användning över innehåll. REL kan användas som fristående uttryck (dvs. metadata som kan användas för sökning, kompatibilitetsspårning) eller inom ett DRM- system.

REL kan uttryckas på ett maskinspråk (som XML , RDF , RDF Schema och JSON). Även om REL: er kan behandlas direkt kan de också påträffas när de är inbäddade som metadata i andra dokument, såsom e- böcker , bild- , ljud- eller videofiler.

Anmärkningsvärda REL: er

Anmärkningsvärda REL: er inkluderar:

ccREL: Ett RDF-schema som används av Creative Commons- projektet för att uttrycka sina licenser .; Samma vokabulär har också antagits av GNU-projektet för att uttrycka deras General Public License (GPL) i maskinläsbar form.

W3C Open Digital Rights Language ODRL: Arbetsgruppen W3C Permissions and Obligations Expression (POE) har utvecklat ODRL-rekommendationerna för att uttrycka behörighets- och skyldighetsuttalanden för digitalt innehåll.; W3C ODRL informationsmodell erbjuder en ram för de underliggande begreppen, enheterna och relationerna som utgör grunden för semantiken för ODRL-uttryck. Syftet med ODRL-informationsmodellen är att stödja flexibla policyuttryck genom att låta författaren inkludera så mycket eller så lite uttrycksfulla detaljer om villkoren för tillgångsanvändning, berörda parter och skyldigheter.; W3C ODRL Vocabulary & Expression beskriver de potentiella termer som används i ODRL Policyuttryck och hur man serierar dem. Termerna ingår i ODRL Ontology och formaliserar semantiken. Den breda uppsättningen av termer i vokabulären ger stöd för samhällen att använda ODRL som huvudspråk för att uttrycka vanliga användningsfall.

XrML: XrML började med arbete på Xerox på 1990-talet. Efter att ha gått igenom flera versioner och separata projekt, bildade den senare grunden för REL för MPEG-21 .

MPEG-21: Del 5 av denna MPEG- standard innehåller en REL.

METSRättigheter: METSRights är ett förlängningsschema till METS- förpackningsmetadatastandarden.

Användning av en REL

Funktionen för en REL är att definiera licenser och att beskriva dessa licenser i termer av de behörigheter eller begränsningar de innebär för hur relaterat innehåll sedan kan användas.

"Licens" här kan betyda antingen:

En "välkänd licens", såsom GFDL , Apache-licens eller en Creative Commons CC-by-sa-3.0 etc.
En fördefinierad licens som är så här, men inte så känd. Exempel skulle vara proprietära "krympfilm" -licenser.
En specifik licens som skapas med individuella villkor för innehåll som licensierats från en part till en annan.

Välkända licenser

Användning av en välkänd licens väljs ofta för sin otvetydiga enkelhet: GFDL betyder samma oavsett vem som använder den. Användning av befintliga licenser undviker också problem med licensförökning . Det är också praktiskt att använda en sådan licens och att kontrollera att ett projekt följer den utan att förstå för mycket om vilken detalj det innebär. Att bara veta att "GFDL är acceptabelt för detta projekt" och "Alla resurser inom detta projekt använder GFDL" är tillräckligt. I den bemärkelsen är välkända licenser ett sätt att undvika att behöva använda en REL för att modellera detaljerna i en licens, bara namnet är tillräckligt.

Trots detta kan en REL fortfarande vara användbar med dessa licenser. Det ger ett maskinbehandlingsbart sätt att identifiera licensen som används, undvika namngivningsproblem och potentiella tvetydigheter mellan "Apache-licens" eller "Apache 2.0-licens". Författarna till dessa licenser kräver också ett sätt att beskriva sina interna detaljer.

Fördefinierad licens

Dessa liknar de välkända licenserna, eftersom de definieras innan de används och kan tillämpas på många fall av licensiering. Deras skillnad är att eftersom de inte är välkända är det också nödvändigt att förklara vad var och en av dem innebär, eftersom användaren alltid kommer att stöta på dem för första gången. En REL ger medel för att göra detta.

Att använda licensierat innehåll inom ett projekt kräver nu utvärdering av uttalandet, "Finns det några resurser inom detta projekt vars licens förbjuder ett villkor som projektet kräver, eller kräver ett villkor som projektet inte kan tillåta?". Dessa kan inkludera en nödvändig förmåga att distribuera kopior av projektet efteråt, eller ett villkor för ackreditering på en stänkskärm som kan vara oacceptabelt för vissa projekt.

I programvaruutveckling med öppen källkod är det också vanligt att projekt skapar sin egen licens under sitt eget projektnamn, men att detaljerna i denna licens är en kopia av en panna från en välkänd licens eller till och med en referens till denna licens. En REL bör stödja detta genom att tillhandahålla ett sätt för att licenser ska definieras genom att underklassificera befintliga licenser och eventuellt ändra deras beteende. Många av dessa licenser är lite mer än fåfängelicenser , även om andra beroende projekt fortfarande måste kunna arbeta med dem.

Specifika licenser

Dessa är licenser som skapas efter behov för specifika innehållsdelar eller specifika slutanvändare. Detta är vanligtvis så att de kan ha användarspecifika villkor knutna till sig, till exempel utgångsdatum. Även om dessa licenser kan baseras på en standardpanna, är var och en därför unik. Att hänvisa till dem med namn kunde inte fungera eftersom det inte finns något enda, stabilt namn. Det är därför nödvändigt att använda en REL för att uttrycka var och en i termer av dess individuella egenskaper.

Exempel kan vara ett tidsbegränsat kontrakt för att titta på TV-sport i en månad, som betalas av ett pågående kontrakt, och att titta på detta inom hemmet men inte för att visa det inom en offentlig bar.

Struktur för en REL

En REL kan bekvämt använda en Entity-Attribute-Value-modell , som för RDF , för att strukturera sin beskrivning av en rättighetsmodell. En sådan modell uttrycker sig som listor över:

Enheter: Konkreta "saker" eller "klasser", t.ex.

Arbete / tillgång

Föremålet som licensieras.

Licens

Licensen, särskilt när detta antingen är en "välkänd" licens (där många verk använder en jämförbar abstrakt licens, till exempel GFDL )

eller annars en instans av en specifik licens, såsom innehållsuppspelningsrättigheter som köpts av en användare.

Slutanvändare / parter

Ett medel för att identifiera slutanvändaren när licensiering är ett specifikt avtal med en person eller ett organ, liksom licenspartiet.

Jurisdiktion

Sällan anges uttryckligen, men en viktig kvalificering när det finns lokala rättsliga variationer i IP-lagstiftningen .

Attribut: "Egenskaper", eller aspekter av var och en av dessa enheter, t.ex. för en licens:

begränsningar

Åtgärder som antingen är tillåtna eller förbjudna

Vissa REL separerar dessa begränsningar i grupper, eftersom de troliga värdena för var och en är i allmänhet ojämna uppsättningar (åtgärder som ibland kan vara förbjudna är sällan obligatoriska)

behörigheter
förbud
krav / skyldigheter (eller skyldigheter)

Värden: Värden för dessa egenskaper, från ett fördefinierat ordförråd, t.ex. de fyra friheterna :

Använda arbetet
Studera och modifiera arbetet
Omfördelning av kopior
Omfördelning av modifierade kopior
Skriv ut tillgången

REL definierar medlemmar för var och en av dessa tre grupper och de tillåtna relationerna mellan dem. I exemplet ovan kan det finnas begrepp med licenser , behörigheter och omfördelningskopior . Det kan också finnas förhållanden, En licens kan uttrycka förbud , och separat Tillstånd kan ges till omfördelning av kopior .

Uttalanden kan sedan göras med hjälp av REL (dessa skulle vara utanför själva REL) såsom:

<cc:License rdf:about="http://example.org/licenses/distribution/">
  <cc:licenseClass rdf:resource="https://creativecommons.org/license/"/>
  <dc:title>FooCo's Distribution Permitted Licence</dc:title>

  <cc:permits rdf:resource="https://creativecommons.org/ns#Distribution"/>
    
</cc:License>

Detta definierar en ny abstrakt licens, en som tillåter återdistribution av kopior. Works kan sedan använda denna licens genom att hänvisa till den,

<p>This web page is licensed under <a rel="license" href="http://example.org/licenses/distribution/" 
    >FooCo's Distribution Permitted Licence</a>.

Observera att även om denna hypotetiska licens för "distribution tillåten" har uttryckts med Creative Commons REL, är det inte en Creative Commons-licens. Den använder bara begreppen "Licens", "tillstånd" och "Distribution". Även om det inte är en av Creative Commons-licenser som definierats av det projektet, delar den exakt gemensamhet för dessa termer: "Distribution" har exakt samma betydelse och juridiska definition mellan dem.

Nedanstående W3C ODRL-exempel visar ett avtal (licens) från tilldelningsparten för en tillgång som kan visas av en uppdragsgivare (användare) och en annan för att skriva ut tillgången.

{
    "@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"
    }]
}

Samverkan mellan licenser

Ökande intresse för mashups och samarbetsprojekt skapar en efterfrågan på att kombinera innehåll och på licensieringstekniker som kan stödja detta.

Det enklaste tillvägagångssättet är att bara kombinera innehåll under samma välkända licens. Detta är dock överbegränsande och många kompatibla licenser kan tillåta att deras innehåll kombineras . Det är dock svårt att bedöma detta, om det är tillåtet och hur det resulterande innehållet ska licensieras. Det kan fortfarande finnas finesser när det finns överlappande krav eller Copyleft- problem. Särskilt Creative Commons 'attribution-sharealike' och 'attribution-noncommercial-sharealike' är oförenliga.

Att kombinera licenser är enklare om alla berörda licenser kan uttryckas genom samma REL. I så fall är det lättare att se när ett tillstånd eller ett förbud gäller om de åtminstone gäller en identisk definition av "distribution". Ett uppenbart exempel på detta är Creative Commons-licenserna , där en familj av licenser alla definieras i termer av samma REL .

Även om olika licenser ursprungligen definierades genom olika REL, kan det vara möjligt att omkoda en licens samtidigt i en annan delad REL, vilket gör dem jämförbara. GPL har nyligen uttryckts i ccREL , vilket ger denna fördel.

Svårigheter att samarbeta mellan licenser

Bortsett från frågorna om motstridiga krav (ovan) finns det också tekniska problem i att jämföra licenser. Många av dessa lindras om samma REL kan användas, även om licenserna är olika.

Semantik

Ett regelbundet problem med semantisk översättning mellan scheman (som REL) är att se till att betydelsen av termer är identiska. Även om det semantiska nätet börjar använda ontologiverktyg som OWL för att beskriva betydelsen, är det nuvarande läget för REL mindre avancerat än detta. Enklare bearbetning och risken för dyra tvister annars innebär att semantiken för REL: er måste vara helt identisk, inte bara för att vara sådan genom en resonemang .

De vanliga problemen är att visa likvärdigheten mellan klasser , egenskaper och instanser . För REL är det största problemet för instanserna , dvs. de exakta definitionerna av "Distribution", "Share-alike" etc. Klasserna och egenskaperna är vanligtvis enkla begrepp och mycket lika. Inte alla REL stöder dock alla klasser: vissa ignorerar jurisdiktion eller till och med slutanvändare, beroende på marknadens behov de utvecklades för.

Underförstådda förutsättningar

Ett mindre uppenbart problem vid jämförelse av REL är när de har olika baslinjer. Baslinjen definierar villkoren för licensen när inga uttryckliga uttalanden ingår. Vissa REL: er använder metoden "Allt som inte är tillåtet är förbjudet", andra (såsom ccREL) använder Bernkonventionen som baslinje.

Languages

In other projects