Eric,
First, where is the patent? No patent has been issued.
Second, I have serious issues for the merits of the patentability of the
weak concepts involved. Any good prudent lawyer could fight this patent
with ease.
Third, there is little to no benefit, in fact produces more issues than it
resolves. So considering 1, 2 and 3, I have a problem with given credence to
a weak idea.
Forth, if it was patented, it is quite conceivable that a "judge" can deem
this PUBLIC DOMAIN just for the fact that it can have world wide
implications. It has happen before. Case in point: HAYES and AT Command
set.
Fifth, Not all products are OPEN SOURCE! So in short, in no way would we
subject the future of our mail product lines based on Microsoft "patents."
We have never done it and we will never will.
We have a very successful anti-spam system. Why would be want to alter this
now? The only reason we were here in the first place was to help make SPF
the standard. Not get into idiotic IPR issues.
As far as I am concern, this is has been a big waste of time in my book.
All this process has done is raise the bar for a continuation of exploration
for better ways. I would be among the first to work with a technology that
was sound, even if it was one that was going to impose serious redevelopment
cost which this will most definitely will do for those who support it.
However, we will no longer subject ourselves to this moronic IPR issue that
quite frankly is technologically flawed. It doesn't even address CANSPAM
nor the full address. So why bother?
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Eric Allman" <eric(_at_)sendmail(_dot_)com>
To: <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Monday, August 23, 2004 10:39 PM
Subject: 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.