Slashdot Mirror
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."
FAQ for Microsoft's
Royalty-Free Sender ID Specification License
Microsoft Corporation
August 2004
Q1: What is the purpose of the patent license?
A1: The adoption of Sender ID is important for the industry and Microsoft wants to facilitate the
adoption of the standard by licensing its necessary patent rights on a royalty free basis and
encouraging others to license their patent rights that cover the Sender ID specification similarly
on a royalty-free basis. That is why Microsoft's license includes all of Microsoft's current and
pending patent rights that are necessary to implement the Sender ID specification not just the
pending patent application claims Microsoft is currently aware of.
Q2: Doesn't having a patent on Sender ID complicate the process of getting it adopted as
an IETF standard?
A2: No. It should not. There are dozens and dozens of patent rights that have been disclosed to
the IETF that may cover IETF standards. See http://www.ietf.org/ipr.html for a complete list. We
are not aware of any of these patents complicating the standards process especially where the
patent owner has provided an assurance that it would make licenses available on a royalty-free
basis with other reasonable and non-discriminatory terms and conditions as Microsoft has done
here.
Q3: Why is Microsoft asking people to take a license?
A3: 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 also 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.
Q4: When do I need to execute a license with Microsoft?
A4: At this time Microsoft is only aware of pending patent application claims that cover its
submission of the Sender ID specification. Because Microsoft is not aware of any issued patent
claims, Microsoft does not require any one to sign a license with Microsoft to implement the
Sender ID specification or any part of it that is incorporated into IETF working drafts. In
conformance with the IETF IPR policy Microsoft has disclosed the existence of those pending
patent claims and has provided its assurance that if such claims are granted Microsoft will make
licenses available on reasonable and non-discriminatory terms. Microsoft has also gone beyond
the IETF's requirements by clarifying that its licenses will require no fees or other royalties, and
further, to make a license available to early adopters who wish at their option to clarify their rights
with Microsoft with respect to early implementations. Typically patent holders do not make their
license terms available until after the standard has been adopted and until after their patent
claims have been granted, leaving early implementers to speculate as to the ultimate terms of the
license.
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. However, if you disclose or
distribute your implementation in source code form, we think it is important for you to include a
patent attribution (from sec. 2.2 of our royalty-free patent license) in your source code and in
close proximity to the license under which you make your sou
How long will it be before you have to have a signed agreement with Microsoft to send an email?
Why not use something like gnupg to sign email in order to prove the identity of the sender?
Seriously, does Microsoft think that highly of themselves that they can dictate a standard that requires a license from them? Sure they have a majority of the OS and E-mail clients, but I doubt they have a majority of the Mail Servers out there.
In the current climate you could never produce a HTTP/SMTP type protocol because everyone is out to make money and gain power. What Microsoft has done is take a relatively open protocol and slapped a 'Microsoft Property' sticker on it, this will effectively limit its usefulness even if they are not charging a penny.
What is stopping them from letting it catch on and then asking for $1 from each project?
Three drops of blood
Other fluids (defined in separate document)
Provide access for nanoprobes (Resistance is futile, after all.)
I'm in!
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.)
I don't want knowledge. I want certainty. - Law, David Bowie
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.
But did anyone actually read the article? You don't need to sign the agreement to implement sender ID. They are just pre-emptively giving out the agreement that would be necessary if their pending patent is granted.
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.
Just to get everyone up to speed:
- SPF (http://spf.pobox.com) is the current email authentication protocol that is dominating the world.
- Microsoft proposed Caller ID which was never accepted by the community.
- Microsoft and SPF advocate Meng Weng Wong brokered a deal and formed Sender ID. Basically, SPF is intact, but some features of Caller ID are preserved as an optional extension.
The part of Caller ID that remains is the PRA or "Purported Responsible Authority". The PRA is deteremined by a complicated algorithm that I personally don't believe would work. The algorithm is intentionally vague in some areas, and the results are ultimately subjective. The intention of the PRA algorithm is to determine who wrote the email based on the email headers. As everyone knows, the email headers are spoofable. But the idea goes, if you can track down the PRA, then you can authenticate this email based on that, rather than just the last hop like SPF does.
The problem from day one has been the patent issue. Microsoft is in the process of patenting the PRA algorithm. This isn't a problem. The problem is that Microsoft refuses to put the patent in the public domain or license the patent such that anyone can use it except those who use patents against Microsoft. Both of those strategies are perfectly reasonable, and are pretty much what IBM does for most of its patents.
Microsoft originally wanted to get a copy of the software and a signature before they would grant a license. Well, that doesn't work for F/OSS. The MARID working group who is investigating various solutions to the email authentication protocol for the IETF has been petitioning Microsoft to revise or clarify their licensing procedure. Well, they finally have, and in so doing they have not made it F/OSS compatible.
Microsoft thinks they can bully us around, but they don't realize they are the small kid on the email block. Their Caller ID failed. Now Sender ID is going to fail because Microsoft refuses to participate.
But that's okay. The PRA algorithm isn't anything we'll need to solve the email authentication problem.
The radical sect of Islam would either see you dead or "reverted" to Islam.
As long as the IETF maintains a global perspective, it can not accept standards encumbered by IP more restrictive than the GPL. It seems obvious -- we've all benefited by open standards on the Internet. But who knows, stranger things have happened.
This could be a good test case. MS may continue to pursue its IP Holy Grail business model, but if the IETF can stand firm and refuse restrictive licensing, they will not be able to force it down the world's throat. On the other hand, if the IETF does accept these kinds of IP restrictions, MS may have a path forward in pursuing its new business model of patents and copyrights for obvious and trivial ideas.
Whew.. I almost thought I saw Microsoft and standard
used in the same sentence. That was a close one.
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.You raise a good point. MS will use it's Exchange server base as a launch pad to make everyone else play their game. Open source servers can easily be modified to support MS's BS, but I'm sure Exchange won't play nice with other open standards. *Sigh.* Here we go again.
"With sufficient thrust, pigs fly just fine." -- RFC 1925
So everyone shares their patents with MS, but not with each other, MS gets all patent rights, and everyone else has to fend for themselves? Where is the strategic advantage for everyone to jump on board exactly?
.sig: Open Source, Open Mind
So now nobody will implement this, and Microsoft, through patenting something obvious and trying to license it has scared everyone away from some pretty good ideas that would have been implemented otherwise, with or without Microsoft's help.
This is just the latest chapter in IP stupidity.
This stuff has been discussed for years, if this had been treated like most other W3C standards we'd be in the clear by now waiting for implementations, instead everyone's scared. Does anyone realistically think that there aren't patents that W3C standards already infringe? Finally we actually get rights to something and we're inspecting the teeth, simply because the subject has been raised.
The crazy part of this whole deal is that most software is riddled with potential patent violations, including Microsoft's and including projects like Mozilla, Gimp and Open Office. That's why MS are trying to retain *defensive* rights, because they know it would be dangerous to give this IP away, anyone could stand on their shoulders, and a widget and then sue them (and that has happened already) and Microsoft would have no way of countering. If they adopted a more GPL oriented license with the rights being rescinded in the event of any patent suit against M$ it would be golden. They could just do to the protagonists what IBM has just done to SCO, infact that wording is almost already in the GPL.
I think this situation can be salvaged with another revision of the license. We should not give up on this or go for the second best option on such an improtant proposal.
We're getting to witness what the beginning of the web would have been like had Tim Bernards Lee patented some of his ideas. It ain't going to be pretty.
on the birth of your child. We know that bringing an infant up in the 21st century is a daunting business. Thats why we have designed especially for you a completely free licensing policy agreement that will safeguard young (enter name) from the burden of facing a bleak future without a licensed, activated copy of our latest (enter name) operating system or proprietary value added software.
As a further benefit, our intellectual protection package will ensure that your young tit sucker's ideas will never fall into the hands of enscrupulous (note the en..) parties and will be safe in our creativity vault.
Just sign the punch out card below with (name)'s new citizen number and we will do the rest. Just think how (name) will thank you. (snicker snicker..)
(small print: nyk nyk nyk! All your intellect is belong to us! Wahhhah hah!)
My hyperlinks aren't worth the paper they're printed on.
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.
Is just ridiculous. How many things must something be "compatible" (whatever that means in each context) with before it can be considered "good" considering most of you can't make up your minds about them to begin with?
...blatent troll snipped...
It's considered good when anyone can play the game under the exact same rules, regardless of how much money, prestige and lawyers they have. That's what an "Open Standard" is defined as - an agreement on a set of rules that is there for all to see and use. Microsoft still doesn't get the "Open" part, it seems.
Sigh.
Soko
"Depression is merely anger without enthusiasm." - Anonymous
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.
----
If the license they use is not compatable with use in an open source tool, and their system ends up taking off, then the end result is that all people using open source e-mail clients will be misidentified as "spammers" and thus unable to send e-mail to people who do participate in this system.
Are you unable to see what's bad about that - cutting all open source out of the use of e-mail - so that this once open standard gets nicely hijacked and "owned" by MS?
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
Most corp. users don't configure their e-mail personally, it is done by a sysadmin or pre-configured when they arrive to work. A vast majority of home users use webmail's such as gmail, etc.
If word got around that MS was going to change the behaviour of Outlook to this, I doubt a great many corps will change over to this new Outlook. Many companies are still out there using NT4/Office97. Even if they did upgrade, it wouldn't be without first disabling this via a policy. Sure home users will get spooked, but nothing is changed at Microsoft without first considering how major corps will react.
Can I get an eye poke?
Dog House Forum
You obviously didn't read the thread. Microsoft's patent license is explicitly non-sublicenseable, which means that you may not redistribute to anybody who has not already accepted Microsoft's license (and by accept, I mean, printed it out, signed it, and faxed it back to Microsoft).
While that may not seem like a big deal to you, keep in mind that that's an incredible burden to place on freely distributed software, which would otherwise circulate quickly and freely.
From what I've seen looking at the major FOSS development communities you listed they code and just keep moving on. Nobody is really wasting tons of time going on COLA and spending hours debating whether it should be GNU/Linux or just Linux.
Now the people that are debating this in the IETF? Well that's their job. This stuff needs to get sorted out so the proposed standard can be applied as widely as possible. Considering how deep FOSS is in the email infrastructure I, as a user and administrator, want this debate on whether the proposed changes are compatible or not.
I don't want knowledge. I want certainty. - Law, David Bowie
There are lots of other examples at http://ietf.org/ipr.html with
fairly similar "don't sue me and you can use it" terms. The IPR
terms being offered here almost look like a cut and paste job, to
be honest, and that may not be a bad thing. There actually
can be advantages to someone holding a defensive patent:
It means someone who wants to use a submarine patent to
control this technology has to fight Microsoft's lawyers.
Microsoft's grant is: 1) subject to any denial of claims by
the USPTO, 2) Royalty-free (as in beer), 3) Non-discriminatory
(anyone, anywhere, any time). Other submarine patents might
not be nearly so nice, and I'd rather have the next guy along
sue Microsoft than me.
There are some pain in the rump aspects; it is not:
sublicensable (everyone has to get their own free thing).
It does require you license back whatever you have claims on
that is needed for Sender-ID to get their thing needed
for Sender-ID (this is common in the IPR declarations given
to the IETF). That, in my humble not-a-lawyer opinion is
why you have to let them know your use is under the free,
global, yadda-yadda license rather than being an
infringement of the patent.
The good news: this does not require those deploying
Sender-ID records to do anything. It does not
require anyone using packaged binary software to do
anything. It does not require anyone distributing
packaged binary software to do anything.
It's a minor pain for implementors and a hassle for distributors
(who may, like Sendmail, have to put the Sender-ID code in a
different distribution). Not ideal, but not enough of a pita,
in my opinion, to go without the technology. Especially if
their claims cover things like "storing MTA authorization records
in the DNS" (and they could), rejecting this could mean rejecting
the whole ball of wax as an anti-forgery tool.
Who wins then?
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.
SPF is not necessary for exchanging electronic mail. If Microsoft servers fail to exchange mail with any significant number of OSS mail servers, the result won't be that OSS gives up and everybody signs patent license agreements with Microsoft, but rather that SPF won't get used. The long term fall-out would be that people would take Microsoft even less seriously when they come to standards bodies, and to hurt IETF credibility even further (IETF is already largely irrelevant).
Microsoft is apparently trying to play hard-ball with OSS developers, forcing them to accept some kind of licensing terms or forcing them to stop developing this kind of software. But OSS developers don't have a choice: there simply is no way under which OSS developers can give in to Microsoft's licensing terms, even if they wanted to, since the terms are just fundamentally incompatible with most OSS licenses.
Furthermore, going to IETF with such standards proposals is pointless: the only producers of software that count in this space are Microsoft and OSS. If IETF starts producing standards under terms that are not acceptable to OSS developers, then that just makes the IETF irrelevant but it won't help with adoption of a solution.
In this case, if IETF's SPF standard isn't 100% compatible with OSS licenses, OSS software will not incorporate it and Microsoft Exchange installations will be unable to use IETF SPF with a significant fraction of Internet hosts. If Microsoft were competing with a commercial vendor of mail server software, that vendor would be in deep trouble and it might induce that vendor to come crawling to Microsoft begging for a license. But OSS developers won't do that: OSS projects don't have the same kinds of short-term pressures on them as commercial software vendors, and even if they wanted to give in, OSS licenses make it impossible.
Microsoft's management just doesn't seem to understand that they are not dealing with another business anymore: the strategies that they have used against commercial competitors just don't work against OSS. All they are accomplishing with this sort of behavior is to taint their own credibility and the credibility of the standards bodies they get involved.
Ok, so Microsoft seems to be trying to assert patent rights on Sender ID, in a fashion that makes open source difficult to implement.
Can anyone tell us what is stopping the Free world from simply reverting back to plain old SPF and ignoring Microsoft's extensions?
Tired of FB/Google censorship? Visit UNCENSORED!
Even better, SPF doesn't necessarily compete with DomainKeys.
SPF enumerates which servers are allowed to send email for a certain domain.
DomainKeys authenticates individual email messages as having come from a certain domain.
Together they could be quite effective against spam. In particular, Yahoo also talks about building a reputation system on top of DomainKeys. The idea is that a spammer would quickly find the 'reputation' of their domain going down and soon no email server would accept their email.
Seriously, what's the problem?
If all this should have a reason, we would be the last to know.
MARID means sick in the Maltese language... someone must not have done his homework well :-)
---
I'm sorry, I don't follow. How does MS asking you to mention their patent in your source cause any problem for the GPL? The GPL is quite clear that individual users must not need to apply for a patent license; that license must be royalty-free and transferable to anyone who uses the GPL'd code. Period. Microsoft's patent license appears to be royalty-free and transferable. They want their patent license in close proximity to your software license -- that's OK by the GPL, just bundle the two text files with your source, as you today bundle the GPL text file with your source.
You can't bundle GPL with your source and distribute it, unless you are distributing under the terms of the GPL and no other restrictions are imposed.
In order to derive software from Microsoft patent, Microsfot requires you to give them reciprocal rights on certain of your patents. You can not impose such a requirement on software if you are deriving it from other copyrighted material you are using under the GPL license.
The copyright holder expressly forbids it.
The GPL says:
You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
The microsoft software is not transferable to all third parties with no charge under the terms of the GPL. Only to a subset of third parties, namely people who agree to abide by specific additional stipulations of the microsoft license. Consequently the GPL would would not enable them to use the software unless they agreed to the additional microsoft terms. The GPL specifically does not allow you to add additional restrictions to the use of the software. The fact that those restrictions are from microsoft is not at all relevant.
If you want to add additional restrictions you have exceeded the license granted to you by the GPL, and you must obtain permission to derive from the authors, just like you would need to obtain permission in the case of any copyrighted work.
You may not revoke from the recipients of your GPL derived work, any rights the GPL granted to you, because the GPL only gave you license to distribute if you license as a whole the entire work under the GPL. The requirements of Microsofts license do not give all the same rights as those of the GPL and thus you can't impose microsofts license onto GPL work, and then use a GPL license to justify, what would be, copyright infringment against the copyright holders of the GPL software you are deriving from.
No one has a right to their *own* opinion. They have a right to the TRUTH.