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(_at_)mit(_dot_)edu]
Sent: Thursday, October 25, 2007 4:22 PM
To: Norbert Bollow
Cc: ietf(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf