In 1997 the Los Angeles County Sheriff's Department (LASD) was in the process of opening a new jail facility called the Twin Towers. In order to allow PCs in the jail to access a mainframe-based application called the Automated Jail Information System, the Sheriffs needed a terminal emulation program. Managers for the LASD data network chose Wall Data's Rumba and purchased licenses for 2,000 copies, far more than they would initially need for the Twin Towers.

If you're an IT manager, you won't be surprised to learn that the LASD soon decided to include Rumba as part of its drive image - its standard set of system and application software that could be copied onto the hard disks of new or repaired systems. Not only did this significantly speed up the painfully slow machine-by-machine install process for Rumba and other applications, but it eliminated many of the install errors and integration issues that could occur as well. Of course, employing drive images in software deployment can also lead to using more copies of a program than you have licenses for, but on that score the Sheriffs had reason to think they were covered.

After all, this was a jailhouse, so security was not just a top priority - it was everything. And the mainframe database that Rumba was being used to access contained all manner of sensitive information, from the gang affiliation of prisoners to whether they'd served as informants. A system for keeping tight control over who could access what information, and from where, had been in place long before PCs started replacing the dumb terminals. As part of this security system, "Logical Units" (LUs) were assigned to specific PCs. A PC that had not been assigned an LU could not access the mainframe, so "ghost" copies of Rumba on such systems couldn't be used.

LASD officials claim they were quite open with representatives of Wall Data about Rumba being part of their baseline drive image and that they were using the LUs to limit how many copies of Rumba were in use. (Some PCs were set up to use a version of Rumba to access an accounting application on a Unix server as well.) But just how much Wall Data was told about LASD's software deployment and at what point is a matter of dispute. And while there's no record that anyone from Wall Data had any problems with the LASD's approach, neither does the LASD have anything in writing from Wall Data indicating that what they were doing was OK.

By now you've probably figured out how this story is going to end, even if my piece from yesterday didn't already give you enough of a clue. In 2000, a struggling Wall Data was acquired by NetManage, Inc. The next year, in a meeting with NetManage sales staff, LASD officials explained about the baseline images and the LUs. By this time, LASD had paid for a total of 3,663 licenses but through the drive imaging Rumba had been loaded on 6,007 systems. NetManage insisted that LASD must pay for licenses for all the copies, unused or not. LASD removed all the ghost copies and refused to pay. Settlement talks ensued, but the parties failed to reach an agreement -- a decision I would be willing to bet both organizations regret now. After all, once the lawyers ride into town in a story like this, they're the only ones with a chance at a happy ending.

But it is now in the hands of the lawyers, so in my next weblog entry, we'll take a look at how the courts have handled the case of Wall Data vs the Los Angeles County Sheriff's Department. It is a complicated case that raises many issues, so - whichever side you may be inclined to view as the wronged party here -- you might want to suspend judgement until then.