Re: DEPLOY: Santronics position on Sender Id

["Hector Santos" <hsantos@xxxxxxxxxxxxxx>]

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@xxxxxxxxxxxx>
To: <ietf-mxcomp@xxxxxxx>
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.
>
>