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

[Patrick Durusau <pdurusau@emory.edu>]

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