- What do you like/dislike about your current system?
- What features are lacking that you wish it had?
I use simple short serial codes, automatically generated & able to be emailed again when customers inevitably lose them. (Try to avoid doing manual generation & manual lookups, it will save you a ton of support time.) I avoid characters that are easily confused & can cause support issues, so no O and 0, no I and 1, no 5 and S etc.
As part of usability, I like how iZotope include the name of the product in their serial codes (eg SN-MYPRODUCT3-XXXXX). I've had issues with customers mixing up serial codes, and it helps if you can give them a hint/prompt (eg your key begins with SN-MYPRODUCT3).
If your goal is just to put a small indie product out and sell it, you don't have to over engineer the licensing. I've seen apps where every customer got the same unlocking code, and it still sold plenty of copies.
Brandon Staggs' article on implementing serial codes is still my favorite:
We sent XML that was signed with public/private keys and we just used XPath to figure out what modules were allowed. We would load the file into memory from disk on application start up and then would persist to disk any time they updated their license.
We stored a bunch of information in that XML document such as trials, machine name, machine hash (which took a combination of factors) and sent those all back to our server on registration/update. We were able to track the number of licenses used as well as the number of machines and which machines had licenses.
Then comes the issue of non-internet connected machines. We had our program calculate the signed data based on the factors listed above and then had them paste it in a special section on our website. We then generated our key for them and told them to paste it into the application which then persisted to disk. They would have to do that every time they wanted to update but it was very easy and low friction.
Was it the most effeicent way of doing things? Probably not. Was it the most secure? Definitely not. But it was easy to implement, easy to use and provided, what we thought, was a great UX for the end user while still maintaining some sort of licensing controls.
*EDIT: On the server backend we had just a simple database that had each module, customer, machine name, and access (probably some more info, it's been a few years since I've looked at this as I've moved on).
EDIT 2: I've actually thought of taking what I learned from that and starting a licensing as a service that will provide the flexibility of what I implemented so that you could provide fine grain access in your product fairly easily. I'm not sure if there would be enough interest though.
I'm actually developing a licensing SaaS (in closed beta, currently), so I'd love to chat more if you have time.
For the version I sell on Fastspring, I use a library called Aquatic Prime, which uses public key cryptography to validate license files. It's integrated with Fastspring, so that's convenient.
I've had a couple of customers where Aquatic Prime failed for hard to debug reasons -- I think the issue was that they had names with special characters that caused sorting issues. If I'd do it again, I'd probably do something simpler, since bugs in license validation code are really bad.
I wouldn't worry about piracy or cracked versions. Someone did crack my apps, but it doesn't seem to affect sales. The only people who care about cracked versions of my app are shady companies promising to get rid of cracked versions by sending takedown requests on my behalf. I wonder if those guys cracked my app in the first place...
You asked about missing features. It would be nice if business customers had a way to see how many licenses they are using, and they should be able to easily buy additional licenses. However, building such a system would probably be very complicated and not worth the effort.
Most of my customers are individuals, so the problem isn't as bad as it sounds. I'm not sure building a complicated licensing system would be worthwhile; the potential additional sales are probably not enough to justify the effort.
In case someone suggests a service that handles licensing for me: I won't buy it. If I wanted lock-in, I'd stick to the Mac App Store.
What if the service did on-premise/self-hosting?
I guess the most important part is that everything would need to happen on my domains; there can't be any other people's domains in my code (eg update checking), that would make me too dependent.
I don't care about on-premise or self-hosting or cloud or whatever. I care about lock-in.
I plan to keep my company around for many years. At some point some of the services I use will go away or get too expensive or become crappy or whatever. That goes for web hosting, SVN hosting, mail server, payment provider, etc. That's why they need to be interchangeable.
I pay for services that add convenience; I don't pay for services that lock me in.
To be honest I think I've tried to do something too complicated. If I was doing it again I'd go for something much simpler since, anyway, no matter how complex the protection is, the application can eventually be cracked.
So I'd suggest a very simple system where the user inputs a serial number (that fastspring.com can generate directly), then the app verifies if it is valid. If it is, save it to the Windows registry (or similar place) and check it again every time the application starts. That way, you don't need to bother with any manual process like I do and it won't add much complexity to your app.
The public/private key allows doing this by signing the user's information. A serial number is more anonymous as it doesn't carry in plain text any information.
Your customers' sysadmins are probably already dealing with a bunch of commercial software, more dominant than yours. Go with the flow and lower the workload for everyone.
Seems simple to implement your own; you also get security through some degree of being less mainstream. But don't underestimate the variety out in the field or the amount of hardening that existing solutions have had.
In our case, I've never experienced a vendor's 'home brew' solution actually work properly when faced with the load of a renderfarm or HPC cluster (normal for customers like us) without several revisions. Hardly unsolvable problems, but then a dialogue back and forth is needed to fix such issues; wasted time for both parties, unless you are in the business of developing licensing servers.
Obviously there's a balance here with how much it costs to bring in a tried and tested solution (flexlm and rlm are the ones I know of) vs cost of the other options.
The other question is the ease of integration and the cost of the software - if you spend weeks integrating and troubleshooting it, I'd be tempted to forego it for anything but a high-value product.
Keep in mind that troubleshooting it will be an ongoing process when some paranoid BOFH has locked down the user's machine to the extent that they can't do anything, including their job.
What we would like is a truly different approach that is compatible with other licensing systems. It does not need to be perfect, just a pain to the crackers so that it adds another hurdle they have to deal with.
While not security, obscuritiy is another layer of defence hence why I am reluctant to say what we use exactly.
Previously - on PC, there was no Mac version at that time - the 'licensing' was encoded in an INI file which users worked out they could share. QLM has eliminated this kind of 'dumb' piracy, and via the application and logged attempts we can see if people are trying to activate the application on multiple PCs or Macs and so forth.
Next step is to get automatic license key generation working via Paypal payments. I can't really think of any features that we are missing with QLM.
Paddle take care of licensing, trials, payments and associated VAT/tax obligations through to analytics either through the web or a number of SDKs for Mac and Windows.
Worth checking out
We wanted to protect against this but, at the time, the keys did not have any built in date tracking so we tried to implement last date used tracking by writing a timestamp to the keys every few minutes - this proved to be quite flaky and keys would eventually become corrupt. The keys could be recovered by rewriting the original license file, but it was annoying to the users.
There are newer Sentinel keys that include an onboard, battery backed clock which we could have migrated to to solve that problem.
However, our company was acquired and the software team was merged into a larger group. The larger group had standardised on a third party software based license management system. So we migrated the simulation software to this system based on some guidance from the other teams. The migration was painful, taking many weeks. The functionality provided by the license management system is far less flexible than what we could do with the dongles. The license management system worked by fingerprinting the client machine via various keys/ids of installed hardware. The license files contain an unencrypted list of the keys/ids that the license was checking. So it is trivial for someone to read the license file and know exactly how to modify or fake the keys on a second machine to replicate the license. It took me less than 15 mins to perform a license replication to a second machine using just the license file and tools available as part of the default OS installation.
Realising this, I read the docs thoroughly myself as it seemed crazy that this could be the correct way to implement the license management system. Sadly it was correct. If effect the docs said a pure software approach is weak and if you need stronger protection you should use a hardware dongle. This is essentially why they call it a license "management" system vs a license "protection" system.
You should choose a license system based on who you target market is and how much you sell the software for.
If you are selling to the general public, having many users and (probably) lower license fees, then look to the pure software based solutions as managing hardware dongles will be onerous. If the pricing is reasonable and you make it easy for people to buy/renew then there is less incentive for them to pirate.
If you are selling to a enterprise or niche market with high license fees (thousands of dollars per licenses and up) then there is a stronger incentive for someone to try to break your licensing system. This is where a hardware based solution starts to make sense.
Note that even the hardware dongles can be beaten by a truly determined attacker. By going the dongle route you are just raising the bar higher.