NSLog();

In the past, any software I've written has either been freeware or required only a basic registration scheme - a serial number that was validated against not only the registered user's name and email address as well as a standard formatting pattern. Some of it's been pirated, but I didn't want to spend a lot of time making the registration scheme more complex for the few extra sales I might get from the people who pirate software, and I didn't want to annoy our honest customers. Basically, I relied on people's honesty, and for $10 to $40 apps or so, it worked out well enough.

I've said bits of this before, mostly here, and I still feel the same way.

I'm preparing to ship and sell some software later this year that will cost around $500 for a Pro version and $50 for a Home version. The product name starts with "A" and we'll want to sell licenses for Pro which allows for up to 1, 3, 5, and 10 licenses. This isn't software pirates will be after like they might for, oh, a DVD ripper or an $800 graphics software or a video game or whatnot. It's a niche product.

The main goal here is to stop casual piracy. Basically, we want to stop the guy who buys one license and then gives it to his friends or installs it on a bunch of computers used by his peers or employees.

That said, there are a few requirements and a few "nice to haves" out there. An obvious assumption is "the less code we have to write, the better" so any sort of library out there that can help with some or all of these things - great (Aquatic Prime being an obvious candidate).

Requirements

Registration schemes which require a matching name and email address work fairly well at keeping some people honest. It's nowhere near foolproof, but the effort required is minimal.

We're going to be hosting our storefront with FastSpring, so our registration/licensing scheme should work with FastSpring and PHP/MySQL as needed on our server.

The registration code should include a product marker, like "ANP" or "ANH" at the start, along with a version number simply so that we can see - at a glance - when the product was purchased. We could even include order numbers in the code if there's room, and any of these can be used to create the key for the registration code.

The registration code should include the number of licenses in it, likely in an encrypted part of the registration code but possibly only "gently encrypted" (i.e. "BC = 1 license, X3 = 3, 8A = 5…) so that we can recognize them easily.

Preferences
The licensing scheme should ideally not be a file, but rather something that the user can copy and paste into a registration box. Not a requirement, but I think people conceptually find it easier to copy and paste from an email. I may be wrong.

Network checking of registered copies to ensure that the limits aren't being breached. If someone buys a three-install license, we don't want them running it on five computers. Or, more likely, if someone buys one license to this app and gives it to their four co-workers, only one should run at a time.

The Nearly Impossible to Get Right
Ideally we'd like to limit our licenses to a per-machine basis, but there are a number of problems with that. Someone owns two computers that they don't use at the same time. Someone's computer breaks. Someone uses a different computer to buy the software than the one on which they intend to use it.

How do you solve that? By manually activating the software when the user calls you?

We'd love to tie our registration codes to one machine (or three machines, or however many licenses they've bought) but I don't know if there's a good way to do it.

Possible Solution
The best solution I can think of - for now - is one in which we generate a registration code using the above conditions (name, email, product and version number, some indicator of licensed copies).

The registration code is always checked against available networks to see if the registration code is in use by the licensed number of machines (or fewer). If it gets back "more than" it's displays an alert and fails to fully launch.

The application also phones home every time it launches, and passes along some basic information like the registration code and the IP ((The Internet-level WAN IP, not the LAN IP as getting back 192.168.1.54 would be pretty useless.)) and MAC addresses of the machine. If the machine can't connect for X-7 days, we start to tell people that they should connect their Mac to the Internet soon. If they reach X days without checking in, or they get a "NO" response ((The "NO" response from the server can include additional information, like "Please call us as your registration code seems to have been pirated." - text we could use in the dialog box to explain to the customer what's going on.)) from the server when they do check in, the app refuses to fully launch.

If we see a registration code being used by twelve Macs with wildly different IP addresses, we would likely contact the original purchaser and then, pending the result of that conversation, blacklist the registration code on the server as well as future versions of the software.

The downsides? Our application is likely to be used by people who are online, as it includes the ability to do some things online and to create emails and do other things that require network connectivity.

The "phoning home" stuff requires a little more work, and the scheme I'm envisioning is simple enough that someone could simply set up "domainname.com" on their computer and falsify the server responses. Again, that goes to doing just enough work to keep people honest, but not investing a lot of time trying to fight the determined pirates. The vast majority of this app's target market would have no idea how to do what I just wrote. Besides, we should be able to include OpenSSL to encrypt the channel and run HTTPS.

Other Ideas
I'm open for other ideas. Again, with a $50 and a $500 app, even people who are mostly honest will have much less trouble rationalizing giving their registration code to six close friends. Competing products in this category sell for $800 to $1300, and require frequent activation phone calls to the company supporting them, so there's some precedent in this category for being at least "slightly" annoying to customers - though ideally not as annoying as having to call them when you put your software onto a different machine.

Thoughts? Ideas? Suggestions?

P.S. I may amend this as necessary, but I hope to make further clarifications in the comments only, and if I do amend I'll make it clear where I've done so.

Comments RSS