Fog Creek Software
Discussion Board




Software License Management ...

Peeps,

Have any of your integrated a software license management solution into your product ?

What solution did you use ?
What were the pro's and con's ?

Any comments much appreciated.

James Ladd
Thursday, May 16, 2002

Haven't used one in my product. One company I worked at used FlexLM for UNIX and NT, and I was very glad there was no version of FlexLM for Win16 at the time (when I was doing the Win16 port). It seemed like our tech support people spent HOURS on licensing issues.

But as a customer, I have HATED FlexLM in the past. I was inclined not to use a product that used FlexLM unless there were a lot of benefits in the product. I've had too many cases of FlexLM locking out legitimate users; and the administration tools weren't easy to use. And the worst case was if you had floating licenses AND users who sometimes needed to use them on disconnected laptops. The only practical solution was to by a separate fixed license just for the laptop; but that could soon negate the benefit of floating licenses.

They have loosened the product up considerably lately. The administration tools have improved. And since I now have only one fixed license installed on my laptop, the floating license problem doesn't matter to me; but I'm told by others that floating licenses are now "leased" to a particular machine, and can be used disconnected from the license server for some length of time. (My students said it was two weeks, which is GREAT.)

So I think the FlexLM folks recognized user dissatisfaction, and have worked to correct it. And on the plus side, it's an amazingly secure system. Yes, I'm sure someone clever could crack it, but it won't be easy. You certainly won't get casual users pirating. (You also won't get people using the same license at work and at home, but never on two machines at once. I suspect that's usually a copyright/license violation, but I always considered it a fairly benign one. I liked the old Borland "common sense" license that explicitly allowed simultaneous installation as long as there wasn't simultaneous use. FlexLM doesn't support this.)

But realize that with strong security comes a cost. Some people are philosophically opposed to strong copy protection. Yeah, some of those are just pirates, but there are other reasons. And even users who scrupulously respect copyright laws will get annoyed if license management is too cumbersome. (Consider that Rational is now advertising as a feature the fact that their new XDE tool no longer uses FlexLM: they had so many complaints about license management that they decided it was a detriment to their sales and support.) So if you decide to use license management, be aware of the down side along with the benefits.

Martin L. Shoemaker
Thursday, May 16, 2002

A History
We moved to FLEXlm with the knowledge that as many as 50% of our seats were being used illegally.  Many companies bought (for instance) 10 seats, and then grew to 15 users and just kept installing.  Our VAR-channel was aware of this, but unwilling to confront users because of the negativity in a competitive market.  In extreme (but not rare) examples, companies would have 1 annual contract (and thus get 1 new seat of all new releases) and install the new release on all seats.
The expectation was that we would see a 10% to 20% increase in sales revenue with deployment of FLEXlm, estimates that were lower than what Globetrotter (the maker of FLEXlm) pushed.  So we went about the implementation.
To say it was hell would be taking the easy dodge, but it wasn't easy.  Our product is a Windows product and our customers are Windows users, and not sophisticated ones.  Blue-collar guys are our end-users, by and large.  FLEXlm comes from a UNIX background and was ported to Windows, and the heritage could be painfully obvious at times.  I don't want our customers having to care about environment variables, for instance.  They should boot the program and it should work.
In the first release under FLEXlm our customers screamed in pain.  We begged, threatened and generally passed on the pain to Globetrotter.  No real response.  In the second release we did better, and Globetrotter started to come around.  On the third release under FLEXlm I believe we finally have it "right", at least under that majority of cases.  Support continues to be an issue.
We have not seen a 10% increase from the illegal seats becoming.  After we first implemented it, we had anecdotal evidence of people getting legal, and that was very gratifying.  Customer sites who theoretically had 10 seats were calling and asking what it would cost to get 5 more.  However, that has not paid out in the overall.
On the other side - FLEXlm is not hugely expensive.  It is quite likely that enough legal seats have come on board to pay for the FLEXlm side.  A big warning though: the FLEXlm contract is based on the revenues of your company.  Not the revenues of the products that have FLEXlm installed.  We paid our first "royalty?" bill to Globetrotter before we even had a product out the door.
Bottom line - It might still be worth it, and if your customer base is very likely to pirate quietly but come clean under a bit of pressure.
p.s. DO NOT USE FLEXlock, the trial-usage cousin of FLEXlm.  It is pitifully easy to break by a vaguely savvy customer, who then can explain how to break it to all his buds in a 5-line email.

Protecting The Guilty
Thursday, May 16, 2002

If you really want to limit usage, use a dongle, not a software license. Then there's no question about floating vs. fixed licenses. Anyone can install, and if they've got the dongle installed, it'll run.

That way if somebody needs to take a license on their laptop, hand them the dongle.

Just remember that this stuff only keeps the honest people honest - somebody who wants to break your license WILL be able to, no matter what you do.

Chris Tavares
Thursday, May 16, 2002

As we began a migration to using IDEA  from emacs, at a couple points we had a few machine using evaluation licenses as we waited for the real licenses come in.  At some point they complained that the same license was used on more than one machine on the network.  Seems pretty smart to me. 

Why not license in discrete chunks?  1-5, 5-10, 10-20 etc?  Time bomb the licenses so that they have to get a new cert from you periodically.  When you issue the new cert, you can query them about usage, and up the license level.  Let's face it, it doesn't really cost you any more for one additional user.  I costs you more on a contuopus scale per size of support requests.

A little creativity here could really win you big plaudits from you customers.  Get a reputation as an easy company to work with/forIgnore the pirates that don't really affect you. 

There are easy ways to do this.  Require a new install to get a cert from the main web site.  Use the MAC address as the key.  Allow them to continue to do this as many times as they want.  You can monitor their distribution habits.  People will be very wary about this.

Hell, make one of the limits the number of times they can download a license.Be flexible in helping them to get new ones once they exceed their quota.  Do it like FastTrak:  Give em an account with x number of dollars in it.  Each time they down load a license, subtract an amount from that account.  At the end of the time period, return the unused portion to them (actually, just let them roll it over into the new time period)  It'll make accounting hell, but accountants get bored with the routine. ;)

Make life easy for your customers.  You'll spend fewer engineer weeks on it, and have happier cusotmers.  Everyone is online these days.  Make it trivial for them to license over the internet.  Be liberal with your evaluation licenses. A couple weeks using a free copy gets them hooked. 


Joel, Please add a spell check to this site.  I am really smarter than my ability to type correctly would imply. 

Adam
Thursday, May 16, 2002

we do have spell check on this site, it's just that your license has expired.

Joel Spolsky
Thursday, May 16, 2002

Just remember kids, only use the bare miminum license key protection software that you need. Use just enough to stop casual copying - because not matter what you use, you can't stop it. Period.

