[rights-requirements] RE: [rights] Rights vs. Permissions

["DeMartini, Thomas" <Thomas.DeMartini@CONTENTGUARD.COM>]

Title: RE: [rights] Rights vs. Permissions

Patrick,

        Your description of "permissions" seems right on.  It is heartening to know that I wasn't completely off-the-wall when I made the assertion that I think the terms in the requirements document are sufficiently clear to know what we are talking about, though I certainly felt that way after the requirements call.  "Permissions" seems to be the best word that means the same thing to the most people to describe what we are trying to do.

        As far as "rights" go, however, I don't think we can ever reach agreement on a definition, not because I don't want to, but because it is just much too overused and misused in everyday language.  To make this a little more concrete, consider your example of the person who has the basic cable package.  As you point out, if you ask most people if they have the "right" to see ALL of the channels, they will say no.  However, if you ask most people if they have the "right" to see the basic channels, many will tell you "yes, I paid for them, and I have the right to receive the service I paid for."  But, this is actually a "permission," which people also refer to as a right.  On the other side of the spectrum, some legal experts assert that fair use is actually a defense and not a right at all.  So, the term "right" COULD mean the same thing as "permission," if you talk to the correct people.  It could also mean a lot of other things.  Knowing this, MPEG (this issue had come up there before, btw) thought very heavily about changing the name to a "permissions expression language."  In the end, they opted to leave it as a rights expression language, with the understanding that what were meant were permissions.  The idea, it seems, was that the term "rights" was already heavily used to refer to this kind of technology.  I'd like to adopt the same understanding here (at least for the purposes of this letter so that I can speak clearly): "rights" is o.k. for names, such as the name of the language, but not for discussions of functionality like requirements and scope.  I'd like to use "permissions" (which at least you and I seem to understand) to indicate the scope in the requirements document we have been seeing, and the term "fair use expressions" to indicate (one of) the other expressivities you think this language should have.

        You write, "part of my concern...is that a 'permissions' model is being used to define [fair use]."  I don't think the goal is to "define" fair use.  The scope is to provide a language for writing permission expressions.  To be parallel for fair use, I think the proper phrase would be to provide a language for writing "fair use expressions."  In other words, I think what you mean to say is that part of your concern is that a 'permissions' model is being used to write fair use expressions.

        In response to this, let me say that, if it were up to me, the scope would not include "fair use expressions."  Permissions are best expressed in a permissions model.  In order to write "fair use expressions", whatever those are, one would likely need some other model, which could easily form the scope for some other language that would be free to concentrate on defining a language for "fair use expressions" without having to worry about defining a language for permission expressions.

        Part of the confusion/frustration on my part is that I hear a) one group of people yelling that fair use should be included because it is a natural fit for this permissions model and b) another group of people yelling that fair use is not a natural fit for the permissions model so we have to change the model into some unspecified thing.  And all that time the two groups seem to be agreeing with each other and many people happen to be members of both groups, which is completely puzzling to me, sitting here on a third side, agreeing that fair use is not a direct match and concluding that it ought to comprise its own language when people figure out what a "fair use expression" is and how it is supposed to be used.

        You write, "while I can understand the flustration of early participants in this process with the current state of the TC, I think some of that flustration can be attributed to simply under estimating the complexity of constructing a [fair use + permissions] language (as distinguished from an ex parte permissions language for a vendor)."

        On the contrary, I think the founding members (well, I, at least, though I think I speak for others as well) did not underestimate the complexity of such a language one bit.  In fact, it is because of this complexity of doing both fair use and permissions that I liked the XrML approach, which limited the scope only to the permissions aspect.  At the time, it seemed to me that that was a reasonable scope (a piece of a much larger picture) that could easily be agreed upon and progress made, regardless of how people saw the larger picture.  However, judging from the requirements call last Wednesday, it seems I was terribly mistaken there.

        You write, "even if the TC were to declare that it really meant 'permissions' where it uses the term 'rights,' I don't think that solves the problem. Still using the TEI example, a 'permissions' language that cannot express my right of 'fair use' either forcloses a [fair use] right that I have separate and apart from any 'permission,' which may lead me to seek another provider of the information, or, forces the information provider to go outside the 'permissions' language in order to allow that right to be exercised."

        There seems to be this idea held by some and not held by others that the existence of a "permissions language" "forecloses" a fair use right from being exercised.  This is not the case at all.  You can still look at your screen and type in another window that paragraph you wanted to extract from the TEI Guidelines.  I can't envision anything in a "permissions language" (or even any DRM application, for that matter) that could prevent that.  Some DRM applications might not have a copy-to-clipboard feature, but that is strictly a convenience issue at this point.  (In fact, often times I find the clipboard a bigger burden anyway because of all the formatting and styles that get copied along with it.)  Analogously, some photocopiers don't copy documents printed on green paper very well.  That doesn't mean I can't still retype the information on my typewriter into my report rather than photocopying it into my report.  If I really do think it is important to photocopy it rather than retype it, I can use a better photocopier.  Likewise, if it is really important to you to be able to copy-paste that paragraph rather than retype it, you can use a better application.

        To sum up, it seems that some people have a legitimate concern that some DRM applications may not be as convenient as they would like.  Using logic not yet explained they have determined that the cause of that problem is the existence of a rights language that expresses permissions, and have then proceeded to request that the only solution in their mind to that problem be added to the scope of a rights language: being able to write "fair use expressions."  It would seem much more constructive to me if the concern were left where it originated, with the convenience of DRM applications or with the need to develop a "fair use expression language," and not mixed into the work on a "permissions language."

