On Wed Jul 29 19:41:58 2009, Lawrence Rosen wrote:
I agree completely with Richard Stallman's responses to an earlier
email. I
repeat the relevant parts of that earlier exchange below. This
reflects a
basic policy that should be adopted by IETF.
I'm not in favour of software patents, and whilst I don't do much
open-source or free software these days, I'd certainly at least nod
pensively at the suggestions that open-source implementations both
help specification development and act as a good indicator of the
interest in a proposal and the general health of the protocols.
I am also not in favour of burying my head in the sand. All SDOs -
the IETF included most especially, as having set the standard to live
up to - should primarily exist to document what *is*, not what one
might want to be. It's often commented that the IETF, whilst good at
refining designs, rarely produces new protocols successfully, and
it's certainly not alone there.
It's been phrased in terms of "running code" before, by another Dave
- I like to call it "documenting reality", or "not living in cloud
cuckoo land".
The case where a patent is known from the outset, or even is known
very early on, is often a case where the IETF *does* route around the
damage. The exceptions tend to be where the specification either
describes the only, or the only sensible, method for doing something.
Other cases, though, include cases much closer to the well-known
UNISYS GIF patents, where a well-deployed specification turns out to
have a patent applicable to it - or at least a patent potentially
applicable to it.
In either case, the IETF essentially has two choices:
1) It chooses to throw away the core principle of "documenting
reality". This is damaging in itself, because - just like producing
avoidable specifications which have known patents - it risks having
the IETF produce irrelevant standards, and thus becoming irrelevant
itself.
In the case of PNG, it's my understanding that PNG only overtook GIF
on the web due to technical superiority used by better displays,
rather than patent encumberances - certainly when the patents were in
effect, I saw lots of rhetoric, but lots of GIFs, too.
2) It documents what is, including that it's patented, and those
participants who care about unemcumbered standards attempt to have
the market route around the damage instead.
This strategy has two advantages - firstly, it works whether the
patent is known from the outset or not, giving us a consistent
policy. Secondly, it means that we can get on nicely with the
pro-patent crowd, document the encumbered stuff, and then have the
patents documented too - it could be argued as having the effect of
sonar on submarine patents.
So, in summary, by all means argue against patents - I'm right with
you, and so are a lot of the other participants here. But argue
somewhere else - the debate isn't appropriate here, and many here see
your rhetoric with pragmaticism.
Here, you need a working counter-proposal, that the market can then
use to route around the damage. There's a lot of open-source projects
that respond to many suggestions with "please provide a patch" - I
encourage those interested to do the equivalent here.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