FlexLM is a bitch to use. Terrible peice of software, and retardedly insecure. Under linux, it's dead easy to fool it into accepting any "hostid". Therefore, if you have a license that'll only run on computer A, you can now run it on any computer, because flexlm will still think it's on A.

Don't beleive? here is the hack:

FlexLM uses the MAC of your NIC to make a hostid. It does this in linux via an ioctl call. You can PRELOAD your own ioctl that flexlm will call and have it return any MAC you want. Here is the code (made brief, probably wont come out right because of lessthan chars):

#include <dlfcn.h>
#include <net/if.h>
#include <string.h>
typedef int (*ioctl_t)(int, unsigned long int, char *);
int ioctl(int d, unsigned long int request, char *argp) { int out; ioctl_t realioctl;
void *libhandle; /* mac address here */ char data[14] = {0x00,0x00,0x00,0x00,0x00,0x00,0,0,0,0,0,0,0,0};
struct ifreq *lame; lame = (struct ifreq *)argp;
if (request == 35111) { memcpy(lame->ifr_hwaddr.sa_data, data, 14); out = 0; } else {
libhandle = dlopen("/lib/libc.so.6", RTLD_LAZY); realioctl = dlsym(libhandle, "ioctl");
out = realioctl(d, request, argp); dlclose(libhandle); } return out; }
#include <sys/utsname.h>
typedef int (*uname_t)(struct utsname *);
int uname(struct utsname *buf) { int out; void *libhandle; uname_t real_uname;
libhandle = dlopen("/lib/libc.so.6", RTLD_LAZY); real_uname = dlsym(libhandle, "uname");
out = real_uname(buf); strncpy(buf->nodename, "localhost", SYS_NMLN);
dlclose(libhandle); return out; }

Marc Luu
Thursday, May 16, 2002


You are kidding, right? We are talking about end-users, and you post some half baked C code with the word "lame" as a variable name, dealing with address and such.

If you need to write that kind of stuff in order to cheat it, then the software is pretty good, if you are aware that there is no such thing as an inviolable copy/install protection.

Leonardo Herrera
Thursday, May 16, 2002

Adam,

You're making big assumptions that may not apply to average shrinkwrap customers.  May be fine for programmer tool web customers perhaps...

a) Assuming everyone has a MAC address.  Sorry, they don't.  For instance, customer's machine reports its MAC as starting with "44455354".  Is that real.  No, actually it's Windows lying to you.  Spell that out as ASCII and it's "DEST".

b) Assuming everyone wants to have a on-demand access to the web on the work machine used by every employee.  Sorry, they don't.

For the dongle guy:
c) Assuming everyone will buy into a dongle.  Ask yourself why several major packages (such as Autodesks' 3D  Max) no longer have dongles.  Also remember that you can't count on people having parallel ports, so you'll need to offer both parallel and USB dongles.

d) Assuming people don't want floating (aka network) licenses.  If your planned customers do not include any companies with more than 5 employees, you may be safe on this.

So warnings Joel, roll-your-own may not be as easy as it looks...

Protecting The Guilty
Thursday, May 16, 2002

My colleague and I are facing a similiar problem incorporating a good licensing into our .Net components. We tried the LicenseManager built into .Net. Then after we put that crack pipe down realized it would not work for us and decided to roll our own to create licenses for time based demos, full featured versions, and creating a seperate license they can use for royalty free distribution of our components. We really just want to stop the users from casual copying and we don't want to alienate anyone with difficult licensing schemes.

But does anyone know of any products that can help us with these tasks?

Ian Stallings
Thursday, May 16, 2002

Roll-your-own will be very difficult. At least there will not be published cracks around on the www.
I know, "Security through obscurity... yadda, yadda"

Doug Withau
Thursday, May 16, 2002

If you need software license management, you should revisit your business plan.

Tom Smith
Thursday, May 16, 2002

> Roll-your-own will be very difficult. At least there will not
> be published cracks around on the www.
> I know, "Security through obscurity... yadda, yadda"

...doesn't work, so why advocate a spurious benefit?

At my previous job, we rolled our own license key system.  Cracks appeared on the net almost immediately - and this is for a server product.  I don't know how long it would take for desktop products, but my guess is PDQ.

How we got around piracy issues was to provide support (both user and technical, bugfixes and the like) that was so good, people were happy to register just to get it.  And, quite often, they registered pirated installations when they ran into problems, just to get support.

Duncan Bayne
Thursday, May 16, 2002

A great deal of information to assimilate. Thankyou all for the responses.

Has anyone used something other than FlexLM ?

Joel, when is your product out ? Is there a blurb on it ?

BTW- Still blushing over my name on Joel's front page :)

James Ladd
Thursday, May 16, 2002

I am not assuming MAC addresses are unique.  Just that a different installation will get a different MAC address. If you find that this assumtion is false.  Try something else. 

My point has nothing to do with using MAC addresses.  I has to do with not annoying your customers.

Remeber your goal:  Maximize revenue.  Not minimize piracy.  Not increase customre license covereage.  Maximize revenue. 

OK, for the nitpickers out there, you want to maximize profit, so don't spend too much on your licenseing scheme if doesn't have a correspondiing business value.

I realize that people who are reading this thread are probably going "Yeah, Yeah, I know that already.  I want to buy an off the shelf solution that works."  There is a reason why this is hard to find.  It makes bad business sense.

BTW, you can copywrite your project as well, which will allow people to use it as they see fit, and just not allow other people to make redistributable copies....at least legally.  Thus only RedHat Linux can distribute RedHat Advanced Server, although anyone willing to download and compile it can run it.

Adam
Thursday, May 16, 2002

I've used the Rational License Key Manager that they use for all their products (such as Purify). It is very annoying to setup. You can get fixed or floating licenses. To get a fixed license (which is tied to a single machine forever), you must fill out numerous forms on Rational's web site and wait for an email. Then prepare for the sales people to call and email you repeatedly. >:-\

At work, we have some floating licenses for Purify, which you must check in and out of your pool of license.. again using Rational's web site. From what we have seen, however, this scheme is somewhat broken. We have found once you have feed Purify the checked out license on one computer, it will continue to work even after you check that license back into your pool on the web site.

I think the lesson (again) is that these "features" ANNOY your customers and are DIFFICULT to write correctly! Software licenses annoy honest CUSTOMERS and are eventually thwarted by dishonest users anyway..

Banana Fred
Thursday, May 16, 2002

<< I've used the Rational License Key Manager that they use for all their products (such as Purify). It is very annoying to setup. You can get fixed or floating licenses. To get a fixed license (which is tied to a single machine forever), you must fill out numerous forms on Rational's web site and wait for an email. Then prepare for the sales people to call and email you repeatedly. >:-\ >>

