A license file consists of the following sections:
Optional license server section, with information about node where the SERVER (or redundant SERVERs) are running, along with a list of all vendor-specific DAEMON(s) that the SERVER needs to run. This section is required if any features are counted.
Features section, consisting of any combination of FEATURE, INCREMENT, UPGRADE or PACKAGE lines. This section is required.
Optional FEATURESET section, consisting of at most one FEATURESET line per DAEMON line in the file. This section is required for vendor daemons that use FEATURESET.
Comments. The convention is to begin comments with a `#' character. However, in practice all lines not beginning with a FLEXlm reserved keyword are considered comments.
Vendors and license administrators will read the license file to understand how the licensing will behave: what features are licensed, for how many users, whether these features are node-locked, if the features are demo or regular, etc. The options are very broad for what can be specified in a license file.
End-users often need to edit this file. Nearly all of the file is authenticated; if these portions are edited by the license administrator, a LM_BADCODE error will result. However, license administrators often must edit the license file for the following reasons:
Any amount of white space of any type can separate the components of license file lines, and the data can be entered via any text editor. Vendors can therefore distribute license data via Fax or telephone.
Only five data items in the license file are editable by the end-user:
hostnames on SERVER lines
port-numbers on SERVER lines
pathnames on DAEMON lines
options file pathnames on DAEMON lines
Decnet object numbers on DAEMON lines (VMS only)
 | Note: The SERVER hostid(s) and everything on the FEATURE line (except the daemon name) is input to the encryption algorithm to generate the license key for that FEATURE. |
A SERVER line specifies the node on which a license server process can run. If a license file has three SERVER lines, then two of the three servers must be running in order for the licensing system to operate. The SERVER node name in the license file can be any network alias for the node (prior to FLEXlm v2.4 it was restricted to the return of the gethostname() call).
SERVER nodename id optional-port-number |
| where: | is the: | |
| nodename | string returned by the UNIX hostname or uname -n commands. This can be edited by the license administrator. | |
| id | string returned by the lmhostid command. (Case insensitive). Alternate special hostids can also be specified here, including ANY, HOSTNAME=hostname, etc. | |
| optional-port-number |
|
| Note: The SERVER line must apply to all lines in the license file. It is permitted and encouraged to combine license files from different vendors, but this only works if the SERVER hostids are identical in all files that are to be combined. |
| Note: On VMS, the server node name can be entered with the trailing “::”, if desired, as is the practice of many VMS system administrators. |
The DAEMON line specifies the name and location of a vendor daemon, as well as the location of the end-user's options file.
DAEMON daemon-name path [options-file] |
| where: | is the: | |
| daemon-name | Name of the daemon used to serve some feature(s) in the file. | |
| path | Pathname to the executable code for this daemon. | |
| options-file | Pathname of the (optional) license administrator specified options file for this daemon. |
DAEMON xyzd c:\windows\system\xyzd.exe DAEMON xyzd c:\windows\system\xyzd.exe c:\opts\xyz.opts |
The DAEMON line on VMS has an extra field - the DECnet object number. The syntax for a DAEMON line on VMS is:
DAEMON daemon-name path [object] [options_file] |
| where: | is the: | |
| object | DECnet object number: 0 - daemon uses object number 0, task name is “name” from the DAEMON line. |
DAEMON xyzd du:[xyz]xyzd.exe 200 DAEMON xyzd du:[xyz]xyzd.exe 0 [xyz]xyz.opts |
| Note: If an options file is specified, the object number must be specified. |
A FEATURE line describes the license to use a product. An INCREMENT line can be used in place of a FEATURE line, as well as to add licenses to a prior FEATURE or INCREMENT line in the license file.
If the vendor daemon has ls_use_all_feature_lines set in ls_vendor.c, then FEATURE lines function as INCREMENT lines, and the behavior of a FEATURE line is unavailable to that application.
Only one FEATURE line for a given feature will be processed by the vendor daemon. If you want to have additional copies of the same feature (for example, to have multiple node-locked, counted features), then you must use multiple INCREMENT lines. INCREMENT lines form license groups based on the feature name, version, and node-lock hostid. If the feature name, version, and node-lock hostid (and optionally, the vendor string, if ls_compare_vendor_on_increment is non-zero) match a prior INCREMENT or FEATURE line, the new number of licenses is added to the old number. If any of the three do not match, a new group of licenses is created in the vendor daemon, and this group is counted independently from others with the same feature name. INCREMENT is not available for pre-v2.61 FLEXlm clients or servers. A FEATURE line does not give an additional number of licenses, whereas an INCREMENT line ALWAYS gives an additional number of licenses.
There are two formats for FEATURE; pre-v3.0 and current. The old format is still understood and correct with new clients and servers, but the new format is more flexible. The syntax of FEATURE and INCREMENT lines in FLEXlm pre-v3.0 is:
FEATURE|INCREMENT name daemon version exp_date #lic key \ "vendor_string" [hostid] |
The current syntax of FEATURE and INCREMENT lines (FLEXlm v4.0) is:
FEATURE|INCREMENT name daemon version exp_date #lic key \ [HOSTID=hostid][VENDOR_STRING="vendor-string"] \ [vendor_info="..."] [dist_info="..."] [user_info="..."] \ [asset_info="..."] [ISSUER="..."] [NOTICE="..."] [ck=nnn] \ [OVERDRAFT=nnn] [DUP_GROUP=NONE|SITE|[UHDV] |
The following fields are all optional (except for vendor-string in the old format). For optional fields of the “name=value” syntax, if the name is lowercase, it can be modified and the license will remain valid.
| where: | is the: | ||
| “vendor-string” | Vendor-defined string, enclosed in double quotes. This string can contain any characters except a quote (white space will be ignored in the vendor-defined string). The application can retrieve this string by calling lc_auth_data(). [Pre-v3.0 format] | ||
| hostid | String returned by lmhostid. Use if this feature is to be bound to a particular host, whether its use is counted or not. (Case insensitive). If the number of licenses is 0, then this field is required. If hostid is DEMO, the license is valid on any system. If DEMO, the application can determine this is a demo license by calling lc_auth_data() and noting the hostid type. All other special hostids are supported: DEMO, INTERNET=n.n.n.n, etc.[Pre-v3.0 format] | ||
| HOSTID=hostid |
| ||
| VENDOR_STRING=”...” |
| ||
| vendor_info=”...” |
| ||
| dist_info=”...” | Additional information provided by the software distributor. Not encrypted into the feature's license key. | ||
| user_info=”...” | Additional information provided by the software end-user's system administrator. Not encrypted into the feature's license key. | ||
| asset_info=”...” | Additional information provided by the software end-user's system administrator for asset management. Not encrypted into the feature's license key. | ||
| ISSUER=”...” | Issuer of the license. | ||
| NOTICE=”...” | A field for intellectual property notices. | ||
| ck=nnn | A checksum, useful with the lmcksum utility, which will verify that the license has been entered correctly by the license administrator. Not encrypted. | ||
| OVERDRAFT=nnn |
| ||
then you are in an “overdraft state”. | |||
| DUP_GROUP=... |
| ||
Any combination of UHDV is allowed, and the DUP_MASK is the OR of the combination. For example “DUP_GROUP=UHD” means the duplicate grouping is (DUP_USER | DUP_HOST | DUP_DISPLAY), so a user on the same host and display will have additional uses of a feature not consume additional licenses. |
To illustrate INCREMENT, the two feature lines:
FEATURE f1 demo 1.000 1-jan-0 4 .... FEATURE f1 demo 2.000 1-jan-0 5 ... |
would only result in 4 licenses for v1 or 5 licenses for v2, depending on their order in the file, whereas:
INCREMENT f1 demo 1.000 1-jan-0 4 .... INCREMENT f1 demo 2.000 1-jan-0 5 .... |
would result in 4 licenses for v1 and 5 licenses for v2 being available, giving a total of 9 licenses for f1.
To illustrate counted vs. uncounted licenses, the following FEATURE line
FEATURE f1 demo 1.000 1-jan-95 0 12345678901234567890 HOSTID=DEMO |
has unlimited usage on any hostid, requires no license servers (no SERVER or DAEMON lines) and is therefore a complete license file by itself. This FEATURE line also happens to be an “expiring” license and will not allow use of the FEATURE after 1-jan-95.
In contrast the following FEATURE line requires a vendor daemon named “demo” (and naturally a SERVER and DAEMON as well) and
FEATURE f1 demo 1.000 1-jan-0 5 12345678901234567890 \ HOSTID=INTERNET=195.186.*.* |
is limited to 5 users on any host with an internet IP address matching 195.186.*.*, and never expires.
UPGRADE name daemon fromversion version exp_date #lic code "string" [hostid]\ ck=nnn |
All the data is the same as for a FEATURE or INCREMENT line, with the addition of the fromversion field. An UPGRADE line removes up to the number of licenses specified from any old version (>= fromversion) and creates a new version with that same number of licenses.
For example, the two lines:
FEATURE f1 demo 1.000 1-jan-94 5 9BFAC03164EDB7BC0462 "" UPGRADE f1 demo 1.000 2.000 1-jan-94 2 1B9A30316207EC8CC0F7 "" |
would result in 3 licenses of v1.0 of f1 and 2 licenses of v2.0 of f1.
UPGRADE will operate on the most recent FEATURE or INCREMENT line (i.e., closest preceding FEATURE or INCREMENT line) with a version number that is >= fromversion, and < version.
Note that UPGRADE does not work for node-locked, uncounted licenses. A new FEATURE line should be issued in this case, since the license count is irrelevant.
If a user has UPGRADE lines for his license file and performs the following sequence:
start daemons WITHOUT UPGRADE lines in license file
check out old versions of software
add UPGRADE lines to license file
run lmreread
then he will have more checked out licenses of the old version of the software than the FEATURE/UPGRADE or INCREMENT/UPGRADE lines would normally allow. This license overdraft (of the old versions) will only exist for the life of the old processes.
The purpose of the PACKAGE line is to support two different licensing needs:
to license a product SUITE, or
to provide a more efficient way of distributing a license file that has a large number of features, which largely share the same FEATURE line arguments.
A PACKAGE line, by itself, does not license anything - it requires a matching FEATURE/INCREMENT line to license the whole PACKAGE. A PACKAGE line can be shipped with a product, independent of any licenses. Later, you can issue one or more corresponding FEATURE/INCREMENT licenses that will enable the PACKAGE.
PACKAGE pkg_name vendor pkg_version pkg_key COMPONENTS=pkg_list \ [ OPTIONS=pkg_options ] |
| where: | is the: | ||
| pkg_name | name of the PACKAGE. The corresponding FEATURE/INCREMENT line must have the same name. | ||
| vendor | name of the vendor daemon that supports this PACKAGE (VENDOR_NAME in lm_code.h). | ||
| pkg_version | version of the PACKAGE. The corresponding FEATURE/INCREMENT line must have the same version. | ||
| pkg_key | 20-character key generated by one of the license generators: create_pkg, lmcrypter, or the vendor's customized license generator. | ||
| pkg_list | the space separated list of components. Format each component is:
| ||
The PACKAGE must consist of at least one COMPONENT. version and count are optional, and if left out, their values come from the corresponding FEATURE/INCREMENT line. Count is only legal if OPTIONS=SUITE is not set - in this case the resulting number of licenses will be the count on the COMPONENTS line multiplied by the number of licenses in the FEATURE/INCREMENT line. Examples:
| |||
| OPTIONS=pkg_options |
| ||
With OPTIONS=SUITE, the pkg_name FEATURE is checked out in addition to the component feature being checked out. | |||
If OPTIONS=SUITE is not set, then the FEATURE of the same name as the package is removed once the PACKAGE is turned on, and it also is not checked out when a component feature is checked out. |
Example 1:
PACKAGE suite demo 1.0 20CHARCODEXXXXXXXXXX\ COMPONENTS="comp1 comp2" OPTIONS=SUITE FEATURE suite demo 1.0 1-jan-0 5 20CHARCODEXXXXXXXXXX |
This is a typical SUITE example. The user will have 2 features: comp1 and comp2, which are each version 1.0, with 5 non-expiring licenses available. When comp1 or comp2 are checked out, “suite” will also be checked out. The vendor will most likely want to turn on DUP_GROUP (either through the FEATURE line, or lc_checkout) so that the same user can use comp1 and comp2 while using only one license of the suite FEATURE.
Example 2:
PACKAGE suite demo 1.0 20CHARCODEXXXXXXXXXX\
COMPONENTS="comp1 comp2 comp3 comp4 comp5"
INCREMENT suite demo 1.0 1-jan-0 1 20CHARCODEXXXXXXXXXX\
HOSTID=12345678
INCREMENT suite demo 1.0 1-jan-0 1 20CHARCODEXXXXXXXXXX\
HOSTID=87654321
|
This is a good way to distribute multiple node-locked, counted licenses. Rather than requiring 5 INCREMENT lines per node, only one INCREMENT line is required per node, and the features are indicated in the PACKAGE line.
Example 3:
PACKAGE suite demo 1.0 \
COMPONENTS="comp1:1.5:2 comp2:3.0:4 comp3"
FEATURE suite demo 1.0 1-jan-95 3 20CHARCODEXXXXXXXXXX\
ISSUER=distrib1
|
The component versions override the FEATURE versions, and the number of licenses available for any component is the product of the 3 licenses for suite and the number of licenses of that component. The result is equivalent to:
FEATURE comp1 demo 1.5 1-jan-95 6 20CHARCODEXXXXXXXXXX\
ISSUER=distrib1
FEATURE comp2 demo 3.0 1-jan-95 12 20CHARCODEXXXXXXXXXX\
ISSUER=distrib1
FEATURE comp3 demo 1.0 1-jan-95 3 20CHARCODEXXXXXXXXXX\
ISSUER=distrib1
|
The FEATURESET line is required if ls_use_featset is set in ls_vendor.c. Otherwise, FEATURESET is unused.
FEATURESET daemon-name key |
| where: | is the: | |
| daemon-name | Name of the daemon used to serve some feature(s) in the file. | |
| key | License key for this FEATURESET line. This key encrypts the keys of all FEATUREs that this daemon supports, so that no FEATURE lines can be removed or added to this license file. |
The FEATURESET line allows the vendor to bind together the entire list of FEATURE lines supported by one daemon. If a FEATURESET line is used, then all the FEATURE lines must be present in the same order in the customer's license file. This is used, for example, to insure that a customer uses a complete update as supplied, without adding old FEATURE lines from the vendor.
| Note: The SERVER hostid(s) and everything on the FEATURE line (except the daemon name) is input to the encryption algorithm to generate the code for that FEATURE. |
Comment lines can begin with a `#'. Currently, all lines not beginning with a license keyword are comment lines. Therefore, typically, license files can be sent as e-mail messages.
The limits on names for the major parameters employed in the FLEXlm license file are:
| Host Names | 32 characters | |
| Feature Names |
| |
| Date String | 11 characters (dd-mmm-[yy]yy) | |
| License file lines (total) |
| |
| User Names | 20 characters | |
| DAEMON Names |
| |
| Version | 10 characters, in floating point format, maximum 3 decimal places, e.g., 123.456, or 2.10 | |
| All other parameters |
|
When using TCP, a single vendor daemon can support as many clients as the system limit for file descriptors and sockets, which varies from around 256 on sunos4 to 4000 on OSF/1 (SCO comes with a configurable default of around 8). While file descriptors are exhausted, additional vendor daemons are spawned to support the extra file descriptors. the maximum number of spawned daemons is 255, which effectively limits the maximum number of clients to 256*25 -(2* # servers -1) or approximately 6,400 per vendor daemon. When using UDP, there is no limit to the number of clients. Note that multiple daemons can be run on a single network, making the number of even TCP clients effectively unlimited.
This example illustrates the license file for single vendor with two features, and a set of three server nodes, any two of which must be running for the system to function.
SERVER pat 17003456 1700 SERVER lee 17004355 1700 SERVER terry 17007ea8 1700 DAEMON demo /etc/mydaemon FEATURE f1 demo 1.000 01-jan-96 10 1AEEFC8F90030EABF324 FEATURE f2 demo 1.000 01-jan-96 10 0A7E8C4F561FE98BA073 |
On UNIX platforms the license file default is:
/usr/local/flexlm/licenses/license.dat |
For Windows/NT systems, the default license file location is:
C:\FLEXLM\LICENSE.DAT |
For VMS platforms, the default license file location is:
SYS$COMMON:[SYSMGR]flexlm.dat |
Client applications get the license file location in the following manner (in order of precedence; lowest to highest):
Default location
End-user or application sets LM_LICENSE_FILE environment variable to path.
License finder.
LM_A_LICENSE_FILE_PTR set and lc_set_attr(LM_A_DISABLE_ENV,1), which makes the application override the LM_LICENSE_FILE environment variable.
License finder forced via FLEXLM_USE_FINDER environment variable.
Most FLEXlm utilities will accept a –c license_file_path option, in order to specify the license file.
The LM_LICENSE_FILE environment variable can be used to establish a new default location for the license file.
| Note: The –c option will override the setting of LM_LICENSE_FILE for all FLEXlm utilities such as: lmgrd, lmdown, lmstat etc. |
| Note: The FLEXlm daemons do not use the license file path; they will only process the first file in a license file path. |
In addition, client programs can process a series of license files by setting LM_LICENSE_FILE to a path, as in:
% setenv LM_LICENSE_FILE file1:file2:file3:....:filen |
Client programs will then try using file1; if it fails, file2 will be tried, etc.
When using a license file path on VMS systems, the license file names should be separated by the “ ” (space) character, rather than the “:” character that is used on UNIX or Windows systems. When assigning a license file path on VMS, use a command similar to the following:
$ assign "license_file_1 license_file_2 license_file_3" lm_license_file |
| Note: The quotes around all the license file names are required on VMS platforms. |
The license file does not need to be accessible on each client node; it can be read by the client from lmgrd. In order to do this, specify the license file as port@host, either in the LM_LICENSE_FILE environment variable or in your call to lc_set_attr(LM_A_LICENSE_FILE_PTR,...);
The syntax is:
port@host[,port2@host2[,port3@host3]] |
| where: | is the: | |
| port | TCP/IP port number (integer) from the license file | |
| host | Name of the server host from the license file. |
A non-redundant server would have only a single port@host, whereas redundant servers could be specified as 1, 2, or 3 sets of port@host, separated by commas. For example, if you have a single server node named “serverhost”, and you are running FLEXlm on port 1700, you could specify your “license file” as:
1700@serverhost |
You could have a license file path which looked like the following:
1700@serverhost:/usr/local/license.dat:1700@shost2 |
or, if the second server was a set of 3 redundant servers, the path might look like this:
1700@serverhost:1700@host1,1700@host2,1700@host3:1700@shost2 |
In this last example, the “1700@host1,1700@host2,1700@host3” part specifies a set of 3 redundant servers.
| Note: port@host is expensive in its use of networking resources and should be avoided with very large license files (longer than 250 lines) within slow wide-area networks, or extremely busy networks (heavy checkout traffic >1/second). |
| Note: Prior to FLEXlm v2.61, client and server could read different license files, however, after FLEXlm v2.61, both the client and server need to be reading the SAME license file, since the client passes the license key from the FEATURE line to the vendor daemon. |
FLEXlm uses different machine identifications for different machine architectures. For example, all Sun Microsystems machines have a unique integer hostid, whereas all DEC machines do not. For this reason, the Ethernet address is used on some machine architectures as the “Hostid”. An Ethernet address is a 6-byte quantity with each byte specified as two hex digits. Specify all 12 hex digits when using an Ethernet address as a hostid. For example, if the Ethernet address is 8:0:20:0:5:ac, specify “0800200005AC” as the hostid.
The program lmhostid will print the exact hostid that FLEXlm expects to use on any given machine. The following table lists alternate methods to obtain the required hostid for each machine architecture.
Integer hostids (used on Sun, SGI, HP, etc.) are normally hexadecimal numbers. However, a license file can take a decimal number if the hostid has a “#” prefix. Certain systems, notably HP uname and SGI, return decimal numbers by default, and this can make license file generation easier. Note that whenever a FLEXlm utility prints such a hostid, it always prints a hexadecimal number.
Hostids for Windows and Window NT systems is the serial number of the C: drive of the system by default. FLEXlm also supports a hardware key available from Globetrotter Software. For more details, see “Node Lock and Hostid for Standalone PCs”.
The VMS version of FLEXlm includes support for certain specified devices. For more information, see “VMS Ethernet Device Support”.
Hardware | Hostid | Type this command on the license serer: | Example |
|---|---|---|---|
Apollo | 20-bit node ID | lcnode -me | BE70 |
Convex | 32-bit hostid | getsysinfo |
|
DECstation | ethernet address | pfstat or arp hostname[a] | 080020005532 |
DG aviion | 32-bit hostid | /usr/sbin/systemid | 0C020972 |
HP | 32-bit hostid[b] | echo `uname -i' 16o p | dc | 778DA450 |
| Ethernet address | lanscan (use station address without leading “0x”) | 0000F0050185 |
| “id module”[c] | read ID typed on module, remove `A', and convert remainder to hex. | 118CD098 |
MIPS | 32-bit hostid | lmhostid | 170a3472 |
Motorola 88K | 32-bit hostid | lmhostid | 170a3472 |
NeXT | 32-bit hostid | hostid | 170a3472 |
RS/6000 | 32-bit hostid | unmae -m (returns 000276513100), then remove last 2 digits, and use remaining last 8 digitis | 02765131 |
SCO (Current FLEXlm) | Hostid String | unmae -x (returns SCO00354), then prefix with “ID_STRING=” | ID_STRING=SCO00354 |
SCO (FLEXlm pre v.3.0) |
| unname -x (returns SCO00354, then remove any non-hex proceeding letters from the serial number | 00354 |
SGI | 32-bit hostid | echo `/etc/sysinfo -s' 16o p | dc | 69022F72 |
SUN | 32-bit hostid | hostid | 170a3472 |
VAX/VMS | Ethernet address | ncpd | 0800200055327 |
VAX | Ethernet address | pfstat | 0800200055327 |
Windows | Ethernet | lmutil lmhostid | 0800200055327 |
| DISK_SERIAL_NUM —32-bit hostid | DIR C:\ (look for “Volume Serial Number is”, and remove `-') | DISK_SERIAL_NUM= |
| SENTINEL_KEY— 32-bit hostid | lmhostid -sentinel | SENTINEL_KEY=B285003 |
[a] The “arp hostname” (substitute the name of the desired host) command must be issued on another machine on the network, not on the target machine. Alternately, the ethernet address can be read at boot time on the machine console. [b] Default fo FLEXlm v3.0 and above only. [c] Only for HP300. The ID module is the default hostid for FLEXlm v2.21 | |||
FLEXlm contains a number of “special” hostid types which apply to all platforms. These hostid types can be used on either a SERVER line or a FEATURE line, wherever a hostid is required. These are:
| USER=name | Locks the software to UNIX user “name”. | |||
| DISPLAY=disp | Locks the software to display “disp”. | |||
| HOSTNAME=node |
| |||
| DISK_SERIAL_NUM=sn |
| |||
| ID_STRING=string |
| |||
| SENTINEL_KEY=sn |
| |||
| ANY | Locks the software to any node (i.e., does not lock anything) | |||
| DEMO | Similar to ANY, but only for use with uncounted FEATURE lines | |||
| INTERNET=nnn.n n.nnn |
|
FEATURE f1 none 1.000 1-jan-95 0 AB28E0011DA1F13C62B3\ HOSTID=HOSTNAME=globes |
or
FEATURE f1 none 1.000 1-jan-93 0 EB78201163B0CBBD6A07\ HOSTID=USER=joe |
FLEXlm allows you to specify your own vendor-defined hostid types. In order to do this, follow these steps:
Set up four routines to parse, retrieve, compare and print your hostid types:
int parse_id(HOSTID *id, char *hostid) HOSTID *retrieve_id(short idtype) int check_id(HOSTID *id1, HOSTID *id2)
and
char *print_id(HOSTID *id)
parse_id takes the input “hostid” character string and returns the structure pointed to by “id”. If successful, parse_id returns zero, otherwise non-zero value.
retrieve_id returns a pointer to a HOSTID struct after retrieving the hostid of type “idtype”.
check_id takes two HOSTID pointers, and returns 0 if they are different; 1 if they are the same.
print_id takes the input “id” struct and returns a pointer to the corresponding string. (Note: this string should be <= MAX_HOSTID_LEN bytes)
Define your hostid types, with values >= HOSTID_VENDOR (see lm_client.h in the /lmgr/machind directory).
Install your parsing and retrieval routines with lc_set_attr():
lc_set_attr(LM_A_HOSTID_PARSE, parse_id); lc_set_attr(LM_A_VENDOR_CHECKID, check_id); lc_set_attr(LM_A_VENDOR_GETHOSTID, retrieve_id); lc_set_attr(LM_A_VENDOR_PRINTHOSTID, print_id);
You should make sure that your hostid types do not use strings that could be confused with the FLEXlm standard hostids. For example, do not use “DEMO”, “ANY”, “USER=...”, “HOSTNAME=...”, or “DISPLAY=...”. Globetrotter Software recommends using strings of the form “TYPE=VALUE” where TYPE is your new hostid type, and VALUE is the value of the hostid. The ENTIRE string (including the “TYPE=” part) must be less than MAX_HOSTID_LEN bytes (currently 41). Do NOT use “X” or “x” as the first character of your hostid name, and do not use the double quote character (“) anywhere within your hostid.
For example, you might create a new serial number hostid type (to be contained in a “hidden” file). You might then use:
SERIAL_NUMBER=xxx (in your license file) |
You would define MYHOSTID_SERIAL_NUMBER (for use in your parsing and retrieval functions) as:
#define MYHOSTID_SERIAL_NUMBER HOSTID_VENDOR + 1 |
Finally, you would write parsing, retrieval, comparison and printing routines for the serial number, and call lc_set_attr() to make FLEXlm know about them. You should modify your vendor daemon, your application, create_license and lmcrypter to use your serial number routines.
Depending on the information in this file, the contents will be interpreted differently by FLEXlm. The license file supports network licensing, node locking, network licensing on a limited set of hosts, and demo/evaluation software.
The license file will determine whether a license server is needed. If all the FEATURE (or INCREMENT/UPGRADE) lines have a license-count of 0 (unlimited), then no server is needed. This type of license can be called uncounted. Alternatively, if any FEATURE lines have a non-zero license-count, then a server is required to count those licenses. If you want to implement license management without requiring a server, you must issue uncounted licenses. Uncounted licenses do not use any networking and can therefore be safely used on systems where networking is not available.
To provide floating licenses (i.e., concurrent usage), the license file is created with no hostids specified for individual features. This allows anyone on a network that can reach the server nodes to use the licensed software, up to the concurrent usage limit specified in the license file. This is the normal case, and an example of such a license file is:
SERVER sam 17001234 1700 DAEMON xxx /etc/xxx FEATURE f1 xxx 1.00 1-jan-92 2 code1 "" FEATURE f2 xxx 1.00 1-jan-92 6 code2 "" FEATURE f3 xxx 1.00 1-jan-92 1 code3 "" |
This license file would allow 2 copies of f1, 6 copies of f2, and 1 copy of f3 to be run anywhere on the network that could access server node “sam”.
Node locking (i.e., single node use), is provided by specifying a hostid on the feature lines that represent node-locked features. If the number of licenses is set to 0, then unlimited use on the specified host is allowed, and no daemons are required (the license file can not contain INCREMENT lines in this case.). The following license file would allow unlimited usage of feature “f1” on the nodes with host IDs of 12001234 and 1700ab12:
FEATURE f1 xxx 1.000 1-jan-90 0 code1 "" 12001234 FEATURE f1 xxx 1.000 1-jan-90 0 code2 "" 1700ab12 |
If a concurrent usage limit is desired on a single host, then daemons are specified as in standard floating licensing. To enable counted usage, simply set the number of licenses > 0. In this case, the SERVER and DAEMON lines must be present in the license file. The following license file allows 3 copies of feature “f1” to be run, but only on the node with hostid 1300ab43 (the daemons are configured to run on the same node that runs the software, since there is no reason to run the daemons on another node).
SERVER sam 1300ab43 1700 DAEMON xxx /etc/xxx FEATURE f1 xxx 1.00 1-jan-92 3 code "" 1300ab43 |
To provide network licensing on a limited set of hosts, use INCREMENT.
SERVER sam 17001234 1700 DAEMON xxx /etc/xxx INCREMENT f1 xxx 1.00 1-jan-0 2 code1 "" 17001111 INCREMENT f1 xxx 1.00 1-jan-0 2 code2 "" 17002222 INCREMENT f1 xxx 1.00 1-jan-0 2 code3 "" 17003333 |
In this example, feature f1 is separately counted for three separate hostids or nodes. Two uses on each are allowed.
To provide node-locked, uncounted licenses on one set of hosts, yet allow other licenses to float on the network, create a license file with some node-locked feature lines followed by a normal concurrent usage licensing feature line. It is important to put the node-locked lines first; otherwise users on the node-locked hosts will get the floating licenses first. In this case, you can use either FEATURE or INCREMENT lines.
For example, the following license file would allow use of “f1” on nodes 17001111 and 17002222, while allowing 2 other copies of “f1” to be run anywhere else on the network:
SERVER sam 17001234 1700 DAEMON xxx /etc/xxx FEATURE f1 xxx 1.00 1-jan-92 0 code1 "" 17001111 FEATURE f1 xxx 1.00 1-jan-92 0 code2 "" 17002222 FEATURE f1 xxx 1.00 1-jan-92 2 code3 "" |
Demo/evaluation software is provided by setting the expiration date to the end date desired; the vendor-defined field can be used to turn off certain product features. Demo software only operates in “node-locked, uncounted” mode with the word “DEMO” replacing the node ID; thus demo software can run on any node. An example of a license file that supports DEMO software is:
FEATURE f1 xxx 1.00 1-jan-92 0 code1 "" DEMO |
You can check if the currently checked-out feature is using a DEMO license via the following code:
CONFIG *conf; conf = lc_auth_data(feature); /* feature is currently checked out */ if (conf && conf->id.override == DEMO_SOFTWARE) /* it's a DEMO feature */; |
Of course, you are always free to implement demo software in any manner you choose, for example, by using the vendor-defined string.