[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [rights] Comments on Requirements version 16
Comments on RLTC Requirements Version 16, last modified 11/26/2002 Comments from: Anne Anderson Comments date: 15 January 2003 These are all comments I have made in meetings, and that others have made, but I will reiterate them here. 1. "Thus, in this document we use the words equivalent to the marketplace concept of rights: permissions granted by one entity to another." This is NOT the "marketplace concept of rights". A "right" is something that I have intrinsically, not something that someone grants to me. For example, the "right to life, liberty, and the pursuit of happiness". The Bill of Rights is a recognition of certain rights, not a granting of rights. From the American Heritage Dictionary, the definitions that are most applicable (as a noun): "1. That which is just, morally good, legal, proper, or fitting. 5. Something that is due to a person by law, tradition, or nature. 6. A just or legal claim or title." 2. 'the technical work of the RLTC is *not* directed to... Develop a language or system that addresses legal rights and processes. Examples of these rights include, but are not limited to, those legal rights termed as "fair use rights" and contractual rights.' As a key Internet standard in various architectural models, the output of the RLTC MUST be comprehensive enough to ensure that the various applications of the standard will not interfere with or subvert legal rights such as "fair use rights". If the key standard in this area does not address these issues, then consumers will be forced to participate in, argue with, or litigate against every extension to this core standard that makes it useful in real applications. Consumers collectively are a large group, but their direct benefit from working on any particular standard is small. Entities with no interest in consumer rights, but who can benefit from restricting consumer rights are a small group, and their direct benefit from working on any particular standard is very large. The argument has been made that the developers of the "rights" language are not able to know all the legal rights that users may have in various domains. This is not a reason for failing to address protection of these rights. Protection could be provided in various ways. Just to give one example, the RLTC could specify a template for a required extension that MUST be tailored to and included in any conforming application. The template could spell out examples of rights that must be protected, and specify that any of these that apply must be included and that any additional rights pertinent to the application domain must also be added. The RLTC membership includes an incredible legal resources for contributing to any possible solution to this problem. The argument has been made that no rights language can technically protect traditional legal rights such as fair use. If this is true, then no rights language should be used, and particularly should not be standardized. Just because the technical means exist for one party to protect its rights in such a way that another party's rights are violated does not mean that those technical means should be used. Standardization confers the support of all approving parties upon the language, protocol, etc. that is being standardized. When the language, protocol, etc. benefits only a small community and harms a large community, then the benefits of standardization should not be granted. 3. The proposed language can probably not be implemented, at least in its targetted domains, in a way that does not infringe upon intellectual property claims. The owners of that intellectual property have offered only RAND terms for licenses to that intellectual property. Approval of a standard that requires payment of license fees for IP effectively grants a monopoly to the owner of that IP, while providing no protection to the community against mis-use of that monopoly. "RAND" has no legal meaning. It offers no protection to the community against the imposition of prohibitive license fees. RAND has been used in the past to extract increasingly more onerous fees as the associated standard has become more widely adopted. Any key Internet standard must be freely implementable. Interoperability requires that all parties that wish to participate in the Internet must implement key standards. Any key Internet standard that requires payment of unspecified license fees will be a detriment to the development and use of the Internet. The argument has been made that the developers of a standard can never know who holds IP claims that might be asserted. That is true. But where clear IP claims *are* known, and where RF licenses to that IP are not offered, any standard that a large proportion of the Internet community will be forced to implement and utilize must be designed around those known IP claims. If it is not possible to design the standard around such known IP claims, then the standard should not be approved. -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC