+972 52-548-6969
Arrest that man! He had built workaround a technical limitaion!
time to read 1 min | 117 words
Alex* has posted a piece of code that will solve my issue with Window Live Writer and spell checking.
The problem is that this is clearly working around a technical limitation in the software, as a non English speaker, I am obviously required to use Windows Live Writer Team Edition, which will (in the next version only, mind you) support English spell checking for non-English speakers. I am expecting the Cease & Desist to come at any moment, and Alex is currently expecting an attack from the Tean Ninja Lawyers teams.
Nice hack Alex, now off to prison with you.
* Sorry to pick on you, but that was too good an example not to use.
Comments
Oren,
Maybe there is more to the truth on the TDD.NET vs MS story than has been told...have a look an judge for yourself: http://www.infoq.com/news/2007/06/TestDriven-Express-Emails
bakkegaard,
I have read the mails, but I disagree with the conclusions that InfoQ is making.
Take a look at Frans' blog for a good summary of what is wrong with MS approach. I have the same mind set as Frans here.
BTW, I love the URL
I know you aren't being entirely serious, but this isn't really an example of what they mean by working around limitations. I don't agree with them at all, or think it's right, but what they mean is that you can't work around limitations expressly placed in the product, such as the TDD example, where the limitation was that you can't write plugins for the Express products.
Come on Oren, this is a ridiculous example. Alex has in no way hacked LiveWriter or gotten into the code, something that the TDD folk apparently have done: http://blogs.msdn.com/danielfe/archive/2007/06/01/testdriven-net-and-express-technical-information.aspx
In your honor I downloaded LiveWriter to check the license. It has no such language. The Express Editions limitation was an intentional move to limit people using EE as a substitute for the commercial editions (there is not even deployment support). I suspect that, if it weren't for that, the Express Editions would have never got out the door.
Is it? I don't see anything different between the two, both use public API in order to make the software do something that it wasn't supposed to do.
Yes, I know that WLW doesn't have this restriction, but at one point, Vista had it. Since I am not going to starting reading EULAs any time soon, and try to find out what I am allowed to do or not, this move from MS is worrying me.
The last thing that I want to have to do is to start doing daily standup meeting with a lawyer.
The APIs that TDD.NET uses inside Visual Studio Express are intentionally not public. Also, the VSIP program stipulates the products that such information can be used with.
I think the lawyers are going to be working it out now. (I expect them to settle, by the way.)
The command-line initiation of LiveWriter is not technically restricted, nor is its launch from another program. I still say it is silly to trivialize the dispute in this way..
TDD doesn't use VSIP, and the API are public & documented.
Sorry orcmid, as Ayende says, the APIs are public and documented - just not widely known. Jamie wasn't in the VSIP program, so he isn't under any restrictions it may impose.
Jamie hacked nothing - he did use what was available.
I am a developer - my entire life is spent working around feature and technical restrictions in WIndows software (that is all developers do, we provide functionality that isn;t in Windows or other products).
I think Roy Osherove should make a protest song about this subject.
I think Roy Osherove should make a protest song about this subject.
Ayende, I think you should know better than that. MS did not go for Jamie for extending VS Express in any way like the ways you're comparing this to. AFAIK, MS has no track record for going after developers for extending products beyond their current abilities. Even if similar abilities are available in higher-priced product version. For instance, MS has no problem with Jamie providing TDD support for VS pro, although TDD is one of the features that differentiates VSTS. However, they made it clear from the beginning that VS Express can only be free because it doesn't support Add-Ins. They deliberately removed this support from VS Express, and Jamie did actually go out of his way to support it still:
http://blogs.msdn.com/danielfe/archive/2007/05/31/visual-studio-express-and-testdriven-net.aspx
Users are even advised to keep the property window open so this workaround gets a hook. Do you think Jamie was not aware that he was not supposed to do this when he wrote that code?
And "off to prison" is not quite what MS called for. Originally, Jamie agreed to take the support for Express out of his product if MS provided a good enough reason to pass to his users. He has this reason already and is still pushing it. Why?
You can hold up any position on this, and if you talk long enough about it, any argument can be made seem plausible. But the proper place for fact-twisting like that is slashdot. We should just ignore Jamies personal crusade against MS's decision to keep VS Express Add-in-free and get on with our lives.
If you want to raise the question whether the do-not-work-around-limitiations-clause in the EULA is too broad, that's another thing. But please let's separate this from Jamies case, as this is getting really annoying and obviously just makes the entire community argue. Nobody needs this, really.
OK, two people have claimed there is public interface information from Microsoft without providing a source. Can someone provide a link to the material so I can satisfy myself about it?
Orcmid,
Here is sample code:
http://www.mutantdesign.co.uk/downloads/ProjectReferences.zip
I went over it, and I see nothing that isn't publicly exposed and documented.
i can't see why having public interfaces seems to be the only deciding factor in some people's opinions. these interfaces are probably there for technical reasons (it would be hard to remove them), but measures have been taken to prevent 3rd party extensions from using them. namely, the addin-manager has been removed, and jamie had to use a clever trick to get his assemblies loaded at all, presumably being aware that he was not expected to do this.
what law says that workarounds are only workarounds if they use non-public APIs? given the broad wording of the EULA, only a court can make this decision. now we have two companies disagreeing about the interpretation of this clause, none of them backs off, so they're going to have a court decide. i really cannot see the problem here.
Because NOT doing it this way basically means that you exposes yourself to danger each and every time that you dare to use anything at all.
So what if SqlConnection is a public and documented class, you need to consult a lawyer before you can use it. Microsoft may decide that it doesn't like you using a "workaround" to talk to SQL Server when they have the Entity Framework available.
Yes, that is a crazy scenario, but that is simply following with this thought to its logical end. Public, documented, methods are safe to use. By that I mean that it is not "hacking" to use them. Obviously you can use public methods to violate laws, but that doesn't seem to be the case here.
Oren,
I looked over the code that you linked to. It is from January 3, 2006. Three days later Jamie reported to Microsoft that he had removed the special treatment required for the Express Edition.
I noticed that the assemblies used, including extDTE, are installed in the Public Assemblies folder of %ProgramFiles%\Common Files\Microsoft Shared\MSENV\
I am not so facile with C# and the libraries involved to be able to tell whether there is special provision for the Express SKUs or not. It doesn't look like it. Can you tell?
As far as I know, there is nothing different there.
extDTE is installed for Express as well, btw
Ayende,
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."
does that mean that you cannot work around limitations that were obviously introduced to prevent you from doing something? MS thinks it does, and while I'm no lawyer and even lawyers can only guess how a court woud decide, I think they have chance here. It's a risk for both sides though.
does that mean you cannot build on APIs for products that are obviously meant to be extended? no. its not what the license clause says, its not what common sense says, its obviously not what MS currently thinks this clause means (which should mean something in court too, although I'm unfamiliar with the UK legal system). It fails every test. Should MS still try (for bullying, or for desperate hope that the court makes an obviously wrong decision, which they sometimes do), they will face a public backlash that wil basically kill their platform.
.NET framework, SQL server, VS standard and above - all of these products (or almost any other products MS has ever delivered) are made to be extended by third parties. VS express is one of the few products where MS actually says that they don't want this to happen. that's why I don't understand either argument:
why would a (incidentally) public API mean that you can use it, no matter how clear it is they don't want you to and how creative your workarounds are?
why would the opposite automatically apply to products without any such restrictions?
you compare the current case to cases that differ exactly by what counts in this case, and then go on to make conclusions about similarities. this simply doesn't work.
we should not want this either. if you don't subscribe to the notion that EULAs are inherently evil no matter what, that is. otherwise, I think you'd agree that it should be the licensors right to specify in which ways its product can be used. do we want obfuscation and bug-ridden refactorings just to raise the technical barrier for workarounds? after all, public interfaces thankfully are the standard in .net, but that does not mean they are designed to be APIs at any rate. in the case of VS express, they were obviously not meant to be used.
@Stefan,
The EULA doesn't state the you are not supposed to extend Express.
If it did, I would agree about your case.
The difference the way I see it is that the EULA doesn't say that you are not allowed to extend, it has an extensibility mechanism, and I don't see what the use of public API as workaround of a technical limitation.
In other words, the license forbid workarounds around technical limitations, whatever that means. It does not forbid extending the product. To me working with public and documented API is not working around anything, it is using the platform the way it was supposed to.
Does this match what MS wanted to happen to Express? Obviously not, but the license allows this, so they should either change the license or change the API.
sure they should change that license. the question however remains: does this case indicate that we all have to fear that MS might one day successfully sues us for normal programming, working aroudn bugs etc? I am quite sure it does not, that's why I disagree so strongly with your notion of "arrest that man". And I think it makes quite a difference.
the EULA does not explicitly forbid extending the thing in its text. it just has a general clause, and MS will have to prove that this clause covers what jamie is doing. to prove this, several factors will play a role, and the fact that this assemblies had public interfaces is just one of them. will MS win? who knows. who cares? jamie is in no position to ask for moral support.
i would only care if that were a precedent for the kind of stuff you're mentioning, but in other cases MS would again have to prove that the EULA clause applies, and the deciding factors would be different.
That's why I don't worry. There is a general risk associated with using any software with any license except maybe a BSD-style license, but this case does not seem to add any significant risk to the story.
My problem is that it sets a precedent for them to follow. I suggest taking a look at Frans' posts about this subject, they are quite enlightening about the implications that this has.
I guess my point is that I don't see how this sets a precedent.
Is Jamie an innocent victim here, so that this would set a precedent for MS to go after people who are just doing their job, but in a way which they don't appreciate? I think not, Jamie just tried to do something with MS' prodcut he knows MS wanted to prevent, and thought he was just smarter than their engineers and laywers. No this opinion might be challenged in court. That does not make him a villain, but not an innocent victim either. So is this a (moral) precedent for going after innocent people? I think not.
Are the conditions of this case such that a successful lawsuit would set a legal precedence for suing anybody who tries to extend a MS product or work around one of its bugs? Again, I think not. The EULA clause MS invoked is very broad, and they will have to put every single piece of evidence they have into it, including the fact that Jamie was obviously aware that he was working around the intentionally missing add-in manager. Would any verdict be applicable to a case like those you mentioned? Again, I think not.
I agree that this puts a bit of a question mark above MSFTs relations to both individual developers and ISVs. But who has ever had a doubt that MS would eventually take legal action if they think somebody broke their EULA in a way that really hurts their separation of SKUs (and refused to stop doing it, too)? And we've always been aware that the sheer number of EULAs with their many clauses and the differences in legal systems where they'd be applied is a risk. However, nobody believes that MS as a platform provider can go after a competitor who builds upon their platform using unfair claims. This would kill the platform, period.
The question is: Is that just a minor residual risk, or is it a major threat? Currently, I'm just not buying the major threat theory. I'm quite serious about that stuff, because if I'm wrong, my company could one day be a victim too.
BTW, I tried to talk to Frans, but he believes I'm just reiterating opinions he already proved wrong. He's a bit terse too, but maybe he's going to answer my next comment...
Comment preview