[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC