To paraphrase an analogy from that post, this would be comparable to a 3rd party company working around the technical limitations in the LLBGEN demo to unlock features in LLBGen Pro for free.
I'm glad you brought up this analogy, Dan, because it shows perfectly well how flawed the reasoning of MS is. First of all, what follows is nothing personal, I know you are a friendly guy and you just do what you have to do in the position you're in at Microsoft. What I'll write below is how I see it and which will hopefully give perspective to the effects on us, software engineers in the .NET world, so you'll realize what Microsoft is doing at the moment isn't as simple as you try to make it look like to be.
Let's say our demo is crippled (it isn't, it's just time limited, but for the sake of the argument, let's say it is) and lacks a certain feature, say 'save your project'. It appears to be compiled in the code but we simply didn't add a menu option to do so. So in effect, we created a 'technical limitation'.
If we then would have put in our EULA "you can't work around technical limitations" (exactly how MS has worded it), and a user would have created a plug-in for our designer (we have a plug-in system), and that plug-in would open a dialog with a single button, 'Save project', and by clicking it it would call the publicly available save routine, it is valid and legit.
You want to know why? Because: the developer wrote a legitimate plug-in and there's nowhere stated that a plug-in is a workaround for a technical limitation (which are also not stated!), and the plug-in is legitimately calling a public method in the API of the designer. This is possible because similar to VS.NET, our designer is build with multiple assemblies used in a single host process.
Semantically, you can then say: "Hey, that's not what we intended! We deliberately crippled our product and now someone works around that limitation we created!", but that's irrelevant: the road the developer took is legit: he didn't alter the assemblies of the designer, he didn't crack the designer's copy protection, he simply was smarter than us. Smarter in a couple of ways:
- We didn't explicitly specify that using a plug-in wasn't allowed (MS also didn't)
- We didn't explicitly specify the limitations that were forbidden to work around (MS also didn't)
- The way the 'disabled' functionality was enabled is legit: no laws were broken to do so, no copyright infrigment was taken place
So, what's MS problem here? Nowhere did they state in their EULA that you're not allowed to create add-ins for VS.NET. They also didn't state in their EULA that you're not allowed to extend the provided IDE in any way or form. If a smart developer then finds a way to get some functionality working with the VS.NET IDE, using public APIs and public code, without altering assemblies, without patching code at runtime with cracked dlls, is that smart developer then in violation of anything?
The only thing that matters is the law. Is Jamie in violation of copyright laws? No, he didn't crack/alter anything. What he did and does and hopefully will do in the future is providing an alternative to Microsoft's expensive test-enabled versions of VS.NET for much less or even free. He used what's available to him provided by the tools MS provided. Big deal. Even if he would have used private, undocumented APIs it wouldn't matter: the functionality is installed by MS' own installer on his computer and ready to be used by the user. You know, Dan, developers use APIs to get things done. If you provide an API to get things done, what should the developer do? Not use the API? Nice eco-system!
Oh, and for the people who still think he violated an EULA please provide me answers to this:
- Where is stated you can't extend VS.NET Express?
- Where is stated what the technical limitations are
- If he wrote the code in VS.NET Pro and compiles on the command line, is he still violating the EULA of vs.net express? If you answer YES: how is that possible, he never saw that eula, theoretically!
I first decided to stay out of this, but every day I get more and more angry about this. If MS wanted to stop add-ins in VS.NET express, make it impossible to run these and also state clearly in the EULA that running (!) add-ins isn't allowed. Still a bogus claim in court, but it would scare the cr*p out of a lot of potentially happy developers, something Microsoft is apparently trying to achieve. To me, it seems this is all about money: Microsoft provides an expensive tool chain for what Testdriven.NET also provides. If someone can use VS.NET express for free and use a cheap add-in to get the same functionality, use subversion for sourcecontrol etc., it will hurt their sales. Well, Dan, that's business. You as a Microsoft employee should know that word and its meaning through and through.
There's another reason why I'm more and more angry about this and really starting to get fed up by the stupidity of this: I own an ISV which produces software which next year will get a competitor from MS. I don't mind the competition, I think we have a strong product against their work, but what angers me are two things:
- They dump a free competitor to commercial offerings into the market, which is in theory an unfair business practise as they bundle (sounds familiar?) their product with another bigger product. Still MS has the nerve to talk about 'ethos'.
- A very vague, unclarified sentense in an EULA can start a legal threat against your company just because MS doesn't like your product in their market.
As an owner of an ISV, I simply can't ignore what's going on at the moment as it will affect my company as well, and also every other ISV out there: do we want to work in an environment where using a legitimate public API could cause a lawyer threat which will cost you a lot of money? No, I don't want to work in such an environment and I'm sure my fellow software engineers don't want to work in such an environment either.
Let's get back to your other remarks, Dan, because they're worth replying to as well: (emphasis are mine)
As you know, I have great personal respect and admiration for you, for MVPs, for RDs, and the entirety of the .NET developer ecosystem, and to be clear, this has nothing to do with community. As I mentioned in my post, what complicates this even further is that this isn’t a community developer doing this for his or her personal use or experimenting with our product, this is a *business* trying to sell a product that works around our technical limitations.
This has nothing to do with the community? Not directly, but it has everything to do with software engineering and what you can do with the tools provided as a software engineer and that fact alone affects everyone in this community.
Furthermore, it doesn't matter if this is a community member or IBM selling a big product in a market you're in too: it's about the way MS threats its own followers with lawyers and false accusations. Perhaps I'm not getting it, but I would be very happy as an ISV if a user created add-ons for a tool I would provide. You know why? Because it then would spawn a bigger eco-system of tools, more creativity, more users and in the end, more money in the bank. This guy wrote an add-in so express users can use unit-testing. That fact alone should be a signal that what you started: a free express edition of VS.NET, is working: it creates a bigger eco-system, it attracts more users etc. But what do you do instead? You burn a lot of goodwill and money to get rid of that add-in. That shows that you don't care about a bigger eco-system, more users etc.. You want to young developer to work with MS stuff? Make it so. However if that young developer has to be afraid to not violate an EULA or s/he will end up at the receiving end of letters from lawyers, what do you think that young developer will do, if that young developer also has the choice to pick Netbeans or Eclipse to start with Java and the thousands and thousands of add-ons and tools and libraries which are available to him?
Not about the community? Not about Business? You're funny, Dan.
So, Dan, I hope you're very happy with what you and your co-workers have achieved. There's a term for this: a Pyrrhic-victory. That is, IF you win at all in this. You shouldn't be that afraid that someone uses the work you provided. We're developers, we use the API's and other things to get things done. Perhaps not in the way you intended or want to. However that's totally irrelevant. If you don't want a developer to use a given API method, don't expose that method.