Subject: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ

From: "Harry Katz" <[email-masked]>
Date: Mon, 23 Aug 2004 19:01:00 -0700

Over the last few months a number of MARID working group members have
asked questions about Microsoft's Royalty Free Caller ID Patent License.
We have prepared an FAQ to answer questions about this license and its
successor the Royalty Free Sender ID Patent License.  We are in the
process of publishing this FAQ on our web site at
http://www.microsoft.com/mscorp/ip/standards.  We expect the page to be
live on or before September 15.  

For the convenience of the working group, attached is the full text of
the FAQ.  

If you have any further questions about the license, I encourage you to
consult with your own attorney and/or email your question to
[email-masked].  Someone from our legal department will answer
your questions.

Thank you.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 24 Aug 2004 09:16:02 +0200

On Mon, Aug 23, 2004 at 07:01:00PM -0700,
 Harry Katz <[email-masked]> wrote 
 a message of 457 lines which said:

> For the convenience of the working group, attached is the full text
> of the FAQ.

Reading the FAQ:

> A7: [...] we believe you can distribute your implementation under
> many open source software licenses, [...] Microsoft has not been
> made aware of any specific incompatibilities between any of the
> licenses used to distribute Sendmail, Postfix, or Qmail with
> Microsoft's royalty-free patent license.

There is a big free software licence missing, the GPL (none of the MTA
mentioned uses the GPL. Exim, which does, is not mentioned and I
assume it is not a coincidence).

