Licensing to Kill

Could FLEXlm be one of the world's worst-designed programs?

They've just rechristened it FLEXnet Publisher, and I can only think it's to try to get away from existing FLEXlm stigmas.  It's so bad that according to a VMware engineer I spoke to on the phone a few months ago, in the next release of ESX (whatever the new name is going to be) they're ditching it to go back to their own serial-number based scheme, entirely because of a large amount of hugely negative customer feedback.  This is only one major release after they switched to it.

Let me describe the structure of it (if I were to go into the user interface issues, this would become far too long a post, so maybe another time).  There's a management daemon, called lmgrd, and vendor daemons.  These vendor daemons are (often along with the management daemon) provided to you, often without an installer and simply as a bunch of files.  There's also quite often a node-locking generator (based on things like hostname, MAC address, and all manner of things easily faked in a VM) provided to you by the vendors, which as far as I can tell is different for every vendor.  This is possibly so that they can build in their own criteria, but more likely because the FLEXlm people are lazy and can't be bothered to provide a comprehensive set of criteria on their own.

Now, why is there a vendor daemon and a management daemon?  Good question, and I don't know the authoritative answer, but from using it I can make an educated guess or two: either to allow vendors to validate some part of the licenses in their own manner, or to simply confuse and annoy the hell out of you.  See, the different vendor daemons are built against some version of the FLEXlm software, and they may, or may not, have been built against the same version.  This may, or may not, cause problems, including crashes.  It may explain why every time the license server reboots (thanks, generally, to automatic Windows updates), lmgrd fails to start up successfully.

Now, you can run multiple instances of lmgrd -- if you can figure out how to get it installed so that it starts up on bootup, since there isn't much in the way of help in the official help PDF, and only one of the three vendors whose licenses I deal with actually provided an installer (thanks, VMware, I'll be using your installer long after you've switched off of FLEXlm).  This lets you have each license under a different copy of lmgrd, perhaps so that you can attempt matching versions, but mainly so that if one of the lmgrd instances crashes, it will only take down that license.  (Actually, it's because in this configuration you need to run them on multiple machines, so if one machine goes down, most of your licenses stay up.  But I know what they really meant.)

Alternately, you can combine licenses into a single file, a process that the manual warns is time-consuming and error-prone.

Finally, you can simply have all your licenses be handled by a single lmgrd instance.  Now, this isn't really a bad idea, except for port numbers.

See, each vendor daemon needs to run on its own TCP port number.  You can specify the port number in the license file, except when you can't because some vendor hardcoded it into their software.  If you don't specify a port number in the license file, the vendor daemon will be given a port number starting at 27000 on up, giving you an address like 27000@mylicenses.thissucks.com.  Now, because everyone likes autoconfiguration, if in your program you leave out the port number (giving you something like @mylicenses.thissucks.com), then it will automatically search ports 27000 through 27009 for a matching vendor daemon.  Unfortunately, I haven't seen a single vendor product that doesn't puke on such an address, claiming it is invalid because of faulty validation, even when the FLEXlm manual in front of me says it's perfectly legal.

If you don't then modify your license files to specify ports (which you have to remember to do every time you get a new license file), then you better be aware of when the license server reboots, because the ports are given out in the order that the services come up.  So if you're in my situation, where the first of the vendor daemons always crashes the first time it tries to load on bootup, then the other two will have their normal ports decreased by 1.

I haven't even gotten to things like functions to reread license files that don't actually reread them, a UI that doesn't tell you if a server is running or stopped until you hit the buttons to try to run it or stop it, a status window that displays a large amount of license data in a tiny, non-resizable window, and more.  The product feels like it was developed in 1988 (it was) and is a study in market leader stagnation.  I would be very surprised if they have a single developer left and haven't fired everyone to just sit there and watch the money roll in.

If license servers are necessary for some product you're creating, there are other license servers out there that simply run on a well-known port and don't require any of this idiocy.  Unfortunately, in my experience I've seen more companies switch to FLEXlm than away from it. I hope this isn't an industry-wide trend.

Where's the KDE angle?  There isn't one specifically, other than this: if someone in the KDE community thinks this is a good design, or can see themselves designing such a scheme, please just leave.  Now.  (Don't worry, I'm sure this doesn't apply to any of you. )