[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.