Microsoft this month is moving forward with the developer implementation of its anti-spam Sender ID framework, but open-source advocates and mail vendors doubt whether the software giants new proposed license meets open-source requirements.
Sender ID is a proposed IETF (Internet Engineering Task Force) e-mail standard that combines Microsofts earlier Caller ID proposal with SPF (Sender Policy Framework), which was developed by Meng Weng Wong, founder of IC Group Inc.s Pobox.com. Sender ID is meant to stop many spam, virus and phishing attacks before they are launched by inspecting e-mail at the SMTP level to ensure that messages are actually coming from real users at recognized mail domains.
Sender ID has already gained market support. Both ISPs, such as AOL, and mail software and support companies, such as Cloudmark Inc. and Tumbleweed Communications Corp., have announced support for it. Microsoft has also announced that it will start using Sender ID for inbound e-mail to its hotmail.com, msn.com and microsoft.com domains in October.
Despite this groundswell of commercial support, Microsofts licensing requirements are incompatible with many open-source licenses, according to experts. This, in turn, means that Sender ID couldnt be implemented in open-source mail applications.
Richi Jennings, lead analyst for Ferris Research Inc., explained that Microsoft insists that anyone who implements the proposed standard “agree to their licensing requirements, since that standard will be in part based on their contributed IP.”
He continued: “The license appears to be incompatible with usual open-source practice, for several reasons. The most important one is that it precludes the use of GPL [General Public License] open-source license styles for any implementation, because your IP rights are not transferable to people who take your code and modify it, [and] your IP rights can only be used to implement this standard, nothing else. So you cant study how it works and adapt it.”
Lawrence Rosen, a partner in the law firm Rosenlaw & Einschlag and author of “Open Source Licensing: Software Freedom and Intellectual Property Law,” said he has “explained to Microsoft that their license is expressly incompatible with the warranty of provenance in the Academic Free License and the Open Software License.”
Specifically, he said, “the nontransferable, non-sublicenseable language in their reciprocal patent license 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.”
Rosen added that some issues go beyond just open-source concerns. “The requirement that If you would like a license from Microsoft (e.g., rebrand, redistribute), you need to contact Microsoft directly gives Microsoft information about its competitors plans that it has no reason to know.”
In addition, he said, “No open-source license—and all of them allow rebranding and distribution—can be conditioned on informing Microsoft of anything at all. Other proposed licenses have been rejected by OSI [Open Source Initiative] and FSF [Free Software Foundation] because they required licensees to notify the licensor of their intentions.”
Nevertheless, Rosen, on behalf of open-source developers, has been trying to get Microsoft to back down on these sticking points.
“For the last few weeks I have been quietly negotiating changes to the Microsoft Sender ID Patent License Agreement with the responsible attorney at Microsoft. I have kept Eben [Moglen, the FSFs general counsel] and several members of the IETF working group fully informed as those discussions proceeded. It has been a difficult chore because Microsoft objects to several of the important changes I asked for that could transform this into an open-source-compatible patent license,” he said.
“The absence of sublicensing is but one of the important concerns Ive raised with them. There are other parts of this agreement that would make it unacceptable if it were part of an open-source license although, in fairness, I should say that it is a far better license than Microsoft has ever offered before.”
Microsoft has made some changes to its license as per Rosens and other open-source advocates suggestions, but on the major issue of sublicensing, the company has remained firm.
That said, Microsoft might be willing to compromise on this issue in future versions of the license, according to Microsoft sources. Microsoft badly wants its patent accepted as part of an IETF standard. To do that, it may be necessary to compromise on the sublicensing issue.
Eric Allman, chief technology officer for Sendmail Inc., a leading mail server company, said, “In our discussions with Microsoft we were able to get them to make some improvements, at least to the point of making it clear that end users didnt have to execute a license with Microsoft.”
Allman added, “The fact that redistributors still do is a problem, and will probably prevent us from bundling Sender ID with Sendmail.”
As a result, Jennings noted, “if people implement Sender ID with the license as it stands, there will be an unreasonable amount of friction. It will therefore risk not reaching critical mass. If Sendmail doesnt implement Sender ID directly in its MTA [Mail Transfer Agent], its inevitable that Sender ID wont get used as widely as it would otherwise.”
In addition, he said that since “Microsoft has failed to meet the IETFs deadline for full disclosure of the licensing terms and applicable patent details, the momentum of opinion seems to be that Microsofts IP will be dropped from the standard, meaning that the IETF will standardize on a tweaked version of the original SPF proposal.”
Allman also isnt optimistic about Microsoft making Sender ID open-source friendly. “Its pretty clear that its going to take an act of whatever deity Microsoft worships in order to get them to back down on the sublicensing issue. They made it absolutely clear to us that they were not even going to consider changing this, and the legal folks made it further clear that they would rather see Sender ID die than back down.”
Still, there are efforts still afoot within both Microsoft and the open-source community to make Sender ID acceptable to the IETF and the open-source community, so its possible that Microsoft may yet change its Sender ID licensing requirements.
Microsoft did not respond to requests for comment.