views:

342

answers:

9

Hi there,

We are trying to offer a license mechanism for every feature our Linux application is running and we are thinking of controlling it in a centralized way using a license server:

Our aim for licensing is:

  1. Deny features the operator has not bought.
  2. Offer trials (features which expire if they are not bought).
  3. Activate features for periods of time, and make them available just for some period of time.

Does anyone know any server license which allow us to do this (basically, we would use sockets to communicate with our app) ? Any open source / pointer / suggestion just to start up with some ideas ? Thanks !

Best regards, Raul

+1  A: 

Having used various packages that make use of license servers like this, I can tell you it is one sure way to make your software universally hated by its users.

anon
Hi Neil, Can you give some example of such packages ?
+1  A: 

This is such a Dilbet-esqu way of doing things.
Just say no.
Although hated, this is a standard feature in high-end specialized software which costs tens of thousands of dollars. Think 3D scanners and CNC stuff.

shoosh
+4  A: 

If you really want to use a license server then make sure that your app does not have to contact it all the time to authorise use - this will lead to no end of problems when people lose their internet connection or your server goes down or crashes.

I would suggest having something where a key is downloaded and stored locally, thus reducing round trips to the server all the time. The key can be encrypted based on the user's machine details so that keys cannot be shared.

We've used HASP hardware keys in the past and whilst they defnitely work and provide a solution I don't think they are what you want as they are programmed once and that's that. You wouldn't be able to update the HASP key to close a trial period for example.

Steve Claridge
You can program a HASP key to die after a 30 day trial period. This is commonly done for software that is licensed for any period of time. I have done this with a number of different hardware keys including the HASP range of keys. Using a HASP key for a trial period, however, is an expensive way to go. Further, any information stored on a hardware key can be easily changed in the field using a software program. It is only a matter of recompiling the routines that control your key and repackaging in a new update program.
jay
+2  A: 

There are times when software does need protection - check out these guys here - they provide hardware and software solutions.

James Fisher
+2  A: 

Do you really need to "phone home"?

I've seen a relatively painless license system, through which the user was provided an XML file that described the period the license was valid, an optional IP address, and the list of "unlocked" features. A digital signature was generated using the vendor's private key, which was reinserted into the license file. At startup, the application was reading the license, validating it, checking the IP and unlocking the features accordingly.

The vendor can provide newer licenses to the client when needed.

Although you could theoretically fool the license by changing the machine's local time and fudging with the IP address, in that case this would have made the application quite cumbersome to use, so this was not a problem.

small_duck
A: 

A common licensing software is flexlm. However I would think twice if I would impose these restrictions on my users. Many users dislike them; especially from the FOSS/Linux environment.

lothar
A: 

If you do plan to code something up yourself, a common mechanism that I have seen is to tie the license to a mac address.

sharth
+1  A: 

FLEXnet (formerly known as FLEXlm) is a licensing package that is commonly used by high-end or specialized software packages, for example in the electronic design automation market. You can lock a license to a single machine (by hostid, usually an Ethernet MAC address) or to a portable hardware dongle, or have a networked server handle sharing a limited pool of concurrent licenses to clients running your software. Licenses can be granted for a limited time or permanently, and also can be limited by a version number. A license file describes the features that are licensed.

FLEXnet includes several APIs for integrating with your application, including one for C++. I imagine it uses public key cryptography of some kind. Generally, an application using FLEXnet only "phones home" when you ask it to through your use of the API. Many applications check the license once, at startup, or reserve a license from the pool for the duration of the application's runtime.

You pay an annual license fee, of course, to use FLEXnet in your products, starting above USD 1k. The fee varies by the revenue of your company and by the number of platforms (OS/CPU combination) you want your licensing scheme to be able to run on.

I would say it's not worth it to use something like FLEXnet if your product sells for less than several thousand USD per seat. It is onerous to use (the source of a good percentage of support calls for our company), but corporate customers may already be familiar with using it, depending on the market.

FLEXnet, like every DRM scheme I've heard of, is easily cracked. At least I assume it is, since unlocked versions of our products are regularly found on warez sites.

rkb
A: 

Another option for you is he one we provide at Agilis Softare. We protect C/C++ applications on a range of 32- and 64-bit Linux platforms. You can control any number of product features, and even set detailed licensing policies at the level of each feature (e.g. a 30-day license for 5 seats of Feature A, a perpetual license for 10 seats of Feature B at the Pro level etc.).

To rkb's point, FlexLM is regularly cracked, as a quick Google search will find any number of sites offering cracks. It can also be a support issue. However, neither of these is true for our system, as you can also verify. We have attracted a number of former Flex customers who got tired of receiving more support calls for their licensing system than for their own product.

Dominic

Dominic