Enforcing user license limits

[Luke Webber]

I'm soon to commence writing a large-scale app for resale, and I need to
consider how I'm going to enforce user license limits. That is to say,
if I sell company A a license for 200 users, how can I ensure that only
200 users get access. And also make sure that the limit doesn't kick in
when it shouldn't. Obviously, that's the problem with just decrementing
a counter in a table row - if one client OC dies, the license remains used.

I'm thinking of implementing a license server to run on the server
machine, and send heartbeats to it from an application thread every
couple of minutes to keep sessions alive. But I'm open to any
suggestions, especially if they're simpler than this. <g>

TIA,
Luke

 

[Thomas Weidenfeller]

I'm soon to commence writing a large-scale app for resale, and I need to
consider how I'm going to enforce user license limits. That is to say,
if I sell company A a license for 200 users, how can I ensure that only
200 users get access. And also make sure that the limit doesn't kick in
when it shouldn't. Obviously, that's the problem with just decrementing
a counter in a table row - if one client OC dies, the license remains used.

We have discussed this here a few times in the group. You might want to
search an archive.

The conclusion is always the same: There is no 100% secure method. All
things can be hacked. Java makes it slightly easier, since it can easily
be decompiled.

My suggestion would be, if you go for some license enforcement, chose a
method which annoys your users and their system administrators the
least. E.g. avoid complex license server configuration, make the
purchased number of licenses (e.g. your 200) a soft, not a hard limit.
Let the soft limit trigger some friendly, non intrusive notification.
Set the hard limit at something like n + 10%. Let people use the
software for some time, even if the license server is down.

But I'm open to any
suggestions, especially if they're simpler than this.

Buy one. It's the old calculation. It might be cheaper to buy this, than
do your own.

/Thomas

 

[luke]

We have discussed this here a few times in the group. You might want to
search an archive.

I did in fact try that on Google Groups, and I'm normally pretty good
at choosing search terms, but this time I couldn't refine the search
sufficiently to get a meaningful result.

The conclusion is always the same: There is no 100% secure method. All
things can be hacked. Java makes it slightly easier, since it can easily
be decompiled.

Hmmm, hacking was not my immediate concern, because the clients for
this product aren't all that sophisticated. I'm really just looking for
a good and sufficient solution, it doesn't have to be watertight.

My suggestion would be, if you go for some license enforcement, chose a
method which annoys your users and their system administrators the
least. E.g. avoid complex license server configuration, make the
purchased number of licenses (e.g. your 200) a soft, not a hard limit.
Let the soft limit trigger some friendly, non intrusive notification.
Set the hard limit at something like n + 10%. Let people use the
software for some time, even if the license server is down.

Sounds like we're on the same track. It's better to let the users get
away with the odd freebie than to get a name in the business for
screwing them over.

Buy one. It's the old calculation. It might be cheaper to buy this, than
do your own.

I might well do that, but I'd need to find one first. <g>

Cheers,
Luke

 

[Shane Petroff]

I'm soon to commence writing a large-scale app for resale, and I need to
consider how I'm going to enforce user license limits.

Why not drop the user license altogether in favour of a temporal one.
Use OpenSSL, become your own CA and issue clients certs for whatever
duration they pay for. The license then becomes the cert and the SSL
infrastructure manages things for you (although I can't say I've
personally tested expired certs). If someone wants to run unlicensed,
they have to turn off encryption, and 'bad things may happen'.