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 )

Published Sunday, June 03, 2007 12:52 PM by FransBouma

Comments

# » My last post on THE soap

Sunday, June 03, 2007 7:56 AM by » My last post on THE soap

Pingback from  » My last post on THE soap

# re: My last post on THE soap

Sunday, June 03, 2007 12:13 PM by Stefan Wenig
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.

# re: My last post on THE soap

Sunday, June 03, 2007 3:56 PM by ChadM
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.

# re: My last post on THE soap

Sunday, June 03, 2007 4:26 PM by FransBouma

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. :)

# re: My last post on THE soap

Sunday, June 03, 2007 5:39 PM by David Markle

Frans:

Thank you for your blog entries.  I'd just like to  lay out there that although we've got differing and strong opinions, I think it's pretty cool that just about everyone I've read who's been involved in the debate has been professional and respectful in elucidating their ideas.  That's the sign of a truly healthy community, and I guess what makes nerd-blogs ;-) different from political blogs.

Anyway, I too am happy that MS is amending their license.  They should.  And I think it's also right that they completely disable add-ins for Express, though they totally have the right to do whatever they want with their own product.  

There's a point you raise that really bothers, though.  You seem to be saying that it's OK to act unethically (when you say that "ethics have nothing to do with this) if the person you're injuring also acts unethically.  That's really hard to swallow, and I think it's really sad that so many people today believe that.  IMO that mentality is what's crappifying* our society in general.

You also seem to be saying that it was OK for Jamie to go in and re-enable add-ins simply because there wasn't a good enough mechanism to prevent him from doing so.  That argument, too, is disappointing.  If a man locks his door at night with a cheap lock which can be picked with a paperclip, and fails to use the deadbolt, does that mean it is OK to enter his house?  You seem to be saying at least, if this is a rich man who could afford a better lock, it is OK to enter, and do whatever you personally think is fair.  

One last point.  I don't consider Jamie and MS to be competitors -- not in the least.  They're partners.  Jamie makes his money off of writing an add-in that would not exist were it not for the existence of Visual Studio, and MS makes money by having a popular add-in that builds their developer base and causes people to use VS.NET instead of turning to an alternative.  Jamie further benefited with his status as an MVP, which is a serious resume-builder and could have helped him immensely when the time comes to score more work from any client, or when getting a job.  

I see what Jamie has done as being what amounts to be a betrayal of his partner.  Jamie's partner (MS) asked him many times to remove the Express functionality (which he created, we all know, by reverse engineering VS.NET with Reflector, ILDASM, or something else).  

If Jamie's product was a GPL add-in, and he made no money off of it, I would see it (the partnership thing) differently, but that's not the way it is.  He wants to have it both ways,  and I don't think the community should support him either on the forums, blogosphere, or by purchasing his product.

* Yes, it's a word.  Go look in the dictionary.  I'm sure it's in there... um... somewhere toward the back.

# re: My last post on THE soap

Sunday, June 03, 2007 5:55 PM by FransBouma

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.

# re: My last post on THE soap

Sunday, June 03, 2007 6:57 PM by David Markle

So, are you basically saying that if MS adds an *undocumented* function to VS.NET Express called, say, EnableVSNetExtensions();, and someone were to call it, you would take MS's position on this whole thing?  What if it were easily visible in Reflector?

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

So what if the APIs themselves are documented.  Did you read Dan Fernandez's blog where he described how Jamie circumvented the Express functionality to enable (just) his extension?  That hardly sounds like the poor innocent developer stumbling upon some public API that a lawyer said he can't use:

blogs.msdn.com/.../testdriven-net-and-express-technical-information.aspx

# re: My last post on THE soap

Monday, June 04, 2007 1:45 AM by Stefan Wenig

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.

# re: My last post on THE soap

Monday, June 04, 2007 2:46 AM by FransBouma

David: "So, are you basically saying that if MS adds an *undocumented* function to VS.NET Express called, say, EnableVSNetExtensions();, and someone were to call it, you would take MS's position on this whole thing?  What if it were easily visible in Reflector?"

No, I'd stay with the position I have, I already said that in another post. The reason I do that is also there, and no, it has nothing to do with encouraging illegal behavior.

Which part of "within the law" don't you understand, David?

"That hardly sounds like the poor innocent developer stumbling upon some public API that a lawyer said he can't use:"

Yes I read that, but it doesn't matter. No lawyer should be able to tell you NOT to use a method which is public and documented IF (and there's that sentence again, David, pay good attention not to ignore it again this time) you yourself stay within the law.

Company A sending the lawyers to company B because A doesn't like what B is doing and justifies that with flawed reasoning is WRONG.

Stefan: If you keep ignoring what I've explained a couple of times, I don't have to repeat myself. That's why I ignored your post, I also ignored it because I don't have the time to reply to everyone here.

Sure my reasoning is from your POV flawed becuase it doesn't match your point. That's fine by me, you're entitled to your opinion, but so am I.

# re: My last post on THE soap

Monday, June 04, 2007 6:15 AM by Stefan Wenig

Frans, I think your reasoning is flawed because there are some conclusions in it that don't work for me on a logical level. I have absolutely no interest in defending MSFT's attitude concerning the possibility of an eco-system around VS express, but that's no legal matter. I don't like how they treated NUnit one bit, but that's a different case. I don't think that they are defending their test suite (VSTS only) against TD.NET, because they have no problem with TD.NET for VS std/pro. They are probably just defending VS std against VS express. Stupid? Maybe. But that's not really the matter here, right?

Sorry if you've answered this elsewhere, but I was not able to find it (just read it again). How do EULAs not apply if you obviously have to use the product? I think using a product and not abiding by the EULA is against the law AFAIK, so there is no need for an explicit law banning what the EULA already forbids.

The only question is this: Did Jamie really violate the EULA? You think no, because APIs were public. Other people (like me) think that there's more to this than public interfaces. There is a whole range of pros and contras, and a court would have to look at all of them to decide whether a violation took place. Would this decision automatically apply to to other cases without the same properties? No.

I'm working for a MS-centric ISV too, so if you're right, I definately would like to understand it. However, so far I still think your argumentation is flawed and see no reason to be overly frighened as far as our own business is concerned. So if my reasoning is wrong, please take the time and point out my mistakes. Thank you!

# re: My last post on THE soap

Monday, June 04, 2007 8:06 AM by Stefan Wenig
PS: just in case you're wondering what i'm talking about, my comment about whether EULAs are applicable was on http://weblogs.asp.net/fbouma/archive/2007/06/01/look-microsoft-is-working-hard-on-building-a-community.aspx

# re: My last post on THE soap

Monday, June 04, 2007 9:07 AM by Mats Helander
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.

# re: My last post on THE soap

Monday, June 04, 2007 12:06 PM by Marcos

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)
 

# re: My last post on THE soap

Monday, June 04, 2007 12:31 PM by FransBouma

Stefan:

"I don't think that they are defending their test suite (VSTS only) against TD.NET, because they have no problem with TD.NET for VS std/pro. They are probably just defending VS std against VS express. Stupid? Maybe. But that's not really the matter here, right?"

I think they can't have a problem with TD.NET for vs.net pro because it's a valid add-in. They thought to push it out of express with this crusade as well, and I think it IS part of the matter here. You can't justify the amount of work they put into this for just an EULA violation. It's much broarder than that.

"Sorry if you've answered this elsewhere, but I was not able to find it (just read it again). How do EULAs not apply if you obviously have to use the product? I think using a product and not abiding by the EULA is against the law AFAIK, so there is no need for an explicit law banning what the EULA already forbids."

First of all, EULA's aren't legal contracts. Perhaps in the US they are, but not in the EU. This is because the user has no right in negociating the EULA contents. Furthermore, there are a couple of ways in which you aren't actively accepting the eula but do get the installed works on your system. This is for example the case when a sysadmin installs the .msi for you. I also gave an example where it could _theoretically_ (I also added that) be the case he didn't see the eula because he didn't use express. In theory you can write TD.NET in vs.net pro, test it in pro (even though the code TD.NET uses to get itself added to vs.net isn't really necessary) and never ever see express. How do you then violate the EULA of express?

"The only question is this: Did Jamie really violate the EULA? You think no, because APIs were public. Other people (like me) think that there's more to this than public interfaces. There is a whole range of pros and contras, and a court would have to look at all of them to decide whether a violation took place. Would this decision automatically apply to to other cases without the same properties? No."

An EULA with the sentence "You shouldn't work around technical limitations" is useless. I gave a couple of examples of technical limitations you have to work around to get some things done in .NET 2.0. YOU might not think these things are technical limits, but they truly are. The fact that in the EULA 'technical limitations' isn't specified at all, makes it so vague that it can't possibly applied, as the context in which it should be applied and onto what is unclear.

MS could state in their EULA that you shouldn't work around technical limitations, and MEAN things like the lack of an add-in manager, but it doesn't say that. So why should someone obey to this vague claim? If something isn't provided by the IDE of express, you SHOULD consider that as a technical limit as well. Should you then also not work around that? I refered to wsdl.exe schema imports for correctly get IXmlSerializable implementing types and not the stubs with just DataSet as type. This is a technical limitation, you HAVE TO do work to get this working. It's just an example of a technical limitation of the COMPLETE package installed by the VS.NET express installer. Because make no mistake: the EULA is shown ONCE, so it applies also to the .NET framework which is installed with the installer.

"I'm working for a MS-centric ISV too, so if you're right, I definately would like to understand it. However, so far I still think your argumentation is flawed and see no reason to be overly frighened as far as our own business is concerned. So if my reasoning is wrong, please take the time and point out my mistakes. Thank you!"

What you think you should do is of course your decision to make. If you find it OK if for business reasons a competitor sends over a group of lawyers to tell you you shouldn't do ABC, then you have nothing to fear. For companies who compete with MS or with parts of products released by MS, like my own company, this can't be nor should be found 'OK'.

# re: My last post on THE soap

Monday, June 04, 2007 8:56 PM by Stefan Wenig

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

# re: My last post on THE soap

Tuesday, June 05, 2007 4:39 AM by FransBouma

Stefan: There's a difference in perception what is reasonable and what isn't reasonable in an EULA, and this differs between persons but also between countries.

To use a piece of software you indeed need a license, in any shape or form (so "here, use this" from the author him/herself is enough). However, is the author also rightfully capable of telling the user WHAT to do with the software and more importantly: NOT to do with the software?

I'd like to add that this isnt' about distributing the software: you have to have a license to distribute software otherwise you can't distribute it, as distributing a copyrighted work is forbidden by law unless you have a written approval that you are allowed to do so.

What a software vendor can tell the user to do and not to do with the software is a vague area. I admit that it's also unclear to me at times what is reasonable and thus what I would expect to be upheld in court and what is nonsense. It might surprise you, but what is reasonable will also differ from court to court.

So if the software vendor says in the EULA: you can't run this software on Dell computers, is that reasonable? Probably not. If the software vendor states in the EULA: you shouldn't use it for commercial programs, is that reasonable? likely, but it doesn't necessarily have to be. To understand that, please take a step back and replace software with a book or magazine, a TVset or VCR. Do these things come with an EULA which states what you can't do with them? No. Would you find it logical if the VCR manufacturer equips their VCRs with an EULA which states "you can't use this VCR for commercial activities"? Likely not, it's your VCR, you bought it.

As I said: it's a vague area. Similar to this particular VS.NET express case: in the eula is stated: "you shouldn't work around technical limitations". If you read that as "you shouldn't crack any limit we added because we don't want you to extend the software", and you see someone after some work manage to extend the software, then of course what that person did was in violation of that license.

However, looking at that single line in the eula, it doesn't say more than just not work around technical limitations. They aren't specified, it's unclear. Furthermore, as it's unclear, is it reasonable to CONCLUDE that what's stated there is SOLELY meant to limit extensions? Or just a couple of extensions? One could argue that it's clear, but I find it unclear, there are technical limitations to .NET you have to work around to get things done, are these forbidden as well? It doesn't say it's not!

As it's not stated if that sentence is solely about extensibility (if it is, it's stupidly worded IMHO, because a sentence like "you aren't allowed to extend software in any shape or form" is more clear), one can't conclude it's about extensibility.

I added to that that what Jamie did was using plain public api's and not doing anything illegal, that is: he's not violating a law like breaking copyright protection, patching dlls to make his software work etc. He just wrote a program.

I understand that what he wrote is targeted to make the add-in he wants to run from inside vs.net work. Though, why isn't he allowed to do so? The EULA doesn't say he's not (the clause is very vague). Also, even if you argue that the clause which is there IS there solely for prohibiting extensibility, then what he did COULD be argued as within his rights because what was claimed by software vendor is unreasonable, like the examples I gave earlier.

My point I wanted to make was and still is is that, if a company A sends lawyers to company B, based on a business case, to tell B to stop their activity, and the activity of B is within the law (i.e. no copyright protection infrigment etc.), A's actions shouldn't be allowed, as it hurts our profession: a software engineer should be focussing on writing solid software, not be focussing on what a competitor might think. 'Pair programming' shouldn't be about 1 engineer and 1 lawyer, but 2 engineers ;)

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

