We talk a lot about copy protection in this space but what I want to focus on today is what is meant by the phrase "secure software licensing." Let's unpack the term and look at each component separately:
The sina qua non of all this is security. If your software isn't secure nothing else that follows matters. By "secure" we're talking about preventing a host of bad things you don't want to happen:
- License piracy: your customers bought a certain right or entitlement to use your software. That entitlement needs to be secured in such a way that the customers can't accidentally or even deliberately use more copies than they have purchased. Addditionally, you need to be able to ensure that non-customers cannot use your software until they have a license (i.e., become a customer).
- Code cracking: Modifying the executable code to circumvent or disable any license verification is pretty common these days, particularly for very popular applications. You can find these cracked versions on the usual Internet sites. But increasingly even niche-market B2B software is being cracked, particularly for use in the developing world.
- Reverse Engineering: Reverse engineering of the original IBM PC BIOS led to a slate of instant clones competing with IBM for the same market space. Reverse engineering of software is not illegal in the USA, since it's considered fair use under the copyright laws. Protecting your software against this is critical.
- IP Theft: You're in the software business, and in software your most important assets are your IP--some of which probably exists as algorithms in your code base. Do you want your competitors to see how you solve tough problems and use that to their advantage? Of course not.
- Code Tampering: How do you know that the binary you have is the binary that was created originally? How can your users know? In some applications, this may be the most important question of all. For example, if you're selling applications to the military or healthcare industry, being able to assure them the there are robust internal safeguards against the code having been modified before they execute it can be vital.
- Malicious attacks: similar to code tampering, but in this case you want to ensure that no malware payload has been inserted at any time. Further, you want to know that the code can't be modified on the user's machine.