MS Releases License For Sender-ID

NW writes "Microsoft published today a new license and FAQ for Sender-ID anti-spam standard being developed by the IETF's MARID WG (based on SPF). To use the license, a signed agreement with MSFT is required. Compatability with the Open Source Definition, the Free Software Definition, the Debian Free Software Guidelines, and the GPL/LGPL licenses is already in question."

Why not create another solution?

[Flower]

Note: I have not gone into all the gory details of this issue but I did RTFA. So here goes:

OpenBSD did it when they made CARP. Cisco wouldn't play so not only did the OBSD team create a new solution but they created a superior solution. Is there any reason why the FOSS community could not come up with an alternative and try submitting it to the IETF? (I do know that the OBSD developers got stuffed when they tried this but maybe it might work here.)

MS Hypocrisy

[Mike deVice]

So... Microsoft claims to be fighting the good fight on spam. But they then require a license to use Sender ID. It's my hope that people will have the sense to use regular SPF, and let Sender-ID die.

prefer DomainKeys

[Anonymous Coward]

I like Yahoo's DomainKeys solution more; it's open and Sendmail already supports it.

see http://antispam.yahoo.com/domainkeys

Sadly, what I like usually loses the battle. I am sure that all the MS-sexchange-servers out there will start using/insisting on SenderID... :(

Re:Are they purposely shooting their foot?

[SilentChris]

Well...

Outlook is the most popular email client out there, bar none (think how many worms targetted it). Most people who use Outlook use Exchange, at least on a frontend level (my company uses Exchange popping off a more secure backend).

Even if Exchange wasn't being used in the majority of servers, the mere fact that so many people use Outlook as a frontend will dictate whether or not this will be accepted (and, knowing MS, they'll find a way to tie this into Outlook). Think IE, and how many sites are custom crafted to it.

Re:Why not create another solution?

[eln]

Microsoft has a whole lot more leverage to push their own solution. If Microsoft decides that their way is the way to go, they can implement it in all of their product offerings, thus forcing others to follow suit or risk being cut off from the vast majority of the Internet using public.

The Open Source community can, and has, come up with competing standards, but bringing enough pressure down on Microsoft to force them to comply is a whole lot harder, since they hold all the cards.

The only hope, then, for an open source competing standard to succeed, is to make the open source solution so obviously superior that even Microsoft users can see its superiority, and bring pressure to bear themselves to force Microsoft to support that standard.

The First Shot in the Standards Wars

[maximino]

This is it! Of course we've seen things like this before, but Microsoft is preparing to ensure its eternal monopoly by making sure no one can leave its systems. It would be just fine by Redmond if no one could send e-mail without proper authorization. But now that we've got patented standards, expect to see locked-in Office files, network protocols, the works. Most people and companies really couldn't switch from Windows if they could no longer open their files or network with a Windows machine. The fact that Microsoft is willing to pull this now when some high-level spam solution is required is just reprehensible. In light of their withdrawal from the UN standards committee today I think we're seeing how the next 5 years is going to go.

Re:Are they purposely shooting their foot?

[jgardn]

Yes, they probably think they have some control in the email arena. Unfortunately, they don't. All you have to do is look at the competing SPF-classic (spf.pobox.com) and you'll see that even Sender ID - a compromise between SPF and Caller ID - is failing.

People are wondering if Microsoft has any measurable quantity of email servers facing the real internet. Best practice is to put sendmail (or postfix or qmail or whatnot) between your exchange servers and the internet. Even now, people are proposing standards and practices that totally ignore how the exchange server functions, and the community for the most part doesn't seem to mind.

I think this is the "age of irrelevance" for Microsoft. The "real" internet doesn't even come into contact with Microsoft anymore. Companies don't have internet-facing Microsoft servers anywhere that I can tell. Those who do obviously aren't going to have much uptime. (Would you run a Microsoft server without a firewall between it and the internet?)

Senmail's Position

[Mike deVice]

There are two quotes from this [imc.org] message by Eric Allman of Sendmail, Inc. that are pretty interesting...

On the open source side, the sendmail MTA is routinely bundled into other larger systems, notably open source operating system releases such as Linux and BSD distributions as well as commercial closed-source systems such as Solaris and AIX. Bundlers would need to execute their own copy of the RFSIPL. Those systems are in turn sometimes incorporated into other products, which would seemingly require another layer of patent licenses, and so on down the tree. As a practical matter, this makes the decision to include sendmail with Sender ID into their release more problematic. This is obviously not desirable from our point of view.

And...

While these are pragmatic rather than legal reasons, our likely decision at Sendmail will be to distribute our Sender ID implementation as a separate package that is not required to run the sendmail MTA under a distinct (possibly modified) Sendmail Open Source license. Open source users will have the option of downloading and installing the Sender ID package should they want the additional functionality. Bundlers will be able to choose whether they want to include the Sender ID technology or not, but will still be able to use the base sendmail MTA without additional IPR issues.

I'll be really interested to find out what the take of some Linux Distros will be on this.

Re:MS FAQ regarding issue

[Richard_at_work]

Sounds kind of like the GPL, in a sense. Same outcome anyway.

