In summary, I believe that the Sender ID license, whilst somewhat
burdonsome to distributors of code, poses no major difficulties with
the GPL or other major open source licenses, and offers significant
benefits to both the open source community and the industry as a
whole.
I support the drafts being advanced in their current form (subject to
editorial nits and minor technical corrections).
There may be scope for further discussion between the open source
community and Microsoft, and there is nothing to prevent Microsoft
offering an alternative patent license in the future as a result of
the outcome of that discussion. But I see nothing in the current
license that would justify rejecting or delaying the drafts that are
before us.
This is a defensive patent license. It's purpose is to prevent other
people suing not just Microsoft, but all of us. Microsoft have
drafted it in a way to protect the community as a whole -- and not
just themselves -- from patent claims of third parties, and for this
they should be commended.
I suspect that anyone who believes Microsoft have some plot to try to
monopolize Sender ID hasn't actually read and understood the license.
It's a pain you have to sign it, but somehow I don't think that a
shrink-wrap reciprocal patent grant would hold water in any
jurisdiction.
Justification:
(Disclaimer: IANAL, and I'm way behind in reading the list given its
recent volume, so some of this may have been covered before)
GPL is a copyright license, the Sender ID licence is a patent license.
As such there is fairly limited scope for them to be incompatible (in
the traditional sense of incompatibility of software licenses).
The only circumstance that I'm aware of in which a patent claim (and
its licensing terms) can be incompatible with the GPL is that the GPL
prevents a distributor of the code from placing additional
restrictions on the recipients. Eben Moglen has made it clear in the
past that his (and the FSF's) position is that asserting patent claims
with a restrictive license in his opinion constitutes placing
additional restrictions for the purposes of the GPL.
But the point is that this makes the Sender ID license incompatible
with the GPL for Microsoft only.
Microsoft will (by this interpretation of the GPL) be unable to
redistribute other people's GPL'd code that incorporates the Sender ID
invention, since Microsoft, by means of their patent claims, are
placing restrictions (additional to the GPL) on what the recipient may
do with it. I suspect Microsoft can live with that :-)
On the other hand, if _I_ redistribute GPL'd code that incorporates
the Sender ID invention, I haven't violated the GPL, since _I_ have
placed no additional restrictions on what the recipient can do. This
applies whether or not I have signed the Sender ID license. The
Sender ID license doesn't require me to place additional restrictions
on the recipients; it simply requires me to inform the recipients of
the restrictions that Microsoft (might be) placing on them.
Granted, the requirement to execute a license agreement is burdonsome,
but it's not the end of the world.
Probably many distributors of software will fail to do so, out of
oversight more than anything else. If they don't execute an
agreement, what will happen? How is their situation worse than with
anything else they distribute? There could be unknown patent claims
on anything.
In the case of the Sender ID license, the probability of Microsoft
choosing to sue a distributor who didn't execute a license is probably
small. If Microsoft did sue, the chances of them winning any damages
would be slight, given they would not have suffered any financial
losses (since the license is royalty free anyway), unless the
distributor also had a patent on some aspect of Sender ID.
In reality, if Microsoft were to take any action at all, it would
probably be to contact the distributor and insist that they sign the
patent license.
I'm not in any way advocating distributing Sender ID implementations
without executing an agreement with Microsoft, or suggesting this
would be a sensible course of action. But I suspect that the risks to
a distributor who does so are actually much smaller than the risks
that they take with most of the other software they distribute.
As for the compatibility issue, I think it all boils down to what you
meen by 'compatible'. This is very different from the problem of
compatibility between open source copyright licenses. There is a very
real problem that given a work A with a copyright licence L_A and a
work B with a copyright license L_B, if you create AB, which is a
derived work of both A and B, there exists _no_ license under which
you can legally distribute AB without violating either L_A or L_B (or
both).
The Sender ID license, being a patent license, doesn't create this
kind of difficulty. It may be incompatible with the principle of open
source and free software license in some peoples eyes, but I don't see
that it poses significant problems to open/free software.
Even if I'm mistaken on this last point, most (all?) of the major MTAs
support a plug-in architecture (and those that don't could grow one if
need be). There's nothing to stop Sender ID plug-ins being
distributed as separate packages if (for some reason) it can't be
incorporated into the core distribution.
I'd also point out that this license is actually rather good for the
community as a whole (both open source and commercial). The
reciprocal license grant provision requires any other patent holders
to grant a patent license not just to Microsoft, but to everyone else
as well.
At a time when the open source community is becoming increasingly
concerned about the possibility of patent suits against them, I would
suggest that this license gains the open source community far more
that it loses.
-roy