Skip to Main Content
Apache Events The Apache Software Foundation
Apache 20th Anniversary Logo

ASF Position Regarding Sender ID

On September 2, 2004, the Apache Software Foundation sent the following open letter to the mailing list of the MARID IETF Working Group.

Subject: DEPLOY: Apache projects unable to deploy Sender ID

This message summarizes the position of the Apache Software Foundation,
the Apache SpamAssassin Project Management Committee, and the Apache JAMES
Project Management Committee.

The Apache Software Foundation (ASF) delivers enterprise-grade, open
source software products that attract large communities of users.  The
pragmatic Apache License makes it easy for all users, commercial and
individual, to deploy Apache products including Apache SpamAssassin (an
extensible email filter which is used to identify spam) and Apache JAMES
(the Java Apache Mail Enterprise Server).

The current Microsoft Royalty-Free Sender ID Patent License Agreement
terms are a barrier to any ASF project which wants to implement Sender ID.
We believe the current license is generally incompatible with open source,
contrary to the practice of open Internet standards, and specifically
incompatible with the Apache License 2.0.  Therefore, we will not
implement or deploy Sender ID under the current license terms.

We raised these concerns with the IETF ASRG chairs on March 1st and we had
assurances from the ASRG chairs that these matters would be addressed, but
they haven't been.  We feel that dismissal of unspecified, pending, patent
claims recklessly shifts the risk and potential burden onto implementors.

We began working with Larry Rosen, general counsel of the Open Source
Initiative, on June 9th, to coordinate our efforts to resolve the patent
licensing issues.  And since July 20th, Larry Rosen has been negotiating
with Michele Herman at Microsoft, but most of the major barriers are still

We are in agreement with Larry's analysis of the incompatibilities of the
current license:


    From: "Lawrence Rosen" <>
    Subject: RE: Microsoft's amended Sender ID license
    Date: Tue, 24 Aug 2004 10:15:12 -0700

    The open source development and distribution process works as well as
    it does because everyone treats open source licenses as
    sublicenseable, and most of them are expressly so. Open source
    licenses contemplate that anyone who receives the software under
    license may himself or herself become a contributor or
    distributor. Software freedom is inherited by downstream
    sublicensees. Meanwhile, the Microsoft Sender ID patent license
    continues the convenient fiction that there are "End Users" (S1.5) who
    receive limited rights. That is unacceptable in open source licenses.

    I have explained to Microsoft that their license is expressly
    incompatible with the warranty of provenance in the Academic Free
    License and the Open Software License:

       "Licensor warrants that the copyright in and to the Original Work
       and the patent rights granted herein by Licensor are owned by the
       Licensor or are sublicensed to You under the terms of this License
       with the permission of the contributor(s) of those copyrights and
       patent rights." (AFL/OSL S7)

    The "nontransferable, non-sublicenseable" language in their reciprocal
    patent license (S2.3) also imposes an impossible administrative burden
    on the open source development community and, in essence, creates
    additional downstream patent licenses that will be incompatible with
    the AFL/OSL and similar open source licenses, and with the open source
    development process.

    The requirement that Microsoft Sender ID patent licenses be formally
    executed (e.g., S6.10) is incompatible with the way the open source
    development and distribution process actually works. Furthermore, the
    requirement that "If you would like a license from Microsoft (e.g.,
    rebrand, redistribute), you need to contact Microsoft directly" (S2.2)
    gives Microsoft information about its competitors' plans that it has
    no reason to know. No open source license -- and *all* of them allow
    rebranding and redistribution -- can be conditioned on informing
    Microsoft of anything at all. Other proposed licenses have been
    rejected by OSI and FSF because they required licensees to notify the
    licensor of their intentions.

    The requirement that Microsoft's patent licensing notice be placed "in
    close proximity to" the license agreement (S4.3) is, as a practical
    matter, impossible for most open source licenses posted on the OSI or
    other websites. There is no reason for that requirement other than to
    burden open source licenses with Microsoft notices.

    One final point: Open source licenses must be worldwide. The Microsoft
    license, however, makes licensees subject to U.S. Export
    Administration Regulations (S6.2). Similar provisions have been
    rejected by OSI in many other licenses. Instead, Microsoft should
    simply make licensees responsible to obey the relevant export control
    laws and leave it at that. We all understand that an open source
    license doesn't override local laws.


We believe there are additional problems with license and the process.
Some of these include:

  * Microsoft has not disclosed information about their pending patents
    that cover areas of -core and -pra.  It is generally accepted that the
    PRA algorithm is covered, but any patents covering -core could cover
    far more than PRA.

  * Where the Sender ID specification includes additional optional
    features or suggests variations and alternatives to techniques needed
    to implement the specification (or where such variations or
    alternatives are obvious to an implementor), no license is granted.
    Only patents necessary to implement the specification are clearly

  * The licenses are said to be "personal" (though a reciprocally granted
    license is not required to be), which prevent assignment to an
    acquiring party, so open source projects may not be able to transfer a
    license to new maintainers or organizations.

  * The scope of the patent license is limited to compliant
    implementations.  This is incompatible with the broad grant of open
    source licenses to create any derivative work whatsoever.  In
    addition, as Internet software is often non-compliant for many
    possible different reasons, this would restrict the use of Sender ID
    unacceptably.  In addition:

     - Measurement of compliance is a problem.
     - If compliance is needed to get a license, then it's a problem.  If
       compliance is not needed to get a license, then the clause should
       just be dropped.
     - Full compliance might be difficult to achieve for technical or
       resource reasons.
     - Obvious extensions (many already under discussion) could be
       subject to unknown additional patents.
     - Accepted best practices often exceed or conflict with compliance
       for Internet standards.

  * It's conceivable that someone might want (or defensively, need) to
    enforce a patent related to Sender ID, but not "necessarily infringed"
    by an implementation of the specification, against Microsoft, but
    doing so would allow Microsoft to terminate.  The agreement is
    lopsided and will probably give Microsoft a competitive advantage in
    the Sender ID marketplace that is not warranted given the open
    standards that form the basis for Sender ID.

  * We are also concerned by the rush to adopt this standard in spite of
    technical concerns, lack of experience in the field, and a lack of
    consensus in the IETF MARID WG.

We will not be implementing support for Sender ID until such time as the
issues with the license are fixed and acceptable to the Apache James and
Apache SpamAssassin Project Management Committees.  We believe the first
step is fixing Larry Rosen's concerns.  As an alternative resolution, we
would find it acceptable if the pending patents were granted to a
non-profit organization such as ISOC and licensed under sufficiently open

Finally, as developers of open source e-mail technologies, we are
concerned that no company should be permitted IP rights over core Internet
infrastructure.  We believe the IETF needs to revamp its IPR policies to
ensure that the core Internet infrastructure remain unencumbered.

Greg Stein
Chairman, Apache Software Foundation

Serge Knystautas
V.P., Apache JAMES

Daniel Quinlan
V.P., Apache SpamAssassin