Thou Shall Not Work Around Technical Limitations! (whatever they are)


Dan Fernandez responded to my recent blogpost with a follow-up on the Jamie vs. Microsoft soap.

He used an analogy to try to make his point:

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, the developer did extra work to get what he wanted, but not by violating any law: he simply used what's available to him.

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.

26 Comments

  • Good thing that you wrote this clear blog post, because it often feels that Microsoft doesn't care about developers. Since you're an ISV and you bring that up in your post I hope Dan will respond.

    Do you consider switching to a different set of tools (like Java) because of this?

  • Congrats Frans. Great work and great post.

    Cheers,

    Eduardo.

  • Mike: No I won't switch now as our product is a .NET toolkit, so switch now isn't going to help us.

    I have no objections against technical aspects of .NET, C# or related tools, so if MS clearly states that ISVs have nothing to worry about, that they'll proof that they won't pull such a stunt again, there's nothing to worry about when working on .NET. That's what I hope to achieve, that they'll realize that what they're doing now has consequences for them as well as there will be ISVs which will consider a switch, if they haven't already.

  • Samuel: It doesn't matter what my intentions are with not enabling feature x in a demo: you didn't violate ANY law when writing a plugin which makes it possible to enable feature x.

    It's that simple. I put something on a website for all to download. You write a legal piece of code and it makes you use functionality you already HAVE on your system. That's the point. If I don't want that to happen, I should have removed the save functionality from the framework of the designer altogether: it shouldn't be there. It doesn't matter if it's MS or a startup: if you ship a toolkit and say "Do whatever you want" and add a vague clause which is unusable because it doesn't state you can't write extensions nor can you run/use extensions with vs.net express, then don't cry like a baby someone did what you didn't want. Even further: IF they would have stated: "you can't create commercial stuff with vs.net express", the clause wouldn't be legal, because they have no say over what you will do with the toolkit.

    Of course it's about business, but the eco-system of ISVs should be healthy: competition is good but if unfair business practises enter the arena, we're all doomed and it's over. If MS wants the market and we're just here because they allow us around 'for now', it's unhealthy.

    An unhealthy eco-system of tools will create an unhealthy community: they're now bringing fear and uncertainty to the table for developers: what can a developer do and what can't a developer do? Some say "what are you talking about? I can do anything, MS doesn't care", no, not now perhaps, but wait till you create something which really hurts them financially.

    If I give away my stuff for free and ask money for support and all my users purchase support from my competitor, is that fair towards me? That's also why I brought up their bundling of an o/r mapper with .net for free, adding a designer for free in vs.net. All commercial o/r mapper vendors will then get a competitor which uses business practises which are in theory unfair. Should I complain? I could, but it doesn't help so I won't. I only use that argument as a sign that IF there's one who shouldn't talk about ethics and fairness here it's MS.

    Also, think about it: there are many many people across the world violating a lot of MS eulas every day. They pick this developer as their target for a big campaign. Why? To set things straight that you should obey eulas? I don't believe that argument, this is about strong arming a competitor out of the market, just because they're big and the competitor isn't. PRECISELY the thing we software engineers and community members and employees of ISVs should be firmly AGAINST and should stand up against.

  • Well said sir! Well said.

  • > It's not like an unmodified TestDriven.NET could be used in the Express version...

    The property extender trick would work just fine in the upscale SKUs as well. You could conceivably publish an addin that uses this approach to integrate into all versions of VS, bypassing the addin registration altogether.

  • @M: "That's the dumbest thing I've ever heard. Since C# still doesn't support condidtional #ifdef that would be nearly impossible and a dogma of work."
    It doesn't? Hmm, ever looked into '#if' ?
    When we first released llblgen pro, we had a crippled demo: it couldn't create a new project, we shipped a pre-fab project with it. We simply compiled out the create project code entirely with #if ... #endif. Worked great and the define was only there in a given build definition, so easy to build as well in an automated setting. As VS.NET's main code is C++, it's even more odd they didn't use this.

    Let's take a step back for a second and forget about the technical crap. Let's focus on the moral side of the story, ok?

    Ok, MS releases VS.NET express with the intention: 'this is a light version, it can't do a lot of stuff the pro/enterprise version can, but you can get the feeling how things work'. Sounds good? Ok, now, so they say this somewhere on the product website, but not in the EULA. So, how is this legally enforced? It's not. If someone then does what MS didn't intented, MS could say: "You're a dirty [4-letter word here]! You go against the intentions of what we had with this software!".

    Though, who would care? Not a lot of people, nor will it give any advantage to MS. So they go a different route, and with THAT choice they made a big mistake, because that legal route needs backing of proof of violation of laws.

    Let's focus on the 'you shouldn't do that' aspect of the case. Say (I'm not sure, but for the argument), in Orcas express, MS will include a Linq to Sql designer. However we nor any other o/r mapper vendor can create a designer for THEIR work as an add-in for vs.net express, as that's forbidden.

    Unfair competition.

    Oracle and DB2 can't add their vs.net designers and other add-ins to vs.net express. Though it does contain a lot of functionality which is solely targeting sqlserver.

    Unfair competition.

    Of course, it's MS's product, so they of course will make it so that it promotes their own stuff and not the material of the competition. But please, don't forget that with this 'limitation', they also forbid competitors to add an add-in to vs.net express.

    It's business, plain and simple. They give away a product which must have cost a lot of money to make, and they give it away for free. A money power-house like MS is likely wanting something in return, somewhere. All fine by me. They close the product up for competitors so their work is promoting only their own goods. All fine, it's their IDE.

    However, don't come to me with a whining story that what Jamie did is suddenly unethical and he's a true a**hole, because MS is also playing an unfair game with vs.net express. Like I said: it's business, business isn't fair in a lot of ways, and that's a fact of life, but don't come to me that MS is suddenly so incredibly nobel here, because they're not.

    Besides that, using a public API for _whatever_ reason and not violating any copyright laws is simply software engineering and cannot and shouldnot be punished because anyone who will try to achieve punishment in that kind of cases will in one way or the other some day find him/herself in exactly the same situation. Simply because it's what software engineering is all about: problem -> look for solution -> implement solution -> done.

    Any law you violate in that process is of course a law violation and should be brought to court. However simple usage of public api's... that's not violating a law. MS might not like it one bit what Jamie did, and from the point of view that they truly are nobel and sweet and just wanted to be philantropical here, I can understand it's not an ethical thing to do, but MS isn't that, nor is this about ethics. It's about money, marking the market and getting rid of competitors, using low-level under the belt tactics.

    I congratulate you if you want to live in such an environment where the big guy squashes little competitors with unfair tactics, however I really wonder why you would want such an environment...

  • You're forgetting one thing. Macros and plug-ins and other extensions are not enabled in the free Express Edition SKUs. So your example doesn't work. The guys who managed to make a plug-in had to do a technical workaround, they knew they were doing a technical workaround, and they have persisted with it against the objections of Microsoft.

    There is also no source-control integration and no support for MFC and ATL (in the case of the VC++ 2005 Express Edition).

    Whether wise or not, these are clear limitations in the SKUs and Microsoft seems serious about them. I would love to see the boundary between the Express Editions and the commercial versions not be so brittle, but it's not my company and it is valuable that there are now free versions of the IDEs.

  • That's a good point Frans. If I want to deter people from stealing things from my house I don't leave my door unlocked and put a big note on it saying "My door is unlocked, please don't steal anything". I lock my door.

    "no support for MFC and ATL (in the case of the VC++ 2005 Express Edition). "

    WTF do you DO with it then? How do you get anything done?

    Out of all the limitations in the Express products, the "no add-ins" one is the dumbest. (although the single-project one is pretty dumb). They should be building a community around add-ins for the Express products instead of trying to keep people from building them. Am I allowed to create a starter kit that can be used with an Express product or is that forbidden by the EULA as well?

  • While I agree that the EULA was somewhat vague, Microsoft was not being unreasonable. They asked him to disable VS Express support in Dec of 2005. Since then Jamie has repeatedly agreed to do so, only to turn around an reenable it.

    Look at the emails that Jamie posted. It is clear Jamie is acting in bad faith, constantly asking for things like a free membership in VSIP, MVP status, the ability to ship VS at a heavily reduced rate, and the ability to ship components of VS Team System in non-VSTS versions of Visual Studio.

    Finally, what Jamie did was not go through a legitmate API. Rather, he injected his code into the VS process by building his own version of the Add-on manager, clearly replacing a disabled feature. It would be impossible for anyone to stop him from doing that.

  • It’s actually pretty simple. If Microsoft won’t or can’t stop Jamie, they open the door for everyone to write plug-ins for VS Express. This will result in dozens of plug-ins that combined will have the same functionality as the professional version of VS. When this happens companies will switch to the Express version(s) and Microsoft looses money. The harm they are doing now to the community costs less then not stopping Jamie. It’s just business ;-)

  • You will be assimilated.

    Microsoft is the new IBM.


  • Scott:

    So does that mean that if you leave your door unlocked, that it is ethical to steal from you? Awesome. Where do you live? Just a city and a cross street is all you have to give -- I'm sure I can find everything else I need.


  • Totally agree with your post. Well said.

  • While I agree with Frans, it is obvious that MS is seriously worried that VS.NET Express will erode on VS.NET Standard Ed's market. Hence this effort. And that's all that there is. "Ethos" and "IP" my behind.

  • In the end, if Microsoft chooses, they may win in a court of law. Ever hear of winning a battle and loosing a war?

    To me, as a developer, I now have to (and probably should have before), have to live in fear of the giant's foot. If he steps on me on purpose, or by accident, He weighs too much. Because of this, either I or the giant must take extraordinary steps (no pun intended) to protect me. If it's me, the only safe step seems to be, leaving the land of this giant. If it's the giant, it involves, doing many of the good things Microsoft has been doing; but it also includes not doing things with there Managers and lawyers like castng fear around with their 235 patent talks or their actions in the TDD case.

    Peace.

  • >Look at the emails that Jamie posted. It is clear Jamie is acting in bad faith, constantly asking for things like a free membership in VSIP, MVP status, the ability to ship VS at a heavily reduced rate, and the ability to ship components of VS Team System in non-VSTS versions of Visual Studio.

    Did you read other emails than I did?
    He didn't ask for free membership in VSIP: It was an offer (bribery) if he removed Express support. I wouldn't take this offer, because Testdriven.NET doesn't depend on VSIP (VS SDK) and you have to sign contracts to be a VSIP partner, probably limiting your business.
    He didn't ask for MVP status: It was taken from him, because he didn't give enough to the community according too MS (I think otherwise). Then MS offered (bribed) the MVP VSIP, if he removed Express support. Jamie only asked to get his old MVP status back.

    > It is obvious that all forms of Add-ins were removed from VS Express. Therefore, the intent of the EULA is clear.

    EULA is an acronym of End User License Agreement. Jamie is no end user, so therefore the EULA doesn't apply. If the EULA is legit (which I think is not), than the only case that MS has against Jamie is: ‘You are not allowed to create software that makes it possible for end users to use VS Express, when not obliging to the EULA.’ Is this illegal?
    Then is a EULA legit? What if a system administrator installed the software, but a user who is using the software didn’t see the EULA…

    > There is no way he could have overcome the limitations of VS Express without having access to it. It isn't like he used a publically available API to load his add-on.

    So he doesn’t ably to the EULA anymore (which I don't think so), so he stopped using VS Express. Does that mean that Testdriven.NET is illegal?

  • "So does that mean that if you leave your door unlocked, that it is ethical to steal from you? "

    No, it means that if I leave the door unlocked and someone steals from me that it's my own damn fault for leaving the door unlocked. If I want to make it harder for the thieves to steal from me, I lock the door.

    Microsoft didn't lock the door. They are within their rights to uphold their EULA and Jamie is in the wrong by continuing to provide the workaround after MS notified him.

    That doesn't mean that they shouldn't have made a better technical effort at preventing what he did.

  • I believe there is more at play here than just copyright law. If I'm not mistaken, a license agreement is a type of contract. The person offering the license has the legal right to dictate the terms of the contract. If the licensee agrees to the terms of the license, then these terms will be in addition to anything required by copyright law.

    Theoretically, the licensor could stipulate that the software can only be used on Mondays, and this would be legally binding. In this regard, licensing software is akin to renting a seat on an airplane. People in coach do not have a right to sit in first class just because the airline didn't erect a physical barrier between first class and coach. The passenger purchased certain rights. For more money, they could have purchased additional rights.

  • Bob: not in the EU (Jamie lives in the UK). The EU states that an EULA isn't a legal contract, as the user who has to accept the EULA can't negociate terms, and a judge will always rule in favor of the user in these cases.

    This means that normal copyright law applies first. If you add as ISV claims to the EULA which limit usage of the work by the user, it isn't so that the claim is thus valid. At least not in the EU. Your example of usage on Monday would be an invalid clause in the EU.

    The same applies to copy rules in EULAs for example or 'resell' claims: some EULAs forbid the user to resell the license to a 3rd party. However, this isn't a valid claim, as the licensee is in charge of what s/he does with the purchased license, not the licenser.

  • Well said.

    This whole issue should never have occurred. It's wasted a lot of our time.

    I've been puzzled why some good programmers have deliberately left the .NET world. I won't be as puzzled by those who now abandon ship.

    I really believed Microsoft when they talked about freedom to innovate. Here we have some guys who are firnly against the company line.

    I saw the VSIP debacle and then wondered what on earth was happening in the VSTS idea. Microsoft used to go out of it's way to encourage it's developers. (Remember the bouncing Ballmer film clip anyone? Developers, Developers, Developers!!) Somewhere along the line recruitment went wrong. They started hiring less than the best. Now we have the start of the end. I'll be sad if and when it all crumbles to dust, Microsoft has done a lot despite opposition. (... much of that against stupid politicians, goverment legal mercenaries and companies that failed commercially so went to court instead.)

    Look what Microsoft was doing with Java before the lawyers made that unattractive. Now they become the bad guys. Go figure. (I can't.)

  • >The EU states that an EULA isn't a legal contract, as the user who has to accept the EULA can't negociate terms

    >At least not in the EU. Your example of usage on Monday would be an invalid clause in the EU.

    I don't understand the basis for this. Why would that be different from a limitation on which person(s) could use the software? The user is not in a position to negotiate those terms either. Suppose the licensee decided to let all of his friends and relatives use the software? Does the EU believe that an EULA can restrict that practice? If so, what is the principle which allows the software publisher to restrict that practice?

    >as the licensee is in charge of what s/he does with the purchased license, not the licenser

    Let me put the question another way. Exactly what rights DOES the software publisher have in the EU with respect to limiting the use of the software?

  • Whoa. So in August 2004, the Visual C# 2005 Express Edition was in CTP or beta. Publishing a product against those releases is a clear no-no as I recall. (I don't have those, so I can't review the agreements.) My RTM install has files with dates of 2005-09-23.

    Scott: '"no support for MFC and ATL (in the case of the VC++ 2005 Express Edition). " WTF do you DO with it then? How do you get anything done? Out of all the limitations in the Express products, the "no add-ins" one is the dumbest. (although the single-project one is pretty dumb).'

    You use it to build stock C and C++ applications and you can use WinForms (although there are some serious pitfalls) or you use the Platform SDK to build Windows applications at the Windows API level. (There is no deployment support or resource editor either, so I think add-in support is not at the head of the most-missed list.)

    I don't know what is meant by the "single-project one." There are multi-project solutions, at least in VC++ Express Edition. The big difference is you can't have solutions with projects in different languages. No C# and C++/CLI in the same solution, for example.

    Hey, it has a really nice command-line compiler and utility set as long as your only target is Windows on x86. (The VS 2005 standard C/C++ libraries all rely on the Windows kernel and other DLLs.)

  • I went diggging in my archives to find out what the time history of the Express Editions was. I didn't touch them until the RTM versions, but I found out that somewhere around the February 2005 Express Editions CTP, add-in support was removed. So it was apparently in the early alphas, CTPs, and betas but gone before the August CTP and the September RC. The RTM was announced on November 7, 2005, but my copy of VC++ EE RTM VC/bin files have file dates of 2005-09-23.

    I think this may be one of those cases where "it is easier to gain forgiveness than get permission" was perhaps not a good idea.

  • Frans: 'Even further: IF they would have stated: "you can't create commercial stuff with vs.net express", the clause wouldn't be legal, because they have no say over what you will do with the toolkit.'

    Bad example, since that one actually has some teeth to it.

    In general, compilers and related tools copy some of their own code into the output: startup code, import library fixups, standard runtime libraries, etc, and even the code editor may automatically insert various templates etc. All of these things are covered by copyright, so the EULA is the only thing allowing you to distribute them at all.

    You could, of course, carefully use something like Visual Studio to only edit your own code, never use included templates, etc and just compile your code with some other tool. But given that at least half of a product like VS is the compilers behind it, I wouldn't really fault them for using language like "you may not use this product to create commercial software". It's imprecise and slightly misleading, but it gets the point across.

    Some products actually do clarify the distribution terms on the standard library etc -- IIRC Borland did this with the v5 commandline toolset -- but it took quite a bit longer to read through that license ;)

  • Bob Snyder - "Exactly what rights DOES the software publisher have in the EU with respect to limiting the use of the software?"

    Those mentioned by the copyright law of the country where the user lives. An EULA cannot *restrict* the rights of the customer, it can only give him more rights.

Comments have been disabled for this content.