Sender ID, as you no doubt know, is a proposed IETF email standard that combines Microsoft's Caller ID with Meng Weng Wong's popular SPF. The combo is designed to make it difficult if not impossible to spoof an email sender address. It's also an anti-phishing technique. The problem is that Microsoft evidently -- at least so far -- believes that because it is offering to contribute a portion of the standard, and it has applied for a patent on the PRA algorithm, it should be able to control all of the standard by attaching restrictive licensing terms to their contribution, terms that would exclude GPL software from being able to use the standard.

Sounds fair to them.

Some in the FOSS community have already issued statements that they will not deploy Sender ID with its current we-hate-the-GPL license, including the Apache Foundation and the Debian Project. As Greg Stein, Chairman of the Apache Foundation writes at the end of their statement of nondeployment:

"[N]o company should be permitted IP rights over core Internet infrastructure."

Some things are just obvious. Are monopolies allowed to use almost-open standards as a weapon to cut off the competition's air supply? Don't answer that. I think that only works in the dark, not under the always-on bright lights of the Internet, and not any more, now that the community has grown up, has some muscle, and some corporate backing. Not only that, the Internet is largely a FOSS party, to which Microsoft arrived late. If the community refuses to implement Microsoft's almost-open standard, can it make Sender ID irrelevant? It actually is a toss-up as to who would be most damaged if Microsoft takes its patented ball and goes home rather than let the GPL play with it. Deeper, why is the IETF even considering a standard that so many can't or won't be able to use? Why doesn't it insist on open standards? This is turning into a clear demonstration of why open standards are not better than open source.

Is it possible this is more a culture clash, and all that is needed is a bit more education in Redmond, as some hope? Here's an interview with OSI's Larry Rosen, who clearly is doing his level best to make things work out, and if he says Microsoft is negotiating with him still in apparent good faith, then I take him at his word and hope for the best. On the other hand, you can read the recollections of a MessageLabs employee who attended a Microsoft-hosted Sender ID summit recently, if you'd like to evaluate that hope.

Or maybe it doesn't matter, because it might be that Eric Raymond has a Superman cape and will leap over tall buildings in a single bound and fly in to save the day. He mentioned tonight on The Linux Show that it seems he may have some prior art, in Fetchmail, which he promises to use to oppose Microsoft's patent, should one issue. That could come in handy, but since no one has seen Microsoft's patent, as Rosen points out, there really is no way to know if Raymond's code is prior art yet:

"Furthermore, there is a kind of common -- I don't mean that word in a derogatory sense -- but a typical impression of what prior art is about in the world of patent law. It's a little misunderstood, and so you have to look closely at the claims and the specification of the patent, and you have to look closely at the prior art, to determine whether something is in prior art or not. Merely to say, 'Gosh, that sounds familiar, I could have done that,' or 'I did that,' or 'Someone did that, something similar to that,' especially in absence of an actual patent, is real premature."

We are preparing a tutorial on how to identify prior art, which we will make available, on Grokline, when it's ready, but what Rosen is saying is that it's a complex task, and not necessarily intuitive. When the tutorial is ready, you'll understand fully what Rosen is saying. But the bottom line is, we don't know yet if Microsoft's patent is valid or not and we can't yet positively identify prior art yet. But the mere fact that it might be prior art means it may do something similar, in which case, as others point out, it might be an alternative solution, and since the IETF has a preference for non-encumbered code, it is conceivable that it could choose the Fetchmail solution instead. On the other hand, they don't have to. The relevant section of RFC 3668, section 8 reads like this:

"In general, IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing. But IETF working groups have the discretion to adopt technology with a commitment of fair and non-discriminatory terms, or even with no licensing commitment, if they feel that this technology is superior enough to alternatives with fewer IPR claims or free licensing to outweigh the potential cost of the licenses."

I believe we have just found the problem in this picture.

Microsoft is already pushing to get Sender ID adopted in the corporate sector, with or without the blessing of the full FOSS community, with some takers already. Sendmail is playing ball, although they have justified it oddly, saying that because Microsoft doesn't have a patent yet, it's a non-issue, and they just won't get a license, to which the only response has to be: what will you do when the patent is issued?

Microsoft's Bill Gates has fallen in love with patents, that we know, as you can see in this recent speech, and you know how compelling those fantasies can be. You can read Microsoft's intellectual property rights disclosure statement here.

The odd thing is, they are promising never, ever to charge for the patent, so why should they fight to keep the GPL out? Can you think of any good reasons?