Yes. Trust me, if they know they would win in court, they would already have filed a lawsuit. They have a hurdle to take which is pretty big: Jamie isn't a US citizen. He's a UK citizen, so EU laws apply.

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

I'm not sure what particular thing you're refering at with 'LLBLGen one'.

I'm all for clarity and simple EULAs. In fact, I personally (that's my personal opinion as a software engineer) find that EULAs should contain just a few lines: you are granted to  use the software, and then some mumbo jumbo about liability (which are also bogus if I might add. Every EULA has them, though just by adding them doesn't mean you're not liable). Eulas nowadays contain a lot of goo no-one reads, and it's unclear what the rights of the user are: if there's a line in the EULA which limits the rights of the user, is that then in effect every time the user uses the program, or is that line bogus?

I think that if MS wins THIS particular case, we as .NET developers are entering a rough world: not only are we then suddenly liable based on VERY vague EULA clauses, we are also liable even if we use public, published APIs, and do something with them what the owner of the APIs didn't intend or doesn't want what we're doing with the APIs.

Stupid example: say the linq-to-sql designer will be usable with a templated code generator (it's now not usable with a code generator other than it's own), directly, not via commandline crap. Say someone steps up and creates some templates, creates a 100 line template consumer and generates POCO classes and an nhibernate mapping file from the linq-to-sql designer stuff. Say MS then steps up and says: "hey, that's not what we wanted with the designer, it's not meant to be used by 3rd parties. Stop that!".

Is that a reasonable claim from MS? I'm sure some will say "Yes, that's reasonable". Others might say, "if the api's used to make this happen are public and no code patching is occuring, it's unreasonable".

I'm aware that this is grey territory and the vagueness supports the hidden agenda's of every party involved.

About extensibility of VS.NET express: no, you're wrong, it IS extensible, see XNA studio, popfly etc. TD.NET added (via a complex route using public code) the ability to start TD.NET's engine from within VS.NET express so you could run tests from within express. If it was impossible with public APIs, Jamie wouldnt have achieved what he made possible.

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

If it makes a valid business case is indeed a question you should ask yourself as an ISV, and I agree with you that this particular case isn't one which I'd pick up. However that's not to say it shouldn't be done because MS says so. Just because MS says to stop your commercial activity because they don't like it doesn't mean you should. Competitors of MS have told MS a lot of times to stop the activities MS put forward but MS didn't listen as well.

IF MS wanted express not to be extensible, it should have code not to make it extensible. If they want it extensible just for the cases they see fit, make it so, but add code to make that so.

# re: My last post on THE soap

Tuesday, June 05, 2007 4:42 AM by Josh
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...

# re: My last post on THE soap

Tuesday, June 05, 2007 6:14 AM by Stefan Wenig

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.

# re: My last post on THE soap

Tuesday, June 05, 2007 6:15 AM by Stefan Wenig

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.

# re: My last post on THE soap

Tuesday, June 05, 2007 3:27 PM by Josh
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.

# re: My last post on THE soap

Wednesday, June 06, 2007 2:27 AM by Stefan Wenig
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.

# re: My last post on THE soap

Wednesday, June 06, 2007 6:04 AM by Mats Helander
Stefan, "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)" The problem, imo, is that it kinda appears this is what they are doing. No no no, I'm not going to argue that is what they are in fact doing! The problem is that you have to look a bit carefully to see that and that when you do look carefully, the case doesn't suddenly become clearcut in the favor of MS, it only becomes more nuanced...I do agrre with you that looking carefully indeed reveals that they are not doing this: "If MS sues a 3rd party for competing with it's products..." But I guess everyone won't look that carefully. And so what worries me with all this is not that "I'll be next" or anything, it is that MS - which my career depends on more than is entirely comfortable at times - is making bad PR desicions that are turning people away from the platform even if those desicions may be legitimate under close inspection. You shouldn't have to wear your thickest glasses to be able to see that, hmmm, yes the waters might just be safe enough to enter. So MS may be entirely in the right and Jamie might have done something awful (personally I have no idea, I haven't had time to wade deep enough in all this) but all that is irrelevant. What is relevant is the perception of MS that MS is currently forming. Then again, it probably isn't bad enough to kill them. But it could still hurt .NET adoption, don't you think?

# re: My last post on THE soap

Wednesday, June 06, 2007 11:01 AM by Stefan Wenig
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.

# re: My last post on THE soap

Thursday, June 07, 2007 12:18 PM by Mats Helander

Stefan,

Word!