OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

rights-requirements message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [rights-requirements] 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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC