From the archives… NIck Bradbury – the creator of such software as FeedDemon – shares a story about how he deals with pirated software and the types who demand that he fixes their stolen software… I bring this up for a couple different reasons. If you are building your mISV and end up with a product that has any value at all, it's going to get pirated. If you run a consulting shop, you can run into similar problems where customers have the product but they “forget” to pay. If you're doing consulting to build a product, you get the best of both worlds!
Let's just get this out on the table. Realistically, you can't do much. You can't order a nuclear strike on their home. You can't kill their dog. And most of the time, it's difficult – if not impossible – to take any action against them at all.
Yes, you read that correctly… most of the time there is nothing you can do about it. Regardless, I'm using this space to lay out some examples that I've seen in the past. Some of these are likely to cause you legal troubles if you try them, so please don't. This is simply a discussion of what I've seen.
First, you can go the FeedDemon route. When you release a patch/upgrade you can purposely cause it to fail on unlicensed/pirated copies. As long as your error message is sufficiently cryptic, this is probably the most subtle way to combat piracy. The best part is that as new cracks are released, you can keep this up and drop little land mines for these thieves. Unfortunately, no matter how entertaining this is, when they complain about the problems publicly, you know they're thieves but other readers do not. Therefore, it could cause your software to get a reputation that it doesn't deserve.
Next, there was a recent piece of OS X software that upon being fed pirated registration keys would simply delete your home folder. Wow. As entertaining as it sounds, there is no way in the world that this is a good idea. Even if your customers have 0% chance of hitting one of these keys, the creeping doubt of “what if there's a bug” will lurk in every potential customer's mind. Unless you can build 100% bug free software and guarantee that your legitimate customers never hit this issue, you are sitting on a time bomb.
On the consulting front, these can be a bit more complicated since you are often providing the source code at the same time. You can purposely insert errors that “go away” after putting in the magic code, but if they're already avoiding paying you, having any bugs makes things difficult. Damaging their data is an even worse idea. It's simply not worth the time, trouble, and risk inherent in this sort of process. Every bug, problem, etc is simply providing additional ammunition for them. Don't do it. Instead, I've seen in the past where a company has “accidentally” delivered an out of date version of the source which happens to correspond with the last payment received. This one is much more subtle for a couple different reasons:
First, the providing company could argue “this is the code you paid for”. Technically, this would be the last code they paid for, but I can't begin to estimate how this would stand up in a lawsuit. But the second aspect is even more subtle. As the “customer” – are they still a customer if they don't pay? – makes additional changes on the code, they are steadily corrupting the system with out of date code…
Once again, let me clearly state:
I am neither endorsing nor encouraging any of these actions. I have no idea of the legality of any of these things and I am simply sharing situations I have seen.
All of that being said, each of these have pluses and minuses and could be problematic regardless of their effectiveness. Regardless, licensing, payment,and non-payment are some of the things you will have to deal with and you need a strategy that protects both you and your customers.