Apache Software Foundation (ASF) Open Letter on Microsoft's Sender ID Patent License Agreement

Apache Projects Unable to Deploy Sender ID

Subject:       DEPLOY: Apache projects unable to deploy Sender ID 
From:          Greg Stein [Chairman, Apache Software Foundation]
Date:          Thu, 2 Sep 2004 02:09:09 -0700 
List-archive:  http://www.imc.org/ietf-mxcomp/mail-archive/

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 present.

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

------------------------------------------------------------------------

From: "Lawrence Rosen" <lrosen@xxxxxxxxxxxx>
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 licensed.
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 terms.

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

cc: http://www.apache.org/foundation/docs/sender-id-position.html

[Source: http://www.imc.org/ietf-mxcomp/mail-archive/msg04019.html]

Prepared by Robin Cover for The XML Cover Pages archive. See other details in the news story "Apache Software Foundation Rejects Microsoft Patent License Agreement for Sender ID." General references in "Patents and Open Standards."

SEARCH Advanced Search ABOUT Site Map CP RSS Channel Contact Us Sponsoring CP About Our Sponsors NEWS Cover Stories Articles & Papers Press Releases CORE STANDARDS XML SGML Schemas XSL/XSLT/XPath XLink XML Query CSS SVG TECHNOLOGY REPORTS XML Applications General Apps Government Apps Academic Apps EVENTS LIBRARY Introductions FAQs Bibliography Technology and Society Semantics Tech Topics Software Related Standards Historic	Apache Software Foundation (ASF) Open Letter on Microsoft's Sender ID Patent License Agreement Apache Projects Unable to Deploy Sender ID Subject: DEPLOY: Apache projects unable to deploy Sender ID From: Greg Stein [Chairman, Apache Software Foundation] Date: Thu, 2 Sep 2004 02:09:09 -0700 List-archive: http://www.imc.org/ietf-mxcomp/mail-archive/ 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 present. We are in agreement with Larry's analysis of the incompatibilities of the current license: ------------------------------------------------------------------------ From: "Lawrence Rosen" <lrosen@xxxxxxxxxxxx> 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 licensed. 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 terms. 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 cc: http://www.apache.org/foundation/docs/sender-id-position.html [Source: http://www.imc.org/ietf-mxcomp/mail-archive/msg04019.html] Prepared by Robin Cover for The XML Cover Pages archive. See other details in the news story "Apache Software Foundation Rejects Microsoft Patent License Agreement for Sender ID." General references in "Patents and Open Standards."