ietf-mxcomp
[Top] [All Lists]

RE: DEPLOY: IPR [was Re: TECH: use fetchmail algorithm to select header address to verify]

2004-09-08 05:53:02

-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Margaret 
Olson
Sent: Wednesday, September 08, 2004 6:13 AM
To: Yakov Shafranovich
Cc: Dave Crocker; Roy Badami; ietf-mxcomp(_at_)imc(_dot_)org
Subject: DEPLOY: IPR [was Re: TECH: use fetchmail algorithm to select
header address to verify]



[I changed the tag and subject to match the topic of discussion]

On Sep 7, 2004, at 8:43 PM, Yakov Shafranovich wrote:


Dave Crocker wrote:
My own guidance about whether to to treat an IPR claim seriously --
particularly when it includes legal filings -- is to decide whether
the claimant has the means and the resolve to pursue them.

There is definitely means here, but I am not sure about the
resolve.
Somehow I don't think they will make fools out of themselves,
especially considering that the FAT patent is being challenged.

The costs of being in IPR litigation are awesome, no matter how
frivolous one might believe the claims to be.

Considering what happened to the Eolas and FAT patents,
challenging a
patent is now an option as well and is much cheaper.

In any case, does this mean that anyone claiming IPR rights
can stop
the standards process? That's not the reading I get from
the cases of
IDN and IPSec.

My reading of the IPR situation is that the MS patent is
defensive - it
ensures that they (and we) can use the technology. Their license is
positioned for maximum defensive value.

Then why have such a restrictive license, indeed one that forces your 
competitors to inform you of
what they are working on?

I believe they (and we) would have been better off sacrificing some of the 
legal defense value for
sub-licensing and more open source compatibility, but they obviously disagree.

There is no disagreement.  You believe their patent is purely defensive.  Its 
clearly not *just*
defensive else why that discriminatory and/or restrictive license???

In fairness, I'll point out that they have effectively
volunteered to pay for any patent defense that is necessary, and

Of course, and what they get out of it is control from their competing MTA 
products: preventing the
competing MTA products from altering/enhancing/improving the MARID (thereby 
preventing them from
getting an edge with a better product).  Someone please correct me if I am 
wrong.  (Please let me be
wrong)

perhaps can not be blamed too much for a zealous approach to
preventing
litigation expense.

I suggest ignoring the patent. It's not in their interests to
litigate
this kind of defensive (read: bogus) patent if they can possibly help
it - avoiding patent litigation is the entire point of defensive
patents. We'll only see litigation if someone decides to file a
competing patent claim and prevent MS (and the rest of us) from using
Sender ID. In this scenario a patent holder with deep pockets is a
desirable.

The idea that any email authentication algorithm that is not
currently
encumbered will remain so in the face of something as potent as spam
prevention strikes me as a bit naive. Others have posted on the state
of the USPTO office an software patents, so I won't repeat
that here. A
patent holder focused on milking the patent, rather than protecting
large and profitable businesses, would produce far worse licensing
terms. A patent holder acting on behalf of the open source community
would presumably produce a more open source friendly license. But no
patent claim is a temporary situation. We need to be realistic about
this, and I suspect MS's position in many reflects painful experience
with failing to patent things that the rest of us would call either
obvious or long standing prior art. My experience has certainly been
that it if it is useful, you need to patent it if you expect to
continue to use it.

Sure, OK.  But that still does NOT require a discriminatory and/or restrictive 
license!!!

Terry


Margaret.



<Prev in Thread] Current Thread [Next in Thread>
  • RE: DEPLOY: IPR [was Re: TECH: use fetchmail algorithm to select header address to verify], terry <=