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

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

Title: RE: [rights] Rights vs. Permissions

Patrick,

        Thanks for helping focus the issues.  It seems that we have located the root of our disagreement.  You believe that fair use and permissions can and should be expressed in a single language, and you have no proof that it can and I have no proof that it cannot.  Absent a definitive answer to that question, we need to decide what to do with the permissions language we have.

        My bet is that permissions can form a valuable PART of something.  I'm coming from the perspective that I think even a permissions language is a lot more complex than a "simple vendor solution."  But, I do have a solution in hand, one that was developed over a long course of time, that I think can be a well-defined self-contained whole PART of some system (along with, of course, other parts designed to address fair use and many other problems).  I also do not see any reason to withhold agreement on such a well-defined self-contained whole part just because other parts need more work.

        On the other hand (and correct me if I am wrong), you explain that you think that a permissions language is not a part of anything (rather it is only a part of a part).

&Thomas

-----Original Message-----
From: Patrick Durusau
To: DeMartini, Thomas
Cc: Rights-Requirements (E-mail); Rights (E-mail)
Sent: 10/1/2002 1:06 PM
Subject: Re: [rights] Rights vs. Permissions

Thomas,

Thanks for the detailed response! I don't agree with it entirely
(surprise!) but I do think it helps focus the issues before the SC/TC. I

have interposed comments while retaining your entire post (even thought
it makes this longer) so as to retain the context of your remarks and my

replies.

DeMartini, Thomas wrote:

> 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.
>
For purposes of this dicussion, using the definitions as suggested, I
think placing "fair use expressions" out of scope illustrates the
problem of a permissons only language. Such a language, one limited only

to permissions, is incomplete and as I attempt to show below, inadequate

for its intended purpose. (Separate and apart from the issue of not
expressing fair use and other "rights" which I will comment on shortly.)

>         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.
>
May need a forth group because I don't understand why a language could
not be expressive enought to cover both permissions and fair use.
Admittedly I have not created such a language but wonder about the
assumption that since a permission model (and proposed language) exists,

that somehow means that another language that is a superset of
permissions could not include fair use. Noting that we have yet to even
agree on the requirements for the language (whatever name it is given)
it seems premature to assume that we could not devise a language that
covers both permissions and fair use (using fair use as only an
example).

It would require the same modeling process and definition of
requirements that was followed for the proposed permissions language but

that would be the only way to really resolve the issue of whether such a

language could be written. (If someone has a theoretical proof that fair

use and permissions could not be expressed in a common language I would
appreciate the citation. I doubt such exists since in hard to read
prose, a variety of legal statutes and agreements exist now that have
precisely that result.)

>         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.
>
This is very close to the core of the problem, at least in terms of
distinguishing a permission from a right. It is not an issue of
convenience at all. If the content is made known to me at all, I can
certainly type it in on another screen, write it down or repeat it over
the telephone to someone else. But fair use is more than something
allowed by the application.

For example, take a user who has purchased a text and it is now on their

computer. The permissions allow the user to view and print the text but
only as shown (this is one reason academic publishers like PDF, they
think the display of text is meaningful. Maybe so but you would have to
start with meaningful text at the beginning). In terms of "fair use" I
would contend that the user is free to make a copy of the entire work
for re-display on his/her computer using a larger text display than
available in the application or to even convert the text for processing
by a text-to-speech application. (None of this has anything to do with
the application or its abilities. The user has a "right" to do these
things since he lawfully has access to the resource. If someone wants
their computer to sing stock quotes that would certainly be "fair use"
even though it would not be very pretty.)

Note that the user, now or after XrML does not need a "permission" to
perform either of these activities, even though they are "copying,
duplicating, etc." the entire work. They have used a resource which was
duly licensed from the content owner. Once they have the "permission"
for access, then the issue becomes what can they lawfully do with the
licensed resource. To reach the first step without the second, brings me

to why I think the partial solution is a bad one for vendors.

A "rights" language (here used in the sense of the broader approach that

I am advocating) that does not have fair use expressions to allow
precisely that sort of activity places the commercial vendor in an
awkward position. It is possible to construct a permission that allows
all possible activities after the point of sale but then there is hardly

any reason to have a permission language. Correct? On the other hand,
vendors don't want to alienate users (or provide the support lines) by
imposing strictures that prevent activities that users expect as a
"right" after purchasing a resource.

I think the problem more generally with permissions is the early focus
on the requirements of too narrow a community in reaching the conclusion

that a permissions language is "good enough" for now. Thinking about my
cable provider or perhaps a producer of video tapes (now DVDs I guess)
the model and permissions that they need are fairly narrow. But that
model, particularly the notion of permissions, which admittedly works
fairly well in a point-to-point system with a single provider (or a very

small number) or perhaps even with video media but that is not the focus

of this TC.

>         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."
>
On the contrary, it is not now nor has it ever been the contention of
the SBL that some DRM applications might be as convenient as possible.
Users, do have rights, not defenses but actual affirmative rights,  and
those rights, of which "fair use" is only one, are not possible to
express in the proposed permissions language. The inability to express a

"fair use expression" of necessity burdens those who would claim it with

originating a language for its expression and getting it adopted.  The
TC by its "permissions" language has chosen to favor only one side
(actually only one segment of that side) in a much more complex system
of relationships. I understand the desire to say: "Well, we have what we

want so if you want something different, you better get to work." The
problem with that approach is what has been offered is broken even from
a vendor standpoint, in addition to ignoring the legitimate requirements

of the consumers of digital resources.

The lack of "fair use expressions" is an example of using a model, in
this case permissions, that may work quite well for the MPEG community
and applying it across the board to all DRM applications. Is there some
reason why the needs of MPEG are thought to be generalizable across all
other commercial communities? (leaving aside all thought of users for
the moment) It may be the case that the MPEG community has thought
longer and harder about this issue than any other, but that in no way
means that a model for MPEG is desireable or even useful for other
commercial domains. (My personal suspicion is that is it not, given the
ususal divergence of requirements between business communities but that
is something we can settle only by actively soliciting requirements from

various communities.)

All I am asking for is a full discussion of the requirements of all user

communities, not just MPEG or the fledgling ebook folks but the health
care industry (hardly a minor player in information resources), legal
services, libraries, digital information providers, and, yes, users as
well. From those requirements, the TC can develop a model for a "rights"

(in the broader sense) language and then build a standard for it. As you

have noted, the permissions part is fairly well developed so that should

make it easier for the TC to make rapid progress on the the remaining
concerns. We won't make any progress if we keep arguing about whether a
solution for MPEG is or is not a solution for everyone in the absence of

a comprehensive set of requirements and a model built upon those
requirements. It may well be that some requirements cannot be satisfied
in any deterministic language but that cannot be decided in the absence
of real work.

I realize that a model for MPEG is ready to go with a language for it. I

wish them well but see no reason to priviledge a solution for MPEG over
all other communities. If they want a strictly permissions language and
the shortcomings that come with it (in my opinion) then they can simply
adopt what they already have in place. It will cost them later when they

switch to a more robust language from this TC but that is the peril of
having a partial solution to a complex problem.

Patrick

> 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 >
>

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