The following is taken from a GROKLAW article that is exceptionally well
written, and should you have the time to wade through the feedback (the
site is clearly under quite a bit of load so its a bit slow) you'll find
that there is some decent feedback as well. Since the load is quite
high I've pasted more than I normally would, but its the position that I
found most interesting, and particularly relevant to the IPR issues with
SenderID:
The full GROKLAW article from which the following text was taken:
http://www.groklaw.net/article.php?story=20041109031629840
Give credit where its due and please do not cut and paste from this
document but REFERENCE the original article if you plan on repeating
anything quoted below. Thank you.
And finally, Microsoft:
Technology alone, however, will not solve this problem. A holistic
approach that also includes industry collaboration, legislation,
enforcement, and education is necessary to shift the burden from the
user to the spammer, resulting in an increase in the reliability of
e-mail and of the Internet. This approach also requires that any
proposed authentication standard be supported on a global basis,
because spam transcends and traverses national borders. Collectively,
these measures will help to substantially reduce the amount of junk
e-mail delivered to users' mailboxes and optimize users' overall
online experience.
See, that's just the problem. The Internet runs on FOSS and increasing
numbers of individuals, businesses and government agencies prefer to
use Linux, and by choosing a license that excludes all those folks,
Sender ID, by Microsoft's own logic, won't work.
Of course, Microsoft has thought of that and they have a plan:
Sender ID also requires modest changes to the e-mail software used by
sending servers in certain situations -- mainly to those servers that
perform e-mail forwarding. As more and more organizations adopt e-mail
authentication techniques, pressure will mount on those who are not
participating, because their e-mail will be subjected to greater
scrutiny and will be at a greater risk of being blocked by spam
filters. Thus, over time, upgrades to existing software will become
necessary.
Devilish indeed. But I urge you to read the section on Intellectual
Property, beginning on page 8. Their version of what happened with the
Internet Engineering Task Force (IETF) is something to behold. It
begins like this:
Open Standard. Any authentication system requires cooperation between
senders and recipients of e-mail. For that reason, we believe that
specifications for these systems must be publicly available and widely
implemented -- which is why our Sender ID specifications have been
published as Internet Drafts at the Internet Engineering Task Force
("IETF"). A technical interoperability specification is an open
standard when it has been ratified in an open, consensus-based
process. . . . The Sender ID Framework satisfies these conditions
because its specifications are published by the IETF, and because the
essential intellectual property rights disclosed to the IETF have been
made available on reasonable and non-discriminatory terms that are
also free of royalties and other fees.
That is clearly false, as the license attaches terms that preclude its
use with any GPL software. They do mention that the IETF working group
"has not reached consensus on the proposal and has suspended its work
for now -- a decision which is being appealed -- but the disclosure of
intellectual property rights to IETF and its publication of Sender ID
Framework specifications endures and thereby satisfies the conditions
for an open standard." They say the test isn't whether a solution is
an open standard isn't whether it has been ratified "through an
open-consensus based process", but whether the solution "can be widely
adopted. . ." Not a word that I can see in their letter about the GPL
conflict. This kind of doubletalk is beyond my heart's comprehension.
And here's a scary sentence about the Sender ID license:
"The terms of this license can be accepted by anyone at any time, now
or in the future, and will extend to all of Microsoft's essential
patent rights needed to implement Sender ID -- not just the essential
patent rights that could issue from these patent applications. . . .
although this license does not cover other patent rights that might be
owned or controlled by parties other than Microsoft and that may be
needed to make, use or sell implementations of Sender ID . . . "
By the way, this is what Microsoft's words look like if you copy and
paste them, so I had to hand type them:
'l:'chnoiogy ",1011_ 11owt'-v.;r, vì1 not ~wivi.~ this prob1em. A
holi~tit appiwJdi that "i1so incl1tdes industry coJiaboratio):,
kgislaiiüt1, üHfürçem~l1t, and education is necess::ry to shift the
burden i1'om ~he user to the sp;,nw:wr, n::sii1Üng În an increase in
lhi; rdiahilit:" of e--rnai¡ and of the TntemeLThis appwadi "iko requ:
res that any propo~1ed mdientieition :"Ümdardbe supported on a global
basis, hteaw3i; spam tn.mseends and traver~:;es national bün.:kn:" Cü!
kctivdy" i.hese measures wH1 help to sl,bsLmUally redlice
Now, Groklaw is nonpolitical, and I'm not one to be telling the FTC or
any government agency what to do, but you could be a child and see
that Microsoft's definition of open standards is ludicrous. Ludicrous
and dangerous. It looks to me like Sender ID is just another way to
set up conditions to hold back Microsoft's principal competition. They
intend that non-Sender ID email will over time become so annoying that
we all finally acquiesce and sign their poison pill license. What is
the difference between that strategy and Microsoft's tried-and-true
anticompetitive trick of arranging it technically so that competitors'
applications don't work well in a Windows environment?
The OpenSPF positions document is directly referenced in response to the
first comment and we've received quite a few hits already, I'm very
pleased with the wording that we've been able to supply as it appears to
have delivered our position in a clear and concise manner and is being
repeated with confidence.
I am grateful for the speed with which everyone has acted in getting
this information up, and further to Meng for not only asking for but
linking this information and allowing us a path to vocalize our stance.
Cheers,
James
--
James Couzens,
Programmer
^ ( ( (
((__)) __\|/__ __|+|__ '. ___ .'
(00) (o o) (0~0) ' (> <) '
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF