You know what fine print they don't need, probably can't enforce, and their support staff (or connect.microsoft.com) implies that you violate when they ask for workarounds when reporting an issue with their software?
In the section "SCOPE OF LICENSE" it actually says you can't work around limitations. Not sure when this was added, but it's in Office 2007, Visual Studio 2008, Silverlight, and who knows what else:
You may not: work around any technical limitations in the software
I have no idea why any license would specify that the user is not allowed to work around technical limitations. For one thing, there's not really any way to tell if a user is working around a limitation. And if users are working around a limitation, the software maker probably wants them to do that, rather than have end users just sit and complain that they can't do something because of some limitation. On top of that, these are applications that provide gigantic macro/scripting infrastructure and SDK's for automation so that you can build workarounds for any limitation in the software.
At that point, at least one of the following must be applicable: 1) there isn't anything left that could even vaguely classify as a limitation (and you paid a lawyer to write this in the EULA for nothing) 2) you paid a bunch of programmers to add extensibility features into your software that your end users aren't allowed to use 3) you also forgot to tell the product support team that anyone who calls in with a workaround has violated the terms of their agreement and needs to return the software
I guess at this point, the licensor should decide if the goal as a company is to sell and support software or to create overly restrictive and unenforcable license agreements, and quit wasting money on either the lawyers or the developers and support staff. As a licensee, I would probably just ignore all the B.S. so I can get my work done, and I wouldn't hold my breath waiting for Microsoft to go all Metallica/RIAA and crack down on users violating their insane, counter-productive EULA. That is, unless my work is writing a book on workarounds to the lack of UTF-64 support in VBA that's keeping me from supporting the native character set of half the countries on the third planet from Alpha Centauri. Which it isn't, by the way.
Driving in traffic for 45 minutes twice each day causes stress, which is a leading cause of heart disease, which is a leading cause of death. Driving is a little cheaper for day to day expense of gas and tolls, but probably a wash if I considered mileage and the depreciation of the car. But I'm definitely a lot less stressed out after an hour on the train than 45 minutes of rush hour traffic.
A project manager trying to be a developer usually leads to the project manager trying to use their clout as a manager to make architectural decisions, often neglecting their project management duties at the same time. If you want to be a developer, you should stop working as a project manager and more into a junior development role on a different project. Working as a junior developer, you'll be able to get mentoring from the senior developers on the team and likely end up with a better perspective on the process. It's important that you do this on a different project so that you don't end up making junior-level development mistakes on senior-level development problems that you've identified as a project manager.
Slashdot Mirror
You know what fine print they don't need, probably can't enforce, and their support staff (or connect.microsoft.com) implies that you violate when they ask for workarounds when reporting an issue with their software?
In the section "SCOPE OF LICENSE" it actually says you can't work around limitations. Not sure when this was added, but it's in Office 2007, Visual Studio 2008, Silverlight, and who knows what else:
You may not: work around any technical limitations in the software
I have no idea why any license would specify that the user is not allowed to work around technical limitations. For one thing, there's not really any way to tell if a user is working around a limitation. And if users are working around a limitation, the software maker probably wants them to do that, rather than have end users just sit and complain that they can't do something because of some limitation. On top of that, these are applications that provide gigantic macro/scripting infrastructure and SDK's for automation so that you can build workarounds for any limitation in the software.
At that point, at least one of the following must be applicable:
1) there isn't anything left that could even vaguely classify as a limitation (and you paid a lawyer to write this in the EULA for nothing)
2) you paid a bunch of programmers to add extensibility features into your software that your end users aren't allowed to use
3) you also forgot to tell the product support team that anyone who calls in with a workaround has violated the terms of their agreement and needs to return the software
I guess at this point, the licensor should decide if the goal as a company is to sell and support software or to create overly restrictive and unenforcable license agreements, and quit wasting money on either the lawyers or the developers and support staff. As a licensee, I would probably just ignore all the B.S. so I can get my work done, and I wouldn't hold my breath waiting for Microsoft to go all Metallica/RIAA and crack down on users violating their insane, counter-productive EULA. That is, unless my work is writing a book on workarounds to the lack of UTF-64 support in VBA that's keeping me from supporting the native character set of half the countries on the third planet from Alpha Centauri. Which it isn't, by the way.
Driving in traffic for 45 minutes twice each day causes stress, which is a leading cause of heart disease, which is a leading cause of death. Driving is a little cheaper for day to day expense of gas and tolls, but probably a wash if I considered mileage and the depreciation of the car. But I'm definitely a lot less stressed out after an hour on the train than 45 minutes of rush hour traffic.
Silverlight 2.0 works on Intel and PowerPC Mac G4 or greater processors.
http://www.apple.com/downloads/macosx/development_tools/silverlight.html
A project manager trying to be a developer usually leads to the project manager trying to use their clout as a manager to make architectural decisions, often neglecting their project management duties at the same time. If you want to be a developer, you should stop working as a project manager and more into a junior development role on a different project. Working as a junior developer, you'll be able to get mentoring from the senior developers on the team and likely end up with a better perspective on the process. It's important that you do this on a different project so that you don't end up making junior-level development mistakes on senior-level development problems that you've identified as a project manager.