Fred, unless I'm wrong, the Rational License Key Manager is just FlexLM under the hood. And you're right: it can be annoying to set up.


<< I think the lesson (again) is that these "features" ANNOY your customers and are DIFFICULT to write correctly! Software licenses annoy honest CUSTOMERS and are eventually thwarted by dishonest users anyway.. >>

Well, in all cases I know, yes. I'm willing to believe somebody has a secure-yet-simple-and-not-annoying solution. But I haven't heard of one yet. And I suspect there are business cases where they're useful.

Martin L. Shoemaker
Thursday, May 16, 2002

I also think that one of the *best* approaches is the one used by CityDesk. It is free to try and use. When you reach a certain size, then it is clear that he business is becoming dependant on the software, and thus finds it most useful. I learned this idea from Joel, and am planing to use it for one of my software packages also.

My point here is that you don’t need complex license system. However, it is really silly to assume that nothing is needed either! You need something, and it should be as little hassle and unnoticed to the end user as possible. You need something that discourages the Accounting department to copy the software for the sales department.

As side note I do have a simple license key system for my software. This key is issued to the company, and is a file with the Company name that purchased the software (along with some check sum stuff, and a expiry date). Thus, they can copy the software, and employee can steal the software (perhaps for a competitor). However, if they change the name, then a check-sum will not match. Since the name appears on the main menu, and also on a whole bunch of reports, then this is very good method, since most companies don’t want a competitor name, or simply just a different name appearing on menus, and reports.

The problem with the above method is that it really depends on the kind of software, and also how the software is to be sold. In other words, do you really want any labor content to be involved in the Licensing of each "copy" your software?

If your distribution is to be totally electronic, and no intervention required, then the above is a little more difficult to do. In other words, there are questions here of *how* the end product is going to be distributed.

Albert D. Kallal
Edmonton, Alberta Canada
Kallal@msn.com

Albert D. Kallal
Friday, May 17, 2002

Since I am from a country where the wages are much lower than these in the USA or Western Europe I have experience with not licenced products :)

Cracking the software protection is as easy as downloading the crack from a site.
http://astalavista.box.sk for example

Making the software uncrackable by a unual user is often easy, but the real problem is that 'if there is will there is a way' to crack it.
In my case, no matter the protection, no one can make me pay $1500 for product which I will benefit much less in my country. This is the average year wage here (Bulgaria).

But of course here we are talking about clients who can pay this but just do not have the 'stimulus' to do this.

One of the good solutions is to not make your product popular and good selling. No one will care making cracks. Well the problem is that you do not benefit from that :)

BTW I have seen all kind of software cracked. I have seen one using FlexLM too.

Boris Yankov
Friday, May 17, 2002

Has anyone here seen the key that the "CloneCD" program requires? If you chose keys to protect your software, then *please*, make it a short one! I don't want to enter an 68-digit prime number just to register!

Dongles are no good for Shrinkwrap software. What would have happened if Windows 3.11 required a dongle? Dongles are, however, a good idea when developing internal software. If you talk dongles, then talk eAladdin:
http://www.ealaddin.com/
I had great experiences with their dongles, and they can be used to protect your program, without any programming.

Another way would be the [Name of very large company where Joel used to work] method: release buggy software, make patches that can only be installed from the web directly to the downloading PC, and log everyone downloading your patches ;)

rrobin
Friday, May 17, 2002

You can find good program with very simple software license management at www.aspack.com. It has very severy limitation (no floating license, so on), but it works good. It encrypt your program, so it's quite difficult to hack it. We've used it for our program for a year, no cracks yet.

The name of a product is asProtect.

Sergey
Friday, May 17, 2002

We have made our own licensing scheme. Didn't use any third party software. Simple DES encryption should work for the kind of product we have.
I agree with the notion that there's no "100%" security. Anything that can be built, can be broken.

Anand H
Friday, May 17, 2002

Oh btw, there's this cool freeware product from Psychoticsoftware, specially for Java based products.
http://www.psychoticsoftware.com/products/guardian/index.html
I had tried this out, and it works pretty well!

Anand H
Friday, May 17, 2002

Whatever kind of security scheme you use (S/N, dongle,...), the first door visited for crackers is always the same : Where in you program do you call the license-check function.
You can have 128 bits encryption, a 68 digits prime number or a Hasp (Aladdin) dongle. The situation is the same : At the beginning of your program, if you have a call such as

if (LicenseFound())
  GoFullFeaturedMode();

