One can divide users in to three categories: those saints who will pay regardless of what measures you take, those freeloaders who won't pay regardless, and the largest group, those who will pay if that is a better experience than not paying. Most people value being able to think of themselves as honest. They want the software to be easy to install and use. They want to be able to update easily when bug fixes come out. They want technical support. They expect their software to run when they get new hardware. And they don't want to pay more than a "fair" price for it. (Ideas of what constitute fairness differ.)
So, you should evaluate every protection measure against the question "Does this make it a better experience to pay, rather than not pay?". So, if users must do complicated things to activate their software, it tilts the equation against you. Making it easy to obtain tech support if you have paid, and hard if you haven't, tilts the equation your way. Making easy for paid users to upgrade to a version with new features, vs. waiting for the the new version to be cracked, tilts the equation in your favor.
As a citizen, it may advance the social good to deny software to people who won't pay for it, but as a businessman, you shouldn't care -- if they won't pay, there's no profit to be made, and it doesn't cost you anything.
The easier it is to plug a security package or library into an application, the easier it is for crackers to unplug. So, if you're serious about technical protection measures, it needs to be intertwined with the functioning code. You need to implement a system where you can vary the protection measures with each release, so it can't be cracked the same way as previous releases. The cracker community has spent thirty years developing its tactics and tools. Inform yourself before expending effort on technical protection measures.
One area that does pay off is making it difficult to generate valid license codes. Then, at least black marketeers can't sell licenses for your software that work with uncracked software. A license code is like a message from the publisher saying 'it's okay to run given such-and-such environment'. Public key cryptography can make it near- impossible to fake a message -- if you dot all your i's and cross all your t's. But keep in mind what you're locking the software to. Palm OS devices don't all have unique hardware IDs, and most customers expect to be able to take their software with them to a new model. You can expect that HotSync names are effectively unique -- but there are hacks to change the HotSync name before any given app executes, so anyone willing to cheat can use a published HotSync name - license code pair and still use their normal HotSync name for syncing.
This is a simplified overview -- there are caveats to almost everything I've said above. But learn about the whole situation before expending effort.
smime.p7s
Description: S/MIME cryptographic signature
