Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 27 posts

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

#11

Post by duncan-donuts »

ezekg wrote: post #9
jetti wrote: post #5

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 syste…

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

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

#12

Post by fian »

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.

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

#13

Post by mb_72 »

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.

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

#14

Post by jakobegger »

ezekg wrote: post #8
jakobegger wrote: post #7

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…

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.

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

#15

Post by laurent123456 »

ezekg wrote: post #10
laurent123456 wrote: post #4

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 publi…

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.

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

#16

Post by danieltillett »

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.

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

#17

Post by jetti »

ezekg wrote: post #9
jetti wrote: post #5

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 syste…

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

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

#18

Post by jetti »

duncan-donuts wrote: post #11
ezekg wrote: post #9

Earlier quoted context omitted.

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

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

#19

Post by ezekg »

jakobegger wrote: post #14
ezekg wrote: post #8

Earlier quoted context omitted.

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…

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?

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

#20

Post by SyneRyder »

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

Post reply on HN