You can download the license itself as a PDF. They explain their license and why they wish to encumber it in this paper [PDF]. I believe Microsoft would prefer that we all switch to BSD licenses. You can read some history of authenticating email in a thorough and thoroughly fascinating article by Joe Barr on Newsforge, Email Sender ID: The hype and the reality and its followup, "Sender ID: It's like Kerberos All Over Again", keeping in mind Rosen's tweaks to the narrative and that it isn't, from what I'm seeing, exactly like Kerberos, because the community has more strength and some corporate backing this time.

Legalities

So what, from the legal perspective, is it all about? So you can decide for yourself, here's a collection of materials on both sides of the argument. First, an explanation by an insider, Yakov Shafranovich, a co-founder and software architect with SolidMatrix Technologies, Inc., and former co-chair of the Anti-Spam Research Group (ASRG) of the Internet Research Task Force (IRTF), in the second of a two part series on Sender ID, "Sender ID: A Tale of Open Standards and Corporate Greed?" published in CircleID:

"After the new Microsoft license was published, it was reviewed by Eben Moglen, the legal counsel of the Free Software Foundation (FSF) and Larry Rosen, the legal counsel of the Open Source Initiative (OSI). They have both stated that this license is not compatible with the General Public License (GPL) and possibly other open source licenses (see DEPLOY: IPR/GPL). Microsoft lawyers have concurred with that analysis in regards to the GPL in their updated FAQ published a few days ago. Aside from this, the very act of Microsoft knowing about possible competitors in the email business, is in itself rather disturbing. And to stir the pot, the viewpoint of Microsoft lawyers on the subject is rather die hard and strange. They have stated that they would rather see Sender-ID die than change the license, according to Eric Allman of Sendmail. Eric commented on this by stating that 'It's pretty clear that it's going to take an act of whatever deity Microsoft worships in order to get them to back down on the sublicensing issue'."

Here is what Moglen wrote about the Microsoft patent license:

"The license posted by Microsoft is not compatible with GPL and is not a free software compatible license. There are several problems, of which the most severe is the requirement that anyone who wants to redistribute a covered implementation must execute a license with Microsoft. If you cannot give people code that they can redistribute without permission, you are not giving them free software. This would be the conclusion under all the meta-definitions of freedom: the OSD, the FSD, and the Debian FSG."

Here is an analyst's take on it:

"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 can't study how it works and adapt it.'"

As Rosen explains in the same article, there are additional issues besides the GPL incompatibility:

"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.'"

Here's the statement by Debian:

"The current Microsoft Royalty-Free Sender ID Patent License Agreement terms are a barrier to any Debian package which wants to implement Sender ID or include Sender ID support. We believe the current license and resulting encumbrances are incompatible with the DFSG, unlike other Internet standards that Debian is able to support. Therefore, we cannot implement or deploy Sender ID under the current license terms. Indeed, we would be forced to remove SenderID support from software we ship that does support Sender ID upstream according to the terms of our social contract.

"For the most part, our legal concerns mirror those of the Apache Software Foundation, the Free Software Foundation, as well as the Postfix, Exim, and Courier maintainers."

Here is what Richard Stallman had to say about the MS license:

"Microsoft's Sender-ID license is directly incompatible with free software regardless of which free software license is used. Free software means users are free to run it, study and modify the source, and to redistribute it with or without changes. Free to do so means there is no requirement to ask or tell anyone that you are doing so.

"The Microsoft license for Sender-ID directly forbids release of software with all these freedoms, so it is impossible for any program to be free software under Microsoft's regime.

"I've been expecting to see something like this ever since Gates started talking about spam. This license is an example of Microsoft's strategy for killing off free software as an alternative to Windows. Microsoft first patents something, then incorporates it into a format or protocol, then tries to make it de rigueur while excluding those it wishes to exclude. In the absence of resistance, Microsoft has a good chance of imposing whatever standards it likes. Let us, therefore, resist it here and now."

Here is the Apache Software Foundation's statement that it will not deploy Sender ID, sent to the MARID IETF working group:

"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"

They also reproduce attorney Larry Rosen's analysis of the Microsoft license:

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

A separate issue is whether Sender ID will actually work as promised. Some are posting to the ietf-mxcomp list that they won't be using it because they don't believe it is going to work to solve the problem. Others worry that it will cause network instability.

Microsoft's Side

Let's consider Microsoft's point of view and take a look at Microsoft's Sender ID license FAQ:

