On Sun, 8 May 2005, Bob Wyman wrote: +1. In spirit, I think I agree with what Bob says below. My mistake, in trying to agree with Bob's statement that DRM "is a snake pit" [1] lead me to overreach and say unnecessary things about DRM. I also support the foundation of law with respect to IP, and even if I disagree with some particulars, I respect its force.
[1] http://www.imc.org/atom-syntax/mail-archive/msg13896.html Clarifications and qualifications appear inline: > > First, let me say that I am a *very* strong supporter of > intellectual property rights... I have always made my income by "selling" my > intellectual property and I consider the anti-IPR proponents and "Free > Software" evangelists to be no better than thieves or communists... Also, I > am listed as sole inventor on four patents dealing with DRM and I have a > number of pending applications in the works today... Having said that: Personally, I would wear none of the labels "anti-IPR proponent", "thief", or "communist" agreeably; even if I allow that communism is to be allowed as an experiment, the experiment seems largely to have failed. But: enough of this! and Bob is to be forgiven for responding to some words which I should not have uttered. I apologize, Bob. > > If writers and publishers are provided with mechanisms to attach > "rights" or DRM-like information to Atom entries or feeds, we are likely to > discover that they will mistakenly assume that software will actually take > some note of their statements and use those statements while processing > entries. I believe, however, that it is exceptionally unlikely that Atom > processors will, in fact, process such rights statements. I agree that Atom processors will not (properly) process rights statements, whether the term 'atom:copright' or the term 'atom:rights' is used. Furthermore, I fail to see how Atom processors reasonably could be enjoined to properly process rights statement if the assumption be that "properly process" means compliance with legal norm in various jurisdictions. No way: it's never been done before, to my knowledge, even in commercial DRM software. I therefore concur with Bob that the Atom spec should include some statement of the kind he proposes: "Publishers MUST NOT expect that processors of atom feeds or entries will, in fact, modify their behavior based on any content provided in or linked to by this element." I agree with this no matter whether the name of an/the element (attribute) be "copyright" or "rights" or something similar. > There are many > reasons for this and I've outlined them in numerous posts in the past. The > most important are: > 1) There are no useful, open and unencumbered standards for > expressing limitations to rights in a machine readable fashion. (Note: CC > does *not* support "limiting" rights.) Granting that CC is in no way a standard, and that its chief role is not to express prohibitions against use (otherwise granted as right), I probably agree, if "unencumbered" means "nowhere on the radar screen of any pure-play DRM company in search of possible patent infringement." Therefore, I advocated no use of any such (putative) standard. > 2) The DRM space is carpeted with patents and it is unlikely that > people will find an unencumbered DRM method for at least another 10 years or > so. Very possible, and for this very reason, some LARGE corporate bodies are seeking to deploy access/security/rights solutions using unencumbered specifications like XACML and SAML (and others) in place of the "DRM methods" where minefields hide 20 patents per square inch. > 3) Authors and publishers are notoriously bad at understanding the > legal implications of what they are saying concerning IPR and will often > limit rights more than they expect. Thank you! I agree. Many people will not understand what is meant, in the large, if some explicitly declares (rather than leaves implicit) <copyright>Copyright (c) 2005 John Q. Public</copyright> Creative Commons, now being internationalized to respect different legal conventions, was designed to counter *precisely* the problem Bob identifies: that people (using 'copyright' statements) indeed "limit rights more than they expect." And Creative Commons strongly disavows any interest in DRM: its goal is to encourage permissions, not rights limitations. This is one of the reasons, though not the chief reason, why I would not approve of a specification that provided the <copyright> element and **no other markup element** as the sole authorized/structured/labeled means for an author to declare that his/her work "may be used freely". > 4) The cost of upgrading every Atom processor to handle rights > "properly" and without legal risk will make it virtually impossible for > people to build the kind of quick-and-dirty processors that exist today. > (i.e. before you could release your latest PHP-hack, you'd have to get legal > review...) Agree: I cannot imaging Atom processors being equipped to properly handle rights "without legal risk"; that includes processing of content in the <atom:copright> element as well as content in any similar element like <atom:rights>. > 5) We'll make it legally dangerous to build software that *reads* > Atom feeds. Thus, it will only safe to write software that creates Atom > feeds. The result will be reduced innovation in the space and potential > domination by a small number of "feed readers" who are able to demonstrate > legal compliance. I'm not sure what Bob fears as being legally dangerous: legal danger comes into play, as far as I can see, more from <atom:copright> than from <atom:rights>, if any legal danger is material. An explicit statement in the Atom spec indicating that "processors are not required (SHOULD NOT, MUST NOT be required) to read and act upon possible claims in the xxxx(copy(rights)) element" should be adequate. > 6) We're likely to "pollute the stream" by creating a babel of > rights languages and legal traps that will choke off the Blogosphere. In my opinion, the Babel will begin if the Atom spec is delivered without any clear provision for users to clearly express their intentions and preferences with respect to (re-use) of Atom documents on the web. Giving them an appropriately-labeled element and a URI reference ("for further information") is a reasonable beginning. > 7) We risk a situation where some aggregator will obtain preferred > access to an encumbered DRM technology and then evangelize its use among > authors and publishers. The result might be that all feed readers who don't > use the method are forced to either go out of business to avoid the legal > attacks of irate users or they will be forced to pay license fees to the > patent holders. This would not be difficult to orchestrate... I don't understand the ingredients which make this risk palpable, but if it's a real threat, it's a threat no matter what the Atom spec prescribes and proscribes. Generic-label markup elements will not create this risk. > We should studiously avoid encouraging people to believe that > software management of rights is possible in the open internet until some > time in the future when someone identifies a formal standard which is > demonstrated to be unencumbered by patents. Agree 110%. And for this reason, among others, the Atom spec should be clear that it does not intend to support "software management of rights." On other hand, I believe that the right to express, in English or in any natural language, or in equivalent straight-forward markup notation, one's preferences and intents about the use of digital content -- has to be a foundational human right. If we believe it has become legally risky to declare our intent and our wish, we have forfeited our right to live in a free society. > If people really insist on providing more encouragement to the > "rights management" folk in the Atom spec, then let us *please* include > something like the following in the specification in order to discourage > people from believing that processors will actually head the content of > their DRM statements: > > "Publishers MUST NOT expect that processors of atom feeds or entries > will, in fact, modify their behavior based on any content provided in or > linked to by this element." I've seen no evidence of "rights management" folk near the Atom spec -- and I certainly do not qualify. I agree that some kind of statement like the above should be used to clarify expectations about any kind of (copy)rights expression used in Atom documents. Cheers, Robin > > bob wyman > > > --
