Back Draft
Licensed to Aggravate
Complex licensing mechanisms hurt developers and vendors.
By Jonathan Goodyear
One of my current consulting clients uses one of the leading commercially available .NET components in part of their Web application. It has a good, solid feature set, and based on the research I had done on it, I anticipated no problems using it.
Sure enough, in my development environment, I didn't experience any problems. Things got a bit messy when I tried to deploy to the Quality Assurance (QA) server, though. Instead of the component doing its job, all I got was a "Missing License Tag" message. I fiddled with some settings for awhile and checked for any available service packs. No luck.
I called the support phone number. I eventually learned that the issue was being caused because the component implements a licensing mechanism that requires read access to the directory on my server that stores Crypto RSA machine keys.
Of course, the ASPNET account (which is the account the ASP.NET worker process runs by default) doesn't come with those permissions by default. So I had to add them manually.
Because my client's Web application runs on a dedicated server, I was able to fix the issue with relatively little effort. It got me thinking, though. What if I didn't have absolute control over my server environment? In that case, if I wanted to use this component for my Web application, I'd have to ask my hosting provider to make these permissions changes for me - which they might not agree to do.
A number of component vendors try to thwart component theft through licensing mechanisms that are counter-productive to X-COPY deployment. This is unfortunate because one of the most attractive goals of .NET is to eliminate complex deployment issues. And when licensing begins erecting deployment roadblocks, I have to draw the line.
My question to component vendors is, "Who are you trying to block out?" In my experience, when developers are presented with a problem, they like to stick to solutions they're familiar with. If a Web app requires a certain functionality, a developer is going to try to use the component that he/she is familiar with first. Component vendors who - instead of aggressively protecting their components with licensing mechanisms - look the other way when developers use unlicensed copies for their own personal Web sites tend to build a larger user base, and therefore they garner a larger share of the business that really matters (that of larger clients that actually have money to spend).
The way I see it, there is no component licensing mechanism that can't be hacked, so dishonest developers are going to get their hands on illegal copies if they want to. Reputable businesses who want to use a component will purchase a legal license 99 times out of 100. The only purpose complex licensing mechanisms serve is to give honest developers deployment headaches.
My advice to component vendors is that they stop trying to outsmart the hackers - it will never happen. Instead, concentrate your efforts on catering to developers, allowing them to use your components for their own personal purposes. After all, it is almost always the developers who decide which component vendor to go with for their employers' Web applications.
Jonathan Goodyear is president of ASPSoft (http://www.aspsoft.com), an Internet consulting firm based in Orlando, Fla. He's a Microsoft Certified Solution Developer (MCSD) and author of Debugging ASP.NET (New Riders). Jonathan also is a contributing editor for asp.netPRO. E-mail him at mailto:[email protected] or through his angryCoder eZine at http://www.angryCoder.com.
Tell us what you think! Please send any comments about this article to [email protected]. Please include the article title and author.