Thanks,
Thomas.

-----Original Message-----
From: Patrick Durusau [mailto:pdurusau@emory.edu]
Sent: Wednesday, September 25, 2002 3:35 PM
To: Rights-Requirements (E-mail)
Cc: Rights (E-mail)
Subject: [rights] Rights vs. Permissions

Greetings,

One of the comments today about the lack of a definition of "rights" in
the requirements document brought something into focus for me that I
think I had felt but had not expressed very clearly. (Note that the
following is an attempt to be descriptive and not prejudicial so with
hold flames until you reach the end.)

The comment was made that there is no definition of "rights" in the
requirements document and the response, as I heard it, was the
requirements do talk about permissions (R04, Specifying Permissions)

When I hear the term "digital rights," I hear it as something completely
  different from "digital permissions." A permission to me is something
that is granted by (at the sufferance if you will) of some particular
party, usually in favor of another specific party. Permission to use a
particular software program, usually conditioned on payment of a fee,
for example, is something that I would use to illustrate the word
permission.

On the other hand, "digital rights," that bundle of things that I can do
in the absence of any permission and in fact can do even if anyone
wishes that I would not, I would not think of as including any of the
things that are covered by permissions.

By way of example, I have "permission" from my cable provider to use the
  cable connection into my home for basic cable channels. I do not have
permission to view ShowTime (I assume it is offered, I don't watch a lot
of TV) on that same connection. But if you were to ask me if I had a
"right" to see anything on cable TV in everyday conversation, I would
say no. (Leaving to one side the issue of "fair use" for copying a
program for later viewing and other "rights" type issues.)

I have a right to "fair use" which I used earlier today to copy (in the
sense of moving text from a webpage into a document I was authoring) an
example from the TEI Guidelines, which properly attributed the source
and was in fact about a quarter of a page of material from a 1,000+ page
document. That right was not granted by the TEI Consortium and assuming
what I have done is within the scope of "fair use," they cannot complain
about my use of that material.

Part of my concern, aside from the procedural issues which I have voiced
in the conference calls and in writing (including the definition of
terms, which was also raised in the SBL submissions to the Requirements
SC), is that a "permissions" model is being used to define "rights."

The charter that everyone seems so fond of citing says in one of the few
  undisputed portions that:

****
The language needs to be:
Comprehensive: Capable of expressing simple and complex rights
Generic: Capable of describing rights for any type of digital content or
service
****

I may be reading the charter too literally but it appears that by its
terms it should cover the activity I described above of copying a
portion of the TEI Guidelines into another document. And that
description would be of a "right" as opposed to a "permission," at least
as I understand the terms.

Even if the TC were to declare that it really meant "permissions" where
it uses the term "rights," I don't think that solves the problem. Still
using the TEI example, a "permissions" language that cannot express my
right of "fair use" either forcloses a right that I have separate and
apart from any "permission," which may lead me to seek another provider
of the information, or, forces the information provider to go outside
the "permissions" language in order to allow that right to be exercised.
In either case, the "permission" language becomes a detriment to the
provider and in the former case an unwarranted restriction on the user.

While I can understand the flustration of early participants in this
process with the current state of the TC, I think some of that
flustration can be attributed to simply under estimating the complexity
of constructing a rights language (as distinguished from an ex parte
permissions language for a vendor).

Patrick

--
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>