My last post on THE soap

14 Comments

• The license text says (quoted from the c&d letter jamie posted):
  "... you may use the sw only as expressly permitted in this agreement. in doing so you must comply w/ any technical limitations in the sw that only allows you to use it in certain ways... you may not work around technical limitations in the sw."
  
  all the examples i've read so far about how this could cripple legitimate sw-development simlpy don't have anything to do with what the sw allows you to do. a bug is obviously not a technical limitation that does not allow you to use the sw in a correct way. whether this will hold in court for the TD.NET case remains to be seen. however, I don't understand why it's a problem for so many people that MS is going to try it, even if they admit that jamie was obviously acting against the spirit of the product and was actively implementing a way to work around the missing add-in manager.
  let them try, the court will decide. if it decides in MSFT's favor, this still does not mean that they can sue anyone out of business for fixing bugs, because this would simply be an altogether different situation.
  
  btw, removing public APIs is not always easy. what if those are just public interfaces in assemblies you use internally? lets be glad that .net makes everything more open, and not force ISVs to close everything down technically. i'd hate to see obfuscated assemblies everywhere just because people feel its somehow evil to enforce certain conditions via licenses instead.
  

• Yowser, Frans backing down from his position? Are you feeling OK? :-) JK
  
  This is a good post but you're still missing a point. Jamie would never know about these API's and could have never found the holes without using reflector or a similar tool which is reverse engineering. From my perspective that makes this an open and shut case. He reverse engineered Express before ever got to the point of building a piece of software that works around the technical limitations. It would have been impossible for him to use notepad and the .Net SDK to build TestDriven without know how to hook himself into Express. Just look at his code. Sure Microsoft may not be able to prove this in court but no developer could write that code without lots of intentionaly poking around and trial and error.
  
  I agree this is getting old. Microsoft will come out of this fine but it's a loose loose situation for Jamie.
  

• Chad: erm.. where do I back down from my position? :) I still have the same opinion as last year and yesterday about this. I just want to make clear that I don't want to be sucked in either camp for the wrong reasons. :)
  

• David: why is it so hard to understand? NO, I don't say it's OK to be unethical. On the contrary... I just say it's very ironic to play the ethics card if you're unethical yourself ('yourself' here being MS).
  
  I also just want to make clear that writing code which uses public, published APIs is perfectly OK, as it's just normal code which uses public published APIs. Why is that so hard to understand for some people? Apparently you find it perfectly fine to be bullied around by some lawyer drone because that lawyer finds it unfair that you use a public published API method somewhere in your code.
  
  Well, good for you, but I won't find that OK. Mind you: I did say a dozen times: if the code you write stays within the law there's nothing wrong with the code. Apparently that's a tough pill to swallow...
  
  We're not talking locks here, or copy protection and crack code or whatever. We're talking code using public API's, which are documented. If you find it dissapointing I stand up for my profession as software engineer, that I find it silly that some lawyer tells someone not to use public published api's in his code, so be it. But trust me, I find it really dissapointing to read on various websites that there are people out there who apparenlty agree and incourage the situation where a software engineer has to be afraid with every public method used and with every algoritm implemented.
  
  THAT was my point, and you seem to not understand that. I'll quit now before I get angry again about this whole stupid MESS.
  

• You're just focusing on the single issue that speaks for your opinion: the fact that this API is public. You're ignoring the facts that a) MS removed the addin-manager that gives you access to that API from within the VS express process in the first place, and b) MS was very clear that it doesn't want anyone to extend VS express. You're ignoring my first posting too, unfortunately. I really think your reasoning is flawed (although I do get it, you just assume people who disagree don't understand), and getting angry is no replacement for defending your point of view.
  

• Chad,
  
  >Jamie would never know about these API's and could have never found the holes without using reflector or a similar tool which is reverse engineering. <
  
  Really? /never/?? ...well, I guess security through obscurity is ok then... ;-)
  

• Congratulations Frans, I think that near all in the community feels like you, and you talk excellent, thanks a lot for all your posts and comments =)
  
  I cant belive like some in the comments of Dan (some ISV) said: "destroy that guy" there are so IDIOTS !!! and miss the point, because they dont do nothing for express why they hate others that have the corage to do it. He have all the fear to MS that MS wants.
  
  Keep in the good work
  
  Marcos
  (I edited your comment for 'M$' into 'MS' -- FB)
  &nbsp;
  

• To legally use a copyrighted product, you need some sort of license. That does not mean that you can sue anybody (like end users who broke a seal) over anything the license says (like selling your grandmother if you violate some clause). But Jamie runs a buiness buildt on extending VS, so you would assume he is aware of the EULA. The license term is about what kind of use is granted. If you're not granted the right to use a product for something specific, where does the right come from? I don't see any reason why MS should not assume that the EULA applies. If it would obviously not apply, suing would be bullying. But chances are that it applies.
  
  We seem to have different expectations about how a court would judge. My understanding is that MS has reason to believe they can win this lawsuit, but that it would not apply to different cases, like integrating LLBLGen in VS standard or above. If MS loses, it's their fault - they should have put more effort into preventing extensions. If Jamie loses, it's his own fault too - he must have been aware that MS does not want an ecosystem built on VS express, but he thought he found a legal hole to push it through and failed.
  
  I did not fully get your point though. Are you bothered because you think MS is clearly wrong to assume that the EULA works? Then they'd have to assume that they are going to lose the lawsuit. If they still sue a small competitor, that would be bullying, and next time they could be bullying me or you. Is that it?
  
  Or is it that you think they would win, and that this would also apply to cases like the LLBLGen one? But if you think they would win, how could you at the same time maintain that the EULA clause cannot be applied?
  
  The comparisons you make don't seem to be too similar. VS express's is not missing a certain feature that could be provided via extension, but the possibility of being extended at all. This difference is exactly what a court would have to look at in order to make a judgement. MS never claimed that providing 3rd-party TDD support for VS std violates the license, although a similar functionality is available with VSTS and was deliberately excluded from cheaper versions. That would be a smoking gun that I'd be scared of. The situation would not even be the same (but more similar) if the assemblies with the TDD-support were delivered with VS std and only disabled in the menu. In this case, Jamie would be able to argue that he was allowed to build extensions and was only using public APIs, like you explain. In this case, the fact that it is unclear whether this argument would be accepted in a court would be a problem for anyone building on the .NET plattform or any "extensible" MS product, like VS std or Office. But this is not the situation.
  Extending a product that MS does not want extended is not a business model anybody would rely on in the first place. This makes all the difference here, does it not?
  
  Cheers,
  Stefan
  

• This is a response to Stefan. As a student, and a new user to VS.NET Express (coming from Java), I had no idea that "add-ins" were a "feature" that microsoft had available in another product (std/pro versions?).
  But to quote
  "Extending a product that MS does not want extended..makes all the difference here"
  means that somehow I need to research what MS wants and does not wants, and have to research their other products to know that "add-ins" are something that, *they didn't disable*, but didn't want?
  This is exactly the kind of nonsense a java developer gets to avoid...
  

