Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Spam GNU is Not Unix Microsoft

RMS Weighs In On SPF/Sender-ID License 250

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

This discussion has been archived. No new comments can be posted.

RMS Weighs In On SPF/Sender-ID License

Comments Filter:
  • by FyRE666 ( 263011 ) * on Sunday July 25, 2004 @10:01AM (#9794135) Homepage
    I've STFC (Scanned the charter) and from what I can gather, it's simply a new record type on the DNS'. Surely the MTA would then query the DNS responsible for the domain for this record, and act accordingly; so what's the problem? I'm sure Sendmail can be made fully capable of this, or any other lookup tool.
    • by Smallpond ( 221300 ) on Sunday July 25, 2004 @10:29AM (#9794239) Homepage Journal
      From the copyright for RFC2821 [ietf.org]: (SMTP):

      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 [ietf.org]:

      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 /. posts, but now I think I need some clarification.
      • by Anonymous Coward on Sunday July 25, 2004 @11:43AM (#9794546)
        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.
        • by voixderaison ( 665336 ) on Sunday July 25, 2004 @03:40PM (#9795830) Homepage
          Your analysis seems to make sense if the patented components of Caller ID strictly concern the XML stuff which is not included in the Sender ID draft specification. In an effort to learn more about this, I looked over the Microsoft site for a pointer to the relevant patents or patents pending, and didn't find one. So then I googled around looking for this, and found mostly references to, and quotes from, the same Microsoft Caller ID license page.
          Caller ID licensing for software developers [microsoft.com]
          "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."
          Then I tripped over this article, which is a bit clumsy, and a dated reference to Caller ID (rather than a current discussion of Sender ID), but which contains an interesting and relevant idea.
          Eben Moglen on Microsoft's Caller ID Patent License [newsforge.com]
          "Note, however, that a developer could specifically *disclaim* the Microsoft patent license, which--since it does not actually identify any patent claims being licensed--could be said to be a nullity in any event. Such a developer could legitimately distribute under GPL, which would arguably be the wiser course."
          That makes some sense, although I suspect that Microsoft has a large enough patent archive and accompanying staff of attorneys that they could bog down or possibly shut down almost any Sender ID project they choose by taking them to court, citing relevant patents at that time.

          Then I tripped over another reference that indicates that there may be other IP issues which could affect Sender ID.
          Bill Gates Is A Thief [codecloset.com]
          "We believe that, totally bereft of their own ideas and lacking any in-depth understanding of the issues, Mr. Gates and company were absolutely desperate to appear relevant in the struggle against SPAM, if nothing else to deflect culpability and bad press for the unrelated, clumsy, and manifestly irresponsible security issues and quality failings in virtually every Microsoft product to date. In an odd twist of the same logic that two weeks ago had them beating up a 17-year-old over his website MikeRoweSoft.com (because it merely sounded like Gate's company site), they presumed FailSafe Designs would be too small and too timid to stop them from taking yet something else they wanted that wasn't theirs (as has been Microsoft's habit since inception). Had they merely asked, we would have considered selling or licensing our products, trademarks, patent rights, and other intellectual and real property, but Mr. Gates never stoops to common decency whenever any opportunity to bludgeon someone avails itself."
          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.
  • by pongo000 ( 97357 ) on Sunday July 25, 2004 @10:07AM (#9794157)
    I'm surprised the author didn't link directly to Microsoft as well...here's the missing link [microsoft.com].

  • It's pretty simple (Score:5, Insightful)

    by Featureless ( 599963 ) on Sunday July 25, 2004 @10:08AM (#9794168) Journal
    If we let Microsoft, through some machinations during our anti-spam re-engineering or in any other manner, take any measure of control over what has, until now, been an 100% open-standard email infrastructure, email will be fragmented and ultimately ruined, far worse than any cadre of spammers could ruin it.

    It is trivial to do what "caller ID" does in an open fashion. And it is absolutely crucial that we do exactly that. No "complicated" licenses, no fancy agreements, no lawyers. Just pick a standard, and follow it.

    Letting Microsoft have any involvement in the email infrastructure - other than using it - will be a disaster. And it wll be all the more terrible because of how easily it can be prevented.
    • by thogard ( 43403 ) on Sunday July 25, 2004 @10:18AM (#9794200) Homepage
      The problem is no one has done it yet.
      Every poject seems to get hijacked into committees that never get the real work done.

      Take SPF for example. It was mostly pushed by one guy into some code and that is starting to move on, but why do I need to do that much extra work when the existnig DNSBL stuff works and could be used in nearly every MTA as is without doing any extra code?

      I worked on the X.400 Gossip committee back in '92 or so. The result was the system was too big to be useable and the complexity was so bad that no one ever got it right. The fundamental with email is that I want any person in the world to be able to send me a message but I don't want spam. The problem is there is no tehcnial way to tell them apart.

      I do agree with RMS that going down the MS path is a dead end that will only result in MS getting more money and gives them the ability to kill off all open source systems with their patents and I know they will use them. The one thing we have learned about patents is that it doesn't matter at all if someone gives us rights to use it, they can change their mind and then we have to pay.
      • All true, but we can probably stop address forging.

        If no one's done it yet, then this is basically the call to arms. If we don't do it now, Microsoft will coopt and destroy email.
      • by Iphtashu Fitz ( 263795 ) on Sunday July 25, 2004 @11:06AM (#9794417)
        but why do I need to do that much extra work when the existnig DNSBL stuff works and could be used in nearly every MTA as is without doing any extra code

        First of all SPF targets an entirely different problem inherent to spam than DNSBL's do. SPF specifically targets forged "From" addresses. DNSBL's target the originating IP of the e-mail. You can't target one type of spam using the other method.

        Second, even support for DNSBL's didn't exist in the vast majority of MTA's until spam became a problem and the first DNSBL's like MAPS [mail-abuse.com] came along. If SPF becomes more and more widespread in its use then I'm sure you'll start seeing support for it getting rolled direclty into MTA's rather than having to use add-on's.

    • [i]It is trivial to do what "caller ID" does in an open fashion. And it is absolutely crucial that we do exactly that. No "complicated" licenses, no fancy agreements, no lawyers. Just pick a standard, and follow it.[/i]

      Exactly my thought. So why is this an issue? Can we not write on own code for sendmail and other open email servers? Why does this sound like RMS is FUDing us just a bit? Sure MS' software will be non-GPL be we expect that. How does this stop anyone from writing SenderID checking softw
      • by Anonymous Coward
        As the inventor, no doubt MS will hold the patent. So you have to license it, whether for GPL or otherwise.

        If the license isn't GPL compatible then GPL software can't use it.
        • M$ didn't invent SPF... they invented Caller ID. Sender ID is just the combination of those two things.
          • If the patent even partly applies to sender ID, you're screwed nevertheless. And it's quite possible that the patent office will consider the combination of those two things non-obvious as well, resulting in another patent on the whole thing.

            That said, I have no idea whether their called-ID patent applies nor whether they already have another patent (pending) on the combination of SPF and called-ID.
          • And much of the original Caller-ID has been rejected, so there is far more of SPF in Sender-ID than there is Caller-ID.

            Also nowhere have I seen any indication from Microsoft as to exactly what they are claiming the IP rights for. All that I have seen is that they stated that parts of Caller-ID are covered by a parent application and require to be licensed.

            Some people have suggested that the patent is on the PRA algorithm (which determines the 'responsible' sender of the email) but this is basically just a
      • by gaijin99 ( 143693 ) on Sunday July 25, 2004 @11:24AM (#9794474) Journal
        How does this stop anyone from writing SenderID checking software that is GPL'd or GPL friendly?
        It stops it because MS has patents on some of the critical aspects of the "standard", and their license for using the "standard" can be modified to preclude someone from implementing a GPL'd implementation. It doesn't now, but they explicitly reserve all rights, and state that they can modify the license at any moment, so what keeps them from screwing us with this?

        Look at what SCO is doing now, claiming to own ELF, using that as an attempt to demand money from Linux users. If we let MS's non-open "standard" become a real standard they'll wait a few years until everyone depends on it, then use it as a weapon to try and crush competition. I'm not being paranoid here, I'm simply extrapolating from MS's history; they do that sort of thing on a regular basis.

        • The more common occurance is the company that promises not to enforce their patent, sells their patent. Or goes out of business.

          The new company never made such a promise, and further, they bought the patent with the expectation to enforce it for profit.

          We dont expect MS to go out of business, but they could loose interest and sell the patent at any time.
        • As far as I know, it's not legally possible for someone to make a retroactive license.

          Thus, if someone takes the standard and makes a GPLed application with it, the principles and code within that application are then made public domain. MS has patented it, yes - but it would also seem that they would be either not protecting their patent intentionally, or giving blanket rights to the patent to anyone that asks via the GPL.

          • Placing something under a GPL license is nothing like making it public domain.

            Public domain means that the authors have surrendered their copyrights over the material.

            With the GPL, the authors still retain full copyrights to the material. The license defines how you are permitted to use it. If you do not follow the license, you have no permission to use it.
        • they do that sort of thing on a regular basis.
          Name one instance where MS has pulled a Rambus and had their patented process integrated into a standard, then sued everyone over implementing the standard.
      • by Zeinfeld ( 263942 ) on Sunday July 25, 2004 @11:44AM (#9794551) Homepage
        Exactly my thought. So why is this an issue? Can we not write on own code for sendmail and other open email servers? Why does this sound like RMS is FUDing us just a bit? Sure MS' software will be non-GPL be we expect that. How does this stop anyone from writing SenderID checking software that is GPL'd or GPL friendly?

        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.

        • Mod Parent Up. Straight from the horses mouth.
        • by a_n_d_e_r_s ( 136412 ) on Sunday July 25, 2004 @12:24PM (#9794794) Homepage Journal
          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.
          • Actually publishing an idea will prevent it from being patentable by others accordingin to the law.

            In theory yes, in practice no. Microsoft had a $500 million judgement against them on the Eolas patent before that got squashed. They were not even allowed to present their evidence of prior art. There are plenty of judges who are as stupid as the USPTO examiners.

            We spent millions 'winning' a bogus patent case.

            The situation in the MARID WG is like the UN weapons inspectors in Iraq. We have given Micros

        • by wayne ( 1579 ) <wayne@schlitt.net> on Sunday July 25, 2004 @12:45PM (#9794933) Homepage Journal
          PHB?

          RMS has made no attempt to talk to anyone in the group to find out the real situation.

          I'm not sure how you know this. Apparently he was communicating with Michel Bouissou.

          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.

          For those who aren't in on who's-who on the IETF MARID working group, Harry and Jim are two of the folks from Microsoft who are working on the SenderID proposal.

          However, I know that I have been asking for resolution for this licensing issue on the working group for much more than a week. This is not a new issue.

          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 is almost completely not true. Microsoft lawyers have been in discussions over the license issue since early June (6 weeks ago). While there were indeed some luckers who posted first about the license issue, many of the active participants in the working group started the license discussion. People who object to the current SenderID license for MS do want the best proposal possible. If no one objected to the license, we would have a bad proposal.

          • I'm not sure how you know this. Apparently he was communicating with Michel Bouissou.

            If he had made any effort to find out the Microsoft position he would know that the Microsoft lawyers were working on the situation. He could have found that out by reading the post on the matter from Ted Hardie the IETF area director.

            RMS never bothers to find out what the situation is that he is wading in to.

            This is almost completely not true. Microsoft lawyers have been in discussions over the license issue since

        • Marid is an Arabic name meaning "rebellious". I'm just wondering if this was intentional or a coincidence.
        • This type of scheming is both unprofessional and damaging.

          I don't see any "scheming". RMS is warning about what seems to be the legal situation right now. Instead of pointing us to facts that contradict his view, you are just giving us a lot of verbiage, flaming, and accusations, and you are telling us that we should trust you and that everything is going to be right in the end.

          This is the machinations of a faction who want to use MARID for conducting a vendetta against Microsoft and don't care what t
    • See how James Ewing of Sveasoft treats people who follow the GPL! [streamfire.net]

      Posting binaries without source is a violation of the spirit and letter of the GPL. Ewing is right to go after that jerk.

      • The source has been published and is now on the page, so this problem is solved.

        • Who produced the binaries? If they are the original Sveasoft binaries, the guy is still in violation of their copyright. The GPL gives him the right to publish source. It's up to the copyright holder (the one who produced the binaries) to give or withhold permission to distribute them, and pretty clearly Sveasoft didn't give their permission.
    • Letting Microsoft have any involvement in the email infrastructure - other than using it - will be a disaster. And it will be all the more terrible because of how easily it can be prevented.

      To be honest, I'm still not convinced that letting them just use e-mail wasn't a disaster.

      c.
    • Let someone else innovate, steal the idea, clone it and compete against them without rewarding them for their work.

      Name me five open source products that aren't simply a clone of a commercial products.

  • IANAL and don't want to be, but I always wondered what were the implications of this RFC (which is about intellectual property rights & IETF publications)

  • by Kadmium ( 679058 ) on Sunday July 25, 2004 @10:12AM (#9794184)
    Newsflash: OSS community dissatisfied with Microsoft's actions. The shock caused by this devastatingly original sentiment is almost immeasurable.
  • by blowdart ( 31458 ) on Sunday July 25, 2004 @10:25AM (#9794223) Homepage
    Here is the microsoft license [microsoft.com]. It applies to the original Microsoft Sender ID spec [ietf.org]. This is not the new spec, where they merged [microsoft.com] with SPF.

    So, the license RMS is ranting about doesn't apply, and there doesn't appear to be another license on the Microsoft site. Having said that the 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".

    Of course the SPF implementation [pobox.com] is still "non-licensed", there's no mention of restrictions, although they do point out there are patents [pobox.com] all over the anti-spam arena.

    But hey, we don't expect people to look at this stuff, lets just add yet another protocol.

    • Thank you for the clarification. This post is more informative than the original article. Incidentally, I think MTA authentication is a good idea, but I also think that all e-mail should be authenticated at every step, and encrypted using public-key encryption.

      Validation, encryption, and a great anti-spam measure all in one. Is my logic flawed?

      • if the emails themselves were authenticated.

        If the emails themselves are authenticated, the MTAs just become a delivery mechanism (which is actually what they really are today anyway). Which MTA delivers the authenticated email doesn't matter, and therefore MTA authentication doesn't matter.

        Authenticating emails would ensure you absolutely known the sender. A spammer wouldn't be anonymous anymore. Once they aren't anonymous anymore, anti-SPAM laws would be very effective at reducing or preventing spam.

    • by NigelJohnstone ( 242811 ) on Sunday July 25, 2004 @11:12AM (#9794433)
      '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". '

      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/spam _s enderid.mspx

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

  • by gbjbaanb ( 229885 ) on Sunday July 25, 2004 @10:27AM (#9794234)
    its probably a good thing. If anyone could amend the software, they could, for example, add a section that says 'but accpet all spam.com emails'.

    I understood that the protocol was to be made into a standard, so how would changing the software help us?

    The Licence (pdf) [microsoft.com] says that MS grants you a non-transferable licence to use it and sell it on to end-users.

    If you do redistribute the source code, its fine, but you must add a clause to your licence that says the software may contain IP owned by MS, and that anyone obtaining such derived source must go ask MS for permission to use their bits directly - you can't give that away.

    So I can only surmise that when RMS says it is incompatible with free software, he means the GPL. It is acceptable to use the software, look at it, but you can give it to someone else, but they cannot take away the terms MS set. Sounds a bit like the GPL, but with different terms. (hey RMS, you don't want to agree to those terms, you don't have to use the software).
    • Sounds nasty (Score:3, Insightful)

      "If you do redistribute the source code, its fine, but you must add a clause to your licence that says the software may contain IP owned by MS, and that anyone obtaining such derived source must go ask MS for permission to use their bits directly - you can't give that away."

      Sounds nasty, an obvious play would be to get this non-standard widely accepted then for MS to refuse permission to new licensee's unless they pay a fee.

      That would then lock out free software.

      Because you need their permission to get t
    • by Pharmboy ( 216950 ) on Sunday July 25, 2004 @10:48AM (#9794328) Journal
      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 [microsoft.com] you provided.
      • 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)

        So it's more BSD-like then, big deal.

        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.

        Why is that different to the GPL? They're both licences that apply to the use of software. Without

        • by Pharmboy ( 216950 ) on Sunday July 25, 2004 @11:59AM (#9794653) Journal
          So it's more BSD-like then, big deal.

          Actually, it is a big deal. The old BSD license that had the advertising nag is NOT GPL compatible, per the FSF.

          They're both licences that apply to the use of software.

          You need to READ the GPL. It flatly says you need NO license to use it, only to distribute it. This is a major difference in Free and non Free licenses.

          Newsflash: licences are contracts.

          Not according to the law. A license is a grant to someone to use copywrited material. There is more than enough case law on the differences that I won't go into detail here, google it.

          Isn't that more of a self-defence clause in case people find bugs and want to sue Microsoft about it?

          Yes. And it is so vague and broad in scope that the potential for abuse is a serious concern.

          Big deal. Why does everything have to be GPL compatible? What would be wrong with, say, a BSD-style license for this particular application?

          That would be fine. A modern BSD license *is* GPL compatible. (without the ad nag). This license is not "Free". Its not the worse license in the world, but its still not Free. When it comes to software that sets standards for the entire internet, it is much better for it to be Free, so that one company does not abuse it. Technically, this license would allow MS to change its mind once the technology is developed, and start charging people to use the technology. THAT is why the license must be free, to protect everyone who uses the internet, including your right to sell the software for any price you want.

          I don't care about the license for MS Office, I can choose to use Open Office, but if MS patents this, then gets greedy, I can't run mail servers without paying a royalty (at least the servers wont be able to connect to other servers that require this 'patented' protocol). This is not acceptable to me, even if it is not likely to happen.
        • 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)

          So it's more BSD-like then, big deal.

          The BSD abandoned that clause for a reason. But Microsoft's license actually goes much further. If you distribute source code under a BSD license, the recipient still has no rights to use the software unless they contact Microsoft and get permission specifically. The license r

    • Before you go all Sally Field on Microsoft, can you name another common Internet spec that you have to sign an agreement to use?

      You call it a License, which it is not, Microsoft calls it an Agreement.

      A License is a one-way set of conditions. Anyone can use the product under the terms of a License. The GPL is a license to use copyright works.

      An Agreement (or License Agreement, or Legal Agreement, they all mean the same thing) is a contract with mutual obligations. You can make any set of conditions th
  • It is absolutely essential that standards like this are open and available to everyone (including microsoft's competition). I haven't read the microsoft license yet, but if it indeed creates any type of obstruction for open-source (or any other) software, it should be soundly rejected.

    It isn't clear to me from this story or the comments exactly how Microsoft would claim any type of control here. Can somebody clue me in?

  • by MarsF ( 631122 ) on Sunday July 25, 2004 @10:30AM (#9794247)
    * To: rms@xxxxxxx
    * Subject: Re: Sender-ID and free software
    * From: "Douglas Otis" <dotis@xxxxxxxxxxxxxx>
    * Date: Sat, 24 Jul 2004 14:23:54 -0700 (PDT)
    * Cc: "IETF MARID WG" <ietf-mxcomp@xxxxxxx>, team@xxxxxxxxxxxxx
    * Importance: Normal
    * In-reply-to: <>
    * List-archive: <http://www.imc.org/ietf-mxcomp/mail-archive/>
    &n bsp; * List-id: <ietf-mxcomp.imc.org>
    * List-unsubscribe: <mailto:ietf-mxcomp-request@imc.org?body=unsubscri be>
    * References: <>
    * Sender: owner-ietf-mxcomp@xxxxxxxxxxxx
    * User-agent: SquirrelMail/1.4.2

    <* snip [ed] *>

    Richard,

    In the case of the PRA proposal, proponents have difficultly explaining
    why this concept is better. PRA ensures there is NO relief with respect
    to network overhead, even if messages are rejected. PRA ignores the
    primary motivation for which identity is being spoofed, being a means to
    avoid accreditation filtering, the RFC 2821 MAIL FROM. If accreditation
    is allowed to become more effective with CSV, this oversight is
    significant. A rather weakly supported claim is this will end phising.
    Support for PRA checks overlooks the identity significant to the user, and
    that many techniques still exist to allow phising, some without the need
    to publish DNS records by the entity committing the fraud.

    There is also a potential for network instability caused by early
    termination of a series of DNS queries, that both allow accumulation of
    outstanding UDP traffic and necessitate the resending of the messages. A
    serious flaw made far worse with PRA. As PRA has been isolated, envision
    rejection of both the Submitter and PRA draft. Take the BATV draft of
    Dave Crocker and add a mode using an address based technique to include
    the SPF record sets. This would allow Forwarding and List Servers for the
    most part to continue working, without the use of Submitter. (EzMLM may
    be an exception for signatures, but would still work with the SPF mode.)

    Submitter and PRA should be rejected as being highly disruptive. Combine
    SPF with BATV. Submitter and PRA fail to provide the most basic goal of
    the MARID charter. That is to authenticate (and authorize) the MTA domain
    (responsible for policy as implied with DNS), as compared to CSV that
    ignores filtering objectives of messages, but accomplishes the basic goal
    of the charter.

    -Doug


    Just a little contrast for those who read only one level deep.

    Mars
    • Now could someone please translate this acronym-laden message for those of us who do not happen to have spent their entire lives following this particular mailing list? (Don't get me wrong, of course it's only natural and quite alright for them to develop their own abbreviations and conventions, and no doubt some will already be familiar with them, but how is a wider audience supposed to understand it, this way, taken out of context and posted here?)

      Without a truckload of background information, it is hard

  • by Ianoo ( 711633 ) on Sunday July 25, 2004 @10:31AM (#9794252) Journal
    So, we have Microsoft in the distinctly red corner with their proprietary standard.

    Let's face it, as vocal as the OSS community is these days, there's not a lot that can be done to stop Microsoft from doing whatever the hell they like, so long as it's legal(!). Sure, sendmail is OSS software, but I got the impression that SPF is pretty much independent of the MTA software anyway.

    But, in the blue corner, we have plenty of heavyweight companies who are big on Linux and big on e-mail who have teams of lawyers that have undoutedbly been over this license already, and found the problems.

    We have IBM, the people who make Lotus Notes, which is still pretty widely used, IIRC. We have Novell, who now own SuSE/Ximian and are betting the shop on Linux, who produce NetWare. We also have Sun, who are getting vocal on OSS, which produces Solaris, which seems to power a large proportion of MTAs around the globe.

    The best defense, surely, is to make sure these companies understand the issues with SPF, and don't implement it in their own products. After all, Microsoft won't get that far without support from other companies, since much as they'd like to, they don't currently control the world's Internet server market....
  • by wayne ( 1579 ) <wayne@schlitt.net> on Sunday July 25, 2004 @10:45AM (#9794307) Homepage Journal
    I've been very active in the SPF project for a long time and have been very active in the IETF MARID working group that is standardizing the merged SPF and Caller-ID spect. In particular, I have been a very vocal critic of the MS license have have tried to work both within the IETF working group and outside to make the license compatible with all major mail servers (MTAs) and other packages, such as spam filters.

    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.

    • You have to admit though, if the licensing terms are not "drum tight", then Microsoft can just take anyone to court and financially bulldoze their way to a verdict of their choosing.

      We've already seen how they "pimped" the US Government, and as far as lawsuits go, that didn't even take that long.

      I think that's the thing that scares people.
    • 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

      Microsoft is a corporation, not a human person. Whether its minions have good faith or not is beside the point.
    • I'm sure the Microsoft lawyers have ALREADY evaluated the various Open Source licenses so it shouldn't take them long to just pick one.

      The coders that are working on this at Microsoft are NOT the ones that will be choosing the license.

      The LAWYERS working for Microsoft will be working on an approach that is BEST FOR MICROSOFT. (read that as "control").

      It all comes down to a matter of priorities.

      Microsoft's FIRST priority is to establish control.

      Microsoft's SECOND priority is to stop spam.

      If Microsoft w
  • finally (Score:4, Insightful)

    by CAIMLAS ( 41445 ) on Sunday July 25, 2004 @10:47AM (#9794318)
    Finally, now I know what to think about all this.

    I was beginning to wonder if I was supposed to think MS had done something right for once... :P
  • by gillbates ( 106458 ) on Sunday July 25, 2004 @11:01AM (#9794390) Homepage Journal

    Why shouldn't free software be the first to implement secure email? Imagine how much easier Linux advocacy would be if we could say: "SPAM? - I thought that was a Windows problem?..."

    Imagine this conversation:

    Tech: What's the problem?

    User: I get all this SPAM, and I can't read my real email.

    Tech: Let me guess, you're still using Windows, right?

    User: How'd you know?

    Tech: Because you're still getting SPAM. If you upgrade to Linux, which uses the SPAM-blocking mail protocol, your SPAM problem will go away... I'll send you a CD in the mail.

    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. What we should really be doing at this point is implementing a SPAM-free mail protocol in free software, which, once it became the standard, would force commercial companies into compliance, rather than trying to play a game of dodge-the-patent-lawsuit by copying someone else's improperly done anti-SPAM protocol.

    Let's face the facts here, folks: if we wait for Microsoft to implement an anti-SPAM protocol, they'll do it wrong, and the free software world will be stuck trying to ensure compatibility with an interface that is fundamentally broken in the first place.

    • The OS on the end-user PC is irrelevant. Any serious spam-BLOCKING proposal (as opposed to spam-FILTERING) takes action long before the mail hits your inbox, much less gets displayed.

      So you ask, why not run spam blocking on all open source MTAs? Simple: it takes two to tango. Email is a communication medium, emphasis on that prefix "co-". Your new Final Ultimate Solution to the Spam Problem [rhyolite.com] is useless if the other guy's server doesn't support your protocol. And I suspect most of us are unwilling to cut o

      • Granted, it does need to run on the server. But why not simply add to the existing infrastructure?

        The web has mostly replaced ftp by now. Yes, it's still available, but far more people like to browse the web than ftp'ing files and viewing them later.

        It's the same principle. There's email, and then there's securemail. Write the protocols, the clients, and the servers, and let it take off like P2P did. There's no need to completely replace email at first, but after a while, it would go the way of t

    • Imagine how much easier Linux advocacy would be if we could say: "SPAM? - I thought that was a Windows problem?..."

      Of all the reasons for implementing a secure, spam-free alternative to the current version of SMTP, I think "acting smug towards Windows users" must come last.

      Sheesh, since when is easy advocacy a goal by itself?

    • 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.
    • >> Let's face the facts here, folks: if we wait for Microsoft to
      >> implement an anti-SPAM protocol, they'll do it wrong

      Why is this a fact? They've been doing a lot of things RIGHT lately if you didn't notice. .NET Framework, WinXP SP2, Win2K3... They just keep cranking it out all the time.
    • Are you an idiot?
      As if the solution is that simple.

      What the fuck is on that magic cd of yours? An email client that connects to special spamproof linux email servers? What about the other million email servers out there. Or is it a beefed up filtering client? Huh?

      I'm sorry. The answer is not that easy. There are two choices, clientside or serverside. Clientside masks the problem, serverside is what groups like this are working on and are EXTREMELY difficult to coordinate and do properly. They are trying
    • 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.

      I'm sorry, but you totally miss the point here. First, you have to realize the original source of FOSS, which was Unix, before AT&T started suing people. Code was shared freely, thus the standards that the entire Internet are based on are either Free or PD. Apache isn't exactly a rip off of IIS. Sendmail is a clone
  • by Rayban ( 13436 ) on Sunday July 25, 2004 @11:02AM (#9794391) Homepage
    The site Boycott Caller-ID for E-mail [boycott-em...ler-id.org] 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.
  • Comment removed (Score:3, Insightful)

    by account_deleted ( 4530225 ) on Sunday July 25, 2004 @11:21AM (#9794465)
    Comment removed based on user account deletion
    • M$ is always trying to change that. Everywhere they don't dominate, they buy the one that does, or start a new standard compatable with no one else, put it un Winblows and tell the rest of the world: you will follow this standard if you want to deal with Winblows users. They shove it down everyones throat.

      Standard operating proceedure from Redmond. If they can't dominate something, change the rules.
  • by Anonymous Coward on Sunday July 25, 2004 @11:24AM (#9794477)
    There was a big discussion on the IETF MARID mailing list about the problems with the license. Finally, the IETF posted this: IETF 's says we shouldn't worry about the license [imc.org]

    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

    • by NigelJohnstone ( 242811 ) on Sunday July 25, 2004 @12:11PM (#9794727)
      "1) This discussion has been unprofessional in the extreme. "

      Get a thicker skin.

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

      The wording requires you get a license from Microsoft and that any future products require a license too. So clearly this problem comes under the "ability to implement" part of the sentence.

      3) There is no such thing as a 'defensive' patent. Ted cannot see into the mind of Microsoft and determine their intent is to only use it for defence. Therefore he cannot make this statement with any substance behind it.

      4) Non substantial argument. The license is very clear, show me a lawyer that says otherwise.

      5) Agreed.

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

      Oh boy, we have a spec that has issues XYZ,
      he's telling them to look at X and only X. i.e. to ignore Y & Z and make a decision based on only part of the information.

    • Re-read #2, #3 and #4.

      IETF does not concern itself with patents/licenses and has published standards that include patents and you don't know what patents are, anyway.

      Bugger off. The patents and the licensing are VERY IMPORTANT to the implementation of the standard. Otherwise, you're writing a standard that won't be implemented. Why do that?

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

      Yes
  • by Skapare ( 16644 ) on Sunday July 25, 2004 @11:53AM (#9794613) Homepage

    I think we need to take a look at where forged sender spam comes from before we are willing to consider trying to detect forgery as a means to detect a message as being spam. In the past, small time spammers did forgery to avoid flooding their one mailbox. Now days, bigger spammers have domain names (often thousands of them) and don't have to worry about that issue. But there are still spammers doing forgery. Most of these using the infected zombie machines on insecure home computers often connected 24x7 via "always on" DSL or Cable.

    If the providers hosting these users would:

    • block outbound port 25 from these users (with certain exceptions)
    • require SMTP AUTH to log in to their provided mail server
    • rate limit mail sent through that mail server (for example no more than 30 messages per hour)
    then this would go a long way to defeat the utilization of these infected machines as a spamming tool.

    I mentioned an exception to the port 25 blocking. They should simply allow port 25 for anyone who mentions certain keywords indicating they need it. While there is some spamming that originates at the DSL or Cable user, that doesn't account for much right now. So sure, someone intent on spamming can call in to customer support and ask "please enable SMTP for my access account". But they would be fewer in number than those who ask the same because they just want to run their own home mail server without having to forward through the ISP's mail server. And one simple way to do this is to ship DSL/Cable modems with SMTP access disabled except for the provider mail servers. And manufacturers could do that if providers would set up private IP addresses to access their mail servers (so by default SMTP would be allowed to 10.0.0.0/8, 172.16.0.0/12, 169.254.0.0/16 and 192.168.0.0/16). Someone who wanted to run their own mail server could simple change the settings. The average user who lets machines become infected would know nothing about it.

    Like anything else, this isn't a solution to spam. But it is a viable alternative to forgery detection in terms of catching most of the spam from most of the sources being used by the spammers that do use sender address forgery.

  • He's such a zealot that he's going to trash anything that's not completely open and free, even if it has the potential to improve a serious situation.
    • You're being a zealot yourself. If this standard goes through unchanged, we'll all be paying royalties to MS if we want to use email. The mere mention of the initials RMS is all it takes to shut down all cognitive functions of most readers here. RMS' point is damned valid and wouldn't be very controversial if it came from anybody other than him.

      There is no problem serious enough that the solution merits MS or any other company being allowed to hijack open infrastructures.
      • Well, perhaps I am an anti-RMS zealot.

        Anyhow, you've missed the point of my post. The issue he was being asked about is irrelevant. My point is that no matter what you ask him, his reply is one hundred percent predictable. If you ask him "What do you think of Skype releasing a Linux binary?" his reply would invariably be along the lines of "It should be avoided at all costs because it's a closed-source product."

        Free software is great, I use it whenever I can. But there are certain situations where closed
  • When I learned that the Microsoft additions were being added, and that they were going to use XML, I immediately thought 'hah! bloat! typical microsoft! This data does not require or need or benefit from using XML.'

    But, I was wrong. Adding XML allows them to patent it. That is the ONLY reason why they are using XML.

    --jeff++

Software production is assumed to be a line function, but it is run like a staff function. -- Paul Licker

Working...