"Q13: Why can’t Microsoft make its patent license sub-licensable?
"A: Microsoft’s Royalty Free Sender ID Patent License does effectively enable every distributor and End Users in the licensee’s chain of distribution for its product to use the licensed patents rights from Microsoft in connection with licensee’s product according to the terms of the license agreement. The prohibition of sublicensing Microsoft’s patent rights outside of the licensee’s product in its chain of distributions is consistent with wide-spread industry practice.

"Q14: Can I distribute my implementation under an open source software license?
"A: Probably yes. While each open source software license may differ, we believe you can distribute your implementation under most open source software licenses, so long as you include the attribution stipulated in sec. 2.2 of Microsoft’s Royalty Free Sender ID Patent License. You should check with your own counsel if you have questions about a particular open source software license.

"Q15: Is Microsoft’s Royalty Free Sender ID Patent License compatible with the GPL?
"A: Unlike other open source software licenses, the GPL includes a provision that appears to prohibit the distribution of code that is subject to patent licenses that are not sub-licensable and/or are limited for a particular purpose like implementing a specification. While almost all open source licenses require that the code be freely modifiable and redistributable with or without modification, only the GPL appears to expressly prohibit distribution of code if those requirements can not be satisfied. Microsoft's Royalty Free Sender ID Patent License Agreement does not prohibit the use of any open source license including the GPL. However, because the Royalty Free Sender ID Patent License Agreement is offered for implementation, distribution and use of the specification, Microsoft believes that the GPL would prohibit the distribution of this patented technology. As discussed in the answer to Question 7, it might be possible to use and distribute Sender ID implementations with Linux and other software released under the GPL.

"Q16: What happens if I combine my Sender ID implementation with GPL code?
" A: Where conditions of the GPL can not be satisfied, the GPL prohibits you from distributing your code under the GPL. If you combine your Sender ID implementation with code that purports to subject your Sender ID implementation to the terms of the GPL, you could be violating this requirement of the GPL. You should seek your own counsel concerning whether or not your implementation would be subjected to the GPL and, if so, whether the GPL would prohibit the distribution of your code. The Free Software Foundation www.fsf.org may also be an appropriate source for your inquiries about the GPL."

Huh? It's the GPL's fault it will be ghettoized? Hmm. And what does Question 7 offer in the way of relief?

"Q7: Is Microsoft’s license compatible with Sendmail, Postfix and Qmail?
A: 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 Microsoft’s 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 Microsoft’s royalty-free patent license."

I gather the relief proposed is that you give up the GPL. No doubt that would cause MS intense relief. After statementes from Eben Moglen, Larry Rosen and Richard Stallman that the Microsoft license is not compatible with the GPL, how can Microsoft write in good conscience that "it might be possible to use and distribute Sender ID implementations with Linux and other software released under the GPL"? It's not possible, and clearly they know that. I find this Question 18 in Microsoft's FAQ troubling as well:

"Q18: As a user of a mail product or service which includes Sender ID, what license must I use?
"A: End Users who are recipients of an implementation of Sender ID are already licensed under Microsoft’s Royalty Agreement."

Yikes. Please. No automatic licenses. Where do I opt out? Details on SPF are at http://spf.pobox.com/. Microsoft describes how Sender ID works like this:

"Sender ID works in a three-step process.

1. E-mail senders, large or small, publish the Internet Protocol (IP) addresses of their outbound e-mail servers in the Domain Name System (DNS) in a text format described in the Sender ID specification.

2. Receiving e-mail systems examine each message to determine the purported responsible domain, that is, the Internet address that purports to have sent the message.

3. Receiving e-mail systems query DNS for the list of outbound e-mail server IP addresses published by the purported responsible domain. They then check whether the IP address from which the message was received is on that list. If no match is found, the message has most likely been spoofed."

Enough of Microsoft's point of view. These are the folks who in their most recent annual report for the fiscal year ended June 30, 2004, wrote that Linux is "derived from Unix" and I'm sure we all know what they mean.

Living Without Microsoft?

There is a two-part interview with Weng Meng Wong which is helpful because it makes very clear that it is absolutely possible to continue with SPF, with or without Microsoft's involvement. But it also explains why some thought it would have been nice to have MS's Caller ID merged with SPF:

"Meng Wong: In May, Microsoft agreed to adopt SPF's syntax and semantics for their Caller ID proposal. The result, which we're calling SenderID, applies SPF checks to the Purported Responsible Address from the message headers. I believe it represents the best of both worlds. The best thing about the CallerID proposal was the use of XML, which provides a path to future extensibility. SenderID uses a dual-syntax model: because the core semantics are drawn from SPF but are expressed in XML, SenderID clients will be able to parse both XML and regular SPF records. This means that if, in the future, the SPF syntax runs out of steam, and we need to say things that can't be said in the SPF language, we can upgrade to XML with a minimum of pain.

"Meanwhile, SPF Classic, which applies SPF checks to the return-path, is still going strong. It is more mature and is better understood; it continues to enjoy a lot of support in the open community. Many people on the MARID mailing list have argued that SPF Classic and SenderID can and should proceed in parallel, especially since they both use the exact same records but can be used for two mutually compatible purposes....

"The big players wanted CallerID and SPF to converge because they were both designated sender schemes. It didn't make sense to have two different syntaxes and two different semantics for two different identities, because receivers would have to code up two sets of functions that do basically the same thing, and publishers would have to publish two records that say the same thing. Now that Microsoft has committed to remain backward-compatible with the SPF syntax, publishers don't have to worry about publishing both, and receivers don't have to worry about parsing both."

As Barr notes in his article, Paul Vixie, Founder & Chairman of Internet Software Consortium, who wrote the "Repudiating Mail-From" paper in 2002 and is the author of BIND, noted in a comment attached to the first CircleID.com interview with Meng Wong about SPF that he has low expectations for success for Sender ID and he also highlights an alternative:

"I very much wish that I had jumped on this in 1998 when I first heard about it, and that the community had implemented this before Y2K, so that e-mail could be nearly forgery-free by now. Instead, the IETF ASRG is still trying to merge the merged CallerID/SPF proposal with some other competing work, and the final result is very much an open issue.

"Finally, an observation. After co-founding MAPS and turning that crank for a number of years, 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. No 'designated sender scheme' will ever be able to cut down the amount of spam that's sent, or received. All it can do is help domain holders avoid the brand dilution of having their domain name forged by spammers. This is a valuable contribution, but we must make it clear that none of these schemes will stop or even slow spam, and that their benefits accrue to domain holders, not to spam recipients."

Here's a spam proposal [PDF], by the AntiSpam Technical Alliance, whose members are Microsoft, Yahoo, AOL, British Telecom, Comcast, and Earthlink. Even it acknowledges there is no one, complete solution:

"This Statement of Intent (SOI) document presents best practices and technologies that ASTA members are implementing to help secure the e-mail infrastructure and bring increased accountability. We fully recognize that this document does not provide all solutions to the spam problem and intend to update and enhance this SOI over time. However, we feel that our recommendations, if implemented on a large scale, can be successful in improving e-mail messaging and Internet communications in general. Because we represent a large percentage of mailboxes on the Internet, we hope to provide the necessary leadership to ensure large-scale adoption within a relatively short period of time. . . .

"We also recognize that there is not one easy solution to the spam problem; solutions for handling spam are technically challenging and may take considerable time and effort to implement. This is why we have chosen to pursue multiple approaches: those that can be implemented quickly as well as those that may take more effort and time but have a greater impact. . . .

"We recognize that our recommendations may be applicable to other areas of the Internet and encourage the adoption of these technologies in other protocols as appropriate, for example, instant messaging (IM), Short Message Service (SMS), Hypertext Transport Protocol (HTTP), Network News Transport Protocol (NNTP), and so on."

Here's something that has sprung up, developed at Australia's Queensland University, to cope with spam, using a statistical learning method to categorize emails. They are applying for a patent also, I gather. Spam is big business, no matter what angle you look at it. In Gates' recent speech, he talked about machine learning and spam:

"If you have a spam recognizer that's kind of hard coded, the people who generate the spam just watch, generate new things, and they get around whatever your specific word checks might be. The only way to make it tough for them is to do what is called 'machine learning.' That is, have a base of what's not spam and what is spam, and then have software go through and look at that and say, okay, what word frequencies are different? What kind of Web sites are linked to? What kind of imagery might be connected with this? And by doing that you make sure that it's actually resilient as they change their techniques, you see how they're changing their techniques, and it adapts to that."

Yakov Shafranovich, in the first of his two-part explanation of the flap on Circle ID notes prior authentication solutions. He mentions Paul Vixie's MAIL-FROM suggestion back in the 90s:

"Back in 1997, right after Paul Vixie, the author of BIND, established MAPS and blacklists, he received a message from Jim Miller describing the idea of using DNS to authenticate incoming mail hosts (copy of the message appears here). In 2002, Paul Vixie wrote it up as a draft and posted it to an IETF list (original draft). At the same time, David Green posted a draft with the similar idea (original draft). At the end of 2002, Hadmut Danisch published the first draft of Reverse Mail eXchanger protocol otherwise known as RMX. The main idea that all of these proposals were pursuing is the closure of one of the loopholes in the original design of the email system. The original SMTP protocol provided no measure to check whether any of the sender's information provided in the SMTP transaction is actually valid. These proposals added an ability to check whether a specific domain had authorized this SMTP server to use its name in the MAIL FROM command, which is used to indicate the address to which bounces are sent. However, due to the lack of interest or perhaps more accurately lack of proof that this would actually help reduce spam, no one acted on their proposals and they simply faded away."

Then, as Shafranovich explains, as spam became more of a problem, a number of factors caused the issue to come to the fore, and here is the Microsoft element in this history:

"At the same time, Microsoft has begun circulating its proposal among various ISPs and industry leaders, and also begun talks with Meng Wong of SPF. In the winter of 2004, right before the Seoul meeting, Microsoft publicly announced its proposal in a speech by Bill Gates at the RSA Conference. The proposal did not differ significantly from the existing ones, except for two parts: the use of XML for encoding data instead of plain text like SPF did or new DNS record types like RMX); and an algorithm for checking Caller-ID information based on email headers inside an email client, as opposed to using the SMTP transaction inside an email server. Microsoft wanted to deploy Caller-ID inside Outlook and Outlook Express so they came up with this algorithm which become known as 'Purported Responsible Address' or PRA. It was eventually published as a separate Internet draft.

"Many members of the anti-spam community still think that the entire sender authentication set of proposals may not accomplish anything at all, even with the proposed reputation extensions."

Paul Vixie added a comment to this article as well:

"This whole debate is silly. There will never be a universal standard for e-mail authorship verification, no matter what IETF MARID or Microsoft do. Let a thousand flowers bloom. SPF works. Jim Miller's MAIL-FROM . . . works. Domain holders can put in metadata for all the verification styles they consider relevant, and mailserver administrators can look up the ones they consider relevant. Let's stop debating this and start implementing it. We're bogging down on questions of IPR and authorship when the fact is that a single standard isn't necessary (or possible). It's clear that IETF just can't settle this kind of controversy -- but we all know that market forces can."

As I understand it, Sender ID doesn't do a thing for spam, except make it harder to spoof a sender address. I'd personally love that, because people use my email address to send spam sometimes, and it bothers me greatly to have my name used that way. I felt better knowing I am not the only victim, Vixie himself being a victim of email forging. But what I noticed in reading the ASTA Statement of Intent is that Microsoft's interest in this field of Sender ID doesn't match the interests of the FOSS community outside the email forgery context, because we don't suffer from some of their kinds of problems:

"Summary of Best Practices

"Much of the spam today is generated by spammers exploiting a security flaw in the configuration and application software used to support Internet communications. This includes proxy software, mail server software, and CGI scripts that act as open relays or proxies upon initial installation. More recently, criminals have been creating viruses and worms specifically designed to infect and compromise personal computers around the world. These computers, sometimes called zombies, can then be controlled by spammers and used to send out spam on their behalf. Security is paramount in order to combat these issues."

I think the fact that the zombie computers are Microsoft computers is worth mentioning. Remember when Darl McBride asked the audience during his Harvard speech about the MyDoom virus? He asked if any there got infected and thus were part of the problem of zombies hammering SCO's site, and one person said, No, I use Linux so I didn't get infected.

By the way, it has now been pretty much confirmed that the virus that attacked SCO was written by expatriate Russian programmers with mob connections, for the purposes of spreading spam and pornography via zombie computers, not Linux "zealots", as SCO accused:

"The link between viruses, worms and the underground criminal economy, however, goes back to long before the latest version of MyDoom, says Mikko Hypponen, antivirus research director at F-Secure Corp. in Helsinki, Finland. Starting with the initial outbreak of MyDoom in January, Hypponen began to notice that what had previously been considered little more than a rogue virus-writing subculture actually had a significant link to organized efforts to use malicious code to make money.

"'MyDoom got press coverage because of the denial-of-service attack it launched against SCO and Microsoft Corp.,' says Hypponen. 'But nobody was paying attention to what was happening behind the scenes.'

"And what was happening, according to Hypponen, was the beginning of a concerted, unabashed effort to turn virus and worm infections into cash.

