Sender ID: Shakespearean Tragedy in the Making?

With a flair for the dramatic even Shakespeare might appreciate, commentator Larry Seltzer recently predicted that Sender ID — a spam-filter technology some call the “king of the e-mail security mountain” — would soon be history. “It’s a tragedy,” Seltzer wrote. “Microsoft’s uncompromising licensing attitudes show a blindness worthy of King Lear.”

Sender ID has been proposed to the Internet Engineering Task Force (IETF) for adoption as an industry-wide standard for e-mail authentication.

Rather than filter by message content — spammers know that most filters look for content, so they misspell words and add spaces to get past the filters — Sender ID filters by sender authentication and reputation scores for message senders, a technique attractive to ISPs.

The Sender ID specification combines Microsoft’s “Caller ID for E-mail” proposal, the Sender Policy Framework (SPF) proposal and a third specification called the Submitter Optimization. SPF might be familiar to end users who send e-mail from their own virtual domain through a large ISP, because several of the big players have activated SPF checking.

What’s the Catch?

Presumably to allay concerns that the IETF might adopt a standard that would require royalty payments, Microsoft announced that the use of the source code for its Caller ID for E-mail technology would be provided on a royalty-free basis. Not surprisingly, Microsoft’s offer comes with a catch: Users must sign their Royalty-Free Sender ID Patent License Agreement (RFSIPL).

While the RFSIPL seems to provide Microsoft’s technology at no cost to all comers, some are suspicious. Last week, Apache pulled its support of Sender ID, saying, “We believe that the current license is generally incompatible with open source, contrary to the practice of open Internet standards, and specifically incompatible with Apache License 2.0.”

Although it has its share of detractors, not everyone agrees that Sender ID is doomed. Besides the IETF, which reportedly is close to adopting Sender ID as the industry standard, several large ISPs are implementing it, including Microsoft for inbound e-mails to its hotmail.com, msn.com and microsoft.com domains.

As the plot thickens, will the suspense surrounding Sender ID end happily or embroil the characters in tragedy? Perhaps a closer look at the subplots will provide some answers.

Perils of Adopting Standards

Standards are rules that software developers agree to play by. Without standards, there is chaos. However, once a standard is adopted and applications are developed around that standard, it becomes very hard to change the rules without the community’s consent. Starting out on the wrong foot makes it harder to retrace your steps. This particular standard is likely to be implemented in the domain name system, a key Internet infrastructure that is hard to change.

Even though Microsoft released the source code, the open-source community is skeptical of Sender ID’s compatibility with the general public license (GPL). One reason is that the RFSIPL says that the source code is “nonsublicenseable” and “nontransferable.” Also, many open-source advocates are suspicious because the license requires anyone redistributing the open-source code with Sender ID technology to send a signed license to Microsoft.

Making source code available on a royalty-free basis does not convert it into free software. This is clearly stated in the GPL, which refers to freedom of use, not price. Until Microsoft relents on the restrictions on distribution, the RFSIPL is not compatible with the GPL.

Baby Steps or Sinister Conspiracy?

Some see the RFSIPL as Microsoft’s way of taking baby steps toward better relations with the open-source community. After all, Microsoft removed its original language requiring software developers who bundle Sender ID technology with a third-party solution to sign Microsoft’s agreement before proceeding. The language was replaced with a clarification that does not impose any obligation to require downstream recipients to accept an agreement with Microsoft.

However, those inclined toward conspiracy theories could interpret Sender ID as part of Microsoft’s grand scheme. Indeed, Free Software Foundation’s Richard Stallman warned, “This license is an example of Microsoft’s strategy for killing off free software as an alternative to Windows.” He called on the free software community to resist and to prevent Microsoft from “imposing whatever standards it likes.”

Beware of Half-Truths

The famous Shakespearean tale of MacBeth tells of a tragic hero whose downfall starts when he believes the half-truths of the three witches, who prophesied that he would be king. Likewise, beware of the fine print, exceptions and omissions in a contract. Look for what it does not say, not just what it says. For example, saying the RFSIPL is compatible with most major open-source licenses means it’s not compatible with every license, perhaps even the GPL.

Always read between the lines. The RFSIPL says: “Microsoft grants a nonexclusive, royalty-free, nontransferable, nonsublicenseable, personal license under Microsoft’s ‘Necessary Claims.'” The definition of “Necessary Claims” is drafted vaguely and subject to interpretation. It would likely have to be fought out in court to determine who owns the patents and if the patents are necessarily infringed by implementing the Sender ID specification.

‘Let’s Kill All the Lawyers’

Not so fast. Microsoft’s legal team has come under criticism for its uncompromising take-it-or-leave-it attitude on the Sender ID sublicensing issue, but the phrase “Let’s kill all the lawyers” from Shakespeare’s “Henry VI” is really a compliment to lawyers. It was uttered by the villain Dick the Butcher, who wanted to get rid of the lawyers to establish a dictatorship.

While some resent all lawyers, keep in mind that lawyers like Lawrence Rosen and Eben Moglen contribute significantly to the open-source cause. By all means, read the licenses. But if the legal liabilities are not clear, it’s advisable to seek legal counsel. Doing so before the fact is less expensive than discovering later that you must give away something you meant to keep proprietary.

This might sound idealistic, but if developers resist adoption, Microsoft might eventually decide to compromise on the sublicensing issue. A case in point is the XFree86 project, which created the once popular X server, originally licensed under a GPL-compatible MIT/X open-source license. When the XFree 86 license was changed to a non-GPL-compatible license, a mass exodus by developers and users led to the eventual demise of Project XFree86.

Microsoft understands money. If the open-source world en mass defies Microsoft and focuses on developing alternatives, Microsoft will realize that it is missing out on a viable market. At that point, joining a collaborative effort to find a solution to the spam problem might seem a lot more appealing to Microsoft.

The Real Tragedy

Even Seltzer admits that it would be helpful to co-opt Microsoft: “…think of the potential for a cooperative Microsoft: they could be a major part of a specification that helps to solve perhaps the biggest problem in computing today.”

Is Sender ID a Shakespearean tragedy in the making? Hardly, but e-mail users continue to labor under the crushing weight of spam overload. Meng Weng Wong, the coauthor of Sender ID, said: “I know that spam is like a drug in that people will go to almost any lengths, no matter how absurd, to send more of it. Sender ID and other spam filters cannot stop the flow of spam, but they can help domain holders prevent having their name forged by spammers. This in itself is an important step.”

Whatever the outcome of the Sender ID discussion, experts in both camps can agree on one point: No matter what progress is made in spam-filtering technology, the real tragedy is that spam is here to stay.