Re: [rights-requirements] Parallel or Complimentary System

[Deirdre Mulligan <dmulligan@law.berkeley.edu>]

Pete -- I agree with your last paragraph. Our initial submission began to do this, and we are continuing to work on it.


Peter Schirling wrote:

> John,
>
> Am a long way from the wonderful colors of fall and won't be back until all
> the leaves are off the tree... : - ((... short note follows.. jet lag...
>
> To the subject at hand:
>
> You bring up flaws in a simplified notion but we need to start somewhere if
> we are to solve this problem. In the end we still need to convert the legal
> interpretations into technology and in this instance it is not a straight
> forward task otherwise we would have had a working solution long ago. What
> you propose as the technical means of resolving rights versus permission's?
>
> I think role and their associated inherent rights are important factors in
> the solution. In any case, one of the 1st things that needs to be done is
> casting "fair use" in technical terms whether as a role or by other
> means... suggestions... proposals please.
>
> Pete Schirling
>
> Digital Media Standards
> IBM Research Division
> Office: +1 802 769 6123/Mobile: +1 802 238 2036/E-Fax: +1 802 769 7362
> Mobile text messaging 8022382036@msg.myvzw.com
> Internet e-mail: schirlin@us.ibm.com
>
>
>                       John Erickson
>                       <john_erickson@hplb.        To:       rights-requirements@lists.oasis-open.org
>                       hpl.hp.com>                 cc:
>                                                   Subject:  Re: [rights-requirements] Parallel or Complimentary System
>                       10/09/2002 04:49 PM
>                       Please respond to
>                       John Erickson
>
>
>
> Thanks, Pete, for this posting last week. Please accept my apologies for
> not
> responding sooner (spontaneous travel to UK, etc, etc)...
>
> Pete wrote:
> > per our conference call this morning, let me frame this notion.
> > I am not going to get hung up terms but try to express the concept
> > of inherent rights versus granted rights and how we might resolve
> > a means to provide technology that can enable each of these. Call
> > it fair use call it rights granted by the US constitution or by
> > EU directive... The notion is:
>
> JSE: The notion of "inherent rights" *may* include one's "role," as Pete
> suggests, but it will also include (as I suggested in another email) the
> context
> and attributes of use. Indeed, in certain scenarios, "role" might indeed
> *not*
> be a parameter for consideration.
>
> I can certainly see why one might consider role as a simplification --- a
> number
> of years ago I proposed just such an approach --- but I'm suggesting here
> that
> "role-based fair use" is an *over-simpliciation*.
>
> > ASSUMPTIONS.
> > 1. Unless there is a continuous connection between provider
> > and consumer, even if it exists it will be impractical to modify
> > an expression on how a digital item can be used each time its
> > "consumer" changes roles and when the expression traverses
> > geographies as well.
>
> JSE: Again, a fundamental problem with this is that Pete is assuming that
> "fair
> use" can be adequately cast as, or reduced to, a role-based access control
> problem --- for example, given an affiliation with a particular group, a
> particular use becomes a "fair use."
>
> He does bring to mind one of the difficulties pointed out in the Dan
> Burk/Julie
> Cohen paper [Dan L. Burk and Julie E. Cohen, "Fair Use Infrastructure for
> Copyright Management Systems,"
> http://www.cfp2002.org/fairuse/burkcohen.pdf] ---
> that of *spontaneity*. The risk that transactional approximations of fair
> use
> have is that they fail the spontaneity test if the client isn't networked
> when a
> decision needs to be made (and the applicable policies are not resident on
> the
> machine). Thus we have to consider the notion of somehow capturing policies
> ---
> policies expressed using an REL --- that adequately evaluate. These would
> of
> course be based upon conditions (attributes describing context of use, etc)
> that
> must somehow be gathered.
>
> An interesting aspect of Pete's assumption is that, if he didn't assume a
> role-based simplification, he wouldn't necessarily have this problem.
> Again,
> this is the question of what the attributes of the usage are, not simply
> (or at
> all) who the user is, even their role...
>
> > 2. Roles are important when dealing with inherent rights. As expressed
> > today the role of teacher vs consumer, production executive vs consumer,
> > etc have inherent rights and for expressions to embody all possibilities
> is
> > also not practical. Each of us changes roles several times each day from
> > worker, to digital item creator, to consumer, to parent to.... and the
> list
> > goes on
>
> JSE: Role-based authorization is certainly important --- indeed, critical
> --- in
> doing distributed "DRM" correctly; it is arguably a superior approach for
> DRM
> applications serving the enterprise and for inter-organizational
> requirements,
> especially within the research and education communities.
>
> But, again, it is not clear that "role" is an acceptable surrogate for a
> particular use, aspects or parameters of which might have been
> unanticipated
> (which must be one of the entry points for making a "fair use"
> determination).
>
> > POSSIBILITIES
> >
> > 1. define a complimentary set of expressions to those currently under
> > consideration (or maybe we have what we need and its only the context
> that
> > changes) and the behavior of an associated "enforcement" function that is
> > bound to a person. Allow it to define roles that that person plays, such
> as
> > children, parents, teacher, office manager, ticket agent etc... and
> define
> > inherent rights associated with each role. This will vary some not only
> by
> > role but by native geography.
>
> JSE: First, again, simply going to "role based" is not the answer to fair
> use or
> to other copyright limitations.
>
> Second, if the role-based capabilities Pete describes are *not* present in
> the
> REL in the first place, I would argue that it is a not sufficiently
> flexible
> "access control language..."
>
> > 2. The enforcement function would then be responsible for resolving
> > rights/permission (whatever) expressions delivered with the digital item
> > verses inherent rights and thus what can or cannot be done with a digital
> > item.
>
> JSE: This is an important notion. This also ties into the David Parrott
> document
> that was sent to the w3c-drm list
> two weeks ago [David Parrott, "When is a Right not a Right: When it is a
> Permission"], esp. the part in which Dave describes a possible
> implementation of
> the policy-based enforcement mechanism I was talking about in my 2001 Dlib
> article [John Erickson, "Fine-grained Policy Enforcement for Digital
> Information
> Objects"].
>
> | John S. Erickson, Ph.D.
> | Hewlett-Packard Laboratories
> | PO Box 1158, Norwich, Vermont USA 05055
> | 802-649-1683 (vox) 802-371-9796 (cell) 802-649-1695 (fax)
> | john_erickson@hpl.hp.com         AIM/YIM/MSN: olyerickson
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

--
Deirdre K. Mulligan
Acting Clinical Prof. and Director
Samuelson Law, Technology and Public Policy clinic
Boalt Hall
University of California
346 North Addition
Berkeley, CA 94720-7200

v 510.642.0499
f 510.643.4625
dmulligan@law.berkeley.edu
http://www.samuelsonclinic.org