Table of Contents * Previous Chapter * Next Chapter

FLEXlm End User Manual: Chapter 2 The License File

Chapter 2 The License File

This chapter explains the contents of FLEXlm license files including the following topics:

Specifying Location of the License File 8

License File Format 10

The Anatomy of a License File 17

Types of License Files 17

The license file contains all site-specific information required by FLEXlm. This information includes:

In general the license file, or a copy of it, must be accessible to every machine that runs a FLEXlm-licensed application, and each machine designated as a license server. Before you can use the application you have to start the license manager daemon (lmgrd) using the following syntax:

lmgrd [-c license_file_path] 			 (Unix and OS/2)
lmgrd -app [-c license_file_path](Windows/NT)

-c license_file_path
full pathname to the license file. Only use this option if the license file is not installed in the default location -/usr/local/flexlm/licenses/license.dat (Unix) or C:\flexlm\license.dat (Windows). See Section 2.1, `Specifying Location of the License File,' on page 8 for information about using alternate locations.

On VMS and Netware systems there is no lmgrd and the vendor daemon is run directly.

Section 2.1, `Specifying Location of the License File' and Chapter 3, `The License Finder' on page 19 discuss how applications find an appropriate license file.

2.1 Specifying Location of the License File

If your software vendor recommends a specific location for your license file, or if the default is not practical for you, use one of the following two methods to put the license file in another location:

If you are running the application on multiple nodes, you have three options for making your license file available on all the machines:

Since the vendor daemon keeps track of license usage, and since the license file contains encrypted data to protect it against modification, you may move and copy the license file as much as necessary.

You can only start lmgrd on the server node specified in the license file.

If you are running redundant servers, you should have one copy of the license file (as well as the binaries for lmgrd and the vendor daemons) on each server node. If you do not do this, you lose all the advantages of having redundant servers, since the node holding these files becomes a single point of failure.

No matter which option you choose, you must first install lmgrd (on Unix and Windows/NT systems) and the vendor daemon.

2.1.1 Setting the Path to the License File at Start-Up

On Unix systems, since it is prudent to avoid using root for commands that do not require root permissions, (and no part of FLEXlm requires root permissions) it is strongly recommended that lmgrd be run as a non-privileged user (not `root').

To start the license manager daemon (lmgrd) execute a command similar to the following.

% lmgrd_path -c license_file_path >& log_path &
$ nohup lmgrd_path -c license_file_path > log_pathname 2>&1 &

To start the lmgrd daemon automatically every time you reboot the license server add a line similar to the following to /etc/rc.boot, /etc/rc.local, or the appropriate startup file:

[username's login shell is csh:]

su username -c `umask 022; lmgrd_path -c license_path >& log_path&'

[username's login shell is sh:]

su username -c `umask 022; lmgrd_path -c license_path > log_path 2>&1 &'

username
non-privileged user (It's not recommended that lmgrd be run as root, for OS security reasons).
lmgrd_path
full pathname to the lmgrd executable.
license.dat
full pathname to the license file.
log_path
full pathname to the debug log file.

This will not start the daemon until you reboot your license server machine.

To start lmgrd on Windows/NT systems, you must add lmgrd to the list of available NT services. Please check the Control Panel's Services icon to verify the status of the server.

Because FLEXlm supports a large number of platforms, we can not describe all variations of system boot files in this manual. See your operating system's documentation for specific information about modifying startup files.

2.1.2 Setting the Path with an Environment Variable

Use the environment variable LM_LICENSE_FILE to set the location of the license file. For example in the C shell:

% setenv LM_LICENSE_FILE license_file_path

In the Korn and Bourne shells:

# LM_LICENSE_FILE=license_file_path
# export LM_LICENSE_FILE

In Windows 3.1, add the following line to C:\autoexec.bat:

SET LM_LICENSE_FILE=license_file_path

license_file_path
full pathname to the license file.

The `-c' option overrides the setting of the LM_LICENSE_FILE environment variable for lmgrd and other FLEXlm utilities like lmstat and lmdown. See Section 4.2.2, `Using Separate License Files on the Same Server Node,' on page 23 for more information about LM_LICENSE_FILE.

Some applications do not recognize the LM_LICENSE_FILE environment variable.

2.2 License File Format

License files usually begin with a SERVER line (or three lines for redundant servers) followed by one or more DAEMON lines, followed by one or more FEATURE lines. In some cases the license file requires no SERVER line and no DAEMON line. See Section 5.4, `Counted vs. Uncounted Licenses,' on page 28 for more information.

You can modify five data items in the license file:

Everything else is used to compute the license key, and should be entered exactly as supplied by your software vendor. All data in the license file is case sensitive, unless otherwise indicated.

In the following sections, options modifiable by the license administrator are italicized.

2.2.1 SERVER Lines

The SERVER line specifies the node name and hostid of the license server, and the port number of the license manager daemon (lmgrd). Normally a license file has one SERVER line. Three SERVER lines means that you are using redundant servers. The absence of a SERVER line means every FEATURE or INCREMENT line in the license file is uncounted. For more information about uncounted features, see Section 2.2.4, `FEATURE or INCREMENT Lines,' on page 11. License administrators do not have the option of deleting SERVER lines from a license file because the hostids from the SERVER lines are encrypted into the passwords on every FEATURE and INCREMENT line. For more information about redundant servers, see Chapter 5, `Selecting Server Nodes' on page 25. The format of the SERVER line is:

SERVER nodename id [port-number]

nodename
string returned by the Unix hostname or on some systems, uname -n command.
id
the string returned by the lmhostid command.
port-number
TCP port number to use. (Optional, but if not specified, then the FLEXlm TCP service must be present in the network services database.) The port number is usually specified.

Example:

SERVER enterprise 0122345 1701

2.2.2 DAEMON Lines

The DAEMON line specifies the daemon name and path. The format of the DAEMON line is shown below.

DAEMON daemon-name daemon_path [options_file_path] [PORT=port_num]

daemon-name
name of the vendor daemon used to serve some feature(s) in the file. This name cannot be changed by the administrator.
path
pathname to the executable for this daemon. Generally the license administrator is free to install the daemon anywhere. (It is recommended however, that it be installed on the same license server node as the lmgrd.)
options_file_path
full pathname of the end-user specified options file for this daemon. (See Chapter 6, `The Options File' on page 29.) FLEXlm does not require an options file.
portnum
Vendor daemon port number. NOTE: This is for firewall support only, and is otherwise not recommended. This requires a v5+ lmgrd.

Example:

DAEMON sampled /usr/local/sampled \
/usr/local/options/options.dat

`\' characters as continuation characters are only legal syntax in FLEXlm v3.0 and later. Previous versions required that each line in the license file fit on a single line.

2.2.3 USE_SERVER line (v5+ only)

USE_SERVER takes no arguments, and has no impact on the server. When the application sees USE_SERVER, it ignores the rest of the license file, and the checkout validation occurs at the vendor daemon. USE_SERVER is recommended since it improves performance, except for uncounted (`node-locked' or demo) FEATUREs, where you may want to avoid requiring a server. For these licenses, either leave out the USE_SERVER line, or put the uncounted licenses above the USE_SERVER line.

2.2.4 FEATURE or INCREMENT Lines

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 `incrementally' add licenses to a prior FEATURE or INCREMENT line in the license file.

Only the first 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 the vendor specified this) 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 is a rarely used option in FLEXlm which causes FEATURE lines to function as INCREMENT lines. This option is called ls_use_all_feature_lines. You will have to ask your vendor if they use this option. If they do, then all FEATURE lines behave exactly as INCREMENT lines.

A FEATURE line placed after another FEATURE or INCREMENT line will be ignored, unless ls_use_all_feature_lines is set.

The format for the FEATURE line changed in FLEXlm v3.0. The old format is understood by new clients and servers, but the new format is more flexible, and you will likely see it more often in the future.

Pre v3.0 format:

FEATURE|INCREMENT name daemon version exp_date #lic key `vendor_string' [hostid]

New format:

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]]

Nothing in a FEATURE/INCREMENT line is editable, except for values in the `name=value' pairs where name is all lowercase.

name
name given to the feature by the vendor.
daemon
name of the vendor daemon; also found in the DAEMON line. The specified daemon serves this feature.
version
version of this feature that is supported by this license.
exp_date
expiration date, for example, 7-may-1996. Note: If the year is 0, then the license never expires.
#lic
number of concurrent licenses for this feature. If the number of users is set to 0, the licenses for this feature are uncounted and no lmgrd is required but a hostid on the FEATURE line is required. See Section 5.4, `Counted vs. Uncounted Licenses,' on page 28.
key
license key for this FEATURE line. Two identical looking FEATURE or INCREMENT lines may have different license keys if the start dates are different.

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.

`vendor_string'
vendor-defined string, enclosed in double quotes. This string can contain any characters except a quote.
hostid
string returned by lmhostid. Used only if the feature is to be bound to a particular host, whether its use is counted or not. (Numeric hostids are case insensitive). See Appendix A, `' for more information.
DUP_GROUP=...
Duplicate Grouping parameter can be specified in the license in FLEXlm v4.0 and later. The syntax is:
              			DUP_GROUP=NONE|SITE|[UHDV]
        				U = DUP_USER
        				H = DUP_HOST
        				D = DUP_DISPLAY
        				V = DUP_VENDOR_DEF
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.
HOSTID=hostid
Same as hostid above, but in the name=value pair syntax (v3+ FLEXlm).
HOST_BASED[=n]
Hostnames must be specified in INCLUDE statements in the end-user options file, and the number of hosts are limited to #lic, or the number specified in `=n'.
ISSUED=dd-mmm-yyyy
Date issued.
ISSUER='...'
Issuer of the license.
NOTICE='...'
A field for intellectual property notices.
OVERDRAFT=nnn
FLEXlm v4.0 and later. The OVERDRAFT policy allows your vendor to specify a number of additional licenses which users will be allowed to use, in addition to the licenses they have purchased. This allows your users to not be denied service when in a `temporary overdraft' state. Usage above the licensed limit will be reported by the FLEXadmin reporting tool.
SN=serial_num
Serial number, used to identify INCREMENT lines.
SUPERSEDE
If this appears, all licenses issued before the date specified in ISSUED= are superseded by this line, and become ineffective.
USER_BASED[=n]
Users must be specified in INCLUDE statements in the end-user options file, and the number of users are limited to #lic, or the number specified in `=n'.
VENDOR_STRING=string
Same as `vendor_string' above, but in name=value pair syntax.
asset_info='...'
Additional information provided by the software end-user's license administrator for asset management.
ck=nnn
A checksum, useful with the lmcksum utility, which will verify that the license has been entered correctly by the end-user.
dist_info='...'
Additional information provided by the software distributor.
user_info='...'
Additional information provided by the software end-user's license administrator.
vendor_info='...'
Additional information provided by the software vendor.
Examples:
FEATURE xyz_app xyzd 2.300 31-dec-1997 20 1234567890 `xyz'
INCREMENT f1 demo 1.000 1-jan-0 5 12345678901234567890 		\
		HOSTID=INTERNET=195.186.*.* NOTICE='Licensed to XYZ corp'

2.2.5 FEATURESET Lines

The FEATURESET line is used to prevent FEATURE lines from being added to or removed from the license file. The format of the FEATURESET line is shown below.

FEATURESET daemon-name key

Nothing in a FEATURESET line is editable. Use the FEATURESET line exactly as it comes from your vendor.

daemon-name
name of the vendor daemon.
key
license key for this FEATURESET line. This key encrypts the keys of all features this daemon supports, so no FEATURE/INCREMENT lines can be removed, added to, or rearranged in this license file.

Example:

FEATURESET sampled 12345678

sampled
name of the vendor daemon
12345678
key generated by the vendor

2.2.6 PACKAGE Lines

The purpose of the PACKAGE line is to support two different licensing needs:

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 by your software vendor with a product, independent of any licenses. Later, when you purchase a license for that package, one or more corresponding FEATURE/INCREMENT licenses will enable the PACKAGE.

Example:

PACKAGE pkg_name vendor pkg_version pkg_key COMPONENTS=pkg_list \
			[ OPTIONS=pkg_options ]

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.
pkg_version
version of the PACKAGE. The enabling FEATURE/INCREMENT line must have the same version.
pkg_key
20-character license key.
pkg_list
list of components. The format is:
			feature[:version[:count]]
PACKAGEs 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:
			COMPONENTS='comp1 comp2 comp3 comp4'
			COMPONENTS='comp1:1.5 comp2 comp3:2.0:4'	
OPTIONS=SUITE
This is what distinguishes a suite PACKAGE from a PACKAGE used to ease distribution.
With OPTIONS=SUITE, the corresponding FEATURE of the same name as the package name is checked out in addition to the component feature being checked out.
If OPTIONS=SUITE is not set, then the corresponding FEATURE of the same name as the package is removed once the PACKAGE is enabled; and it is not checked out when a component feature is checked out.

Examples

	PACKAGE suite demo 1.0 20CHARKEYXXXXXXXXXX\
                        COMPONENTS='comp1 comp2' OPTIONS=SUITE
	FEATURE suite demo 1.0 1-jan-0 5 20CHARKEYXXXXXXXXXX

This is a typical SUITE example. You 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.

	PACKAGE suite demo 1.0 20CHARKEY COMPONENTS='c1:1.5:2 c2:3.0:4'
	FEATURE suite demo 1.0 1-jan-95 3 20CHARKEYXXXXXXXXXX SN=123

In this example, 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 for that component. The result is equivalent to:

	FEATURE c1 demo 1.5 1-jan-95 6 20CHARKEYXXXXXXXXXX SN=123
	FEATURE c2 demo 3.0 1-jan-95 12 20CHARKEYXXXXXXXXXX SN=123

2.2.7 UPGRADE Lines

UPGRADE name daemon fromversion version exp_date #lic key `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.

2.3 The Anatomy of a License File

The following example is a license file for single vendor with two features.

SERVER excellent_server		 17007ea8 	1700
DAEMON xyzd /etc/xyzd
FEATURE xyz_app1 xyzd 1.000 01-jan-1993 10 1EF890030EABF324 ""
FEATURE xyz_app2 xyzd 1.000 01-jan-1993 10 0784561FE98BA073 ""

The license file above would allow the license server excellent_server with the hostid 17007ea8 to serve 10 floating licenses for xyz_app1 and xyz_app2 to any user on the network.

2.4 Types of License Files

License files are created by the software vendor. License files can specify floating (concurrent) usage, node-locked (both `counted' and `uncounted'), and any combination of floating, counted and uncounted.

2.4.1 Floating (Concurrent) Licenses

A floating license means anyone on the network can use the licensed software, up to the limit specified in the license file. (Also referred to as concurrent usage or network licensing.) Floating licenses have no hostids on the individual FEATURE lines. This configuration requires an lmgrd daemon because the daemon is going to count the concurrent usage of the licenses.

An example of a license file that provides floating licenses is:

SERVER lulu 17001234 1700
DAEMON xyzd /etc/xyzd
FEATURE f1 xyzd 1.00 1-jan-95 2 key1 "" 
FEATURE f2 xyzd 1.00 1-jan-95 6 key2 ""
FEATURE f3 xyzd 1.00 1-jan-95 1 key3 "" 

This license file specifies that two licenses for feature `f1', six licenses for feature `f2', and one license for feature `f3' are available anywhere on the network that can access the license server `lulu'.

2.4.2 Node Locked Licenses

Node locking means the licensed software can only be used on one node. A node-locked license has a hostid on any FEATURE line that is node-locked to a particular host. There are two types of Node-locked licenses; uncounted and counted.

If the number of licenses is set to 0, then the licenses are uncounted and unlimited use is permitted on the specified node. This configuration does not require an lmgrd daemon because it is not going to count the concurrent usage of the features.

The following license file allows unlimited usage of feature `f1' on the nodes with hostids of 12001234 and 1700ab12:

FEATURE f1 xyzd 1.000 1-jan-95 0 key1 "" 12001234
FEATURE f1 xyzd 1.000 1-jan-95 0 key2 "" 1700ab12

If these were the only FEATURE lines in this license file, no lmgrd daemon would be necessary and you should not start one.

The following license file allows three licenses for feature `f1' to be run, but only on the node with hostid 1300ab43. (In this case, the daemons should be run on the same node that runs the software, since there is no reason to run the daemons on another node.)

SERVER lulu 1300ab43 1700
DAEMON xyzd /etc/xyzy
FEATURE f1 zyzd 1.00 1-jan-95 3 key "" 1300ab43

2.4.3 Mixed Node-Locked and Floating Licenses

Uncounted node-locked and concurrent usage licenses can be mixed in the same license file.

The following license file allows unlimited use of feature `f1' to be used on nodes 17001111 and 17002222, while allowing two other licenses for feature `f1' to be used anywhere else on the network:

SERVER lulu 17001234 1700
DAEMON xyzd C:\flexlm\xyzd.exe
FEATURE f1 xyzd 1.00 1-jan-93 0 key1 "" 17001111
FEATURE f1 xyzd 1.00 1-jan-93 0 key2 "" 17002222
FEATURE f1 xyzd 1.00 1-jan-93 2 key3 ""

This configuration does require an lmgrd daemon because it is going to count the concurrent usage of the two licenses on the third FEATURE line.

Table of Contents * Previous Chapter * Next Chapter