Alias Licenses

Alias licenses are licenses that define themselves in terms of another license. You can think of an alias license as the nodelocked version of a token license.

Alias licenses are processed by the client only; they are never processed by the server. Here are some differences between token-based and alias licenses:

	Token-based License	Alias License
Where processed	Always on the server. Token-based licenses are ignored by the client.	Processed only by the client. Must be in a local license file. The server ignores alias licenses.
# of target licenses	Any number	One only
Target license(s)	Must be served	Can be nodelocked or served.
Nesting	Up to 20 levels	None allowed

For example, an application could request a license for product write. If this were a normal license, the product write would appear in the license file (if the request succeeds) with a license count (or uncounted). On the other hand, if this were an alias license, the product write would appear in the license file without a count, but with a specification of one other product which is used to satisfy the request. When the client encounters a request for an alias license, it uses the other product specified in the license to satisfy the request, rather than the originally requested product. This other license is called the primary license. The primary license can be either another nodelocked license or a served license.

An alias license is similar in syntax to a token-based license; both differ from a normal license in a few significant ways:

The count field contains one of the keyword alias rather than an integer, uncounted, or single.
The license has an alias spec: alias=”<prod ver count>”
The only optional parameters on an alias license which are used by RLM are the start date, and the hostid. All other optional parameters are ignored.
License Administration option processing is different for alias licenses. See License Administration Options.
There are a few restrictions on alias licenses, especially for queuing. See Restrictions on alias licenses.

Example of an alias Licenses

When a product is specified as an alias license, requests for that product are turned into requests for the primary license specified in the alias= part of the license. For example, consider this license for product test (primary license dollars):

LICENSE reprise test 1.0 permanent alias sig=xxxx alias="<dollars 2.0 5>"

LICENSE reprise dollars 2.0 permanent uncounted hostid=abcdef01 sig=xxxx

A request for the product “test”, v1.0 will check out “dollars”, v2.0

Issues with roaming

Since an alias license is processed by the client, it cannot roam.

The License Count Keyword

In an alias license, the count keyword is “alias”.

If you want the alias license usable only on a single host, include the “hostid=xxx” keyword in the alias license itself.

The alias= keyword

In an alias license, the alias= keyword specifies the primary license which is checked out in response to a request for the alias license itself. Specify only one license to be checked out. Although the syntax processing is the same as for token-based licenses, only the first product specified will be used. These licenses also cannot be alias licenses themselves. The format is:

alias="<product1 ver1 count1>"

The request for the one of the original licenses turns into a checkout of count1 of product1, ver1

Nesting alias licenses

Unlike token-based licenses, which can be nested 20 levels deep, alias licenses cannot be nested.

Restrictions on alias licenses

There are fewer restrictions on alias license than on a token-based license:

All alias licenses are processed by the client, so there can be no floating alias licenses, in fact, the license server completely ignores alias licenses.
The mapping from an alias license to its primary license will attempt to find the primary license wherever it can, either node-locked, or on any license server.
You can queue for the primary license of an alias(ed) license.

Report Log

When an alias license is checked out, if the primary license comes from a license server, the name and version of the primary license is logged.

License Administration Options

All options affect the primary licenses.

Use cases for alias licenses

There are three main uses for alias licenses, the 2^nd and 3^rd are the same as for token-based licenses.

Perhaps the most compelling use of an alias license is in conjunction with Activation Pro. If you sell several different product bundles, your options for doing that are either to issue independent licenses for all the products in the bundle, or to use an options= keyword in a single RLM license and decode the options in your product.

The second approach has a couple of disadvantages: (1) you have to process the options yourself, and, more importantly (2) it becomes nearly impossible for your customer to select which bundle they want to check out. The first approach (separate licenses) is easier for everyone, until you get to issuing activation keys for the bundle. No one wants to issue N independent activation keys. Using alias licenses allows you to avoid this. Let’s say you have 4 products: a, b, c, and d, which you sell as 3 different bundles: x, y, and z. With alias licenses, you can do the following, assuming you want a and b in bundle x; a, b, and c in bundle y; and a, b, c, and d in bundle z:

Create static definitions of the bundles, as follows:
- alias a to x
- alias b to x
- alias a to y
- alias b to y
- alias c to y
- alias a to z
- alias b to z
- alias c to z
- alias d to z
These alias definitions can be shipped with your product, or updated when you have new bundle definitions. The point is that they are the same for all your customers, and they are independent of your code.
When your customer purchases bundle y for example, issue them an activation key for product y. Now RLM will allow them to check out a, b, and c, based on those alias lines, but not d.

The second use of an alias license allows a license administrator to mix-and-match different products as their needs change. If several products are all defined in terms of a single pool of primary licenses, the license administrator can control license usage as needs demand. This can be a benefit to both ISVs and their customers, since as new products are introduced, if they are licensed based on the same primary license, all customers instantly have access to the new products without having to go through a purchaseorder cycle.

A third use of an alias license is to allow alternate licenses to satisfy a request for a product. To use the familiar example, if product write checks out a write license, the addition of an alias license for write mapping it to office would allow an office license to be used in the case where no write licenses are available. Even though the office license is a more expensive license, the customer is allowed to continue working by consuming the more expensive office license. Several alias licenses can be used in this way, and the order of the licenses in the license file will determine the order that alternate checkouts are attempted.