DEPLOY: Sendmail position on Sender Id

Sendmail, Inc. has worked with Microsoft to help them produce a 
patent license that will be acceptable for ourselves, the IETF, and 
the open source community at large.  This message summarizes our 
position.  The following discussion refers to the Royalty Free Sender 
ID Patent License (RFSIPL), dated 23 August.  Harry has already 
posted it to the list, although it will take a few days to appear on 
the Microsoft web site.
The executive summary is that we believe that the Sender ID 
technology is promising, and will hopefully be adopted.  We believe 
that although not ideal, the RFSIPL and associated IP disclosures 
satisfy the IPR requirements of the IETF and are compatible with most 
major open source licenses.  It would be extremely disappointing if 
this potentially useful technology to combat fraud and spam failed 
for reasons unrelated to its technological merits.
The revisions in the RFSIPL have clarified several important issues. 
Notably, it is now explicit that recipients of a Sender ID 
implementation who do not intend to redistribute the code do not need 
to get a patent license to use such an implementation.  However, the 
license is not without restrictions.
Sublicenseability

Our key concern is that anyone redistributing open source code with 
Sender ID technology would need to execute a license with Microsoft 
to remain within the letter of the current license.  Sections 2.1 and 
2.2 provide patent license grants for object and source code 
respectively; in both cases they are non-sublicenseable.  This 
restriction means that anyone distributing or redistributing Licensed 
Implementations (that is, Sender ID) should contact Microsoft for a 
patent license.  This process is reasonably painless, requiring only 
that the licensee fax the signed license (available at 
<http://www.microsoft.com/mscorp/ip/standards/>) to Microsoft.  None 
the less, any time a license is involved friction is added to the 
process.
Defensive Suspension

A somewhat lesser concern is specific to the GPL: it has been claimed 
that section 6 of the GPL (version 2) prohibits invalidation of a 
license on the basis of a patent infringement claim as required by 
section 2.4 ("Defensive Suspension") of the RFSIPL.  We believe this 
to be a reasonable term, common in many open source licenses (e.g., 
the Mozilla Public License, the IBM Common Public License, the Apache 
License).  It is notable that many programs with similar license 
terms are already packaged in GPLed distributions, so the 
incompatibility claim is clearly not universally believed.
Reciprocal Patent License

Section 2.3 of the RFSIPL extends the patent license grant to apply 
to the licensee as well as the licensor.  In other words, if the 
licensee also has a patent on IP necessary to implement Sender ID, 
then they in turn grant the rights to that patent under the same 
terms (including royalty-free and non-sublicenseability) to all other 
licensees.  This ensures that any additional IP required from other 
suppliers will also be available royalty-free.  We believe this to be 
a net positive term for the interests of the community.  However, it 
may be expected that some organizations will want to review their own 
patent portfolio prior to signing, which adds additional friction.
License Compatibility

Viewed from the license compatibility perspective, our legal counsel 
has opined that the RFSIPL is consistent with the Sendmail Open 
Source License, and we believe it is also compatible with the BSD 
license, since neither of them refer to patents at all (nor does the 
Python license or the Artistic License, to name a few additional 
examples).  Some other Open Source licenses explicitly state that it 
is the recipient's duty to acquire any necessary IP rights needed to 
run the software (e.g., the IBM Common Public License). In all such 
cases we think it is probably safe to presume compatibility from a 
"letter of the law" perspective, if not the "intent" perspective.
The major exception to this may be the GPL, both as regards Defensive 
Suspension as noted above, and as regards the non-sublicenseability 
clause.  Even this isn't completely clear; Eben Moglen (FSF Counsel) 
has published an example of at least one case (the Office 2003 XML 
Schema) where he found such conditions acceptable from the GPL legal 
perspective, albeit not within the original intent 
(http://www.theregister.co.uk/2003/11/18/fsf_eases_microsoft_schema_patent/). 
In particular, the article says:
        "I don't think the alarm is justified," the FSF's pro bono
        counsel Eben Moglen told us last night. "This is not a
        license that I would like to accept; Microsoft is saying we
        might have some patents. But it's not a problem if Microsoft
        is making it available to everyone to make use and sell.

The Sendmail Perspective

The non-sublicenseability element does present certain practical 
problems for Sendmail.  On the open source side, the sendmail MTA is 
routinely bundled into other larger systems, notably open source 
operating system releases such as Linux and BSD distributions as well 
as commercial closed-source systems such as Solaris and AIX. Bundlers 
would need to execute their own copy of the RFSIPL.  Those systems 
are in turn sometimes incorporated into other products, which would 
seemingly require another layer of patent licenses, and so on down 
the tree.  As a practical matter, this makes the decision to include 
sendmail with Sender ID into their release more problematic. This is 
obviously not desirable from our point of view.
On the commercial side, we have end user customers who install and 
use our product and channel partners who rebrand and/or redistribute 
our product.  Although the RFSIPL does not require us to demand a 
license from any of our customers, our customers do demand IP 
disclosure as part of sales contracts.  End-user customers are fine, 
since the RFSIPL permits them to use Sender Id without executing a 
license.  But all of our channel partners would have to sign the 
RFSIPL to be within the terms of the license.  They will want to have 
their own lawyers review the license, just as we have.  This is not 
going to sit well with our partners, who expect us to take care of 
IPR issues when we bundle a technology into our product.  This 
requires additional effort on the part of both ourselves and our 
partners and thus lengthens our sales cycle for these important 
customers.
While these are pragmatic rather than legal reasons, our likely 
decision at Sendmail will be to distribute our Sender ID 
implementation as a separate package that is not required to run the 
sendmail MTA under a distinct (possibly modified) Sendmail Open 
Source license.  Open source users will have the option of 
downloading and installing the Sender ID package should they want the 
additional functionality.  Bundlers will be able to choose whether 
they want to include the Sender ID technology or not, but will still 
be able to use the base sendmail MTA without additional IPR issues.
Considerations for MARID

In regards to the MARID Working Group of the IETF, we believe that 
the IPR disclosure requirements of the IETF (RFC3668) are consistent 
with the RFSIPL, and hence we do not see any by-the-book impediment 
to proceeding forward using this license.  In fact, Microsoft has 
gone beyond the strict requirements of RFC3668, which do not require 
royalty-free licenses, nor even any explicit disclosure of licensing 
terms at all (section 6.5).  However, we understand that email is one 
of the most fundamental protocols on the Internet, and there may be 
reluctance to rely on any encumbered intellectual property, even with 
the promise of royalty-free licenses to all users.
It is worth noting that IP encumbrances for popular standards are not 
a new problem.  For example, the W3C Patent Policy does not require 
patent licenses to be sublicenseable.   In his new book "Open Source 
Licensing, Software Freedom and Intellectual Property Law", Larry 
Rosen states (pp 309-310):
        Not every requirement of the W3C Royalty-Free license policy
        is friendly to open source, however.  For example, because
        such licenses are "non-assignable" and "non-sublicenseable"
        each licensee theoretically must obtain a license directly
        from the patent owner.  In practice hardly anybody does and
        because the W3C member commitments to each other, nobody
        needs to fear that the royalty free patent license wouldn't
        be available to anyone who actually wanted one.

He does however say that such patent licenses need to be royalty-free 
(pp 306-307), as is the RFSIPL.
Recommendation

Although the RFSIPL is not ideal, we believe that it satisfies the 
requirements of the IETF and is compatible with a broad range of Open 
Source licenses.  Sender ID seems to be a technologically appealing 
option in the IP address based authentication space.  There is great 
urgency in the marketplace right now to combat fraud, phishing, and 
spam.  As a result of these considerations, we recommend that MARID 
proceed with Sender ID.