Best Practices for licensing

[Scott Kane]

Hi Mark

> Open question for those on the list with commerical offerings for Windows:

>What are best practices for licensing of your RR-created applications?
> For example, how do you recommend generating the keys, how do you
>distribute them, and how do you store the bits locally etc?  And in
> general, what are the problems to look out for.

I'm the moderator for the comp.software.shareware.* newsgroups.  I'm also an 
ex ASP (Assoc of Shareware Authors) Vice President and a member of the Board 
of Directors (term expired).  This is pertinent in that I can  assure you 
there is no "best practice".  The strongest protection tools use exe 
wrapping and I've found Rev app's  break in every single one of  them.  The 
big names were Aramadillo and ASProtect.  Both have now been well and truly 
cracked to the point where they are useless anyway. ExeCryptor is getting 
good press - but I believe it only works with .Net compiled code.  You are 
going to get pirated.  It's a fact of life.  Use a protection scheme that 
keeps the honest people honest as you'll never get a sale out of a pirate 
regardless.  You also won't get "the goods" from authors in public forums. 
Groups like AISIP and the ASP are private and developers are more open about 
what they do (but they don't give it all away)

Resources I recommend:

comp.software.shareware.authors  (I'm moderator there)

AISP http://www.aisip.com    Very cool and private - lots of good info. 
Twenty odd bucks to join.  I'm a founding member for this group

ASP http://www.aspshareware.com  $100 a year.

OISV http://www.oisv.com   Free membership.  I'm a founding member of this 
site.

A Rev application is a doddle to crack compared to some other compiled 
program code.  There is a lot of text in there.  If I was going to hide 
something in a Rev program I'd put it somewhere important  (like a database 
stack - but not a preferences window) and have it checked from different 
parts at the program *randomly*.  This drives hackers nuts.  The second 
thing I would do is partial key validation.   Basically I would create a 16 
digit key code (different for each customer).  When the customer "registers" 
the program you supply a key.  But only check the first four digits.  At 30 
days (or whatever) post the entering of the key  you according to the 
algorythm you have defined you check the last 12 digits.  Doing this means 
the hacker cracks only part of the key.  He gets the first four and thinks 
he's done it.  However many days later your program checks the remaining 
digits.  I know of many successful authors doing this technique.  If the 
check reveals an invalid "full" key  then politely pop up a web browser and 
direct it to your website where you explain their key is invalid and that if 
they have paid for their key they should request another and if not that 
they should buy one.  A small note about pircacy tacked at the bottom.

HTH

Scott