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>>