michael screwed up the story...

[Anonymous Coward]

and omitted any info about sendmail's participation in this. Interestingly, Newsforge has a slightly better (though still flawed) story on the whole isue that includes sendmail.

Leave it to Michael to post some flame in an instance where Eric Allman argues that Microsoft has made signficant changes in the license in an effort to work closely with open-source vendors.

Sender-ID adds very little if anything

[barcodez]

SPF works, it does exactly what it is designed to do what reason would there be to use Sender-ID?

SPF works today with existing software - I'm at a loss to why anyone would want Sender-ID apart from Microsoft.

I'm sure Microsoft people will install it all blindly (no change there) but if a significant number of mail servers don't implement and or deploy it then it has failed anyway.

Re:MS FAQ regarding issue

[ePhil_One]

Take the tin foil hat off.

Thanks, but I'll stick with the fool me twice, shame on me system. MS has proven time and time again that they play to win, and that their idea of fair play is whatever they can get away with. Wasn't that long ago they decided I needed to buy a second Windows license for every PC in my office because the one I bought with the computer didn't include a right for me to Ghost(tm) images onto it.

Fortunately, there's a lot of really sharp and really paranoid folks who understand the law better than me (IANAL, though I do work in IP protection); you just have to separate them from the really paranoid people who don't understand the law.

Re:MS FAQ regarding issue

[zurab]

Q5: What do I need to do for binary and/or source code distribution?

A5: Many open source licenses require you to include copyright notices distributed in the code itself identifying the authors of the code being distributed. Some open source licenses also require you to include the license under which you received the code with the code that you distribute so that downstream users of the code are made aware of the terms and conditions under which they can use the code. Microsoft does not require any notice or other attribution when you disclose or distribute your implementation in binary form.

The above is a variation of MS propaganda against OSS; taking shots at OSS while pretending to answer a "question," failing to distinguish that they are comparing their license for a specification vs open source licenses for actual programs.

Anyway, I read most of the license and the sections 2.1 and 2.2 seem incompatible with most open source licenses that I am aware of. Why? Because both the patent and source code distribution license grants are explicitly stated as:

nontransferable, non-sublicenseable, personal.

IANAL, but to me this means that if you are a recipient of a program under this license (from a party who accepted this license), you have no right to redistribute the source code unless you sign a separate license with Microsoft. This, in turn, means that the source code distribution license is held hostage by Microsoft - i.e. they may, at any time, change the terms or discontinue this license offer and no new developers (who have not agreed to the original license) would be able to redistribute the source of the existing open source programs implementing the specification.

Once this becomes popular, as Microsoft seems to hope, they may even (or at least have an option to) say - sorry, but we are no longer offering the "source code distribution" option with our new licensees, so sorry, really.

So, at the end, again they hope, everyone would have granted their patent licenses to MS, and MS would be in charge of the terms for the source code distribution.

This license is not compatible with OSS.

Re:MS FAQ regarding issue

[LO0G]

Here's the thing to think about here. Spam is KILLING Microsoft, especially with Hotmail. It's literally costing them millions of dollars a year (they've made this quite clear). Microsoft believes that widespread adoption of this standard will help them fight spam.

So now then you have a question to ask yourself:

Which is more important to Microsoft: Stopping spam or winning points against other developers?

If it's the former, then they're on the level.

If it's the latter, then they're going to use the license as an excuse to rape you.

Re:MS FAQ regarding issue

[tacocat]

What do you think?

They don't care about a few millions of dollars a year in this crud. It's all a tax write off to them.

They prefer raping over fighting

Re:Where Sender ID fits into the picture

[bigberk]

The SPF/SenderID group understands exactly what it is doing. It is not making the claims you are asserting

I was an SPF supporter (had TXT records for my domains, even) until I took a look at their objections page [pobox.com]. Take a look at it yourself.

• "Second, to handle bounces, I propose a rewriting scheme as follows" -- as Vernon points out, this scheme is terribly broken. It is not a generic solution, and is definitely not going to work globally.
• "Domains that refuse to publish SPF or publish global-allow SPF out of political principle, malice, or incompetence will simply have to accept the penalty of a higher spam score." -- but many domains are simply unsuitable for using with SPF! What about a provider who provides a mail forwarding service, even universities, etc. They want their addresses to be used as return paths outside their own systems. The SPF people are saying that these domains must be punished for their unwillingness to adopt SPF. Internet email is a flexible thing, and there are a zillion instances in which SPF is unworkable.
• "What do the customers want? They want to communicate with their friends and family; and they want to not get spam. They do not particularly care if a few eggs are broken along the way." -- this shows a severe misunderstanding of their own system. SPF does not prevent spam, but rather provides a domain owner with the power to prevent their return paths from being forged. This is very different from addressing a spam issue. It's not a bad goal, but it's not addressing spam.

Those quotes are directly taken from the SPF proponents at pobox.com; you can see the major flaws in their thinking. Especially unfortunate is their expectation that everyone must adopt SPF. There is no way SPF will be adopted by all domains, and penalizing domains for refusing to participate in the scheme is senseless. This is why I have lost faith in SPF.