I'm the author of Mail Avenger (www.mailavenger.org), a GPLed,
SPFv1-compliant SMTP server. I would, of course, like to comply with
whatever standard emerges from the MARID effort. However, I have
several questions/concerns about the license terms offered by
Microsoft.
* Reciprocal license agreement at universities
My first concern is about section 2.3, the reciprocal patent license.
I myself have no software patents and no plans to acquire any that
might interfere with Sender ID. So I personally have no problem
reciprocally licensing my (non-existent) patent portfolio. However,
I'm also a professor at NYU, where I developed Mail Avenger, and from
whose network I distribute the source code. The question is whether
the contract applies just to patents on which I'm an inventor, or to
any patent application by any faculty member at NYU. In the latter
case (which sounds more likely), this could pose some serious
problems.
Unlike companies, which often enter into blanket patent
cross-licensing agreements, NYU (like many universities) doesn't tend
to license a patent without the consent of the inventor. Thus, at the
very least, this kind of blanket patent license would constitute a new
case that would need to be investigated.
I could easily imagine having to get every faculty member with a
remotely related patent or patent application to agree that it is
unrelated to Sender ID. While it's unlikely someone at NYU has
applied for any relevant patents, I doubt people would agree to sign
over their patent rights without at least reading over the internet
drafts to make sure. That's asking already busy people with no vested
interest in my software to do work, which could then easily fall of
the end of their to-do lists. A related problem is that some patent
applications might be secret. Still another problem is that some
funding contracts *require* principal investigators to patent any
inventions and license them in certain ways. Thus, this kind of
blanket license could potentially conflict with other PI's funding
sources.
In short, it seems there is a real danger that Microsoft's license
would be unacceptable to many universities, which would prevent people
in academia from releasing MARID-compliant software.
* Trademark requirement
I have two concerns about the requirement for a trademark. The patent
license (sections 2.1 and 2.2) is only for "Licensed Implementations",
which, according to section 1.2, must be "branded with a trademark
owned or controlled by You." I notice that section 2.1, about object
code, allows implementations to be distributed "directly or
indirectly", while section 2.2 for source code only allows
"distribution" without mention of indirect. Is this distinction
intentional/meaningful? In particular, for GPLed code, someone who
doesn't own the code can't distribute object code without also at
least having the ability to distribute source. Thus, I'm worried that
"indirect" distribution of GPLed code would not be possible.
[Note: I gather there may be some specific incompatibilities with the
GPL, but this question applies to any GPL-like license that requires
source code availability.]
Another problem is that it seems as though everyone along the chain
requires a trademark. Suppose NYU had a trademark on Mail Avenger.
If someone at another university made modifications to the software
and wanted to redistribute them, it sounds like they could not do this
unless they re-branded the software and got a new trademark--even if I
want to allow people at other institutions to put out new versions of
Mail Avenger. The license seems to require that each university
executing the agreement have its own trademark under which the
software is branded. I don't understand why consent of the trademark
owner isn't good enough, but this seems like a very serious annoyance
when collaborating across organizations only one of which can
obviously own a particular trademark.
Again, this is probably a more serious concern for academia than for
industry.
* Requirement that implementations conform to the specification
This concern may be more specific to Mail Avenger, but nonetheless it
seems like a potentially bad restriction. Mail Avenger's goal is to
give individual users the maximum amount of control over what happens
during SMTP sessions. Thus, while a traditional SMTP server might
have a monolithic Sender ID implementation built in, Mail Avenger
actually implements policies by reading scripts in users'
$HOME/.avenger/ directories. These scripts can, for example,
formulate arbitrary queries in the SPF language and implement either
straight SPF or use SPF as a means of enforcing a different policy.
If Sender ID were to become a standard, I would of course want to
expose the various components, like, for instance, the query language
and a $PRA variable that could be used for various purposes--for
everything from regular Sender ID enforcement to RBL checking, SMTP
callbacks, greylisting, or even SYN fingerprint validation against
previous messages. Many potential uses of Sender ID's components,
including the query language and PRA, would not be for the purposes of
enforcing Sender ID, but rather for some other, related policy. In
practice, giving users this kind of flexibility has proven extremely
powerful in fighting spam.
I'm concerned that:
1. This kind of toolkit-structured Sender ID implementation would not
be covered by the license because of the ability to use encumbered
components of Sender ID for other purposes.
2. If the actual sender ID enforcement is done by little config files
or scripts in users' home directories, these scripts themselves
might require the patent license and thus could not be easily
shared and discussed amongst users.
In general, ease of constructing spam-fighting tools is extremely
important in the fight against spam. Thus, any licensing requirements
that would rule-out highly extensible mail server designs would be
unfortunate.
* Effect on deployment
The effectiveness of a technology like Sender ID will be proportional
to its deployment. While it's good that Microsoft's patents can be
licensed on pretty liberal terms, any need to sign contracts is still
going pose an impediment to deployment. The burning question is
exactly how serious the impediment will be--obviously there is a lot
of disagreement on this point amongst members of the mailing list.
However, at the very least, the fact that Sendmail's "base package"
will not automatically support Sender ID will likely reduce deployment
by a significant amount. In particular, given how tempers have flared
on the list, it's hard to imagine there won't be at least one or two
high-profile open-source OS distributions that don't include sender ID
by default just on principle, because the maintainers object to this
license.
If our main goal is to stop mail forgery, then what we really need is
a cost-benefit analysis. What is the cost of requiring a license for
Sender ID compared to the benefit gained from incorporating the
patented technology? Unfortunately, at this point the debate has
centered only around the left side of the equation, and we have zero
information about the right because Microsoft has not disclosed the
nature of their pending patents.
It would be a great gesture of good faith if Microsoft would disclose
their patent applications so as to help guide the debate. For
example, if there's some trivial modification that gets around the
patents without reducing effectiveness, I don't see how anyone could
argue we're better off incorporating the patented technology. On the
other hand, if there are concrete benefits, then we can have a more
concrete debate.
In the absence of information on the scope of the patents, all we have
information about is the scope of the license, namely that it applies
to the core and pra drafts. Based on this, my personal
opinion--colored, of course, by the license's effect on people in
academia and my experience with the success of extensible designs in
fighting spam--is that I would gladly give up the PRA algorithm and
stick with something like SPFv1 if it eliminated the license
headaches.
David