then the hacker will simply have to find and patch your 'if'. No matter what kind of protection is behind.
So you have to be careful that this test is split out all over you code and threads. But here comes the bad news : Doing so forces you to go against all good programming practice (i.e. rules leading to maintainable code) :-(

One option to slow down hackers regarding this 'unique call' problem is to encrypt/compress the code. That way, even if the guy founds the entry point in the decrypted/uncompressed code at run-time, he will have a harder time to patch the crypted/compressed exe file.

But as mentioned in earlier posts, the matter is always about slowing down hackers, not stopping them.

Serge Wautier
Friday, May 17, 2002

Don't be so lazy! What I mean is:
If your software is bespoke, your customer base is probably small. Visit the customers, and personally install and configure the software for them. I used to do this by installing a multi-user dongle with server based software. You got to meet the users and sysadmins face to face which was very valuable.
If your software is more generic, the chances are there is plenty of competing software doing the same thing. You have to find the balance between reducing piracy, and making the software appealing by simplifying the install/use.

License management software is often used as an alternative to dealing face to face with customers. Get out on their turf, they are likely to thank you for it by buying in to your product; hide behind a license agreement and they'll take advantage of your impersonal approach.

TimG
Friday, May 17, 2002

So, FogCreek software uses Licence management?

Thanks for the warning, I'll be going elsewhere.

Bill, just don't need the hassle.

Bill Godfrey
Friday, May 17, 2002

Let's get one thing very clear: until you control the memory space, you WILL loose when it comes to obscuring or disabling something in software. In most comodity OSes, you DON'T control the memory space.

As many other posters have rightly pointed out, the right answer here is the one that maximizes your profit, not the one that keeps people from copying your code. As with most security systems deployed in a large way to end-users, the less involve ment they have with the system the better. Additionally, you can easily make the system untennable very easily by worring about the 3% of attackers that pose a real threat when in fact you can deal with their brand of expensive-to-prevent attack better through administrative or social controlls.

Worry about defending your castle from guys with trebuchets 'cause they're a heck of a lot more likely to attack you than the dragons you might be inclined to worry about.

Alex Russell
Friday, May 17, 2002

Low-tech almost always wins out over hi-tech.

pb
Friday, May 17, 2002

>> Low-tech almost always wins out over hi-tech.

That's why my company does all of its license managment on a chalk board.

Benji Smith
Friday, May 17, 2002

One of you mentioned that the crackers always go for the simplest way to crack a program, and so look for the i(!LicenseKey()) exit();

One good way around this that I have used effectively is to do something like this :

#define malloc(a) malloc((a)-(Licensed()?SomeAmmount:0))
(this is actually simplistic, the best is to put a mathematical expression that compares the license ID to the registered ID into the malloc. The compare is obviously easy to find and remove, but its pretty hard to 'reverse engineer' a mathematical expression from the assembly !)

Anyhow, what this will do is under-allocate memory when the application is not registered which will cause a crash at some later point in the application (which has no relationship to where the actual license check is made, making it even harder to crack.

On a more philosophical note, you should ask yourself the question of why copy protection is important to you. It is often not a simple as reducing the number of 'illegal' licenses out there.

People who are using an application on a non-professional basis are unlikely to pay for it since they are not deriving revenue from it. Their use of the application should be seen to you as 'free training' on it for a user. When that user then becomes employed and their employer recommends that they recommend an application to use for a particular task, if they know your application they will recommend it ... and their employer will purchase it. This is incidentally why software companies love giving truly amazing discounts to universities and schools; get people out there trained on your application and they are likely to buy it when they truly have a need for it.

I often see this much like the music industry, we certainly don't think that listening to the radio is piracy, for thet matter recording music off the radio is not considered picracy and neither is video-taping MTV ... Clearly music companies see these forms of music distribution as marketting as opposed to piracy, and in some ways I think that the copy protection issue with software is similar.

Inded, it's interesting that a number of companies in the market that I work in have started strongly pushing 'discovery' or 'learning eddition' versions of their applications for free or very minimal cost if they are not going to be used professionally. They know that the more users out there who know their applications, the more likely job adds are going to be asking for skills in those apps, the more likely managers are going to be choose those apps because its easy to get people who know them, etc... and the cycle goes on ...

One other small note on this point is that in the US, software training is a multi-billion dollar industry (the average companyt spends more on training than software purchases !). When considering which application to move a busniess to, training and existing knowledge of employees is often considered more importantly than the cost of the package. For example:
A fictional company called Calculators, inc. is using 'Super Cal 4D 1.0". A year goes by and a new version of "Super Cal 4D" is release, version 2.0. Unfortunately the upgrade price is $500 per seat. The IT manager looks around and finds that a competing package called "ArithPro 2.3" retails for only $100. Problem is that to retrain all 300 users of "Super Cal" is going to take 2 months and require a training company to come in. This training cost (and opportunity lost during training) alone would be probably cost more than 10x the $500 upgrade cost per user and so
"Calculators, inc" clearly sticks with SuperCal.

The point I am making is that users knowing an application is often more important to a customer than the cost of the application. Allowing users to use the product without a license is one means to this goal.

Now, don't think for a second that I am advocating piracy or the use of non-licensed applications; I am just stating the fact that there might be cases where the unauthorised use of your application might generate a revenue stream. As someone remarked above, very correctly, the goal of being in business is to maximize profits ... stopping any user from using an application without having paid for it first is not always going to acheive this goal (would you buy a car without a proper test-drive, money-back guarantee and warranty ?)

On the flip-side, the purpose of piracy protection is to avoid a user failing to purchase an application when they where in a position to otherwise do so. In my mind, casual piracy is the greatest cause of this. I have seen time and time again the hiring of an employee where the 'need to purchase the software license before the employee arrived' was clearly overlooked, and the idea of leaving the new employee without the ability to start training on the systems in use at the company was clearly not a very good idea, so an unlicensed version of the software was used but with the clear intention of purchasing a license at a future date (which then never happened.) The best way to combat this form of piracy is :
- Encourage users to use your application without thinking about licenses when they get started (this is to acheive 'lock in' as Joel calls it). After a period of time make sure that they
- Be realistic about the true problem that you have with piracy. If 50% of users of your application are using a non-registered copy, would all 50% of those purchase it if you stop their ability to use it? How many of those 50% might go on to purchase a copy at a later date when they have the means to do so?
- Price your application reasonably. If cutting the price by 40% causes 50% more users to purchase it (who might have been using it illegally) you are more profitable (assuming your raw costs are not a significant part of the sales price, which is rarely the case in software.)
- (An approach that I like a lot) Consider allowing all users to use your application for free until they get to the point that you consider that they are using it professionally. For instance in a database, allow people to create databases under 1000 records and have no limitations at all. The second they hit 1000 records they get a warning once an hour that they need to purchase the application (don't stop them from increasing their lock-in by expanding the databvase) ... guess what, they certainly don't want to convert their entire database and way of working to another application ... so the chances are that they will purchase yours!
- Give your customers a reason to purchase your application. Technical support, quick fixes to reported bugs, 'addon packs'.

Sorry for the long post. Keep up the good work and interesting site Joel, its a benefit to the community !
Andrew

ps. You have my vote for a spell-checker on this site !

Andrew Cross
Sunday, May 19, 2002

> #define malloc(a) malloc((a)-(Licensed()?SomeAmmount:0))

Well, first, it will slow down the application since you'll a license check every memory allocation, on many applications, that is *expensive* like hell.

Second, having the program crash on un-registered users is pretty bad, don't you think so? What kind of reputation will it give you?
No to mention the debugging problems that it may create.

Ayende Rahien
Sunday, May 19, 2002

Furthermore, if Licensed() is a subroutine call, the easiest thing to do is patch Licensed() so it always returns true.  I like the idea, though.

Alyosha`
Sunday, May 19, 2002

As far as I'm concerned, licencing ensures your product isn't sitting around in 100 warez sites available for the taking. This does rob you of serious revenue. Casual use isn't the problem.

And as others have pointed, the licencing will not provide complete protection, but at least it provides some.

Hugh Wells
Sunday, May 19, 2002

Very useful thread ... thanks to all who participated.

This is an interesting discussion about the pros and cons of using some type of license management. Many of the replies have been from the developer side. Hope you won't mind a voice from the "other side of the aisle"...

I've been involved with floating licenses since 1987 and have watched FlexLM improve and a number of other vendors come and go. I've consulted with vendors on how to get paid for the value they create and think there are certain applications that are just not worth managing the licenses because a). You want them to spread like wildfire and are willing to accept a small percentage of piracy as a cost of doing business; b). The customer doesn't have the wherewithal to do the administration; c). The business concept of value-pricing is not a driving force.

For companies that are serious about growth in revenues that serve companies that take their contractual responsibilities seriously, some type of license management is needed.

First the customer view then the vendor view...

Customers at the corporate level want to make good (in general) on the contracts they sign including purchases of software licenses. Unfortunately there is often a disconnect between the contract administration at the corporate level and application administration at the sysadmin level. There is sometimes a disconnect between the app admin and the use by end users.

The problem is this... Company XYZ signs up for 1000 licenses spread amongst 5 groups. The groups operate independently. When the application comes into the company, the licenses are spread around within the bounds of the 1000 license limit. Everything is OK...

Now the 5 sysadmins set everything up for their users. "New app available. Log on. We have 200 copies" and the word goes out.

When more than 200 users take down licenses what happens?

Typically nothing. The sysadmin doesn't know they need more licenses. The end user isn't alerted. The company thinks everything is OK.

If there is an audit by the software vendor, the company has a problem. When it is time to upgrade, all of the sysadmins and the company are in for a nasty surprise: The budget for upgrading the 1000 users needs to cover 1200 users instead.

Either the company negotiates a better deal with the software vendor (pay for 1000 upgrade licenses and get 1200) or 200 users are out of luck.

All of this could have been avoided if there was a simple alerting mechanism that either prevented or warned users and sysadmins that the number of authorized licenses were being exceeded.

Now what happens from the vendors side?... The vendor got hammered to do the 1000 license deal. The vendor loses some part of the the revenue from the extra  license use. The vendor gets hammered once again when it is time to do the upgrade deal.

What is hidden here (from the vendor's perspective) is the ability to talk with the customer about the license distribution that meet the customer's need. When the license limits are exceeded, the vendor has a chance to remind the customer of the value they are getting with the use of the software.

The vendor, by causing the customer to run out of licenses, has created an "impending event" that allow both parties to re-evaluate their business relationship moving forward.

Keep in mind a couple of things here:

First, license management (the function -- not the product instance like FlexLM) is needed for a company to ensure they comply with a vendor's terms and conditions. This can be done with paper but electronically is probably better and easier.

Second, license management can mean strict control (the n+1 user is locked out) or minimal control (the n+1 user is alerted and the log file goes records the "violation").

Finally, what a vendor does with this knowledge is up to them. The vendor can get quarterly or annual reports and charge full price more licenses (the "violations") or they can offer term licenses (30- 60- 90-day use licenses) or they can use the information during the next round of negotiations.

What I am saying is license management is not a binary choice or a technical decision. It is an important business decision (at least) and typically an important strategic decision that is often made without the full participation of all the groups involved.

You may want to check out the resources below. (Full disclosure: our firm developed the softwarepricing site.)

Other resources:

http://www.softwareCEO.com
http://www.SoftwarePricing.com/Articles/seven-steps.htm

Jim Geisman
Sunday, May 19, 2002

<<
So you have to be careful that this test is split out all over you code and threads. But here comes the bad news : Doing so forces you to go against all good programming practice (i.e. rules leading to maintainable code) :-(
>>

Look at AOP (Aspect Oriented Programming, e.g., AspectJ) you can easily distribute you licensing through your code without breaking your OO-ness. The idea is to encapsulate the treatment of the "Aspect", in this case -- license management, by keeping the aspect processing together and telling the system when to apply the aspcect code (e.g., on entry to every method call).

Amir Kolsky
Sunday, May 19, 2002

<<< The idea is to encapsulate the treatment of the "Aspect", in this case -- license management, by keeping the aspect processing together and telling the system when to apply the aspcect code (e.g., on entry to every method call). >>>

Which helps not, because if done this way, patching it amounts to patching just one "aspect" of the program.

Make licensing friendly, e.g., only warn if up to 20% overuse, or start to annoy at that time, but don't kill functionality. Big bussinesses (where the big money is) will comply for a variety of reasons, very highly ranked among them is fear of retaliation from disgruntled employees.

Licensing for the home market doesn't work at all - I've yet to see an example.

It's profit that needs to be maximized, and profit comes from happy customers. (Or strongarmed ones, but that's luxury reserved for monopolies).

Ori Berger
Sunday, May 19, 2002

We developed our own license system on a shrink-wrapped CRM system (over 100k seats sold).  The old system got cracked (after five years faithful service), and we finally updated our algorithms.  The old hand-crafted bit shifter/xor method wasn't that strong to begin with, so now we've started using proper crypto.  (DES is not that strong, 3DES is better).

We do multiple license checks inline in the code to prevent simple patching.  We also like to think of C++ assembler output as pre-encrypted. :-)

We also allow use for 30 days without a license.  After 30 days the software goes into read-only mode.  You can still use it, but you can't add any new info to the system.  I feel this is a fair trade-off between try-before-buy and actually generating revenue.  (Personally, I'd like to extend the 30 days to 90, in order to really hook the customer before taking away the supply.)

Ideally you might want to consider using a public key system together with a web service.  Each client has the web service public key, and before activation sends the license info to the web service.  The response is encrypted with the private key, and can thus be verified with the public key.  Note that you should only need to do this when you need to add licenses.  The license count (encrypted of course) goes into the shared db, and your clients just check the db.  That way you avoid requiring everyone be on-line.

Christian Mogensen
Sunday, May 19, 2002

I'm an engineer on a product called Lotus Notes.  With our product we've never used any copy protection scheme.  We currently have over 90 million licenses sold.  I believe a big part of our success stems from the ease at which the product can be deployed.  Many of our larger customers started out using it in a single small division, and it spread from there.  The hassles of copy-protection tend to inhibit this, both for legitimate and pirated use.

Think of your user base as a big pie.  The amount of money you get is related to both the size of your slice (percentage of users who pay) and the total size of the pie (all users). The mistake of many copy protection schemes is they try to increase your slice of the pie, but they neglect to keep the pie big.  Obviously, the proper goal is to maximize the amount of pie you eat.  If that means lots of people get away with piracy, then so be it.

I personally don't think copy protection has a place in shrinkwrap business software, because generally businesses want to be legal (even though they often aren't).  The more successful a business becomes, the more likely they are to pay you.  Regardless if a business becomes successful or not, if they choose competitive software because yours puts up roadblocks you lose anyway.  If yours is installed illegally then at least it has a chance of one day becoming legal, not to mention employees become famililiar with it and are more likely to recommend it if they change companies.

Damien Katz
Sunday, May 19, 2002

Just a follow-up to my suggestion of using #define malloc to help in copy protection. Some points ...

1) Obviously your 'licensed' routine does need to be quick. If it is not, you can do all sorts of things to make it, one secure way to speed it up is to use a static variable that is reset periodically another thread to avoid it simply being changed by a hacker at run-time.

2) Someone pointed out that you should not use a Licensed()?true:false kind of check. In my post I did say that this is a bad way of doing it. Much better to do something like
long LicenseResult=LicenseKey^RegistrationKey; (or some other check here that might produce a result that has some value -not a bool- if
long MemoryToReduceBy=((LicenseResult&0xff000000)>>24)+((LicenseResult&0xff0000)>16)+((LicenseResult&0xff00)>>16)+(LicenseResult&0xff));
return malloc(a-MemoryToReduceBy);

This is going to be really hard to reverse engineer for a hacker since it is going to put a mathematical expression inline for the malloc() and not have any true or false check. The hacker now has no way to simply 'doctor' a single routine in the code, but probably modify hundreds (thats why its a #define).

3) It is indeed bad to have your application 'crash' if a unregistered user is using it. However I would recommend that you have proper exception handling in all your code anyway ! Just put an additional license check in the code that reports exceptions to users to let them know that its probably because they are using an unlicensed copy.

4) Don't user copy-protection at all. Make users want to buy the software !

Andrew

Andrew Cross
Monday, May 20, 2002

<<< 3) It is indeed bad to have your application 'crash' if a unregistered user is using it. However I would recommend that you have proper exception handling in all your code anyway ! Just put an additional license check in the code that reports exceptions to users to let them know that its probably because they are using an unlicensed copy.>>>

Ahm.

This is exactly the kind of "bugs" (intentional in this case) that exception handling is NOT supposed to handle, and it's generally impossible to robustly handle.

However, you should have a "simple" license check upfront, and a relatively high probability to blow up within 30 seconds of actual program use.

That said, informational-only or total-lack-of licensing schemes are better for all - customers and producers alike. There are very few examples to the contrary, and many in favor.

Ori Berger
Monday, May 20, 2002

"Whatever kind of security scheme you use (S/N, dongle,...), the first door visited for crackers is always the same : Where in you program do you call the license-check function.
You can have 128 bits encryption, a 68 digits prime number or a Hasp (Aladdin) dongle. The situation is the same : At the beginning of your program, if you have a call such as

if (LicenseFound())
GoFullFeaturedMode();"

That's why you need to make multiple versions of "LicenseFound()" and make a call to one of these key validators for EVERY action the program takes.  It adds a lot of overhead to you app, but it gives the crackers a bigger headache.

Brad Clarke
Monday, May 20, 2002

So many excellent point and suggestions. Some of the noise was kewl too.

Thanks heaps people. If you have any more, then please add it.

Regs, James.

James Ladd
Tuesday, May 21, 2002

You might want to look at Concept Software, http://www.softwarekey.com .  The protection part is done using Protection Plus.  The Electronic License Management is done using the SOLO or Instant SOLO products.  They have been doing this 10 years and appear to be striving toward making the activation of software as painless as possible, which is key to retaining customers.

Ted

Ted Christiansen
Tuesday, May 21, 2002

1. Execution protection is easy to screw up !  You can easily offend your customers in fighting off the crackers.  You can also end up spending all of your time working on the security code.  Dont be surprised when you see your software on  news://alt.binaries.warez.ibm-pc  (saw ours this week !  twice !).  Go to  http://www.google.com/  and look for "crack" "your-company-name".  You might be surprised (and terrified - how do I feed my kids this week ?).

2. Find something that is easily repeatable on 98% of PCs.  We use a munge of the IDE hard drive serial number.  See  http://www.winsim.com/diskid32/diskid32.html  for info on how to get the hard drive serial number on Win9X / WinME / Win2K / WinXP.  Dont confuse this with the volume serial number. 

3. Use good encryption like twofish  http://www.counterpane.com/twofish.html  for your passwords.  Ours is 128 bits (32 chars of hex digits).  Yes, the customers scream having to enter 32 characters.  We used to use 64 bits (16 chars of hex digits) but they cracked it.

4. Make people send their Computer IDs to you for a testdrive password to be emailed to them.  You've gotta have complete control over the password generator in order to do this on a secure box (we use FreeBSD) so that the crackers cannot attack it !  See 
http://www.winsim.com/gen2wkps.html  for our password generation page.

5. Make sure that your testdrive passwords have start dates AND stop dates in them.  Keep track of what date that they run your software somewhere on their PC.  In fact, several somewheres.  Otherwise, they will roll the clock back on you.

Good luck, you're gonna need it !
Lynn McGuire

Lynn McGuire
Tuesday, May 21, 2002

Re: AOP and Patching Code

<< Which helps not, because if done this way, patching it amounts to patching just one "aspect" of the program. >>

Of course it amounts to pathcing just one aspect of the program! That's what we wanted to achieve!

Make the code run on entry to every method / function (or whichever combination of conditions you desire)...

The point is that you write it ONCE, in ONE place, and it gets incorporated into EVERY function call, automatically.

Amir Kolsky
Tuesday, May 21, 2002

Re: Timebombs

I wouldn't purchase software that has a timebomb in the (production) licence. Imagine the software company going bancrupt, or simply their licence renewal service having a few days downtime, while your business grinds to a halt.
If the software you're buying is of any importance to your company then you shouldn't be taking this kind of uncontrollable risk.

Anders Bengtsson
Wednesday, May 22, 2002

I am not a "peep!"

Not A Peep
Wednesday, May 22, 2002

<<Of course it amounts to pathcing just one aspect of the program! That's what we wanted to achieve!>>

Ahhm. I was referring to the _reverse_ action - patching the aspect OUT in order to REMOVE the copy protection. No free lunch here - if you can apply it in retrospect (one aspect or license check) you can remove it easily.

Ori Berger
Wednesday, May 22, 2002

Ori, I'm sorry to be so blunt, but you are dead wrong.

If I specify an AspectJ rule to add a piece of code on entry to every function (Which is a VERY simplified case of what you can do), that rule is applied by a pre-compiler to EVERY function in the program.

In order to remove it, you have to manipulate each and every assembly reference in the code.

You have 100 methods? That's 100 places to look...

Amir Kolsky
Thursday, May 23, 2002

I might be dead wrong, but I doubt it; It will make more work to create disassembler/decompiler tools that decompiles aspects, but eventually it will be there - Java bytecode is too regular.

You're invited to decompile any of your Java or Python files (using decompyle or Jode) and observe with horror that except for local loop variables and comments, they reconstruct the source intact.

13 years ago, I wrote a program that was able to automatically remove any "shell" around an executable, be it a virus, compression scheme, encryption scheme, etc. It did this by analyzing what the code actually did, run it several times, dumping memory to disk at various stages, comparing all of the images and eventually generating a "true image" that is both (a) a memory dump of the process after it has REALLY started running (past the outer layer of code), and (b) exhibits the same attributes as all of the analyzed images. This may sound extremely complicated, and it isn't simple, but it took no more than 6K of a DOS COM file (written in Assembly language) to achieve, and was nearly automatic - to the extent that 6 years afterwards, it still took me less than 5 minutes to apply it.

What protection/licensing schemes don't give in to automated analyzers? Those that are not automatically applied, or those with such random variety in application that they are for all practical analysis purposes independent. I haven't examined any AspectJ output code, but I suspect that without global bytecode optimization or optimized compilation to native code, it will be relatively easy to manipulate program aspects at the bytecode level.

Native code is significantly harder to manipulate, but technology is also advancing in that front - e.g. JiiTi and valgrind that both analyze and rewrite native x86 code on the fly.

Ori Berger
Thursday, May 23, 2002

>>> I wouldn't purchase software that has a timebomb in the (production) licence. Imagine the software company going bancrupt, or simply their licence renewal service having a few days downtime, while your business grinds to a halt.
If the software you're buying is of any importance to your company then you shouldn't be taking this kind of uncontrollable risk.  <<<

Excuse me?

Most enterprise contracts on any scale (which what you're describing would be if your business is grinding to a halt) have a couple of clauses in them.

First, you'd have a penalty clause if they couldn't relicense your software.  Besides, you should have started that process a month (or more) before it expired.  More if you're doing contract negotiations around it.

Second, why on earth wouldn't you have an escrow agreement for not only the licensing algorithms but proabably the application code itself if its that business critical?

You present a legitimate enterprise-software complaint, but one that was solved a very long time ago.

- - -

Having said that, my enterprise product doesn't currently have any form of strict licensing.  It is a pain to deal with, and in all fairness if anything did screw up it can be very expensive for any software vendor (assuming that their customers are larger than them and that there are some pretty stiff penalty clauses in the contracts).

Its hard.  Maybe a technical solution could work ... maybe a social one is better ... or maybe a combination?  You could do something like this though:

For a support call, have the reporting user execute a command on the installed machine.  This would return a data fragment (it can be long, cut-n-paste into email is fine here) that encrypts their product key, the current date, and the peak number of users (maybe even some more advanced distribution data).  This is required information before support can be given.  No enterprise customer is going to go long without support, after all.  If you find out that they are over their limit, you go ahead and support them anyway but pass that information on to your Sales team as an easy win.

Richard Stanford
Thursday, May 23, 2002

In general, as soon as crackers find the piece of code that checks serial numbers they can generate them.

To stop s/n generators, try encrypting/signing a company number with a private key (which is *not* included in the software for obvious reasons), and check the validity of the signature. This way, crackers can't generate numbers on the fly, forcing them to crack the software, leading to unmaintainablity/unrelaliability.

When you send out updates, check the programs (as you would normally, but with a gpg/pgp signature) to stop cracked programs being updated for free.

This way you can see where serial numbers have been leaked.

Better systems involve physically limiting the programs forcing thm to upgrade, i.e the limit of pages in citydesk,
the complxity of files in demonstration mode.

Thomas Figg
Tuesday, May 28, 2002

"I personally don't think copy protection has a place in shrinkwrap business software, because generally businesses want to be legal (even though they often aren't). The more successful a business becomes, the more likely they are to pay you. Regardless if a business becomes successful or not, if they choose competitive software because yours puts up roadblocks you lose anyway. If yours is installed illegally then at least it has a chance of one day becoming legal, not to mention employees become famililiar with it and are more likely to recommend it if they change companies. "

That's the spirit. The key for shrinkwrapped software is to generate "addiction", and the best way to do it is making access to their software easier, not harder.

Leonardo Herrera
Tuesday, May 28, 2002

'That's why you need to make multiple versions of "LicenseFound()" and make a call to one of these key validators for EVERY action the program takes. It adds a lot of overhead to you app, but it gives the crackers a bigger headache. '

If you're doing this much work,you've already losing more revenue than you'll gain.  Hackers have, for all intents and purposes, an infinite amount of time compared to you.

Jason McCullough
Wednesday, May 29, 2002

This discussion should really be seperated into high-volume business apps and low-volume apps since the rules of the game are different (volume=number of licenses per company).

My thoughts on high-volume:

Most companies are afraid of the license police. They usually want to pay but often get distracted by such issues as making money. The best way to get them to license correctly is to make it as easy as possible for them to comply with the law. IMO that means that you should do the auditing for them. Create a nice app that counts the number of users/installs/whatever and base your licensing directly on that. Let the app send a mail to an administrator when the company needs more licenses (and allow them to suspend the notifications for a temporary period!). Provide an easy way to upgrade the license. This way you turn adversity into comradery. "We help you doing business."

Stopping companies that really don't want to pay for all copies is usually a lost cause IMO. It might be a good choice to offend the paying customers with all kinds of copy prohibition measures if illegal usage is really getting out of hand. But remember that these are considered "negative" features. Everything you do to combat illegal copying will piss off legitimate users. That ranges from problems with losing license keys to apps that stop working after an upgrade, problems with working at home, dongles that don't fit between your PC and the wall, etc. For these products, the measures will usually have to be very annoying if they are to be effective.

My thoughts on small volume:

The chance that your application is cracked mostly depends on the audience for which it is written. Apps that are written for developers or a wide audience will get cracked if they are succesful. Don't even bother with the tools that crackers use themselves (disassemblers, debuggers, etc). On the other hand, if the application is only of interest to people without a clue about IT, it will be fairly save (unless the clueless father has a whizkid as son...). A simple protection mechanism might be a good choice there.

Of course, with this kind of software you have the same problem with losing business to users that want to pay, but get turned of by the licensing hassles. My humble opinion is that the best incentive to license is usually extra features. That can be a limit to the size of the project as was coined earlier, good support, manuals, access to training, access to prereleases and auto-updates. Always try to convince your customers to pay by positive measures, before you resort to policing. A good example of going about the wrong way are protected music CD's. Customers who would like to pay are pirating because the pirated copies provide better value. Those can be played in your computer, you can make (legal) backup copies, etc. Something similar is happening with games. Paying users are using and creating cracks so they can backup their CD's and can play without the CD in the drive.

PS. Don't forget that over 90% of the illegal copying you see on the Internet is by:
- Software hoarders (download, try, uninstall & burn to CD).
- 'Poor' students or foreigners.
- People who wouldn't have used the software if it they had to buy it.
PS 2. If people who copy your software illegally couldn't have afforded it (Photoshop for instance), you haven't lost a sale. This is a free form of advertising however. The student who used Photoshop in college will sell it to his boss a few years later. If illegal copying by these users is rampant, instead of protecting the software and not gaining many sales, why not start selling light or education versions of the software? That way these users will pay what they can afford.
PS 3. Illegal copying is not piracy. Piracy is a violent way to deprive one of it's property. You've still got the app after an illegal copy and nobody assaulted you. Please use proper terminology. Before we know it, Microsoft will start to compare using open source to supporting terrorism. Oops, they already did ;)

Wouter Zelle
Wednesday, June 05, 2002

<a hred="www.crypkey.com">Crypkey</a> is a product I have heard good things about. I have not used it myself, but if offers web-based sales and license activation for your users. So you distribute your app freely, but the user then buys the key through a site (not sure if it is your site or Crypkey's site...)

Jason Wood
Thursday, June 06, 2002

Hred? What the heck is that???

Here is the link: www.crypkey.com

Joel, can you make a preview? Hmm, looks like that wouldn't have worked anyway...

Jason Wood
Thursday, June 06, 2002

Sorry to waste space, but what does it take to make a hyperlink? One last try:

http://www.crypkey.com/

Jason Wood
Thursday, June 06, 2002

Wouter in his PS's pointed out some nice things.

When it comes to affordability of a software product I think most US companies tend to forget that the US dollar is a pretty high priced currency.

I'm located in Canada. A simple 500 *files* license for the excellent CityDesk would cost me Can. $121.00. That is half my budget for groceries for a month. I can't explain to my wife that my hobby site just set me back that amount of money. When (no, not if - when) I find a cracked version of CityDesk no-one has lost a sale from me because I can't afford it in the first place...

I run a lot of software I could never afford. And a lot of the programs which over time proof to be solid I do buy if possible (Forte Agent, Bulletproof/G6 FTP server, Movie Library, etc.). Besides that I promote those programs wherever I can -  because they not only deliver... they deliver for *me*: the small guy.

An idea to get people like me to 'buy' your app is to enable X monthly payments of X amount of dollars.

Btw, remember the phone-home-to-activate Windows XP? Everything can and will be cracked. Phone home? Firewall. "Yes but CityDesk has to connect to the net..." : publish locally and upload with a FTP program yourself.

<side note> CityDesk v1.0.23 (full) just got uploaded to me. Do I want the 'new' features that much that I lose so much groceries? ....hmmm, now what kind of license management could convince me of that?

PS: CityDesk is an excelent product with excellent, outstantind support... I'll be mentioning it around a *lot*

Ruud
Monday, June 10, 2002

There's a good article at Gamasutra from last year ( http://www.gamasutra.com/features/20011017/dodd_01.htm ) about the tricks the programmers on Spyro the Dragon used to help copy-protect their programs: certainly the most elaborate scheme I've seen documented, though I seem to remember that some parallel port dongles from a while back (probably still do) contained cheap Z80 processors, and had critical parts of the program actually running on the dongle (though presumably not *speed* critical parts <g>).  It's a topic that fascinates me from days of cracking game floppy protection on old games, but I've never had to devise such a a scheme myself, except for a pretty cheap serial number trick.

Matthew Bloch
Tuesday, June 18, 2002

I had a great experience back when I was support for Wind River System's license system.

We had a cumbersome home-grown tcl product rollout system.  This had a key.  The installed software also had keys.  Customers often confused the keys (because they looked the same) and there were multiple steps of sending things back and forth.  Most people in support didn't understand the system either.

I ended up being the point man on all licensing questions.

Node-locked licenses are generally a hole.  "Oh, we changed the IP address on the system, please send another key".  You simply can't have a 100% win here.

Floating licenses are generally a pain.  The license server has a termporary outage and no one can work, or someone misconfigures networking somewhere and everyone can't run their editor or compiler or whatever.

My favourite part of corporate licensing was when my company was SUED by Globetrotter (maker of FlexLM) because we decided not to use their licensing anymore.  We went with a competitor (now defunct) who made the Elan License Manager, which was a fair amount more friendly, although not without its own issues.  I certainly am unwilling to license software from a company with those tactics.


If you do any kind of licensing at all, do yourself a favor and take the user story, functional model, and information flow of licensing as seriously if not more seriously than that of the established functionality of your product. This includes painless installs, active advance notice of impending expiry, seamless integration with the support process, and so on.

No one's going to give you a medal for the best license manager implemenetation, but a flawed and problematic one is likely to earn you indignant customers who are uninterested in investing in further purchases, or who return the product upon evaluating it.

Joshua Rodman
Friday, July 26, 2002

Commercial.
We were also frustrated with FlexLM and the other commercially available software license management when we tried to use them with our product eXoDy (A program for automatically generating web-enabled database applications from XML business descriptions).  We ended  up rolling our own and including it with our software.  Our users liked the no-hassle license management so we decided to try making it available more widely.  You can get details from our website http://www.easylicenser.com/

Paul Offredi
Monday, September 09, 2002

Paul,

Thanks for the tip on EasyLicenser. We were looking for a license manager that wouldn't annoy our users with a license server, and EasyLicenser works well.

Dave

Dave Williams
Tuesday, December 10, 2002

SOME SITE KEYS  AND SITE CODES ARE GIVEN HERE . CAN YOU FIND OUT POSSIBLE MEANINGS OF THE SAME.
D4BF 8B84 6029 7863 04                                            
F546 719F 1F65 60D0 FF49 D68A 88    

                    
D9AC 6A7B 600D 6648 F2                
D0B9 530E D4F9 E7FE 0677 C79F 3F                                
D1A5 1202 6044 3C64 6C                    
D360 71F8 1636 3D06 08B8 1D3B 6B                                                                                                        
        

CHARUHAS P. KULKARNI
Saturday, February 22, 2003

Hi,
yes FlexLM is a pain however they are the only one, as far as I know who will cover windows AND UNIX.
there are new comers..but I have heard that products are full of bugs....like netquartz. I know a guy who moved from them because he was loosing customers...others are protexis with nTitles systems.

D. Dikinson
Monday, May 05, 2003

Software And Cracks For YOU !
Cracker@bk.ru

Cracker
Tuesday, June 17, 2003

Some of the comments here need to realise Licensing is not necessarily always about security or causing annoyance to end users, but to offer Vendors different, new and alternative ways to sell their products.  Therefore increase Revenues.

Personally I would not trust a half baked solution that 3 developers cooked up and is on version 1, in my new expensive software release.  Sometimes you pay for what you get and implementing a solution from a company with experience in the field of licensing can mean reduced disatisfaction from end users.  Price is not your number one priority thats all I can say!

Anon
Wednesday, September 24, 2003

Great discussion. We are mulling over some of these issues now: http://www.bloglines.com/blog/gterrill?id=2.

Gavin Terrill
Monday, July 12, 2004

*  Recent Topics

*  Fog Creek Home