Re: 'right' vs 'permission'; was: RE: [rights-requirements] Parallelor Complimentary System

[John Erickson <john_erickson@hplb.hpl.hp.com>]

ThomasD wrote:
> In order to answer this question, let me first add some context
> from your original e-mail:
>
> "If pressed I would hazard that at least one way to distinguish
> rights and permissions is: Do I have to ask before I can do some
> particular action? If the answer is no, then we are talking about
> a right. If the answer is yes, then we are talking about a permission."

JSE: This is consistent with e.g. AAP policies, which essentially say that
"permission is required in order to use the works of others, unless the use can
be considered a fair use or the work is in the public domain..." Permissions are
administered by the party holding the rights (publisher or author) or an agent
for that party.

> The thing to realize is that if the answer is no (what you call
> rights) then we don't have any communication.  And, if we don't
> have any communication, then we don't need a language.  And, if
> we don't need a language, then it is not in the scope of a language
> technical committee.
>
> On the other hand, if the answer is yes (what you call permissions),
> then we have communication.  And, thus, need a language.

JSE: The problem with this is, in the case of DRM there is almost always an
*implicit* communication --- a "communication" that happens prior to the user's
use and without their knowledge. Examples include:

* "permissions" that have been implicitly been "built into" the DRM VM

* "permissions" that are explicitly expressed, but have been implicitly "shipped
with" the DRM VM/language interpreter and are generally applied (e.g. for a
broad catagory of objects, users and/or platforms). These could either augment
or be superceded by rights that are "requested" by the user.

* "permissions" that are explicitly expressed, but have been implicitly "shipped
with" the content (e.g. "asttached to") and are generally applied (e.g. for a
broad catagory of users and/or platforms). These could either augment or be
superceded by rights that are "requested" by the user.

* "permissions" that are explicitly expressed in response to a request that the
user is responsible for (e.g. taken some action in a rendering client to
trigger).

Ultimately, the usage control that actually affects the user experience (and
that the rightsholder can expect or demand to be applied to their deployed
material) will be the "summation" of controls exerted above. Because of the
limitations of "hard-coded" policies (the first bullet, mostly), it is
increasingly likely that system designers will opt for explicit policy
expression --- i.e. a "rights" language" --- at any point that control must be
exerted.

My point then is this: in the case of explicitly expressed usage rules, there is
*always* a "communication" --- just a question of when and who is responsible
for it...

John