Re: Generic permissions and prohibitions

The list of prohibitions in a licence document is never exhaustive (and depending upon circumstances, may prohibit things which legally you cannot prevent somebody from doing - depending upon jurisdiction).

Even if you want to restrict things to talking only about those terms in the ODRL vocabulary itself (which you shouldn't), that amounts to an arbitrary bag of possible permissions.

Interpretation of a licence statement, be that in natural- or logical-language, can only operate on the basis that:—

(a) there is a starting state (as defined by the legal context)

(b) anything not specified in the statement is undefined by the statement

(c) [some of the things which might be prohibited by the licence will not apply]

We'll ignore (c), because it's not going to affect most applications.

The starting state is going to be, in effect, 'you have permission to do nothing' (it's much more complicated than that, but it'll do for most commercial applications).

A licence then grants you permission to odrl:give.

Given a query of 'can I odrl:sell this?', the answer is 'no', because the licence did not modify the starting state.

Now, as it stands, a query of 'can I odrl:lend this?', the answer is *also* 'no', and I leave it up to somebody cleverer than me to decide whether the implications of the actions need to be better captured in the specification, or whether each application is going to end up doing it differently.

[Side-note: it might be interesting to attempt to model the copyright exceptions granted in various jurisdictions using ODRL itself (such that (a) above is an in-built set of ODRL permissions which are added to an empty set; at some point somebody will need to actually implement something like this...]

M.

> On  2014-Jun-03, at 06:51, Alapan <alapan@gmail.com> wrote:
> 
> Hi,
> 
> Yes - we discussed this a number of years ago; and I also had a paper on the logical model around permissions and prohibitions [1].
> 
> The problem arises because there is a difference between the license (as expressed in ODRL) and the interpreter that enforces the license. There are three sets of actions:
> a) Actions that are explicitly permitted
> b) Actions that are explicitly prohibited
> c) Actions that are not specified
> 
> For the last set, this can be broken to two further classes:
> i) Actions that are not specified but in the dictionary of defined possible actions
> ii) Actions that are not specified and also not in the dictionary of defined possible actions
> 
> My basic proposal was that, on interpretation of the license, the enforcement should be on the basis of:
> 1) Permit - a and c (ii)
> 2) Prohibit b and c(i)
> 
> This should be specified as one of the requirements of the interpretor/enforcement engine. Perhaps this should be added as part of the ODRL specs also?
> 
> Regards,
> Alapan
> 
> [1]: Arnab, Alapan and Andrew Hutchison (2007) Persistent Access Control: A Formal Model for DRM. In Proceedings Seventh ACM Workshop on Digital Rights Management (ACM-DRM). Non paywall link: http://pubs.cs.uct.ac.za/archive/00000411/

> 
> Blog: http://idiots-mind.blogspot.com/

> -------------------------------------------------------------
> Life's a gamble - take a chance
> 
> 
> On 3 June 2014 06:13, Renato Iannella <ri@semanticidentity.com> wrote:
> 
> On 3 Jun 2014, at 02:03, Michael Steidl (IPTC) <mdirector@iptc.org> wrote:
> 
>> Example: a permission to use a photo for printing is granted by an ODRL policy. This policy includes the single permission and nothing else.
>> This raises the question – at least for lawyers: what about all the other actions in the ODRL vocabulary (and maybe beyond it)? Are they implicitly prohibited?
> 
> I can recall discussing this on the list (many years ago)...but reviewing the current Core Model, I can see no explicit statement.
> 
> The general idea as that you can only do what was explicitly stated, and nothing else
> 
> Even in Version 1.1 we had "A Permission that is not specified in any Rights Expressions is not granted"
> 
>> To solve this issue I see two options:
>> i/ To write down in the ODRL specs that the default state is: “nothing is permitted”, only explicit permissions lift that. The exact role of a prohibition in such a context would need a good explanation.
> 
> Yes, we should do this.
> 
> Cheers...
> Renato Iannella
> Semantic Identity
> http://semanticidentity.com

> Mobile: +61 4 1313 2206
> 
> 


-- 
Mo McRoberts - Chief Technical Architect - Archives & Digital Public Space,
Zone 2.12, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA.

Inside the BBC? My movements this week: http://neva.li/where-is-mo

Received on Tuesday, 3 June 2014 07:36:56 UTC