Slashdot Mirror
RMS Weighs In On SPF/Sender-ID License
NW writes "In a recent message to the MARID list RMS weighs in on the licensing issues of Sender-ID/SPF and Microsoft:
'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.'" "MARID" stands for MTA Authorization Records in DNS; here's the IETF MARID working group's charter. (Read more below.)
Stallman's message continues: "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."
I'm surprised the author didn't link directly to Microsoft as well...here's the missing link.
Not exactly. To the Free Software Foundation, "Free" has *always* been about being "open source" as you would put it. "Open source" was a relatively recent term adopted by people because people kept confusing zero cost with freedom to modify the source code and do what you want with it. RMS has been using the term "free" to describe that for decades.
From the copyright for RFC2821: (SMTP):
/. posts, but now I think I need some clarification.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works.
From the copyright for Sender ID:
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights
Note that "the authors" is:
J. Lyon
Microsoft Corp
M. Wong
pobox.com
I used to be an SPF fan, largely because it was the source of many hilariously mistaken
Just a little contrast for those who read only one level deep.
Mars
Too early in the morning I guess... ;-)
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
I have personally met several of the Microsoft employees who are doing the work on Sender-ID. I have ever reason to beleive that they are working in good faith to try and make sure this technology can be deployed by everyone, including GPLed software. The problem is that Microsoft is a huge company and things like the licensing issue are handled by Microsoft lawyers, not the people directly involved in SenderID.
I know that the SenderID MS folks are working with MS lawyers, and the MS lawyers are working with lawyers from the FSF, Open Source Initiative (OSI), and IBM (for postfix). The IETF working group co-chair has given MS until early August to get this problem resolved.
Personally, I'm going to give Microsoft lawyers a little more time before I try to outright kill the SenderID RFC.
SPF support for most open source mail servers can be found at libspf2.
After a quick view of the license, here are the obvious problems I found with it, and why it is not compatible with Free software:
1. You can only use the code for software that is related to Caller ID (section 2.1)
2. Annoying advertising clause that says if you want to rebrand the code you must get permission from Microsoft. In other words, you can't fork the code under a different name. (section 2.2)
3. Overall reading seems to indicate that you must accept the license in order to USE the software, even though you did not sign anything. This is directly in opposition to the GPL.
4. The focus of the document is how you have the "right" to use their "patented" code. If this doesn't throw up red flags, nothing does. This means they can withdraw the license at any time, since it is more of a contract to use patented software than it is a license to distribute.
5. The clause in section 2.4 "Defensive Suspension" gives Microsoft broad discression to "terminate all license grants" if _they_ are sued in any way regarding the technology. This means, "sue us over the restrictions and we can instantly take away your right to use it, and thus your right to transfer email". It guarantees a bullet proof monopoly on the Patented technology.
And yes, there are plenty of other things that are at odds with the GPL, those are just the EASY to find items. See it yourself at the PDF link you provided.
Tequila: It's not just for breakfast anymore!
The site Boycott Caller-ID for E-mail has been saying this for a very long time. Since the merging of SPF and Caller-ID into Sender-ID it's been getting a bit out-of-date, but the patent issues are still valid.
æeee!
'Microsoft license does not stop the distribution of source, in fact there's a specific clause allowing it (2.2), you just have to include a paragraph in the source code. Nor does RMS say what his problem is, aside from "Grrr, it's Microsoft". '
m _s enderid.mspx
The problem *IS* that paragraph, it makes the license extendable, since anyone who wants to use/give away/do anything with, it in future would have to get permission from MS.
"Our provision of this source code does not include any licenses or any other rights to you under any Microsoft intellectual property. If you would like a license from Microsoft you need to contact Microsoft directly"
There is no limit set on that permission, so MS can change the license terms using that paragraph at any time for any future product.
"So, the license RMS is ranting about doesn't apply"
Yes it does (Published 23rd June 2004):
http://www.microsoft.com/mscorp/twc/privacy/spa
"If you are a software developer and are interested in implementing this specification in software, please review the terms of the Caller ID for E-Mail Implementation License before you begin, as the patent license discusses the rights that Microsoft would grant you or your organization."
From: Ted Hardie
Subject: Regarding the recent licensing thread
To: ietf-mxcomp@imc.org
Date: Mon, 19 Jul 2004 11:27:41 -0700
Some points on the recent licensing postings:
1) This discussion has been unprofessional in the extreme. Contributors to this working group have been accused of failing in a duty they did perform, and that is rude and unproductive. The Microsoft IPR filing related to callerid was posted with their first ID, which is exactly what is required. Those who have been waiting for such a statement either don't understand the process or have not been paying attention, and their acting offended about things now carries no weight. A refresh with the new name and some details on coverage is warranted for clarity before the documents go to the RFC editor, but that is a paper trail issue, not substantive.
2) The IETF is an engineering body, and it makes engineering decisions. It cares about licensing only as it affects the ability to implement and deploy a standard. Religious opinions on the sanctity of specific license texts belong elsewhere. The sudden appearance of this as a separate topic without reference to the engineering choices misses the point of how the IETF makes these calls: in the context of the engineering decisions. Comments based solely on the licensing terms without regard to the engineering choices they affect *do not speak to the question working groups need to decide*. The sudden appearance of new working group participants after postings inviting them to comment is welcome *if they contribute to the engineering discussion*. But if you are here to comment on licensing outside of the engineering context, you are wasting your electrons.
3) The IETF has published standards with defensive patents many times, and the use of a reciprocal/royalty free license is a common way for contributors to protect themselves from later claims while still encouraging the creation of an interoperable, open standard. Trying to persuade the working group that something is outside the norm when the IETF IPR page is full of contrary examples insults the intelligence of the group, as well as insulting the contributors who are providing a royalty free license.
4) Armchair lawyers often assume things about patents and licensing which aren't true. Get a real lawyer to read things you're concerned about and have them talk to the contributor's lawyers about things that concern you. The creation of a licensed "libipr" called by other applications may be all it takes to have licenses with severe restrictions co-exist with royalty free/reciprocal licenses; this isn't something you can assume one way or the other. You really have to have professionals check. And when you find things that concern you, be aware that this license isn't responsible for ways you may already have bound yourself; if you signed an agreement with HP Lovecraft that said "I will only acknowledge Chthulhu in my code", don't blame Microsoft for requiring an IPR notice. Take it up with the Elder Gods.
5) Generic rants about patents belong on your national I-hate-the-patent-office list. Rants about the IETF's standing decision *against* requiring a specific license or class of licenses belong on the IPR list, but are very likely to be redundant to arguments already made. Read the archives.
New drafts are now out, waiting for careful review. I urge the working group to review them carefully and to focus on how they can be interpreted, coded, and deployed. We have a lot of work to do.
Ted Hardie
Yes! Someone HAS created such a web page. See: http://www.technoids.org/maridterms.html
SPF support for most open source mail servers can be found at libspf2.
The primary authors of SPF saw the deal with Microsoft as an opportunity to get Microsoft to incorporate SPF into their SMTP servers and mail clients. They were trying to get SPF as widely used as possible, to reap the maximum benefits. This is good. Plain old SPF is extremely lightweight, extermely effective, and can put a bullet through almost all the domain forged spam on the planet.
Microsoft wants to incorporate CallerID, which is theirs, proprietary, and allows owners of CallerID tickets to be allowed to get past SPF. Its a typical use of their monopoly power to warp a standard, but the SPF authors accepted it to get wide usage. It's too bad: CallerID is Microsoft patented XML code in the email header, which means adding a patented XML parser to SMTP servers and email clients, and which means you can't do filtering with it at connect time the way you can with SPF. It means you have to *take the whole email message* before you can filter it, which is a stupid burden for a mail server being spammed to pieces by email viruses.
Now, anyone sane writing software that does this will leave in a switch to say "Use SPF only, and ignore Caller-ID", and leave Microsoft to stew in its own silliness. Expect the open-source toolsets to do this, and Microsoft to mandate the Caller-ID check, which will help accelerate people away from Microsoft mail servers.
Also, fortunately, the MARID proposals threw out most of the Caller-ID features in the proposal because of the underlying stupidity of using XML in your mail servers. There are things XML is good for, but Microsoft is betting the farm on XML in many of their products such as Microsoft Word, because they own patents on it and can keep out open source readers that way, and because it solves a lot of problems for dealing with their bloated document formats.
The SPF authors made a nasty deal with Microsoft to get their stuff into use and try to turn the tide on spam. And frankly, I think they were right. The time saved dealing with email viruses and spam can be spent doing real work, like getting rid of more fundamentally Microsoft software in the workplace.
I am a member of the MARID WG. I have been working on this for two years. RMS has made no attempt to talk to anyone in the group to find out the real situation. All he did was to wade in and make a statement to promote his own agenda.
I'll not pretend that I am not pissed off with RMS, he is to the anti-spam world what Ralph Nader is to the anti-Bush world.
The real situation is that the licensing issue was considered when the original submissions were made. Then when Caller-ID and SPF were merged for sound technical reasons the licensing issue has to be revisited. We asked Harry and Jim to take up the licensing issue with their lawyers about a week ago. They are meant to come back with a reply before we have the MARID meeting at the San Diego IETF the week after next.
Obviously the group is not going to accept an encumbered specification. The brutal fact is however that if you do not patent the ideas behind a protocol someone else will. Remember the $500 million Eolas judgement? So now we have to go through the licensing issue every single time we write a standard.
The fact is that I have never been in a situation where we have failled to get a satisfactory license grant with respect to any technology that was held by a vendor who actually makes products. I have negotiated with Microsoft on this issue many times and have always ended up with a license acceptable to all parties including OSS.
Now less than 24 hours after Microsoft go off to talk with their lawyers people start campaigning to take the Microsoft technology out using the licensing issue as an excuse. This came mainly from a group of tourists who had had nothing to do with the group previously. It is very obviously a campaign by people whose priority is not getting the best MARID spec we can.
This type of scheming is both unprofessional and damaging. Microsoft are on notice that they have to deliver a satisfactory license in the next 9 days. It has been made clear that this will have to have a sublicense clause and allow both commercial and GPL implementations.
The purpose of MARID is to address the spam problem. People who have other agendas, particularly using it as a forum to attack Microsoft are so not wellcome. The IETF is already in a very weak state, over the past ten years its influence has declined from being the most influential Internet standards body to being a distant third. One of the reasons commercial vendors have learned to avoid the IETF is that more effort is spent on ideological food fights than engineering issues. The point of MARID was to try to prove that the IETF can produce specifications in a timely manner relevant to real world issues - i.e. less than five to ten years. That point is lost if we have people trying to prevent commercial vendors having any influence in the process. At the end of the day the only reason any standards group has influence is that it can influence vendors and major OSS projects that have influence.
The complaints are not about the license issue, that is being addressed. This is the machinations of a faction who want to use MARID for conducting a vendetta against Microsoft and don't care what the effect on MARID is.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
Actually publishing an idea will prevent it from being patentable by others accordingin to the law.
And yes I know it practice that may not always be the case - but its not even safe if you have a previous patent for it to not be patented.
A guy describe how he got a patent on an already patented idea, some patent-lawyers managed to change the wording of the patent application so it was not obvious and got the patent. It may be unenforceable in a court because of that but hey the company got another patent.
Just saying it like it are.
"We asked Harry and Jim to take up the licensing issue with their lawyers about a WEEK AGO. "
2 53 .shtml
Your RFC is dated 20th July 2004. 5 days ago.
Later on you say this:
"Now less than 24 hours after Microsoft go off to talk with their lawyers "
Which is it a week or 24 hours? It looks like you put out the RFC, people complained about the licensing issue, and now you're in ass covering mode.
Yet this problem was known about for a long time:
Here's "Eben Moglen -- professor of law at Columbia Law School and General Counsel for the Free Software Foundation " complaining about the patent and license problems with Caller ID from late FEBRUARY.
http://www.newsforge.com/software/04/02/26/1448
What really irks me is that rather than invent new solutions to existing problems, the free software community waits for a commercial vendor to implement a solution, and then copies it.
In general, you're right. In this specific case, you're totally backwards. SPF (most of what is now sender-id) was published as a free and open standard months before AOL and Yahoo got on board. Microsoft has only been participating for a very short time, compared to how long SPF has been around.
0 1 - just my two bits
Then I tripped over another reference that indicates that there may be other IP issues which could affect Sender ID. I suppose these other IP claims against Microsoft regarding their Caller ID specification might invalidate the presumed Microsoft patents relevant to Sender ID as "prior art". However, they might also directly encumber Sender ID if it includes components contributed by Microsoft but patented by another party.
In any case, it seems that this standard is important enough that it should be clearly unencumbered. This will require clear statements from Microsoft about which patents, if any, apply to Sender ID, and to which portions of Sender ID they apply. This disclosure seems to be required by the IETF. However, if Sender ID is to be adopted universally in the SMTP universe, a license that allows free software to use the patented methods without restriction is also clearly required -- and this situation at present seems anything but clear.
Things should be made as simple as possible, but not any simpler. -- Albert Einstein