My last post on THE soap

Ok, this will be my last post on the soap of TD.NET and MS (has anyone already called Hollywood? ). In the community there's some controversy starting to pop up here and there and I just want to make clear what my position is and will be. This to avoid getting pulled into any camp in this soap.

My sole motivation to step up and say something about the matter is based on the fact that I as a software engineer don't want to have my hands tied on my back just because a competitor doesn't like what I do and sends his lawyers. A software engineer should, within the boundaries of the law, be able to write the software that fits the problem to solve. If that solution isn't what a competitor would have liked to see, that's life, but that shouldn't matter. To me, what Microsoft is doing at the moment, is falling into that category: sending along the lawyers because they don't like what a competitor is doing. The core point is: should this be allowed as a normal practise or not. It doesn't matter if you like MS or find Jamie a great guy or not or hate his guts: it's about that core point. Imagine yourself behind the keyboard on monday, writing code. Do you want to be afraid that what you write at that moment could cause a lawyer attack? No, of course not. That's my core point and motivation.

Some people try to put words in my mouth as if I would propagate the authoring of software which violates license terms, or the authoring of cracks of copy protection. No, of course I don't propagate that, on the contrary. That's also why I put clearly in my posts: within the law. That's important: as long as a software engineer's code doesn't violate a law, there's nothing wrong with the code. Please realize that violating a license and its terms is violating a law. So staying within the boundaries of the law covers that too: if you agree to a license, you have to obey these terms. If you don't, you violate the license and therefore violate copyright laws.

Sure, it's fuzzy sometimes: a crack of a given copy protection mechanism isn't illegal on its own, it's just a program. However as soon as you run it, it is, as it then alters other people's code. So where to draw the line? It looks complicated but it's actually quite simple: as long as you don't violate a law when writing your code and your code doesn't violate a law as well, you're OK, whatever that code might be, why wouldn't you be OK, you and I write that kind of code every day. If your code uses public APIs, public documented code and simply utilizes what's there, even if you have to spend 2 weeks straight to write it, it's not illegal, as it doesn't violate any law. If it would: what is the difference with other code which also uses public APIs, public documented code and simply utilizes what's there? IMHO nothing.

This whole mess wouldn't have happened if MS would have closed the hole Jamie used in their public APIs. It also wouldn't have happened if the usage of their toolkit would clearly state that you can't extend VS.NET express, not manually, nor via external means: he then wouldn't have been able to test his work. Sure, some people claim that MS intended VS.NET express not to be extended and that we all knew that that was the case. I fully agree with that. I even did assume that VS.NET express wasn't extensible at all, because MS said it wasn't extensible through add-ins. Apparently they missed a big spot and left a big chunk of their API ready to be used in the tool so it was extensible and with legally normal code. The code might go against what some company thinks is OK, but that's of course irrelevant: every ISV thinks the competition does things which aren't what they'd like to see, these competitors create a competing product .

Is creating an add-in for VS.NET express then 'unethical', because it goes against the spirit and intentions of VS.NET express? I can only say 'yes' to that. However let me tell you, dear reader, a small remark: ethics have nothing to do with this. Because it is also unethical to bundle a free competitor to commercial offerings in a bigger, also free product. It is also unethical to add functionality to your free IDE for your own database and block the competition's add-ins, while your free IDE is the de-facto standard for software engineers of your platform.

This to bring things a bit in perspective. I'm all for a world where business is fair, where ethics are a very valuable thing and everyone tries to do the very best for one another. The reality is however that things aren't that way in today's hard-core business world where one company's death is another one's breakfast. To the defenders of both sides: please keep that in mind as well.

This whole story about TD.NET and MS will likely end up in tears for both or one side. I have to admit that if I look at the case from a professional software engineering's perspective, I simply can't agree with MS' way of how they handled it. I also can understand how Jamie went the 'I have nothing to lose' route as his lawyer stated he has done nothing wrong (what else can you do in that case?). As a human being, I also have to admit that what Jamie did wasn't matching with the intentions of what MS had with VS.NET express: a crippled version of the professional tools. Though I then also have to admit that in the real world of hard cash and business, no-one gives a rats a** about that and finding MS brining up the point of ethics makes it rather, sorry to say it, ironic and funny.

As a software engineer, I would have handled it from MS' position very differently: close the hole, make it impossible to achieve what Jamie did, also re-word the EULA so it's clear what the intentions are with VS.NET express. Now it's too vague and 'You shouldn't work around technical limitations' also tells me as a user not to do things I simply have to do, as a bug or a design flaw is also a technical limitation. So don't write an XmlSchema import class library to make wsdl.exe recognize your own types with IXmlSerializable implementations, you software typer, you! (No VS.NET express user is allowed to do so, according to the EULA. Sorry, couldn't resist )

Apparently, MS will re-word the EULA soon. That's great news, so hopefully the vagueness will be removed and we all will know, license-wise what we're dealing with. I also do hope that MS will alter VS.NET express in such a way that you can't run add-ins, period. Not XNA studio, not popfly, not TD.NET, nothing. No add-ins means no add-ins. This will leave no room for a software engineer to turn the wrong corner, to use the wrong method: there's no method to use, there's no service to call, so the engineer has to conclude: 'it's not possible, what I need for building blocks isn't provided'. This will free the software engineer from looking into EULAs for every method s/he wants to use and it would free the software engineer from calling to lawfirms for every public published API they might utilize in their code.

I hope both players in the soap will take a step back, get off their high horses (didn't knew they'd make them this tall nowadays ) and talk about software again instead of business. Because, Microsoft also has to realize: the more they pack into VS.NET express Orcas, the more they'll lose their own argument that they're using now, because the more tools they pack into a free, de-facto standard IDE to kill off competition (e.g. a linq-to-sql designer to kill off any other O/R mapper out there to be sure everyone uses MS' offering so SqlServer is the RDBMS of choice, oh, just thinking out loud here), the more unethical it will become. As I said in my previous post, I don't mind their competition as I'm sure a lot of developers will make the right decision, what I'm against is unfair competition and uncertainty with the code I use and write. I hope MS will realize that you can't use the argument of unfairness and unethical against company A and using that same technique you accuse company A of yourself.

EOD (for me at least )


  • 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

    (I edited your comment for 'M$' into 'MS' -- FB)

  • 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?


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

Comments have been disabled for this content.