"Dick St.Peters" <stpeters(_at_)NetHeaven(_dot_)com> writes:
I've been a free-software guy for decades and don't like Microsoft
very much, but I think it's important to stick to the truth...
[Microsoft's licence] explicitly allows anyone to *use* Sender-ID
without a exectuting a license agreement.
Nonetheless, the license excludes a lot of free-software developers.
For example, I'm a professor who also happens to work on open-source
mail software in my free time. I asked my university's lawyers
whether they could execute Microsoft's sender ID license, and the
answer was probably not. The problem is that it requires the
university to license *all* of its patents back to Microsoft for
sender ID--including patents obtained by other research groups--which
the lawyers were extremely reluctant to do.
In general, universities like to license patents in accordance with
the wishes of the inventor--especially when the inventor creates a
start-up company, as this can be lucrative for the university. To get
a Sender-ID license, I would need to argue that no one has in the
past, and no one will in the future, invent and patent technology that
would be of use to Sender-ID implementors. The future part is
particularly problematic since no one can see into the future. For
example, even if no current faculty member thinks they will work on
relevant stuff, signing the license affects future hires as well.
Another problem with the license is that it is incompatible with the
GPL, meaning you can't incorporate third-party GPLed code into a
Sender-ID-compatible mailer.
So your description of the patent is technically correct. Nothing
precludes an open-source implementation. However, by excluding A)
developers from academia, and B) systems that incorporate GPLed code,
clearly Microsoft is making it much harder to have an open-source
implementation.
For this and other reasons, I'm really distressed that the Sender-ID
draft RFC specifically conflicts with SPF. The idea that SPF and
Sender-ID could co-exist side-by-side was reassuring, because if SPF
works, this means we could just ignore Sender-ID and still reduce
unwanted mail. My guess is that Microsoft was worried that if we did
this, two years from now there would be many more v=spf1 records than
spf2.0/pra records, and people would make an argument for
standardizing SPF. If they manage to coopt v=spf1 records, Microsoft
can take SPF's success and use it as an argument for standardizing
Sender-ID.
I almost wonder if it is worth extending the SPF draft to accept a new
version string (v=spf3?) as well as v=spf1, so at least there is some
way of declaring a sites exclusive participation in the SPF
experiment.
David
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
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