I do not believe in a blanket policy, nor am I proposing one. What I want to do is to establish an effective constraint against Patent Weasels. A Patent Weasel is not the same as a Patent Troll. A Troll waits till you have built the bridge and then tells you that he wants a toll. A Weasel helps you to build the bridge by promising that they will give you an open license but is deliberately vague as to what the actual terms of the license will be. It is always something that will be postponed into the future and meanwhile you continue to build the bridge. This is of course what some people are concerned that F500 patent powerhouses might do, or at least what some people will say is their concern. I am not really worried about that, a large company with a real business is always much more concerned about their brand and their reputation and their ongoing business. The real concern in my view is two-fold. First there is the OpenMarket problem, a company files a patent with a ridiculous claim in it, goes bust and gets bought out. Second there is the patent weasel who is really planning to become a troll. The reason I would like to be able to put a RANDZ requirement in a WG charter is that there are certain areas where I would like to see a working group form, where there is a set of clearly unencumbered technology that can be used and alternative technology that is owned by a proprietary concern. I want a WG to be able to make it clear to such rights holders from the outset that their technology is going to be stripped from the documents if they fail to deliver acceptable access terms before the start of last call. For example, say were were going to develop an audio compression standard (I choose this because its something we are not going to do and thus clearly an example). The starting point candidates might be AC3, AAC, OGG-Vorbis, MP3, TROLL, SPLUNGE, etc. Now there are many ways to compress audio and many ways to evaluate the value of the result. Newer algorithms require less bandwidth, better quality, whatever. But from my point of view I simply don't care. If the SPLUNGE CODEC is acceptably compact and offers acceptable quality and is out of patent (and thus definitively open) I simply do not care how compact or efficient the proprietary contenders might be. Having chosen the SPLUNGE codec and thus guaranteed a level of basic interoperability the value of the patents on the alternatives has been diminished considerably. If the mandated codec in APP is TROLL, the owner of the TROLL patents can charge an amount proportional to the value of APP. If the mandated codec is SPLUNGE the owner of the TROLL patent can only charge for the marginal increase in value it provides, (APP(TROLL) - APP(SPLUNGE)). So when starting the CODEC WG it makes good sense to require RANDZ upfront, in fact identifying an unencumbered CODEC might well be the entire point of the exercise. Clearly if we are going to develop a standard for Content Rights Management or the like it is pretty unlikely that a group could succeed if its charter mandated RANDZ (although this might change as the patents expire). > -----Original Message----- > From: Theodore Tso [mailto:tytso@xxxxxxx] > Sent: Thursday, October 25, 2007 4:22 PM > To: Norbert Bollow > Cc: ietf@xxxxxxxx > Subject: Re: A priori IPR choices > > On Thu, Oct 25, 2007 at 07:09:54PM +0200, Norbert Bollow wrote: > > > And I would argue that the above issue is not a matter of > concern to > > > the IETF. Having a reference implementation to encourage > adoption > > > of the spec, that is of IETF's concern. The issue of GPL > > > requirements is, I would argue, Not Our Problem. > > > > Is it really your position that that is in no case a > concern that IETF > > should consider??? > > > > For an extreme example, consider hypothetically the case that an > > essential part of the IPv6 protocol stack had such a patent issue. > > I was thinking mainly about protocols used by application > programs. I agree that something essential needed for IPv6, > that might be something that an individual wg might want to > consider. But in terms of a blanket policy that would apply > to *ALL* IETF protocols? That would something that is really > NOT an IETF-wide concern. > > - Ted > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf