License File Format

License files usually begin with a SERVER line (or three lines for three-server redundant servers) followed by one or more VENDOR lines, followed by one or more FEATURE or INCREMENT lines. In some cases the license file requires no SERVER line and no VENDOR line.

8-bit Latin-based characters are fully supported in license files, options files, log files, and FLEXenabled application environments.

License File Syntax

Sample License File

SERVER my_server 17007ea8 1700
VENDOR sampled
FEATURE f1 sampled 1.000 01-jan-2005 10 SIGN=9BFAC0316462
FEATURE f2 sampled 1.000 01-jan-2005 10 SIGN=1B9A308CC0F7

The license file above allows the license server system "my_server" with the hostid "17007ea8" to serve ten floating licenses for each feature, "f1" and "f2," to any user on the network.

SERVER Lines

The SERVER line specifies the host name and hostid of the license server system and the TCP/IP port number of the license server manager (lmgrd). Normally a license file has one SERVER line. Three SERVER lines mean that you are using a three-server redundant license server system. The absence of a SERVER line means that every FEATURE and INCREMENT line in the license file is uncounted.

The hostids from the SERVER lines are computed into the license key or signature on every FEATURE and INCREMENT line. For this reason, make sure you keep SERVER lines together with any FEATURE/INCREMENT lines as they were sent from the vendor.


Field	Description
`host`	The system host name or IP address. String returned by the UNIX `hostname` or `uname -n` command. On NT/2000/XP, `ipconfig /all`; on Windows 95/98/ME, `winipcfg /all` return the host name.
`hostid`	Usually the string returned by the `lmhostid` command. This is changed only by your software supplier.
`port`	TCP/IP port number to use. A valid number is any unused port number between 0 and 64000. On UNIX, choose a port >1024, since those <1024 are privileged port numbers. If no TCP/IP port number is specified, one of the default ports in the range of 27000 and 27009 is used. SERVER lines specifying servers in a three-server redundant license server system configuration require a port number to be specified; Macrovision recommends using port numbers outside the range of 27000 through 27009.
`PRIMARY_IS_MASTER`	For a three-server redundant configuration, indicates how master control is transitioned between the primary and secondary servers. If set and the primary server goes down, the secondary server becomes the master and transitions control back to the primary server as soon as it comes back up. If not set and the primary server goes down, the secondary server becomes the master and remains the master even when the primary server comes back up. If both primary and secondary go down, licenses are no longer served. In no instance does the tertiary server become the master. This parameter is optional and is placed on the first SERVER line in the license file. You must be running a v10.8 vendor daemon to use this parameter.
`SERVER_TIMEOUT=seconds`	For a three-server redundant configuration, indicates how long a server waits to receive a heartbeat from another server in the configuration before shutting itself down. `seconds` is used in the following equation to calculate the timeout: timeout = (3 x `seconds`) + (`seconds` - 1) If not specified, the default value for `seconds` is 20, equating to a timeout of 79 seconds. Valid values for `seconds` are `0` through `120`. This parameter is optional and is placed on the first SERVER line in the license file. You must be running a v10.8 vendor daemon to use this parameter.

Three-Server Redundant Configurations

The machines that compose a three-server redundant configuration are required to have excellent communications. This form of redundancy requires that the servers exchange heartbeats periodically, and poor communications can cause poor performance. Avoid configuring redundant servers with slow communications or dial-up links.

Maintain an identical copy of the license file (as well as the lmgrd and the vendor daemons binaries) locally on each server machine rather than on a file server. If you do not do this, you lose all the advantages of having redundant servers, since the file server holding these files becomes a single point of failure.

Three-server redundant configurations are specified by including three SERVER lines in the license file. The set of three SERVER lines must appear in the same order with each line for a given server being identical across all three files. At any given moment in time, lmgrd has a notion of the master server, whose duties include:

By default the primary server is the master; the method of transitioning the master server duties, in case of primary server failure, is controlled by the PRIMARY_IS_MASTER parameter.

Why are three license server systems required in a redundant configuration?

In order to provide for license server system failover, multiple redundant server systems, each running on their own machine, must be able to serve the same set of counted licenses. However, to ensure consistency and security of the software publisher's licenses, these redundant license server systems must ensure that only one of them can serve licenses at any one time.

A given set of counted licenses is bound to the hostids of a specific number of redundant license server machines via SERVER lines in the license file. In this way, each license server system knows how to communicate with the other redundant license server systems that are bound to the same set of counted licenses. Upon startup, each server system determines whether or not it can communicate with the other redundant license server systems. A group of redundant license server systems is formed when all members of the group can each communicate with all others in that same group.

Once a group is formed, the group guarantees that only one of its license servers can serve licenses at any one time. However, FLEXnet Licensing must ensure that only one such group will be formed from the total number of redundant license servers. To ensure that there is only one group that is formed, only the group that contains greater than one half of the redundant license servers allows itself to serve licenses. This group of license servers is called the majority. License servers that are not part of the majority, including single license servers that cannot communicate with any other of its redundant license servers, refuse to serve licenses. License servers that are not part of the majority continue to run, but only so that they can continue their attempt to join the majority or form a majority if no majority yet exists.

If a license server system ever detects that it is no longer in communication with the majority, it refuses to serve licenses until it can. If the members of the majority determine that they have lost communication with enough other license servers that they have lost the majority, they refuse to serve licenses.

If FLEXnet Licensing allowed a set of counted licenses to be bound to only two redundant license server systems, then, by the rules above, only a group that contains greater than one half of the total number of redundant license servers would allow itself to serve licenses. For a group of only two, this would mean both license servers would have to remain in constant communication and neither could fail. That is, the only number greater than one half of two is two, which is not a fail-over solution.

Because of the requirement for a majority, the obvious number of redundant license server systems to use is an odd number. Using an even number of license servers would require an extra license server to be part of the majority without adding value. For simplicity, FLEXnet Licensing only supports three redundant license servers because three is the smallest odd number greater than one.

See Also

USE_SERVER Line

USE_SERVER takes no arguments and has no impact on the server. When the application sees USE_SERVER, it ignores everything in the license file except preceding SERVER lines and transfers checkout validation to the vendor daemon.

USE_SERVER is recommended since it improves performance when a license server system is used. For uncounted features, USE_SERVER is used to force logging of usage by the daemons.

FEATURE/INCREMENT Lines

A FEATURE line describes the license required 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.

Field	Description
`vendor`	Name of the vendor daemon used to serve some feature(s) in the file. This name cannot be changed by the administrator.
`vendor_daemon_path`	Optional path to the executable for this daemon. Generally the license administrator is free to install the daemon in any directory. (It is recommended, however, that it be installed in a local directory on the license server machine.) If omitted, `lmgrd` looks for the vendor daemon binary in the current directory the path specified in `lmgrd's` $PATH environment variable in the directory where `lmgrd` is located If `vendor_daemon_path` is blank, then any options or TCP/IP port number specifications require the `OPTIONS=` and `PORT=` strings.
`options_file_ path`	Full path to the end-user options file for this daemon. FLEXnet Licensing does not require an options file. If omitted, the vendor daemon, by default, looks for a file called `vendor.opt` (where `vendor` is the vendor daemon name) located in the same directory as the license file.
`port`	Vendor daemon TCP/IP port number. The default, if `port` is not specified, is chosen by the operating system at run-time. Sites with Internet firewalls need to specify the TCP/IP port number the daemon uses. If a TCP/IP port number is specified on the VENDOR line, there may be a delay restarting the vendor daemon.

Only the first FEATURE line for a given feature is 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, or pools, based on the following fields:

If two lines differ by any of these fields, a new group of licenses, called a license pool, is created in the vendor daemon, and this group is counted independently from other license pools with the same feature name. A FEATURE line does not give an additional number of licenses, whereas an INCREMENT line always gives an additional number of licenses.

{FEATURE|INCREMENT} feature vendor feat_version exp_date \
num_lic SIGN=sign [optional_attributes]

The six fields after the FEATURE/INCREMENT line keyword are required and have a fixed order. They are defined by the vendor and cannot be changed. Table B-1 presents these fields in the order they must appear.

Table B-1: FEATURE/INCREMENT Line Required Fields
Field	Description
`feature`	Name given to the feature by the vendor.
`vendor`	Name of the vendor daemon; also found in the VENDOR line. The specified daemon serves this feature.
`feat_version`	Version of this feature that is supported by this license.
`exp_date`	Expiration date of license in the format `dd-mmm-yyyy`, e.g., 07-may-2005. Note: If `exp_date` is the string "permanent" or the year is 0 (or 00, 000, 0000) then the license never expires.
`num_lic`	Number of concurrent licenses for this feature. If the `num_lic` is set to the string "uncounted" or 0, the licenses for this feature are uncounted and no `lmgrd` is required but a hostid on the FEATURE line is required. See "Counted vs. Uncounted Licenses."
`SIGN=sign` or AUTH=...	SIGN= signature to authenticate this FEATURE line. If your publisher has deployed his vendor daemon using the common vendor daemon technology, license certificate signatures are embedded within the AUTH= keyword. Contact your publisher for further details.

Table B-2 lists attributes that may appear in a FEATURE or INCREMENT line. They are supplied at the discretion of the vendor to provide particular licensing behavior. If present in the FEATURE or INCREMENT line, they must remain there and cannot be altered by the end user. These attributes have a keyword=value syntax where keyword is in uppercase.

In places where value is a string surrounded with double quotes ("..."), the string can contain any characters except a quote.

Table B-2: Vendor Supplied Attributes
Attribute	Description
`BORROW[=n]`	Enables license borrowing for a particular FEATURE/INCREMENT line. `n` is the number of hours that the license is borrowed. The default borrow period is 168 hours, or one week.
`DUP_GROUP=...`	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 for a user on the same host and display, additional uses of a feature do not consume additional licenses.
`FLOAT_OK [=server_hostid]`	Enables mobile licensing via FLEXid with FLOAT_OK for a particular FEATURE/INCREMENT line. This FEATURE/INCREMENT line must also be node-locked to a FLEXid. When FLOAT_OK=`server_hostid` is specified on a FEATURE line: The `server_hostid` must refer to the same host that appears on the SERVER line of the license file. The license server system runs only on the machine with the hostid that `lmhostid` returns equal to the `server_hostid` specified with FLOAT_OK.
`HOSTID=` `"hostid1 [hostid2 ... hostidn]"`	Id of the host to which the feature line is bound. `hostid` is determined with the `lmhostid` utility. This field is required for uncounted licenses; but can be used for counted licenses as well. See Appendix A, "Hostids for FLEXnet Licensing-Supported Platforms," for more information.
`HOST_BASED[=n]`	Host names must be specified in INCLUDE statements in the end-user options file, and the number of hosts is limited to `num_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=n`	The overdraft policy allows your vendor to specify a number of additional licenses which users are 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 license limit is reported by the FLEXnet Manager reporting tool.
`PLATFORMS="..."`	Usage is limited to the listed platforms.
`SN=serial_num`	Serial number, used to identify FEATURE or INCREMENT lines.
`START=dd-mmm-yyyy`	Start date.
`SUITE_DUP_GROUP=...`	Similar to DUP_GROUP, but affects only the enabling FEATURE line for a package suite. It limits the total number of users of the package to the number of licenses, and allows the package to be shared among the users that have the SUITE checked out.
`SUPERSEDE="f1 f2 ..."`	If this appears, all licenses issued before the date specified in `ISSUED=` are superseded by this line and become ineffective.
`TS_OK`	FLEXnet Licensing detects when a node-locked uncounted license is running under Windows Terminal Server. To run the application via a Terminal Server client window, `TS_OK` must be added to the FEATURE line. Without `TS_OK`, a user running on a Terminal Server client is denied a license.
`USER_BASED[=n]`	Users must be specified in INCLUDE statements in the end-user options file, and the number of users are limited to `num_lic`, or the number specified in `=n`.
`VENDOR_STRING= "..."`	Vendor-defined string, enclosed in double quotes.

The following attributes listed in Table B-3 are optional and are under control of the end user. These attributes have a keyword=value syntax where keyword is in lowercase.

Table B-3: End-User Attributes
Attribute	Description
`asset_info="..."`	Additional information provided by the license administrator for asset management.
`dist_info="..."`	Additional information provided by the software distributor.
`sort=nnn`	Specifies sort order of license file lines. See "Order of Precedence."
`user_info="..."`	Additional information provided by the license administrator.
`vendor_info="..."`	Additional information provided by the software vendor.

FEATURE sample_app sampled 2.300 31-dec-2005 20 \
        SIGN=123456789012
INCREMENT f1 sampled 1.000 permanent 5 \
        HOSTID=INTERNET=195.186.*.* NOTICE="Licensed to \
        Sample corp" SIGN=901234567890

Order of Precedence

FEATURE/INCREMENT license file lines are automatically sorted when they are processed by FLEXnet Licensing; the default sorting rules are is as follows:

To turn off automatic ordering add sort=nnn to the FEATURE/INCREMENT line, where nnn is the same on all lines; nnn specifies the relative sort order. The default sort order value is 100. Lines with a sort order value of less than 100 are sorted before all lines without this attribute, and lines with a sort order value greater than 100 appear after all unmarked lines. All lines with the same number are sorted as they appear in the file.

Pre-v7.1 FEATURE/INCREMENT line format uses license_key:

{FEATURE|INCREMENT} feature vendor feat_version exp_date
num_lic license_key [optional_atributes]

The pre-v7.1 format is understood by the current client library and vendor daemon.

The SIGN= keyword introduced in the v7.1 client library and vendor daemon.

For v7.1 through v8.0 client libraries and vendor daemons, the FEATURE/INCREMENT line must have a SIGN= signature and, for backward compatibility with pre-v8.1, can contain a license_key:

{FEATURE|INCREMENT} feature vendor feat_version exp_date \
num_lic [license_key] SIGN=sign \ [optional_attributes]

license_key obsoleted in v8.1 client library and vendor daemon

The keyword "permanent" for exp_date introduced in v6 client library.

The keyword "uncounted' for num_lic introduced in v6 client library.

BORROW keyword introduced in v8.0 client library and vendor daemon.

FLOAT_OK keyword introduced in v8.0 client library and vendor daemon.

TS_OK keyword introduced in v8.0 client library and vendor daemon.

AUTH keyword introduced in v10.8 client library and vendor daemon.

PACKAGE Lines

A PACKAGE line, by itself, does not license anything-it requires a matching FEATURE/INCREMENT line to license the whole package. A PACKAGE line is 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 lines enable the PACKAGE line.

PACKAGE package vendor [pkg_version] COMPONENTS=pkg_list \
[OPTIONS=SUITE] [SUPERSEDE[="p1 p2 ..."] ISSUED=date]
SIGN=pkg_sign

Table B-4: PACKAGE Line Fields
Field	Description
`package`	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`	Optional field specifying the package version. If specified, the enabling FEATURE/INCREMENT line must have the same version.
`COMPONENTS=pkg_list`	List of package components. The format is: `feature[:version[:num_lic]]` 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. `num_lic` is only legal if `OPTIONS=SUITE` is not set-in this case the resulting number of licenses is `num_lic` 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`	Optional field. Used to denote a package suite. If set, the corresponding feature of the same name as the package is checked out in addition to the component feature being checked out. If not set, then the corresponding feature of the same name as the package is removed once the package is enabled; it is not checked out when a component feature is checked out.
`OPTIONS= SUITE_RESERVED`	Optional field. If set, reserves a set of package components. Once one package component is checked out, all the other components are reserved for that same user.
`SUPERSEDE [="p1 p2 ..."]`	Optional field. Used in conjunction with ISSUED date. Replaces all PACKAGE lines for the same package name with ISSUED dates previous to `dd-mmm-yyyy`.
`ISSUED=`dd-mmm-yyyy	Optional field. Used in conjunction with SUPERSEDE. Replaces all PACKAGE lines for the same package name with ISSUED dates previous to dd-mmm-yyyy.
`SIGN=sign` or AUTH=...	SIGN= signature to authenticate this FEATURE line. If your publisher has deployed his vendor daemon using the common vendor daemon technology, license certificate signatures are embedded within the AUTH= keyword. Contact your publisher for further details.

PACKAGE suite sampled 1.0 SIGN=3B24B2F508CB \
COMPONENTS="comp1 comp2" OPTIONS=SUITE
FEATURE suite sampled 1.0 1-jan-0 5 SIGN=4193E6ABCCCB

This is a typical OPTIONS=SUITE example. There are two features, "comp1" and "comp2," which are each version 1.0, each with five non-expiring licenses available. When "comp1" or "comp2" is checked out, "suite" is also checked out.

PACKAGE suite sampled 1.0 SIGN=2CBF44FCB9C1 \
COMPONENTS="apple:1.5:2 orange:3.0:4"
FEATURE suite sampled 1.0 1-jan-2005 3 SIGN=321E78A17EC1 SN=123

In this example, the component version overrides the feature version, and the number of licenses available for any component is the product of the three licenses for "suite" and the number of licenses for that component. The result is equivalent to:

FEATURE apple sampled 1.5 1-jan-2005 6 SIGN=0D3AD5F26BEC SN=123
FEATURE orange sampled 3.0 1-jan-2005 12 SIGN=EB16C5AE61F0 SN=123

UPGRADE Lines

UPGRADE feature vendor from_feat_version to_feat_version \
exp_date num_lic [options ... ] SIGN=sign

All the data is the same as for a FEATURE or INCREMENT line, with the addition of the from_feat_version field. An UPGRADE line removes up to the number of licenses specified from any old version (>= from_feat_version) and creates a new version with that same number of licenses.

INCREMENT f1 sampled 1.000 1-jan-2005 5 SIGN=9BFAC0316462
UPGRADE f1 sampled 1.000 2.000 1-jan-2005 2 SIGN=1B9A308CC0F7

An UPGRADE line operates on the closest preceding FEATURE or INCREMENT line with a version number that is >= from_feat_version, and < to_feat_version.

Decimal Format

Licenses can be represented in decimal format. Decimal has the advantage that it's simpler to type in, and often the licenses are much shorter.

If needed, decimal lines can be mixed with readable format lines in a license file. Use the lminstall command to convert decimal licenses to readable format.