
Ask HN: Developers who sell desktop software, what do you use for licensing? - ezekg
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&#x27;s why I&#x27;m curious.<p><pre><code>    - What do you like&#x2F;dislike about your current system?
    - What features are lacking that you wish it had?
</code></pre>
[0]: http:&#x2F;&#x2F;www.mikeperham.com&#x2F;2016&#x2F;05&#x2F;17&#x2F;commercial-gems&#x2F;
======
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...](http://www.brandonstaggs.com/2007/07/26/implementing-a-partial-
serial-number-verification-system-in-delphi/)

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

~~~
ezekg
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?

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

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

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

~~~
ezekg
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?

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

~~~
ezekg
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?

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

------
laurent123456
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/](http://easyhanzi.com/)

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

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

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

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

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

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

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

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

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

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

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

------
louisharwood
Full Disclosure: I work for Paddle
([https://paddle.com/](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

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