Taking this into account and reading Eric Allman analysis
(http://www.imc.org/ietf-mxcomp/mail-archive/msg03500.html), it seems
the most common free software licence, the GPL, is incompatible with
Microsoft licence on SenderID.

---

From: [email-masked]
Date: Tue, 24 Aug 2004 18:52:10 +0200

All,

Again, I come out of the darkness of my lurking position and speak up my
mind.

I have been watching the discussions on this list continuously, and
technically there is not a lot against Sender-ID (although some proper
objections have been made, which I will not repeat here).

I have been worried about the licensing issue, but have been convinced
to wait it out. Now, with the 23 august deadline passed, I still see
that there is reason for concern. Although a license has been prepared,
it still does not say what exactly is licensed.

> [email-masked].  Someone from our legal department will answer

I am not prepared to contact my attorney (i don't have one) to do
open-source development on Sender-ID. For me, this means all work on
Sender-ID is a nono. I will continue to labour for SPF+SRS. I can only
hope the SPF Classic drafts (or better, Unified SPF) will be MARID's
proposal, replacing the technically imperfect and legally troublesome
Sender-ID proposal, but failing that I (and I believe many others) 
will continue work on SPF.

It would be a shame if this leads to a split, where one part of the
industry/community works on Sender-ID and another works on SPF. This
will frustrate the general cause we are 'fighting' for.

Koen Martens

P.s.: note that there are many people lurking on the list as did I,
reluctant to step in and join a debate among real experts that seem to
have a more than thorough knowledge of email. I hope many of them will
step forward, and voice their concern about this IPR business now, or
else it might just be too late.

-- 
K.F.J. Martens, Sonologic, http://www.sonologic.nl/
Networking, embedded systems, unix expertise, artificial intelligence.
Public PGP key: http://www.metro.cx/pubkey-gmc.asc
Wondering about the funny attachment your mail program
can't read? Visit http://www.openpgp.org/

---

From: <[email-masked]>
Date: Tue, 24 Aug 2004 13:09:51 -0400

I concur, the vague license application issues, as they currently remain (un)stated, are
unacceptable.

Terry Fielder
Manager Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
[email-masked]
Fax: (416) 441-9085

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of [email-masked]
> Sent: Tuesday, August 24, 2004 12:52 PM
> To: Harry Katz
> Cc: IETF MARID List
> Subject: Re: DEPLOY: Microsoft Royalty Free Sender ID Patent
> License FAQ
>
>
>
> All,
>

---

From: "Mark C. Langston" <[email-masked]>
Date: Tue, 24 Aug 2004 10:26:26 -0700

I'd have to agree with Koen.  I'm adding SPFv1 checks to GOSSiP.  I'd
like to support the eventual product of MARID, but given the current
license confusion, I can't, nor am I inclined to.  This isn't a "I won't
support anything from Microsoft" position; this is a "It's not entirely
clear to me what rights I retain and which I surrender by including a
Sender-ID implementation in my code." position.

-- 
Mark C. Langston            GOSSiP Project          Sr. Unix SysAdmin
[email-masked]   http://sufficiently-advanced.net    [email-masked]
Systems & Network Admin      Distributed               SETI Institute
http://bitshift.org       E-mail Reputation       http://www.seti.org

---

From: Eric Allman <[email-masked]>
Date: Tue, 24 Aug 2004 13:48:43 -0700

| Taking this into account and reading Eric Allman analysis
| (http://www.imc.org/ietf-mxcomp/mail-archive/msg03500.html), it
| seems the most common free software licence, the GPL, is
| incompatible with Microsoft licence on SenderID.

I didn't say that.  I said that _some_ people may believe this, but 
there is also some significant reason to believe that they are 
incorrect, including statements from both Eben Moglen and Lawrence 
Rosen, both of whom are lawyers.  As near as I can tell, the question 
of GPL compatibility is quite ambiguous at this time.

eric

---

From: George Mitchell <[email-masked]>
Date: Tue, 24 Aug 2004 14:01:47 -0700 (PDT)

> else it might just be too late.

I second Koen's remarks.  Based on these facts:

* SPF+SRS is embodied in working code.  (Two widely publicized
  implementations, and there are probably others.)
* SPF+SRS is deployed.
* SPF+SRS is not encumbered by any intellectual property claims.

what do you think we should do next?
-- George Mitchell

---

From: Douglas Otis <[email-masked]>
Date: Tue, 24 Aug 2004 15:37:01 -0700

> of GPL compatibility is quite ambiguous at this time.

A few years back, working within a different standards body developing a
standard for a storage device, there were deliberations regarding how
data would be referenced.  A device manufacture holding a patent for an
existing scheme made a very similar offer to the group.  This
contractual agreement was honored until the rights to the intellectual
property were transferred to a media manufacturer after production
became established.  Suddenly, reasonable terms were refused other media
manufacturers.  Media quickly tripled in price.  At the time, there were
better schemes that could have been used. : (

At least, this was regarding a device in competition with several other
technologies, and where a breach in this promise (in spirit at least) 
only affected the profits of about half a dozen manufactures.  Email is
not divided into small independent segments of an industry however. 
Email is likely one of the most pivotal network and business
applications that exists. I would hate to be lured by false promises of
Sender-ID, into acquiescing this application to a corporation.

-Doug

---

From: Mark Shewmaker <[email-masked]>
Date: Tue, 24 Aug 2004 18:49:25 -0400

On Tue, 2004-08-24 at 16:48, Eric Allman wrote:
> As near as I can tell, the question 

I'm sorry, but the [L]GPL incompatibility couldn't be more unambiguous:

1.  Choice of law restrictions, choice of venue restrictions, and poison
    pills are widely understood to be incompatible with the [L]GPL.

2.  A distributor of an implementation of SenderID would
    have no way of allowing all recipients to modify and further
    redistribute that implementation, which means that it simply
    can't be [L]GPL compatible.

It's too bad the mxcomp list restricted discussion of licensing issues
before yesterday's deadline.  I truly believe we could have ended up
with a licensing solution that everyone could have been pleased as punch
about.

-- 
Mark Shewmaker
[email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 25 Aug 2004 11:05:37 +0200

[Shifting from the legal and political issue...]

On Tue, Aug 24, 2004 at 02:01:47PM -0700,
 George Mitchell <[email-masked]> wrote 

> * SPF+SRS is not encumbered by any intellectual property claims.

SPF is coded and deployed. SRS is much less common (IMHO the SUBMITTER
extension could make SRS unnecessary).

---

From: Chip Mefford <[email-masked]>
Date: Wed, 25 Aug 2004 09:40:54 -0400

Mark Shewmaker wrote:
| On Tue, 2004-08-24 at 16:48, Eric Allman wrote:
|
|>As near as I can tell, the question
|>of GPL compatibility is quite ambiguous at this time.
|
| I'm sorry, but the [L]GPL incompatibility couldn't be more unambiguous:

Aaaah! Help me out here, I don't understand this empircal statement.

"I'm sorry, but the [L] GPL incompatibility couldn't be more unambiguous:"

Okay, "I'm sorry, but the [L] GPL /in/compatibility could /not/ be more
/un/ambiguous:"

So, does that mean the GPL compatibility could not be more ambiguous, or
is it the opposite?

Or, does that mean the GPL compatibility could be more unambiguous?

I'm not splitting hairs, I really am not sure what is the point.
Thanks for any enlightenment.

---

From: Mark Shewmaker <[email-masked]>
Date: Wed, 25 Aug 2004 10:23:24 -0400

> "I'm sorry, but the [L] GPL incompatibility couldn't be more unambiguous:"

To clarify any grammatical ambiguity:

o  I claim that the [L]GPL is incompatible.

o  I also claim that that the incompatibility should not be in dispute,
   that it's quite clearly, and unambiguously, incompatible.

I should have avoided using the "couldn't be more" wording.

-- 
Mark Shewmaker
[email-masked]

---

From: wayne <[email-masked]>
Date: Wed, 25 Aug 2004 20:48:45 -0500

> [email-masked].  Someone from our legal department will answer

Ok, I'm afraid I'm confused by all this and I would like some help in
clarifying the situation around qmail.

In the Microsoft SenderID FAQ, it states:

    Q7: Is Microsofts license compatible with Sendmail, Postfix and Qmail?
    
    A7: While each open source software license may differ, we believe you
    can distribute your implementation under many open source software
    licenses, so long as you include the attribution stipulated in
    sec. 2.2 of Microsofts Royalty-Free Sender ID Patent License
    Agreement. You should check with your own legal counsel if you have
    questions about a particular open source software license. Microsoft
    has not been made aware of any specific incompatibilities between any
    of the licenses used to distribute Sendmail, Postfix, or Qmail with
    Microsofts royalty-free patent license.

Now, at the IETF-60 meeting, it was pointed out that qmail has a
quirky license.  (Many/most people do not consider qmail to be Open
Source Software because of its license.)   Basically, only the
original author can modify qmail, all other changes must be
distributed separately and applied as patches.  As the original author
hasn't updated qmail for years, almost all qmail users take the
original source and apply one or more sets of "patches" in order to
create an MTA (mail server) which they can use.

At the IETF-60, it was pointed out that the SenderID license would
mean that all users of qmail would need to obtain a license from
Microsoft.  Qmail, it should be pointed out, is one of the popular
MTAs on the Internet.  Some claim it ranks #2 behind sendmail, but it
clearly is one of the top 5.

So, the question is:

Would a qmail patch author qualify as a "licensed implementation" and
thus someone who takes qmail and creates a derivative work of it by
apply the patch qualify as an "end user"?

If not, wouldn't this mean that users of qmail that want to support
SenderID (which we hope will be all of them) need to get a license
from Microsoft?

Section 2.1 says how you can distribute to "End Users" in object code form,
but a patch isn't object code.

Section 2.2 says how you can distribute to "End Users" a "Licensed
Implementation" in source code form.  So the question is: can a patch
be a "Licensed Implementation?"

Section 1.2 gives the definition of a "Licensed Implementation",
which, in the second of the two (ii) clauses, requires you to have
branded trademark.  Do any patches have trademarks?

Section 1.5 gives the definition of a "End User", it talks about
receiving a "product".

Section 1.3 gives the definition of a "Licensed Product", but I don't
think a patch is a product.

Now the whole problem with patches is that they are derivative works
of the original because they contain lines of source code for
"context".  When you apply a patch and compile it, you are creating a
derivative work of both the original and the patch.  Often times, the
resulting patch needs to be tweaked because of other patches that have
also been applied.  

It isn't at all clear to me that a patch can be a "Licensed Product"
and thus allowing the person applying the patch to the qmail
source to be covered by the "End User" aspects of the SenderID
license.  Even if a patch could be a product, aren't you
creating a new product when you apply the patch?

-wayne

---

From: Paul Iadonisi <[email-masked]>
Date: Fri, 27 Aug 2004 16:54:53 -0400

On Wed, 2004-08-25 at 21:48, wayne wrote:

[snip]

> creating a new product when you apply the patch?

  This follows right along with my explanation that, at least with the
GPL, there is no distinction between end user and intermediate developer
(see http://www.imc.org/ietf-mxcomp/mail-archive/msg03589.html).  I
think that any license that makes this distinction will be a problem for
the GPL and possibly lots of other FOSS licenses.  And even some
non-FOSS license (by FSF, OSI, or DFSG definitions), like the qmail
license.
-- 
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets