decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
Unix Books


Groklaw Gear

Click here to send an email to the editor of this weblog.

You won't find me on Facebook


Donate Paypal

No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.

What's New

No new stories

COMMENTS last 48 hrs
No new comments


hosted by ibiblio

On servers donated to ibiblio by AMD.

Sender ID and Almost-Open Standards
Tuesday, September 07 2004 @ 09:27 PM EDT

I've been reading about Sender ID and the flap about Microsoft's difficulty in playing nicely with others. It's a story that refuses to stand still. For three days, I've had an article ready, and then pulled it at the last minute when something new happened. Now I've decided to just tell you what I know so far and suggest you stay tuned for breaking developments. There is a lot of information, so feel free to skim. The last call period for Sender ID ends on Friday, which means the IETF must make a decision then on what to do about all this.

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.


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


Sender ID and Almost-Open Standards | 365 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
OT Here Please
Authored by: Anonymous on Wednesday, September 08 2004 @ 05:43 AM EDT

[ Reply to This | # ]

Terms that would exclude GPL software
Authored by: Anonymous on Wednesday, September 08 2004 @ 05:45 AM EDT
Terms that would exclude GPL software are not of themselves a problem as far as
the Apache folks are concerned, yet ASF finds these unacceptable. Your intro
could thus be considered misleading, which is unfortunate given the confusion
between GPL and OSS (the former is of course a subset of the latter).

[ Reply to This | # ]

Eric Raymond and Prior Art
Authored by: MathFox on Wednesday, September 08 2004 @ 06:01 AM EDT
Without further information from Microsoft on their patent claims I am very
sceptic about the validity of their SPF license.

Let's stop throwing mud.

When people start to comment on the form of the message, it is a sign that they
have problems to accept the truth of the message.

[ Reply to This | # ]

Corrections here please
Authored by: Anonymous on Wednesday, September 08 2004 @ 06:02 AM EDT
If there are any...

[ Reply to This | # ]

Another Microsoft embrace, extend and own tactic!
Authored by: Anonymous on Wednesday, September 08 2004 @ 06:06 AM EDT
Microsoft has dreamed of owning the internet for a long time.

Oh for any prior art regarding the internet - just ask Al Gore who at one time
said that he was responsible for the internet.
The only thing he will have a problem with is that Bill Gates has most likely
patented the idea and so Al will get nothing for his invention.

Seriously, if Microsoft wins this one... they will end up owning the internet.
As most e-mail will use this critical invention and the MS patent can be used to
stop or hinder anyone from making something that will work with it.

Just ask Al, he will know...

[ Reply to This | # ]

Neat trick
Authored by: moggie on Wednesday, September 08 2004 @ 06:15 AM EDT
Nice business model Microsoft have there, eh? Populate the world with spam
zombies, then ride to the rescue with a supposed solution which could destroy
your competitors.

[ Reply to This | # ]

Sender ID and Almost-Open Standards: don't worry; be happy
Authored by: Anonymous on Wednesday, September 08 2004 @ 06:20 AM EDT
M$ can NOT win win, ever. Freedom of speach is a unalienabl right in any free
society == Vox Populi, Vox Deo.

The fact of the matter is that M$ is realising that it is facing an unbeatable
foe -- this is the begining of the end. We'll talk again in 5 years time, when
people say: "I wonder what happened to that Microsoft crowd?"

Simply trust democracy and freedom, guys. It brought down the Soviet Union --
how can M$ hope to fight that?

[ Reply to This | # ]

What we need is a decent whitelist
Authored by: Anonymous on Wednesday, September 08 2004 @ 06:31 AM EDT
I have read lots recently about how SPF and Sender-ID are great for stopping
phishing, but won't fix the problem of spam because spammers will (and indeed
are) simply publishing their own SPF records.
But, that problem will go away if/when a proper whitelist of non-spamming
domains gets published. If you think about it, most of the world non-spam email
comes from a relatively small number of domains (probably a few hundred). These
are the big ISPs (who presumably rigorously block any customer trying to send
spam), the big webmail companies (e.g. Hotmail) and big corporations. Once they
are on a whitelist, any mail which appears to come from them and passes SPF can
sail right past our anti-spam filters. We can then crank up the gain on our
filters without being too concerned about the problem of false positives, since
very few legitimate emails will enter the filter in the first place.
What we need is for the IETF to stop dickering about trying to define a standard
for sender checking and establish a standard for whitelists.

[ Reply to This | # ]

Sender ID and Almost-Open Standards
Authored by: Anonymous on Wednesday, September 08 2004 @ 06:44 AM EDT
What ever happens, I am with Richard Stallman on this one. Microsoft should be
resisted at every turn to submit a patented, licenced piece of software to what
could end up being a core Internet protocol.

It has to be _free_ and FOSS for all to benefit and make it work correctly.


[ Reply to This | # ]

Spamassassin is an Apache project
Authored by: jeleinweber on Wednesday, September 08 2004 @ 07:00 AM EDT
One subtle point that I haven't seen emphasized enough in the discussion of
Microsoft, MARID, and software patents is that the extremely popular
Spamassassin software put itself under the Apache umbrella a while back. The
rejection of Microsoft's Licensing terms by the Apache Software Foundation has
very large implications in the anti-spam community. Kind of like if the ISC,
which writes BIND, objected to a DNS proposal.

Note that many commercial anti-spam solutions are based in part on Spamassassin.
So Microsoft may be fighting more than just the open source community on this
one. However, Spamasssisin is distributed under the Apache license, which is
BSD-like, and doesn't prohibit taking changes private. There is a danger that
Microsoft could get the Spamassassin community to fork, with the commercial
versions obtaining Microsoft licenses, but the open source versions not being
able to. I'm sure their embace/extend/extinguish agenda would love that

You'd think by now that people would have figured out that you can't get a
standard widely adopted if it is encumbered with licensing restrictions; we've
seen stuff fail before. The main counterexample is in digital media, where most
of the formats and/or codecs require onerous licensing terms.

Sender-id looks to me like an important test case: is the DCMA camp going to be
able to pollute the IETF, perhaps marginalizing it in the process, or will the
traditional scientific community assert itself? Open source and open protocols
are squarely in the scientific tradition of peer review and building on the work
of others.

-- Jim Leinweber (Madison, WI)

[ Reply to This | # ]

Sender ID and Almost-Open Standards
Authored by: WBHACKER on Wednesday, September 08 2004 @ 07:03 AM EDT
Once again, as a community, we are starting 'late' to look at a problem and potential solutions without paying attention to older 'lessons learned'.

DARPANET, successors, and the national security needs which gave rise to them did not vanish in a puff of smoke.

Current internet mail practices seem to be ubiquitous, but are - still, yet, today - not the only way to move messages electronically, nor have they excluded other means.

We cannot easily know everything that we would wish to know about the private intranets of major corporations or governments, but we can be aware that they have largely been implemented with Open standards and F/OSS software - carefully and intelligently configured.

One might have a read of "Top Secret Intranet", by F. T. Martin. Prentice-hall, 1997. It is reasonable to presume that things have moved on w/r secure government networks in the seven years since that was written - and not as much in the direction of Redmond as desktops have done.

IMHO, there is too much movement towards 'agreeing a solution' w/r Sender-ID, and not enough breadth of review of possibly better alternatives.

Just how useful to anyone but a public body or social/professional group, is a methodology designed primarily to 'vet' incoming mail from 'all comers' , anyway?

Seems to me all that does is open the door to 'legitimate' advertisers, i.e. 'MS licensed' vs the other kind.

Those engaged in regular correspondence are more securely served by challenge-confirm "whitelist" generators, and - if justified - mutual exchange of PEM certs or use of a VPN.

Would a move, for example, to IVP6, reduce, or even obviate this need altogether?

This entire intiative can very easily be simply dropped on the floor with little or nothing lost if Microsoft - or anyone else - doesn't care to play by Open' rules.

And speaking of the cure being potentially worse than a disease it won't cure anyway - have we forgotten that simply blocking all 'hotmail' and 'msn' incoming on a mail server (forged or genuine), cuts the spam load dramatically?

Is Microsoft just seeking a way around that, as 'doubleclick' has done by purchasing Verisign certs to sneak adverts and spyware in under the browser's http radar by use of the 'pre-approved' https CA chains?

The patent issue is only the tip of the iceberg w/r the owner of hotmail, msn, msnbc, and others.

Bill Hacker

[ Reply to This | # ]

For things to work out
Authored by: Anonymous on Wednesday, September 08 2004 @ 07:08 AM EDT
All the planets have to be in line.

A better solution will arrive with less problems,best to
forget this and move on. Let it stand as a lesson to those
that support the current US patent system.

[ Reply to This | # ]

Oh great - the LAWYERS are sorting it out
Authored by: Anonymous on Wednesday, September 08 2004 @ 07:22 AM EDT
That said, if FOSS in the form of SPF is so all-fired good, would we even be
having this debate? If there's a FOSS out there that's *better* than SenderID,
then let's hear about it.

[ Reply to This | # ]

maybe this is contreversial, but...
Authored by: Anonymous on Wednesday, September 08 2004 @ 07:49 AM EDT
I think what's happenning here is Microsoft genuinely think they should be
allowed to re-build the internet and email system with their software and
standards. I'm sure they're all for other people helping, but they just want to
be in control.

They're probably scratching their heads and being amazed at the resistance to
sender-id, especially as they aren't charging for it.

I think that expecting a company that got to be the worlds most powerful
software provider by selling software to embrace Open source ideal's is frankly,
absurd. Yes they've done a little, but nothing of significance.

I refer people to Bill Gates 'Open Letter to hobbyists'.
He, and his company, simply don't give away their hard work without charging in
some way, either through making money, or gaining some control over something.
It's just not in their psyche.

Is this wrong? In a pure business sense, no. In fact it's common practice.
They're so powerful though, that something that would be normal competitive
practice is usually devastating to their opponant/s. Again I suspect they see
nothing wrong with this 'To the victor the spoils' and all that.

The Open source community (of which I am a member) thinks differently, and has a
right to.
I find it interesting that one one side we have m$ saying they don't think
there's a problem, and it seems, saying that all people have to do is either not
use the gpl, or just quite whining and use the standard, and on the other side,
the Open source people refusing to use the m$ licence terms.

I suspect neither will change their mind, and as a result, consumers of software
(the people a lot of write our stuff for) will be the one's who suffer.

So what exactly is this? An attempt to solve the spam problem? Or a power/ego
struggle? In normal situations where either side cannot agree, Arbitration is
called for. Who can arbitrate this so that the important things can be got on
with? like killing off spam.

Why not implement Sender-ID as is and see if it works? It may not, and then the
FOSS community can try to make something better. The point is, they have a
solution now, and while we argue about it, ordinary computer user's are
suffering, kids are getting pron in their inboxes, and vulnerable people are
getting scammed.

Grow up and implement something now is what I say. Argue about it later.

[ Reply to This | # ]

How old is the patent app, I might have personal prior art
Authored by: Anonymous on Wednesday, September 08 2004 @ 08:17 AM EDT
I have been thinking about the spam problem for a long time now, and this sender
ID thing sounds like it is a portion of a solution I came up with. Not being a
member of any organization, I sat on it for a long time as just another
satisfying mental exercise. About a year ago, I decided I should post it
somewhere so I didn't loose track of my thoughts. I posted it on slashdot (but
I don't think anyone read it). ( Microsoft
probably has notes going back many years, so this is probably not prior art.

[ Reply to This | # ]

Sender ID and Almost-Open Standards
Authored by: Geertsema on Wednesday, September 08 2004 @ 08:30 AM EDT
Read a BBC news article: Spammers exploit anti-spam trap. Some spammers are getting their messages through using techniques designed to spot and stop them. A survey shows that spammers are the biggest users of a technique designed to find out if e-mail comes from the net address it says it does... _stats There is more work to do before we can use this technology

[ Reply to This | # ]

OT: IBM's next move?
Authored by: Wol on Wednesday, September 08 2004 @ 08:32 AM EDT
Posted here for the sake of somewhere to post it ...

Now that it looks like IBM are going to get their three PSJ's, what's the chance
that their immediate move after that will be to sue McBride and Stowell?

Basically, sue them *personally* for libel, slander, and malicious prosecution.
Use as evidence all their statements about "mountains of evidence" etc
etc. Plus the fact that SCO have produced none of this in the current SCO vs IBM

Basically, the complaint would be "they haven't produced any evidence in
the current lawsuit, and the only reasonable conclusion is they haven't got any.
Therefore they *must* have known they were lying".

The result is a very nasty catch-22 :-)

DMB and BS can ask for the this case to be joined with the current SCO/IBM case.
In which case they're sunk - they can't introduce all this evidence because it's
too late and they *personally* go down with the SCO ship.

Or they fight the case themselves, produce no evidence, and go down by

Or they fight the case themselves, produce all this stuff (while admitting that,
in hindsight, it turned out not to be valid), and hope to get themselves off the
hook against IBM. While this would probably succeed ...

They will have effectively admitted to the SEC that they ran a scam. Anybody who
lost money in the stock gyrations will be able to sue for ?criminal? negligence
in that they have admitted that they launched a lawsuit with no evidence ... etc
etc etc.

And it'll sink the SCO ship - not just by opening the scuttlecocks but by
blowing them to bits!

I guess that's why His Darlness is looking so haggard. I really cannot see any
serious downside for IBM in this scenario - they can really argue that "on
information and belief" they have a case that deserves an answer. The
trouble for Darl is that if he doesn't give an answer then the case would ruin
him, but if he does give an answer IBM can walk away with almost no penalty. And
to make matters worse for Darl, that answer would lay him wide open to other
claims - for all of which he would be *personally* liable!


[ Reply to This | # ]

Isn't this kinda easy to defeat?
Authored by: Anonymous on Wednesday, September 08 2004 @ 08:36 AM EDT
The GPL is about distribution, not the use of the software. So just don't
distribute sender-ID code with GPL software, distribute it seperatly then there
is no violation of the GPL.

And if sender-ID does get accepted, have a few dozen sites set up central
repositories for distributing sender-ID for the rest of the community and it
will be business as usual until we find an implimentation that works.

[ Reply to This | # ]

Fake patents
Authored by: Dark on Wednesday, September 08 2004 @ 08:37 AM EDT
What I find amazing is that Microsoft is able to do all this without even having
a patent. They just have a patent application, and they're not even saying what
it's about, and in any sane world a patent on this protocol would be denied for
obviousness anyway. (How do you figure out if a message you receive is forged?
You ask the purported sender if it's real. Duh. That's all that SenderID does.)

When we finally see this patent it'll probably turn out to be something trivial
that we can easily work around, or else something so broad that it covers all
SPF-like solutions.

[ Reply to This | # ]

Spam filters and search engines.
Authored by: Brian S. on Wednesday, September 08 2004 @ 08:41 AM EDT
Although Google may currently top the list, most people have their favorite
search engines, I assume because generally they get the kind of answers they
want in the format they want. There are probably hundreds of small unknown
search engines providing answers for specialist users. One thing they all have
in common is they must compute their answers from the information they can gain
on the web.

One thing that PJ's article seems to confirm is that the sender's info. to be
used for screening the mail is unencumbered with IP. It therefore seems to me
that the receiver can make a choice on how they want to filter their mail. Some
lonely? people like junk mail. I don't know of anyone who wants a virus except
perhaps the likes of Symantec who may want to actually attract them.

Maybe a user should be able to make the choice of what email they wish screened
out and who's version of software they think will do the job best for them. Just
like I screen my snail mail my way (50% in the bin) before I read it, it is my
choice to make based on what I see visible on the outside.

As long as the sender info. is there for all to examine, maybe there is room for
various versions of receiver screening, (even with options?).

Looked at this way, it makes M$ attitude seem even worse. Attempting to make a
default, basic system unavailable to all.

They won't win this. It's not their choice. I choose which newspaper I read, I
choose which snailmail to open, I choose which search engine to use.

There must be many ways around M$ IP and judging on past results they will
probably be better. If M$ persists in going their own way maybe their sender ID
will end up with as many problems as IE.

Brian S.

[ Reply to This | # ]

Counter proposal
Authored by: ajrs on Wednesday, September 08 2004 @ 08:51 AM EDT
Proposal to reduce SPAM

I have a proposal for reducing spam by requiring email to
be verified
by the originating domain.

Each email would be digitally signed by the sender. The
receiver could either A) request a public key to validate
signature, or B) deliver the entire message for
authentication. If the
message was not authenticated, it would be discarded by
the receiver.


reduce or eliminate forged email addresses.
identify original source of email.


prevent legitimate anonymous email.
additional network and processing overhead.
incomparability with existing systems, especially uucp.

Details of Public Key Server Method

The cost of verifying an email would be shared between the
sender and
receiver.The sender would be required to sign each email
and provide a
public key server. Given the signature and the time stamp
of the
signed email, the sender would confirm the source of the
email by
providing the public key used to sign the message. The
receiver would
use the public key to validate the signature on the
message. This
method would be preferred initially, as it requires no
change to the
receiving server, only the sending and receiving clients.

Details of Authenticate

sample dialog with passive validation (default, old SMTP)


sample delayed validation


sample dialog with aggressive verification

mail server:
public key

key server:

sample dialog with encrypted connection

mail server:

This would ensure that the burden of validating an email
is the
explicit responsibility of the sender. Any email that
didn't match the
key provided by the server would be discarded. Each ISP
would be
resopnsible for validating the source of email from within
its own
network. ISPs responsible for excessive spam could be

Key server requirements:

each key server may provide public key as requested, given
a signature
and time stamp.

Sending server requirements:

each sending server shall sign each email with a valid

Receiving server requirements:

Each receiving server shall remove any existing
validation. Each
receiving server may validate the signature and mark the
email as
valid, invalid, or indeterminate.


denial of service on the key server:

trivial key server provided by reference implementation.
used to protect web servers applicable.

line mangling by mail server:

confirming servers prevent mangling.

flawed implementations:

reference implementation provided for testing.

receiving server not signature aware:

sign sent email but fall back to normal SMTP dialog.

forged validation:

key server reduces but does not eliminate possibility of
forged messages.

Andrew Snyder

[ Reply to This | # ]

We have a pattern here
Authored by: PolR on Wednesday, September 08 2004 @ 08:58 AM EDT
Let's looks at this Microsoft Royalty Free Protocol Licensing Agreement. Look especially at clause 7.5.
7.5 Assignment. You may only assign this Agreement, and any rights or obligations hereunder, whether by operation of contract, law or otherwise, if the assignee first agrees in writing to all the terms and conditions of this Agreement and You first provide written notice of such assignment to Microsoft (and, if requested by Microsoft, You thereafter promptly provide Microsoft a copy of that written agreement with the assignee); any attempted assignment by You in violation of this Section shall be void.

This is the same attempt to make the license incompatible with the GPL. But the most curious part is the protocols being licensed. Scroll down at the bottom of the page and read all the 130 of them. This list is amazing. The FAQ that can be found on the left-hand side bar is also instructive. Especially the first question:

Q. When I sign a royalty-free agreement for these protocols, what am I licensing?

A. The list of protocols under this license includes protocols for which documentation has been published, and that Microsoft has implemented in Windows client operating systems to interoperate with Windows server operating systems (up to and including Windows Server 2003). However, just because a protocol appears on the list does not mean that Microsoft is the owner or sole owner of rights in that protocol or its documentation. What the royalty-free license does is ensure that a license is available from Microsoft under whatever rights it may have in the published documentation and/or protocols on the list.

This looks like a trap to me. Anyone obtaining this license can't develop a free implementation of the protocol anymore. I wonder under which circumstances they can get someone to agree to this. Do they bundle it with some other program?

[ Reply to This | # ]

Has SUN signed Microsoft's Communications Protocol Program?
Authored by: NZheretic on Wednesday, September 08 2004 @ 09:33 AM EDT
As of the July 16 2004, Sun had not signed up to Microsoft's Communications Protocol Program

In response to my article in linuxworld plus some "slashdot flamage" from the same author, Sun's James Gosling blogged in More on Sun & Microsoft:

My last blog entry stirred up a lot of commentary and flamage (and some of the flamage was entertainingly wild: I love the Internet!). Reading through it, it's clear that there's still confusion about the meaning of our "collaboration" agreement with Microsoft.

While it is true that as a part of it we did sign up for Microsoft's Communications Protocol Program that is a part of the US v. Microsoft case, our full agreement both modifies and expands on it to give us a much more broad and useful agreement. It is important to understand that in no way does this lock Sun or Sun customers into interoperating with any Microsoft system on Microsoft's strict terms. Right now, most of our interoperability is achieved through reverse-engineering. We have the option, entirely at our discretion, to access Microsoft's specifications through the collaboration agreement. But before we do so, on a case-by-case basis, we will do an analysis of the business case for the entanglements that such access implies (principally confidentiality and royalties). Right now, the vast majority of the software that we (Sun) produce has free and open specifications and we provide the implementations of a large and growing fraction of it as open source. We are not going to slow down our involvement in the open source community. Right now we have launched no projects that will access any Microsoft specifications under the agreement - we simply have the option to, if we decide that the benefits outweigh the costs.

This ablity to selectively pick and choose and other "flexabilities" was a detail left out of Sun's press release, and more interestingly, the joint status report on Microsoft's complicance with the US DOJ final antitrust judgement.

[ Reply to This | # ]

Sender ID and Almost-Open Standards
Authored by: eric76 on Wednesday, September 08 2004 @ 09:40 AM EDT

From their FAQ,

Why is Microsoft asking people to take a license?

A: In order to promote Sender ID, Microsoft is pleased to offer its necessary Sender ID patent rights on a royalty-free basis, but only to those who are willing to make their Sender ID patents available on a reciprocal royalty-free basis. The license is also important to Microsoft for defensive reasons. The reciprocity provisions and the ability to reserve defensive rights for Microsoft's implementations of standards are very important elements in our decision to contribute technology to standards.

So does this mean that if you get in a patent dispute with Microsoft, they intend to use their Sender ID patent rights against you?

Also, is the term "defensive rights" only interpreted to refer to the the practice of one company retaliating with patent infringement claims against another when the other makes patent infringement claims against the first? It seems a rather nebulous and poorly defined phrase that could be interpreted to cover a whole lot more than that.

[ Reply to This | # ]

Patent Articles On Slashdot
Authored by: Jeff on Wednesday, September 08 2004 @ 09:49 AM EDT

Since I have started following Slashdot, I have been watching MS collect more and more patents. Some of the interesting Slashdot articles include:

MS Patents Sudo
MS Patents Keyboard Browse Navigation
MS Pockets Patents For Encouraging TV Viewing
MS Patents Grouped Taskbar Buttons
MS Patents The Body Bus
MS Patents The Task List
MS Patents The Double Click
MS Patents Timed Button Presses
MS Seeks Patents On Virtual Desktop Pagers
MS Receives XML Patent

In regards to spam related patents, Slashdot had an interesting article on McAfee being granted a patent that covers, amongst other things, bayesian filtering. How much do you want to bet that McAfee was well aware of Paul Graham's "A Plan For Spam" when they applied for the patent?

McAfee Granted Far-Reaching Spam-Control Patent

[ Reply to This | # ]

Will accepting Microsoft's license help them get the patent?
Authored by: Liquor A. on Wednesday, September 08 2004 @ 09:54 AM EDT
As I understand the situation, right now, Microsoft has only applied for the
patent, but it has not progressed far enough to even be publicly viewable.

Also, as I understand it, there is little that they can actually claim a patent
on that is not already published and in use, and what remains should probably be
considered 'obvious' (not that that has ever prevented a software patent from
being granted).

It's not clear to me if they are patenting a specific algorithm for determining
PRA, or using an algorithm with SPF - and how does patent law distinguish
between their algorithm and the one Fetchmail has been using for years?

On the other hand, if their licence were to be accepted (even though at the
moment, they have nothing to license) could this be used to influence a patent
examiner? ("Many groups have accepted our licence: They accept that this is
already our IP.")

Liquor A.

[ Reply to This | # ]

Just say "NO!!" to Macroshaft
Authored by: ray08 on Wednesday, September 08 2004 @ 09:57 AM EDT
This Sender-ID has turned into a poison pill! It is a "clever" (*not*)
plan by M$ to infiltrate FOSS, which is nearly synomonous with the internet, and
control it. Let's just ignore M$ and do it without them.

Caldera is toast! And Groklaw is the toaster! (with toast level set to BURN)

[ Reply to This | # ]

Sender ID and Almost-Open Standards
Authored by: Anonymous on Wednesday, September 08 2004 @ 10:04 AM EDT
It seems that the basic email mechanism is broken and that has to be fixed first
before you can resolve the spam problem. I have a suggestion that will fix the
problem I see, and also reduce spam.

An email is a header(from, to, subject, path, ect.) That is all that is sent
initially. The other part, the body, will be sent when the system that
recieved the header requests the body.

An email transfer would work like this:

System A sends a header to system b and saves the body
System B does its think with blacklists and any other
checks in the header to validate that it really wants it
System B requests the email body from System A
System A sends the body, transaction complete.

This has the benefit that a spammer wanting to send 100000 emails will have to
keep the body and send each one individually, it will force the spammer to send
data at a much lower rate at least reducing the amount of spam injected into the

It seems so simple to just use the from address (force it to be valid).

[ Reply to This | # ]

Let microsoft have it's way
Authored by: Anonymous on Wednesday, September 08 2004 @ 10:24 AM EDT
90% of spam is made possible by defective microsoft
software. Let them have their license and implement it in
their own MTA/MUA's and the rest of the internet will no
longer have to deal with 90% of the spam anyhow.

If exchange server or outlook can't communicate with the
rest of the internet, well then, they can all be relegated
to communicating with only other microsoft users via

Firewall the rest of us from microsoft users :)

One thing I am curious about. What percentage of mail
exchangers use sendmail/postfix/exim as opposed to
proprietary microsoft based MTAs?

A stupid question. Why don't we just use DNS mx and
inverse records to verify mail is coming from a valid
address? Or something similar to the public key
infrastructure that allows us all to bank online via ssl?
Have a trusted public key infrastructure for dns servers
and mx records.

[ Reply to This | # ]

Sender ID and Almost-Open Standards
Authored by: pooky on Wednesday, September 08 2004 @ 10:31 AM EDT
Frankly, I will be very disappointed if the IETF accepts the merged proposal as
a standard with the current IPR requirements attached. They should consider the
massive opposition to this system amongst the community as a warning that they
need to consider the consequences carefully.

ALL IETF standards should be IPR free, period. For one, to have standards that
someone owns defeats the purpose of publishing a public standard. How it is
public if you have to license it? Having IETF "standards" with IPR
attached turn them into a marketing gimmick and nothing more. I mean, I could go
to Microsoft directly if I was interested in implementing Sender-ID and
accepting the license to do so, the IETF is not required.


If at First You Don't Succeed, Skydiving Isn't for You.

[ Reply to This | # ]

Unisys and the GIF-Patent.
Authored by: Jadeclaw on Wednesday, September 08 2004 @ 10:40 AM EDT
> '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.'
Don't we remember?
Unisys promised the same for the LZW-algorithm in the GIF-format.
A few years later, when everyone was using it, Unisys turned around and started
suing the world and dog over royalties.
And because of that, it is good, when Microsofts Sender-ID dies as quickly as

And speaking of Spam, 80% of it could be killed, if ISPs would generally reject
mail originating from Dial-Up- and private Broadband connections.
Another 15% would be killed, if SMTP-AUTH is used on ALL mailhosts.
What's left, is easy to handle...


[ Reply to This | # ]

This is doomed to failure for many reasons
Authored by: Anonymous on Wednesday, September 08 2004 @ 10:46 AM EDT
First of all, its not infallable, in fact, I doubt it works at all, at least not
as advertised.

M$ is all about advertising hype and delivering smoke. happens every time.

But I've read the docs, checked the stuff out, personally I think it's very easy
to circumvent. and thats not even mentioning the huge glaring holes in it.

like what you say? well gee, for example - the largest ISPs in the world are
PAID by spammers to send their crap. For example AT&T (US) gets paid over
$50k a MONTH to carry spam from some people, and over $100k a MONTH from

You really think this is going to slow that down at all?
yeah, like they're going to give up that massive amount of cash! keep dreaming!

by the way there is ALREADY in place, a "sender verification program"
where the spammer needs to pay $30k for "access" and $30k PER domain
PER year to allow their spam to be whitelisted. These agreements are in place -
long term contracts.

so if SPF/whatever junk gets in, what are they going to do? violate the
contracts? yeah... right.

There is more "legalized" spam than anyone realizes. Hell, the company
I work for sends out over 100 million spam a DAY!

The best - absolute best defence would be "egress filtering", but no
one is going to do that... now ask yourself why? :)

[ Reply to This | # ]

Sender ID and Almost-Open Standards
Authored by: Anonymous on Wednesday, September 08 2004 @ 11:03 AM EDT
I'd actually like to see this go through. Let everyone who runs a windows mail
server have it, and linux users not.

That way when we set up our OWN e-mail system (mail² maybe?), we'll bypass all
the spam. By the time the spammers start bothering us, we'll have a nice head
start on a REAL solution.

[ Reply to This | # ]

What about Yahoo's DomainKeys?
Authored by: twhlai on Wednesday, September 08 2004 @ 11:11 AM EDT
Does anyone know if Yahoo's DomainKeys licensing is GPL compatible?

[ Reply to This | # ]

S-100ost-Open Standards
Authored by: Anonymous on Wednesday, September 08 2004 @ 11:42 AM EDT
I suspect that if Microsoft manages to get a
proprietary foothold in email then Europe
would basically ban Microsofts extensions.

Then big businesses would either have to
use two mail systems or forgo Microsoft.

This situation reminds me of the fight over the S-100 bus in the early days of
microcomputers. Manufacturers wanted control over their busses and want to make
proprietary modifications to "lock-in customers". The customers would
have none of it. So the S-100 bus was created and
manufacturers stuck to it. The customers won back then. If
people stick together the customer can win again.

[ Reply to This | # ]

The value of SPF, etc
Authored by: Anonymous on Wednesday, September 08 2004 @ 11:44 AM EDT
Vixie is quoted as saying:

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.

I had a nice account on Yahoo, consisting of my initial and last name, nice and easy to remember. I got spam, but Yahoo's spam filter is not bad.

Then a spammer started forging my email address as his From: address. My email account became unusable within days. The spammer was sending probably millions of emails per day, and I was getting hundreds of "Undeliverable" messages per day from servers where addresses were invalid. I also got angry messages from people who thought I was spamming them. I had to abandon that email account and create another one.

Spam we can deal with. What happened to me is called a "joe-job". We have got to do something about joe-jobs. I believe SPF eliminates almost all joe-jobs. (it eliminates all of them where the real sender is in a different domain from you, which is at least 99.9999% of cases.) We don't need Sender ID to do that.

[ Reply to This | # ]

Non-compliant implementations?
Authored by: risacher on Wednesday, September 08 2004 @ 11:45 AM EDT
Could you implement the protocol in a non-compliant way, such as using the
algorithm in Fetchmail instead of Microsoft's patent (the standard)? It seems
to me that this would likely still work, and not violate the patent.

[ Reply to This | # ]

The majority of spam
Authored by: paul_cooke on Wednesday, September 08 2004 @ 11:51 AM EDT
comes from bot nets of zombied ms-windows boxes... and as usual, Microsoft is doing their level best to avoid fixing the real problem but is proposing a technical solution on top of the whole email handling protocols...

Microsoft's "technical" solution won't fix the problem anyway because the spam is being sent using the legitimate email accounts of those self-same zombied ms-windows boxes...

The only reason there hasn't been a terminally deadly payload for recent trojans/viruses etc. is because those self-same criminal gangs of spammers don't want their zombies dead, but very much alive and under their control. I would personally love to see a virus that was produced to knock out those zombied machines, but any writer would be jailed under the very laws that currently are failing to protect the monoculture of vulnerable ms-windows boxes out there. In fact, the very best way to release it into the wild would be as a super-dooper spamming tool for those gangs to use that has a secret backdoor for the deadly payload to be slipped in via several weeks down the line when they think things are all right.

Use Linux - Computer power for the people: Down with cybercrud...

[ Reply to This | # ]

Microsoft's seductive gambit
Authored by: tz on Wednesday, September 08 2004 @ 11:56 AM EDT
It is interesting that Microsoft's license and/or patent is specifically
incompatible with GPL type implementations.

Worse, what happens if I agree to license something even if the patent or other
claims are rejected? Am I bound by the license?

It would be easy to renounce any rights they would gain and put into the public
domain if they considered it important and if they really were seeking a
protective patent.

Instead, they prevent sublicensing and create all kinds of administrative
headaches. Do I just have every user visit Microsoft and register before
allowing it?

The IETF should just reject the encumbered parts if Microsoft insists on keeping
strings attached.

Think of the implication. There will be sections of the RFC that ought to (but
probably will not) be labeled "You can't implement the following without
kowtowing to Microsoft".

It doesn't matter that you don't have to cut a cheque to Monopolysoft. That is
"free as in beer".

ANY restriction on redistribution and modification is unacceptable. That is
"free as in speech", and Microsoft wants to limit this aspect.

How much money could they make off this single restriction even if it was
"free" - probably less than the legal fees they will pay to patent it.
So why not place it in the public domain? The only explanations I have are
sinister and no amount of hot air from Redmond assuring me they are nice will
convince me otherwise (from the people who put a logic-bomb to make the Win 3.1
beta crash on DrDOS but not MSDOS).

The way to play nice is to preemptively renounce any IP claims or licensing
terms on the technology.

If they only want to play semi-nice, or by their definition of "nice",
they should go home and play alone.

[ Reply to This | # ]

SPF is anti-Forgery, not Anti-spam
Authored by: kitterma on Wednesday, September 08 2004 @ 12:11 PM EDT
All the comments about SPF won't stop spam completely miss the point....

I've published SPF records because my domain is regularly spoofed by spammers.
As a domain owner, SPF protects my name from being associated with spam.

I really don't care that much about checking SPF to reject inbound spam for
myself. SpamAssassin is working very nicely for that.

What I really want to be able to do is have a technical mechanism allow others
to separate legitimate e-mail from my domain from forgeries (which are by
definition spam).

SPF gives me a way to do that today. Sender-ID (if and only if the IPR problem
gets fixed) supports the same goal if perhaps not quite as well for my

SPF does "break" forwarding. There are solutions. One simple
approach is for each SPF checking MTA to whitelist known and trusted forwarders.
All SPF checking implementations support this. If the forwarder isn't trusted,
why are you using it.

[ Reply to This | # ]

So many problems...
Authored by: Anonymous on Wednesday, September 08 2004 @ 12:19 PM EDT
Oh man, there are so many problems with this scenario... To keep this post
shorter, I won't quote the parent article.

1. The IETF needs to revise their procedure for choosing "open"
standards. They clearly state that they *may* choose a standard which requires
you to pay for a license. How can they, in good faith and conscience, base a
worldwide standard on something you must pay for? That would preclude many (if
not most) people from using or basing their products/services on the standard.
Why should the IETF be able to force every single Internet user to pay for
something that they (the IETF) decided we all needed?

2. This lack of a proper license on Microsoft's part proves that they are *not*
in this to help people, but to increase their monopoly power.

3. The IETF should not base any standard on something restricted by any
country. Does Microsoft's license require licensees to be in compliance with
the U.S. Export Administration Regulations, or does the U.S. Export
Administration need to be aware of the licenses? It would seem like a great
burden on the Export Administration if it were to have to keep track of every
Sender ID license granted.

4. Microsoft cannot, in good faith, claim that you can distribute any
implementation of Sender IP under open source, though they claim that you
"probably can". "Probably" means more than a 50% chance,
which they know is not true.

5. The answer to Q15 in Microsoft's FAQ says that "almost all open source
licenses" *require* your code to be freely modifiable and redistributable,
while the GPL *prohibits* the distribution of code which is not. How does that
differ, really? The GPL *expressly* prohibits distribution because you don't
have a GPL license. The open source licenses merely won't grant you a license,
which means you have no *legal right* to distribute the software, and if you do
distribute it you're guilty of copyright infringement. The only difference is
that the GPL expressly prohibits distribution, but that's meaningless since that
text is part of a license which you haven't been granted. In either case, you
are not granted a license, and therefore have no legal right to distribute the

6. Does Microsoft have the legal right to *automatically* license it's part of
Sender ID to the end user? If I haven't agreed to their license, how can they
bind me to it? A license is something that you must expressly accept in order
to be valid, is it not?

Finally, a personal opinion. I don't think that Sender ID will work. First, a
lot of spammers are praising it, because they simply add themselves to the list.
If they're on the list, it won't block them, and it does no good. But aside
from that, it seems like it would break a lot of things (routers, firewalls,
intrusion detection systems, backup software, etc) that use internal SMTP
servers to relay important information. Do I really want Sender ID to block by
backup logs or my firewall messages? Some (if not most) of the things which
would be affected don't give you the option of specifying an external mail
server, username and password, and whether SMTP authentication needs to be used.
One example is the backup software Backup Exec by Veritas (as late as version
9, which is when I last used it); you set the SMTP server and "from"
address, but nowhere does it accept username/password or SMTP authentication.
Indeed SPAM is a problem that needs to be addressed, but are we really that
willing to break all of these software products and hardware appliances in order
to achieve this?

[ Reply to This | # ]

Sender ID and Almost-Open Standards
Authored by: pooky on Wednesday, September 08 2004 @ 12:41 PM EDT

Microsoft said:

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

I guess this is what they are referring to:


I should note that I was unable to find any of F. Scott Deaver's claimed "established patents" at the, however I'm probably not nearly as good at searching there as PJ is! :-D


If at First You Don't Succeed, Skydiving Isn't for You.

[ Reply to This | # ]

a modest proposal
Authored by: gdeinsta on Wednesday, September 08 2004 @ 01:55 PM EDT

IMO the underlying problem is that email (like snail-mail and the telephone) does not give the recipient control over who is allowed to send them mail.

A simple general solution to the problem is to require senders to put a stamp on the email - a stamp issued in the first place by the intended recipient. Without the stamp the email just bounces. The recipient issues a unique stamp to each correspondent and can revoke individual stamps at will. Since the stamp identifies the sender, if a buddy's computer is infected, even though the From: address is forged you know whose machine actually sent the thing.

Yes, you still want old friends who have lost touch with you to be able to send you email. But for that sort of thing you can require that the sender buy a stamp for some reasonable amount - say a dollar - and the money goes to a charity that runs the stamp sales website. You might still get some junk mail but not a lot at that price.

This can be done without any changes to the current email protocol or client software. The stamp can be embedded in the email address as a subdomain, e.g. "".

Too simple I suppose. Besides it would never occur to MS to give control to the user.

[ Reply to This | # ]

Microsoft breaks all it's commitments
Authored by: kawabago on Wednesday, September 08 2004 @ 02:37 PM EDT
As soon as Microsoft sees an advantage it breaks whatever agreements it has
made, that is why it loses so many lawsuits. However it makes so much money
before being sued that it just pays up and keeps going. Microsoft cannot be
trusted and no agreement with Microsoft will last. That is the lesson of
history, let's not repeat it, again.

[ Reply to This | # ]

  • I agree - Authored by: Anonymous on Wednesday, September 08 2004 @ 04:56 PM EDT
Sender ID and Almost-Open Standards
Authored by: Anonymous on Wednesday, September 08 2004 @ 02:57 PM EDT
"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.

What about email servers (like mine) that have a dynamic IP address? Will I have to be constantly updating the Sender ID database?

[ Reply to This | # ]

Sender ID and Almost-Open Standards
Authored by: geoff lane on Wednesday, September 08 2004 @ 03:21 PM EDT
We are close here to the core of MS fear of the GPL.

Should the next "killer application" be a GPL product, MS would have huge problems creating a work-alike without falling fowl of the GPL and even if they manage a functional clean-room version, how can they do otherwise than give the result away?

The only protection for this is to surpress software development outside of MS control and the only reliable way to do that is with the patent system.

MS has already missed every essential software component that is necessary for the basic functioning of the Internet. The only thing left is to target application development in the short term and mean while attempt to get new protocols accepted that provide higher level functionality on top of the basic internet operations and are controlled by MS. Promises not to charge license fees are not relevant - a zero-cost license is still a license and the terms may still be unacceptable.

There is a good case for requiring that only open and free protocols are allowed on the internet because it is acting as a "common carrier"

Ten Truths Of Linux --

[ Reply to This | # ]

  • Not quite. - Authored by: Anonymous on Wednesday, September 08 2004 @ 03:31 PM EDT
Sender ID and Almost-Open Standards
Authored by: Anonymous on Wednesday, September 08 2004 @ 03:42 PM EDT
This is turning into a clear demonstration of why open standards are not better than open source.

NO, it isnt.

This is only an "open standard", if you consider "open source" to mean "code you can read, but not freely use or modify".

[ Reply to This | # ]

  • Huh? - Authored by: RealProgrammer on Wednesday, September 08 2004 @ 04:17 PM EDT
    • Huh? - Authored by: Anonymous on Wednesday, September 08 2004 @ 04:58 PM EDT
      • Precisely! (n/t) - Authored by: Anonymous on Wednesday, September 08 2004 @ 09:17 PM EDT
      • Yes, and also... - Authored by: Anonymous on Thursday, September 09 2004 @ 01:11 AM EDT
Sender ID and Almost-Open Standards
Authored by: Anonymous on Wednesday, September 08 2004 @ 04:37 PM EDT
The Microsoft’s Sender ID licence requires a signature and personal data of the
developer and a concession from the developer.. with legal ramification..; how
anyone can call it an "open standard"? An open standard is like a
language syntax; a document or publication that presents such rules.. You do not
need to sign anything nor to submit your personal information to be permitted,
for example to write an article ( use language open standard rules).

[ Reply to This | # ]

Slight Quibble: "scientific method"
Authored by: Simon G Best on Wednesday, September 08 2004 @ 04:48 PM EDT

A slight quibble :-)

In your article, you said, "The freedom to cooperate and follow the scientific method of development, to modify and learn, is important enough that nothing can substitute for it." (Emphasis mine.)

I've noticed you using the term 'scientific method' before, in a way that doesn't really seem to match the conventional, established meaning of the term.

In 'The View from the EU Patent Proponents & Grokster', you wrote:

When it's guys coding for the fun of it or because they believe in freedom to modify and the scientific method of sharing information, ...

(emphasis mine). The "scientific method of sharing information"? Certainly openness, at least some kinds of openness, are important in science, but that use of the term 'scientific method' does grate a bit.

Another example is in 'Thinking Small', where you wrote:

But assumptions are not always accurate, which is one good reason for the scientific method of sharing ideas, of course.

(again, emphasis mine), and:

Not liking the scientific method, which is based on sharing information, can definitely lead to black hole dropouts in your reality base.

(yet again, emphasis mine).

However, in an earlier article, 'Want to See One of the Letters to the 1500?', you wrote:

There appears to be a disconnect between Darl's theory and reality. The theory is that a ragtag, unreliable, unknown group of unsupervised ruffians writes code, some of it maybe stolen, so the end result isn't secure software. Why, you can't even indemnify it, he says. In contrast, according to his theory, a hand-picked, restricted group of upright proprietary software writers produces secure code. But what we see in real life is exactly the opposite. What happened? The scientific method requires us to conclude that Darl's theory simply is not true.

(As if you haven't guessed: emphasis mine.) I have no quibble with that! :-)

While openness, the sharing of information and ideas, and so on, are extremely important in, to and for science, they're not actually part of the scientific method itself. Certainly, however, publication of findings, results, methods, etc, are parts of how we do science and what we do with science.

May I suggest, perhaps, terms such as 'scientific practice', 'scientific approach', 'academic practice', or something like that? As I said, it's just a slight quibble, really :-)

Open and Honest - Open Source

[ Reply to This | # ]

Linux cannot compete with Longhorn
Authored by: Anonymous on Wednesday, September 08 2004 @ 04:59 PM EDT
It says here. link It also gives reasons why.

[ Reply to This | # ]

Sender ID and Almost-Open Standards
Authored by: Anonymous on Wednesday, September 08 2004 @ 05:22 PM EDT
Posting to the mailing list from Andrew Newton.

The working group is proposing changing the specification to make 'pra' (the
patent-encumbered bit) optional, and permit a secondary method called 'mailfrom'
(I suspect based on the fetchmail algorithm).

I'm not entirely sure what that means.

[ Reply to This | # ]

Authored by: Anonymous on Wednesday, September 08 2004 @ 08:32 PM EDT
Most spam these days is sent via machines that have been compromised by flaws in
MS Windows.

Now MS is trying to monopolise a fix for the problem that's in some degree
caused by their actions/negligence.

How close is this behaviour to the sort of protection racket that RICO (?)

[ Reply to This | # ]

M$'s take on qmail - lazy, or disingenous?
Authored by: Anonymous on Wednesday, September 08 2004 @ 10:32 PM EDT
> "Q7: Is Microsoft’s license compatible with Sendmail,
> Postfix and Qmail?
> 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 don't know what "Qmail" is, but I know "qmail" well. And
it takes very little research to determine that Sender-Id is incompatible with
qmail's license. You cannot distribute modified versions of qmail source code,
nor binaries built from modified source code. And qmail does not implement

[ Reply to This | # ]

Authored by: Anonymous on Thursday, September 09 2004 @ 04:29 AM EDT
From what I've seen, the worldwide purpose of legal rights to published
intellectual property, including trade marks, is to permit the inventor or
creator to obtain reasonable financial return or return in kind for a time
before releasing the creation for the public good.

If any IP is offered by the IP owner as a part of a published standard, it
should be accepted that any licence terms which restrict the use of that
standard within other inventions or creations is contrary to the purpose of the
law and is, therefore, illegal.

The same argument could be extended to the prohibition of *any* IP ownership as
part of a published standard. The only legal rights would be those of the
control of the content of the standard by the publishing body.

Failure to publish a standard outside of a group of public companies or bodies
would be unfair and restrictive (trade) practices akin to the cartel

Do you agree? Would the effect on companies selling operating systems and
failing to publish the application programming interface be unreasonable?

Ian Al

[ Reply to This | # ]

Sender ID and Almost-Open Standards
Authored by: Anonymous on Thursday, September 09 2004 @ 05:35 AM EDT
there is a VERY SIMPLE way to kill spam off MAKE the risk of getting caught so terrible that you dare not get involved make the punishment fit the crime spam wastes huge amounts of Internet bandwidth make the penalty huge if needed Arab theft style chop off the offending hands .# Then we would not need any of this rubbish from companies like M$ Corp to rip you off blind with every intention of increasing the ripoff on an logerithmic scale , They either fully Open Source the no doubt stolen code or get the heck out of it , They think they rule the world and have got to be taught that they are only another bunch of BIT players play the game and they will survive carry on the way they are going and they WILL inevitably (SP) die out just like the diaosaur (SP) they are

[ Reply to This | # ]

Who supports SenderID?
Authored by: CavemanOg on Thursday, September 09 2004 @ 12:53 PM EDT

Although I've been following the SCO drama with interest, this SenderID matter is something in which I am both a player, and have a long-term stake.

While I was not at the August 31st presentation at Microsoft, which Matt Sargeant talks about in his post to the MARID WG list, I met Matt in the bar at the Redmond Marriott the night before Present that evening were Matt, Alan Murphy from The Spamhaus Project, two representatives from AOL, Dan Quinlan from Ironport Systems, a representative from Adelphia Communications, Paul Judge from CipherTrust and Josh Baer CEO of Skylist.

Can you spot who supports SenderID on that list?


scroll down to "J".


[ Reply to This | # ]

OT: any autozone news
Authored by: Anonymous on Thursday, September 09 2004 @ 03:11 PM EDT
I know the news will get here when it gets here,
but I can't resist asking:

is there any word yet from the autozone hearing
that was scheduled for today?

[ Reply to This | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )