I think the discussion around this has been absolutely excellent. Lots of very good information and perspectives. At this point I need to stew over things for a few days and think about how to proceed with the extension.
In addition to the several technical changes that I may end up making to the specification, I am thinking now that a detailed description of the non-technical issues surrounding this spec would be a great addition to the document. I'm just not sure I'm qualified to write such a thing myself. - James Bob Wyman wrote: > John Panzer asks of Karl Dubost: >> (Let's say that Doc Searls somehow discovers a license that >> would deny sploggers more than implied rights to his content >> while allowing liberal use for others[1], and deploys it. >> Are you saying that all of his readers' feed software would >> have to drop his feed content until they're upgraded to >> understand the license?) [1] http://doc.weblogs.com/2006/08/28 > I think John's question can be (aggressively) rephrased as: "Can Doc > Searls, by inserting a license in his feed, 'poison' the entire syndication > system that we've built over the last few years?" (i.e. Can he do things > that make it unsafe or illegal for people to do things which the syndication > system was intentionally built to permit and which he knew were being done > before he willingly inserted his content into the syndication network?) I > don't think so. > As argued in other messages, I strongly believe that we should not > do anything that hinders or conflicts with the establishment or recognition > of a limited implied license to syndicate content which is formatted using > RSS/Atom and is made openly available on the network. (An interesting > question, of course, would be: "What does it mean to 'syndicate'?") > In any case, there is a general problem of "proper notice" here. As > mentioned before, there is nothing special about an optional IETF protocol > extension. This subject of inserting licenses in content should be discussed > in a general sense -- not limited to this specific protocol extension. > A vital question to ask is: What is proper notice of the presence of > a license? No IETF standard has the force of law. Readers are not obligated > to understand or even take note of the license links. Thus, no one using it > should be able to have any expectation that readers will take note of it any > more than they would of many other possible means of inserting licenses or > references to them in content. Publishers and consumers should both be > working on the assumption that normal copyright exists (i.e *all rights > reserved*) except where there are fair use privileges of implied licenses > that weaken the *all rights* default.) > If we were to allow or encourage any one mechanism to associate > restrictive licenses with content, we establish a precedent that would allow > or encourage others as well. Any other "standards group" or informal > collection of one or more persons could decide to define a new mechanism -- > just like the IETF did. At that point, no reader could safely consume > content since no matter how many mechanisms they supported there might be > some others that they didn't know about. The issue here is about proper > notice... How can we obligate folk to respect licenses that they have no > means of discovering? > We should also ask: "At what point does a restrictive license become > operative?" Imagine that I decided that reading (copying) of my feeds by > commercial organizations was to be prohibited. Could I bar such copying by > putting a license in the content itself? Of course, if I did, that means > that in order to discover that copying was not permitted the reader would > have to actually do the thing which is prohibited. Clearly, even if there > was some way to put effective restrictive licenses in content, there would > have to remain some "implied license" exceptions to the *all rights" > provision of copyright. > We are all best served by an assumption that copyright leaves "all > rights" reserved to the publisher and that only "fair use," "limited implied > license to syndicate," and "explicit license grants (like CC)" limit the > totality of those rights. With this in mind it might be best to change from > a "license" link to a "rights-grant" link... In other words, frame this link > type as something which can *only* be used to broaden rights, not restrict > them. > > bob wyman > > > >
