Copy Protection Follow-up

If you saw my post last month on copy protection you know I was a bit frustrated with Aladdin. And in the heat of my frustration, I vented. I still stand by my comments on their documentation and lack of support for 64-bit Vista, but now that I've calmed down, and made some headway in implementing their copy protection solution, I wanted to elaborate on why I chose them.

One reason I went with Aladdin is my sales rep, Krista McCormack. I met her years ago at an Aladdin presentation that I was invited to when I was with my old company (who was a client). She was our sales rep for years and I always enjoyed talking to her. So when I needed a copy protection solution, I thought of her as much as I thought of Aladdin. She is helpful in making sure I get the answers I need. And not long after my ranting post, we talked and knowing how upset I was, she made sure I got the technical support I needed. And I've been relying on that support as I get ready for my release. (I probably could have avoided some headaches by just calling Krista in the first place.)

But the main reason I went with Aladdin's SRM solution is that it offers the flexibility I'm looking for. Although it does have a quick "wrapper" type of technology where you can just "wrap" your compiled project up without making any API calls, that is not what I wanted. I have a bunch of .NET dlls being called from a 3rd party program and I wanted to use an API to control my copy protection from the inside. I didn't want a simple run/don't run solution. I wanted to copy protect individual features. And the SRM API gives me that ability, that detailed control.

Aladdin also provides APIs for all of their functionality - not just the runtime copy protection. They have a separate API for license activation so I can create a way for users to activate new licenses right from inside my application without having to rely on an out-of-the box solution (although if their out-of-the-box solution for this had been less kludgy, I may have used it initially to get to market sooner). And there are a few other APIs that I haven't needed yet.

I also like the flexibility when it comes to licensing. Although I don't want to use hardware locks, I have that option down the road. I know from past experience that some companies prefer a hardware lock and I might want to offer that option someday, and with SRM I can do that without having to change my application. But for now, I am going to offer node-locked licenses and network or floating licenses. And my application will come with a 30-day trial by default. There are even more options that I plan to use, and I like that it is so flexible.

I spent a lot of time doing technical support at my last job related to copy protection, which is why I'm trying to make sure I make it as easy on my users as possible and give them ample licensing options to suit their needs. Which means using some of the more advance features of SRM. Which means running into the shortcomings in their documentation as I'm trying to figure out how to do more advanced things. The downside of having so many ways to customize their product is that it requires a lot of documentation. And unfortunately, documentation doesn't seem to be their strong suit.

The good news is that the support person I'm working with now is a HUGE help. She has all the right answers and has been very responsive. Ideally, though, they would overhaul their documentation so I don't HAVE to rely on support to get my job done.

I'm still not ready for release. I'm still struggling with my implementation of floating licenses and installation of the runtime dlls, but I'm making progress. And in the end, I think it will pay off. Or Krista will never hear the end of it...