spf-discuss
[Top] [All Lists]

RE: Patent license

2004-08-25 05:35:40
It seems to me that Microsoft's bad past behavior (or lack thereof) is a bit
off topic.  For example, would anyone feel better if it were Oracle or Sun?

The point to be made is that there is considerable uncertainty about the
possibility of the Microsoft license being compatible with GPLed software.
I don't think anyone one either list is a lawyer (I'm certainly not).  There
is no way this ambiguity is going to be resolved in the next two weeks.

The simple fact of the uncertainty ought to be sufficient to delay adoption
of Sender-ID.  A solution that excludes certain popular MTAs is no solution
at all.  This is independent of what anyone thinks of the GPL.  If someone
had brought forth an patent claim and said that to license the patent, the
software would have to be GPL, I think that would be equally bad.

If you look at RFC 3668:

http://www.ietf.org/rfc/rfc3668.txt Page 8 (My comments are delimited by //
below):

8.  Evaluating alternative technologies in IETF working groups

   In general, IETF working groups prefer technologies with no known IPR
   claims or, for technologies with claims against them, an offer of
   royalty-free licensing.  But IETF working groups have the discretion
   to adopt technology with a commitment of fair and non-discriminatory
   terms, or even with no licensing commitment, if they feel that this
   technology is superior enough to alternatives with fewer IPR claims
   or free licensing to outweigh the potential cost of the licenses.

//The existence of SPF (and even CSV) would seem to dictate that Sender-ID
is NOT "superior enough to alternatives with fewer IPR claims or free
licensing to outweigh the potential cost of the licenses".  No some would
say that the Sender-ID license is free and so this doesn't apply.  In a
narrow sense (you don't need to send Microsoft money) that's true, but in a
broader sense, there is a cost associated with compliance with this license.
For many potential developers the cost of legal advice alone is
prohibitive.//

   Over the last few years the IETF has adopted stricter requirements
   for some security technologies.  It has become common to have a
   mandatory-to-implement security technology in IETF technology
   specifications.  This is to ensure that there will be at least one
   common security technology present in all implementations of such a
   specification that can be used in all cases.  This does not limit the
   specification from including other security technologies, the use of
   which could be negotiated between implementations.  An IETF consensus
   has developed that no mandatory-to-implement security technology can
   be specified in an IETF specification unless it has no known IPR
   claims against it or a royalty-free license is available to
   implementers of the specification unless there is a very good reason
   to do so.  This limitation does not extend to other security
   technologies in the same specification if they are not listed as
   mandatory-to-implement.

//If the MARID specs were expanded to include SPF mail-from testing, then
there could be "at least one common security technology present in all
implementations of such a specification that can be used in all cases".//

   It should also be noted that the absence of IPR disclosures is not
   the same thing as the knowledge that there will be no IPR claims in
   the future.  People or organizations not currently involved in the
   IETF or people or organizations that discover IPR they feel to be
   relevant in their patent portfolios can make IPR disclosures at any
   time.

//And we should probably be looking ourselves for examples of prior art that
might make the current debate moot.//

   It should also be noted that the validity and enforceability of any
   IPR may be challenged for legitimate reasons, and the mere existence
   of an IPR disclosure should not automatically be taken to mean that
   the disclosed IPR is valid or enforceable.  Although the IETF can
   make no actual determination of validity, enforceability or
   applicability of any particular IPR claim, it is reasonable that a
   working group will take into account on their own opinions of the
   validity, enforceability or applicability of Intellectual Property
   Rights in their evaluation of alternative technologies.

//Since the "IETF can make no actual determination of validity,
enforceability or applicability of any particular IPR claim", I don't think
we should be looking to the chairs of the WG to resolve this question.  It
is uncertain and it will stay uncertain.  That uncertainty alone should be
sufficient to require addition of alternative approaches that can be used in
common among all implementations.//

I'm not going to post on this thread in the MXCOMP list.  I haven't been
active enough there for my voice to make much difference.  I post this here
in the hopes that it will be of assistance in promoting SPF (and thus on
topic, if only just) for those who are posting on this topic.  Feel free to
re-use whatever of this may have any value.

Scott Kitterman

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta features 
SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com

<<attachment: winmail.dat>>

<Prev in Thread] Current Thread [Next in Thread>