Ask HN: Developers who sell desktop software, what do you use for licensing? | Hacker News Reader

Ask HN: Developers who sell desktop software, what do you use for licensing?

53 pointsezekg26 comments

Is there a quality service that you use or is it all developed in-house? I know licensing systems can range from super simple [0] to intrinsically complex — that's why I'm curious.

    - What do you like/dislike about your current system?
    - What features are lacking that you wish it had?

[0]: http://www.mikeperham.com/2016/05/17/commercial-gems/

View on HN

Seems it depends on your market. I'm doing desktop consumer software, and the licensing is all in-house stuff. Rather than being uncrackable, I'm more focused on usability and keeping honest people honest.

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: http://www.brandonstaggs.com/2007/07/26/implementing-a-parti...

At one of my jobs we used a 3rd party library for .NET to do our licensing but then we decided to roll our own. By rolling our own we got the benefit of doing things that wouldn't be available in commercial solutions. For instance, we sold our software in modules and you bought each module separately but they each fit into the product. With our homemade system we could disable or enable modules at will from our system and have the user refresh. They had to connect once a year but if they bought a new module they could just go to the help menu and refresh their license and the module would unlock immediately. Not sure if you can do that with other commercial products or not.

You're one of the first developers I've talked to that actually implemented feature-licenses (modules, add-ons, etc.). That's something I'd love to know more about. How do you handle toggling features within the codebase? I'd imagine that you'd handle it kind of like you would with feature flags?

I am as thinking it might involve a lot of ACLs. I'm curious too

Not as complex as ACLs, in the strict sense. Take a look at my response here: https://news.ycombinator.com/item?id=13500058

I'm going to preface this with the fact that it has been a couple years since I implemented this and so my memory may be a bit hazy but here we go...

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.

Thanks for the in-depth reply. I hope you don't mind, but I sent you an email with a few additional questions. (I used the email from your HN profile.)

I'm actually developing a licensing SaaS (in closed beta, currently), so I'd love to chat more if you have time.

I sell two Mac Apps. For the Mac app store versions I have no copy protection at all.

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...

EDIT: 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.

So you want a way for your customers to easily see and manage their licenses, and to be able to easily purchase additional licenses? Do you machine-lock licenses for your app, or are they allowed to float between machines?

There is no online activation, so customers can reuse license files as often as they want. That's why most customers don't bother buying additional licenses beyond the initial order, since it is a hassle to figure out how many licenses they are using.

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.

Is there any particular reason you wouldn't use a service that provides this? Aren't you already vendor-locked to your payment provider, or is that not as tightly integrated?

What if the service did on-premise/self-hosting?

I could walk away from Fastspring any day (I don't have subscriptions).

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.

For my application[0] I'm using fastspring.com. From there users can buy a license and when they do so I receive an email. I then run a small program to generate a license file which is then automatically emailed to them. The license is just a plain text file (that contains the user's personal details), which I sign with a private key. The application then verify that the license is correct based on an embedded public key.

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.

[0] http://easyhanzi.com/

Is there any specific reason that you went with public/private keys as opposed to user accounts w/ associated license keys? Then again, maybe your app is primarily used while offline so you may need to do it that way.

I wanted the license file to be associated with the user's personal information (name and email) so that there's an incentive to keep it private and not share it on forum, etc. (I think that's how Total Commander does it as well, as I see my name and post code/town in the About box).

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.

I'd recommend to work out what field you're selling to, and consider if you can follow what the major vendors are using in that field.

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 risk you run by using a third party licensing solution is that they are more attractive targets to crackers. Generally, once a system has been compromised, all of the software using that system become vulnerable. Rolling your own solution takes time and effort and there's no guarantee that it won't be broken but you can also change and update it as needed. In the end you're really only affecting honest customers so keep the system as unobtrusive as possible and put more focus on selling more software and that quality of what you're putting out there - that will more than make up for any shortfalls due to piracy.

A lot of the licensing systems I've encountered cause problems if you're selling to big corporations because they don't work well in locked down environments. Whatever you use needs to have an alternative way.

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.

Good point. I'd imagine big corps would be more interested in an on-premise solution, rather than something that is hosted, e.g. SaaS.

We use a layering of different systems (we choose ones that the crackers complain about) combined with our own in-house systems. It is mighty complex, but it lets us sell expensive software into the Chinese and Indian markets.

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.

Your answer doesn't help Tbh. You could as well say "we use something" and it would have given the same information.

The OP asked what features we were missing from our system and I answered. I assumed he is looking to make a new system and asked us what we would like.

While not security, obscuritiy is another layer of defence hence why I am reluctant to say what we use exactly.

I am indeed developing a licensing API (SaaS + on-prem options), so I appreciate the response either way.

QLM, for both the OSX and PC versions of our product. QLM is web-based, but also handles off-line licensing via a generated file. Our product can be used in demo mode (no saving, limited editing, reports printed with a 'demo' watermark) indefinitely, time-limited demo mode, a basic function mode and a full operation mode. The last three modes are handled via information encoded into the customer's activation key which is then decoded in the application, and acted upon.

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.

Full Disclosure: I work for Paddle (https://paddle.com/)

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

I have used a couple of license management systems for an engineering simulation tool. We first used the Sentinel Super Pro USB hardware dongles. These provided strong license protection and were easy to integrate. The downsides were that you had to send customers physical keys and occasionally keys were "lost" when they were due to be returned.

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.

Reply on news.ycombinator.com