Article: 295 of comp.software.licensing Newsgroups: comp.software.licensing Path: senator-bedfellow.mit.edu!enterpoop.mit.edu!gatech!purdue!mentor.cc.purdue.edu!mab From: mab@mentor.cc.purdue.edu (Mike Brown) Subject: Looking for License Manager (requirements etc.) Message-ID: Organization: Purdue University Computing Center Date: Wed, 7 Apr 1993 00:22:39 GMT Lines: 396 We (Purdue University Computing Center) run a large instructional lab network consisting of one (soon to be two) IBM RS/6000 AIX file server serving PC and Mac clients via NFS. The PCs run Beame & Whiteside's BW-NFS and the Macs run InterCon's NFS/Share. After the installation of a few more labs this summer, we'll have more-or-less 900 PC and Mac clients in 35 different labs. These clients are scattered across 8 subnetted Class B subnets which are connected by NSC routers configured to do IP-only routing. We're currently running a home-brew license management scheme on the PCs that worked reasonably well in its early days, when we had many fewer clients and much less licensed software to administer. But with increased loads, it's not working well any more. There appears to be little we can do to make it scale up better, so we're planning to replace it with a new system that will work better under heavy loads. We'll develop the new license manager ourselves, if need be. But we'd prefer to find one already available (either commercial or freeware) at reasonable cost that will suit our requirements. I've put together a requirements document (attached) outlining what we're looking for. I'd appreciate it if the experts or other interested parties listening in on this newsgroup would: - Let me know of any available license managers that come anywhere close to meeting these requirements. - Comment on requirements I might have missed. - Share their experiences on problems and solutions encountered in the development of license manager systems. - Share their requirements for license management in their own shops. Is there a FAQ or vendor contact list available? I'd like to contact vendors who may not follow this newsgroup to see what products they may have available. Thanks very much for any comments etc. you may have. Mike Brown, Network Systems Programmer Internet: mab@cc.purdue.edu Purdue University Computing Center Bitnet: xmab@purccvm 1408 MATH, Room B18 Phone: (317) 494-1787 West Lafayette, IN 47907-1408, USA Fax: (317) 494-0566 License Manager Requirements Mike Brown, Purdue University Computing Center OVERVIEW ======== This document outlines the requirements for a software license management system. It does not address the design or implementation of any specific system to address those requirements. A glossary of terms appears at the end of this document. LICENSE SYSTEM ENTITIES ======================= For the sake of discussion, we assume the license system to be composed of the following functional entities, each with distinct tasks: Code Name Description and/or Functions LM License Manager The licensing system as a whole, composed of the various functional entities and their configuration files. LMS LM Server Grants licenses, maintains global status info, logs transactions, monitors user clients, recovers idle & expired licenses. LMUC LM User Client Requests & returns licenses for users, allows access to apps on license grants, displays error & status messages to users. LMAC LM Admin Client Interacts with LMS for administrative functions, accepts command line and/or interactive commands from administrator. These should be thought of as functional entities, not physical entities. Actual license system implementations may map each functional entity into an arbitrary number of programs on one or more sytems. Actual entities may be "normal" application programs, inits, TSRs, device drivers, daemons, etc. Each of these functional entities may interact with any or all of the other entities to meet the requirements of the license system. REQUIREMENTS ============ The requirements listed herein are divided into four groups and labelled accordingly: Required These requirements are absolutely critical to the operation of a license manager in our environment and must be satisfied before initial deployment.. Desired These requirements, while not absolutely critical to the operation of a license manager, are highly desirable. These need not be satisfied before initial deployment, but should be serious candidates for future enhancements. Someday These requirements are thoughts for the future, items that would enhance the capabilities, utility, or administrability of the license manager. These should also be candiates for future enhancements, but at a lower priority than the "desired" requirements. Blue Sky These requirements are low priority thoughts for the future, things that would be nice to have but probably not worth investing a lot of effort. These are things we might do in the course of satisfying other requirements if there is only minimal extra effort involved. Supported Platforms ------------------- (Required) An LMS implementation is required for RS/6000 AIX 3.2 systems, running nfsd and bwnfsd 3.0. (Required) LMS must provide simultaneous support for LMUC and LMAC clients running on all supported client platforms. (Required) LMUC implementations are required for PCs running MS-DOS 6.0 with or without Windows 3.1, using BW-NFS 3.0. (Required) An LMUC implementation is required for Macs running MacOS 7.1. (Required) An LMAC implementation is required for RS/6000 AIX 3.2 systems. User friendly screen-oriented interfaces are nice, but we must also be able to do all administrative tasks via slow dialup lines connected through modems to standard terminals or terminal emulators running on PCs and Macs. (Required) LM components should be independent of platform, OS, and file system technologies to the greatest extent possible. (Desired) LMAC implementations for PCs running MS-DOS 6.0 with or without Windows 3.1, and for Macs running MacOS 7.1. (Someday) LMUC implementations for Windows NT, Unix, and/or OS/2 clients. Communications Protocols ------------------------ (Required) All network communications are to use IP-based protocols. (Required) Reliable client-server communications is required, either through the use of reliable network protocols or through reliability built into the LM entities. (Required) Network traffic analysis facilities are needed that understand the protocols used by LM components for inter-machine communications. (Desired) LMUC should conform to LSAPI specs as these stabilize. (Desired) All state-changing operations should be idempotent. Access Restrictions ------------------- (Required) LM restricts usage of administered entities resident either on a central file server or on a local disk. (Required) Administered entities may or may not be copyable, but should not be usable without a ticket issued to the client. (Required) LM supports an independent set of license limits for each administered entity. (Required) LM supports license limits based on total license counts. (Required) LM must support license limits based on clients and client groups, e.g. labs. (Required) LM access controls must be difficult for non-administrative users to circumvent. (Required) LM must be able to reliably identify clients in order to enforce client and client group (e.g. lab) based access restrictions. (Required) LM must be able to reliably identify users in order to enforce user and user group (e.g. course or department) based access restrictions. (Required) LM components must agree on the current date & time in order to enforce date and time based access restrictions. LM components must monitor and detect time syncronization problems, though the resyncronization process may be external to LM. (Desired) LM restricts access to entities which are either active (applications) or passive (data files). (Desired) LM supports prioritized license limits based on user/client groups. With this we could implement policies like giving ENGL 101 students higher priority to Mac Word, but still allow other users to use it without locking them out entirely. Or we could allow outside users to use software which was primarily acquired for our own administrative use but make sure it was available when we need it. (Desired) LM must support license limits based on users and user groups, e.g. 30 copies of Mac Word reserved for ENGL 101 students, regardless of what lab they may be using. (Desired) LM must support license limits based on day/time combinations, e.g. a 2 hour limit on Windows Excel during peak times Monday-Friday 1400-1800. (Desired) LM must support reservations based on client/day/time combinations, e.g. 30 copies of AutoCAD for use in the AGAD lab on Monday/Wednesday/Friday 10:30-12:20. (Desired) LM supports the issuing of tickets with limited or unlimited lifetimes. The decision as to whether a ticket issued should be of limited vs. unlimited lifetime may be affected by a number of factors. Factors may include client/user identity, impending reservations, license limits, general policies, etc. (Someday) LM supports cross-platform license limits, e.g. with 40 copies of (Mac + PC) Excel, could issue x Mac Excel tickets when 40-x PC Excel tickets are in use. Access Procedures ----------------- (Required) LM must recognize and arbitrate client attempts to access administered entities. (Required) When a client attempts to use an administered entity, LM must decide whether or not to issue a ticket and what type of ticket to issue. (Required) If LM refuses to issue a ticket, an error message must be returned to the user informing the user of why no ticket was issued and other relavent information. (Required) LM revokes tickets when they expire. (Required) LM revokes non-expired tickets as needed to honor ticket reservations. (Required) LM monitors client activity and salvages tickets held by clients presumed to have been idle for an excessive time. (Required) Holders of revoked tickets will be requested with increasing frequency to release administered entities, to the point where the increasing annoyance makes it difficult or impossible to comfortably continue to use the entity. LM will not force the release of administered entities to ensure it's not the cause of lost work. (Required) LM monitors connectivity with ticket-holding clients and salvages tickets held by clients presumed to have died. (Required) If connectivity is lost with ticket-holding clients, salvaged tickets should continue to be honored for a reasonable period following the return of connectivity. Clients must reassert their claim to the entity within a reasonable time. (Desired) If LM refuses to issue a ticket based on an exceeded license count, the user/client should be queued for receipt of a ticket at some time in the future. User should be allowed to wait on queued ticket or bail out of the ticket queue at any time prior to the issuance of the ticket. (Desired) Users waiting on queued tickets should be able to proceed with other work while waiting. (Desired) Users should have the option of waiting for queued tickets and having their app start up automatically when a ticket is available, without further user action required. This makes it a whole lot easier to deal with these delays in compiler makefiles and batch files. Administrative Procedures ------------------------- (Required) There must be a generic and easy to perform administrative procedure for taking a virgin entity and putting it under administrative control. There may be a different procedure for each entity class, but all entities of a single class should be placed under administrative control using the same procedure. (Desired?) The process for putting an entity under administrative control should be reversible by the LM administrator, but not by users. Performance and Limits ---------------------- (Required) LMS must be able to support an arbitrary number of administered entities. (Required) LMS must be able to support 1000 or more user clients simultaneously. (Required) LMS must be able to field 20 simultaneous ticket issue requests. (Required) Successful ticket issue processing should not delay startup of administered applications by more than two seconds. (Desired) Administered entities should function normally when network connectivity is lost between LMUC and LMS. Lab-resident backup LMS? Configuration ------------- (Required) All configuration information must be kept in an easily maintained format. (Desired) Configuration changes may be made dynamically without losing previous status. Activity Logging and Data Collection ------------------------------------ (Required) All state-changing transactions are to be logged. Other transactions that do not alter state (status requests, tickles, etc.) may be logged at administrator's option. (Required) LMS current state is to be available to LMAC at all times in sufficient detail to allow LMAC to produce dynamic displays of time-critical information for emergency problem diagnosis. (Required) LMS transaction logs should be detailed enough to produce detailed historical usage etc. reports. LMS not required to produce historical reports; this can be done by other programs, e.g. SPSS or SAS. GLOSSARY ======== Administered entity Program and/or data to which access is controlled by LM. Client A single computer that interacts with LM. Client group A possibly related group of client computers, e.g. some or all computers in a lab or department. Entity class The type of entity, e.g. DOS application, Windows application, Mac application, data file, etc. Express ticket A limited duration ticket. Express tickets expire and become invalid in a relatively short time frame. LM License Manager. The entire collection of software and associated files designed to satisfy these requirements. See the License Manager Entities section of this document. LMAC License Manager Administrative Client. See the License Manager Entities section of this document. LMS License Manager Server. See the License Manager Entities section of this document. LMUC License Manager User Client. See the License Manager Entities section of this document. Revoked ticket A ticket which is no longer valid due to administrative policy, e.g. time expired, ticket needed to satisfy prior reservation, etc. Salvaged ticket A ticket which is no longer valid due to non-administrative reasons, e.g. idle/dead client, network connectivity problems, etc. Ticket An authorization for a specified user on a specified client to user a specified administered entity. Tickets may be of limited or unlimited duration. User A human user of an administered entity, probably identified via a server login and password. User group A group of users, probably identified via server accounting groups. Could be the students in a course, users in a department, etc. -- Mike Brown, Network Systems Programmer Internet: mab@cc.purdue.edu Purdue University Computing Center Bitnet: xmab@purccvm 1408 MATH, Room B18 Phone: (317) 494-1787 West Lafayette, IN 47907-1408, USA Fax: (317) 494-0566