"Eight days after MyDoom.A hit the Internet, somebody scanned millions of IP addresses looking for the back door left by the worm, said Hypponen. The attackers searched for systems with a Trojan horse called Mitglieder installed and then used those systems as their spam engines. As a result, millions of computers across the Internet were now for sale to the underground spam community. . . .

"'We have information that the writers of both MyDoom and Bagle may be Russian immigrants living in various European countries,' says Hypponen."

I wouldn't say *nobody* was paying attention. Groklaw, for one, covered this story from day one, here and here and here.

Shafranovich points out the culture clash going on here in the Sendmail story:

"Taking a step back we see a glaring contrast between the acts of Microsoft and of others involved in these proposals. While the various authors of sender authentication proposals have based parts of their drafts on other drafts, none of them filed for patents (although SPF authors considered filing a defensive patent). While there have been disagreements and some heated arguments about acknowledgements, nevertheless these are not issues that affect implementors. It turned out to be what the open standards process is all about -- building standards together in an open fashion very similar to the way FOSS operates. On the other hand, Microsoft is claiming IPR in proposals that may very well not even be theirs, which evolved in an open discussion, is asking for a restrictive license, and refusing to consider the market truth -- that most of email server software is FOSS and might not be able to use this standard. Their claim of a defensive patent does not hold water since other companies have managed differently and there are other ways to accomplish the same goal. The fact that FOSS is Microsoft's greatest competitor at this time, does not help their image as many including governments may start to wonder whether Microsoft is using standards development as a backdoor to killing FOSS."

Speaking of prior art, there is already a lawsuit promised over SenderID, which F. Scott Deaver, owner of Failsafe Designs, claims is a ripoff of his work violating both his pending patent and his trademark ("Caller ID for E-Mail"), which further complicates using CallerID as part of a standard, since he threatens to sue anybody who uses his technology, not just Microsoft.

And at the end of the day, that's the apparent bottom line: that Microsoft would like to use standards to destroy the GPL and with it its primary competition. As Barr writes, it's a play to separate the GPL from the rest of the community, so everyone will use the BSD-style license instead, with some success:

"Sendmail author Eric Allman told us last week, when we asked if the licensing terms had prevented them releasing a Sender ID solution, that:

'It's true that we were unclear about the previous version of the license, and that was one part of holding off. There were other issues -- for example, we had Caller ID ready to go about the same time as it morphed into Sender ID, and we felt it was better to wait. In any case, we believe the terms of the new license to be acceptable.'

"And to demonstrate just how acceptable Microsoft's new licensing terms are to part of the free software community -- and just how deftly Microsoft is playing BSD-style licenses against the GPL -- Sendmail yesterday announced its new open source Sender ID plug-in."

Acceptable? To whom? Actually, it's not a big surprise. Sendmail endorsed CallerID back in February. I view this article about how unimportant it is to mention the word free any more as another part of the problem. Some think that as long as the license is "royalty-free", that is enough. Here a Microsoft spokesman:

"'It's a little baffling why this issue in particular has gotten so much attention because our intentions are 100 percent pure; we have a pretty good track record on spam and how we've made an effort to make no money to solve this for our customers and anyone else's customers as well.

"'We have never and will never charge any money whatsoever for this patent,' he said. 'The patent, which has not been granted yet, was filed mostly as a defensive measure down the road should people come back at us and file an IP-based lawsuit.'"

It isn't about money. I have decided that the expression "Open standards are better than Open Source" has a necessary rejoinder: Freedom trumps everything. The freedom to cooperate and follow the scientific method of development, to modify and learn, is important enough that nothing can substitute for it. It's really that simple. And yes, free software matters, and it's not dead unless you kill it, or stand by and let it be killed.

Let's remember what the word "open" means. It doesn't mean that Microsoft or SCO or any other proprietary company gets to muscle their way in and coopt other people's work, give it a tweak, and then call it their own. It also shouldn't mean they get to impose a restrictive license on a standard so that the largest body of FOSS is excluded.

Why do you think Microsoft prefers the BSD license? Just imagine if the Linux kernel had been licensed under a BSD license instead of the GPL and then SCO came along. I'm glad the Sender ID flap happened. Unless Microsoft changes its stance, it will be clear to everyone, most especially standards bodies, that Microsoft is slapping the GPL across the face with their glove, and it will be obvious that they intend it to be a fight to the death. Any standards body that allows that to happen has failed in its primary mission.