• Frans,
  
  you're right, the question of whether EULAs apply is a difficult one. But all I'm saying is that MS has reasons to believe they do apply, so it's just natural that they would enforce them if they see them violated.
  
  As for whether they stand a chance of actually winning the case, I think we just have to agree to disagree. I'm no lawyer, and I know little about the UK legal system, so I can't go into a detailed discussion about this. My experience with Austrian law would lead me to believe that MS stands a good chance here, if all things are considered. But then again, this might be a difficult call for any court, and the outcome may well depend on which court gets to decide. This uncertainty is also a good reason for MS to try and resolve this peacefully (besides the PR perspective which they so much underestimated), so shying away from a lawsuit is not always a sign of knowing that you're wrong. Often, it's just reasonable risk minimization, everyone does that. I would.
  
  I maintain that if MS gets their will in court, this will only be because all details of the current situation are considered. So I would not be too afraid that this sets a straight precedence for a similar, more problematic one like the LLBLGen one I've obviously made up. (I thought you were comparing this case to MS suing you over integrating LLBLGen with VS in some previous comment or posting, but could not find it.)
  
  I believe that Jamie was not acting in good faith here, that he must have been aware that MS does not want this, that he must have been aware that he was working around an intentionally introduced obstacle, and that he should have checked the EULA and, when in doubt, just ask MS whether they'd object. This is not only about competition between Jamie and MS, but also about competition between VS SKUs. I don't believe any comparison to another case that you and other bloggers make works. Competing with MS products on MS platforms is not anything you'd expect MS' lawyers to go after you for.
  
  You seem to argue that besides being a direct precedent, this somehow makes any broad license clause more enforcable (I guess they'd have to win in court to achieve this). Or that it just shows that MS is willing to enforce broad clauses, which should bother ISVs and the OSS community.
  
  I'd agree with this statement. (Although I'm not really scared about it, because of the reasons I think Jamies situation is different from anything I'd do or try, but that's just my opinion. Can't really argue about that.)
  
  If this is what you mean, I think you should make this clear. This would be a way of putting it that would probably resonate better with MS employees.
  
  If you argue that their legal opinion is wrong, they would lose a lawsuit, and they're just bullying or hoping for a clueless judge, you should make that clear too. Because if this case is settled out of court, it will be hard to find out whether this is true, and the uncertainty will remain.
  
  I fully agree that the EULA should be more specific, and it's unfortunate that MS didn't realize this in the first place. But if this is all they have, I understand that they'll take their chances with it. (Unfortunately, in my experience some layers tend to recommend not being to specific in contracts, if they think that some ceneric clause already does the trick if you bend your brains backwards around it.)
  
  When you argue that everyone needs to go out of their way to make technical limitations instead of EULA clauses, I'd disagree. I like the way that every assembly has public interfaces and meta data in .net. If it were my product, I'd hate to have to find a (probably bug-ridden) workaround for this. How do you keep the functionality of an assembly, but keep its interfaces private in certain bundlings? This is not a road I'd want to go down, and I think it's a mistake to ask for it.
  

• Josh, if you'd build a business around extending one of my product, yes, I'd expect you to browse the web site and know the license.
  

• If I understood correctly, the 'license' was the EULA, which had no language in it about developing add-ins or even that extending the product was not allowed, just some vague notion of "technical limitations".
  
  Microsoft made a mistake in their EULA, and now they're trying to make this guy pay for it.
  
  In my opinion, they should acknowledge their mistake, release an updated EULA with the new downloads, possibly update their software to block add-ins, and be done with it. Instead, they chose to attack their developer community over a mistake 'they' made in their license.
  
  What if Frans wants to offer VS.NET integration of his product in the future? Will Microsoft crush him too because it 'competes' with their LINQ offering? Will his innovation be curbed by lawsuit worries? This kind of fear tactic does not promote healthy competition nor growth for the platform, and has seemed to me Microsoft's business as usual.
  

• Josh, I don't know what to tell you, we've just been over this in much more detail. No, the EULA does not contain explicit language about add-ins, but it does contain a generic clause that is not quite as vague as you claim. It just seems so because it's often cited incompletely. Here's the text:
  
  "9. SCOPE OF LICENSE. The software is licensed, not sold. This agreement only gives you some rights to use the software. Microsoft reserves all other rights. Unless applicable law gives you more rights despite this limitation, you may use the software only as expressly permitted in this agreement. In doing so, you must comply with any technical limitations in the software that only allow you to use it in certain ways. For more information, see www.microsoft.com/licensing/userights. You may not work around any technical limitations in the software" (copied from the infoq article regarding this story)
  
  so the sentence about not working around technical limitations is clearly in a context (comply w/ technical limitations in the sw that only allow you to use it in certain ways).
  
  Now if this should apply to the TDD.NET case, that would have to be because a court decides that a) Jamie clearly worked around the fact that the add-in manager is missing from VS express, and b) that the absence of this add-in manager (together with the widely known information that VS express does not support add-ins) in the free adition is a situation where the sw does not allow you to do it.
  
  Whether this would be the case is up to a court to decide, but it's hard to imagine how a verdict in favor of MS would apply to bug fixing, competing with LINQ or anything else.
  
  If they lose in court, you'd be right to say they've made a mistake. But it's just as possible that their reading of the license situation will be confirmed and it turns out Jamie is the one who has made a mistake, and MS is paying for it in bad PR right now. I don't buy that Jamie is doing the Express thing for profit (one who can't afford the $250 for VS std would certainly take the free personal edition of TD.NET). But I believe that he has clearly picked this fight for whatever reason. He could, like everyone else, have accepted that VS express is not extensible long ago and that would have been it. He wants to fight it out, fine with me too. But if you think you can outsmart the EULA, you should be prepared for a lawsuit. At least, MS has not yet demanded compensation for legal assistence, lost profit or anything else. They just want to keep add-ins out of vs express.
  
  You should not forget that MS has managed to have competition on their platforms for decades. The real problems there are different. Think about killing competition with free products and product bundlings, for instance. If MS sues a 3rd party for competing with it's products, that would be something entirely new, entirely futile, and it would damage the platform badly (probably kill it, eventually). This would be so different from the TD.NET case, which is about competition between VS editions, not between MS and 3rd parties.
  

• Mats, I agree fully. MS has been showing a lot of good will lately, and its reputation is slowly getting better. (Don't get me started about the Linux patent stuff though...) Stuff like this is definately turning people away from the platform. People are not going to follow them up and down with their moods too often. This will either get better soon, or it won't matter anymore. How loud can you say "Mono"? Mono can help us to safeguard our investments in .net, but it cannot compete with Java, LAMP, RoR or anything else on its own today.
  
  Now if MS is doing stupid things, we should not let them have their way without complaining. But we should also not exaggerate every little mishap as if we were trying to be the better slashdot crowd. We are hurting ourselves too.
  And I think it does make a difference whether accusations like this one come only from the usual suspects, or they are supported by respected members of the .net community too.